SHERPA/PC : THE SCADA OF ELIOP

Code: 4913 9004

Version: 1.0/023
 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

General Table of Contents

1. INTRODUCTION......................................................................................................... 1-1

2. MAIN CHARACTERISTICS OF THE SCADA SHERPA/PC...................................... 2-1

2.1 OPEN SYSTEM............................................................................................................ 2-2
2.1.1 Hardware ............................................................................................................ 2-2
2.1.2 Operating system................................................................................................. 2-2
2.1.3 Communications.................................................................................................. 2-3
2.1.4 Man-Machine Interface ....................................................................................... 2-4
2.1.5 Storing the information........................................................................................ 2-6
2.1.5.1 RDBMS system (Configuration and HDB)............................................................... 2-7
2.1.5.2 Real Time database.................................................................................................. 2-8
2.1.5.3 Alarm Cache............................................................................................................ 2-9
2.1.6 User applications................................................................................................. 2-9
2.1.7 Commercial tools .............................................................................................. 2-10
2.2 SYSTEM ARCHITECTURE .......................................................................................... 2-10
2.2.1 Interface with the operating system ................................................................... 2-12
2.3 INTERCONNECTION WITH OTHER TELECONTROL CENTERS ......................................... 2-13
2.4 INTERCONNECTION WITH OTHER APPLICATIONS PACKAGES ....................................... 2-14

3. SCADA SHERPA/PC FUNCTIONS............................................................................. 3-1

3.1 MAN-MACHINE INTERFACE ....................................................................................... 3-1
3.1.1 Windows............................................................................................................. 3-2
3.1.2 WorldMap........................................................................................................... 3-5
3.1.3 Synoptic.............................................................................................................. 3-7
3.1.4 Alarms .............................................................................................................. 3-10
3.1.5 Lists of Signals.................................................................................................. 3-12
3.1.6 Real Time graphics............................................................................................ 3-14
3.1.7 Signal configuration .......................................................................................... 3-15
3.2 ACQUISITION OF FIELD DATA ................................................................................... 3-16
3.2.1 Treatment of events/alarms................................................................................ 3-19
3.2.2 Groups of alarms............................................................................................... 3-21
3.3 CARRYING OUT TELECOMMANDS ............................................................................. 3-22
3.3.1 Tag’s................................................................................................................. 3-23
3.3.2 Checking command permission signal................................................................ 3-23
3.3.3 Overriding command permission........................................................................ 3-24
3.3.4 One or two step commands on devices .............................................................. 3-25
3.3.5 Raise / lower commands.................................................................................... 3-25
3.3.6 Sending setpoints. ............................................................................................. 3-25
3.3.7 Programming command sequences. ................................................................... 3-25
3.3.8 Activating/deactivating signals........................................................................... 3-26
3.3.9 Introducing manual values. ................................................................................ 3-26

Reservados todos los derechos. Información propiedad de ELIOP i

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.3.10 Disabling alarms .............................................................................................. 3-26

3.3.11 Supervising Telecommand execution. .............................................................. 3-27
3.4 HANDLING HISTORIC INFORMATION ........................................................................ 3-27
3.4.1 Storing Information........................................................................................... 3-28
3.4.2 Processing Historic Information. ....................................................................... 3-29
3.4.2.1 Displaying / Modifying Historic data.......................................................................3-29
3.4.2.2 Historic data graphs................................................................................................3-31
3.4.2.3 Historic data reports. ..............................................................................................3-33
3.5 COMMUNICATIONS.................................................................................................. 3-34
3.6 TASK PLANNER........................................................................................................ 3-37
3.7 USERS / PRIVILEGES / AREAS OF RESPONSIBILITY...................................................... 3-39
3.8 TOPOLOGICAL COLORING......................................................................................... 3-42
3.9 DATABASE MANAGEMENT ....................................................................................... 3-43
3.9.1 Configuration database...................................................................................... 3-45
3.9.2 Real Time database ........................................................................................... 3-47
3.9.3 Alarm database.................................................................................................. 3-47
3.9.4 Historic Database .............................................................................................. 3-48
3.10 INCREMENTAL MANAGEMENT................................................................................ 3-50
3.11 CUSTOMIZING THE APPLICATION............................................................................. 3-52
3.11.1 Configuration .................................................................................................. 3-52
3.11.2 Graphical screen editor .................................................................................... 3-53
3.11.3 Other characterizations of the Application........................................................ 3-55
3.12 DOCUMENTATION.................................................................................................. 3-56

Reservados todos los derechos. Información propiedad de ELIOP ii

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

1. Introduction
Industrial society has developed to become more global, dynamic and diversified, making day
to day information a strategic factor upon that company managers can decide quickly and
correctly.

In this context, ELIOP, S.A. has executed numerous projects on both national and
international level that deal with acquiring and managing information in the world of
Telemetry, Monitoring and Telecontrol Systems.

Different potential architectures with SCADA SHERPA/PC

For more than 20 years, ELIOP, a company with experience in both the development and
implementation of SCADA systems and Remote Telecontrol Stations, has provided Users with
their Systems:
l Real time information management tools for controlling and supervising the industrial
processes, which have proved to be effective in decision making.
l Guarantee of profitability and return-on-investment, specially by preserving most of the
initial investment for dealing with enlargements.

With the aim to provide solutions according to the "state of the art", and even contributing to
define it, ELIOP has devoted a large amount of its work potential to R & D activities,
increasing, enhancing and renewing its catalogue of products, stressing the SCADA
SHERPA/PC whose description in its version 1.0 are dedicated the following sections in ths
document.

Reservados todos los derechos. Información propiedad de ELIOP 1-1

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

