This is the second in a series of blogs about the architecture of SCADA systems. In them I would like to address the important features of SCADA technologies, the presence (or absence) of which affects the functionality, user-friendliness, usability and scalability of these technologies. This blog will be about Dynamic Object Data Model (DODM).
What is DODM?
In 1993, when a small group of people (with experience in the development and deployment of control systems, work with the RMX operating system, knowledge of SMEP minicomputers) began to develop the D2000 technology, for the first half a year they only worked on a thorough design - only then did they start programming. Their design drew on their previous experience - in particular, they tried to avoid the mistakes present in the control systems and software projects they worked on in the past.
The technology they designed they named DODM. What do each word mean?
Dynamic – configuration of Ipesoft D2000 applications takes place on a live system. It is not necessary to restart it to apply the changes. To be completely precise, in some situations it may be necessary to restart the communication process (e.g. changing the type of communication line from serial to UDP), but this can also be avoided by changing the configuration procedure.
Object – the application configuration consists of objects. Objects are of various types (measured point, station, line, calculated point, archived value, process...). In addition to static objects (existing in the configuration), there are also dynamic ones - e.g. a list of objects opened from the configuration tool, a control dialog for setting the value of an object or a list of alarms.
Data Model – the configuration of the application is in the memory of the D2000 Server. It consists of objects and relationships between them. There are two basic types of relationships between objects:
- Parent - child
- Object X uses object Y
Since the configuration of objects takes place on a live system, it is important not to corrupt the configuration - for example, by the user deleting an object that has children (and making them orphans) or deleting an object that is being used by another object (and making that object stop work correctly). Therefore, an important feature that Ipesoft D2000 implements as a necessary condition for DODM consistency is the so-called referential integrity, which was discussed in the previous blog: an object cannot be deleted if it is the parent of other objects, or if other objects use it.
Parent-child relationship
Every object in D2000 has a parent. At the highest configurable level are processes (their parent is the SYSTEM object). Processes take care of their descendants, for example:
- Communication processes (D2000 KOM) have children - communication lines, those have communication stations and those measured points. Communication processes are responsible for communication with the environment (PLC, RTU, other SCADA/MES systems).
- Calculation processes (D2000 CALC) have children - calculated points and are responsible for performing calculations (periodic, on-change).
- Archive processes (D2000 ARCHIV) have children - archived values and are responsible for archiving values (primary, statistical, calculated, script filled) and reading values from the archive SQL database.
- Database processes (D2000 DbManager) have children - the databases, they have tables. They are responsible for working with SQL databases (reading/writing/working with BLOBs/running SQL commands and calling SQL procedures).
- Script interpreters (D2000 Event Handlers) have children – the scripts we call events (written in D2000 ESL or in Java) and their task is to execute them (on a trigger or as a permanently running server script).
- Client processes, i.e. the configuration tool (D2000 CNF), the graphics editor (D2000 GrEditor), and the user interface process (D2000 HI) have no children, but can open objects. For example, HI opens diagrams, graphs, reports, but also measured points - either directly in the browser or as a result of opening a diagram that uses the measured point.
Processes
In the previous list, I deliberately mentioned the processes in the plural. In the new application, e.g. only one communication process is preconfigured (SELF.KOM), but it is possible to create others (e.g. OTHER.KOM, REMOTE.KOM, etc.), and these processes can be run locally or on a remote computer. After starting and connecting to the D2000 Server, they receive a list of children and can start working. The same applies to other types of processes. The parent-child relationship thus makes it possible to divide objects into groups served by separate processes, which can be moved to separate servers - e.g. due to load distribution or in the case of a communication process due to physical topology – the KOM process can be located at a remote location, collect autonomous data even in the event of a network connection failure and send it to the D2000 Server after the connection is restored (this mode is called KOM Archive).
The core of the system – the D2000 Server process – is responsible for sending new object values to processes that need them. The "need" could have arisen statically (it is part of the configuration - for example, a measured value is needed by an archived value and a calculated point) or dynamically (it arose as a result of opening an object - for example, , a measured value is needed by a scheme opened in the Human Interface process or by a dynamic list of objects opened in the D2000 CNF configuration tool).
Object identification
Objects in Ipesoft D2000 have three different types of identifiers:
- Text name
- Numeric identifier (HOBJ – Handle of Object)
- Unique identifier (UID)
Internally, Ipesoft D2000 uses numeric identifiers (HOBJ) that are assigned by the D2000 Server when the object is created and never changed thereafter. Therefore, an object can be renamed without breaking referential integrity (and without needing to update the object name in all objects that use it). It is interesting that even in scripts (ESL scripts and Java) the name of the object (entered by the user) is replaced internally by the corresponding HOBJ.
Notice - if the name of the object is "brought out" out of D2000 (e.g. via OPC Server or OPC UA Server, or to third-party software using OBJApi or to Excel using VBApi), renaming the object will make it unavailable from the external environment!
The object name consists of a prefix, a body, and a suffix. Prefix and suffix are optional and configurable for individual types of objects:
The exception confirming the rule are objects of process type. Their suffix is determined by the type of process, e.g. KOM (D2000 KOM), CLC (D2000 CALC), EVH (D2000 Event Handler), DBM (D2000 DbManager), HIP (D2000 HI). Subsequently, the system allows you to create a child of the process according to the suffix (e.g. a line for a KOM process, a calculated point for a CLC or a database for a DBM).
Naming convention is important - just by looking at the name of the object, it is possible to distinguish e.g. a calculated point (M.something) from a calculated point (P.something), a structured variable (SV.something) or a user variable (U.something).
The unique identifier (UID) was created when implementing support for XML Export and XML Import of objects. They make it possible to distinguish whether objects in two different systems have an identical origin (one was created by importing the other, or both by importing the same object) or if the name match is only accidental. In addition, when connecting two D2000 systems using a transparent gateway, it is possible to identify objects based on UID (the standard identification is by name), so that objects can be renamed without losing the functionality of the D2000 Gateway. More information - see the blogs about connecting several SCADA systems and about the SysMirror application module. System objects have "pretty" UIDs, others have standard 16-byte numbers, expressed as 32-character strings (UUIDs).
Objects can be filtered in D2000 on the basis of the relationship to the parent (display of the children of a specific object), the mask for the object name and on the basis of the object type. In addition, objects can be classified into a hierarchy of logical groups and filtered according to belonging to logical groups.
Communication between processes
All D2000 processes are connected to the D2000 Server process and communicate through it. The following figure shows the connection of several server processes (blue) and user interface processes (orange) and the communication of the D2000 Server with the configuration database (at startup, it reads the application configuration from it and then saves all configuration changes).
Redundancy
The D2000 supports several types of redundancy. In this blog I will list three that are related to DODM, more information is in the blog about redundancy.
Network redundancy – remote processes (e.g. D2000 HI) can be connected to the D2000 Server via two independent networks, i.e. two TCP connections. Even the active connection will fail, unconfirmed data will be forwarded through the backup connection, so the data will only "freeze" for a few seconds.
Application server redundancy – operation of two or more application servers connected in a so-called redundant group. Each application server runs on a different physical computer. One of them is active - "HOT", all others are passive - "SBS" (standby servers). These receive changes in the configuration and object values from the HOT server so that they have current data at any moment and are ready to assume the role of the HOT server.
The activation of the SBS server occurs automatically due to the unavailability of the HOT server or maually by switching redundancy by the administrator (or by command from a script). Clients can be configured to automatically connect to the new HOT server. As a rule, remote processes (D2000 HI) and processes instances (D2000 KOM, D2000 Archive) are configured this way.
Redundancy of processes – server processes can be started as so-called instances. Instead of SELF.KOM, e.g. instances 1 and 2 can be started (i.e. [1]SELF.KOM and [2]SELF.KOM). There can be up to 15 instances of the process. One instance is always active and the others passive. The selection of the active instance is controlled by the D2000 Server and can also be set from a script. The functionality of the active instance is normal, the functionality of the passive depends on the type of process:
- D2000 DbManager, D2000 Event Handler – passive instance does nothing
- D2000 KOM – most communication protocols are passive, in the case of some (e.g. IEC 870-5-104) the behavior can be parameterized.
- D2000 Calc – the passive instance calculates the values of the calculated points due to the setting of internal states (e.g. the %PrevV function or the implementation of the time filter), but does not send the values to the D2000 Server process.
- D2000 Archive – passive instance archives the values, requests to read values are performed only by active instance.
Instances of the same process are typically running on different physical computers.
Network redundancy also enables maintenance of network components during operation (replacement, firmware update, etc.). Redundancy of processes and the application server makes it possible to perform computer maintenance, firmware updates, operating system updates (including restarts), database updates and the Ipesoft D2000 system itself during operation. Usually, redundancy is used with two D2000 Servers and two D2000 Archive instance processes (which connect to the HOT server), in some cases even triple redundancy is used (two servers and two instance processes on the main site, one on the backup site).
Conclusion
A good and high-quality design of the architecture of the SCADA system is critically important not only for its correct and optimal functioning, but also for its long-term development and expansion of both the SCADA system itself and the applications that are built on it. In the case of the Ipesoft D2000 real-time application server, 30 years have passed since its design, during which it was being developed and it has grown in accordance with the requirements of increasingly larger and more important applications in which it was deployed. Even the applications themselves grow and are developed over time - several of the big ones for more than 20 years. DODM technology with features such as referential integrity, redundancy, XML export and import enable stable operation of large industrial control systems and control of critical infrastructure (electricity production and distribution, gas dispatching, water dispatching, heat distribution and others). Ipesoft D2000 has managed to gain and maintain the trust of our customers and partners - and I believe that it will continue to provide valuable services to them in the years and decades to come.
October 30, 2023, Ing. Peter Humaj, www.ipesoft.com
