Connection of six SCADA systems

A recent upgrade at the customer included, in addition to the standard hardware replacement and D2000 update to version 22, configuring the connection of six smaller SCADA systems with a redundant MES system. In this blog, I would try to show the technology used and the benefit to the customer.

Why to connect

The goal of connecting the previously independent SCADA systems in six geographical locations was to make available local data, which until recently was only seen by dispatchers, to a wider set of MES system users. And not only data - the goal was to make technological schemes (or their copies) available, in addition to maintaining security - that is, users of the MES system can see all values, but the control is disabled, so they cannot control the technology, but only monitor the state of the technology and display historical values.

Figure 1 - Connection scheme of six SCADA systems with a redundant MES system

In terms of sizing, these were smaller SCADA systems (up to 5,000 tags) that controlled the technology through various PLCs (CompactLogix, Schneider Electric and others).

How to transfer data

Data transfer between two D2000 systems (e.g. production and test environment, or production environment and new system during migration) is ensured by the Gateway Client and Gateway Server processes in the Ipesoft D2000 real-time application server. The protocol between these processes is version-independent, so it is possible to connect different versions of D2000.

If there are the same objects on both systems (e.g. lines, stations, measured points, user and structured variables), the Gateway Client can be started in the so-called in transparent gateway mode, when it copies the values ​​of selected objects. For example, all lines/stations/measured points from the selected KOM process. Or a specific station with measured points. Alternatively, the values ​​of the user variables according to the selected mask.

The transparent gateway acts as a data diode, protecting the source D2000 system from being written to by the target. So it is possible to work without worries, e.g. on the test environment, or copy the diagrams and scripts of the source D2000 system to the target system without the risk of writing in an unwanted direction.

How to transfer objects

Before a transparent gateway can be used, the target D2000 system must contain the same objects as the source. If it is, for example, a test environment, it's easy - just copy the entire configuration database.
In our case, only selected objects had to be copied (using XML export and import). Communication process and its descendants – lines, stations and measured points. Archive objects, so that the values are also archived and available, e.g. for display in graphs. Some (selected) schemes and objects that are used by schemes (bitmaps, display, bitmap and extended palettes, graphs, etc.).
Moreover, in addition to one-time copying, it must be taken into account that the configuration of the SCADA system changes over time. Someone adds a few measured points, displays them in the scheme, improves the graphs ... for such cases it is advantageous to have a tool that allows comparing the configurations of two systems and finding changes.
The D2000 system has such a tool. It is a SysMirror application module that enables exactly this – comparison of the source and target configuration database, filtering and selection of objects and then their XML export and copying to an FTP or SFTP server. This tool is deployed on source D2000 systems. Its twin, a module named SysRorrim (Mirror backwards) deployed on the target D2000 application, is a simple scheme that enables display and user-friendly XML import directly in the D2000 HI environment.
SysMirror compares objects based on modification time. It can thus distinguish whether the objects in the source and target systems are identical (the desired state), whether the object in the source system is newer (and needs to be exported), or whether there is a newer object in the target system (which is a non-standard state and must be determined, whether someone modified it and whether the change must also be implemented on the source system, or it can be ignored), or whether some objects of the source system are missing in the target system (as we mentioned, we copied only selected schemes, not all).
In addition, SysMirror can also work with object dependencies. For example, if a scheme is selected for export, other objects (e.g. graphs, bitmaps, measured points) are automatically added to it, if they do not exist in the target system and thus the XML import would be unsuccessful due to a violation of referential integrity.

You can read a separate blog about the SysMirror application module and its deployment on a pair of large SCADA/MES systems (more than 57,000 objects were transferred). In our case, there are incomparably fewer objects, but on the other hand, we deployed SysMirror on six SCADA systems. As a bonus, we implemented SFTP support, so exported XML files are safely copied to the OpenSSH server (in this particular case, it was the OpenSSH server that is part of Windows 2019). In the past, SysMirror used standard FTP.

Naming

In order to easily distinguish in the target MES system whether the object belongs to one of the SCADA systems or is an "original MES" object, the SysMirror module also adds a prefix to the exported XML objects. For example, the measured point M.Temperature becomes M.SCADA_BL.Temperature if it comes from the BL system. Each of the six SCADA systems has its own unique prefix, so name collisions cannot occur.
For this reason, the Gateway Client processes in the MES system request objects from the Gateway Server processes (running in the source SCADA systems) not by their names, but by the UID - unique identifiers of the object. When renaming an object performed by the SysMirror module, the UID of the object does not change.

Conclusion

The Ipesoft D2000 real-time application server not only provides a comfortable environment for the development of separate applications, but also allows configuring a fast and elegant interconnection of several D2000 applications, as well as for migrating configuration changes between them. This can be appreciated by users who have test/production environments as well as those who need to interconnect different D2000 applications. The data diode functionality offered by the D2000 Gateway Client additionally increases the security of such a connection and prevents data transmission in an unwanted direction.

October 25, 2022, Ing. Peter Humaj, www.ipesoft.com