ELIOP's concept of SHERPA/PC is fully aimed to fulfil market needs, based on the long
company “know-how” in the development and use of previous SCADA products (GESTEL,
WINDOWS and ARCOS) products, accepted by its end users as effective for managing and
controlling their operations. Furthermore, SHERPA/PC can now be considered as a SCADA
software that is highly competitive on a world level, because it has been developing according
to the latest trends for Open Systems with "real time" applications. A brief summary of its main
characteristics is as follows:
l Developed in ANSI C and C++ in accordance with the object orientation methodology.
l Client/Server Architecture.
l It can be implemented on UNIX operating systems and de facto standard systems, but it can
also be implemented on other operating systems (Windows NT, etc.), using different
machines supporting them.
l It contains a Real Time Relational Database, to which access can be gained through
information exchange protocols (API structured), for storing its real time data.
l It contains an ORACLE Relational Database for storing its historic data and alarms,
although it can also work with other Relational Databases Management Systems.
l It supports standard communications for LAN and WAN (Ethernet under TCP/IP), as well
as many synchronous and asynchronous communication protocols with the Remote
Telecontrol Stations.
l SHERPA/PC is built with a modular concept, which enables the user to choose the
optimum configuration based on a nucleus to which a number of optional modules can be
added, increasing or supplementing the features of the basic system. Modules that can be
included both in the project phase and when the System is being operated.
l It can be distributed in different functional units (e.g. RTU scanning, Man-Machine
Interface, Databases, etc.) or in several machines, regardless of where they are located.
l SHERPA/PC can be built with redundant configurations, both on an information level, and
on an equipment or functions level. Active standby ("hot stand-by”) redundancy is offered
for the SCADA servers and communications.
l It includes security procedures for gaining access to the data and functions that guarantee
the security and integrity of the data belonging to the System.

The SCADA SHERPA/PC is the evolution of SHERPA (UNIX) product to the personal
computer world, mantaning the fiability and benefits that its “big brother” has been apported
to the Telecontrol World

The SCADA SHERPA/PC has been designed as a high performance nucleus providing generic
Monitoring and Control systems, with the ability to include other more specific functions,
associated with the applications of each industrial sector, customer, etc.

Thus SHERPA/PC is conceived to provide open connectivity to application environments such

as the DMS (Distribution Management System), the EMS (Energy Management System), the

Reservados todos los derechos. Información propiedad de ELIOP 1-2

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

CTC (Centralized Traffic Control), Leak Detectors, Training Simulators, Centralized

Measurements Offices, Simulators, etc.

SHERPA/PC had been designed under international standards like : IEC, ISO, ANSI, IEEE
and others.

SHERPA/PC is now a rich reality that has come to be part of the solutions for all the
aforementioned environments, as a high responsibility piece with respect to interaction with the
field, information management, presentation of results and management of the most demanding
real time flows the industrial applications.

SHERPA/PC is an Advanced Real time System that enables users to incorporate hundreds of
thousands of data elements coming come from thousands of RTU centers, using tens of
communication lines of different technologies (Cable, Optical Fiber, Switched Telephony,
Mobile Telephony (GSM), Radio, Trunking, Satellite, Network, etc.) and that have been
designed in accordance with the very latest quality software techniques.

A description of SHERPA/PC is offered in this document in two steps. The aim of the
description contained in Chapter 2 is to gain an initial understanding of the SHERPA/PC main
characteristics. Chapter 3. describes in more detail the main functions provided by
SHERPA/PC in its current version V1.0.

Reservados todos los derechos. Información propiedad de ELIOP 1-3

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

2. Main characteristics of the SCADA SHERPA/PC

SHERPA/PC is a very extensive set of programs whose clear and schematized presentation is
complex and demanding.

A set of basic characteristics have been chosen in this chapter, which will help the user to get
an initial understanding of the scope of SHERPA/PC, without trying to explain certain details
that will be dealt with in other sections of this Document.

SCADA SHERPA/PC: Standards for an open system

The outstanding features offered by SHERPA/PC are as follows:

l Open system concept
u System architecture, multi-platform.
u Hardware and software distribution
u Man-Machine Interface
u Interconnection with other centers
u Interconnection with other application packages
l Acquisition of field data
u Execution of Telecommands
u Storing and managing information
u Processing alarms and grouping them together

Reservados todos los derechos. Información propiedad de ELIOP 2-1

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Customization of the application

u Configuration
u Event processing options.
u Graphical screen editor.
l System users. Areas of Responsibility
l Supplementary applications. Topological coloring
l Task Planner

Details about each one of these are given in the different sections of this document.

2.1 Open system

SCADA SHERPA/PC has been designed and developed as an open system that complies with
the definition given by the IEEE, and therefore it is capable of the following:
l Functioning in a wide range of operating systems with a minimum amount of changes.

l Interacting with other applications in local and remote systems.

l Interacting with the users in a way that it allows its portability.

A breakdown is given below of the different levels on which the openness of the SCADA
SHERPA/PC is demonstrated.

2.1.1 Hardware
SHERPA/PC is operational on a PC Intel with S.O Windows 2000,also existing versions on
platforms: Alpha by COMPAQ (DIGITAL), 9000 by Hewlett-Packard, etc. so when a decision
is taken about which platform to use, economic and performance considerations must be given
priority without sacrificing functionality.

2.1.2 Operating system

SHERPA/PC uses the POSIX definitions as an interface with the Operating System, together
with an intermediate “isolating” layer between the services of any Operating System and
SHERPA/PC software. This allows all SHERPA/PC functions to operate in a wide variety of
modern Operating Systems such as Digital UNIX (Tru64), HP/UX, Windows 2000
(SHERPA/PC), etc.

Reservados todos los derechos. Información propiedad de ELIOP 2-2

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

2.1.3 Communications
A SHERPA/PC control center is capable of communicating and interacting with other systems,
such as remote stations, other Telecontrol systems or specific applications.

Communication with other monitoring / control center systems includes other SCADAs by
ELIOP and from other manufacturers, in different contexts that range from the same
hierarchical level to different levels within a Control Center Network. A variety of protocols
are used to implement this range of possibilities, such as TASE.2, CCR, specific protocols
based on TCP/IP, use of RPCs, etc. Similar methods have been used to communicate with
other applications, such as EMS, DMS, load prediction modules, etc.

The need to communicate with Remote Telecontrol Stations from a variety of manufacturers,
means that it has to be possible to easily incorporate a variety of communications protocols
such as GESTEL, IEC-870-5-101, IEC-870-5-104, as well as proprietary protocols by other
manufacturers into the SHERPA/PC communications architecture (like MODBUS, RP570,...).

Several qualitative and quantitative factors are involved in obtaining information from the
remote equipment.

1. SHERPA/PC is capable of integrating more than one communication protocol, so several

protocols can coexist in one single system integrating RTUs from different manufacturers
and technologies.

2. A great variety of types of information can be obtained, and this basically depends on the
type of the scanned RTUs; digital values, analog values in different formats and accuracy
levels, meter values, sequence of events information (SOE), historic information, etc.

3. There is no practical restriction on the number of communication lines that can be

configured to be managed by SHERPA/PC. The maximum number of RTUs that are
configured per line depends on the protocol used and not on any restriction imposed by
SHERPA/PC

4. The SHERPA/PC communication paths with the RTUs can be duplicated to guarantee
connection with these paths in the event of a failure affecting one of the communications
channels. One specific case consists of implementing a configuration of redundant lines in
ring-form, which enables the user to communicate with the RTUs from either end in the
event of a failure in the path of communications through any intermediate point along it.

Reservados todos los derechos. Información propiedad de ELIOP 2-3

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

Monitoring the communications status in a system controlled by SCADA

SHERPA/PC

2.1.4 Man-Machine Interface

The Man-Machine Interface (MMI) by SHERPA/PC has been designed to obtain an easy-to-
use user environment, that can be utilized on a wide range of platforms, guaranteeing suitable
response times and incorporating graphical representations from a variety of sources and
formats.

Graphical representation in SHERPA/PC is in accordance with the WIN-32 standards, with the
operation of multiple windows on one single display. The MMI has been developed on the
ILOG-VIEWS library and C++, and is object orientated.

The way that the MMI is displayed and presented is defined in the configuration database, so it
is extremely flexible.

Regarding graphical capabilities of SHERPA/PC, it must be pointed out that it supports the
following:
l real time graphical representation (trending) and historic representation; X-Y graphs
l dynamic objects with many possible representations (color fading, scaling on the basis of
values, bitmap sequence, color changes, etc.)
l Integration of virtually any graphical object into a synoptic; files with a variety of formats:
bmp, gif, dxf, etc.
l Presentation of lists of signals and lists of alarms, with color codes to identify their type and
situation
l User buttons

Reservados todos los derechos. Información propiedad de ELIOP 2-4

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Dynamic graphical objects associated with the entities defined in the real time database
l Dynamic Link: objects that enable the user to browse through the different synoptic screens
in the System without it being necessary to resort to an external menu; they usually have
button-type representations or similar.
l Synoptic and Worldmap representations, with Zoom, scroll, panning and decluttering
functions.

These dynamic links also allow for signaling certain situations such as the alarm status of a
specific signal. For example, a user can obtain a general map of the monitored System with
links to other more detailed zone maps. If a certain event occurs in any of the entities
represented in a detail synoptic, the corresponding graphic link in the general map change its
color, as a way to advise the operator that a significant event has occurred in the associated
zone.

It should be pointed out in this section that SHERPA/PC is extremely versatile for defining and
handling the graphical representation of the stored data and has a facility that enables it to
associate graphical processes for different events in the system, and these include the changes
of status and values for the different entities under control.

Another important characteristic is that any operation defined for a specific entity controlled by
the System can be executed from any point of the screen where it is graphically represented.
For example, a command can be sent to a switch from any synoptic that contains it or from any
list of signals that features it.

Some of the basic operations that can be executed through the MMI are as follows:
l Sending commands to devices

l Including / removing Tag’s

l Sending commands on analog output points

l Activating / deactivating remote stations

l Loading the configuration of remote stations when the communications protocol permits
this.
l Entering manual values for any type of signal

l Entering / displaying / deleting notes written by the operator

l Defining and requesting reports and lists
l Defining and requesting real time graphs (tendencies) and historic graphs

Most of these operations can be performed in a variety of ways:

l Via a menu associated with the object, which is activated and operated with the mouse

l Via the general menu in the respective window

l Via a certain combination of keys

Reservados todos los derechos. Información propiedad de ELIOP 2-5

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Via a quick-access button if the window is provided with it

It must also be pointed out that the link between objects and the Real Time Database is
established by name, and not by the internal number.

The final result is a powerful graphical interface that is easy to use, with the added value of
looking very similar in all the display platforms in the System. The configuration facilities that
are available are added to this.

2.1.5 Storing the information

All the information whose updating is not subjected to stringent time restrictions
(configuration, historic and sequence of events) is stored and processed with a commercial
Relational Database Management System (RDBMS).

Therefore, access can be gained to this information from many tools on the market, such as
spreadsheets, other databases, editors, tools for presenting information, etc.

Furthermore, this access can be gained from different platforms being supported by
SHERPA/PC; a PC located in an office can gain access through the company network to the
computer that contains the SHERPA/PC Databases and extract the information with
commercial programs.

SHERPA/PC uses two main methods for storing and managing the information, which are
consistent with the way that the information is structured and handled: Relational Database
(RDBMS) and Files mapped in memory (used for real time information).

Reservados todos los derechos. Información propiedad de ELIOP 2-6

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

The main SHERPA/PC Databases are as follows:

l Configuration Database, contains all the information about the telecontrol, communications,
Central Workstation and information that specifies how SHERPA/PC behaves in each
application; it is supported on the RDBMS system.
l Real Time Database, stores all the information that is arriving from the field through the
remote stations and other equipment; it makes this information available to all the
SHERPA/PC functions; it is supported on files mapped in memory.
l Alarm Database, contains information concerning events, detected by SHERPA/PC, which
have been configured as “Alarms” and are presented like that to the Operators; two
structures are distinguished: “Cache” of Alarms, for quick access, which is displayed by the
Operator and is supported on files mapped in memory and “Sequence” of Alarms, in which
the entire History of Alarms detected by the system is stored; the latter one is supported on
the RDBMS system.
l Historic Database (HDB), stores information concerning digital signals, analog signals and
meters for a variety of periods that are pre-established (15 minutes, hour, day...); the
information is drawn up on the basis of the real time data that reaches the system. All this
information is supported on the RDBMS system.

2.1.5.1 RDBMS system (Configuration and HDB)

The Configuration and Historic data is stored in the ORACLE Relational Database, taking
advantage of its great storage capacity and administration facilities. It is also equipped with a
powerful SQL interface that allows for customer application access. It also provides with
several useful programs such as report generators, screen generators, graph generators, etc.,
that allows easy access to information.

Therefore, SHERPA/PC uses this Database to manage the entire configuration for the System
and to store and manage the historic and sequential information for events, given that this
information is very extensive and complex, but does not change quickly in time.

The way that the Configuration Database is organized on ORACLE, enables SHERPA/PC to
link up easily with other the Inventory Databases, etc. belonging to the end user, thereby often
making it unnecessary to execute costly procedures for the initial filling of the Telecontrol
System Database.

The Historic Database (HDB), stores historic information about the different telecontrol points
(digital, analog and meters) that have been selected, keeping different information for each one
of them and for different periods of time.

The HDB can be exported to mass storage devices (tapes, optical disks...); when this data is
recovered it is possible to make queries and obtain reports containing data for a given period
of time.

Reservados todos los derechos. Información propiedad de ELIOP 2-7

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

The direct use of a Relational Database as the Historic Database of the system, makes it
possible to share the procedures and tools that are available to the users of the company
network, so that they can display data and generate reports from this Database.

Database in SCADA SHERPA/PC

2.1.5.2 Real Time database

The Real Time information is handled by a proprietary Relational Database, which is mapped
in memory and designed to support the huge amount of transactions that are received in the
system as a result of the changes that have been detected in the field.

Given the performance requirements of certain types of information that have many changes in
short periods of time, SHERPA/PC is provided with a Real Time Database whose main
characteristics are:
l Organized into Relational tables.

l It is equipped with an API programmed in C++ that provides easy and very swift access to
the information.
l Mapped in shared memory for simultaneous, but protected, access to the information.

Reservados todos los derechos. Información propiedad de ELIOP 2-8

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l This Database enables the operator to gain rapid access to the information, both for writing
and for querying, and is capable of processing hundreds of transactions in very few seconds.
That is why it is used by SHERPA/PC to house the Real Time Database that contain all the
information about the measurements obtained from the field and others calculated in real
time by the System. Because of the performance of the SHERPA/PC applications, the
configuration of the System that is administered from ORACLE, is also copied to this
Database.

2.1.5.3 Alarm Cache

The information about System events is also subjected to severe time restrictions, so
SHERPA/PC is equipped with a temporary cache that is capable of storing large avalanches of
them. This cache is also mapped in memory and SHERPA/PC provides an API to gain access
to that information via a Server Process.

The information about events is classified into two groups in the cache: alarms and sequential
events. The alarms are those events that inform the Operator about important occurrences that
have taken place in the System, and which are classified depending on their severity. The
Sequence of Events information is a historic chronology of all the events that have occurred
place in the System, including those that are in no way severe and are merely informative.
These two types of information are transferred to the Database in ORACLE so as to enable the
user to manage them from management tools.

It is important to stress that SHERPA/PC includes all the tools that are required and especially
designed for the typical work with different types of information, and it is not necessary,
although completely possible, to use the product opening options for exchanging or querying
that information using external applications.

2.1.6 User applications

The ORACLE Relational Database makes it possible to use embedded SQL language in a large
number of programming languages and, as it is a standard language, the program encoding task
is relatively easy for the end user, the only need is to know the structure of the stored
information.

Specific user applications, whether they are commercial or developed by the end user of the
system, can be easily incorporated into SHERPA/PC by means of two methods:
l The Man-machine interface is equipped with an “Applications” options, and the Operator
has access from any Workstation.
l Task Planner, enables the person in charge of the system to decide when and why (by time,
by event detection) a program written by the end user will be executed.

The introduction of a new application on either of these two options is an operation for which
those who are in charge of the SHERPA/PC Systems are facilitated through the documentation
and training provided.

Reservados todos los derechos. Información propiedad de ELIOP 2-9

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

2.1.7 Commercial tools

The philosophy of an open and modern SHERPA/PC system leads it to seek possibilities for
using the data stored by means of commercial tools that are easy to use and constantly being
improved.

Access to the information stored in ORACLE, by means of tools from other software
manufacturers takes place through ODBC drivers that can be provided with SHERPA/PC.

The combined use of a commercial Database (ORACLE) and commercial tools such as MS-
Office (Access, Excel), ORACLE Reports, ORACLE Graphics, CRYSTAL Reports, etc...
enable the end user not to need a large amount of training in tools belonging to the telecontrol
system and obtain the maximum performance and brightness in drawing up reports.

These commercial tools for drawing up reports are easy to use and are usually provided with
an intuitive graphical interface for defining them, and they are generally adapted by the end
user.

2.2 System architecture

The use of standards such as POSIX theoretically make it possible to safeguard the portability
of the SHERPA/PC code to different platforms, but they are often in contradiction with this
aim. That is why an intermediate software layer has been created between the SHERPA/PC
code and Operating System services upon which it is to be implemented. This layer acts
towards the SHERPA/PC software, providing it with one single interface for access to the
different Operating Systems, so the migration of code to other platforms does not mean that it
is necessary to develop the SHERPA/PC code again, all that has to be re-encoded is the
intermediate layer or “software bus” that provides the path that gives access to the different
services of the different Operating Systems.

SHERPA SHERPA
GRAPHIC SHERPA SHERPA GRAPHIC
MMI DATABASE COMMUNICATIONS MMI

BUS SOFTWARE

OPERATING OPERATING
SYSTEM SYSTEM
SERVICES SERVICES

Machine 1 Machine 2

Software BUS by SCADA SHERPA/PC

The general architecture of SHERPA/PC, which is shown in the following figure, consists of
the subsystems with different degrees of complexity, as described below.

Reservados todos los derechos. Información propiedad de ELIOP 2-10

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Interface with the Operating System

l Databases Subsystem
l Man-Machine Interface Subsystem
l Communications Subsystem
l Distribution Subsystem
l Control Subsystem

Man-Machine
Interface Database Communications
subsystem subsystem subsystem

Distribution Control
subsystem subsystem
Remote units

Operating system interface

Operating system

General architecture for SHERPA/PC

Reservados todos los derechos. Información propiedad de ELIOP 2-11

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

2.2.1 Interface with the operating system

The main aim of the Access Module to the Operating System (MASO) by SHERPA/PC is to
make the product portable to different hardware and software platforms. It is structured as a
library that offers a variety of services to all SHERPA/PC processes requiring the Operating
System to perform a task. Therefore, to get the SHERPA/PC software supported on a variety
of platforms mostly consists in changing this library and recompiling the application. The
implementation of this library is subjected to a number of requirements to guarantee portability;
using ANSI C and C++ and by using POSIX 1 and POSIX 4 calls.

The MASO offers services that are used from the rest of the SHERPA/PC application, and that
can be also be used by specific user applications:
l Environment Management Services: These define the environmental conditions for
operation for the processes of the System, machine, application, logical names, etc.

Operating system interface

Digital HP Other
UNIX UNIX Windows NT Systems

Interface with the Operating System

l File Management Services: These allow to handle sequential and direct access files, the
attributes, directory management and the use of unique names for temporary and permanent
files.
l Process Management Services: These allow to create, control, synchronize processes and
synchronous an asynchronous messaging services between processes, support for multi-
threading processing for parallel works.
l Memory Management Services: These allow to use dynamic memory and shared memory
between processes.

Reservados todos los derechos. Información propiedad de ELIOP 2-12

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Time Management Services: These allow to handle the System clock, timers and warnings.
l Input/Output Management Services: Communications with TCP/IP sockets, serial and
parallel ports.
l Distribution Services: These allow for the processes to be connected to the MASO, as if it
were a software bus, and to establish communication between them regardless of the
machine from which they are executed.

In short, this interface serves to isolate the characteristics of each specific Operating System
from the rest of the subsystems. This subsystem is adapted to the platform on which the
application is installed.

2.3 Interconnection with other Telecontrol centers

The need for a telecontrol center to interact with another centers, which often belongs to
another company, is becoming increasingly necessary.

Interconnection with other control centers involves two basic needs: an exchange of
information in either direction, and the telecontrol over the RTUs managed by the other center.

Several mechanisms are offered to support the first need, which always involve modeling the
information to be exchanged with the Control center in the SHERPA/PC Databases, and
supporting the communications protocol that is required for that exchange.

For the second need, servers and clients are implemented between both systems that makes it
possible to act on the RTUs managed by the other control center by means of another protocol
and after filtering against a Permission Database.

These protocols are implemented by means of several methods that range from an exchange of
files to protocols oriented towards connection, using the TCP/IP network protocol as a
support.

SHERPA/PC currently supports two protocols for communication between Telecontrol

centers:
l CCR Protocol (Computer to Computer Remote)
l Standard ICCP (TASE2) protocol. This protocol is performed through using TASE.2
protocol servers (implemented under Windows-NT); it can execute the following
Operations within the TASE.2 SHERPA/PC:
u Deactivate communication with the other center.
u Transfer all kinds of information about analog signals (in engineering units), digital and
meter, regardless of whether they are acquired or calculated data.
u The changes in the digital signals are transmitted together with the information about the
status and the time at which the source system detected the change (the time indicated by
the RTU if the latter provided chronological information).
u Sending commands to the other center (with or without prior selection).
u Management of commands between both centers through permission signals or Areas of
Responsibility.

Reservados todos los derechos. Información propiedad de ELIOP 2-13

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

u Handling Tag’s from one center to the other.

u Different ways of providing the other center with the information:
n For a set time
n By detecting changes in the information or part of it
n By polling from the other center.
n Periodical Database Integrity checking.
u Data and message Exchange
u Account information.
u Configuring the TASE.2 Server from the SHERPA/PC configuration: (Bilateral Tables,
Data Set). They can be also modified directly in TASE.2 Servers.
u Blocks 1,2 and 5 are supported.

2.4 Interconnection with other applications packages

SHERPA/PC is the essential nucleus for being able to obtain the real time data that the most
developed management systems require to execute the specific functions for each case.

There are applications on the market that supplement and enrich the SCADA application,
tailored to the requirements of the sector concerned (electricity, water, gas,
communications...). For the electric sector, these application packages include the DMS, with
its connections to AM/FM, GIS, etc; EMS and its respective modules, such as State Estimator,
Demand Prediction, Contingency Analysis, etc.. In transport applications, Centralized Traffic
Control systems (CTC) and other specific applications. Applications for water, such as the
topology of the water network, quality analysis, hydraulic simulation, hammer blow, analysis of
pump efficiency (EPANET, TRANSAN). In the gas sector, applications for detecting leaks,
locating leaks, simulation, analysis of efficiency, analysis of overpressure and low pressure
(Simulations, LICENERGY). All these applications have to be based upon a high performance
SCADA like SHERPA/PC.

Because of its Open System concept, SHERPA/PC can use all the potential offered by the
Application packages to the needs of the Industrial sector to which it is aimed.

Reservados todos los derechos. Información propiedad de ELIOP 2-14

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

The architecture of SHERPA/PC is designed like a large software bus through which the
information passes and the different applications are connected to that bus, almost as if it were
a "plug and play” technology.

Possibilities for connecting to other applications

Reservados todos los derechos. Información propiedad de ELIOP 2-15

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3. SCADA SHERPA/PC functions

3.1 Man-Machine Interface

The MMI is structured into Operator Workstations, each one of which can be supported in
different machines (distributed) or one machine that is common to several of them. Every
Operator Workstation is handled with a keyboard and a mouse and controls from 1 to 4
monitors.

The Operator Workstation is equipped with a Database shared by the different processes that
are executed for that workstation and keeps state information as identification of user
connected, number of open windows, contents of those windows, etc.

The SCADA SHERPA/PC synoptic are clear and intuitive

A Manager process that controls the user that is connected is executed for each monitor
allocated to an Operator Workstation. It makes it possible to boot Application windows in any
of the monitors on request from the user and provides important information such as the
System time, the system to which the user is connected, name of the Operator and icons for
starting applications.

The rest of the MMI windows are opened and monitored by the Manager process and are
connected to the shared Database for exchanging information between them. For example, it is
possible to use the alarm list to request the Manager to open a certain drawing in the Synoptic,
to open a window for configuring a signal, etc.

Reservados todos los derechos. Información propiedad de ELIOP 3-1

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

The Graphical representation in SHERPA/PC is in accordance with the WIN-32, managing and
displaying multiple windows on the same screen. Furthermore, SHERPA/PC can control more
than one screen per Operator Workstation, so one single user can control a large number of
graphical windows on different screens, with one single keyboard and mouse.

3.1.1 Windows
The Man-Machine Interface is multi-window. Apart from the Manager window that gives
access to the rest of the windows, there is also a generic Hardcopy window that enables the
user to make copies of the contents of the screen in Postscript format.

The Man-Machine subsystem Interface consists of a set of windows that cover the functions
that are described below.

When a telecontrol point is selected for operation by an user it can not be selected by another
user.
l Management of the Information to the Real Time Database for the system (RTDB)
supporting the following functions:
u Displaying instantaneous numerical and graphical values through synoptic diagrams
representing to the installation that is being controlled.
u Handling Tags.
u Forcing instantaneous point values.
u Enabling/Disabling alarm generation on a signal.
u Activating/deactivating points and remote stations.
u Sending commands to the remote elements.

These functions are executed from the windows in SHERPA/PC that are referred to as:
WorldMap, Synoptic, Lists of signals.

There are also two auxiliary windows, associated with the aforementioned ones, namely: Real
Time Graphics (Trending) and Signal Configuration Window.
l Management of Information about Alarms in the Alarm Database for the system (ADB)
with respect to:
u Displaying alarm records organized in different pages, in order to improve navigation
though the system.
u Acknowledging/deleting alarms.
u Insertion of comments to the alarms.

This management is executed from windows referred to in SHERPA/PC as: Groups and
Alarm Lists.
l Management of the information stored in the Historic Database (HDB) with respect to the
following:
u Displaying historic values of the different signals in a numeric or graphical way.
u Modifying the historic values stored.
u Requesting reports

Reservados todos los derechos. Información propiedad de ELIOP 3-2

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

These functions are executed from windows referred to in SHERPA/PC as: Historic
Graphic, Displaying/Modifying Historic (tabular format) and Selecting Lists/Reports.
l Managing the communications networks within the control center itself, with the remote
stations and with other Centers:
u Displaying the communication status for all the remote station network elements.
u Displaying the communication status between the system computers or with their
peripherals.
u Activating/deactivating of RTU scanning.
u Release of peripherals for the different functions.

These actions are executed from the Synoptic window.

With a view to preventing a possible system overload caused by an indiscriminate opening of

windows, SHERPA/PC limits the number of windows that can be open for each Operator
Workstation.

Operating on the different windows is executed using the three mouse buttons, using the
keyboard mainly only for entering alphanumerical data.

Screen layout:

The screen has of two static parts (always present, at the top and the bottom of the screen, but
the bottom one can be removed) and one dynamic part (in the middle of the screen).

The top static part contains the name of the system, the name of the node on which the
operator is working, the name of the Operator connected together with the date and the time.
It is also equipped with a number of “icons” that make it possible for the Operator to connect
or disconnect, use the horn, open the different windows that handle the application, gain access
to on-line help and different informative messages to the Operator.

The bottom static part shows a predefined number (from 0 to “n”) for the most recent alarms
detected in the system; the number of alarms to present can be customized in the system
configuration.

The dynamic part in the middle of the screen shows the different windows requested by the
Operator. Several windows can be displayed simultaneously onto the computer screen, but
only one of them can be active, that is to say, the one that receives the mouse and keyboard
events generated by the user. The active window is distinguished from the rest because the
edge is dark brown, whereas the edge of the rest of the windows is light brown. Any window
can be activated by merely clicking with the mouse anywhere into it.

To open the application windows, the Operator first has to identify himself to the system using
a name and a password: on doing this he is assigned with privileges and Area of responsibility,
in such a way that:
l All the actions that the Operator intends to execute will be subjected to a check to find out
if he has the privilege required.

Reservados todos los derechos. Información propiedad de ELIOP 3-3

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l All the actions/operations that the Operator wishes to perform on the Database signals will
likewise be check to verify if they are all within his Area of Responsibility.
l All the actions executed by the Operator will be identified with the name of the Operator
who performed them.

The different windows can be subjected to the following operations: iconization, change of
position, remodeling, maximization, concealing, closing.

The windows are provided with a standard format in which the following zones are identified:
l Identification and control line
l Menu line.
l Presentation area.
l Message line (for error or information messages)

All windows are provided with access to on-line help; help pages in HTML format that make it
possible to access the desired information, including photographs; this help can be modified by
the user.

Reservados todos los derechos. Información propiedad de ELIOP 3-4

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.1.2 WorldMap
The WorldMap is a way of representing the telecontrolled network, that enables the user to
handle the following functions:
l Decluttering, associating levels of data presentation to the Zoom level at any moment.
l Panning, in all directions and in a specific zone, with the "camera" function, which enables
the user to locate the zone displayed within the overall representation.
l Possibility of activating/deactivating the camera.
l Levels of representation, handled independently from the Zoom.
l Discrete and continuous Zoom.
l Direct jumps to pre-selected zones.
l Enabling/disabling operation on the network elements, definable on a system level.

l Jumps to synoptic representations for a specific installation.

l Access from the synoptic pages, lists of alarms and lists of signals.

Synoptic provide a graphical image of the controlled system

Reservados todos los derechos. Información propiedad de ELIOP 3-5

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

The following Maintenance facilities are also provided:

l Use of “.DXF” files, as static structure representation.
l Link and representation of elements on the basis of real time data (dynamic elements).
l Updating “.DXF” files without the need to relocate the dynamic elements, and selective
updating of layers.

Example of DXF file imported to handle the WorldMap

Reservados todos los derechos. Información propiedad de ELIOP 3-6

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.1.3 Synoptic
Synoptic are windows that enables the user to show the information in a graphical form,
variable and configurable by using dynamic objects with many possible ways of representing
them (color changes, scaling according to values, bitmap sequence, changes to text, sequence
of figures, etc.). These objects are customized for each application.

The drawings presented through this window are drawn by a powerful Graphic Editor that
makes it possible to make representative diagrams easily; the static parts of the drawings, the
dynamic parts (associated with the real time data) and their behavior can be defined by the
user, as well as the handling of “.bmp” and “.gif” files.

In addition to updating the elements defined as dynamic in this window (by means of the
Graphical Editor), it is also possible to assign to those elements defined as static a color change
through applying the Topological Coloring function offered by SHERPA/PC.

Every part in a system can be supervised thanks to a functional diagram

Reservados todos los derechos. Información propiedad de ELIOP 3-7

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

The behavior of the dynamic elements on the screen can be associated with a large amount of
information contained in the RTDB:
l Value of an analog signal (shown numerically or in bar format)
l Status of a digital signal (open/closed)
l Tag and characteristics of a signal (active, inactive, deactivated alarms, forced manual)
l Pending alarm Acknowledge
l Communications status with RTUs and peripherals from the central Workstation)

