Zeus - Technical Specification - Eng - v101 - PP PDF

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 authori-
zation 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
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
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 de-
scribes 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
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
 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
2. System design
The ZEUS SCADA is a high level process control system which consists of software modules de-
veloped 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 in-
dustries. 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, Tur-
key.
 Middle-size applications are Local MMI of large electrical substations or other industry ap-
plications 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 - multi-
ple 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 config-
urations are based on dual server, multiple workstations, and large communication net-
works, 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 com-
munication 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
The following schema shows typical system architecture for medium/large applications:
Workstation 1 Workstation 2 Engineering Maintenance Printer Time Server
GPS/NTP
H
E
W
P
A
CL
E
T
K
A
RT
D
HP LP2045W HP LP2045W
auto input auto input
HP LP2045W
auto input
HP HP HP
workstation workstation workstation HP LP2045W
auto input
xw4600 xw4600 xw4600

SCADA network
10Base-T/100Base-TX Catalyst 2950 SERIES
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 A 100Base-FX B
SYST RPS
STRT UTIL DUPLXSPEED
MODE
10Base-T/100Base-TX Catalyst 2950 SERIES

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 A 100Base-FX B
SYST RPS
STRT UTIL DUPLXSPEED
MODE
Dual LAN
Primary Secondary
Server Server
POWER POWER
SUPPLY SUPPLY
PCI
RISER
CAGE
1 2 3 4 5 6 7 8
HP
ProLiant
DL385 G2 POWER POWER
SUPPLY SUPPLY
PCI
RISER
CAGE
1 2 3 4 5 6 7 8
HP
ProLiant
DL385 G2
Firewall CISCO ASA 5510 SERIES
Adaptive Security Appliance
PPM
PPM
POWER STATUS ACTIVE VPN FLASH

DIMMS DIMMS DIMMS DIMMS
PROC PROC PROC PROC
INTER INTER
LOCK LOCK
FANS FANS
OVER OVER
TEMP TEMP
MIRROR MIRROR
UID 1 2 UID 1 2
Customer network LAN

Communication TO HUB
TO PC
ETHERNET 10 BASE T
Model Cisco 828
CONSOLE G.SHDSL
+5, +12, -12, -24, -71 VDC
equipment
4 3 2 1
RAID
Unit HP
workstation
xw4600
HP LP2045W
auto input
Data transmission newtwork
Maintenance Remote terminal

Model Cisco 828 +5, +12, -12, -24, -71 VDC
TO HUB ETHERNET 10 BASE T CONSOLE G.SHDSL
TO PC
4 3 2 1
Technology network LAN
Communication TO HUB
TO PC
ETHERNET 10 BASE T
Model Cisco 828
CONSOLE G.SHDSL
+5, +12, -12, -24, -71 VDC
TO HUB
TO PC
ETHERNET 10 BASE T
Model Cisco 828
CONSOLE G.SHDSL
+5, +12, -12, -24, -71 VDC
TO HUB
TO PC
ETHERNET 10 BASE T
Model Cisco 828
CONSOLE G.SHDSL
+5, +12, -12, -24, -71 VDC
4 3 2 1 4 3 2 1 4 3 2 1
equipment
RTU 1 RTU 2 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 re-
quired availability.
 Network of RTUs can be also dual. In this case each RTU must have two interfaces to-
wards 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
 The workstations are connected to the Primary server as clients. The workstations are run-
ning 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 re-
sponse 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 hard-
ware requirements; e.g. Java-based applications.
 single- or dual configuration. In dual configuration additional processes have to be config-
