Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

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

AttributeDescriptionExpected valuesMandatory
namethis identifies the protocol stackiec104client, iec104server, tase2client, tase2server, 61850client, 61850server, etc...Yes
versionversion number of the configuration file2 digits x.y => x = major change, y = minor changeYes
redundancy_groupsarray of redundancy groups
Yes
redundancy_groups.connectionsarray of connections of a given redundancy group
Yes
redundancy_groups.connections.srv_ipIP address to remote IEC 104 serverIP addressYes
redundancy_groups.connections.portport number to remote IEC 104 serverdefault = 2404No
redundancy_groups.connections.connestablish connection at startupTRUE, FALSE, default = TRUENo
redundancy_groups.connections.startstart data transfer at startupTRUE, FALSE, default = TRUENo
redundancy_groups.k_valueMaximum number of outstanding (unacknowledged) APDU's at a given timedefault = 12No
redundancy_groups.w_valueAcknowledge the reception latest after this number of APDU'sdefault = 8No
redundancy_groups.t0_timeouttime out of connection establishmentdefault = 30No
redundancy_groups.t1_timeouttime out for send or test APDU'sdefault = 15No
redundancy_groups.t2_timeouttime out for acknowledges in case of no data messages (t2 < t1)default = 10No
redundancy_groups.t3_timeouttime out for sending test framesdefault = 20No
redundancy_groups.rg_namethis identifies the redundancy group
Yes
redundancy_groups.tlsactivation of TLS (see tls configuration chapter for details)TRUE, FALSE, default = FALSENo
orig_addrOriginator Addressdefault = 0No
ca_asdu_sizesize of "Common Address of ASDU"default = 2 (byte)No
ioaddr_sizesize of 'Information Object Address'default = 3 (byte)No
startup_timetime to wait for startup completiondefault = 180 (seconds)No
asdu_size

maximum ASDU size in transmission direction, if set to "0" => maximum possible value is automatically used.

default = 0 (byte)No
gi_timetime to wait for General Interrogation (GI) completiondefault = 0 (seconds)No
gi_cyclesend General Interrogation (GI) cyclically for the specified period of timedefault = 0 (seconds), if 0  => DEACTIVATEDNo
gi_all_casend a separate GI request to every CA; otherwise a broadcast GI request is usedTRUE, FALSE, default = FALSENo
gi_repeat_countrepeat GI for this number of times in case it is incompletedefault = 2No
disc_qualinformation object quality in case of interrupted connectionIV = Invalid, NT = Not Topical, default = NTNo
send_iv_timetime delay before infos are sent as invalid (0 = deactivated)default = 0No
tsivspecifies 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_timeUTC timezone (=TRUE) or local timezone (=FALSE) for time conversionTRUE, FALSE, default = TRUENo
cmd_parallelmaximum number of commands to be executed at in parallel (0 = unlimited)default = 0No
exec_cycl_testexecute cyclical test requests (C_TS_NA_1/C_TS_TA_1) in monitoring direction (=TRUE) or not (=FALSE)TRUE, FALSE, default = FALSENo
reverseallow transmission of information objects in reverse direction (=TRUE) or only in standard direction (=FALSE)TRUE, FALSE, default = FALSENo
time_syncperform time synchronizationdefault = 0 (seconds), if 0  => DEACTIVATEDNo

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":false
      }
   }
}

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 IDType ID with timetagAlternative format type id
M_SP_NA_1M_SP_TA_1,M_SP_TB_1M_PS_NA_1
M_DP_NA_1M_DP_TA_1,M_DP_TB_1M_EP_TA_1,M_EP_TD_1
M_ST_NA_1M_ST_TA_1,M_ST_TB_1
M_BO_NA_1M_BO_TA_1,M_BO_TB_1
M_ME_NA_1M_ME_TA_1,M_ME_TD_1M_ME_ND_1
M_ME_NB_1M_ME_TB_1,M_ME_TE_1
M_ME_NC_1M_ME_TC_1,M_ME_TF_1
M_IT_NA_1M_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.

3 parameters are needed to set up the TLS secured connection:

  • private key file
  • server certificate
  • root certificate (CA)

Fledge's certificate store allows certificates to be stored and used by the south plugins.

{
  "tls_conf:": {
    "private_key": "server-key.pem",
    "server_cert": "server.cer",
    "ca_cert": "root.cer"
  }
}
  • No labels