Example: Image for a Gas Regulating Station

The Decluttering (levels of presentation), Scroll and Zoom functions can be used in the
Synoptic windows.

The actions that can be performed from this type of representation are those described above in
the sections “Management of the Information in the Real Time Database” and “Management of
the communications networks”, as well as the acknowledge of alarms affecting an element,
querying the technical file for that element (which could contain photos of the element and its
technical characteristics) and loading a new configuration file to the RTU.

Operation on elements can take place in two ways: selection from the window menu or
displaying the Operations available together with the selected element.

Reservados todos los derechos. Información propiedad de ELIOP 3-8

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

Access to a particular drawing can be gained by jumping from another drawing or by

specifying the name of the requested drawing.

Example: Synoptic representation of a water system

From this page it is also possible to force the display of the Alarm Page for the RTU being
shown.

The Operator can request the display of up to 4 graphical windows in real time (Trend Curves)
from the Synoptic window. It is possible to include up to 6 signals for display in each one of
these windows; the signals included in a graph can be chosen by the Operator at the same time,
or a preselection of previous signals can be used.

Reservados todos los derechos. Información propiedad de ELIOP 3-9

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

SHERPA/PC is capable of coping with up to 4 windows of synoptic at one single screen

simultaneously.

Example: Synoptic representation of a communications system

3.1.4 Alarms
SHERPA/PC is equipped with three supplementary windows for handling the alarms: one
window with the latest alarms, one summary of all the alarms in the system and a page of
alarms that displays the set of alarms selected by the Operator.

Grouping of Alarms and List of Alarms

Reservados todos los derechos. Información propiedad de ELIOP 3-10

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Window of latest alarms, whose main characteristics are:

u Is located at the bottom part of the screen, it cannot be moved and cannot be concealed,
the operator always has it before him.
u The number of alarms shown can be determined on the basis of the system requirements
from 0 to “n” alarms.
u Neither acknowledge nor deletion of alarms is possible from this window.
u When the user selects an alarm from this window, the diagram on which the alarmed
signal is shown appears immediately and automatically.
l Summary Presentation of Alarms (Grouping), whose main characteristics are:
u It is possible to group the alarms on different pages with different criteria: alarms that
come from one single remote station, communications alarms, all the alarms, logical
groupings of alarms (e.g. the same level of voltage, valves, switches, piping,...). These
groups of alarms can be simple or complex, including logical operations (AND, OR,
NOT) on the simple groups (e.g. alarms that belong to three remote stations, but which
do not belong to a particular voltage level).
u One single alarm can belong to several different groups.
u The use that is made of this tool, with respect to how the alarms are "grouped" is defined
in the customization of the system.
u A name is allocated to each Group of Alarms, which enables the user to identify it within
the system, and color management is executed in the Summary window, on the basis of
the severity of the alarms that form part of that group.
u If a particular group of alarms is selected with the mouse, all the alarms belonging to that
group immediately appear in the list of Alarms window. When several lists of Alarms are
being handled, the user can press the right-hand button to change the way any of them
are presented.

Lists of Alarms, whose main characteristics are:

l It is a window in which all the alarms in a particular group appear in a structured way
(according to the timetag assigned).
l The contents of the text for the alarm that appears is defined in the configuration of the
system, but the data that appear most frequently are: complete date/time (up to a
millisecond), cause of the alarm (coming from RTU, generated by SHERPA/PC), complete
identification of the element in alarm (according to each system), type of alarm detected
(change of status, exceeding of limits,...).
l A summary appears with the number of alarms at each level of severity on the page,
together with an indication of whether or not there are more alarms than those currently
being displayed. The window includes management of page/line forward/backwards for the
lists of alarms that appear and beginning/end of list.

