Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

IEC 104 Protocol stack configuration

...

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 = FALSENo
redundancy_groups.k_valueMaximum number of outstanding (unacknowledged) APDU's at a given timedefault = 12, range : 1 to 32767No
redundancy_groups.w_valueAcknowledge the reception latest after this number of APDU'sdefault = 8, range : 1 to 32767No
redundancy_groups.t0_timeouttime out of connection establishmentdefault = 30 seconds, range : 1 to 255No
redundancy_groups.t1_timeouttime out for send or test APDU'sdefault = 15 seconds, range : 1 to 255No
redundancy_groups.t2_timeouttime out for acknowledges in case of no data messages (t2 < t1)default = 10 seconds, range : 1 to 255No
redundancy_groups.t3_timeouttime out for sending test framesdefault = 20 seconds, range : 1 to 172800No
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), enum: 1 or 2No
ioaddr_sizesize of 'Information Object Address'default = 3 (byte), enum: 1, 2 or 3No
asdu_size

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

default = 0 (byte), range : 0 to 255No
gi_timetime to wait for General Interrogation (GI) completion (time between each consecutive step of the GI fail handling process)default = 60 (seconds), minimum: 1No
gi_cyclesend General Interrogation (GI) cyclically for the specified period of time, if 0  => DEACTIVATEDdefault = 0 (seconds), minimum: 0No
gi_all_casend a separate GI request to every CA; otherwise a broadcast GI request is usedTRUE, FALSE, default = TRUENo
utc_timeUTC timezone (=TRUE) or local timezone (=FALSE) for time conversionTRUE, FALSE, default = TRUENo
cmd_parallelmaximum number of commands to be executed in parallel (0 = unlimited)default = 0No
cmd_exec_timeoutmaximum time to wait for command execution (ACT-CON/ACT-TERM) before the command is considered faileddefault = 1000 (milliseconds), minimum: 1No
reverseallow transmission of information objects in reverse direction (=TRUE) or only in standard direction (=FALSE)TRUE, FALSE, default = FALSENo
time_syncperform time synchronization cyclically for the specified period of time, if 0  => DEACTIVATEDdefault = 0 (seconds), minimum: 0No
south_monitoringconnection 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

NB: Parameter marked in italic are not yet implemented.

...

south_monitoring.cnx_loss_status_idid name (label) in the exchanged data conf of the connexion loss datapoint to be senddefault = "CONN_LOST"

NB: Parameter marked in italic are not yet implemented.

Configuration JSON structure

Code Block
languagejspy
{
   "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.

Code Block
languagejs
{
    "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.

...

languagejs

...

AttributeDescriptionExpected valuesMandatory
do_type

Yes
do_ca

Yes
do_oa

Yes
do_cot
See Cause of TransmissionYes
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_ivInvalid

[0..1] (Valid = 0, Invalid = 1)

No
do_quality_blBlocked [0..1] (not blocked = 0, blocked = 1)No
do_quality_ovOverflow [0..1] (normal = 0, overflow = 1)No
do_quality_sbSubstituted [0..1] (not substituted = 0, substituted = 1)No
do_quality_ntNon topical [0..1] (topical = 0, not topical = 1)No
do_ts

No
do_ts_iv

No
do_ts_su

No
do_ts_sub

No


Code Block
languagepy
{
    "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.

Parameters are needed to set up the TLS secured connection:

AttributeDescriptionExpected valuesMandatory
private_keyclient private keyvalid private keyYES
own_certclient certificatevalid certificateYES
ca_certsallows to specify the ca certificates if not included in the owner certificatelist of valid certificatesNO
remote_certsallows to specify the server certificates, so if specified, only these certificates are acceptedlist of valid certificatesNO

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

Code Block
languagepy
{
   "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.
Info

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:
StatusSeverityDescription
unusedINFORMATIONThe configuration does not include this path
disconnectedFAILUREThe path is not connected
activeSUCCESSThe path is connected and is the active path
passiveSUCCESSThe path is connected and is the passive path
  • Global level:
StatusSeverityDescription
disconnectedFAILURENone of the configured path is connected
connectedSUCCESSAt 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.