Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Zeus SCADA System Technical Specification
Document related concepts
Transcript
Zeus SCADA system All rights reserved. ©Copyright Prolan Power Co. Passing on and copying of this document, use and communication of its contents not permitted without written authorization by Prolan Power Co. ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Revision history # Date Editor Amendment 100 30. April 2014. Székely A First version. 101 22. May 2014. Székely A Small changes 102 03- JUne 2014. Székely A IED functions added 3/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Table of Contents 1. Introduction ................................................................................................................... 5 1.1. Table of abbreviations ......................................................................................... 5 1.2. Intended audience .............................................................................................. 5 1.3. Reference documents ......................................................................................... 6 2. System design................................................................................................................ 7 2.1. Configuration principle ........................................................................................ 9 3. System configuration ................................................................................................. 12 3.1. Process configuration ......................................................................................... 12 3.2. Dual system configuration ................................................................................. 16 3.3. Data Communication ........................................................................................ 18 3.4. Data archive ........................................................................................................ 20 3.5. Graphical display ................................................................................................ 21 3.6. Authority control .................................................................................................. 30 3.7. Alarm system ........................................................................................................ 43 3.8. Time management ............................................................................................. 31 3.9. Security ................................................................................................................. 33 4. Functions and configuration parameters ............................................................... 35 4.1. Main functions of the Zeus SCADA system ...................................................... 35 4.2. Other functions of the Zeus SCADA system .................................................... 61 4.3. System Diagnostics.............................................................................................. 64 5. Configuration tools ..................................................................................................... 66 6. Appendix A .................................................................................................................. 67 4/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 1. Introduction The present documentation is the technical documentation of Prolan’s ZEUS SCADA system. The description highlights important functions of the system together with application examples. Topics covered include system architecture, communication methods, reliability considerations, graphical user interface. System configuration, database and picture editor descriptions are not included in this document. 1.1. Table of abbreviations The following table details the abbreviations used throughout the document and describes their respective meaning: Abbreviation Definition CO Controlled Object DP Double Point signal GUI Graphical User Interface HMI Human Machine Interface IEC101 Data communication protocol according to IEC 60870-5-101 standard IEC103 Data communication protocol according to IEC 60870-5-103 standard IEC104 Data communication protocol according to IEC 60870-5-104 standard IEC61850 Standard for the design of electrical substation automation I/O Input/Output LACP Link Aggregation Control Protocol MMI Man Machine Interface NTP Network Time Protocol OEM Original Equipment Manufacturer PLC Programmable Logic Controller PSDC Power Supply Dispatcher Centre RBAC Role Based Access Control RTU Remote Terminal Unit RHEL Red Hat Enterprise Linux SCADA Supervisory Control And Data Acquisition SP Single Point signal UPS Uninterruptible Power Supply Yabasic Yet Another Basic (programming language) Table 1 Table of Abbreviations 1.2. Intended audience The present technical document is intended to be used by: designers and system engineers responsible to configure SCADA systems using ZEUS SCADA 5/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION designers and system engineers responsible to configure other control systems that have interface with ZEUS SCADA 1.3. Reference documents The following documents are related with ZEUS SCADA system configuration: Document name ZEUS Database Filling-In Guide Proedit picture editor ZEUS configuration guide ProField-IED Technical Documentation 6/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 2. System design The ZEUS SCADA is a high level process control system which consists of software modules developed by Prolan. The ZEUS SCADA system runs on Red Hat Enterprise Linux (RHEL) operating system using computers certified for RHEL, e.g HP. The ZEUS SCADA can also run on CentOS Linux operating system which is considered to be identical with RHEL only without special support for the above mentioned hardware vendors. Presently all reference systems operate with Red Hat operating system. The ZEUS SCADA system has a highly scalable architecture. That means it is appropriate to use it in small, medium and large applications. The smallest applications are Local MMI for control systems of power, oil, gas or water industries. In these applications the ZEUS SCADA usually runs on a single computer having one or two monitors or panel PCs, and it is used to control and monitor data related to a relatively small area or technological segment. Examples: Local MMI of 120/20 kV power substations E-ON Hungary, Local Control Panel of train station disconnectors - Izmir, Turkey. Middle-size applications are Local MMI of large electrical substations or other industry applications or Control Centres of smaller areas. In these applications the ZEUS SCADA is configured to run on single or multiple computers. Typical architecture: dual server - multiple workstations with multiple monitors. Extended communication networks are usually part of system configuration. Example: Bulgarian Railway Power Supply Dispatching Centre Plovdiv. Large applications are Control Centres of large areas, such as power grids. System configurations are based on dual server, multiple workstations, and large communication networks, including Engineering and maintenance facilities. Example: Hungarian Power Grid Control Centre - MAVIR. The system configuration depends on the complexity of the monitored and controlled technology, as well as the availability requirements. High level of availability can only be attained by duplicating critical elements of the system. The most critical elements are the SCADA servers and the communication network. In high availability systems the servers of the Zeus system are operating in dual hot-standby mode. In this mode both the primary and the secondary servers are running data processing functions in parallel. 7/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION The following schema shows typical system architecture for medium/large applications: Workstation 1 Engineering Workstation 2 Maintenance Printer Time Server GPS/NTP H E W L E T T P A C K A R D HP LP2045W HP LP2045W input auto auto input HP LP2045W auto HP LP2045W input HP LP2045W auto input auto HP workstation xw4600 input HP workstation xw4600 HP workstation xw4600 HP LP2045W HP LP2045W auto input HP LP2045W input auto auto HP LP2045W input HP LP2045W input auto auto input SCADA network Catalyst 2950 SERIES 10Base-T/100Base-TX SYST 1 2 3 4 5 6 7 8 9 10 11 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 15 16 17 18 19 20 21 22 23 24 A 100Base-FX B RPS STRT UTIL DUPLXSPEED MODE Catalyst 2950 SERIES 10Base-T/100Base-TX SYST 12 13 14 A 100Base-FX B RPS STRT UTIL DUPLXSPEED MODE Dual LAN Primary Server 1 2 3 4 5 6 7 8 1 HP ProLiant DL385 G2 PCI RISER CAGE POWER POWER SUPPLY SUPPLY PPM PPM POWER POWER SUPPLY SUPPLY DIMMS Secondary Server DIMMS DIMMS 2 3 4 5 6 7 8 PCI RISER CAGE Firewall HP ProLiant DL385 G2 DIMMS CISCO ASA 5510 SERIES Adaptive Security Appliance POWER STATUS ACTIVE VPN FLASH PROC PROC PROC PROC INTER LOCK INTER LOCK FANS FANS OVER TEMP OVER TEMP MIRROR MIRROR 1 UID 2 UID 1 2 Customer network Communication equipment Model Cisco 828 ETHERNET 10 BASE T TO HUB TO PC 4 3 2 LAN +5, +12, -12, -24, -71 VDC CONSOLE G.SHDSL 1 RAID Unit HP LP2045W auto input HP workstation xw4600 Data transmission newtwork Maintenance Model Cisco 828 ETHERNET 10 BASE T TO HUB TO PC 4 Communication equipment 3 2 Remote terminal +5, +12, -12, -24, -71 VDC CONSOLE G.SHDSL Technology network 1 Model Cisco 828 ETHERNET 10 BASE T TO HUB TO PC 4 3 2 CONSOLE Model Cisco 828 +5, +12, -12, -24, -71 VDC G.SHDSL 1 RTU 1 ETHERNET 10 BASE T TO HUB TO PC 4 3 2 CONSOLE Model Cisco 828 +5, +12, -12, -24, -71 VDC G.SHDSL 1 RTU 2 ETHERNET 10 BASE T TO HUB TO PC 4 3 2 CONSOLE LAN +5, +12, -12, -24, -71 VDC G.SHDSL 1 RTU 3 Maintenance ZEUS system structure In this architecture all typical elements are included; the elements of the system can be flexibly configured in various ways: The LAN network of the SCADA system can be either single or dual, depending on the required availability. Network of RTUs can be also dual. In this case each RTU must have two interfaces towards the SCADA, one for each server. RAID storage: o RAID 5+1: typical when using external RAID array - using 4 or more Hard Disks o RAID 1: typical for servers’ internal RAID - using 2 Hard Disks Remote equipment can be connected to the system using a firewall for security, such as: maintenance notebook or a remote terminal for accessing the SCADA database. Number of SCADA workstations can be increased in such a way, that the total number of operator terminals (monitors) cannot exceed 64. Maximum number of RTUs is virtually unlimited (limited only by hardware constraints; the number can be increased using data concentrators as interface). 8/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION The workstations are connected to the Primary server as clients. The workstations are running only graphical interface processes (and also alarm and internal diagnostic processes). All data displayed on the screens and in the event logs originate from the Primary Server. All control- and setpoint commands are executed by the Primary Server. 2.1. Configuration principle The ZEUS SCADA system is developed in such a way to provide very fast processing and response times without excessive hardware requirements. Hardware requirements depend mostly on the size of the application. Parameters that affect the sizing: number of controlled objects number of historical data and required storage time number of RTUs number of screens type of configured SCADA functions; there are some functions that may need higher hardware requirements; e.g. Java-based applications. single- or dual configuration. In dual configuration additional processes have to be configured to ensure synchrony of database and historical data. Single system ZEUS system can be configured to run on a single computer. In this configuration the server and clients processes run on the same computer. Hardware requirements (PC): Minimum Proposed 1 GHz x86_32 or x86_64 system 512 MB RAM 2 GHZ or higher multicore x86_32 or x86_64 system 40 GB HD (SATA) 256 GB HD (SATA) or higher Graphic card with 128 MB memory Graphic card with 128 MB or more memory 1 GB or more RAM Dual system Hardware requirements (server): Minimum Proposed 1 GHz x86_32 or x86_64 system 2 GB RAM 2 GHZ or higher multicore x86_32 or x86_64 system 36 GB HD (SAS) 36 GB HD (SAS) or higher Graphic card with 64 MB memory Graphic card with 64 MB or more memory 4 GB or more RAM Hardware requirements (client): 9/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Minimum Proposed 1 GHz x86_32 or x86_64 system 2 GB RAM 2 GHZ or higher multicore x86_32 or x86_64 system 36 GB HD (SAS or SATA) 36 GB HD (SAS or SATA) or higher Graphic card with 128 MB memory Graphic card with 128 MB or more memory 4 GB or more RAM o NOTE: The graphic card’s memory requirement depends on the size of the monitor(s) to be used. Dual system In order to obtain high availability, the servers shall be configured to operate in dual hot-standby mode. This can be achieved in two ways: dual hot-standby using external RAID - Only the Primary server runs all SCADA tasks, the Secondary server only runs diagnostic processes, ready to take over the duty in case of Primary server failure; on-line database and historical data are stored only on the RAID unit. o Advantage: robust data storage due on external RAID unit, no need to synchronize two databases and historical data. o Disadvantages: data processing gap in case of Primary server failure (the Secondary server needs to start all SCADA processes); however data loss is prevented by RTU storage function - all events occurred during takeover time will be sent to the new Primary server. External RAID units are expensive, system power consumption and maintenance need is higher. dual hot-standby without using external RAID - both servers run all SCADA tasks independently, and each server communicates with each RTU simultaneously. The only difference between the roles of the Primary and Secondary servers is the tasks that send control commands and setpoints to the COs (Controlled Objects). These tasks run only on the Primary server. The real-time database and the event logs are stored on both servers. o Advantage: no data processing gap in case on Primary server failure, seamless takeover. Cost-efficient solution (no need to buy expensive external RAID), lower power consumption, less maintenance need. o Disadvantages: more LAN bandwidth used, because all RTUs have to communicate with both SCADA servers. Control command can be initiated only by the Operator logged-in with the necessary authority. If no operator is logged-in, the workstation can only monitor the COs. 10/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION In case that the Primary server fails, the Secondary server automatically takes over the duty and becomes the Primary server. Then all Workstations will reconnect to this server. During the reconnection phase the GUI of the workstations will restart. There will be no data loss during Primary server takeover. Duration of the takeover process and the MMI restart is around 10 seconds. It is recommended to use an Engineering Workstation to provide possibility of system maintenance: Configuration of the picture system and the configuration files. Operation as backup workstation. Operation as playback workstation. Functions of the Zeus SCADA system 11/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 3. System configuration The ZEUS SCADA system is based on client-server architecture. The core of the SCADA system consists of software modules that operate as data server and communication server. The client modules run the graphical user interface modules and they connect to the server modules to get the necessary data. It is possible to run server and client processes on the same computer. 3.1. Process configuration The ZEUS SCADA system runs several processes at a time. A part of the processes are called server processes; these are the processes that manage the data transmission, storage, status evaluation, etc. Another part of the processes are client processes which provide the interface for the operator; these are graphical processes that are displaying schemes and data lists, also alarm process providing audible alarm. Server modules (in alphabetical order): Module name Description alarmd alarm management process checktim time management process control evcentr evlogd hamon Note necessary when using IEC101 or IEC104 commands for time setting control command process in hot-standby mode runs only on the Primary server event server - creates client module; runs only together with msgserver event log files Postgres sql-based event client module; runs only together with msgserver server dual server role manager; used only in dual systems sets the Primary and Secondary server modes iec870_101 IEC101 process communication iec870_104 IEC104 process communication interpreter logical calculation process msgserver internal process proc processing module - sets the status and value of data programmable using Yabasic programming language communication data link between processes 12/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION playback_archiver rqserver playback function archiver runs on Primary Server process core process of the SCADA database server system runner management of running processes SAGateway communication process setpoint setpoint process simul simulation process only for testing topol2 topology analyser process trserver watchdog alarmlist_gui communication gateway for IEC 61850, IEC 103 and Modbus devices in hot-standby mode runs only on the Primary Server used voltage-dependent colouring function analogue trend archiving xview contains a graphical trend viewer program process assures the stop and/or checks the availability of restart of critical processes rqserver, msgserver processes runs only together with alarmd alarm list EventLog only together Java- and Postgres SQL runs rqserver and evlogd based event log playback_archiver playback function proedit graphical program voiced sound alarm process xevent Event log (tex-based) xview watchdog screen only editor runs rqserver together with with generating runs only together with alarmd process runs only together with rqserver and msgserver only together with Screen display process, runs rqserver part of SCADA software GUI assures the stop and/or checks the availability of restart of critical processes rqserver process Client modules (in alphabetical order): Module name Description Note alarmlist_gui alarm list EventLog runs only together Java- and Postgres SQL rqserver and evlogd based event log runs only together with alarmd with playback_ playback_data_server_sql runs only together with playplayback function client back_archiver process 13/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION runs only editor rqserver proedit graphical program voiced sound alarm process xevent Event log (tex-based) screen generating together with runs only together with alarmd process runs only together with rqserver and msgserver runs only together with Screen display process, rqserver part of SCADA software GUI xview NOTE: there is a number of special software modules developed for special functions (e.g. video camera control); they are not included in the above list. The below charts contain the necessary processes for the main SCADA functions. Core processes of ZEUS (they are necessary for every function): ZEUS Function/ required process runner rqserver msgserver proc Core processes YES YES YES YES iec870_101 or iec870_104 YES checktim YES Processes of ZEUS necessary for specific functions: ZEUS Function/ required process xview YES xevent or evlogd - alarmd control alarmlist_gui command voiced - Basic signal and measurement display including access control, data lists event log - YES - alarm, alarm log - - YES control command YES trend display YES voltage-dependent colouring YES trserver topol2 YES YES YES In addition to the above processes they are a number of special functions that need different processes to be started. Also in case of dual system configuration an additional process has to be configured: ZEUS Function Playback Calculations Simulation required process playback_archiver playback_ data_server_sql interpreter simul note server process client process server process server process 14/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Dual system management Diagnostic hamon to be used in dual system; runs on both servers process runs both on servers and client computers watchdog Simplified block scheme of client-server and communication processes: ZEUS client Core processes: - xview - xevent - voiced - alarmlist - evlogd - watchdog ZEUS server Core processes: - rqserver - msgserver - proc - watchdog - alarmd - trserverl - control - setpoint - SAGateway Communication processes: IEC104 server - IEC104 (client) IEC103 client Relay IEC103 (server) RTU IEC104 (server) MODBUS master PLC MODBUS (slave) IEC 61850 RTU IEC 61850 The full list of ZEUS directories and files is given in Appendix A. 3.2. Start and stop Starting of the SCADA system is realised by the use of operating system functionality at service level. For this a separate service is created called ‘xgramservers’. To start the SCADA system automatically this service must be configured in run levels 3, 4, 5 and 0. Running of ZEUS processes is managed by so-called ‘runner’ processes. The runner processes are configured in configuration files called also ‘runners’. Such runners are created separately for server and client processes. Detailed description of system’s start and stop can be found in the ZEUS configuration guide. 15/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 3.3. Dual system configuration Dual system is used in applications that require high availability. Typically the SCADA servers and LAN network elements are duplicated. Dual systems usually include more workstations and one engineering workstation. In dual system one of the SCADA servers runs as Primary and the other server as Secondary. The RTUs are connected to both servers. 3.3.1. Dual system management The management of the dual function is done by the hamon process. ‘hamon’ process is configured to run only in dual system. It is started in every server as part of runner configuration. The primary task of hamon is to determine which computer will be the Primary Server and which the Secondary Server. In principle the computer which starts first will become the Primary and the second the Secondary. Configuration After start-up the Secondary server will watch the availability of the Primary server through communication interfaces configured in the hamon.ini file which is located here: Runner configuration: Client process <application dir>/bin/hamon Configuration file: <application dir>/config/servers/hamon.ini Parameters: Parameter -c <config file> Description -i 01 -i 02 identity (server1) identity (server2) config file located here: <application dir>/config/servers/hamon.ini Typically the following interfaces are configured in hamon.ini: Parameter network device remote server name name of common server Description typically ‘bond0’ in case of dual network configuration typically ‘server1’ and ‘server2’ typically ‘server’ The common server is a virtual server created by the Primary server. All clients are connected to this server thus allowing to clearly identifying the Primary server at all times. The dual status of the servers is set in the run-time database (can be displayed by graphical object) and also in a file. The file that contains the dual status is located here: Path <application dir>/trace/hamon/ha 16/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 3.3.2. Dual network Dual network configuration relies on duplicated network elements. This usually means two switches and two Ethernet cards in every computer. When configuring the computers running ZEUS SCADA system, the following configuration is proposed: link aggregation which is a method of combining multiple network connections in parallel. The proposed link aggregation method is the LACP bonding. The Red Hat Enterprise Linux kernel supports creating a so-called ‘bond’ device by combining the two Ethernet devices. Configuration The configuration is done in the following files: Path /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth1 /etc/sysconfig/network-scripts/ifcfg-bond0 Configuration syntax ifcfg-eth0 MASTER=bond0 SLAVE=yes Configuration syntax ifcfg-eth1 MASTER=bond0 SLAVE=yes Configuration syntax ifcfg-bond0 DEVICE=bond0 IPADDR=192.168.1.1 NETMASK=255.255.255.0 GATEWAY=192.168.1.254 The link aggregation mode is set in the following configuration file: Path /etc/modprobe.conf Configuration syntax alias bond0 bonding options bond0 miimon=100 mode=4 lacp_rate=1 The LACP mode has to be configured also in the switches for the ports where the SCADA computers are connected. 17/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 3.4. Data Communication The main functionality of the SCADA system is to collect data from the RTUs, store and use this data to display the facilities to the operator, also allowing the remote control of devices in the system. The Zeus SCADA system communicates with the RTUs via the following data transmission protocols: 3.4.1. IEC60870-5-101 This communication module has the following configuration possibilities: Parameter role in communication communication port communication speed (bit/sec) parity frame length stop bit repeat count link address CAD group ProcServicePort test TIME setting diagnostic features message types Value Unbalanced Master serial port 1200, 1800, 2400, 4800, 9600, 19200, 38400; default rate: 9600 even, odd, none; default: none 5, 6, 7, 8; default: 8 1, 2; default: 1 1÷20, default: 5 (repeat interval: 3 sec) 0÷255, default: 0 0÷65535; default: 0; obsolete, use ProcServicePort 64 char string, location: etc/services file on, off; default: off get, set, none; default: none Watchdog, logging see IEC101 interoperability documentation The configuration file dedicated for the above parameters is the following (one file for each RTU): Configuration file application dir>/config/servers/iec870-101_RTU.ini The name of the file is optional, but it has to be in accordance with the “runner” file configuration, see below. Runner configuration: configuration syntax bin/iec870_104 ./config/servers/iec870/ iec870-101_RTU.ini configuration file <application dir>/config/servers/iec870-101_RTU.ini 3.4.2. IEC60870-5-104 This communication module has the following configuration possibilities: Parameter role in communication communication port Link parameters (defaults) Value IEC104 server or client TCP; default port: 2404 T0: 30 sec T1: 15 sec T2: 10 sec 18/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Tcikl CRC CAD group link address CAD group ProcServicePort test TIME setting diagnostic features message types 50 sec (link drop if no messages during timeout) If Link104_Crc=1 CRC232 checksum sending (used by ProField RTU) 0÷65535; default: 0; obsolete, use ProcServicePort 0÷255, default: 0 0÷65535; default: 0; obsolete, use ProcServicePort 64 char string, location: etc/services file on, off; default: off get, set, none; default: none Watchdog, logging see IEC104 interoperability documentation The configuration file dedicated for the above parameters is the following (one file for each RTU): Configuration file application dir>/config/servers/iec870-104_RTU.ini The name of the file is optional, but it has to be in accordance with the “runner” file configuration, see below. Runner configuration: configuration syntax bin/iec870_104 ./config/servers/iec870/ iec870-104_RTU.ini configuration file <application dir>/config/servers/iec870-104_RTU.ini 3.4.3. SAGateway The SAGateway software module is a communication interface to other devices, using various data transmission protocols. It has client-server architecture. By using SAGateway it is possible to interface other devices through the following protocols: IEC101, IEC104 - although these protocols are natively supported by ZEUS, the gateway can be used as data concentrator, or additional functionality can be obtained using the built-in functions of the gateway IEC103 - interface to relays IEC61850 - interface to relays, substation automation and other devices through IEC 61850-8-MMS standard MODBUS, MODBUS/TCP - interface to MODBUS devices DLMS/COSEM - interface to energy meters compatible with IEC62056 standard data transfer Other SAGateway functions that provide additional functionality to ZEUS SCADA: Web interface - offers web server service to access process- and diagnostic data using a web browser. This function can be used also from within the ZEUS system. 19/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Switching sequences - pre-configured switching sequences can be executed by the gateway. The sequences can be started by the ZEUS dispatcher using standard control commands. Internal automations - configured using PLC-like script language. All above data transmission protocols and other functions communicate with ZEUS native IEC_101 or (preferably) IEC_104 protocol. 3.5. Data archive The following data are processed and stored in the ZEUS SCADA: trend archives (historical data) event logs 3.5.1. Trend archives There are two types of historical data that can be processed by the system: analogue values received from the RTUs. These data are received by the iec870_101 or iec870_104 process then processed by the proc process; digital values (signals) received from the RTUs. These data are received by the iec870_101 or iec870_104 process then processed by the proc process; analogue and digital values resulted as internal calculation processed by the interpreter process. 3.5.2. Event logs There are two types of event logs that can be processed by the system: the text-format logs created by the xevent process sql-format logs created by the evlogd process 3.5.2.1. xevent In the first case event logs are created by the evcentr process. The logs can be viewed in the ZEUS client using the xevent graphical process. The archive files are saved to the storage device in form of text-files. 20/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 3.5.2.2. evlogd In the second case event logs are created by the evlogd process. The logs can be viewed in the ZEUS client using the EventLog graphical process. The archive files are saved to the storage device in form of sql database. The used database format is Postgres. The content of the event log can be saved in form of .csv files. These files can be opened using Microsoft Excel for further analysis. To ease the event log savings, there are pre-configured software tools. The saving (to temporary directory) can be done using the following command: Save command sysntax psql -h plovsrv evlog -c "copy (select* from event) to '/tmp/event.csv' with csv header;" 3.6. Graphical display ZEUS processes (or programs) that require graphical display (GUI) are the following: xview, xevent, evlogd, alarmlist. These client programs can be configured to run in any required combination (all together or just one of them). All main ZEUS functions require that xview program is running; see functions listed in paragraph: 4.1 Main functions of the Zeus SCADA system. ZEUS client can be configured to use one- or more displays. The maximum number of displays depends on the number of VGA ports. In applications with several monitors the configuration possibilities are even more. It is also possible to leave one- or more monitors for other applications such as documentation management. The total number of monitors (xview instances) in a ZEUS system cannot exceed 64 - including remote terminals. In multiple monitor systems the screens belong to a single logged-in dispatcher, but they are independent of each other. The control devices (keyboard, mouse) of the screens are common. One may continuously move the mouse pointer over from one display-screen to the other with the mouse. 21/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 3.6.1. xview This is the main display of the ZEUS SCADA system. It is the primary interface used by the operator to control the technology. xview can be run in the following ways: full-screen mode: in this mode the screen stretches over the full monitor, there is no status area and no event or alarm area; normal mode: in this mode the program will be divided in three areas: o status area: this is the upper part that contains buttons and display areas, such as time and date. o basic screen area: here are displayed the screens configured using ProEdit editor o event or alarm area: here can be displayed the event log, the alarm list or both. In the following example the display is divided into three parts (see Figure 1): Status area: The top two strips of the area viewed are called the status area. This is the place where the program displays the most important information concerning display; the intervention points (buttons) that may be managed by the mouse are also located here. Basic screen: In the central part of the screen, there is the basic screen that displays technology schemas. This is the primary surface through which the operator gets information about the status of the technology, and where he/she may execute the interventions needed. The status area and the basic screen are jointly called the screen area. Event area: This area is a window located at the bottom of the screen. All the functions that are connected to event list function together with the buttons that are used to manage them are displayed in this area. In multiple-monitor system the configuration of the xview can be different on each monitor if needed. It is also possible to use the total area of the monitors as a joint screen to run a single xview. 22/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Status area Basic screen Event area Figure 1: Display of the Zeus SCADA system Zoom map Each screen has zooming possibility. By default 4 zoom levels are defined, which can be accessed in several ways (zoom icon, mouse scroll and rectangle defined by mouse). In addition there is a zoom map that helps navigation when zooming in. The zoom map has a configuration file where the following parameters can be defined: zoom map active zoom map size Zoom map parameters are included in the configuration file of xview, see below. Configuration Runner configuration: configuration syntax bin/xview ./config/clients/xview.ini Parameters: Parameter -display <host:x.y> -M --geometry geometry string -h Description screen configuration; on local computer ‘host’ is not necessary, e.g. -display 0.0 (first screen) maximize; xview will be displayed full-screen set xview size and position help In case of multi-screen system the xview process has to be started independently for every screen. For this separate runner configuration rows and configuration files must be used. The configuration files are cascaded; the child files have a reference to the parent file. See the following example for 4-screen Workstation runner configuration: 23/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION start type next program start program owner program group owner root root restart nowait configuration syntax bin/xview ./config/clients/xv.ws1_1.ini -display :0.0 bin/xview ./config/clients/xv.ws1_2.ini -display :0.1 bin/xview ./config/clients/xv.ws1_3.ini -M -display :0.2 bin/xview ./config/clients/xv.ws1_4.ini -M -display :0.3 Cascading configuration files: Location of configuration files <application dir>/config/clients/xview.ini <application dir>/config/clients/xv.ws1_1.ini <application dir>/config/clients/xv.ws1_2.ini <application dir>/config/clients/xv.ws1_3.ini <application dir>/config/clients/xv.ws1_4.ini Note parent file child file (screen 1/4) child file (screen 2/4) child file (screen 3/4) child file (screen 4/4) The principle of cascading is to include the parent file path in the very first row; the parameters defined inside the child files have higher priority than in the parent file, see below: xv.ws1_1.ini #include ./config/clients/xview.ini xv.ws1_2.ini #include ./config/clients/xview.ini xv.ws1_3.ini #include ./config/clients/xview.ini xv.ws1_4.ini #include ./config/clients/xview.ini xview.ini Zoom map parameters: Parameter Value Default value, notes ZOOM_MAP_ACTIVE ON = show OFF = hide default: OFF; if active, it is displayed on the normal zoom level, otherwise only when zooming in ZOOM_MAP_SIZE 10÷50% 25%; defines the zoom map window size in % of the original screen size Database configuration: Table name keptip keptip keptip keptip keptip keptip Field name Description Note kepnev keprol kepazo keprek alarmgrp pic_action name of screen name of parent screen short name of screen screen index alarm group action related to opening a screen used for alarm system displayed in xview used by ProEdit link to alarms table default: 0 24/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION keptip anapar jelpar1 jelpar2 pic_action_param a_alarmpic j1_alarmpic j2_alarmpic parameters of action link to keptip/kepnev link to keptip/kepnev link to keptip/kepnev default: NULL0 part of alarm system part of alarm system part of alarm system 3.6.2. Event log The events are statuses or activities, which are recorded and stored by the SCADA system. The events can be displayed by the event log. The event messages are chronologically archived. It is possible to display the events from any of the ZEUS clients. There are two kinds of event logs available in the ZEUS system: xevent (older, text-based type event log) evlogd (newer, Java- and Postgres SQL based type event log) Each event log has its advantage and disadvantage; the system designer can use the most appropriate depending on the size of the system and the required functionality. In a simple approach it is recommended to use the xevent in case of small, single-computer application and evlogd for bigger system. xevent has the advantage of simple configuration and very fast scrolling in the GUI. Its disadvantage is the way of storing the messages: separate file for every day. This makes it difficult to search for an event in time period bigger than one day. evlogd has the advantage of the sql database storage, which allows for nearly unlimited searching and filtering possibilities. Its disadvantage is the more complex configuration and slightly higher hardware requirements. 3.6.2.1. xevent This event log has a server process called msgserver and a client process called xevent. The events are stored in text files; every text file has an associated index file. Data is stored in files that are created each day at 00:00 (hr:min). When the system starts it will check the presence of the daily event log file. If no file found then a new file will be created; in case that the file already exists, data will be written in the same file. [Date and time] [Event message] [Operator] Configuration Runner configuration: configuration syntax 25/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION bin/xevent ./config/clients/xevent.ini Parameters: Parameter -display <host:x.y> --geometry geometry string Description screen configuration; on local computer ‘host’ is not necessary, e.g. -display 0.0 (first screen) set xevent size and position In case of multi-screen system the xview process has to be started independently for every screen. For this separate runner configuration rows and configuration files must be used. The configuration files are cascaded; the child files have a reference to the parent file. See the following example for 4-screen Workstation runner configuration (xevent running only on one of the monitors): configuration syntax bin/xevent ./config/clients/xe.ws1_1.ini Note example: Workstation with 4 screens (only one event log on first screen) Cascading configuration files: Location of configuration files <application dir>/config/clients/xevent.ini <application dir>/config/clients/xe.ws1_1.ini Note parent file child file (screen 1/4) The principle of cascading is to include the parent file path in the very first row; the parameters defined inside the child files have higher priority than in the parent file, see below: xe.ws1_1.ini #include ./config/clients/xvevent.ini xvevent.ini Configurable parameters of the xevent process: Parameter XEVENT_INSTANCE LOGOSTR SHOW_MILLISEC LINE_COUNTING ALARM_MULTISOURCE SHOW_ALL_RTU SCADA_SHOW ACCESS_GROUP SERVER_HOST1 SERVER_HOST2 SERVER_HOST3 Value instance number - unique for every client (terminal) Logo text that appears in the printed header display milliseconds in the time display event serial numbers technological segments display Name of client location Name of server host Name of server host Name of server host Location and name of the archive files: 26/70 Default value, notes 0 ZEUS-SCADA yes no no no ALL see also file: /etc/services “IEC870 services” section not used in single-computer configuration ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Path <application <application <application <application dir>/data/evcentr/events/yyyy.mm.dd.eve dir>/data/evcentr/events/yyyy.mm.dd.idx dir>/data/evcentr/events/archive/yyyy.mm.dd.eve dir>/data/evcentr/events/archive/yyyy.mm.dd.idx Where: yyyy=year; mm=month; dd=day; The .eve extension is the event log file format (text format); The .idx extension file is a binary-format index file. It is updated by the program and ensures that the event log cannot be altered by other programs. In this way it is a security feature preventing fraudulent event log entries. Database configuration: Table name eventcatx eventcatx eventcatx eventcatx eventcaty eventcaty eventcaty Field name Description catnamx catcolx catscada evx_id catnamy catcoly catcbgy eventcaty catval short name of location colour of event link to location table index field short name of location colour of event background colour of event colour category index anapar anapar anapar jelpar1 atipus ahelye a_evx stipusf event type event location event index event type 0 to 1 jelpar1 jelpar1 jelpar1 jelpar2 jelpar2 jelpar2 stipusl shelye1 j1_evx stipus2 shelye2 j2_evx event type 1 to 0 event location event index event type event location event index Note aclocation/ac_loc_name key field aclocation/ac_loc_name categories filled in anapar, jelpar1, jelpar2, etc. tables e.g. protection e.g. field number used by Xfill wizard e.g. protection, diagnostic, etc. e.g. field number used by Xfill wizard e.g. breaker, switch, etc. e.g. field number used by Xfill wizard 3.6.2.2. evlogd This event log has a server process called evlogd and a client process called EventLog. On the server computer there must be installed a Postgres SQL database process. The events are stored in the sql database and the client program displays the events in various views, offering many filtering possibilities. 27/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION The messages included in the rows are built from the following elements (displayed as columns): [Sequential number] [Date and time] [Event message] [Operator] In the event log the number of rows is not limited. The sequential number is the number of the event in the list. The system reset it every day at midnight. The date and time column contains the date and time when the event occurred. In respect of events in the technological equipment the time is determined by the data acquisition system, therefore it shows the real technological time. The display system assigns a timestamp to events initiated from the GUI that do not relate to the technology (i.e. operator login/logout). The event message generally consists of three parts, the source location of the signal, the identifier of the signal and the event text. The event text describes the change in the state of the object. The operator’s interventions (e.g. operation of a switchgear, etc.) are recorded in the event log together with the operator’s log-in name. The operator can insert his/her own comments which are recorded together with the relevant timestamp and the operator’s log-in name The stored events can be displayed in two forms: The daily continuously updated (on-line) event log can be displayed at the bottom of the screen(s), in the alarm area. It helps the momentary work of the operator. The non-updating (off-line) event log appearing in the event (list) window can be used for the evaluation of the system’s operation and the analysis of operating problems. The on-line event log contains events that occurred in the last 24 hours. The systematic saving of the archive’s files to a backup media is recommended in order to avoid any problems caused by the hard drive becoming full. The system guarantees the safe storage of event logs created during one year, while the limit of the storage capacity is the size of the hard drives. The functions of the event log Opening the event log in a separate, full window (see Figure 2); Opening the filtering window (both for the on-line and archive log); Opening the archives window; Inserting new dispatcher note; Opening the print preview window and then print the event log; Searching in the event log; Showing all fields in the event log (adding type and source columns); 28/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Changing display settings (grid, font size, etc.). Figure 2: Full window of the event log Using the filtering window the event log can be: filtered by event category filtered by text filtered by predefined database fields, such as o location o voltage level o field name o equipment type Configurable parameters of the evlogd process: Parameter geometry fullWindow grid menu sortStationNames Value position and size of graphical program on the screen option makes possible displaying the program in full window option makes possible displaying the grid option makes possible displaying the menu option makes possible displaying the menu 29/70 Default value OFF ON OFF OFF ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION onlineShowingColumns select columns to display and column widths in pixel offlineShowingColumns colour Name of server host setting foreground colour of event text (different colour for every event type) setting background colour of the event log window (R,G,B; decimal) setting font type and size hostname of server where the evlogd process runs and port number background font ip dailySerialNumber:100, date:100, time:100, eventText:800, operator:200 49,76,82 Arial 0 14 srv:4040 Location of configuration file: configuration syntax bin/xevent ./config/clients/EventLog.ini 3.6.2.3. xevent This event log has a server process called evcentr and a client process called xevent. The events are stored in text files and the client program displays the events in simple view. 3.7. Authority control ZEUS system has several authority levels that can be configured in the database. The number of authority levels is not limited. Authority system is configured according to RBAC (Role Based Access Control) principle - every user is assigned with a role; roles are managed by the system’s administrator. The ZEUS system does not allow any modification of the system including issuing control commands as long as no operator is logged in. The active level is displayed using an icon on the upper part of the screen. For reference see the ZEUS operation and maintenance manual. The name or short ID of the logged operator can be displayed on a screen. Also the short ID of the logged operator is added to the event log every time a control command, acknowledgement or other dispatcher action is made. Access control is used to define and apply access rights to the SCADA system. Every operator and workstation has a predefined authorization level containing the operations allowed. Operations in the system can only be carried out by logged-in operators (dispatchers) who are assigned a user name, a role and a secret password. Generally the following roles are used: Operator (dispatcher), Administrator (SCADA system administrator), 30/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Developer (system engineers). The SCADA system is suitable to control and monitor larger areas consisting of several technological segments, using multiple workstations located even in different locations and operated by several dispatchers. A possible configuration is the following: the area of control is divided into two technological segments. These segments are assigned to two different workstations. Each segment is controlled by different dispatchers on different workstation. The dispatchers working on a workstation have control only on the specified segment and they will only receive alarms and events related to that segment. The dispatcher has the possibility of acquiring the authority of control over the other area in case of emergency. Configuration Database configuration: Table name acfunclist acfunxws acloc2ws Field name ac_func_name ac_ws_01 … ac_ws_32 ac_ws_name aclocation acoplist acposlist actermlist ac_agtoobj ac_op_lid ac_pos_name ac_term_name actermxterm ac_term_00 … ac_term_63 actermxtseg ac_tseg_01 … ac_tseg_16 actseglist ac_tseg_name Description function name link between functions and workstations link between locations and workstations link to access group name of dispatcher(s) list of operator roles list of terminals long name one terminal needed for each screen terminal matrix link between terminals and technological segments alarms alrp_peident list of technological segments authority and alarm management list alarm of alarm groups terminals terminals_key alarm group management acserveradm ac_alarmstat Note list of available functions also alarm sound settings more alarm sound settings Full reference of access control configuration is provided in the ZEUS Database Filling-in Guide. 3.8. Time management Every device of the SCADA system which has internal clock has to be synchronised to a reference time. Synchronisation of the clocks can be performed in the following ways: 31/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Using Time Servers (synchronised by GPS receiver) and NTP protocol; Using data transmission commands, such as the Clock synchronisation command (C_CS_NA_1) of the IEC101 and IEC104 protocol; If no time source available then it is possible using internal clock of the computer and setting the time manually. The SCADA system can provide- or get time information to- or from other devices in the system that have communication interface with SCADA. Time synchronisation can be configured in any of the above mentioned ways, but it is important not to use simultaneously the data transmission- and the NTP protocol synchronisation. 3.8.1. Using data transmission commands Time can be set using the Clock synchronisation command (C_CS_NA_1) of the IEC 60870-5-104 or IEC 60870-5-101 protocol. Time management configuration in case of the Clock synchronisation command can be configured in the configuration file of the protocol. The following settings are possible: Parameter SetTime GetTime RtuUtc SetCmos=on Value off; on off; on off; on off; on Default value off off off on Location and name of the configuration file: Path <application dir>/config/servers/iec870/iec870_rtu-name.ini The following ZEUS process shall run: checktim. The task of the checktim process is to watch the time difference between the time of the ZEUS and the time received from the RTU. Notes: In case that the difference is bigger than 5 minutes then the hour will be ignored and this will be shown in the event log as “?” signs. In case that the difference is bigger than 3 days then the time will be ignored and the time will be acquired from the CMOS (BIOS) of the computer. In case that the difference is smaller than 3 days then the time will be set to the CMOS (BIOS) of the computer. If the time received from RTU is UTC time than the RtuUtc=on parameter shall be set and the ZEUS time will be set to local time. When time is sent from ZEUS to RTU than it will send UTC when parameter value is ‘on’ and local time when parameter value is ‘off’. When SetTime is set to ‘on’ then the ZEUS will send the first time set command 3 minutes after start-up, then once every hour. 32/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 3.8.2. Using NTP protocol Time can be set using the NTP protocol. ZEUS system can be the server of the client or it can be both server and client. Configuration file is independent from ZEUS, it is part of the Linux operating system. To use the NTP protocol, the following Linux process shall run: ntpd Configuration file name and location (Red Hat Enterprise Linux 5): Path /etc/ntp.conf If the computer that runs the ZEUS system is NTP client, then the file shall contain the IP address of the NTP server. More NTP servers they can be entered as well. The following example shows the setting of an NTP client in case of two NTP servers: Example configuration server 192.168.1.1 server 192.168.1.2 Notes: If RTU sends time set command it will be executed by ZEUS even if GetTime parameter value is ‘off’. In this case the RTU shall be configured in a way that time set commands shall be not sent as C_CS_NA_1 commands. 3.9. Security ZEUS SCADA system’s security considerations can be grouped into three main areas: Physical security measures This is provided by the security of the buildings and the facilities where the devices of the system are installed. Security level can be increased by: door locks, security guards, surveillance cameras, motion detectors, etc. Technical measures This area is related to the technology used for system configuration. One of the greatest strength of ZEUS SCADA system is the operation system chosen as its platform. Red Hat Enterprise Linux has partnered with IBM and HP for accreditations such as the Common Criteria EAL4+ CAPP profile Security Evaluation, which certifies that Red Hat Enterprise Linux meets stringent product and process standards for security. Other technical security measures are provided by the following: 33/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION RBAC (Role Based Access Control) - users are assigned with different roles which are managed by the system’s administrator SSH support - computers can be accessed on the internal LAN network only through SSH (Secure Shell) which uses public-key cryptography to authenticate the remote computer and allow it to authenticate the user. Use of firewalls when connecting to any external device on the network. The best protection can be achieved when all computers of SCADA system are physically separated from external networks. Administrative measures These measures define the human factors of security. The organization policy has to determine which users have access to the system. Security level can be increased by strengthening the following areas: Personnel training Personnel registration and accounting including picture IDs, biometrics (fingerprint, voice, face, iris recognition) etc. Maintenance and recovery plans 34/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 4. Functions and configuration parameters The ZEUS SCADA system consists of background processes that do not need graphical interface and client processes that provide man-machine (MMI) interface for the user. MMI is also known as human-machine (HMI) interface. The MMI part of the ZEUS needs a graphical user interface (GUI). In the Red Hat Linux operation system there are available several graphical user interfaces such as KDE, or GNOME, but ZEUS is configured to run using the Motif graphical user interface. This is important because of the following consideration: while the ZEUS client processes run it is important to hide the operator’s access to the operating system features, thus preventing the dispatcher from running other programs or to modify system configuration 4.1. Main functions of the Zeus SCADA system The main functions of the system are detailed later in this document. All these functions are accessible through the GUI thus helping the work of the operators: Measurements Signals Control operations Voltage dependent colouring Trend monitoring Alarm list Event log Switching sequences Access control Lists of filtered events and data Safety documents Archive playback 4.1.1. Measurements The measurement values received from RTU or resulting from the internal calculation process (interpreter) are processed using several configuration parameters. The results of the processing are the actual value and the status. These results are then further used by other configured processes, like trserver. In order to process the actual value of the measurement the configuration parameters listed in the chart below are used. These are set in the ZEUS database, anapar table. 35/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION The following charts contain the most important database fields affecting the value and status of the measurement. Complete reference of database fields can be found in document: ZEUS Database Filling-in Guide. The following parameters have effect in producing the actual value of the measurement: Field name skalaa skalfe helyer helyet lekapk Description signal range - minimum value signal range - maximum value replaced value replaced value flag zero threshold tavado physical range constant filter digital filtering Note entered by dispatcher 0=not replaced, 1=replaced below this value skalaa value will become the actual value it’s value must be set according to the range of the measurement, see the following chart default value: 1 (no filtering) Measurement ranges; the range must be set in the parameter tavado: Signal range Value 12 bit signed -4095 ÷ 4095 12 bit; 4-20 mA transducers -4095 ÷ -819; 819 ÷ 4095 15bit signed float -32767 ÷ 32767 float 15bit signed -32767 ÷ 32767 12bit*(-1) negative conversion -4095 ÷ 4095 13bit 0 ÷ 8191 14 bit signed -16383 ÷ 16383 15 bit signed; 4-20 mA transducer -32767 ÷ -6553; 6553 ÷ 32767 16bit float 0 ÷ 65535 float 16bit 0 ÷ 65535 synchrophasor; phasor frequency 0 ÷ 8000 synchrophasor; phasor amplitude 0 ÷ 24570 synchrophasor; phasor angle 0 ÷ 100 float, divide by 10 -32767 ÷ 32767 float float, divide by 100 -32767 ÷ 32767 float float, divide by 1000 -32767 ÷ 32767 float The following parameters have effect in setting the status of the measurement: Field name hihjel hihals hihfls tiltott Description credibility signal link credibility low value credibility high value disabled flag Note link to a comm. status signal set by dispatcher 36/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION hiszte lekapk anauza anaals anafls anauzf alflm1 alflm2 alflm3 allem1 allem2 allem3 a_alarmpic dead zone zero threshold alarm for emergency low value alarm for low value alarm for high value alarm for emergency high value low mask 1st alert level low mask 2st alert level low mask 3st alert level high mask 1st alert level high mask 1st alert level high mask 1st alert level link to screen a_alarmgrp link to alarm group effect on alarm status effect on actual value triggers alarm of the screen; link to keptip table link to alarms table In order to display the current status levels, the following preliminary processing activities are carried out by the system: Conversion of values into scaled physical values (actual value); Technological credibility analysis; Limit monitoring with hysteresis (dead zone); Values close to zero are set to zero (zero threshold). Validity check (measurement not reported by RTU are invalid) In addition to this primary processing, further calculations with current values are possible. Such operations are called “secondary processing” (e.g. summation of the measured values, etc.). All the important characteristics of the measurements are displayed in the window containing the analogue channel’s parameters (see Figure 3). The window contains both the raw value and the actual scaled value gained from the measurement. Functions related to measurements Entering measurement values manually (replace) Enabling/disabling measurement Setting scale limits Setting credibility limits Setting two-level technological limits (emergency low, low, high, emergency high) Setting dead zone (minimum change in the value which will trigger an alarm in case of values crossing technological limits) Setting zero threshold (for eliminating errors in the measured values near the measurement scale’s lower limit) 37/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Figure 3: Parameters of analogue channel 4.1.2. Signals The signals received from the RTU may be the following: Double point signal inputs Single point signal inputs Transformer step positions (can be analogue value as well) The signals values received from RTU or resulting from the internal calculation process (interpreter) are processed using several configuration parameters. The results of the processing are the actual state and the alarm status. These results are then further used by other configured processes, like event log (evlogd). In order to process the actual value of the measurement the configuration parameters listed in the chart below are used. These are set in the ZEUS database, jelpar1, jelpar2 and steppar table. The following charts contain the most important database fields affecting the value and status of the signals. Complete reference of database fields can be found in document: Xgram Database Filling-in Guide. The following parameters have effect in producing the actual value of the DP signals (similar for SP and ST signals): Field name nevhos2 j2_namexl jehely2 Description signal name signal name replaced flag Note 46 characters only 128 characters 0=not replaced, 1=replaced 38/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION jelhee2 szov002 szov012 szov102 szov112 szov002 szov012 szov102 szov112 replaced value text for 00 bit state text for 01 bit state text for 10 bit state text for 11 bit state text for 00 bit event text for 01 bit event text for 10 bit event text for 11 bit event can be set by dispatcher displayed in data windows displayed in data windows displayed in data windows displayed in data windows displayed in event log displayed in event log displayed in event log displayed in event log The following parameters have effect in setting the status of the DP signals (similar for SP and ST signals): Field name jtiltt2 jalmf12 jalmf22 jalmf32 jalml12 jalml22 jalml32 hibamk21 hibamk22 hibamk23 j2_alarmpic Description disabled flag bit mask for 1st level alarm state bit mask for 2st level alarm state bit mask for 3st level alarm state bit mask for 1st level alarm state bit mask for 2st level alarm state bit mask for 3st level alarm state bit mask for error state bit mask for error state bit mask for error state link to screen j2_alarmgrp j2_alarmpic link to alarm group link to screen j2_alarmgrp link to alarm group Note can be set by dispatcher effect on alarm state effect on alarm state effect on alarm state effect on alarm state effect on alarm state effect on alarm state effect on alarm state effect on alarm state effect on alarm state triggers alarm of the screen triggers alarm of the screen; link to keptip table link to alarms table All the important characteristics of the signals can be found in the signal data window (see Figure 4). The functions related to signals: Setting text of signal values (two states for single point signals, four states for double point signals) Manual replacement of signal values (e.g. for electric network objects that are not monitored directly) Disabling/enabling signal Disabling/enabling signal processing for a device or a bay Disabling/enabling control of a device group (e.g. bay). 39/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Figure 4: Data window of double point signals 4.1.3. Control operations Controls are sent to RTU using the control command function. Control type can be Double Control (DC) or Single Control (SC). Command can be initiated only by the dispatcher logged in and having the necessary authorisation. The GUI part of the control command window (see Hiba! A hivatkozási forrás nem található.) displays the following information: Object name: name of the object to be controlled, Control type: OPEN (red button) and CLOSE (green button); actual text is configured in the controlobj table cszvez1 (open) and cszvez2 (close) Disable function: the blue button Execute button - can be pressed only after selecting on of the OPEN or CLOSE command Cancel button - closes the control window, the command is not sent. Help - opens the help system at the Control paragraph. 40/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Figure 5: Control command window NOTE: The command window will close after cca. 20 seconds of inactivity – if no button is pressed. Control commands are recorded in the event log. If the operation is successful, the signals for status changes will appear on the screen (if configured so), depending on the operation time of the object. If for some reason the object does not execute the command within a pre-set time limit (controlpar table, ctmout field), the unsuccessful command will be recorded in the event log and the command will be cancelled. Principle A schematic presentation shows the interaction between processes in relation with the control process. Control commands are always initiated by the dispatcher logged-in with the necessary authority. Switching sequences can be also configured, see paragraph 4.1.7. 41/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION xview ZEUS client ZEUS server SAGateway control rqserver proc IEC104 server iec870_101 or iec870_104 client IEC103 client Relay IEC103 (server) RTU IEC101 or IEC104 (server) MODBUS master PLC MODBUS (slave) IEC 61850 RTU IEC 61850 Configuration The controls are configured in the database and in the graphical system using Proedit. The following tables of the database contain configuration of control commands: Table name controlpar Field name cmuknev controlpar c_namexl controlpar controlpar controlpar controlpar cpvezobj cjevez1 cjevez2 ctmout controlpar controlpar controlpar controlobj controlobj controlobj cvezben cvezeng1 cvezeng2 cjalla1 cjallam1 cjalla2 Description short name of controls Note used in xevent event log (45 characters) long name of controls used in evlogd event log (128 characters) link to cpvezobj table index of switch type index of control primary RTU index of control redundant RTU control timeout (sec) check back signal timeout; no alarm generated if signal arrives within timeout index of blocking signal interlocking function index of enabling signal OPEN control index of enabling signal CLOSE control check back signal status OPEN control check back signal mask OPEN control check back signal status CLOSE control 42/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION controlobj controlobj jelpar1 jelpar2 steppar cjallam2 cobjtyp ctrl1 ctrl2 stpctrl check back signal mask object type index of control index of control index of control CLOSE control e.g. switch, breaker, etc. check back signal check back signal check back signal Complete reference of database fields can be found in document: ZEUS Database Filling-in Guide During configuration all control commands have to be linked with their check back signals. This configuration task is made using the “control” wizard of the Xfill program. Complete reference of database tables and fields related to control function can be found in document: Xgram Database Filling-in Guide. Graphical system configuration: the graphical object dedicated for issuing the control command has to be assigned with the Control command action. This can be configured in Proedit. Other function related to control command: Voltage dependent colouring. Sections have a bit called “simulated” that can be assigned to active (coloured) sections. When this bit is configured (using ProEdit graphical editor) the sections affected by a control command will show the state resulting after a successful control command. The simulation is activated when either OPEN or CLOSE button is selected and it is working until either the Execution or Cancel button is pressed. Simulation also stops if no other button is pressed within 20 seconds after OPEN or CLOSE selection; in this case the control window will be automatically closed and no control command is sent. Disable function. When Disable button is pressed, the command window will be closed and no control command will be sent. At the next attempt of issuing control command the OPEN and CLOSE buttons will be hidden, and only the Enable button will be available. Now when the Enable button is pressed the command window again closes and on the next attempts the OPEN and CLOSE buttons will be available. The disable state can be commented by the dispatcher, the comment will appear in the window, see figure below: Figure 7: Control command disable state 43/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 4.1.4. Alarm system The alarm system ensures notification of the dispatcher when a significant change occurs in the controlled technology or in the status of the SCADA system. The alarm notification consists of visual and audible alerts. The designer of the system has many possibilities to configure an appropriate alarm system. The alarm system has three main components: graphical alarm system; audio alarm system; alarm list. All three are based on the alarm status of data which has to be configured in the configuration file of the alarmd process and in the database. Alarm status Alarms can be generated upon various changes in the system: analogue data value, digital input status, communication link status. Analogue measurement can be configured to trigger alarm when the value crosses predefined limits. The following limits can be configured: LOW, HIGH, CRITICAL LOW, and CRITICAL HIGH. When the value crosses one of the limits the alarm will be either activated or terminated. To prevent repeated alarms near the limits a dead zone can be configured. Signals can be configured to trigger alarm when selected status bits are changed. Typically the device status bits are selected: ON, OFF in case of SP signals and OPENED, CLOSED, ERROR STATE in case of DP signals. In bigger systems it is possible to create more alarm groups, in correlation with the technological segments. Alarm groups can be distributed between the workstations in a way that one workstation will be notified only about alarms originating within a pre-defined technological segment (area). 4.1.4.1. Graphical alarm system Graphical objects properties offer the following main possibilities to display the alarm status: Properties of the graphical objects: visibility, colour and blinking. Configuration of alarm screen Using active links to screens where alarms are displayed. Based on the data status configuration the designer of the SCADA system can configure the objects according to the requirements. The alarm cascading function allows identifying and displaying the parent screen of each screen. Using this function the designer can place active links e.g. buttons that will acquire the alarm status of the child screen thus making possible bringing to attention several screens where alarms are present. 44/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 4.1.4.2. Audio alarm system The function is realised by the alarmd process which generates the sound alarm according to the configuration file of the alarmd process, the database configuration and the changes occurring in the system. At start-up the alarm daemon reads and stores the object statuses and the database configuration in the memory; during operation it watches every status change and compares it with the stored status. When a change is configured to trigger an alarm, then the program writes the alarm status in the on-line database according to the configuration: it sets the alarm level (1, 2 or 3), the unacknowledged status, and the alarm status of the screen where the object is displayed. If the object is displayed on more screens it will set the alarm status on all other screens according to the cascading configuration. The generation of the sound alert is triggered by the xview and the alarm sound file is processed by the voiced module. The file itself will be played by the play program of the operating system. The alarm function has a horn feature; it triggers a command to one or more horns. The horn function is activated on the 3rd (and biggest) alarm level when configured so and it is deactivated by the dispatcher acknowledgment action. Three alarm levels are designed by default, thus every data can be classified in one of them, or it can be left without alarm. It is possible to set higher alarm level for the 0->1 transition of a signal and lower (or none) for its reversed 1-> 0 transition. The voiced process is capable of playing individual audio file (vaw format) or audio streams (GSM format). A number of audio files can be assigned to each alarm level. Alarms and audio alerts can be cleared in several ways: Action Alarm status cleared Sound alert cleared by acknowledging every alarm in the system yes, all alarms cleared yes, all sound alarms cleared by acknowledging every alarm on a screen only all alarms on the screen all sound alarms caused by objects on the screen by acknowledging one object only the object’s alarm status cleared only sound alarm caused by the object by stopping the sound no alarm cleared only sound is muted; the next alarm will cause the resuming of the sound alarm by muting the sound no alarm cleared all sounds muted; only with sufficient operator authority (used for testing purposes) 45/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 4.1.4.3. Alarm list The alarm list displays the alarms occurring in the system. Alarms can be displayed as rows in different colours according to the alarm levels and the alarm status. In time alarms appear in the list in the following sequence: alarm is displayed when alarm status of the data is triggered; alarm display in the list: o alarm is displayed with different colour when data value falls back into normal state (e.g. measurement value returns to normal range, or digital signal value changes back to normal) but it is not yet acknowledged by dispatcher; o alarm is acknowledged by dispatcher: alarm is cleared from the list. Each alarm row contains the date, time, description and the number of changes of the data since the alarm appeared. If the list contains both the acknowledged and the unacknowledged alarms then the unacknowledged alarms are always displayed at the top of the list. Functions of the alarm list Acknowledge: This function used to acknowledge the unacknowledged alarms of the list. Open data window: This function used to open the parameter window of the data related to the selected alarm (measurement or signal parameters window). Open alarm picture: This function used to open the operational screen or the data list of the selected alarm. Show/hide full alarm window. Set filtering and sorting options o show alarms by priority (1, 2 or 3; according to the alarm level class) o Show/hide acknowledged alarms o Sort by time or alarm level (also by time within the alarm level) Displays the total number of alarms in the list. 46/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION The small window of the alarm list is displayed in the alarm list area: The full window of the alarm list: Configuration The alarm system is based on the alarmd process running on server and the voiced process running in the client (only needed for audio alarm). The alarm system is further configured in the configuration files of ZEUS and the database system, see below: Runner configuration - server process: Server process <application dir>/bin/alarmd configuration file <application dir>/config/servers/alarmd.ini Parameters: Parameter -t Description -h help test mode Runner configuration - client process: Client process bin/voiced Process does not have parameters. Sound card and speakers are necessary. The audio files are located inside the application directory structure. The following program is also required: play. This is part of the Linux operating system, its default location is the following: Program path usr/bin/play Audio files path 47/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION <application dir>/voice Database configuration: Table name alarms alarms allpar Field name alrp_peident SOUND_FILE0 SOUND_FILE1 SOUND_FILE2 SOUND_FILE3 SOUND_VOL0 SOUND_VOL1 SOUND_VOL2 SOUND_VOL3 all_alarmgrp allpar all_ack anapar keptip keptip a_alarmpic alarmgrp keprol link between RTU groups and alarm groups link between RTU group and segment with acknowledge authority link to alarm screen link to alarm group link to parent screen dudapar dudapar dudaid dudaref Name of horn link to horn command dudapar dudacommon link to common horn dudapar dudainversion dudatime dudarepeat dudakeep dudadisablesign command inversion; on time; repeat cycle time; repeated on time; link to disable signal alarms Description Name of alarm group Sound file name for the 0..3 alarm levels Note key field Volume level for the 0..3 alarm levels [range 0..100] default: 100 link to alarms table link to actseglist table link to keptip table link to alarms table alarm cascading function link to controlpar table common horn is activated together with other horns fine-tuning parameters See also database configuration related to measurement and signal status in paragraphs 4.1.1 Measurements and 4.1.2 Signals. 4.1.5. Trend monitoring The trend monitoring function is designed to store and display historical data. Analogue measurement and digital signals can be selected for trend monitoring. Data storing is performed when the values are changed. It is possible to display up to eight channels simultaneously in a graphical format, and the data of one channel in a table format. Opening trend display may be done using a separate button, or from a screen using the menu of the selected object. The scaling of the window is adjusted to the selected channel (the active channel). It is possible to set the time axis between 1 and 31 days (see Figure 6). 48/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Figure 6: Trend monitoring of Zeus Principle: The trend function is based on server-client architecture. The trend server creates and stores the historical data and the clients are getting data from the trend server. Archives of historical data are created according to the database configuration. Data defined to be archived is stored immediately after the data has changed, together with a time stamp. The data files are stored in the server or on the external RAID unit. During operation the trend server creates new files daily at 00:00 (hr:min) and it moves the older files (more than 30 days) into the archive directory. When the system starts it will check the presence of the daily trend file. If no file found then a new file will be created; in case that the file already exists, data will be written in the same file. It watches the free disk space and it deletes the oldest archive files until the free space increases to the configured amount. The trend server has a couple of parameters to control the sizes of the daily files, as well the available space on the storage device to prevent the filling of the device. The internal resolution of the historical data is 1 sec. 49/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION The graphical trend display window (xdiag) is embedded into the xview. The following diagram explains the relation between processes involved in the functionality of the trend server and the clients. ZEUS client export to file xview xdiag trend display print external archive storage (RAID) ZEUS server rqserver trserver interpreter proc internal archive storage Core processes SAGateway IEC104 server iec870_101 or iec870_104 client Communication processes: IEC103 client Relay IEC103 (server) RTU IEC104 (server) MODBUS master PLC MODBUS (slave) IEC 61850 RTU IEC 61850 Configuration: Runner configuration: configuration syntax <application dir>/ bin/trserver Parameters: Parameter -h <host> -s -? Description host name of other server in dual system silent mode; it does not create trend file. This is required for playback servers help Configuration and log files: Process trserver Location <application dir>/config/servers/trserver.ini Configuration within the trserver.ini file: 50/70 Note ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Process TREND_PATH FILE_SIZE_WARNING Location storage path warning generated when file size exceeds value warning generated when hard EMPTY_SIZE_WARNING disk free space drops below value minimum empty space value KEEP_EMPTY amount of data/data block DATA_BLOCK_SIZE SIGNIFICANT_IN_PERCENT significant change value move older data to archive ARCHIVE_TREND_MOVING directory after ‘value’ days Note default: ./datatrserver default: 80 [MB] default: 50 [MB] default: 20 [MB] default: 32 default: 0,4 [%] default: 30 [days] Location and name of the archive files: Path <application dir>/data/trserver/trend_archive.yyyy.mm.dd <application dir>/data/trserver/archive/trend_archive.yyyy.mm.dd Where yyyy=year; mm=month; dd=day Database configuration: Table name jelpar1 jelpar2 anapar Field name jeldtd1 jeldtd2 anadtd Description trend processing flag Note trend processing only for records marked with value ‘1’ anapar anapar diagska diagskf diagram scale low limit diagram scale high limit can be different from-, but must be within the measuring range 4.1.6. Voltage dependent colouring The voltage dependent colouring function provides graphical display of the status of power lines. The function analyses the topology of the supply and sectioning schemes and dynamically calculates the status of the sections based on the voltage measurement and status of disconnectors, circuit breakers that are connecting the sections. The topology evaluation program takes into consideration the following inputs: The voltage values measured by RTU. The replaced voltage values. The value of DP or SP signals. The replaced value of DP or SP signals. Accordingly, the propagation of voltage is interpreted by sections, from element to element. The following statuses of the sections are handled: Energized. Not energized. 51/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Earthed. Manually earthed - by portable earthing. Error status (when input signals are contradictory, e.g. energized section is earthed through disconnector). Simulated - when a control command is selected, (before execution) the effect of the command can be displayed by blinking sections Source display: this is a possibility to display the used phases on the catenary system (in case of three phase/one phase traction power transformers; AB, AC, BC and other sources, e.g. beyond border). Up to 8 different sources can be used. The operation of the section colouring is illustrated on Figure 7. In the picture there are two typical section statuses present: The left and bottom sections of the line are energized (maroon colour); The section on the right side of disconnector 02 and upper side of disconnector 06 is not energized (green colour). The dark-blue coloured line is the so-called return conductor - a permanently coloured line. Figure 7: Voltage dependent colouring Configuration: The function shall be configured using the following processes and database data: Runner configuration: configuration syntax <application dir>/bin/topol2 configuration file <application dir>/config/servers/topol.ini Parameters: Parameter -i -I Description switch on Intelligent Alarm Focus (IAF) handle invalid switch state 52/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION -C -h use anapar/phcolor for colouring help Database configuration: Table name galpar anapar jelpar1 Description name or index of section index of voltage measurement bitmask of phase source phcolor section on one side of galvan11 switch section on other side of galvan21 switch j1_galvan_flag index of earthed section jelpar2 galvan12 anapar jelpar1 jelpar1 jelpar2 jelpar2 Field name galname galvan section on one side of switch section on other side of galvan22 switch j2_galvan_flag index of earthed section StatuGalvan Phcolor status description status description Note source of colouring in case of three-state switch in case of three-state switch name of used bits name of used bits 4.1.7. Switching sequences The task of the switching sequence is to ensure the safe and simple execution of group commands from the SCADA to the RTU. The group commands are transmitted to the controlled technology as sequence of control commands. The list of the control sequences including the series of commands and the preconditions of each command is predefined during initial configuration of the system. The status of the equipment can be checked during the execution, before each command. During operation, each command and the status of the switching sequence are logged into the event log of the SCADA system (depending on the configuration). The switching sequence function can be activated through buttons placed on SCADA screens. After selecting the desired sequence, the function first checks the validity of the initial status of the involved equipment. If the status corresponds to the initial setting, then the command sequence starts by sending the first command. The following commands are sent only if the status changes of the equipment correspond with the conditions of each step of the sequence. The switching sequence can be carried out semi-automatically or manually. In semi-automatic mode starting of the sequence is manual, after that all steps are executed automatically one after another until the last step is executed. In manual mode, the system requires dispatcher confirmation before each command. 53/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION The system generates warning messages if the execution of the sequence fails. The window of the function displays the list of the preconfigured sequences on the left side, while the steps of the sequence are on the right side (see Figure 8). The window contains the control buttons and a status bar displaying the current status of the sequence. The detail level of the messages displayed while running can be increased choosing expert mode (in normal mode only the main events are displayed). Figure 8: Switching sequences function - normal view Principle: The switching sequence function is realised in a server process called SAGateway and a client graphical interface - a window - that allows for viewing and initiating the configured switching sequences. The SAGateway contains an xml type configuration file that can be edited using the SAGateway Configuration Tool. The switching sequences can be initiated only by the dispatcher; the SAGateway can communicate with the rqserver process during execution of switching sequences. 54/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION ZEUS client xview switching sequence ZEUS server SAGateway control grpcom rqserver proc IEC104 server iec870_101 or iec870_104 client Communication processes: IEC103 client Relay IEC103 (server) RTU IEC104 (server) MODBUS master PLC MODBUS (slave) IEC 61850 RTU IEC 61850 Configuration The switching sequence function is processed by the SAGateway process. The configuration is of the gateway made using IedConfTool. The result of the configuration consists of several ‘xml’ extension files. These files have to be copied into the computer running ZEUS servers. The function is configured using the following processes, database data and configuration files: The configuration of the function relies on the following: Runner configuration: program name with path followed by parameters if any /usr/bin/sagateway /etc/SAGateway/grpcom.xml -l /etc/SAGateway/saglogconf.xml Configuration and log files: Location /etc/SAGateway/grpcom.xml /etc/SAGateway/saglogconf.xml Note log parameters /var/log/sagateway.log log file Database configuration: Table name Field name Description 55/70 Note ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION grpcom gc_peident sequence identifier grpcom grpcom gc_name gc_filter sequence name sequence filter key field used by program visible in GUI used for grouping sequences in the GUI 4.1.8. Lists of filtered events and data List screens contain several types of data present in the system. There are many predefined data sets that can be opened with buttons placed on the screens. Data included in the lists can be the following type: Measurement; Single Point data (e.g. alert signals); Double Point data; List of unacknowledged signals; List of circuit breakers and disconnectors with status different from normal; List of earthed sections. The data lists are data sets that are filtered according to the technological segments. Every data list has built-in features like filtering, opening data window, or initiating actions that are specific for the displayed data. For example the measurement list allows for opening trend diagram for the selected data (see Figure 9). 56/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Figure 9: Data list of measurements Configuration Database configuration: Table name tdlist Field name filter_name tdlist tdlist filter_this td_field tdlist xpm_on xpm_off init_state tdlist Description identifier of predefined filters filter string link to field where the filter is applied name of icon file assigned to filter filter flag 57/70 Note used by Proedit what to filter where to filter how to apply filter filtering when list is opened or only upon pressing the filtering button ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION keptip pic_action_param link between screen and filter filter will act as a screen; it gains alarm status when any data’s alarm status is activated Location of ‘xpm’ icon files: Path <application dir>/ schema/xpm 4.1.9. Summary lists by statuses Summary tables display the status of objects according to their momentary states (unacknowledged, substituted, disabled, etc.). The summary screen presents a summary list by location and by type of data point. The opening screen of the function contains the following (see Figure 10): After selecting the data type or section as the header of the column, the possible statuses are displayed as rows on the left and the number of objects in each state is displayed in the corresponding cells of the table. Using the tabs on the right it is possible to select the location (e.g. substation). The “All” tab on the bottom is used for displaying all the data. The numbers on the (button-like) cells show the number of objects having the state that exist in the given moment at the location. By clicking on the cells, data of the selected location are displayed as a list. 58/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Figure 10: Summary lists by statuses In case of that an element is selected from the list, it is possible to perform the operations that are usual in case of objects: Updating (refreshing the state); Opening a data sheet; Opening an alarm screen (if configured); Individual acknowledgement; Acknowledging all the elements of the list. Configuration The function uses a configuration file which provides the setting of the following matrix: 4 data types as columns (e.g. measurement, SP signals, DP signals, sections); 16 status bits as rows, with status names in the first column; RTU groups as tabs on the right side; possibility to open every data using the ‘ALL’ tab. The following data shall be set: Configuration and log files: Location Note 59/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION <application dir>/config/clients/xstatus.ini xview.ini file contains reference to this path Database configuration: Parameters COLUMNNAME STATUS LISTNAME ALARMPICTURE ACCESS WIN_CMD_IDX BITNAME ACK_CMD_IDX Description data type database reference to value database reference to name database reference to alarm screen database reference to alarm field index of data window name of index field code of acknowledge action Note e.g. MEAS e.g.: ANAVAL STATU1 e.g.: ANAPAR NEVHOS e.g. ANAPAR A_ALARMPIC e.g. ANAPAR ANA_SHOW e.g. 3 for analogue 16 rows e.g. 7 The file is structured in data sets, one for each data type, which means four sets in total. Sample configuration file provided in Appendix A. 4.1.10. Duty event and instructions list This function manages the duty change process between dispatchers and records the events during a dispatcher’s duty (see Figure 11). The log records all actions of the dispatcher regarding his/her duty. The log records all reported switching operations. (For manual or motorized disconnectors which are not connected to SCADA.) The log records all portable earthing operations. The log also records the trip events (spontaneous circuit breaker signal change). 60/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Figure 11: Duty event and instructions list Configuration The function is based on a Postgres SQL database, a server process (villnap) and a Javabased GUI process (PowerWorksLog.jar). Runner configuration: program name with path followed by parameters if any <application dir>/bin/villnap Process location: Location <application dir>/bin/villnap Configuration and log files (located at client computer): Location <application dir>/config/clients/ PowerWorksLog.ini <application dir>/config/clients/ PowerWorksLog.properties Database configuration: Table name berendezes feszszint mezo Field name brzes_namex fsz_namex mezo_namex Description list of objects list of voltage levels list of fields 61/70 Note e.g. breakers e.g. 110, 20 kV e.g. feeders ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 4.2. Other functions of the Zeus SCADA system The Zeus SCADA system contains many additional functions. In the following there is a brief description of them: Archive playback Help Calendar 4.2.1. Calculations The ZEUS SCADA can perform various calculations based on the existing data. The results of the calculations can be handled in the same way like all other data in the system, namely they can be displayed on the screens, event logs, trends diagrams, etc. Example of calculations that can be configured: Transformer load in % Transformer power factor Node power Feeder power The calculations are processed by the interpreter process and the configuration can be made using the Proform editor. The syntax used for calculations is the Yabasic which is a simple basic interpreter. Configuration Runner configuration - server process: Server process <application dir>/bin/interpreter Parameters: Parameter -x Description 128 character event name (exp_namexl; exps_namexl) used instead of 45 character name (exphname; expshname) Configuration file: Server process <application dir>/config/servers/entity.dat Configuration file can be edited also using text editor. Database configuration is similar to measurement and digital signals configuration. The following tables are related to the function: Table name exppar expspar Description table of analogue calculation results table of signal calculation results 62/70 Note ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION table of diagnostic system data diagstatus data are stored in the on-line database and are used for screen display. Data written by the interpreter process into the expspar or exppar tables can be configured to appear in the event log and/or alarm log. These data have additional status bits because the resulting status is influenced by all components of the calculation (source data) and by the calculation itself. 4.2.2. Archive playback The playback function can be started typically on an Engineering Workstation, or any other Workstation that is not used for system operation at the moment of archive playback. The archive playback is a separate operational mode; it is started using a separate runner configuration file. The preconditions of running a Workstation in playback mode are the following: Running playback_archiver module on the server (the module shall have run for sufficient time before starting the playback) Existing playback_data_server_sql module on the Workstation The archive files created on the server have to be copied to the Workstation; this can be done: o manually; the contents of the following directory has to be copied from the server to the client (Engineering) computer: Path <application dir>/data/playback/ o or automatically using the following built-in script: Path <application dir>/scripts/rsync_playback_data.sh Playback can be accelerated, slowed down, stopped or restarted as required. 4.2.3. Printing Print function is available from the graphical user interface. The following programs have printing possibilities: xview, xevent, evlogd. The printing function uses the printer(s) configured in the Linux operating system. Configuration Firstly the printer (or printers) has to be installed within the Linux system, then in the ZEUS system the following configuration has to be done: defining path for ‘print to disk’ function defining path for ‘print to usb stick’ function 63/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION setting preview program parameters setting header and footer parameters Configurations are made in the following files: Path <application dir>/config/clients/xview.ini <application dir>/config/clients/xevent.ini 4.2.4. Help The help system is a web-based document which can be opened in the following way: Using the help icon located on the top of the xview display. On open the table of contents will be displayed. Using the ‘Help’ buttons located all over the graphical screens, e.g. in the data windows of measurement and signals. Using this way the paragraph related to the function will be displayed automatically. Configuration Help system is located by default in the following directory of ZEUS system: Path <application dir>/help The help system is structured on paragraphs located inside the ‘help’ directory. If modification of the help paragraphs is necessary, then the following file has to be edited: Path <application dir>/help/list.html 4.2.5. Calendar The ZEUS system is provided with a simple, Java-based calendar function. The calendar covers the following time range: years between 1900 and 2100 inclusive. It displays the date in a month view, the number of the week and it has controls to jump on year, month and the actual day. Configuration Path <application dir>/bin/Calendar.jar The Calendar can be displayed using a graphical icon located on the top-right part of xview. The following configuration is necessary: Path <application dir>/config/xview.ini Syntax ACT_BUTTON = "calendar.xpm", "java&-jar&./bin/Calendar.jar&geometry&(1400,17)", "Calendar" The icon file must be located in the following place: 64/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION Path <application dir>/images/xpm/calendar.xpm 4.3. System Diagnostics The ZEUS system has a number of built-in diagnostic processes and features that assure the robustness of the system. The most important elements of system diagnostic are the following: watchdog process. device status checks using native scripts Nagios (open source computer and network monitoring software application) 4.3.1. Watchdog ‘watchdog’ process is configured to run as part of every runner process. It has different target on server and client computer: In both server and client computer it watches the availability of the following processes: rqserver msgserver The action triggered in case of unavailability of any of the watched processes is different in case of server and client computer. server: the watchdog will trigger the reboot of the server computer client: the watchdog will trigger the restart of the client processes configured in the ‘runner’ configuration. In this way it is assured that the client always displays valid data in the system. 4.3.2. Device status checks Operational status of the SCADA system and of the connected RTUs is monitored by built-in diagnostic processes. Failures in the system can generate alarms and events. The following technical areas are monitored: communication with RTUs status of servers (Primary or Secondary) availability of devices connected to the network It is possible to install and configure third-party diagnostic system; the best experiences are achieved with Nagios. In the ZEUS SCADA the built-in processes that are used to manage diagnostic system are the interpreter and a number of predefined Bash scripts. Configuration: Runner configuration of interpreter: 65/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION configuration syntax <application dir>/bin/interpreter configuration file <application dir>/config/servers/interpreter/entity.dat Parameters: Parameter -h -f/-F Description host name - used in dual systems name of basic file - used by GUI for testing purposes Database configuration: Table name diagstatus diagstatus Description name of device status fields of monitored Ethernet devices Note key field diagstatus Field name status_ident eth0_status eth1_status eth2_status master_status status fields of server status Primary or Secondary status detection diagstatus ups_status status fields of monitored UPS devices Principle: diagstatus table is updated by processes configured in built-in bash scripts. The interpreter updates the table expspar which allows further configuration possibilities: alarm and event Script name bond_status.sh Description hamon_status.sh checks status of servers (Primary or Secondary) iec_srv.sh checks status of communication between server and RTUs; (IEC101 or IEC104) ping_status.sh checks status of other Ethernet devices (RTUs) ups_status.sh checks status of UPS devices (connected, not connected, on-battery) checks status of devices connected to SCADA network (only servers and workstation Ethernet devices) 66/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 5. Configuration tools The ZEUS SCADA system configuration is based mostly on two programs: the database editor and the graphical picture editor. In addition the Proform calculation editor can be used to create calculations. The system designer has to be familiar with a text editor to edit the configuration files. These base programs have detailed descriptions so only a brief introduction will be presented: The database editor program runs on Windows (XP or Win 7) operation system and it is called ‘Xfill’. It has several built-in functions such as data import and export default fill of most important data tables control command configuration Fill and check identifiers Compare database versions, etc. The input of the program are the description files of the RTUs which can be xml or other supported formats; it is also possible to import direction descriptions created in Excel format. The output of the database editor is a number of sql files which have to be copied into the file system of ZEUS. The ‘Proedit’ picture editor runs on Linux operation system and it is called ‘Proedit’. It allows for creating graphical pictures, objects, and configuring the object’s dynamic properties. The output files have binary format that can be opened by xview. It is also possible to import wmf or xpm graphical files to use them as background. The Proform editor provides a comfortable environment to create calculation algorithms using Yabasic (BASIC-like) language. The Linux operating system has many built-in text editors, some of them are Windows-like (e.g. Kate), others are dedicated to experienced users, like vi. The latter has the advantage that it is present in most Linux distributions. One of the simplest editors is the Midnight Commanders’ builtin editor; Midnight Commander is a simple file manager which covers all file management- and editor needs of a system designer when configuring ZEUS system. 67/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION 6. Appendix A The base directory of the ZEUS application is the following: Path /usr/local/zeus/app-zeus-user-location This is used as <application_dir> throughout the document The following list contains the directory structure within the application main directory. <application_dir> app-defaults /. /./. /././. hu_HU en_US de_DE tr_TR bin lib config clients runners servers data Note Resource files Hungarian English (US) German Turkish binary files system files Configuration files client configurations runner configurations process configurations Data archive files evcentr events archive filters iec870_gui j2_export swseq trserver archive database db.src db.zdb help images bmp xbm xpm locale hu_HU en_US de_DE tr_TR safetydoc savings grafpic playback 68/70 event log files (last week) event log files (older) saved event log filters saved IEC101 logs saved DP status data files switching sequences trend archive files (last month) trend archive files (older) Database files offline database files (sql) real-time database files help files image files displayed in xevent image files (bmp type) image files (xbm type) image files (xpm type) Resource files (notifications) Hungarian English (US) German Turkish Safety document function files Saved files by function graphical files playback files ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION trendprg xdiv xevent xevent trend archive export files xdiv files event log files xevent files Graphical system files binary files eps files links to binary files ProEdit log files Object library schema files wmf files Diagnostic scripts by function schema bin eps grafpic log objlib sch wmf scripts evlog kdsync pendrive sql startup sysdiag topol2 trace Log files by function dbcoresql evlog grafpic hamon lc uid voice binary files of GUI alarm files (wav) The following list contains the operating system directories and files related to ZEUS SCADA: root directory Note etc/hosts host file etc/services services configuration file ZEUS services are added to the end of the file etc/logrotate ZEUS log rotation configuration etc/sysconfig/xgramservers startup configuration etc/sysconfig/i18n language setting home/xgram/.Xclients GUI configuration; Motif configuration, backround picture, screensaver u01/app/oracle Postgres SQL database location usr/bin/sagateway SAGateway binary file usr/share/SAGateway/ SAGateway web-configuration usr/share/X11/fonts ZEUS fonts var/log/iec104/rtu.log log file; one file/RTU, file name is created according to the RTU name var/log/xgram.info ZEUS info messages var/log/xgram.notice ZEUS notice messages var/log/xgram.warning ZEUS warning messages var/log/xgram.err ZEUS error messages var/log/xgram.crit ZEUS critical messages 69/70 ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION var/log/xgram.debug var/log/messages var/log/messages.1 var/log/messages.2 var/log/messages.3 var/log/messages.4 var/xgram ZEUS debug messages all system messages and all ZEUS messages rotated messages 1st part rotated messages 2st part rotated messages 3st part rotated messages 4st part; oldest is deleted cyclically according to logrotate configuration time spent since last ZEUS start (sec) 70/70
