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
startup_time	time to wait for startup completion	default = 180 (seconds)	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	default = 0 (seconds)	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 = FALSE	No
gi_repeat_count	repeat GI for this number of times in case it is incomplete	default = 2	No
disc_qual	information object quality in case of interrupted connection	IV = Invalid, NT = Not Topical, default = NT	No
send_iv_time	time delay before infos are sent as invalid (0 = deactivated)	default = 0	No
tsiv	specifies what to do with a time stamp marked as 'invalid'	remove, process, default = remove remove: the time stamp will be removed from the information object process: the time stamp will be processed on regular basis and additionally marked as 'not synchronized'	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 at in parallel (0 = unlimited)	default = 0	No
exec_cycl_test	execute cyclical test requests (C_TS_NA_1/C_TS_TA_1) in monitoring direction (=TRUE) or not (=FALSE)	TRUE, FALSE, default = FALSE	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

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_cycle":0,
         "gi_all_ca":true,
         "time_sync":0
      }
   }
}

IEC 104 datapoint representation

This is the Datapoint representation of an IEC 104 ASDU.

{
    "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"
      }
   ]
}

IEC 104 south plugin