Zeus SCADA System Technical Specification

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

ZEUS SCADA SYSTEM TECHNICAL SPECIFICATION

3/70

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


4/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


5/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


6/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


7/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.


8/70

The following schema shows typical system architecture for medium/large applications:

Primary

ServerSecondary

Server

Workstation 1 Workstation 2

Communication

equipment

RTU 1 RTU 2 RTU 3

Data transmission newtwork

PrinterEngineering

Firewall

Time Server

Remote terminal

Maintenance

Maintenance

Maintenance

Customer network

SCADA network

LAN

RAID

Unit

UID 1 2

1 2 3 4 5 6 7 8HP

DIMMS

PCI

RISER

CAGE

FANS

POWER

SUPPLY

POWER

SUPPLY

PROCPROC

DIMMS

MIRROR

OVERTEMP

INTERLOCK

PP

M

ProLiantDL385 G2

UID 1 2

1 2 3 4 5 6 7 8HP

DIMMS

PCI

RISER

CAGE

FANS

POWER

SUPPLY

POWER

SUPPLY

PROCPROC

DIMMS

MIRROR

OVERTEMP

INTERLOCK

PP

M

ProLiantDL385 G2

HP

workstation

xw4600

HP

workstation

xw4600

HP

workstation

xw4600

HEWLETTPACKARD

inputauto

HP LP2045W

inputauto

HP LP2045W

inputauto

HP LP2045W

inputauto

HP LP2045W

inputauto

HP LP2045W

inputauto

HP LP2045W

inputauto

HP LP2045W

inputauto

HP LP2045W

inputauto

HP LP2045W

inputauto

HP LP2045W

SYST RPS

STRT DUPLXSPEEDUTIL

MODE

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 B100Base-FX

Catalyst 2950 SERIES10Base-T/100Base-TX

SYST RPS

STRT DUPLXSPEEDUTIL

MODE

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 B100Base-FX

Catalyst 2950 SERIES10Base-T/100Base-TX

GPS/NTP

Model Cisco 828 +5, +12, -12, -24, -71 VDC

TO HUBTO PC

ETHERNET 10 BASE T

4 13 2

CONSOLE G.SHDSL

Model Cisco 828 +5, +12, -12, -24, -71 VDC

TO HUBTO PC

ETHERNET 10 BASE T

4 13 2

CONSOLE G.SHDSL

Model Cisco 828 +5, +12, -12, -24, -71 VDC

TO HUBTO PC

ETHERNET 10 BASE T

4 13 2

CONSOLE G.SHDSL

Model Cisco 828 +5, +12, -12, -24, -71 VDC

TO HUBTO PC

ETHERNET 10 BASE T

4 13 2

CONSOLE G.SHDSL

Model Cisco 828 +5, +12, -12, -24, -71 VDC

TO HUBTO PC

ETHERNET 10 BASE T

4 13 2

CONSOLE G.SHDSL

CISCO ASA 5510

POWER STATUS ACTIVE VPN FLASH

Adaptive Security Appliance

SERIES

HP

workstation

xw4600

inputauto

HP LP2045W

Communication

equipment

LAN

Technology network

Dual LAN

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).


9/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 MB memory Graphic card with 128 MB or more memory

Dual system

Hardware requirements (server):

Minimum Proposed



2 GB RAM 4 GB or more RAM

36 GB HD (SAS) 36 GB HD (SAS) or higher

Graphic card with 64 MB memory

Graphic card with 64 MB or more memory

Hardware requirements (client):


10/70

Minimum Proposed



2 GB RAM 4 GB or more RAM o

36 GB HD (SAS or SATA) 36 GB HD (SAS or SATA) or higher

Graphic card with 128 MB memory

Graphic card with 128 MB or more memory

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.


11/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


12/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

event log files

client module; runs only to-

gether with msgserver

evlogd Postgres sql-based event

server

client module; runs only to-

gether with msgserver

hamon dual server role manager;

sets the Primary and Sec-

ondary server modes

used only in dual systems

iec870_101 IEC101 communication

process

iec870_104 IEC104 communication

process

interpreter logical calculation process programmable using Yabasic

programming language

msgserver internal communication

process

data link between processes

proc processing module - sets

the status and value of

data


13/70

playback_archiver playback function archiver

process

runs on Primary Server

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

process

xview contains a graphical

trend viewer program

watchdog assures the stop and/or

restart of critical processes

checks the availability of

rqserver, msgserver pro-

cesses