ured 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 2 GHZ or higher multicore x86_32 or x86_64 system
512 MB RAM 1 GB or more RAM
40 GB HD (SATA) 256 GB HD (SATA) or higher
Graphic card with 128 Graphic card with 128 MB or more memory
MB memory
Dual system
Hardware requirements (server):
Minimum Proposed
1 GHz x86_32 or x86_64 2 GHZ or higher multicore x86_32 or x86_64 system
system
2 GB RAM
4 GB or more RAM
36 GB HD (SAS) 36 GB HD (SAS) or higher
MB memory
Hardware requirements (client):
9/70
Minimum Proposed
1 GHz x86_32 or x86_64 2 GHZ or higher multicore x86_32 or x86_64 system
system
2 GB RAM 4 GB or more RAM o
36 GB HD (SAS or SATA)
36 GB HD (SAS or SATA) or higher
MB memory
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 Second-
ary 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 inde-
pendently, and each server communicates with each RTU simultaneously. The only differ-
ence 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 Pri-
mary 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
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 recon-
nection 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 mainte-
nance:
 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
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 Note
alarmd alarm management pro-
cess
checktim time management process necessary when using IEC101
or IEC104 commands for time
setting
control control command process in hot-standby mode runs only
on the Primary server
evcentr event server - creates client module; runs only to-
event log files gether with msgserver
evlogd Postgres sql-based event client module; runs only to-
server gether with msgserver
hamon dual server role manager; used only in dual systems
sets the Primary and Sec-
ondary server modes
iec870_101 IEC101 communication
process
iec870_104 IEC104 communication
process
interpreter logical calculation process programmable using Yabasic
programming language
msgserver internal communication data link between processes
process
proc processing module - sets
the status and value of
data
12/70
playback_archiver playback function archiver runs on Primary Server

process
rqserver database server core process of the SCADA
system
runner management of running
processes
SAGateway communication process communication gateway for
IEC 61850, IEC 103 and Mod-
bus devices
setpoint setpoint process in hot-standby mode runs only
on the Primary Server
simul simulation process used
only for testing
topol2 topology analyser process voltage-dependent colouring
function
trserver analogue trend archiving xview contains a graphical
process trend viewer program
watchdog assures the stop and/or checks the availability of
restart of critical processes rqserver, msgserver pro-
cesses
alarmlist_gui alarm list runs only together with alarmd
EventLog Java- and Postgres SQL runs only together with
based event log rqserver and evlogd
playback_archiver playback function
proedit graphical screen editor runs only together with

program rqserver
voiced sound alarm generating runs only together with alarmd
process process
xevent Event log (tex-based) runs only together with
rqserver and msgserver
xview Screen display process, runs only together with
part of SCADA software rqserver
GUI
watchdog 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 runs only together with alarmd
alarm list
EventLog runs only together with
Java- and Postgres SQL
rqserver and evlogd
based event log
playback_
play- runs only together with play-
back_data_server_sql playback function client back_archiver
process
13/70
proedit runs only together with

graphical screen editor rqserver
program
voiced runs only together with alarmd
sound alarm generating
process
process
xevent runs only together with
Event log (tex-based)
rqserver and msgserver
xview runs only together with
Screen display process, rqserver
part of SCADA software
GUI
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/ runner rqserver msgserver proc iec870_101 check-
required process or tim
iec870_104
Core processes YES YES YES YES YES YES
Processes of ZEUS necessary for specific functions:
ZEUS Function/ xview xevent alarmd control trserver topol2
required process or alarmlist_gui
evlogd voiced command
Basic signal and YES - -
measurement display -
including access
control, data lists
event log - YES -
-
alarm, alarm log - - YES
-
control command YES YES
trend display YES YES
voltage-dependent YES YES

colouring
In addition to the above processes they are a number of special functions that need different pro-
cesses to be started. Also in case of dual system configuration an additional process has to be
configured:
ZEUS Function required process note
Playback playback_archiver server process
playback_ client process
data_server_sql
Calculations interpreter server process
Simulation simul server process
14/70
Dual system man- hamon to be used in dual system;

agement runs on both servers
Diagnostic watchdog process runs both on servers and
client computers
Simplified block scheme of client-server and communication processes:
ZEUS client
- xview - alarmlist
Core processes: - xevent - evlogd
- voiced - watchdog
ZEUS server
- rqserver - alarmd
- msgserver - trserverl
Core processes: - proc - control
- watchdog - setpoint
- SAGateway
Communication IEC104 IEC103 MODBUS IEC

- IEC104 (client) server client master 61850
processes:
RTU Relay PLC RTU

IEC104 IEC103 MODBUS IEC
(server) (server) (slave) 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 pro-
cesses is managed by so-called ‘runner’ processes. The runner processes are configured in con-
figuration files called also ‘runners’. Such runners are created separately for server and client pro-
cesses. Detailed description of system’s start and stop can be found in the ZEUS configuration
guide.
15/70
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 config-
ured 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 com-
munication 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 Description
-c <config file> config file located here:
<application dir>/config/servers/hamon.ini
-i 01 identity (server1)
-i 02 identity (server2)
Typically the following interfaces are configured in hamon.ini:
network device typically ‘bond0’ in case of dual network configuration
remote server name typically ‘server1’ and ‘server2’
name of common server 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 ob-
ject) and also in a file. The file that contains the dual status is located here:
Path
<application dir>/trace/hamon/ha
16/70
3.3.2. Dual network