Reservados todos los derechos. Información propiedad de ELIOP 3-11

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Several alarm management options can be configured in this window:

u Superimposing alarms: enables the user to determine for each system whether different
alarms on one single element are superimposed, in such a way that when they appear
individually only the last alarm is displayed for that element, or whether the user prefers
one different line for each event detected for an element.
u Colors of alarms: SHERPA/PC enables the user to determine the color of the alarm that
is shown for each element and for each type of event.
u Behavior when alarms are acknowledged or deleted: SHERPA/PC can configure
different types of behavior in the face of acknowledge/deletion of alarms in every system
that is installed:
n Acknowledge and deletion of alarms are executed in one single operation, that is to
say, acknowledge involves deletion.
n Acknowledge and deletion require different operations, acknowledge has to take
place before alarms can be deleted.
n The automatic deletion of an alarm that has been acknowledged beforehand when it is
detected that the element has returned to “normal”.
The actions that can be executed from this window are:
l Acknowledge and Deletion of alarms, in the following modes:
u one or several, selected beforehand
u all the alarms displayed at that moment
u all the existing alarms in the database (this function can be deactivated)
l Adding comments to the alarms.

l Forcing to appear in the synoptic window the image that contains the signal that has caused
the alarm.

SHERPA/PC is able to open up to 4 windows of lists of alarms at one single screen

simultaneously.

3.1.5 Lists of Signals.

SHERPA/PC is equipped with means for presenting the telecontrolled signals in a lists of
signals format, in which each signal takes up one line of text, and in which the status and the
value are shown in real time, using the colors for a line to provide certain information about it
(existence of Tags, alarm deactivated, manual entry, signal deactivated, signal not updated).

This window is designed mainly for RTU commissioning and troubleshooting, and includes a
point-to-point check with the Telecontrol Center.

This window is equipped with page/line forward/backward management for the lists of signals
shown, as well as jump to the beginning and end of the list.

All the Operations described above in the section “management of the Information in the Real
Time Database”, can be executed from this window, and the user can also acknowledge alarms
for an element and gain access to its Technical File.

Reservados todos los derechos. Información propiedad de ELIOP 3-12

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

Once a List of signals has appeared, the user can request filter the information in certain
circumstances:
l Signals with any of the existing Tag’s (total prohibition of command, partial prohibition of
command, comment).
l Signals with value entered manually.
l Signals in alarm.
l Signals with telemetry error.
l Signals with their alarms disabled.
l Signals calculated in the SCADA on the basis of other signals coming from the field or also
calculated.
l Static signals, their value is neither calculated nor updated from the field; it is only updated
by action from the operator.
l Analog signals configured to detect significant variations in their value.

The Operator can request the display of up to 4 graph windows in real time (Trend Curve)
from the Synoptic window. It is possible to include up to 6 signals for display in each one of
these windows; the signals included in a graph can be chosen by the Operator at the same time,
or a preselection of previous signals can be used.

SHERPA/PC is capable of coping with up to 4 windows of synoptic at one single screen

simultaneously.

Reservados todos los derechos. Información propiedad de ELIOP 3-13

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.1.6 Real Time graphics

SHERPA/PC is equipped with the possibility of showing the values for the signals in graphical
form, whether these are real time values (requested from the synoptic windows or Lists of
signals), or the accumulated historic values (requested from a specific Historic Graphs
window).

Trend curves

The types of image that are permitted by SHERPA/PC are :

l Trend Curves (Trending). An image of a set of signals is shown (up to 6 in each graph) with
the time
l X-Y Graphs. A signal is shown together with another signal, the time being the common
reference point. Images in the following formats can be obtained within this type of graph.:
u Single Point Curve: this shows one single point that changes in real time and indicates
the cut-off point for the last value for the signals shown in X and Y axes.
u Multi-point Curve or Cluster of Points: this shows all the points through which
development takes place, in real time and from the moment the curve is requested, the
cut-off point for the values of the signals shown in X and Y axes. The last point is
distinguished from the rest of the points that form the cluster.
u Unbroken Curve: this shows all the points on the multi-point curve, but joined together
with segments as they develop in time.

All the signals acquired or prepared by the system can be displayed in real time with graphs.

Reservados todos los derechos. Información propiedad de ELIOP 3-14

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

Up to 6 curves can be shown simultaneously on each display, each of them containing up to 6

signals.

The main characteristics of the SHERPA/PC graphs are:

l Configurability.
l Modification of ranges of presentation: automatic or through selection by the operator
l Sampling, modifying the sampling period for the signals.
l Colors shown for each signal, together with signal label.
l Proportionality for the sides of the display window.
l Displaying values for the signals at every instant in time, through mobile vertical axis.
l Tags, to distinguish manual, deactivated, error and alarm values.
l Zoom

3.1.7 Signal configuration

SHERPA/PC is equipped with a specific window for on-line display and/or modification of the
parameters that determine the identification and behavior of the database signals.

This window can be called from the Synoptic, Lists of signals and Lists of Alarms pages.

The information shown in this window has one part that is common to all the signals and
another specific part depending on the type of signal (digital, analog, meter).

From this window, the user can display not only the static configuration data (the static part of
the RTDB for the signal), but also the dynamic part of that signal.

Reservados todos los derechos. Información propiedad de ELIOP 3-15

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

On-line modifications can be made to certain configuration fields for the signal from this
window.

Configuration of signal

3.2 Acquisition of field data

All the data acquired from the field via a variety of communications protocols are dealt with in
the same way when they reach the SHERPA/PC "nucleus".

Different types of checks are executed depending on the type of data concerned (digital,
analog, meter), before the new value updates the RTDB.

When the changes are labeled with a timetag from the remote station, SHERPA/PC keeps this
timetags (Sequence of events, SOE).

When it is SHERPA/PC itself that detects a change not time-tagged by the RTU, a timetag is
entered from the SCADA. The different utilities used for dealing with the alarms, enable the
user to find out whether the timetag came from the RTU or from the SCADA.

The treatment that the different types of signals are subjected to before they are deposited in
the RTDB are:

For digital signals:

l Change of value with respect to the previous situation.
l Change of value with return to the previous value in a pre-configured period of time (a
typical case is reclose in electrical applications)

Reservados todos los derechos. Información propiedad de ELIOP 3-16

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Control of telemetry error indicated by the RTU.

l Passing through intermediate situations for double digital signals.
l Detection of close/open/closed sequences, (typical action for reclosing in electrical
applications)
l Monitoring of command progress.
l Control over number of changes for maintenance of a device.
l Control of the time elapsed in each one of the states (available as historic data)

For analog signals:

l Exceeding one of the alarm limits (two lower and two upper), including management of the
hysteresis value to prevent multiple generation of alarms.
l Exceeding Range of measurement. With management of hysteresis value to prevent
rebounds.
l Freezing its value associated with a change in an associated digital input.

l Detection of sudden variation, because a defined threshold has been exceeded.

l Calculating average, maximum, minimum values and statistical data (available as historic
data).
l Telemetry error, indicated by the RTU.

For Accumulator signals:

l Calculating the accumulated value for the previous period (available as historic data)

l Meters of “Rollover” and “Read and Reset” type

All the checks to which the telecontrol points are subjected are considered to be events by
SHERPA/PC; and some of these can be configured as alarms if needed by a specific
application.

Calculated signal:

Calculated signals in SHERPA/PC can be derived from the values of the signals acquired from
the field. These Calculated signals are processed in a similar way as those acquired directly
from the field.

The value of these signals depends on the value of one or more signals (physical, manually or
calculated) from the Database, as well as parameters and constants.

The evaluation of the calculated expression inherits the qualifiers of manual input and telemetry
error from the signals that form part of the calculation. The qualifiers are treated in such a way
that the result assigned to the qualifier is the equivalent to the maximum degradation in the
signals that are involved in the calculation. For inheriting those qualifiers, a distinction is made
between two types of calculations:

Reservados todos los derechos. Información propiedad de ELIOP 3-17

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

Mathematical: operations with mathematical Operators, the result is always analog. The
operation is always performed regardless of the possible instructions such as “telemetry error”
or “manual” for the signals included in the calculation, and the qualifier is subsequently
propagated.

Logical: operations with logical Operators (OR, AND,XOR,NOT,...).In this case the result
depends on the operator as well as the value of the Operands, for example:
l If one of the parts of a logical calculation (OR) is in "telemetry error", if the other part is
ZERO, the result has a “telemetry error”.
l If one of the parts of a logical calculation (OR) is in "manual", and its value is ONE, if the
other part is ONE, the result does not have a “manual ” indication.
l If one of the parts of a logical calculation (AND) is in "telemetry error" and the other part is
ONE, the result has a “telemetry error”.

Even in a case where the calculation includes signals in “Telemetry error”, the calculation will
be made, and the qualifiers will be applied at the end using the methods described above.

It is possible to define calculated signals for status signals conditioned to analog values and
vice-versa.

The main operators handled by SHERPA/PC are:

l Logical: OR, AND, XOR, NOT.

l Conditional: IF Then Else.

l Relationships: Less than, More than, Less or equal, More or equal, equal, not equal

l Algebraic: Add, subtract, multiplication, division, potentiation, percentage, square root,

integral, logarithm, exponentiation, absolute value.
l Trigonometric: sine, cosine, tangent, arc sine, arc cosine, arc tangent, hyperbolic sine,
hyperbolic cosine, hyperbolic tangent.
l Statistical: maximum value, medium value, minimum value.

l Constants: TRUE, FALSE, PI; Other constants defined numerically

l There is also another expressions that provides information about the communications
status (main path, secondary path), operational status of the computers (Primary,
Secondary, Trials, Stopped), indication of alarm in groups (depending on degree of
severity)
l There are other operations that enable the user to take actions automatically:
u Sending a command depending on the result of an expression.
u Sending a command depending on the detection of a change in an expression.
u Automatically activating/deactivating the generation of alarms for a signal depending on
the value of an expression.

SHERPA/PC also offers the possibility of including complex equations defined by the user (or
specific ones for the application concerned) by means of a program written in a high level

Reservados todos los derechos. Información propiedad de ELIOP 3-18

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

programming language and included in the system in the same way as the rest of the
calculations.

3.2.1 Treatment of events/alarms

SHERPA/PC considers to be an event any action that the Operator takes on elements of the
system or telecontrol points and any change that SHERPA/PC automatically detects in field
data. The decision about what to do with the event concerned is totally customizable in the
system: from ignoring the event and not keeping any information about it, considering it to be
an alarm with a specific level of severity and with certain behavior, referring to the way of
accepting/deleting that particular alarm.

Once the event has been detected and classified as an alarm, as a result of its particular
configuration, SHERPA/PC process and store it as this particular type of information.

The list of SHERPA/PC alarms shows the user all the events that have taken place in
the system

SHERPA/PC offers a first “cache” in memory to store this information guaranteeing fast
access, enabling the user to obtain and show the alarms received from the field or those
generated in the system itself, and to do so very quickly. This information is immediately stored
on disk, making use of the most advanced characteristics of the Operating Systems regarding
the quick access to the hard disk, which guarantees that no information is lost about alarms
handled by the system.

An operator who has sufficient privileges can acknowledge and delete alarms. The response
time for these operations is very fast, unless the system is receiving large alarm bursts.

Reservados todos los derechos. Información propiedad de ELIOP 3-19

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

This information about the alarms and the operations executed on them is kept in deferred
form in the ORACLE commercial database. This procedure guarantees a rapid refreshing in the
normal operation of the system, and also opens up a wide range of possibilities for processing
the information about alarms using programs specifically intended for these tasks: reports, lists,
graphs, statistics, etc.

The alarm levels handled by the system, the capabilities for graphical treatment associated with
the filtering options on the lists of alarms, the way that the icons appear for different groups of
alarms, are all completely configurable. This makes this subsystem a powerful tool for
analyzing the actual status of the equipment under control.

Another major characteristic is related to the configurability of the Alarm Database. The user
can define the following parameters without needing to modify the code:
l Whether or not a signal generates alarms
l Alarm limits (lower and upper range limits, together with two lower and two upper alarm
limits)
l Behavior of the alarms: automatic deletion (or not) on acknowledge, event generation (or
not) every time that an alarm is deleted, etc.
l Correlation of alarms: this makes it possible, for example, that if a level 2 alarm arrives
when a previous level 1 alarm exists on the same object, the previous one can be deleted
(from the cache of alarms, not from ORACLE).
l Format for presenting the alarms: fields to be shown in the alarm window, sorting, size, etc.

l Color code for identifying the alarms for the different levels or different types of signals.

l Line of presentation with variable fields depending on the type of signal.

Sequence of Events (SOE) are considered like an system detected event and stored in
ORACLE database.

Reservados todos los derechos. Información propiedad de ELIOP 3-20

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.2.2 Groups of alarms

SHERPA/PC enables the user to configure different levels of alarms, up to four, and different
behavior patterns related to any of the different entities supported: signals, remote stations,
operators, printers, displays, computers, etc.

The level of granularity for defining the different behavior patterns of the alarms is that of the
individual elements, although it is normal to group together a number of common elements into
one single behavior pattern.

The different behavior patterns that can be defined for an object are:

1. If an alarm has to be presented in the alarm window or whether it is only a event for the
sequence of events file.

2. The alarm level (4 levels) that establishes different colors for each one of them, which
affect the Groups.

3. If this alarm has to be associated with any other on the same object.

4. The type of deletion that can be executed.

5. If an acoustic warning has to be generated.

6. If a new sequential event has to be generated for each operation that is executed on the
alarm.

The Group page offers an overview of the alarms in the system

Apart from the great flexibility that is offered in the configuration of the behavior patterns for
the alarms, SHERPA/PC also offers very advanced functions for grouping them.

