Communication – IEC 104 Protocol
The IEC 104 communication protocol is intended for telemetry data collection and control in the energy sector. It is used for communication between two systems connected by a TCP/IP network. Basically, it is a network variant of IEC 101 enhanced by mechanisms that take advantage of TCP over a serial line - higher baud rates, guaranteed and error-free data stream transmission – in order to increase transmission speed and suppress the effect of latency. It is therefore advised to familiarize yourself with the IEC 101 protocol before reading this article.
IEC 104 uses the same ASDUs (Application Service Data Units) as IEC 101 for data transmission in the monitoring direction - in fact, it refers directly to IEC 101 in definition in accordance with the modularity of IEC 60870-5 standards, among which it belongs (since its full name is IEC 60870-5-104).
In the controlling direction, it adds the command ASDU 58-64 (variants with a 56-bit timestamp), which we have already mentioned in the article on IEC 101 - since the D2000 KOM also supports them in the IEC 101 protocol.
So how does IEC 104 differ from IEC 101 and how does it achieve the benefits mentioned above?
Packet format
Individual IEC 104 packets begin with a START byte (0x68), followed by a byte with a data length, a four-byte control field, and the ASDU itself. For comparison, an IEC 101 variable length frame starts with START, followed twice by length, and START again. Since TCP (unlike a serial line) guarantees error-free data transmission, there is no need to double START or length.
There is also a short packet format without the ASDU (then the field length is 4 bytes).
What are such packets used for? For control purposes (the start/end of data transmission), for sending test frames and acknowledging messages. To explain the details, we need to take a closer look at the structure of the four-byte control field.
IEC 104 defines three control field formats:
· The I-format (information) is used for frames containing ASDUs (I-frames). It contains a 15-bit SSN (Send Sequence Number) and RSN (Receive Sequence Number). Each party increments its SSN when sending an I-frame and at the same time sets the RSN to a value one higher than the last received SSN. The RSN is used to acknowledge the received frames. Therefore, if the station wants to send an ASDU, it can confirm the received data within the transmitted data (a technique called piggybacking in the communication).
· The S-format (supervisory) is used to confirm I-frames. The station sends an S-frame to acknowledge receipt of I-frames whose SSN is less than the RSN specified in the S-frame. This frame is sent by the station if it does not have any data that it would like to send via I-frame (typically an IEC 104 client, which usually only receives data from the IEC 104 server and only occasionally sends a command).
· The U-format (unnumbered) does not contain SSN or RSN and is used in 3 special cases:
o StartDT activation/confirmation - request for sending data via the established connection and its confirmation (request is sent by the client, confirmation by the server).
o StopDT activation/confirmation - request to stop sending data and its confirmation (request is sent by the client, confirmation by the server).
o TestFR activation/confirmation - sending the test frame and responding to it. Test frames can be sent by both parties to verify the functionality of the TCP channel when no other frame has arrived for a long time. The standard defines the idle time as t3 timeout with a default value of 20 seconds and it can be changed in the protocol parameters in the D2000 (the “Wait Timeout T3” parameter).
Establishing a connection
The controlled station in the IEC 104 protocol functions as a TCP server (it accepts clients). The controlling station is a TCP client (it connects to the server). Depending on the specific implementation, the IEC 104 server only supports single or multi-server operations. The "IEC 104 Server" protocol implemented in the D2000 is able to serve several clients in parallel while creating separate service tasks for reading and writing for each client.
The IEC 104 server listens on a defined port (in default TCP port 2404 assigned by IANA). By default, the client sends StartDT activation as the first U-frame by default, and the server responds with a StartDT confirmation U-frame. Subsequently, the server can send data ASDUs to the client with value changes, and the client can send command ASDUs with commands.
If the client does not send the StartDT activation U-frame, data ASDUs (in I-frames) must not be sent over such a connection, but only the TestFR activation/confirmation U-frames to verify that the TCP connection is functional. This option is useful if the client makes multiple connections to the server (e.g. via redundant networks A and B). In order not to overload the server, it communicates via network A and only in case of network failure A activates sending data via connection via network B. Similarly if such a client decides to change active connection (though connection A is not broken) and start communicating via connection B, it will send StartDT activation via connection B and StopDT activation via connection A.
Confirmation of data frames with ASDU
As mentioned above, SSNs and RSNs are used for confirmation. The following figure shows the sending of I-frames (SSN and RSN are in parentheses) and illustrates their acknowledgment. After receiving a frame with SSN = 2, station A sends a frame with RSN = 3 (which acknowledges receipt of SSN 0, 1, and 2). After receiving a frame with SSN = 1, station B sends a frame with RSN = 2 (which acknowledges receipt of SSNs 0 and 1).
If station A does not want to send I-frames, the standard defines the t2 timeout, after which the station must acknowledge receipt with S-frames. In the D2000, this parameter is labeled “Wait Timeout T2” and the default value is 10 seconds according to the standard.
If a station does not receive an acknowledgment of the sent I-frame or a response to the sent U-frame (i.e. to StartDT, StopDT, or TestFR activation) within t1 timeout (15 seconds), it considers the connection to be non-functional and closes it. The situation is shown in the following figure, in which station B received an acknowledgment of a frame with SSN = 0, but not another sent with SSN = 1 and therefore closed the connection after time t1 since the sending of this frame.
Furthermore, the standard defines a “k” parameter indicating the maximum number of sent and unacknowledged ASDUs. If the station has sent “k” ASDUs (the default value is 12), it will not send another and is waiting to receive an acknowledgment S or I frame.
At the same time, it defines the “w” parameter indicating the number of ASDUs, after receiving which the station must send an S-frame (or I-frame). The default value of the “w” parameter is 8.
The difference of the values of the parameters “k”-“w” (default 4) indicates the number of "pending" ASDUs, i.e. sent by one station and not yet processed by another. In specific cases (WAN connections with higher latency) it has proven in practice to increase the values of “k” and “w” parameters (up to tenfold, i.e. “k” = 120, “w” = 80) to eliminate the influence of latencies (network latency and possibly latency of the receiving station caused by e.g. CPU load) to ensure high throughput of the line and to avoid "stalling" due to waiting for confirmation after sending “k” frames.
Thus, increasing the parameter values can also eliminate the effect of latency at the level of hundreds of milliseconds, for which the serial IEC 101 protocol would be practically unusable for larger amounts of changes (the request/response cycle would last so long that unsent values would accumulate).
Interrogation
After establishing a connection (and sending StartDT activation), the controllingstation usually sends the first I-frames ASDU 100 "Interrogation Command" and/or ASDU 101 "Counter Interrogation Command" to request the current values of all objects, since after receiving StartDT the controlled station starts sending changes only.
In the D2000 KOM process, the sending order of the ASDUs 100 and 101 and whether they are sent is determined by the values of the "Order of IC" and "Order of Counter IC" protocol parameters.
Balanced mode
The balanced mode in the IEC 104 protocol means that both stations can send data ASDUs and command ASDUs. At the same time, the controlled station can send Interrogation (ASDUs 100 and 101) to obtain the current image of the controlling station's data points. The only difference between the two parties is who initiates the communication.
The balanced mode is not switched on by any protocol parameter on the D2000 side. Processing of command ASDUs in the protocol "IEC 104 Client" as well as data ASDUs in the "IEC 104 Server" protocol is supported by default (and it depends on the configuration of the other party whether it sends such ASDUs). The ASDU type is configured in the output I/O tag configuration and it is up to the configurator whether to use data or command ASDUs. In the I/O tag configuration, ASDUs of unbalanced mode (data for server, command for client) are offered first and then ASDUs of balanced mode (and at the end, the D2000 specific ASDUs).
When selecting an ASDU, the nature of the I/O tag must be taken into account - data ASDU values are sent to the other party in response to Interrogation, command ASDU values are sent only when there’s a change.
Time synchronization and timestamps
Just as in IEC 101, the ASDU 103 “clock synchronization command” is used to synchronize the time of the controlled station.
The "IEC 104 Server" protocol implemented in the D2000 processes the ASDU 103 so that it does not change the time of the computer or the D2000 system (this would not be desirable and in the case of multiple connected clients not even meaningful), but it preserves the time difference between its time and client time for time corrections of transmitted values (for ASDUs that use a timestamp).
The "IEC 104 Client" protocol implemented in the D2000 performs time synchronization according to the parameters set on the station. Additionally, if the "Force Master Time" parameter is set, it is willing to process the ASDU 103 sent by the IEC 104 server (which is beyond the scope of the standard) and it corrects the times of the values that came with the timestamp to adjust to the D2000 system time. An alternative is "Force Slave Time" parameter, which in turn causes the time-stamped ASDUs to be accepted into the system without change and the values from the time-stamped ASDUs to be marked by the D2000 system time corrected by the time difference (so they are converted to communication partner time). Of course, in the ideal scenario, the times of the communicating systems are synchronized (e.g. by means of NTP).
One more note on time - the standard does not indicate whether the timestamps are in local time (taking into account daylight saving time) or in UTC. The implementation in the D2000 uses the time set in the station parameters - local (with possible daylight saving time in summer) or UTC (or UTC plus defined offset). Our experience is that it is ideal to use UTC or UTC with a defined offset, because in this case there are no problems with the “jumping” time when changing to DST and back. Not every implementation supports this. We met a specific version of ABB Microscada at a specific customer, which, as an IEC 104 server, set the "SU" (summer time) flag in the timestamp, and thus at the time of the transition from summer to winter time it was not possible to distinguish whether it was the "first" 2ndhour or by "second", as the "SU" flag was set all the time.
ASDU 70 – „end of initialization“
The mentioned ABB Microscada had another unpleasant feature, due to which the parameter "End of initialization" was added to the "IEC 104 Client" protocol. Namely, the ABB Microscada server already accepted clients after the restart, responded to StartDT, but it did not have to be fully initialized yet. It responded to ASDUs 100 and 101 by sending a response, but no data. After a complete initialization, it sent ASDU 70 and expected the client to repeat ASDUs 100 and 101 to obtain the current data image. We have not encountered this behavior on the other 104 servers.
ASDU beyond the standard
Several ASDUs beyond the standard are supported in the IEC 104 protocol. We used "high" ASDU numbers in the implementation.
ASDU 252 – D2000 Unival
If the IEC 104 protocol is used between two D2000 systems, the ASDU 252 allows value transfer with user flags, attributes (limits and process alarms). It can also transfer text, relative and absolute time values. It transmits the analog value as a 64-bit float, so accuracy is not lost and the range is not reduced as with the 32-bit float used by IEC 104.
ASDUs 249-251 – reading of historical data
If two D2000 systems are connected, then the ASDU 250 is used to request historical data for one object for a defined time interval. The data itself is sent as ASDU 251 (32-bit float values) or - if the parameter "D2000 64-bit Historical Values" is set - as ASDU 249 (64-bit float values).
Reading of historical data can be used to fill a hole after a communication failure. The D2000 system, which is an IEC 104 client, requests data for the required period. The IEC 104 server retrieves data from the D2000 archive. A notable thing is the ability to specify (in the configuration of the output I/O tag) an archive object for providing historical data. It is thus possible to provide, for example, minute averages instead of 1-second data when patching holes.
Activation of the reading of historical data is possible manually via the GETOLDVAL command, or by the GETOLDVAL action from a script.
ASDUs 241 and 243 – 64-bit floating-point numbers
For the needs of the joint project of URAP and Ipesoft, data ASDU 241 (64-bit float) and 243 (64-bit float with timestamp) were implemented on the D2000 side as well as on the B&R PLC side used by URAP. They differ from the standard ASDUs 13 and 36 by only 64-bit values instead of 32. These ASDUs were used due to the need to transfer values with a large range and high accuracy from gas converters.
Server and network redundancy
The "IEC 104 client" protocol is supported in the "TCP/IP-TCP" and "TCP/IP-TCP Redundant" lines. On the "TCP / IP-TCP" line, one TCP connection to the IEC 104 server is established at one time. You can enter one or more IP addresses in the line configuration, separated by a comma or semicolon. The D2000 KOM will try to gradually connect to these IP addresses until it successfully establishes a TCP connection and receives a response to the StartDT frame. This configuration can be used e.g. in a situation where we communicate with one server over two redundant networks.
We would use the same configuration when communicating with a redundant system, with only the active IEC 104 server receiving clients.
If it were necessary to communicate with both servers at the same time, we would use the "TCP/IP-TCP Redundant" line. Just as the IP address of the primary device, we would give IPA, the secondary device address would be IPB.
If there were two servers on redundant networks, we would again use the "TCP/IP-TCP Redundant" line. We would configure IPA1, IPA2 as the IP addresses of the primary device, secondary device would have IPB1 and IPB2 addresses.
For this case (redundant servers on redundant networks) there are "Asymmetric Redundancy Mode Periodicity" and "Asymmetric Redundancy Mode Slave Detection" protocol parameters, which are used to use a different network for each TCP connection after failure and subsequent restoration of the functionality of each network connection (due to uniform network load or survival of one connection in the event of another network failure). Thus, if both TCP connections are functional, it is checked with a defined periodicity whether both connections go through the same network (both TCP connections use the same configured IP address, e.g. the first one). If so, one connection will be closed and re-established over another network. Which one? This is determined by the "Asymmetric Redundancy Mode Slave Detection" parameter. Either any or the one that sends the ASDU with the "test" bit set in the Cause of Send (COT) field, or the one that has the lowest bit set to 1 in byte 3 of the control field (which is behavior beyond the scope of the standard). It depends on the IEC 104 server, what form of detection of "passive" or "standby" server it offers. If a redundant D2000 system is an IEC 104 server, using the "Standby Set Test Bit" or "Standby Set Control Field" parameters, it is possible to set both of the above-described ways of distinguishing the passive D2000 KOM process.
What if the D2000 system itself is redundant and therefore has two or more client KOM processes (one active and the other passive)? By default, the TCP connection will be closed if the KOM process becomes passive (for both IEC 104 client and server protocols). The "Standby Keep Open" protocol parameter causes the connection not to be closed. In addition, if the "Standby Write Values" protocol parameter is set, the passive KOM process will also send new values and commands. These parameters allow the D2000 redundancy to be switched "smoothly" at the cost of higher network and server load during normal operation (since the TCP connection will not be closed by the passive D2000 KOM process, nor will Interrogation be opened and sent by the active one).
How to detect a malfunction of one of the routes? In addition to "external" means (pinging IP addresses by the D2000 Server), it is possible to use the FLC and FLD flags in the station value on the "TCP/IP-TCP Redundant" line. These flags are set by the KOM process to indicate the malfunction of the primary or secondary route.
In addition to the "IEC 104 Client" and "IEC 104 Server" protocols, the D2000 system has also implemented the "IEC 104 Sinaut" protocol more than 12 years ago. This protocol takes into account the specifics of the Sinaut Spectrum system. In terms of redundancy, both active and passive KOM processes communicate with both active and passive Sinaut servers over redundant networks at one time (i.e. each KOM process has 4 TCP connections open).
The "IEC 104 Sinaut" protocol does not support all ASDUs and does not have many configuration parameters that are not required for Sinaut.
Other specialties
To speed up the detection of communication path problems, the "IEC 104 Client" protocol has the "Ping Timeout" and "Ping Count" parameters. By setting them, it is possible to achieve that the D2000 KOM process sends ICMP ping packets to configured IP addresses in the background. If there is no "Ping Count" response within the "Ping Timeout" (entered in milliseconds), the TCP connection to this IP address is closed (if it has been established) and the D2000 KOM process tries to reconnect to another IP address according to the configuration lines.
The "Stop Data Confirm Ignored" parameter was implemented in the "IEC 104 client" protocol in 2007 due to a METSO DNA server error. This will send a StopDT confirmation U-frame after the connection has been established, after which the D2000 KOM would close the connection process by default. This way the frame is ignored and communication continues :)
Conclusion
We started implementing the IEC104 protocol in the D2000 system more than 14 years ago (first the client part, later the server part, and finally the Sinaut version). During that time, many parameters were added, reflecting the diversity of communication partners and the situations in which the protocol was used. At present, it is used by many customers in the energy and gas industries, in various production plants, but also to connect customers with partner organizations (and not only in Slovakia). I think that due to its simplicity of implementation, performance, and latency-suppressing features, it will continue to be used to a significant extent, even if it faces competition in the form of ICCP/TASE-2 or OPC UA protocols, which are significantly more difficult to implement but offer possibilities beyond IEC 104 in the field of authentication and encryption - which is becoming more and more important in today's world.
October 20, 2017, Ing. Peter Humaj, www.ipesoft.com