Dual network configuration relies on duplicated network elements. This usually means two switch-
es 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 comput-
ers are connected.
17/70
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 sys-
tem. 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 Value
role in communication Unbalanced Master
communication port serial port
communication speed (bit/sec) 1200, 1800, 2400, 4800, 9600, 19200, 38400;
default rate: 9600
parity even, odd, none; default: none
frame length 5, 6, 7, 8; default: 8
stop bit 1, 2; default: 1
repeat count 1÷20, default: 5 (repeat interval: 3 sec)
link address 0÷255, default: 0
CAD 0÷65535; default: 0;
group obsolete, use ProcServicePort
ProcServicePort 64 char string, location: etc/services file
test on, off; default: off
TIME setting get, set, none; default: none
diagnostic features Watchdog, logging
message types 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 Value
role in communication IEC104 server or client
communication port TCP; default port: 2404
Link parameters (defaults) T0: 30 sec
T1: 15 sec
T2: 10 sec
18/70
Tcikl 50 sec (link drop if no messages during

timeout)
CRC If Link104_Crc=1 CRC232 checksum send-
ing (used by ProField RTU)
link address 0÷255, default: 0
ProcServicePort 64 char string, location: etc/services file
test on, off; default: off
TIME setting get, set, none; default: none
diagnostic features Watchdog, logging
message types 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:
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 trans-
fer
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
 Switching sequences - pre-configured switching sequences can be executed by the gate-

way. The sequences can be started by the ZEUS dispatcher using standard control com-
mands.
 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 interpret-
er 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
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 soft-
ware 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 pos-
sibilities 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 inde-
pendent 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
3.6.1. xview
This is the main display of the ZEUS SCADA system. It is the primary interface used by the opera-
tor 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 tech-
nology 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 need-
ed. 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
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
bin/xview ./config/clients/xview.ini
Parameters:
-display <host:x.y> screen configuration; on local computer ‘host’ is not
necessary, e.g. -display 0.0 (first screen)
-M maximize; xview will be displayed full-screen
--geometry geometry string set xview size and position
-h 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 con-
figuration 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
start type next program start program owner program group owner
restart nowait root root
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 Note
<application dir>/config/clients/xview.ini parent file
<application dir>/config/clients/xv.ws1_1.ini 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:
xv.ws1_1.ini
#include ./config/clients/xview.ini
xv.ws1_2.ini
xv.ws1_3.ini
xv.ws1_4.ini
xview.ini
Zoom map parameters:

Parameter Value Default value, notes
ZOOM_MAP_ACTIVE ON = show default: OFF; if active, it is displayed on the normal
OFF = hide 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 Field name Description Note
name
keptip kepnev name of screen
keptip keprol name of parent screen used for alarm system
keptip kepazo short name of screen displayed in xview
keptip keprek screen index used by ProEdit
keptip alarmgrp alarm group link to alarms table
keptip pic_action action related to opening default: 0
a screen
24/70
keptip pic_action_param parameters of action default: NULL0