It displays icons that symbolize a specific group of alarms. These groups can be defined on the
basis of:

1. Type of object associated with the alarm.

2. Type of alarm that has been generated.

3. For alarms associated to signals, they can be grouped using one or several criteria, such as
the class of signal, the area, the zone or the RTU to which they belong.

Reservados todos los derechos. Información propiedad de ELIOP 3-21

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

4. Without any specific criteria, just numbering the signals to be grouped together in an icon.

These icons are linked to the alarm windows, in such a way that, after an alarm situation is
signaled for an icon, the operator can display those alarms by clicking on it with the mouse.

These windows refresh the information when new alarms are received. The operator can
browse upwards or downwards in the window, and can execute acknowledge and deletion on
one, several, or sets of alarms that are displayed.

3.3 Carrying out telecommands

SHERPA/PC enables users to act on remote signals, both of analog and digital type. It also
offers a great variety of options that can be configured in order to choose the type of
verification to be made when a command is executed:

The synoptic allow easy operation on every element in the system

1. Check if the operator is authorized to send the requested telecommand.

2. Analysis of whether or not a telecommand can be made on the basis of reasons that can be
configured in the System and which depend on the status of other signals in real time.

3. Verifying the arrival of the command at the remote station by analyzing the
communications status or the acceptance of the command by the RTU.

4. Timed checking of the actual activity on the output element by means of an analysis of
input signals associated with the output.

Reservados todos los derechos. Información propiedad de ELIOP 3-22

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

The consequence of carrying out a command, whether it is positive or negative, turns it into a
warning to the operator and the generation of alarms or events that, as has already been
explained, are configurable.

When an element is selected by an user it can not be selected by another user.

The SHERPA/PC subsystem in charge of managing Telecommands enables the user to execute
the following functions:
l Attach/remove Tag’s
l Check the command permission signal
l Commands on devices in one or two steps
l Raise/Lower commands
l Send setpoints
l Programming command sequences

3.3.1 Tag’s
SHERPA/PC is equipped with four Tag’s or labels that affect the possibility of carrying out
Telecommands:
l The first TAG prohibits the issue of any type of Command on a Telecontrol Element. It is
normally known as “Unload” or “Prohibition”.
l The second one prohibits the generation of “Close” commands, enabling the “Open”
commands.
l The third one prohibits the generation of “Open” commands, enabling the “Close”
commands.
l The fourth one does not prohibit any operation on the element, but on entering a command
a “Comment” (previously created by any operator) in shown about the state or any other
circumstances of the device.

3.3.2 Checking command permission signal

For each command element SHERPA/PC is equipped with the possibility of
permitting/refusing the execution of a command depending on the status of a signal from a
Database for each command element. This signal can be telemetry or calculated, so in the latter
case, a logical expression is provided (AND, OR, NOT) to define the conditions affecting the
command.

The different sets of conditions are available as part of the checks that SHERPA/PC makes
before sending a command to the RTU:
l Unload tags
l Control of special situations (manual, communications failure, deactivated,...)

Reservados todos los derechos. Información propiedad de ELIOP 3-23

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Result of the permission signal, whose value can be a result of a complex calculation.

These three conditions can be configured, on a system level and independently, in such a way
that although the result of some of them is that the command cannot be executed, a user who
has “permission to override the command controls” may, in spite of everything, force the
sending of a command to the RTU. When this happens, the user receives detailed information
from the overridden command and SHERPA/PC records an event for the command sending
and including a reference to the command.

3.3.3 Overriding command permission.

There are times when as a result of the configuration of the permission for the command the
system prevents a command from being executed, but the operator is sure (because of the field
circumstances) that he can and must execute it. In these cases SHERPA/PC allows for the
possibility (configurable on a system level) of overriding the check made by the system.

Within the general configuration of the system, it can be indicated whether the system
concerned allows the operator to override the checks established for the commands and send
the command to the RTU, or whether it is not possible to do that under any circumstance.

With a view to being able to override the result of the checks, the operator must also be
provided with special permission to “override the command checks”.

On a system level, whether or not it is possible to perform overriding, the following command
checks is configured on an individual basis:

1. Tags for Unloading and Voltage Work (Not recommended, because of the special
circumstances involved in these operations).

2. Controls over special situations (manual, communications failure, deactivated,..)

3. Result of the permission signal, whose value can be the result of a complex calculation.

If the operator decides to execute a command with a negative permission check, an event is
generated by the system containing the command check that was overridden by the operator.

Reservados todos los derechos. Información propiedad de ELIOP 3-24

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.3.4 One or two step commands on devices

The SCADA SHERPA/PC is able to distinguish, by configuration and thus on an individual
basis, where the command on an element has to be executed in one step (IMMEDIATE
EXECUTION) or two steps (SELECTION plus EXECUTION).

If it is IMMEDIATE EXECUTION, through the protocol concerned, the execute command is

sent and then the progress of the command is supervised.

If the command is configured as SELECTION plus EXECUTION, a first "selection command"

is sent through the message provided by the protocol, and the RTU answers. If the reply is
consistent with the “selection command” an EXECUTION command is sent. If it is not
coherent, execution does not take place.

3.3.5 Raise / lower commands

The possibility of sending commands to raise/lower devices is included among the
SHERPA/PC command procedures; these commands can be supervised from SHERPA/PC
through an associated analog input.

This command can be used in Incremental form; it is not necessary to select device again .

If the command is not completed correctly, and event or alarm is generated, depending on the
configuration.

3.3.6 Sending setpoints.

SHERPA/PC has interfaces so that the operator can send Setpoint Commands to analog
outputs of the RTUs, and then providing a monitoring function based upon an analog input
associated to it that must reach a certain value within a dead band.

If the expected value is not obtained, SHERPA/PC generates an event, that can be considered
as an alarm, depending on the specific configuration of the system.

3.3.7 Programming command sequences.

SHERPA/PC is equipped with a programming language that enables the user to determine the
actions to be taken automatically when a piece of information arrives from the field. Sending
commands automatically to the RTUs is one of the actions included.

Once the sequence is programmed, it can be executed for the following reasons:
l Logical condition: any event is detected, concerning data that arrive from the field.
l By time: a data and time for execution can be programmed or this can be done periodically
(every day at the same time...)

Reservados todos los derechos. Información propiedad de ELIOP 3-25

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Upon operator request.

The programmable sequences can be Activated/Deactivated by the operator.

When the operator executes the sequences the following operating modes are possible:
l Execute step by step.
l Execute selected block of instructions.
l Execute from the current instruction to the end.

3.3.8 Activating/deactivating signals.

If the operator deactivates a signal, when data arrive from the field about that signal, the
information is not treated by SHERPA/PC. The data are tagged internally as “not updated”
(telemetry error)

The operator has the options of Activating/Deactivating logical groups of signals in one single
operation.

The Activation/Deactivation of signals generates an event.

3.3.9 Introducing manual values.

SHERPA/PC is equipped with the possibility of entering data Manually on digital and analog
signals.

When a signal contains an item of data entered manually, SHERPA/PC ignores the data that
reach that signal from the field. The data are tagged internally as having been entered manually
(manual entry).

The entry of manual values generates an event.

3.3.10 Disabling alarms

The operator can disable the generation of alarms in a signal.

When the generation of alarms is disabled for a signal, SHERPA/PC performs all the processes
associated with the data acquired from the field, and so its value is updated in real time in the
database, but the set of actions associated with the generation of alarms is not executed
(activation of horn, entry on list of alarms, blinks, etc...)

The disabling/activation of the generation of alarms generates an event.

Reservados todos los derechos. Información propiedad de ELIOP 3-26

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.3.11 Supervising Telecommand execution.

Verifying the correct or incorrect execution of the commands takes place through the
following:
l Acceptance/rejection of the telecommand by the RTU
l Timed checking of the actual action on the output element by analyzing the input signals
(digital or analog) associated with that output.

The command monitoring period can be configured on a signal level, thereby making it
possible to adapt it to the different conditions that might exist in the field (equipment whose
change of status takes place rapidly or slowly).

Whether the result of a Telecommand being executed is positive or negative, it is managed by

SHERPA/PC as an “event” that can be configured in the customization of the system as
“alarm”. It can be accompanied by such behavior as: an element blinking, activation of the
horn, entry on the lists of Alarms.

3.4 Handling Historic Information

The Historic Database is implemented on the ORACLE Relational Database, so it provides all the
capabilities of this powerful RDBMS.

The Historic Database enables the user to store the values that the different signals in the
system have had throughout time, not only those acquired in the field but also those calculated
locally, in several time periods (hourly, daily,...) as defined by the user.

Furthermore, in the case of measurement signals, the user can define a historic group of
variable accumulation. This Historic with variable accumulation can be used for studying the
significant variations in a measurements, for Percentage Analysis or for accumulated trend
storage, merely by suitably configuring the signal. This type of Storage is generally associated
with the detection of a specific event in the system.

In addition to the historic and statistical values associated with the signals, this Database also
stores the “events” detected by SHERPA/PC that have been configured as such.

All the software applied to the historic data supports days lasting for 23 and 25 hours, to take
into account seasonal time changes (daylight saving time).

SHERPA/PC provides a dynamic behavior for the historics, so that it is possible to start or
stop the historic treatment on-line from the signal configuration window.

SHERPA/PC makes it possible to periodically export the information from the Historic
Database automatically.

SHERPA/PC provides the storage of the Historic information from the administration menus,
in some mass storage media. It is also equipped with data recovery procedures.

Reservados todos los derechos. Información propiedad de ELIOP 3-27

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.4.1 Storing Information.

The information that SHERPA/PC is capable of storing if the signals have been configured to
do so, is as follows:
l Analog measurement signals within each accumulation period: The average value, the
maximum value, the time of the maximum, the minimum value and the time of the minimum,
Integrated value.
l Status signals within each accumulation period: The total number of maneuvers in the
working time of the device, the number of changes of state in the period, the time that the
signal is at rest, the time during which the signal has not been updated, the number of
spontaneous openings (moving from closed to open, without operator involvement), the
number of spontaneous openings that are sporadic or reclosings (in electrical terms)
(moving from closed/open/closed with amount of time open/closed < t time configurable on
a system level) and the number of changes forced manually.
l For meters: the accumulated value for the preceding period.

l A chronological file for the alarms that have gone off in the system.

The main characteristics of the information stored are as follows:

l The historic values are calculated and stored as data are received from the telecontrol
equipment. The statistics to be applied at each point can be several of the possible ones, and
it is possible to define more than one statistical treatment for the same object.
l Whether or not a point is stored in the Historic can be modified dynamically with a signal
parameter, which can be modified from the signal configuration page.
l The information that is kept in the Historic about a point includes whether or not there have
been samples of value “in manual” or “deactivate” together with the % of validity for the
stored information (number of valid samples out of the total number of samples).
l The initialization of the information concerning the maneuvers that have taken place in the
working time of a device can start at a specific value. When the number of maneuvers in the
life of a device is greater than a predetermined value, SHERPA/PC generates an alarm in
order to inform the user that the device requires maintenance.

When the remote stations and the protocols used for communication allow for it, SHERPA/PC
is capable of recovering historic data from the RTUs and including it in its own Historic
Database.

Reservados todos los derechos. Información propiedad de ELIOP 3-28

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.4.2 Processing Historic Information.

The historic information can be used in SHERPA/PC in several ways: generating graphs,
displaying in tabular format, preparing reports or lists of values. Furthermore, all Oracle’s
tools, such as SQL* Report and Developer 200, can be used to gain access to historic data.
ODBC drivers can likewise be used to make use of common usage tools such as Ms-Access
and Ms-Excel.

As it is mounted on Oracle’s structure, access to the data through SQL language is completely
guaranteed.

Access to the information from PC’s connected to the network (or the corporate network) is
immediate and simply through commercial applications (MS-office, Access, Excel) through
ODBC drivers, or native Oracle tools (Report, Graphics,..); all of this being controlled with
permissions for access to the Database.

3.4.2.1 Displaying / Modifying Historic data.

SHERPA/PC provides a display showing historics which enables the operator to select a
historic group (variable, by minutes, hourly, daily, monthly,...), and within this a set of signals
to display the historic information; these signals can be from one single RTU or several, and
either physical or calculated.

Window displaying modification to historics

The extent of the data to be shown is all that is available in the Historic Database.

The information appears in different colors depending on the basis of the following data:
measured value, manual value, sample with value deactivated, value being modified (when
access is being gained to it for modification).

Reservados todos los derechos. Información propiedad de ELIOP 3-29

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

The historic values for the signals are shown in the format that has been set for historic data in
the Configuration Database, and this format can be different for each one of them.

Each row shows a date/time and each column shows the historic data concerning the statistics
of a signal.

The pages that display historic data can be pre-configured so that it is unnecessary to execute
signal selection operations every time that the user opens these pages, so it will only be
necessary to specify the dates requested.

The information appears in tabular form and the window grows horizontally and vertically to
adapt to the size required to show all the information requested.

The last line or total line shows the summary of what happened during the selected period of
dates. This line is calculated on the basis of the statistic required using the following criteria:
l For measurements:
u maximum: maximum out of the maximums from the dates
selected
u time of maximum: time of the maximum out of the maximums from
the dates selected
u minimum: minimum out of the minimums from the dates
selected
u time of minimum: time of the minimum out of the minimums from
the dates selected
u average: average of the average values for the records for
the period
l for digital signals:
u changes: total numbers of changes of the records for the
period
u standby time: total standby times of the records for the period.
u number of maneuvers: value of the last record for the period requested
u number of spontaneous trips: total for the records for the period
u number of manual trips: total for the records for the period
l for meters:
u accumulated: total for the values of the records for the period.

