Elipse Knowledgebase

• Each SCADA Server should have an application copy (or a partial copy) configured at the local database.
• Each SCADA Server runs only one database at a time.

This leads us to some management problems, like applying changes to all servers, controlling application versions, or even working with different software manufacturers.

Elipse E3 solves this problem by using the concept of Domain, which includes in a single environment the definition of computers executing real time tasks (servers), and project databases that should be executed at these servers, with the possibility of executing several projects in each one. You can also insert, delete, or modify projects during execution, without affecting the other running parts of the Domain.

Each project can contain any kind of object, such as graphics (Screens), I/O Drivers, Alarm and History Assignment, Reports, Formulas, Databases, etc. When two or more projects are inside a Domain, they can access each other's properties and objects as if they were residing in a single database. This is possible because one object can establish links with the other - if both objects exist and are running, the link is active and any change in value is sent asynchronously between parts, depending on link type. If one of the objects is destroyed or stopped, the link is broken - then the application is notified about it and can indicate the state in a user defined way.

Domain structure is restricted to server counterparts, like server computers, projects, users, and passwords. The client user interface for operation and viewing, called E3 Viewer, can connect directly to any E3 Server with enough viewer licenses. E3 Viewer has three special features:

• The application projects reside on server only.
• Any executable program (Viewer.exe, for any Windows OS), like Internet Explorer or Netscape Navigator , can be used as a client operator interface, with no difference between them. You can also use Windows Terminal Services to access the same client interface regardless of the operating system.
• Client interface is capable of switching from a failed or crashed server and reconnect to the next server available, without having to stop process monitoring.

4) The Domain Structure

Domain structure is divided internally into cells, called Sub-Domains. Each cell is made of one E3Server operating in isolation, or two E3Servers in a dual standby configuration. Each Viewer, in fact, connects to a Sub-Domain instead of just to a Server.


Figure 2: A Super Domain example


After connection, Server and Client check with each other for the existence of system objects registered and updated on Client machine. If not, the Server starts to upload object definitions like user defined libraries and ActiveX Controls.

As for the client, it starts downloading the first screen (graphical interface), including any objects inside it, and saves it in a cache directory. This process can take some seconds, depending on the application, but it shows more benefits the next time you enter the same screen, as the Viewer performs disk and memory cache. If you do not close the Viewer, the next time you open the same screen (and the screen had not yet been reconfigured) it will have already been created in memory, thus reducing pagination time. If the screen has changed, Viewer will download it again, starting the process one more time.

After opening a screen, Server and Client exchange only real time values and database queries in a TCP/IP message scheme, in a high-performance manner when compared to Terminal Services, depending on the system. This is possible because while E3 Viewer receives and sends real time values only, the Terminal Services Client sends keyboard and mouse movements and receives Video Images.

A Viewer connected to an isolated Sub-Domain can handle information residing inside the active server only, according to user access rights. However, if the Sub-Domain is inserted in a Domain with more siblings, it can operate as a bridge to other servers.

So, one or more Viewers connected to a Sub-Domain can access information residing on other Sub-Domains, depending also on user rights for each Viewer. When it requests a certain piece of information, such as a Screen or a link to a non-existing object at the local Sub-Domain, the active local Server starts to talk to the other Sub-Domains to check whether these objects exist. If positive, the Sub-Domains act like a gateway for the local Viewers, downloading screens or performing real-time communication between local viewers and remote servers, enabling a wide area SCADA network across different applications and systems.


5) E3's System Modules

E3's internal architecture is totally scalable, with each main task being executed by a separate server. Below there is an overview of E3's building blocks.

In more details, E3 Server is the responsible for creating a Runtime process (E3 Runtime) that will really execute the application. Inside runtime we find E3 specific servers, with services used by other modules.


Figure 3: E3 modules diagram


6) User and Symbol Libraries

One of the most powerful and interesting features about E3 is the user defined library, which are files with .LIB extension that can contain one or more user defined objects. These objects can be of two different types: XControls, which are graphical libraries, executed at the Viewer, and XObjects, which are data libraries, executed at the server.

XControls are graphical user objects, with properties, methods, and scripts, made with any objects, including ActiveX and other XControls. Once created and registered, you can insert the XControl on a screen, where you can define its behavior or associate its properties to external variables. Any change in library is automatically reproduced in all object instances, creating an endless connection of every instance with the original definition. As explained before, each client that opens a screen performs a download with all object definitions, creating a screen cache management.

XObjects are data user objects, also with properties, methods, and scripts, along with internal server related objects (I/O Drivers, Alarms, Historic, etc.). The XObject is inserted in a specific container called DataServer, where you can define its behavior or associate it to external tags. Just like with XControls, any change in the original XObject definition is automatically reproduced in all object instances.