anapar a_alarmpic link to keptip/kepnev part of alarm system
jelpar1 j1_alarmpic link to keptip/kepnev part of alarm system
jelpar2 j2_alarmpic link to keptip/kepnev 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 appro-
priate 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
25/70
bin/xevent ./config/clients/xevent.ini
Parameters:
-display <host:x.y> screen configuration; on local computer ‘host’ is not
necessary, e.g. -display 0.0 (first screen)
--geometry geometry string 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 con-
figuration 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 moni-
tors):
configuration syntax Note
bin/xevent ./config/clients/xe.ws1_1.ini example: Workstation with 4
screens (only one event log on first
screen)
Cascading configuration files:
Location of configuration files Note
<application dir>/config/clients/xevent.ini parent file
<application dir>/config/clients/xe.ws1_1.ini 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 Value Default value, notes
XEVENT_INSTANCE instance number - unique for 0
every client (terminal)
LOGOSTR Logo text that appears in the ZEUS-SCADA
printed header
SHOW_MILLISEC display milliseconds in the time yes
LINE_COUNTING display event serial numbers no
ALARM_MULTISOURCE technological segments display no
SHOW_ALL_RTU no
SCADA_SHOW ALL
ACCESS_GROUP Name of client location see also file: /etc/services
“IEC870 services” section
SERVER_HOST1 Name of server host not used in
SERVER_HOST2 Name of server host single-computer
SERVER_HOST3 Name of server host configuration
Location and name of the archive files:
26/70
Path
<application dir>/data/evcentr/events/yyyy.mm.dd.eve
<application dir>/data/evcentr/events/yyyy.mm.dd.idx
<application dir>/data/evcentr/events/archive/yyyy.mm.dd.eve
<application 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.
Table Field name Description Note
name
eventcatx catnamx short name of location
eventcatx catcolx colour of event
eventcatx catscada link to location table aclocation/ac_loc_name
eventcatx evx_id index field key field
eventcaty catnamy short name of location
eventcaty catcoly colour of event
eventcaty catcbgy background colour of aclocation/ac_loc_name
event
eventcaty catval colour category index categories filled in anapar,
jelpar1, jelpar2, etc. ta-
bles
anapar atipus event type e.g. protection
anapar ahelye event location e.g. field number
anapar a_evx event index used by Xfill wizard
jelpar1 stipusf event type 0 to 1 e.g. protection, diagnostic,
etc.
jelpar1 stipusl event type 1 to 0
jelpar1 shelye1 event location e.g. field number
jelpar1 j1_evx event index used by Xfill wizard
jelpar2 stipus2 event type e.g. breaker, switch, etc.
jelpar2 shelye2 event location e.g. field number
jelpar2 j2_evx event index 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 fil-
tering possibilities.
27/70
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 mid-
night.
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, there-
fore it shows the real technological time. The display system assigns a timestamp to events initiat-
ed 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
 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 Value Default value
geometry position and size of graphical
program on the screen
fullWindow option makes possible displaying OFF
the program in full window
grid option makes possible displaying ON
the grid
menu option makes possible displaying OFF
the menu
sortStationNames option makes possible displaying OFF
the menu
29/70
onlineShowingColumns select columns to display and dailySerialNumber:100,

column widths in pixel date:100, time:100,
eventText:800, opera-
tor:200
offlineShowingColumns Name of server host
colour setting foreground colour of
event text (different colour for
every event type)
background setting background colour of the 49,76,82
event log window (R,G,B; deci-
mal)
font setting font type and size Arial 0 14
ip hostname of server where the srv:4040
evlogd process runs and port
number
Location of configuration file:
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 Ac-
cess 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 com-
mands 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 oper-
ator 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 as-
signed a user name, a role and a secret password. Generally the following roles are used:
 Operator (dispatcher),
 Administrator (SCADA system administrator),
30/70
 Developer (system engineers).
The SCADA system is suitable to control and monitor larger areas consisting of several technolog-
ical segments, using multiple workstations located even in different locations and operated by sev-
eral 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 seg-
ment 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 con-
trol over the other area in case of emergency.
Configuration
Table name Field name Description Note
acfunclist ac_func_name function name list of available functions
acfunxws ac_ws_01 link between functions and
… workstations
ac_ws_32
acloc2ws ac_ws_name link between locations and
workstations
aclocation ac_agtoobj link to access group
acoplist ac_op_lid name of dispatcher(s) long name
acposlist ac_pos_name list of operator roles
actermlist ac_term_name list of terminals one terminal needed for
each screen
actermxterm ac_term_00 terminal matrix
…
ac_term_63
actermxtseg ac_tseg_01 link between terminals and
… technological segments
ac_tseg_16
actseglist ac_tseg_name list of technological seg-
ments
acserveradm ac_alarmstat authority and alarm man-
agement
alarms alrp_peident list alarm of alarm groups also alarm sound set-
tings
terminals terminals_key alarm group management more alarm sound set-
tings
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
 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 set-
ting 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 pos-
sible:
Parameter Value Default value
SetTime off; on off
GetTime off; on off
RtuUtc off; on off
SetCmos=on off; on 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
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 pro-
file 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
 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 ex-
ternal 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 fol-
lowing areas:
 Personnel training
 Personnel registration and accounting including picture IDs, biometrics (fingerprint, voice,
face, iris recognition) etc.
 Maintenance and recovery plans