alarmlist_gui alarm list runs only together with alarmd

EventLog Java- and Postgres SQL

based event log

runs only together with

rqserver and evlogd

playback_archiver

playback function

proedit graphical screen editor

program

runs only together with rqserver

voiced sound alarm generating

process

runs only together with alarmd

process

xevent Event log (tex-based) runs only together with

rqserver and msgserver

xview Screen display process,

part of SCADA software

GUI


watchdog assures the stop and/or

restart of critical processes

checks the availability of

rqserver process

Client modules (in alphabetical order):

Module name Description Note

alarmlist_gui alarm list


EventLog Java- and Postgres SQL

based event log


rqserver and evlogd

playback_

play-back_data_server_sql

playback function client

process

runs only together with play-back_archiver


14/70

proedit graphical screen editor

program


voiced sound alarm generating

process


process

xevent Event log (tex-based)


rqserver and msgserver

xview Screen display process,

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/

required process

runner rqserver msgserver proc iec870_101

or

iec870_104

check-

tim

Core processes YES YES YES YES YES YES

Processes of ZEUS necessary for specific functions:

ZEUS Function/

required process

xview xevent

or

evlogd

alarmd

alarmlist_gui

voiced

control

command

trserver topol2

Basic signal and

measurement display

including access

control, data lists

YES - - -

event log - YES - -

alarm, alarm log - - YES -

control command YES YES

trend display YES

YES

voltage-dependent

colouring

YES

YES

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_ data_server_sql

client process

Calculations interpreter server process

Simulation simul server process


15/70

Dual system man-

agement

hamon to be used in dual system;

runs on both servers

Diagnostic watchdog process runs both on servers and

client computers

Simplified block scheme of client-server and communication processes:

- xview - alarmlist

- xevent - evlogd

- voiced - watchdog

- SAGateway

- rqserver - alarmd

- msgserver - trserverl

- proc - control

- watchdog - setpoint

ZEUS client

ZEUS server

- IEC104 (client)Communication

processes:

Core processes:

Core processes:

RTU

IEC104

(server)

Relay

IEC103

(server)

PLC

MODBUS

(slave)

RTU

IEC

61850

IEC103

client

IEC104

server

MODBUS

master

IEC

61850

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

3.2. Start and stop

Starting of the SCADA system is realised by the use of operating system functionality at service

level. For this a separate service is created called ‘xgramservers’. To start the SCADA system

automatically this service must be configured in run levels 3, 4, 5 and 0. Running of ZEUS 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.


16/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 -i 02

identity (server1)

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


17/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.


18/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


19/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.


20/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.


21/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.


22/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.


23/70

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:

Status area Basic screen Event area


24/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

OFF = hide

default: OFF; if active, it is displayed on the normal

zoom level, otherwise only when zooming in

ZOOM_MAP_SIZE 10÷50% 25%; defines the zoom map window size in % of the

original screen size

Database configuration:

Table

name

Field name Description Note

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

a screen

default: 0


25/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




26/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

xvevent.ini

#include ./config/clients/xvevent.ini

Configurable parameters of the xevent process:

Parameter Value Default value, notes

XEVENT_INSTANCE instance number - unique for

every client (terminal)

0

LOGOSTR Logo text that appears in the

printed header

ZEUS-SCADA

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

Name of server host

Name of server host

not used in

single-computer

configuration SERVER_HOST2

SERVER_HOST3

Location and name of the archive files:


27/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

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

event

aclocation/ac_loc_name

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.


28/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);


29/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

the program in full window

OFF

grid option makes possible displaying

the grid

ON

menu option makes possible displaying

the menu

OFF

sortStationNames option makes possible displaying

the menu

OFF


30/70

onlineShowingColumns select columns to display and

column widths in pixel

dailySerialNumber:100,

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

event log window (R,G,B; deci-

mal)

49,76,82

font setting font type and size Arial 0 14

ip hostname of server where the

evlogd process runs and port

number

srv:4040

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),


31/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

…

ac_ws_32

link between functions and

workstations

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

…

ac_term_63

terminal matrix

actermxtseg ac_tseg_01

…

ac_tseg_16

link between terminals and

technological segments

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:


32/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.


33/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:


34/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


35/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.


36/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:


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


37/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)


38/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


39/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).


40/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.


41/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.


42/70

ZEUS server

RTU

IEC101 or IEC104

(server)

Relay

IEC103

(server)

PLC

MODBUS

(slave)

RTU