XControls and XObjects can be associated to one another to gain performance in complex applications. You can define one or more XControls to access information from one or more XObjects. XControls only load necessary information, leaving the complete real time database at the Server. This feature allows an application with several monitoring items to have fewer screens, as the XControl can "point" to different XObjects. For repetitive applications, the library scheme shortens development cycle, as it can include the communication driver, tags and variables, alarms, etc. Library objects are also called ElipseX objects.


Figure 4: XControl and XObject approaching


E3 Studio has also included a vector-based symbol library with more than 3,000 graphic symbols. These symbols can be used inside your application, directly on Screens, or inside XControls.


7) Other features

Databases

Elipse E3 does not make use of a proprietary database to store information - the DB Server module handles any commercial database, like MS-SQL Server or Oracle. If you have no database license, it can store data in the Access (MDB) format. Information like Alarms & Events, Historical Data, and Formulas are stored in database tables.

The DB Server uses the database Administrator rights to create and manage tables, so you do not need to perform any database maintenance in a separated tool to keep the system running. E3 just erases old data from main tables or shifts them to a backup table. After being shifted, data can finally be deleted after a defined period of time or even returned to the main table for further analysis.

The Alarm & Events table format is defined at Alarm Server module, where you can choose among the available fields; the Historical assignment and formula definitions are made directly in the corresponding objects.


Database Synchronization

For a dual standby application (or a Sub-Domain), where databases are located at the servers, databases can commonly create blank spaces of information when one of the servers fails. To avoid this, E3 implements database synchronization between servers.

The information sent to the active server database also suffers an attempt to be stored at the backup database - if this operation could be executed, then this data is checked while being synchronized. However, if the process fails, then information is not updated and will suffer other attempts to be stored at defined intervals. Even if both servers are shut down, each server will transfer the unsynchronized records to the other server’s database when it returns to activity, until they complete their tasks.

The same process is used when the database is disconnected for any reason from the DB Server. When this happens, a temporary storage file is created at the local computer to handle data while the main database connection is not retrieved.

A similar problem happens when we need to synchronize or concentrate databases running in different Sub-Domains. In this case, the DB Server can just duplicate information (storing data in two databases at the same time) or even perform a one-way synchronization with a central DB Server.


E3's I/O Servers

Elipse E3 implements special I/O management features to enable applications of any size to run smoothly, even with hundreds or thousands of devices. The concept of communication driver includes four entities:

• IOTags and IOBlocks: These are variables extracted from I/O Devices, like PLC's, Controllers, Data Acquisition boards, Relays, etc. Each IOTag is configured to represent specific information and can assume different data types, like Booleans (true/false, on/off), Integers, Real numbers and Texts. Depending on the equipment and the protocol used, the IOTag can have more complex formats like data structures or recordsets, and important details about information, like quality and timestamp are also informed.
• IODevices: Definition of the devices where the variables are located, with information about models, types, cards, etc.
• IOConnections: These are the physical details of communication, like media, speed, and type - UDP or TCP/IP, Serial, Modem, RAS, etc. Each IODevice should be associated to an IOConnection, being possible for several IODevices to share the same connection (like a RS-485 multidrop network).
• IOServers: Executable programs that handle communication. You can define that an IOServer will handle a specific number of connections, so E3 will create more IOServers dynamically to manage more connections and devices.

Figure 5: Typical driver settings


In addition, Elipse E3 can act as both an OPC Client and an OPC Server for greater connectivity, including data exchange with other SCADA packages.


Alarm Management

E3 defines three main entities for Alarm Management: AlarmConfig, where you can insert hierarchical Areas; by its turn, it can handle AlarmSources that define explicitly the verification type (Analog, Digital, Rate of Change, DeadBand) and Source (IOTag, internal variable, etc.).

During execution, Alarm messages are sent to AlarmServer, which manages the AlarmHub, controlling the input/output of messages to other servers and clients, and user acknowledgement.

The messages can be viewed and acknowledged by the user with E3Alarm object, enabling message filtering, color control, blinking, and ordering.


Superior Reporting

E3 includes top level reporting tools that enable you to create virtually any kind of historical and real time reports. With E3 Query tool, you can create and manage SQL queries to extract information you want from databases, with filters, ordering, views, etc., allowing you to edit SQL queries manually as well.

With graphical report designer you can define report appearance, with headers and footers, groups, and detail sections, including special calculations like sums, averages, deviations, etc. Inside every section you can have objects like barcodes, drawings, images, labels, data fields (from SQL Queries), scripts (VBScript), and Trending/Charting.

The report output can be previewed on screen, sent directly to printer, or exported to Acrobat PDF, Microsoft Excel, RTF or HTML formats.




8) Elipse's expertise and world presence

Elipse Software has been in the automation market for over 20 years, developing solutions for HMI/SCADA projects and interfaces for many types of applications.

Elipse Software brings expertise and knowledge to several application areas, like Chemical, Water/Wastewater, Power (Generation, Transmission and Distribution), Energy (Metering, Protection and Management), Process and Production, with branches and distributors in several countries, like U.S, Germany, India, Taiwan, and Brazil.