There is also a tool for modifying the hourly historic information stored beforehand, as long as
authorization has been given to do so.

This operation se is performed in the same window as the one used for displaying historics.

With a view to ensuring that the information stored in the different periods configured is
coherent, the historics can be modified for the hourly records and the information is then
exported to the daily records.

This tool enables the user to do the following:

Reservados todos los derechos. Información propiedad de ELIOP 3-30

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Cancel the modifications made but not yet validated.

l Recalculate the line of totals on the basis of the data that have been entered.
l Validating and exporting the data to a greater period of time.

Modification of historics causes an event to be generated that indicates that this operation has
been executed; if it is thought to be necessary, this event is configured as an alarm.

3.4.2.2 Historic data graphs.

The values for all the signals defined for historic storage can be shown on historic data graphs.
The historic data can be stored as fixed, variable, changeable periods (out of a percentage of
variation); in all cases they can be displayed on the graphs.

The Historic Graphs show the values of the signals requested in graphical form for the selected
period of time.

Historic graphs

The graphic treatment for the data stored is not only when the data storage is periodical but
also when information is stored because there is a significant variation in the signal; in the latter
case the available data are extrapolated in order to show them in a graphical form.

An utility is used for comparing historic data from one single signal, in several (up to 6)
different periods of time (e.g. one day with another day, one week with another week, etc.).
This utility enables the user to set a date for the start of the first period to be considered and a
number of days to be displayed as from that date. It is possible to choose a further 5 starting
dates for this signal (the number of days to be displayed as from the starting date will always be

Reservados todos los derechos. Información propiedad de ELIOP 3-31

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

the same) and all the periods requested are shown on the same graph (trend curve) a color
being allocated for each one of the periods.

The historic data shown in graphs can be formatted in files in tabular form, and the samples
identified in “Telemetry Error” “T” and “in Forced Manual” “M”. These files can be sent to a
printer and/or displayed.

The main characteristics of the SHERPA/PC graphs are:

l Configurability.
l Modification of ranges of display: automatic or by selection from the operator
l Colors for each signal. With inscriptions that represent the signals.
l Proportionality of the sides of the display window.
l Displaying values for the signals at each instant in time, through mobile horizontal and
vertical axes.
l Tags, to distinguish the following values: manual, deactivated, erroneous, alarm.

l Zoom

l Predefined graphs: The configuration for the most extensively used graphs is stored in the
SHERPA/PC databases, thereby guaranteeing quick access to them, in the desired format.
Possibility of on-line inclusion of new predefined graphs.

Reservados todos los derechos. Información propiedad de ELIOP 3-32

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.4.2.3 Historic data reports.

When preparing reports with the data stored, SHERPA/PC uses the ORACLE Reports tool;
this tool can be used to configure both the content and the format of the report.

Window for selecting alarm reports

In view of the fact that the information to be used in lists and reports consists of historic
information and the alarm chronology, which is stored in a commercial ORACLE database, the
possibility of defining and obtaining printed results is virtually limitless.

All the reports that are generated can be stored on disk or printed out directly. In the first case,
SHERPA/PC offers a report viewer that enables the user to see the report from the operator
screen before giving the final command for them to be printed out and/or deleted.

The following are among the tools that SHERPA/PC is equipped with for analyzing Historic
Information:
l Chronological lists of alarms. A range of dates for the alarms, the type of alarm, the type of
alarm to be shown, the degree of severity and, in the case of lists of signal alarms, the RTUs
to which they belong, can be selected through a number of options in the report window.
l Predefined reports. These reports are configured beforehand using the ORACLE Reports
tool and SHERPA/PC offers the selection of the range of dates for the historic information
that is used to generate them.
l Automatic reports. The content of the reports is defined using the ORACLE Reports tool,
but the period for which they are automatically printed by SHERPA/PC has to be defined in
the SHERPA/PC Configuration Database.

In addition to these tools for managing reports that are inherent to SHERPA/PC, typical
“Office” tools can also be used, such as Ms-Access, Ms-Excel, as well as other commercial

Reservados todos los derechos. Información propiedad de ELIOP 3-33

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

tools such as Crystal Reports, and ORACLE tools; this set of tools, together with the use of
the “Scheduler” by Windows, enables the user to obtain the same features (predefined reports,
automatic reports,...) as with the tools inherent to SHERPA/PC, and it is also possible to use
the data stored in any type of document without the need to use specific tools.

3.5 Communications.
The connection between the RTUs, each one with its different protocols, and the SCADA
responsible for processing the data takes place through the communications subsystem.

Others API
IEC-870-5-101 IEC-870-5-104
ICCP/SNMP SCADA/SHERPA

Upper Network

COMMUNICATIONS SYSTEM

Lower Network

IEC-870-5-101 IEC-870-5-104 GESTEL OTHERS BRITISH GAS

Communications diagram

The SHERPA/PC communications subsystem can either be executed on the Scada Server or
distributed on a dedicated “Communications Concentrator”; the choice of one method or the
other is closely linked to the CPU loads envisaged associated to communications. These loads
are depending on the type of protocol to be used when communicating with the RTUs, the
number of communication lines required and the physical support for the communications
channel.

SHERPA/PC can manage different communications protocols, in such a way that each
protocol is used through one or more physical communication paths that are available to them.

A SHERPA/PC can communicate with one or more RTU's for each physical communication
path, as long as all the RTU's communicated through the same physical path use the same
protocol.

When the communications subsystem is used in distributed form, the protocols used to serve
the data to the SCADA are always standard, and the normal connection to the SCADA
SHERPA/PC is included among them through the appropriate API.

SHERPA/PC not only acquires real time data, it also synchronizes the RTUs, provided that
they accept synchronization by protocol. The accuracy of the synchronization of the RTU from

Reservados todos los derechos. Información propiedad de ELIOP 3-34

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

the SHERPA/PC is in the range of 100 milliseconds. The maximum desynchronization between
to RTU's is 200 milliseconds.

The communications subsystem is structured in the following levels:

Scanning Trhead Trhead Trhead

level xxxx xxxx xxxx

Applications
level Library Library Library

Link Link Link Link Link Link Link

level

Communications subsystem

Link level.

The Link level is defined in the Subsystem for every communication line that is defined in the
database, and its basic functions are as follows:
l Independent management for each one of the lines configured for the communication line.
l Management of each one of the physical ports that are defined for each line.
l Management of the physical communications medium (RTC, dedicated line, conventional
radio, radio Trunking, TCP/IP,...).
l Management of the physical communication signals (RTS, CTS, CD, ...), if it is possible,
depending on the type of connection device.
l Management of port redundancy.
l Generating the communication statistics for this level.
u Total number of retries executed.
u Maximum number of consecutive retries executed.
u Total number of messages not answered.
u Total number of messages received with protocol error (e.g. error in alternating bit, etc.)
u Total number of messages received with CRC error.
u Total number of messages received with character parity error.
u Total number of messages received with character timeout error.

Reservados todos los derechos. Información propiedad de ELIOP 3-35

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

u Total number of switching from the main channel to the alternative one.

Application level.

Its basic function is to construct the messages to a link level and to translate the replies
received into messages to the SCADA via the API defined for this purpose or the standard
protocols.

It is basically a hierarchy of objects in the form of a library that encodes not only the request
messages but also the answer messages from the implemented protocol, so it is software that
really interprets the messages according to the protocols.

It is responsible for “Standardizing” the information that comes from different protocols and
temporarily storing the information received from the RTU's in the local database.

At this level the Subsystem is equipped with an application that enables the user to trace the
messages exchanged with the RTUs. This tool enables the use to display the messages sent and
received in different formats (ASCII, hexadecimal, decimal, octal). The user of this tool can
filter the messages to be studied through criteria such as identifying the RTU, the
communication path or the type of message. The messages that are monitored can be stored on
disk for subsequent analysis.

Scanning level.

It manages each one of the scanning functions (scanning criteria) defined in the database for
each one of the RTUs.

The scanning functions that can be defined depending on the protocol are:
l Recovering from RTU restart or communications failures.

l Integrity scan of the Remote Station database.

l Hourly and seasonal synchronization.
l Global scanning (Poll).

l Commands to output points.

l Retrieve of historic data.
l Change of parameters.

l Broadcast.
l Meter data request.
l Spontaneous irruption.

l Urgent scanning.
l Service terminal.
l Configuration of remote station.

Reservados todos los derechos. Información propiedad de ELIOP 3-36

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

Some of these functions tag the type of messages to be used for each protocol.

The following attributes can be defined for each scanning function declared in the database:
l Type of timing: Continuous, Relative Timing, Absolute Timing.
l Boot cycle, Boot offset, Threshold of day change.
l Duration of the execution.
l Priority of execution over other functions

The Planner forms an essential part of the Scanning level. It is the engine for scanning the
remote stations network. It is responsible for activating the scanning functions, selecting them,
selecting the line through which the connection has to be established, managing the transitions
between the states of communication of the RTUs and lines, managing the priorities
established when executing the scanning functions, dealing with the commands sent by the
SCADA to the RTUs and sending to the SCADA the messages generated by executing the
functions.

This level of communications also depends on the final protocol used as regards activating the
scanning functions that are suitable for certain events or executing the commands received
from the SCADA.

3.6 Task planner

SHERPA/PC is equipped with a generic tool for planning a variety of types of tasks that must
be executed by the system automatically or manually for one of the following reasons:

a) Operator request: the task is executed only upon operator request.

b) Detecting an event: any of the changes of situation controlled as “events” by SHERPA/PC

can be a reason for starting a program or an application.

c) Programmed in time: can be programming both for a particular date or a periodical

programming

The main characteristics of the planner are:

l Allowing parameters to pass on to the applications, and allowing the applications to be
programmed in the same way.
l It can execute applications of the following types:
u Commercial applications
u Executable programs developed for a specific project or by the end user.
u Programs written in the AUTOMATISMS language by SHERPA/PC, see section on
programming sequences.
u UNIX scripts.
l All the actions programmed are stored in a Database, not only those associated with events
but also the timed ones.

Reservados todos los derechos. Información propiedad de ELIOP 3-37

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l This function is equipped with a simple interface, from the operator's Display the following
can be done:
u Displaying the existing programmed actions
u Modifying the programmed actions.
u Programming new actions
u activating/deactivating the planned actions
u checking the format for programming actions
u executing a programmed action even if it does not fulfill the planned conditions.

l If a run-time failure is detected associated to an application (for instance, program not

found, etc.), an event is generated indicating the problem and the associated programmed
action is automatically DEACTIVATED (so that the error event is only generated once)
l Any programmed action can be ACTIVATED/DEACTIVATED; when an action is
DEACTIVATED, it is not executed even if it fulfils the execution conditions.
l The ACTIVATION/DEACTIVATION of any programmed action generates an event that
indicates which of the programmed actions has been ACTIVATED/DEACTIVATED.
l The inclusion of new programmed actions does not mean that the system is unavailable.

l There are two possibilities when programming the Planner:

Programming by events.

A different program can be made for each event and object for which that event is detected;
e.g. SWITCH_52-1

EVENT OBJECT APPLICATION

EV_C_DIG_OPEN SWITCH_52-1 RECLOSE_TIME, 5sec
EV_C_DIG_OPEN SWITCH_52-2 CLOSE_SWITCH,
SWITCH_52-3
EV_EQ_ACTIVATED RTU_1 SHUTDOWN
EV_C_ANA_AL_SUP2 * MESSAGE TO OPERATOR
* COMPUTER_1 STOP_APPLICATION

In this case the meaning of *, is that all the signals for the BD must be applied when an event is
detected (case Num. 4) as well as applying to all the events that could occur to a specific
object (case Num. 5).

That is to say:
u The applications can be different for one single event and different object.
u The applications can be used for any event
u The applications can be used for any object
u It is possible to program one single application for all the objects and all the events

Programming in time.

Reservados todos los derechos. Información propiedad de ELIOP 3-38

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

This programming can be executed in absolute time, setting date and time of execution for the
Application concerned and periodically