34/70
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 im-
portant to hide the operator’s access to the operating system features, thus preventing the dis-
patcher 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 acces-
sible 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 pro-
cessing are the actual value and the status. These results are then further used by other config-
ured 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
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 Data-
base Filling-in Guide.
The following parameters have effect in producing the actual value of the measurement:
Field name Description Note
skalaa signal range - minimum value
skalfe signal range - maximum value
helyer replaced value entered by dispatcher
helyet replaced value flag 0=not replaced, 1=replaced
lekapk zero threshold below this value skalaa value will be-
come the actual value
tavado physical range constant it’s value must be set according to the
range of the measurement, see the
following chart
filter digital filtering 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
The following parameters have effect in setting the status of the measurement:
hihjel credibility signal link link to a comm. status signal
hihals credibility low value
hihfls credibility high value
tiltott disabled flag set by dispatcher
36/70
hiszte dead zone effect on alarm status

lekapk zero threshold effect on actual value
anauza alarm for emergency low value
anaals alarm for low value
anafls alarm for high value
anauzf alarm for emergency high value
alflm1 low mask 1st alert level
allem1 high mask 1st alert level
a_alarmpic link to screen triggers alarm of the screen;
link to keptip table
a_alarmgrp link to alarm group link to alarms table
In order to display the current status levels, the following preliminary processing activities are car-
ried 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 val-
ues crossing technological limits)
 Setting zero threshold (for eliminating errors in the measured values near the measurement
scale’s lower limit)
37/70
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 (inter-
preter) 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 pro-
cesses, 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 sta-
tus of the signals. Complete reference of database fields can be found in document: Xgram Data-
base Filling-in Guide.
The following parameters have effect in producing the actual value of the DP signals (similar for SP
and ST signals):
nevhos2 signal name 46 characters only
j2_namexl signal name 128 characters
jehely2 replaced flag 0=not replaced, 1=replaced
38/70
jelhee2 replaced value can be set by dispatcher

szov002 text for 00 bit state displayed in data windows
szov002 text for 00 bit event displayed in event log
The following parameters have effect in setting the status of the DP signals (similar for SP and ST
signals):
jtiltt2 disabled flag can be set by dispatcher
jalmf12 bit mask for 1st level alarm state effect on alarm state
jalml12 bit mask for 1st level alarm state effect on alarm state
hibamk21 bit mask for error state effect on alarm state
j2_alarmpic link to screen triggers alarm of the screen
j2_alarmgrp link to alarm group

j2_alarmpic link to screen triggers alarm of the screen;
link to keptip table
j2_alarmgrp link to alarm group 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 moni-
tored 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
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 hav-
ing the necessary authorisation.
The GUI part of the control command window (see Hiba! A hivatkozási forrás nem található.) dis-
plays 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
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 sta-
tus 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 pro-
cess. Control commands are always initiated by the dispatcher logged-in with the necessary au-
thority. Switching sequences can be also configured, see paragraph 4.1.7.
41/70
ZEUS client xview
ZEUS server
SAGateway
control rqserver proc
iec870_101 or IEC104 IEC103 MODBUS IEC

iec870_104 client server client master 61850
RTU Relay PLC RTU

IEC101 or IEC104 IEC103 MODBUS IEC
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:
controlpar cmuknev short name of controls used in xevent event log (45
characters)
controlpar c_namexl long name of controls used in evlogd event log (128
characters)
controlpar cpvezobj link to cpvezobj table index of switch type
controlpar cjevez1 index of control primary RTU
controlpar cjevez2 index of control redundant RTU
controlpar ctmout control timeout (sec) check back signal timeout; no
alarm generated if signal ar-
rives within timeout
controlpar cvezben index of blocking signal interlocking function
controlpar cvezeng1 index of enabling signal OPEN control
controlpar cvezeng2 index of enabling signal CLOSE control
controlobj cjalla1 check back signal status OPEN control
controlobj cjallam1 check back signal mask OPEN control
controlobj cjalla2 check back signal status CLOSE control
42/70
controlobj cjallam2 check back signal mask CLOSE control

