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

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

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

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

Connection status audits

This plugin will send Fledge audits of type SRVFL containing different messages to notify about changes in the status of the connection.

The connection status will be tracked at two different levels:

Path level: An IEC104 connection has a maximum of two path defined (A and B) and a maximum of two redundancy groups defined (0 and 1), a single connection among all of those is the active one, others are passive.
Global level: The same level as in south_events representing the global state of the connection.

Generated audit messages will have the following pattern based on their level:

Path level: <service_name>-<red_group>-<path_letter>-<status>
Global level : <service_name>-<status>

With:

<service_name>: The name of the service running this plugin (eg: iec104south_s1)
<red_group>: The ID number of the red group (0 or 1).
<path_letter>: The letter of the path (A or B).
<status>: The connection status.

The usage of an ID for the redundancy group and not the name from the protocol_stack configuration is designed to be able to send an initial audit for each possible path and red group at startup or upon reconfigure.

Sending those initial audits would not be possible if the names were being used instead of an ID as the red group names are not predictible.

These ID represent the order of appearance of the red groups in the protocol_stack.transport_layer.redundancy_groups array.

The connection status can take different values based on the level of connection, each value is sent with a given audit severity :

Path level:

Status	Severity	Description

Status	Severity	Description
unused	INFORMATION	The configuration does not include this path
disconnected	FAILURE	The path is not connected
active	SUCCESS	The path is connected and is the active path
passive	SUCCESS	The path is connected and is the passive path

Global level:

Status	Severity	Description

Status	Severity	Description
disconnected	FAILURE	None of the configured path is connected
connected	SUCCESS	At least one of the configured path is connected

These audits are sent :

Whenever the plugin is reconfigured (including at plugin startup)
Whenever the connection state they represent changes

Some audits may be repeated in the same state (in case of reconfiguration or plugin restart for example) but the implementation is designed to minimize the number of audits sent while ensuring that no state change can be missed.

FledgePower

IEC 104 south plugin