IEC

61850

IEC103

client

IEC104

server

MODBUS

master

IEC

61850

ZEUS client

SAGateway

control

iec870_101 or

iec870_104 client

rqserver

proc

xview

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


43/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


44/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.


45/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

the system yes, all alarms cleared yes, all sound alarms

cleared

by acknowledging every alarm on

a screen only all alarms on the

screen

all sound alarms caused

by objects on the

screen

by acknowledging one object only the object’s alarm

status cleared

only sound alarm

caused by the object

by stopping the sound no alarm cleared only sound is muted; the

next alarm will cause

the resuming of the

sound alarm

by muting the sound no alarm cleared all sounds muted;

only with sufficient op-

erator authority (used

for testing purposes)


46/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.


47/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


48/70

<application dir>/voice



alarms alrp_peident Name of alarm group key field

alarms SOUND_FILE0

SOUND_FILE1

SOUND_FILE2

SOUND_FILE3

Sound file name for the

0..3 alarm levels

alarms SOUND_VOL0

SOUND_VOL1

SOUND_VOL2

SOUND_VOL3

Volume level for the 0..3

alarm levels [range 0..100]

default: 100

allpar all_alarmgrp link between RTU groups

and alarm groups

link to alarms table

allpar all_ack link between RTU group

and segment with

acknowledge authority

link to actseglist ta-

ble

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

dudatime

dudarepeat

dudakeep

dudadisablesign

command inversion;

on time;

repeat cycle time;

repeated on time;

link to disable signal

fine-tuning parameters

See also database configuration related to measurement and signal status in paragraphs 4.1.1

Measurements and 4.1.2 Signals.

4.1.5. Trend monitoring

The trend monitoring function is designed to store and display historical data. Analogue 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).


49/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.


50/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 server

iec870_101 or

iec870_104 client Communication

processes:

RTU

IEC104

(server)

Relay

IEC103

(server)

PLC

MODBUS

(slave)

RTU

IEC

61850

IEC103

client

IEC104

server

MODBUS

master

IEC

61850

trserver

proc

ZEUS client

internal archive storage

external archive storage

(RAID)

interpreter

export

to file

print

Core

processes

rqserver

SAGateway

xdiagtrend display

xview

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:


51/70

Process Location Note

TREND_PATH storage path default: ./datatrserver

FILE_SIZE_WARNING warning generated when file

size exceeds value

default: 80 [MB]

EMPTY_SIZE_WARNING warning generated when hard

disk free space drops below

value

default: 50 [MB]

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

directory after ‘value’ days

default: 30 [days]

Location and name of the archive files:

Path

<application dir>/data/trserver/trend_archive.yyyy.mm.dd

<application dir>/data/trserver/archive/trend_archive.yyyy.mm.dd

Where yyyy=year; mm=month; dd=day



jelpar1 jeldtd1 trend processing flag trend processing only for

records marked with

value ‘1’ jelpar2 jeldtd2

anapar anadtd

anapar diagska diagram scale low limit can be different from-,

but must be within the

measuring range anapar diagskf diagram scale high limit

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.


52/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


53/70

-C use anapar/phcolor for colouring

-h help



galpar galname name or index of section

anapar galvan index of voltage meas-

urement

source of colouring

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.


54/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.


55/70

ZEUS server

Communication

processes:

RTU

IEC104

(server)

Relay

IEC103

(server)

PLC

MODBUS

(slave)

RTU

IEC

61850

IEC103

client

IEC104

server

MODBUS

master

IEC

61850

ZEUS client

grpcom

switching

sequence

SAGateway

control

iec870_101 or

iec870_104 client

rqserver

proc

xview

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




56/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).


57/70

Figure 9: Data list of measurements

Configuration



tdlist filter_name identifier of predefined

filters

used by Proedit

tdlist filter_this filter string what to filter

tdlist td_field link to field where the filter

is applied

where to filter

tdlist xpm_on

xpm_off

name of icon file assigned

to filter

how to apply filter

tdlist init_state filter flag filtering when list is

opened or only upon

pressing the filtering

button


58/70

keptip pic_action_param link between screen and

filter

filter will act as a

screen; it gains alarm

status when any data’s

alarm status is 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.


59/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


60/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).


61/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


62/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


63/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


64/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:


65/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:


66/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

eth1_status

eth2_status

status fields of monitored

Ethernet devices

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)


67/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.


68/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


69/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


70/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)

Documents

Zeus SCADA System Technical Specification