controlobj cobjtyp object type e.g. switch, breaker, etc.
jelpar1 ctrl1 index of control check back signal
jelpar2 ctrl2 index of control check back signal
steppar stpctrl index of control 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 docu-
ment: 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 affect-
ed 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 with-
in 20 seconds after OPEN or CLOSE selection; in this case the control window will be automatical-
ly closed and no control command is sent.
Disable function. When Disable button is pressed, the command window will be closed and no con-
trol 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 but-
tons 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
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 vis-
ual and audible alerts. The designer of the system has many possibilities to configure an appropri-
ate 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 acti-
vated 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 ob-
jects 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. but-
tons that will acquire the alarm status of the child screen thus making possible bringing to attention
several screens where alarms are present.
44/70
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 func-
tion 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 yes, all alarms cleared yes, all sound alarms
the system cleared
by acknowledging every alarm on only all alarms on the all sound alarms caused
a screen screen by objects on the
screen
by acknowledging one object only the object’s alarm only sound alarm
status cleared 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 op-
erator authority (used
for testing purposes)
45/70
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
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:
-t test mode
-h help
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
<application dir>/voice
alarms alrp_peident Name of alarm group key field
alarms SOUND_FILE0 Sound file name for the
SOUND_FILE1 0..3 alarm levels
SOUND_FILE2
SOUND_FILE3
alarms SOUND_VOL0 Volume level for the 0..3 default: 100
SOUND_VOL1 alarm levels [range 0..100]
SOUND_VOL2
SOUND_VOL3
allpar all_alarmgrp link between RTU groups link to alarms table
and alarm groups
allpar all_ack link between RTU group link to actseglist ta-
and segment with ble
acknowledge authority
anapar a_alarmpic link to alarm screen link to keptip table
keptip alarmgrp link to alarm group link to alarms table
keptip keprol link to parent screen alarm cascading func-
tion
dudapar dudaid Name of horn
dudapar dudaref link to horn command link to controlpar ta-
ble
dudapar dudacommon link to common horn common horn is acti-
vated together with
other horns
dudapar dudainversion command inversion; fine-tuning parameters
dudatime on time;
dudarepeat repeat cycle time;
dudakeep repeated on time;
dudadisablesign link to disable signal
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 measure-
ment 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
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 pres-
ence of the daily trend file. If no file found then a new file will be created; in case that the file al-
ready 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 stor-
age device to prevent the filling of the device. The internal resolution of the historical data is 1 sec.
49/70
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
xview export
to file
xdiag
trend display print
external archive storage

(RAID)
ZEUS server
rqserver trserver internal archive storage
Core
processes
interpreter proc
SAGateway
Communication iec870_101 or IEC104 IEC103 MODBUS IEC

processes: iec870_104 client server client master 61850
RTU Relay PLC RTU

Configuration:
<application dir>/ bin/trserver
Parameters:
-h <host> host name of other server in dual system
-s silent mode; it does not create trend file. This is required for playback
servers
-? help
Configuration and log files:
Process Location Note
trserver <application dir>/config/servers/trserver.ini
Configuration within the trserver.ini file:
50/70
Process Location Note

TREND_PATH storage path default: ./datatrserver
FILE_SIZE_WARNING warning generated when file default: 80 [MB]
size exceeds value
EMPTY_SIZE_WARNING warning generated when hard default: 50 [MB]
disk free space drops below
value
KEEP_EMPTY minimum empty space value default: 20 [MB]
DATA_BLOCK_SIZE amount of data/data block default: 32
SIGNIFICANT_IN_PERCENT significant change value default: 0,4 [%]
ARCHIVE_TREND_MOVING move older data to archive default: 30 [days]
directory after ‘value’ 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
jelpar1 jeldtd1 trend processing flag trend processing only for
jelpar2 jeldtd2 records marked with
anapar anadtd value ‘1’
anapar diagska diagram scale low limit can be different from-,

anapar diagskf diagram scale high limit 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 calcu-
lates 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
 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 com-
mand 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:
<application dir>/bin/topol2
configuration file
<application dir>/config/servers/topol.ini
Parameters:
-i switch on Intelligent Alarm Focus (IAF)
-I handle invalid switch state
52/70
-C use anapar/phcolor for colouring

-h help
galpar galname name or index of section
anapar galvan index of voltage meas- source of colouring
urement
anapar phcolor bitmask of phase source
jelpar1 galvan11 section on one side of
switch
jelpar1 galvan21 section on other side of
switch
jelpar1 j1_galvan_flag index of earthed section in case of three-state
switch
jelpar2 galvan12 section on one side of
switch
jelpar2 galvan22 section on other side of
switch
jelpar2 j2_galvan_flag index of earthed section in case of three-state
switch
StatuGalvan status description name of used bits
Phcolor status description 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 com-
mands and the preconditions of each command is predefined during initial configuration of the sys-
tem. 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 execut-
ed automatically one after another until the last step is executed.
 In manual mode, the system requires dispatcher confirmation before each command.
