A redundancy of communication process KOM reduces the loss of telemetric data.
The following picture shows D2000 system with redundancy of communication process in D2000 system:
The redundancy of the communication process is realized by increasing the number of communication processes (D2000 KOM) in the system without the need to define them in the DODM model.
It is realized through the running processes in parallel (i.e. instance communication processes) - their names are identical (e.g. SELF.KOM). They are different in a so-called instance number the value of which can be within the range of 1 to 15.
It holds the following for the value of the object SELF.KOM:
If, at least, one instance is running the process will acquire the value Run. At the same time, each running instance of the process sets the user attribute (flag) of value as follows: instance 1 sets the flag B, instance 2 sets the flag C,...
The parameters of the communication process (kom.exe) can also define the instance number as follows:
kom.exe /Wprocess_name,InstNr
InstNr - instance number (e.g. kom.exe /WSELF,1)
The above-mentioned method allows the starting of several processes D2000 KOM with identical names at the same time.
The individual processes will execute the following actions according to their status:
- Active KOM process - executes an active capturing of data from telemetry and sending them to the system. Only one process can execute this action.
- Passive KOM process - generally, it does not interfere with telemetry, i.e. it does not open the communication channels and does not send any data. In some cases, however, it can watch passively the communication of the active KOM process with the devices. More information is in the document SerialOverUDP Device Redundant and SerialOverUDP Line Redundant.
Note: The /DBSH startup parameter for Serial, Serial Line Redundant, and Modem communication lines causes the serial port to be closed if the D2000 KOM process is connected to the SBS Server or if the D2000 KOM process becomes a passive instance. See note for more information.
The active KOM process becomes the one that connects to the D2000 Server first. Other processes are passive KOM processes. The active KOM process can be set with the command INSTANCE SET ACTIVE. In addition, an instance can be set as the preferred with the INSTANCE SET PREFERRED command, so that it becomes active immediately when it connects to the D2000 Server.
Mode 'active-active instance'
In D2000 version 22, the possibility to configure 2 or more active KOM processes using the SET_LOAD_BAL_MODE command was added. This mode was implemented to support specific redundancy in the configuration:
- redundant 2-node D2000 system
- on each node running one active instance of the D2000 KOM process (SRV.KOM) monitoring the HOT process (kom /WSRV,1 /RDMYGRP and kom /WSRV,2 /RDMYGRP)
- a TCP/IP-TCP line configured on the SRV.KOM process, a station with the IEC 870-5-104 Server protocol and with input and output I/O tags
- a superior control system that communicated in parallel with both SRV.KOM processes, sending commands to a single (but arbitrary) KOM process (and expecting command confirmations from it) and expecting spontaneous values from both KOM processes.
Important information
- Only communication protocols with so-called redundancy support can be used in the redundancy of the communication process. Detailed information about support of redundancy for individual communication protocols is mentioned in the document Communication protocols.
- The behavior of the communication process connected to the redundant D2000 Server in SBS status is the same as the behavior of the passive KOM process. All the above-mentioned information is valid - the passive KOM process generally does not interfere with telemetry.
- If at least one instance of the communication process is running, it is not possible to start non-instance (/WSELF) and vice-versa.
- TELL command SET_ACT_INST allows to control the switching of the active communication process.
- TELL command SET_PREFERRED_INST allows setting the preferred instance of the communication process.
- We recommended installing each of instance of the communication processes on a separate computer. It enables servicing without a breakdown of the telemetry.