IEC 104 Protocol stack configuration
The IEC 104 protocol stack configuration specifies communication parameters and is a collection of entries containing information about OSI Transport and OSI Application layers objects.
Each entry is comprised of attributes that describe the object. All the configuration data are structured using JSON.
Each entry shall be mapped with the corresponding configuration function in the chosen implementation protocol library.
Attributes definition
Attribute | Description | Expected values | Mandatory |
---|---|---|---|
name | this identifies the protocol stack | iec104client, iec104server, tase2client, tase2server, 61850client, 61850server, etc... | Yes |
version | version number of the configuration file | 2 digits x.y => x = major change, y = minor change | Yes |
redundancy_groups | array of redundancy groups | Yes | |
redundancy_groups.connections | array of connections of a given redundancy group | Yes | |
redundancy_groups.connections.srv_ip | IP address to remote IEC 104 server | IP address | Yes |
redundancy_groups.connections.port | port number to remote IEC 104 server | default = 2404 | No |
redundancy_groups.connections.conn | establish connection at startup | TRUE, FALSE, default = TRUE | No |
redundancy_groups.connections.start | start data transfer at startup | TRUE, FALSE, default = FALSE | No |
redundancy_groups.k_value | Maximum number of outstanding (unacknowledged) APDU's at a given time | default = 12, range : 1 to 32767 | No |
redundancy_groups.w_value | Acknowledge the reception latest after this number of APDU's | default = 8, range : 1 to 32767 | No |
redundancy_groups.t0_timeout | time out of connection establishment | default = 30 seconds, range : 1 to 255 | No |
redundancy_groups.t1_timeout | time out for send or test APDU's | default = 15 seconds, range : 1 to 255 | No |
redundancy_groups.t2_timeout | time out for acknowledges in case of no data messages (t2 < t1) | default = 10 seconds, range : 1 to 255 | No |
redundancy_groups.t3_timeout | time out for sending test frames | default = 20 seconds, range : 1 to 172800 | No |
redundancy_groups.rg_name | this identifies the redundancy group | Yes | |
redundancy_groups.tls | activation of TLS (see tls configuration chapter for details) | TRUE, FALSE, default = FALSE | No |
orig_addr | Originator Address | default = 0 | No |
ca_asdu_size | size of "Common Address of ASDU" | default = 2 (byte), enum: 1 or 2 | No |
ioaddr_size | size of 'Information Object Address' | default = 3 (byte), enum: 1, 2 or 3 | No |
asdu_size | maximum ASDU size in transmission direction, if set to "0" => maximum possible value is automatically used. | default = 0 (byte), range : 0 to 255 | No |
gi_time | time to wait for General Interrogation (GI) completion (time between each consecutive step of the GI fail handling process) | default = 60 (seconds), minimum: 1 | No |
gi_cycle | send General Interrogation (GI) cyclically for the specified period of time, if 0 => DEACTIVATED | default = 0 (seconds), minimum: 0 | No |
gi_all_ca | send a separate GI request to every CA; otherwise a broadcast GI request is used | TRUE, FALSE, default = TRUE | No |
utc_time | UTC timezone (=TRUE) or local timezone (=FALSE) for time conversion | TRUE, FALSE, default = TRUE | No |
cmd_parallel | maximum number of commands to be executed in parallel (0 = unlimited) | default = 0 | No |
cmd_exec_timeout | maximum time to wait for command execution (ACT-CON/ACT-TERM) before the command is considered failed | default = 1000 (milliseconds), minimum: 1 | No |
reverse | allow transmission of information objects in reverse direction (=TRUE) or only in standard direction (=FALSE) | TRUE, FALSE, default = FALSE | No |
time_sync | perform time synchronization cyclically for the specified period of time, if 0 => DEACTIVATED | default = 0 (seconds), minimum: 0 | No |
south_monitoring | connection loss and gi failure handling feature | Yes | |
south_monitoring.asset | asset name used to send the connection and gi status information to the north | default = "CONSTAT-1" | No |
south_monitoring.cnx_loss_status_id | id name (label) in the exchanged data conf of the connexion loss datapoint to be send | default = "CONN_LOST" |
NB: Parameter marked in italic are not yet implemented.
Configuration JSON structure
{ "protocol_stack":{ "name":"iec104client", "version":"1.0", "transport_layer":{ "redundancy_groups":[ { "connections":[ { "srv_ip":"192.168.0.10", "port":2404, "conn":true, "start":true }, { "srv_ip":"192.168.0.11", "port":2404, "conn":true, "start":false } ], "rg_name":"red-group-1", "tls":false, "k_value":12, "w_value":8, "t0_timeout":10, "t1_timeout":15, "t2_timeout":10, "t3_timeout":20 }, { "connections":[ { "srv_ip":"192.168.0.12", "port":2404, "conn":false, "start":false }, { "srv_ip":"192.168.0.13", "port":2404, "conn":false, "start":false } ], "rg_name":"red-group-2", "tls":false, "k_value":12, "w_value":8, "t0_timeout":10, "t1_timeout":15, "t2_timeout":10, "t3_timeout":20 } ] }, "application_layer":{ "orig_addr":0, "ca_asdu_size":2, "ioaddr_size":3, "asdu_size":0, "gi_time":60, "gi_cycle":0, "gi_all_ca":true, "cmd_parallel":0, "cmd_exec_timeout":1000, "time_sync":0 }, "south_monitoring":{ "asset":"CONSTAT-1", "cnx_loss_status_id":"CONN_LOST" } } }
IEC 104 datapoint representation
This is the Datapoint representation of an IEC 104 ASDU.
Attribute | Description | Expected values | Mandatory |
---|---|---|---|
do_type | Yes | ||
do_ca | Yes | ||
do_oa | Yes | ||
do_cot | See Cause of Transmission | Yes | |
do_test | [0..1] (default = 0, test data object = 1) | Yes | |
do_negative | Yes | ||
do_ioa | Yes | ||
do_value | SPI : [0..1] DPI : [0..3] (M_DP) VTI : [-64..63] BSI : [0..232-1] NOR : [-1..1-2-15] AJU : [-215..215-1] FLO : IEE 32 bits ST : [0..216-1] BCR : [-231..231-1] ES : [0..3] SPE : [0..63] OCI : [0..15] | No | |
do_quality_iv | Invalid | [0..1] (Valid = 0, Invalid = 1) | No |
do_quality_bl | Blocked | [0..1] (not blocked = 0, blocked = 1) | No |
do_quality_ov | Overflow | [0..1] (normal = 0, overflow = 1) | No |
do_quality_sb | Substituted | [0..1] (not substituted = 0, substituted = 1) | No |
do_quality_nt | Non topical | [0..1] (topical = 0, not topical = 1) | No |
do_ts | No | ||
do_ts_iv | No | ||
do_ts_su | No | ||
do_ts_sub | No |
{ "data_object":{ "do_type":"M_SP_TB_1", "do_ca":18325, "do_oa":0, "do_cot":3, "do_test":false, "do_negative":false, "do_ioa":6468178, "do_value":1, "do_quality_iv":true, "do_quality_bl":false, "do_quality_ov":false, "do_quality_sb":false, "do_quality_nt":false, "do_ts":1653484330239, "do_ts_iv":true, "do_ts_su":false, "do_ts_sub":false } }
Multiple type ids for IEC 104 ASDUs in the monitor direction
As stated in the IEC 104 60870-5-101:2003 standard document §7.2.4 COMMON ADDRESS OF ASDUs: "The information object address may be specified independently from the ASDU (type identification) which transmits the particular information object. Information objects may be transmitted with the same information object addresses using different ASDUs, for example, as a single-point information with or without time tag."
Based on Table 15 – ASDUs in the monitor direction which may transmit objects with equal information object addresses, the following rules shall be implemented:
Any check against type ids should be considering the following combinations table:
Type ID | Type ID with timetag | Alternative format type id |
M_SP_NA_1 | M_SP_TA_1,M_SP_TB_1 | M_PS_NA_1 |
M_DP_NA_1 | M_DP_TA_1,M_DP_TB_1 | M_EP_TA_1,M_EP_TD_1 |
M_ST_NA_1 | M_ST_TA_1,M_ST_TB_1 | |
M_BO_NA_1 | M_BO_TA_1,M_BO_TB_1 | |
M_ME_NA_1 | M_ME_TA_1,M_ME_TD_1 | M_ME_ND_1 |
M_ME_NB_1 | M_ME_TB_1,M_ME_TE_1 | |
M_ME_NC_1 | M_ME_TC_1,M_ME_TF_1 | |
M_IT_NA_1 | M_IT_TA_1,M_IT_TB_1 |
Example: any transmitted ASDU with type id M_SP_* type id is considered as valid if the exchange data configuration of a given datapoint specifies one the type id: M_SP_NA_1, M_SP_TA_1, M_SP_TB_1 and M_PS_NA_1
Path exploration
In redundant network configuration or generally in cases where several communication paths exist between one client and one server, the path checking exploration mechanism allows the client to try all the paths one by one without making any difference between them. The client uses the first available path. On disconnection this procedure starts again from the beginning.
TLS configuration
The CS 104 standard can also be used with TLS to realize secure and authenticated connections.
Parameters are needed to set up the TLS secured connection:
Attribute | Description | Expected values | Mandatory |
---|---|---|---|
private_key | client private key | valid private key | YES |
own_cert | client certificate | valid certificate | YES |
ca_certs | allows to specify the ca certificates if not included in the owner certificate | list of valid certificates | NO |
remote_certs | allows to specify the server certificates, so if specified, only these certificates are accepted | list of valid certificates | NO |
Fledge's certificate store allows certificates to be stored and used by the south plugins.
{ "private_key":"iec104_client.key", "own_cert":"iec104_client.cer", "ca_certs":[ { "cert_file":"iec104_ca.cer" }, { "cert_file":"iec104_ca2.cer" } ], "remote_certs":[ { "cert_file":"iec104_server.cer" } ] }