53/70
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 se-
quence 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 dis-
played).
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 se-
quences. The SAGateway contains an xml type configuration file that can be edited using the SA-
Gateway Configuration Tool. The switching sequences can be initiated only by the dispatcher; the
SAGateway can communicate with the rqserver process during execution of switching se-
quences.
54/70
xview
ZEUS client
switching
sequence
ZEUS server
SAGateway
control
grpcom
rqserver
proc
Communication iec870_101 or IEC104 IEC103 MODBUS IEC

processes: iec870_104 client server client master 61850
RTU Relay PLC RTU

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’ ex-
tension 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:
program name with path followed by parameters if any
/usr/bin/sagateway /etc/SAGateway/grpcom.xml -l
/etc/SAGateway/saglogconf.xml
Location Note
/etc/SAGateway/grpcom.xml
/etc/SAGateway/saglogconf.xml log parameters
/var/log/sagateway.log log file
55/70
grpcom gc_peident sequence identifier key field used by pro-

gram
grpcom gc_name sequence name visible in GUI
grpcom gc_filter sequence filter used for grouping se-
quences 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
Figure 9: Data list of measurements
Configuration
tdlist filter_name identifier of predefined used by Proedit
filters
tdlist filter_this filter string what to filter
tdlist td_field link to field where the filter where to filter
is applied
tdlist xpm_on name of icon file assigned how to apply filter
xpm_off to filter
tdlist init_state filter flag filtering when list is
opened or only upon
pressing the filtering
button
57/70
keptip pic_action_param link between screen and filter will act as a