Date/Time Application
15/10/99 16:00:00 APPLICATION_1, parameters
*/*/* 01:00:00 APPLICATION_2
*/*/99 *:05:00 APPLICATION_3, parameters
1/*/* 02:00:00 APPLICATION_4

In the previous example:

th
l APPLICATION_1 will be executed on 15 October 1999 at 16:00.
l APPLICATION_2 will be executed every day at 1:00.
l APPLICATION_3 will be executed at 5 minutes past every hour every day in 1999.
st
l APPLICATION_4 will be executed at 2:00 on the 1 of each month.

3.7 Users / Privileges / Areas of responsibility

In order to guarantee the security and integrity of SHERPA/PC data, all the accesses to certain
System tools or even points of information are gained by means of what are known as "access
profiles", which are configured on the basis of information to which access can be gained and
the type of access.

The access profiles must be defined for every System User, and this determines the information
that the user can display, the operations that can be performed in the System, the working tools
that are enabled and even which System hardware resources can be used.

Every user must enter DSS name and password key before being able to operate in
the system

The operations that SHERPA/PC has under control for each user on an individual basis are
shown below, making it possible to define users with the same permits (user profiles) both for
the remote and the distributed connections:
u Operations: activate, deactivate, manual and automatic.

Reservados todos los derechos. Información propiedad de ELIOP 3-39

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

u Commands (telecontrol commands, Tags)

u Acknowledge/Deletion of alarms.
u Request for/Cancellation of reports.
u Cancellation de reports.
u Modification of configuration.
u Administration tasks.
u Type of windows that can be requested: Synoptic, Worldmap, Alarm, List of signals,
Graph, Date/Time, Signal configuration.

A key word for each user is defined in the Database, together with a type of timing and a list of
privileges, which are those that enable the user to execute different operations in the different
MMI graph windows.

Three types of access can be managed:

l Permanent: the user is identified to the system and does not lose DSS privileges until he
deliberately disconnects
l Temporary: the user has access to the operations associated with DSS profile for a certain
period of time, after which the system automatically disconnects him; if the user wishes to
carry on operating with the system, he has to re-identify himself (entering DSS name and
the access word or password.)
l By activity: the user will be disconnected when a certain time has elapsed without having
indulged in any activities

These types of access enable to define operator management policies that guarantee the
maximum security for the system. The "temporary" access and by activity reduce the risk of an
unauthorized user carrying out operations taking advantage of the fact that another user has
forgotten to disconnect.

When the operation is not allowed, the system warns the operator of the fact; this warning is
issued through the message window at the bottom of the display.

There is an access control window through which the user must identify himself to the system,
giving DSS name and DSS key (password).

Apart from user management, SHERPA/PC is equipped with the possibility of defining Areas
of Responsibility for selective access to the information for controlled access to the system.

Whether or not Areas of Responsibility are used is a decision that must be taken when the
system is characterized.

The Areas of Responsibility are defined on a telecontrol point level, so in each case the
maximum flexibility is permitted on an individual basis.

The Areas of Responsibility limit the operator's actions to certain Database elements, in such a
way that an Operator can execute a certain operation (e.g. command) on an element that

Reservados todos los derechos. Información propiedad de ELIOP 3-40

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

belongs to DSS Area of Responsibility, but not on an element that does not belong to that
Area.

When an Operator tries to execute an Operation on an element that does not belong to DSS
Area of Responsibility, SHERPA/PC does not give him an opportunity to do so, because the
operations do not appear in selectable form on the menus.

When an Operator tries to perform an Operation for which he does not have permission, the
system enables him to take all the preliminary stems, but when he executes it, the system
informs him that he cannot do so because he lacks the privileges.

SHERPA/PC supports the definition of multiple Areas of Responsibility, without major

restrictions where the number is concerned; so there is a specific table in the Configuration
Database that specifies the names of the Areas of Responsibility.

There is several elements within the SHERPA/PC Database to which Areas de Responsibility
can be allocated; these elements are:
l Communication lines, belongs to one single Area of Responsibility.

l Remote stations, belongs to one single Area of Responsibility.

l Telecontrol points, belongs to one single Area of Responsibility.

l Groups of Alarms, belongs to one single Area of Responsibility.

l Operators; the operators can be allocated several Areas of Responsibility, in such a way that
it is possible to execute a definition of Areas in a granular way and the different Operators
can work with a set of these small Areas.

The allocation takes place through the name of the Area that appears in the Areas of
Responsibility Table; if any element of those is not allocated in the Database of a particular
Area of Responsibility, the system considers that that element is not controlled by that method,
thereby preventing a certain element from remaining out of control by error, because it has not
explicitly been allocated an Area.

Crossing of the Areas of Responsibility allocated to an Operator with the associated different
elements (communication lines, Remote stations, Telecontrol Points, Alarm Groups) give rise
to an Operator:
l The operator is either authorized or not authorized to execute Operations with the line of
Communications object; that is to say he either can or cannot activate/deactivate the
scanning of all the RTUs on the line, he either can or cannot allocate a line of
communications to a Computer in a Trial situation. The operator is not limited to presenting
data concerning communication lines.
l The operator is either authorized or not authorized to execute Operations with a Remote
object; that is to say he either can or cannot activate/deactivate the scanning of a Remote
Station, he can activate/deactivate the generation of alarms for a Remote Station. The
presentation of the RTU status is not limited.

Reservados todos los derechos. Información propiedad de ELIOP 3-41

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l The operator is either authorized or not authorized to execute operations such as

commands, tagging, forced manual, deactivation and deactivation of alarms at a telecontrol
point. The presentation of the information about the value and the status of the point is not
restricted. However, the operator will not be informed (horn) about the appearance of an
alarm at that telecontrol point.
l The operator is either authorized or not authorized to display, acknowledge and delete
alarms that belong to a Group of Alarms; the Operator is not informed about the existence
of that Group, so he cannot execute any operation upon it.

The system thus allows for a great variety of policies for making use of this function. The
policy to be implemented must be outlined in detail during the Phase at which the system is
being defined.

When an Operator selects an element, if that element does not belong to DSS Area of
Responsibility, the Operations that are subjected to control from Areas of Responsibility
appear disabled, so it is impossible to jump that control.

The software for the interface with the operator only shows the Areas of Responsibility to
which the operator is allocated, so it is impossible to gain access to any element that is not
included in those areas.

3.8 Topological coloring.

SHERPA/PC is equipped with the “Topological coloring” option, which enables the user to
color the elements that have been defined as static in the presentation displays according to
certain criteria.

There is a “Topological Information Generator” which creates the topological structure for the
network on the basis of the drawings created by the SHERPA/PC Graphical Editor, so it is not
necessary to insert the connectivity between nodes, because this is deduced from the drawings.

The Topological Information Generator detects those elements in the drawing that are not
connected topologically to the Network (due to errors or inaccuracies in the drawing)
generating an error file for each drawing that can be updated graphically with the Graphical
Editor, so the errors detected can be updated and corrected.

The Topological coloring is a generic tool (regardless of the sector: electricity, water, gas,...),
but it allows for the configuration of certain facilities inherent to a specific sector. With a view
to this it manages generic elements such as:
l Source nodes
l Drain nodes
l All/nothing cut-off elements
l One-directional and two-directional connection elements.

l Regulating elements

Reservados todos los derechos. Información propiedad de ELIOP 3-42

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Deliverable elements
l FRONTIER nodes
l INFORMATION node

When a new drawing appears because the network has been enlarged, the “Topological
Information Generator” recalculates the topological structure upon Operator request but only
in the affected zone.

At present the situations that detect the application of “Topological coloring” are:
l Detecting flow through the elements (equivalent to being energized, water flowing, gas,...)
l Detecting the “islands”: zones on the Network that only have one "source" element.
l Grounding of the elements. (for electrical applications)
l Simulation mode, in this case the Topological Processor does not work with the data that
change from the RTDB, but with a copy of it and the changes that the operator gives
notification about.

The color that is used in the “coloring” of the elements in each one of the previous situations
can be configured at an application level.

3.9 Database management

SHERPA/PC uses two types of support for storing information: RDBMS (ORACLE)
databases and files mapped in memory.

ORACLE is a commercial relational database management system that is extensively used. Any
duly authorized user can gain access to ORACLE through the SQL query language and
through any of the products supplied by ORACLE: Sql*Forms, Sql*Report, PL/SQL, Pro*C,
etc. SHERPA/PC also provides specialist tools for editing databases, generating reports, etc.

It must be stressed that SHERPA/PC includes all the tools required for typical work that is
undertaken for the different types of information, so it is not necessary, but completely
possible, to use the opening options of the product for exchanging information or to query this
information using external applications. These tools have been especially designed by ELIOP
for this particular purpose, so there is a high degree of optimization in time and space.

The advantages of ORACLE are counteracted by the time it takes to gain access, which is not
suitable for some of the tasks that require a real time response. In such situations SHERPA/PC
uses a second support: the files "mapped" in memory. The databases that use support are also
relational, but their internal structure belongs to ELIOP. A programming interface (API) has
been developed that enables the user to develop programs that use them without knowing how
they are implemented. The use of this API provides much faster access than ORACLE queries.

The main aims for which these databases and their processes have been designed are as
follows:

Reservados todos los derechos. Información propiedad de ELIOP 3-43

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l Guaranteeing portability
l Guaranteeing a suitable response time
l Making it possible for both the data and functions to increase in amount
l Providing the users with access
l Guaranteeing the confidentiality of the data through access control procedures.

RDBMS
(ORACLE) Configuration Chronological
Historical Aditional
Database Alarm
Database (HDB) Database
BDCONF Database (BDC)

Alarm Historical Data retrieving

Configuration
Process Processing data Process from
Processing BDC and HDB

Static Dynamic
Memory RTDB RTDB
mapped
files Alarms Cache
Real Time Data Database
Base (RTDB) (ADB)

Alarms
Nucleus
Server
Proccess
Process

General structure of the Databases

Reservados todos los derechos. Información propiedad de ELIOP 3-44

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

The SHERPA/PC databases can be grouped according to their function in the following way:
l Databases that Describe the System. These include the Configuration Database (BDCONF)
and the Real Time Database (RTDB). The former is supported by ORACLE and the latter
on files mapped in memory, one part being static and the other dynamic.
l Alarm Database. This includes the Chronological Database for Alarms (BDC) and the
Cache Database for Alarms (ADB). The former is supported by ORACLE and the latter on
files mapped in the memory.
l Historic Database (HDB): this is entirely in ORACLE.
l Additional Database: this is entirely in ORACLE. All the BDC data can be stored in it, in
tables that have the same structure, and the HDB data when a backup is recovered, whether
it is on tape or on disk. Therefore, it is used as a security support, and also to recover the
ORACLE data that is stored on tape without altering the Databases with which the
application is working.

The two above classifications (physical support and function) are shown in the following
figure.

The BDCONF is like a large data store where all the information is kept in boxes, and each
box keeps information about a specific object in the system. It is supported by ORACLE and
so all the latter's facilities are available.

The static RTDB consists of tables with a different structure from the BDCONF. Its purpose is
to allow rapid access to the configuration information while the System is operating.

The dynamic RTDB also consists of tables, whose structure is similar to that of the static
RTDB. The values collected from the RTUs are stored in it and which constitute the current
state of the System. This information varies greatly in time, hence the fact that these tables are
in a different database from the static RTDB.

3.9.1 Configuration database

This database contains the description of the elements that make up the system, together with
the relationships between these elements.

The Configuration Database contains a complete definition of the System: architecture,

function, hardware and software environment, telecontrol network, field data, etc.

The initial loading of the BDCONF is usually executed from the text files, by means of the
ORACLE Sql*Load utility.

The Real Time Database (RTDB) is automatically constructed from the Configuration
Database. One relevant characteristic is the possibility of modifying the configuration and
partially or completely regenerating the RTDB "on-line".

Reservados todos los derechos. Información propiedad de ELIOP 3-45

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

SHERPA/PC provides a Database Editor for querying and modifying on BDCONF, and it also
retains all the configuration that is necessary for defining the specific system application
environments.

This Database Editor enables the user to gain access to the BDCONF through specific screens,
designed for selective and controlled data input. These screens show the different fields for the
tables for each record (tupla) and these can be modified. This editor is intelligent, in the sense
that it checks that the information that has been entered is consistent, reviewing the presence of
incompatible options and generating the local information that is necessary in order to let the
SHERPA/PC subsystems operate correctly from the configuration. Most of the fields are
equipped with a "help" option that describes the contents, the values that may be entered and
the restrictions, if there are any.

The Editor is based on the "Forms" and enables the user to modify individual elements. The
general characteristics of this tool are:
l To provide a standard interface for gaining access to the data.

l It allows displaying, deleting, modifying and creating new data in the Oracle’s BD.

l Checking that the information is consistent before recording or deleting data in Oracle’s
BD.
l Provides information about the meaning of certain values for some fields.

l Provides the filling in of data, given that some fields already have values by default.

SHERPA/PC is equipped with procedures for on-line modification of the database, in such a
way that, on the one hand, new RTUs can be registered and, on the other hand, it is possible to
modify the information about the configuration of the Telecontrol signals (alarm limits, bottom
of scale, etc.).

The signal configuration page is provided for on-line modification of an element.

Massive modifications to elements can be made, and even to the behavior set for the System;
the following procedure has to be used to make these modifications:
l All the elements that the user wishes to modify can be executed using BDCONF
(ORACLE), by registering any new element in the Database or modifying the characteristics
of one that already exists.
l A check is executed on the BD, to find out if an error has been entered; the go back option
is available to undo any of the changes made.
l The Install Database "option" is executed from the Maintenance Menus.
l While the Database is undergoing a complete change, it is "unavailable" for about 10
seconds.
l The "distributed" Operating Consoles are notified about the unavailability of the system
through a window that appears indicating “RECONFIGURATION”, which disappears
when this reconfiguration process is completed. This operation DOES NOT require the
System Consoles to be reconnected.

Reservados todos los derechos. Información propiedad de ELIOP 3-46

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

l The reconfiguration brings about a deferred launching of an integration between the

Database and the RTU’s. Once this “RECONFIGURATION” process is completed the
system is immediately Operational.

Furthermore,, there are parameter configuration tables for the system that an operator without
privileges cannot gain access to, which make it possible to, for example, design the system.
These tables must only be modified by authorized ELIOP personnel.

3.9.2 Real Time database

The real time information not only for measurements but also for the status of equipment, lines,
devices, etc. are stored in the RTDB, a database with a relational structure belonging to the
SHERPA/PC system; it is especially designed for storing and querying information that is
subjected to major time requirements. It enables the user to add new tables and attributes
without having to recompile.

Its contents can be divided into two parts:

l Static: this basically contains configuration information that is either explicitly contained in
the Configuration Database described above or can be obtained from it. However, as it is on
the RTDB, access for the program is much quicker. Consistency can be guaranteed using
simple control mechanisms. This information does not change when the system is operating
normally.
l Dynamic: this contains values that are constantly being refreshed to show the state of the
system at all times. These values include the measurement of voltage, intensities, loads,
pressure, etc., as well as the status of the switches, pumps, operatively of the equipment,
activities of the printers, availability of the lines, etc.

The RTDB is supported in memory and is updated every second in the files, for quick access.
It is managed by a SUPERVISOR and a RTDB SERVER that performs the following
functions:
l Managing the updating of data

l Managing commands
l Generating alarms when necessary
l Updating the calculated signals
l Service notifying about changes.

3.9.3 Alarm database

This BD is in files mapped in memory (Cache of Alarms) and in ORACLE (Chronology of
Alarms).The alarms in the system generated by the SHERPA/PC and received from other
systems (RTUs, DMS, control centers, ...) are stored in it.

Reservados todos los derechos. Información propiedad de ELIOP 3-47

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

The Cache of Alarms is used to see the alarms quickly and simply through the respective MMI
window. Acceptance and deletion of alarms can take place on this BD.

The filters alarm groups (defined in the Configuration Database) enables the user to select
groups of alarms in accordance with criteria defined by himself, such as geographical location,
component that gives the alarm, RTU that it is comes from, etc.

The ADB can be completely configured by the user through the Configuration Database:
reaction of the Alarm Server to an event, structure/size of the ADB, format of the Alarm
Record, reaction of the Alarms, group filters, correlation etc.

The Chronology of Alarms is an ORACLE database that all the system alarms are stored in.
This BD generates a process referred to as “alarm dumper” that is responsible for copying into
ORACLE the alarms that are in a cache.

There are several significant differences between the two databases. Firstly, the difference in
support allows for a greater depth in Chronology (ORACLE) than in the Cache. Secondly, the
operator cannot delete alarms from the Chronological one (the ones that have been there the
longest are automatically deleted to leave room for the new ones when a predetermined
maximum size is reached), but can delete them from the Cache. Finally, the alarm acceptance
and deletion dates are stored in the Chronological database.

The main use for the Chronological Database is to allow for the preparation of reports with
reports with alarms of a specific type that have been given a certain period of time.

The ADB is managed through a ADB SERVER and a set of utilities that enable the user to
execute the following functions:
l Managing a circular Cache of Alarms for fast access/storage.

l Transferring chronologically the Alarms to ORACLE in a circular or linear BD.

l Access to the Cache of Alarms through libraries that support the Distribution.

l Service that gives notification about new Alarms.

l Emptying/copying/initializing services.
l Access to the alarms in ORACLE through SQL or other tools.

3.9.4 Historic Database

The Historic Database is implemented in ORACLE . This Database enables the user to store the
values that different signals in the system have had throughout time, integrated into several
periods of time (hourly, daily,...).

The historic information can be used in several ways in SHERPA/PC: generating graphs,
preparing reports or lists of values. Furthermore, all the ORACLE tools, such as SQL*Report,
and other types of commercial tools (Ms-Access, Ms-Excel,...) can be used to gain access to
historic data.

Reservados todos los derechos. Información propiedad de ELIOP 3-48

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

There are several tables in the BDCONF that enable the user to define the values of certain
signals throughout time and the treatment they are to be given. The parameters that can be
configured include:
l Structure/size of the HDB
l Signals (measurements or contacts) that go to historics
l Factor and offset (to scale the historic values)
l Period of closure: every 5 minutes, daily, monthly, ...
l Reason for storage: periodical, by events, on request from the Operator,...
l Depth: 6 months, one year, ...
l Statistics: maximum, average, minimum, ...

The historic values are calculated and stored as the data are received from the telecontrol
equipment. The statistics to be applied to each measurement point can be the average, the
maximum, the minimum, etc., and more than one statistical process can be applied to one
single object. Data Quality codes (telemetry error, manual entry,...) are stores in database.

Storage in the Historic Database can be either circular or linear in form.

When the storage is circular, the oldest data are lost, when the storage is linear, the BD grows
until it is full up and it is the System Administrator that is responsible for its maintenance.

Reservados todos los derechos. Información propiedad de ELIOP 3-49

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.10 Incremental Management

SHERPA/PC Incremental Data Base Management option mechanism provides the capability to
append, modify or delete telecontrolled points without affecting SHERPA/PC operation i.e.
without stopping SHERPA/PC operation. Those modifications are named as Increments and
are introduced in the System using Forms, files or drawings, having the same treatment for in
any case.

Each Increment is defined as a set of data that is involved in the SHERPA/PC telecontrol
system, and that can be appended, modified or deleted from the data base. Each Increment is
identified by a unique name.

Main life stages of an Increment are Preparation and its later on Execution.

System is able to manage an undetermined number of Increments in Preparation stage but just
one in Execution stage.

Increments are considered as independent one of each other, so application order is the
Operator responsibility.

The set of Data Base Tables charged of Increments management are named as the Incremental
data base (BDI). This date base resides in Oracle. The contents of the BDI is related to
appending, modifying or deleting tasks of records and to Increment identification.

Incremental Management is compatible with on-line Configuration, although this method will
be used occasionally.

Find ahead a graphic that shows the Preparation and Execution actions for an Increment:

Actions related to the Preparation stage are:

l Create. Generate a new Increment.
l Import. Increment import from files
l Export. Increment export to files

l Modify. Increment modification functionality

l Delete. Removes the Increment from the BDI
l Check. Verifies data consistency at the Base System

l Propagate. Propagate and checks the Increment at the Target System

l Validate. System Administrator action that validate the checked Increment
l Summary. Lists Increment contents

Reservados todos los derechos. Información propiedad de ELIOP 3-50

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

Actions related to the Execution stage are:

l Applicate. Increment application.
l Undo. Returns system data to before Increment application state
l Consolidate. Consolidates an already applied Increment
l Delete. Removes the Increment from the BDI
l Summary. Lists Increment contents

Security mechanism for Incremental Management uses two permissions that can be assigned to
designated Users and that gathers Preparation and Execution tasks.

Increment includes global state and partial state of Base System and possible Target Systems.
Base System is considered the one where Data Base resides and Target System, the one or
ones that are configured with that Data Base (read Centralised Management paragraph).

For every operation, possible errors are identified, making the user correctly develop the
Increment. Checking result is stored in the BDI and can be accessed through a specific Form.
Only last operation errors are kept.

An Increment Logger file keeps all operations performed and the Increment development.

Reservados todos los derechos. Información propiedad de ELIOP 3-51

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.11 Customizing the application

3.11.1 Configuration
SHERPA/PC provides the BDCONF tool, which enables the user to create, modify and
maintain, all the configuration that is necessary to define the specific system application
environments.

The application can be completely configured from a PC

In view of the fact that this information is stored in ORACLE, as is the case with the alarms
and historics, it is not necessary to use the tool provided by SHERPA/PC for this task and
other methods can be used that are compatible with ORACLE, such as loading the information
from ASCII files in tabular form that can be generated by other applications that are
supplementary to or external to SHERPA/PC.

The information concerning the configuration of the system that is stored using this tool,
ranges from the measuring points that are present to the automatic reports, together with the
communication paths, the remote equipment, the different alarms that can be generated, etc.
This makes the System highly flexible and simplifies the task of modifying it so that it can adapt
to new work conditions.

The program that is in charge of bringing the system into line with the changes that have been
made is intelligent. It checks that the information that has been entered is coherent, reviews to
see if there are any incompatible options and generates the information in the Real Time
Databases so that the SHERPA/PC subsystems operate correctly from the configuration.

Reservados todos los derechos. Información propiedad de ELIOP 3-52

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.11.2 Graphical screen editor

The evolution of a system being operated is not only limited to modifying configuration
information, but also involves modifying the way in which information is presented; with a
view to ensuring that this task is not too laborious for the people that are in charge of it, a
powerful graphical tool is necessary to make the work easy and to detect as many errors as
possible.

Each and every one of the system synoptic can be generated with the graphical
display editor

SHERPA/PC includes a graphical editor in the MOTIF environment, which enables the user to
easily modify the contents of the Synoptic windows, by adding or removing elements that can
be controlled by the operator. These elements link up with the editor itself, to functions that
are provided for the different objects in the Real Time Database (signals, RTUs,
communication paths, etc.) and the drawing is available so that an Operator can display the
new information and/or telecommand it.

The Synoptic editor makes it possible to define graphic objects that enable the user to
represent the different entities that are stored in the databases (dynamic element) and any
graphic object that does not vary that is present on any display belonging to the System (static
element). Furthermore, it is capable of including graphs in vectorial or bitmap format that have
been made with commercial graphical packages (.bmp y .dxf formats).

The association between a dynamic graphic element and its corresponding point in the database
is simple to define and involves selecting the object and choosing the name of the database
point in a window.

Reservados todos los derechos. Información propiedad de ELIOP 3-53

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

The association between the graphic treatment and certain events in the system is just as simple
to find: a graphic object is selected and then a selection is made from the desired menu (change
of color, of shape, etc.).

The editor handles the "Jump point" item as well as the static and dynamic objects; this is a
drawing element that causes the window to show another previously allocated drawing when it
is selected.

The main facilities that the Editor is equipped with are as follows:
l For creating the drawings, it allows primitives of the following types:
u Line, Arrow, Rectangle, Filled Rectangle, Rounded Rectangle, Filled Rounded
Rectangle, Button, Shaded Rectangle, Arc, Filled Arc, Ellipse, Filled Ellipse, Polygon,
Filled Polygon, Highlighted Polygon, Spline, Closed Spline, Closed and Filled Spline,
Texts, Lines of Text, Texts with Zoom.
l The tool enables the user to execute the following operations on already drawn objects:
u Rotate, Opaque Movement, Bitmap, change of definition of polygons or Spline.
u It permits handling operations such as:
u Selecting palette of colors (background and foreground). Selecting sources. Thickness
and style of lines. Selection of drawing primitives, Scaling for drawings. Copying and
Pasting elements and zones of the drawing from one diagram to another. Grid tools and
automatic adjustment tools (snap). Use of static / dynamic libraries.
l Handling color:
u Using predetermined colors allocated to RGB levels.
u The background color can be set for each one of the synoptic.
u Setting the type of letter, style of line, thickness of line.
u Grid that can be designed within the drawing area
l Operations on DYNAMIC Elements:
u Defining, Recovering, Saving, Configuring the treatment with a choice of treatment
through lists of significant names. Establishing links with the Database by means of the
identifiers for the signals in that Database. Checking the links and presenting errors on
the display.
u The behavior permitted by the graphic editor for the different dynamic elements includes
changes of shape, color, blinking, visibility/invisibility.
u The Graphical Editor enables the user to handle levels, in such a way that the different
elements that make up the image on the display, both static and dynamic, are allocated at
a presentation level, and this level can, in turn, be associated with Zoom level and give
rise to the selective display of information in accordance with the zoom concerned
(decluttering). The presentation levels do not necessarily have to be associated with
zoom, in which case the information will only be displayed on request from the Operator.
u The Graphic Editor can also be used to show the communications status and operation
for the system RTUs and peripherals, as well as the data associated with the physical or
calculated signals.
u Including and generating Bitmaps.

Access to the Graphical Editor is controlled depending on the level of the user.

Reservados todos los derechos. Información propiedad de ELIOP 3-54

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.11.3 Other characterizations of the Application.

There are other elements that will help to characterize the application for each user, such as:
l Language: All the texts that appear in SHERPA/PC are contained in a small language
database, which means that it can be customized to use the language used locally; even if
the texts proposed by ELIOP do not entirely please the end user, the latter can modify them
without ELIOP having to be involved. The texts currently exist in Spanish, English and
Portuguese.
l Format of the Alarms: the basic format of the alarm line consists of a set of fields that
describe date and time, element in which the alarm has gone off, text associated with the
alarm concerned, information about the final status of the element and supplementary
information. This format easily adapts to the requirements of the end user.
l Colors of the Alarms: Texts may appear in different colors on the alarm pages; these colors
can be configured through the Configuration Database, and can be set to a different color
for each event and every element for which an alarm goes off.
l Frequency of the Horn: when the horn associated with an Operator Workstation is used as
the element to indicate an alarm, SHERPA/PC allows it to be associated on an “event” level
with the frequency (high or low pitch,...) of the horn's sound.
l Windows format: The size and the position in which the different windows of the
application is booted can be completely modified.
l Behavior in the face of events: Any action that the operator takes on system elements or
telecontrol points is considered to be an event, and so is any change that SHERPA/PC
automatically detects as having taken place in the field; a decision concerning what has to be
done with the event in question can be totally customized in the system: from ignoring the
event and not keeping any information about it, to considering it to be an alarm and
attaching a level of severity to that alarm, or with a behavior, referring to the way of
accepting/deleting that alarm, or deciding that in the face of the detection of a certain event,
SHERPA/PC can automatically execute a specific sequence of commands or a specific
program.

Reservados todos los derechos. Información propiedad de ELIOP 3-55

 SHERPA/PC: THE SCADA OF ELIOP

4913 9004 V1.0/023

3.12 Documentation.
The standard documentation for SHERPA/PC consists of the following manuals:
l Operator's Manual. It contains a description of all the actions that are available for the
System Operators; including documents containing the criteria used in each system.
l Graphical Editor Manual. It contains a detailed description of the graphical tools used to
determine the dynamic behavior of the synoptic representations for the system.
l Administration Manual. It contains a description of the tasks that have to be performed to
ensure that the system is correctly administered.
l Database Configuration Manual. It describes the structure of the system Database and also
a field by field description of it. It also includes procedures that have to be followed when
configuring takes place.
l Documentation of events. It includes a description of all the system events, the reason for
each one of them being generated; and also includes a customization of how the events in
each system are configured.

The Operator Manual is available in HTML format so that it can be used by the application for
on-line help; this manual can be modified by the end user.

The rest of the manuals are available in PDF format.

Reservados todos los derechos. Información propiedad de ELIOP 3-56