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

Compare with Current View Page History

« Previous Version 28 Next »

HNZ connexion initialization

When the HNZ south plugin establishes a new connection wit ha HNZ device, it will automatically send the following messages to the device:

  • A set date and a set time: Those two messages will synchronize the date and time of the device with the one from the south plugin machine.
  • A CG request: This message will request all TS to be sent by the device in CG format (equivalent of GI request of iec104).

HNZ Protocol stack configuration

The HNZ 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.

The present specification corresponds to the HNZ B1/TR mode working on a TCP/IP connection.

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
connectionsarray of connections
Yes
connections.srv_ipIP address to remote HNZ serverIP addressYes
connections.port

port number to remote HNZ server

default = 6001No
remote_station_addrremote server station address6 bitsYes
Inacc_timeouttimeout before declaring the remote server unreachable (DF.GLOB.TS)default = 180 (seconds)No
max_sarmmax number of SARM messages before handing over to the passive path (A/B)default = 30No
repeat_path_Amax number of authorized repeats for path Adefault = 3No
repeat_path_Bmax number of authorized repeats for path Bdefault = 3No
repeat_timeouttime allowed for the receiver to acknowledge a frame, after this time, the sender repeats the frame.default = 3000No
anticipation_rationumber of frames allowed to be received without acknowledgement default = 3No
test_msg_sendtest message code in sending directiondefault = 1304No
test_msg_receivetest message code in receiving directiondefault = 1304No
gi_schedulescheduled time for General Interrogation sendingdefault = 99:99 (disabled)No
gi_repeat_countrepeat GI for this number of times in case it is incompletedefault = 3No
gi_timetime to wait for General Interrogation (GI) completiondefault = 255 (seconds)No
c_ack_timetime to wait before receving a acknowledgement for a control commanddefault = 10 (seconds)

Configuration JSON structure

{
   "protocol_stack":{
      "name":"hnzclient",
      "version":"1.0",
      "transport_layer":{
         "connections":[
            {
               "srv_ip":"192.168.0.10",
               "port":6001
            },
            {
               "srv_ip":"192.168.0.11",
               "port":6002
            }
         ]
      },
      "application_layer":{
         "remote_station_addr":12,
         "inacc_timeout":180,
         "max_sarm":30,
         "repeat_path_A":3,
         "repeat_path_B":3,
         "repeat_timeout":3000,
         "anticipation_ratio":3,
         "test_msg_send":"1304",
         "test_msg_receive":"1304",
         "gi_schedule":"99:99",
         "gi_repeat_count":3,
         "gi_time":255,
         "c_ack_time":10
      }
   }
}

HNZ datapoint representation

This is the Datapoint representation of an HNZ message.

AttributeDescriptionExpected valuesMandatory
do_typemessage typeTS, TMA, TMN, ACK_TC, ACK_TVCYES
do_stationstation address
YES
do_addressmessage address
YES
do_valuevalue

TM (do_an = TMA): [-127..127]

TM (do_an = TM8): [0..255]

TM (do_an = TM16): [-32768..32767]

TM: [0..1]

TC: [1..2] (01b = off, 10b = on)

TVC: [-255..255]

YES
do_validvalidityvalid = 0 or invalid = 1YES
do_cgTS sourceCG = 1 or CE = 0TS only
do_tstimestampepoch timestamp in millisecondsTS CE only
do_ts_ivtimestamp invalidvalid = 0 or invalid = 1TS CE only
do_ts_closs of chronologylost = 0 else = 1TS CE only
do_ts_sts not synchronizedsynchronized = 0 else = 1TS CE only

Example for a TSCE:

{
    "data_object":{
        "do_type":"TS",
        "do_station":12,
        "do_addr":325,
        "do_value":1,
        "do_valid":0,
        "do_cg":0,
        "do_ts":1685019425432,
        "do_ts_iv":0,
        "do_ts_c":0,
        "do_ts_s":0
    }
 }

Example for a TSCG:

{
    "data_object":{
        "do_type":"TS",
        "do_station":12,
        "do_addr":325,
        "do_value":1,
        "do_valid":0,
        "do_cg":1
    }
 }

Example for a TMA:

{
    "data_object":{
        "do_type":"TMA",
        "do_station":12,
        "do_address":71,
        "do_value":-15,
        "do_valid":0
    }
 }

Example for a TC ACK:

{
    "data_object":{
        "do_type":"ACK_TC",
        "do_station":12,
        "do_address":71,
        "do_value":1,
        "do_valid":0
     }
 }

Example for a TVC ACK:

{
    "data_object":{
        "do_type":"ACK_TVC",
        "do_station":12,
        "do_address":31,
        "do_value":42
        "do_valid":0
     }
 }

NB: if an attribute is not required, then it is not put in the output data object, which means that the output object structure always fits the protocol model object type.

HNZ command representation

This is the command representation of an HNZ message.

The current implementation does not use a json structure, so the order of parameters is mandatory.

OrderAttributeDescriptionExpected valuesMandatory
0co_typemessage typeTC, TVCYES
1co_addressmessage address
YES
2co_valuevalue
YES

The processing of FLEDGE commands should evolve. Below is an example of JSON format :

Example for a TC:

{
    "command_object":{
       "co_type":"TC",
       "co_address":325,
       "co_value":1
     }
 }

Example for a TVC:

{
    "command_object":{
       "co_type":"TVC",
       "co_address":31,
       "co_value":1
     }
 }

NB: if an attribute is not required, then it is not put in the output data object, which means that the output object structure always fits the protocol model object type.

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.

  • No labels