filter screen; it gains alarm
status when any data’s
alarm status is activat-
ed
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 (unacknowl-
edged, 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 loca-
tion (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 ex-
ist in the given moment at the location. By clicking on the cells, data of the selected location
are displayed as a list.
58/70
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:

Location Note
59/70
<application dir>/config/clients/xstatus.ini xview.ini file contains

reference to this path
Parameters Description Note
COLUMNNAME data type e.g. MEAS
STATUS database reference to value e.g.: ANAVAL STATU1
LISTNAME database reference to name e.g.: ANAPAR NEVHOS
ALARMPICTURE database reference to alarm screen e.g. ANAPAR A_ALARMPIC
ACCESS database reference to alarm field e.g. ANAPAR ANA_SHOW
WIN_CMD_IDX index of data window e.g. 3 for analogue
BITNAME name of index field 16 rows
ACK_CMD_IDX code of acknowledge action 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 dur-
ing 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
Figure 11: Duty event and instructions list
Configuration
The function is based on a Postgres SQL database, a server process (villnap) and a Java-
based GUI process (PowerWorksLog.jar).
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
berendezes brzes_namex list of objects e.g. breakers
feszszint fsz_namex list of voltage levels e.g. 110, 20 kV
mezo mezo_namex list of fields e.g. feeders
61/70
4.2. Other functions of the Zeus SCADA system

The Zeus SCADA system contains many additional functions. In the following there is a brief de-
scription 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 inter-
preter.
Configuration
Runner configuration - server process:
Server process
<application dir>/bin/interpreter
Parameters:
-x 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 Description Note
exppar table of analogue calculation results
expspar table of signal calculation results
62/70
diagstatus table of diagnostic system data 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 result-
ing 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 Work-
station that is not used for system operation at the moment of archive playback. The archive play-
back 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 suffi-
cient 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
 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 dis-
played 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
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 ro-
bustness 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 ‘run-
ner’ 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 diag-
nostic 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 diag-
nostic system are the interpreter and a number of predefined Bash scripts.
Configuration:
Runner configuration of interpreter:
65/70
<application dir>/bin/interpreter
configuration file
<application dir>/config/servers/interpreter/entity.dat
Parameters:
-h host name - used in dual systems
-f/-F name of basic file - used by GUI for testing purposes
diagstatus status_ident name of device key field
diagstatus eth0_status status fields of monitored
eth1_status Ethernet devices
eth2_status
diagstatus 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 in-
terpreter updates the table expspar which allows further configuration possibilities: alarm and
event
Script name Description
bond_status.sh checks status of devices connected to SCADA net-
work (only servers and workstation Ethernet devices)
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 con-
nected, on-battery)
66/70
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 calcu-
lations. 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 Ya-
basic (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’ built-
in 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
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> /. /./. /././. Note
app-defaults Resource files
hu_HU Hungarian
en_US English (US)
de_DE German
tr_TR Turkish
bin binary files
lib system files
config Configuration files
clients client configurations
runners runner configurations
servers process configurations
data Data archive files
evcentr
events event log files (last week)
archive event log files (older)
filters saved event log filters
iec870_gui saved IEC101 logs
j2_export saved DP status data files
swseq switching sequences
trserver trend archive files (last month)
archive trend archive files (older)
database Database files
db.src offline database files (sql)
db.zdb real-time database files
help help files
images image files displayed in xevent
bmp image files (bmp type)
xbm image files (xbm type)
xpm image files (xpm type)
locale Resource files (notifications)
hu_HU Hungarian
en_US English (US)
de_DE German
tr_TR Turkish
safetydoc Safety document function files
savings Saved files by function
grafpic graphical files
playback playback files
68/70
trendprg trend archive export files

xdiv xdiv files
xevent event log files
xevent xevent files
schema Graphical system files
bin binary files
eps eps files
grafpic links to binary files
log ProEdit log files
objlib Object library
sch schema files
wmf wmf files
scripts Diagnostic scripts by function
evlog
kdsync
pendrive
sql
startup
sysdiag
topol2
trace Log files by function
dbcoresql
evlog
grafpic
hamon
lc
uid binary files of GUI
voice 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 pic-
ture, 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
var/log/xgram.debug ZEUS debug messages

var/log/messages all system messages and all ZEUS messages
var/log/messages.1 rotated messages 1st part
var/log/messages.4 rotated messages 4st part; oldest is deleted cyclically
according to logrotate configuration
var/xgram time spent since last ZEUS start (sec)
70/70

Zeus - Technical Specification - Eng - v101 - PP PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Zeus - Technical Specification - Eng - v101 - PP PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Zeus SCADA system

All rights reserved.

# Date Editor Amendment

1.1. Table of abbreviations

Table 1 Table of Abbreviations

1.2. Intended audience

1.3. Reference documents

Workstation 1 Workstation 2 Engineering Maintenance Printer Time Server

xw4600 xw4600 xw4600

STRT UTIL DUPLXSPEED

10Base-T/100Base-TX Catalyst 2950 SERIES

STRT UTIL DUPLXSPEED

Firewall CISCO ASA 5510 SERIES

Adaptive Security Appliance

POWER STATUS ACTIVE VPN FLASH

PROC PROC PROC PROC

Customer network LAN

Data transmission newtwork

Maintenance Remote terminal

Technology network LAN

RTU 1 RTU 2 RTU 3 Maintenance

ZEUS system structure

2.1. Configuration principle

 number of controlled objects

 Configuration of the picture system and the configuration files.

3.1. Process configuration

playback_archiver playback function archiver runs on Primary Server

proedit graphical screen editor runs only together with

proedit runs only together with

trend display YES YES

voltage-dependent YES YES

Dual system man- hamon to be used in dual system;

Communication IEC104 IEC103 MODBUS IEC

RTU Relay PLC RTU

The full list of ZEUS directories and files is given in Appendix A.

3.2. Start and stop

3.3. Dual system configuration

3.3.1. Dual system management

3.3.2. Dual network

3.4. Data Communication

Tcikl 50 sec (link drop if no messages during

Other SAGateway functions that provide additional functionality to ZEUS SCADA:

 Switching sequences - pre-configured switching sequences can be executed by the gate-

3.5. Data archive

 trend archives (historical data)

3.5.1. Trend archives

3.5.2. Event logs

 the text-format logs created by the xevent process

3.6. Graphical display

Figure 1: Display of the Zeus SCADA system

Zoom map parameters:

keptip pic_action_param parameters of action default: NULL0

3.6.2. Event log

 xevent (older, text-based type event log)

Configurable parameters of the xevent process:

In the event log the number of rows is not limited.

The functions of the event log

 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

onlineShowingColumns select columns to display and dailySerialNumber:100,

3.7. Authority control