Mirroring objects between D2000 systems

If you are using multiple D2000 systems, you must have encountered the need to transfer objects between them.

Learn how to do it in this article

A typical case is the development of new functionality in a test environment and the subsequent transfer of objects to production. The challenge is to transfer everything that is needed. While the XML export and XML import functionality offered by the D2000 to transfer the configuration of individual objects guarantees referential integrity - i.e. an object is not transferred unless all the objects used by it are present – it obviously does not protect against all types of errors. Thus, it may happen that an object exists in both environments, but a test environment contains its new (modified) version and production version is still original.

Another case is the need to transfer objects and their values ​​between interconnected SCADA and MES systems. A typical SCADA has only a few users (dispatchers, operators) with permission to control the technology. In contrast, the MES system retrieves data from one or more SCADA systems, computes balances, and communicates this data to dozens or hundreds of users. They can analyze or modify the data, but they have no direct influence on the technology (they cannot control it).

How to do it?

To simplify the transfer of objects among several D2000 systems, Ipesoft developed the SysMirror module (deployed on the source D2000 system) and the SysRorrim module (deployed on the target D2000 system - its name is a mirror image of the name SysMirror). They allow D2000 system administrators to compare configurations of two D2000 systems, select objects for XML export (including handling dependencies of objects), and perform XML export and import.

The objects of the source D2000 system are compared to the objects of the target system - the object search is performed not by the object name but by a unique identifier (UID). This allows the objects to be renamed during the transfer - in the target system, all transferred objects can have a prefix that indicates that they are mirrored (e.g. a measured point M.test will be named M.RIS.test after the transfer).

Objects are compared by object modification time. The administrator can choose to display objects that exist only in the source system, are newer in the source or target system, or are identical. It is also possible to filter according to the modification time in the source system (e.g. we are only interested in last week’s changes).

What about the objects that we do not want to mirror? We also thought of this - you can hide objects (based on the mask of name or UID of a particular object) so that they do not appear in the object list. Thus, for example, system schemes or technological details that are not to be copied to the target system can be filtered out.

This way, after configuration changes in the source system, it is easy to select the modified objects and have them exported. If e.g. a scheme is exported, all objects that it references (e.g. measured points, calculated points, archive objects) that do not exist in the target system are also exported.

Transfer of values

So we have managed to transfer the objects - but can we ensure that they will also "live" - so that the target system will show the values from communication, the calculated points? Will it also be possible to look into archives? And how complicated will be the configuration, or the reconfiguration when changes occur?

For all those asking, we have only positive answers. The values will be transmitted using the functionality provided by the D2000 Transparent Gateway.

It is simply configured to transfer values of objects belonging to specific processes (e.g. KOM, CALC, ALARM) or values of objects specified by mask (e.g. all RIS user variables, i.e. U.RIS* mask). If new objects are imported into the target system, the transparent gateway automatically adds them to the list if they meet the specified criteria. No need to reconfigure the gateway, no need to restart it.

Further details

Until now, the transparent gateway only supported object transfer based on object name. To support the possibility to rename objects, a parameter was implemented that allows object matching between the source and target systems according to the UID of the object.

How about using SysMirror in redundant systems? In the user interface, the user can select the configuration database of the target system against which it is compared. Under normal circumstances, it does not matter whether the active or passive server configuration database is being used - this setting needs to be changed only if the selected D2000 Server is turned off.

If the object name is not changed during the transfer (e.g. transfer between the test and production environment), the SysMirror and SysRorrim modules can be deployed symmetrically in both environments. Thus they can be used to synchronize e.g. changes in configuration of individual objects from production to test environment and vice versa.

SysMirror and SysRorrim modules were tested on a real configuration during migration of customer SCADA and MES system to D2000 V12. Using these modules, more than 57000 objects were transferred in batches of about 1000 objects at a time. We started with communications (lines, stations, measured points), followed by calculated points, archive objects, user and structured variables, graphs. Finally, the schemes were transferred (along with the graphic objects used, such as fonts, text styles, and various palettes).

Conclusion

SysMirror and SysRorrim modules are another tool for working with D2000 technology. I believe that they will be deployed to multiple customers in the near future to simplify and speed up the work of administrators and application developers.