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
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 |
connections | array of connections | Yes | |
connections.srv_ip | IP address to remote IEC 104 server | IP address | Yes |
connections.port | port number to remote IEC 104 server | default = 6001 | No |
remote_station_addr | remote server station address | 6 bits | Yes |
Inacc_timeout | timeout before declaring the remote server unreachable (DF.GLOB.TS) | default = 180 (seconds) | No |
max_sarm | max number of SARM messages before handing over to the passive path (A/B) | default = 30 | No |
repeat_path_A | max number of authorized repeats for path A | default = 3 | No |
repeat_path_B | max number of authorized repeats for path B | default = 3 | No |
repeat_timeout | time allowed for the receiver to acknowledge a frame, after this time, the sender repeats the frame. | default = 3000 | No |
anticipation_ratio | number of frames allowed to be received without acknowledgement | default = 3 | No |
test_msg_send | test message code in sending direction | default = 1304 | No |
test_msg_receive | test message code in receiving direction | default = 1304 | No |
gi_schedule | scheduled time for General Interrogation sending | default = 99:99 (disabled) | No |
gi_repeat_count | repeat GI for this number of times in case it is incomplete | default = 3 | No |
gi_time | time to wait for General Interrogation (GI) completion | default = 255 (seconds) | No |
c_ack_time | time to wait before receving a acknowledgement for a control command | default = 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":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.
Attribute | Description | Expected values | Mandatory |
---|---|---|---|
do_type | message type | TSCE, TSCG, TMA, TMN, ACK_TC, ACK_TVC | YES |
do_station | station address | YES | |
do_address | message address | YES | |
do_value | value | YES | |
do_valid | validity | valid = 0 or invalid = 1 | YES |
do_ts | time code | 10 ms fraction in the 10 min modulo | YES |
do_ts_iv | timestamp invalid | valid = 0 or invalid = 1 | YES |
do_ts_c | loss of chronology | lost = 0 else = 1 | YES |
do_ts_s | ts not synchronized | synchronized = 0 else = 1 | YES |
Example for a TSCE:
{ "data_object":{ "do_type":"TSCE", "do_station":12, "do_addr":325, "do_value":1, "do_valid":1, "do_ts":80, "do_ts_iv":0, "do_ts_c":0, "do_ts_s":0 } }
Example for a TMA:
{ "data_object":{ "do_type":"TMA", "do_station":12, "do_address":71, "do_value":-15, "do_valid":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.
HNZ command representation
This is the command representation of an HNZ message.
Attribute | Description | Expected values | Mandatory |
---|---|---|---|
co_type | message type | TC, TVC | YES |
co_address | message address | YES | |
co_value | value | YES | |
co_val_coding | coding of value | 0 or 1 | YES |
Example for a TC:
{ "command_object":{ "co_type":"TC", "co_address":325, "co_value":1 } }
Example for a TVC:
{ "command_object":{ "co_type":"TC", "co_address":49, "co_value":1, "co_val_coding":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.
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.