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

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.

{
    "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:

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:

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 connection status can take different values based on the level of connection, each value is sent with a given audit severity :

• Path level:

• Global level:

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.