Transcript
GUIDELINE (UNOFFICIAL TRANSLATION) Skapat av (Efternamn, Förnamn, org)
DokumentID
Ev. ärendenummer
Fastställt av
Dokumentdatum
Version
[Fastställt av]
2012-02-29
3.1.2 (unofficial)
[Ärendenummer]
Dokumenttitel
RSMP – Communication protocol - road side equipment 1 Table of contens 1 TABLE OF CONTENS .................................................................................. 1 2 DEFINITIONS ............................................................................................ 3 3 INTRODUCTION ........................................................................................ 5 3.1 BACKGROUND ................................................................................................................ 5 4 PURPOSE ................................................................................................... 7 4.1 IDENTIFIED REQUIREMENTS ........................................................................................... 7 5 APPLICABILITY ......................................................................................... 8 5.1 SCOPE ............................................................................................................................ 8 5.1.1
RESPONSIBILITY ................................................................................................................8
5.2 OBJECT MODEL .............................................................................................................. 8 5.3 TRANSPORT OF DATA ...................................................................................................... 9 5.3.1
Communication establishment ........................................................................................... 9
5.3.2
Communication disruption ................................................................................................. 9
5.3.3
Transport between site and supervision system ............................................................... 9
5.3.4
Transport between sites ...................................................................................................... 9
5.4 BASIC STRUCTURE ........................................................................................................ 10 5.4.1
Alarm messages ..................................................................................................................11
5.4.2
Aggregated status message .............................................................................................. 18
5.4.3
Status Messages ................................................................................................................ 21
5.4.4
Command messages......................................................................................................... 28
5.4.5
Message acknowledgement .............................................................................................. 31
5.4.6
RSMP/SXL Version ........................................................................................................... 34
5.4.7
Watchdog ........................................................................................................................... 36
5.5 USAGE OF JSON .......................................................................................................... 39 5.5.1
Comparison of elements .................................................................................................... 39
5.5.2
Wrapping of packets ........................................................................................................ 40
5.5.3
Alarm messages ................................................................................................................ 41
5.5.4
Aggregated status Message .............................................................................................. 43
5.5.5
Status MessageS ................................................................................................................ 45
5.5.6
Command messages ..........................................................................................................50
5.5.7
Message acknowledgement .............................................................................................. 52
5.5.8
RSMP/SXL Version ........................................................................................................... 53
5.5.9
Watchdog ........................................................................................................................... 54
TDOK 2010:21_Mall Riktlinje v. 1.0
1 (55)
2 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
6 CHANGE LOG ........................................................................................... 55
TDOK 2010:21_Mall Riktlinje v. 1.0
3 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
2 Definitions Term
Meaning
SXL
Signal exchange list
NTS
National Traffic management system. Replaces CTS
Maximo
STA’s support system for maintenance
ITS site
Local roadside equipment. Covers both field level and local level
Site Local roadside equipment Supervision system Object
See ITS equipment See ITS equipment Control and supervision system for regional and/or national level An object is a abstract term which is used in control and supervision systems. An object can have on or more statuses that may change depending on changes of circumstance of the object or control of the object from external source. Communication with the object is made using exchange of signals, e.g. commands, status and alarms. An object may also be equivalent of a physical equipment. E.g. camera, but could also be abstract such as an algorithm. An object is identified using the objects component id. Please note that an object is not necessarily the same thing as an NTS object.
Aggregated object
An aggregated object consists of one or many other objects. E.g. Component group (CG)
Object type
An object type is a classification of objects that controls the properties of all the objects of the same object type. The object type determines how the object is presented in supervision system, how it is grouped and which functional positions, alarm codes, commands
NTS Object
and statuses that exists that object type. Used for objects in NTS All control and supervision related functions in NTS consist of NTS objects. An NTS object can represent on or many objects. An NTS objects is identified in the communication interface using “externalNtsId”. NTS can not use the format used in component-id. An object and NTS object and use the same component-id.
TDOK 2010:21_Mall Riktlinje v. 1.0
4 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
NTS-Object type
A NTS object type is a classification of NTS objects. Determines among other things which functional positions that are possible for the NTS object.
Component
A component is a object or NTS object.
Component-ID
A component is identified using component-id. A component-id identifies components. The format used for the STA’s sites is specified in the STA publication 2007:54 ISSN 1401-9612, e.g. AA+BBCDD=EEEFFGGG.
XML
eXtensible Markup Language
JSON
JavaScript Object Notation
TCP/IP
Transfer Control Protocol/Internet Protocol
W3C
World Wide Web Consortium
DATEX II
European standard for message exchange between traffic system s(www.datex2.eu)
RSMP
Road Side Message Protocol
TDOK 2010:21_Mall Riktlinje v. 1.0
5 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
3 Introduction This document presents a general protocol for communication between supervision systems and equipment, and direct communication between sites. The aim is to offer a standardized protocol that works the same way regardless of supplier or type of equipment.
3.1
Background
Historically, the Swedish Transport Administration has had a regional organization structure which was responsible for the procurement and management of technical systems , including ITS facilities . This has meant that different regions have had different requirements for functionality and interfaces to higher level systems. The Swedish Transport Administration has also been dependent on technology specific and proprietary communication protocols, resulting in limited ability to coordinate the management and operation of various technology areas and regions. The Swedish Transport Administration currently has a national organization for the management of technical facilities and systems. This organization is responsible for creating a uniform structure and set of requirements on the administrations technical systems. This is for: • •
Facilitate the implementation, management and operation of facilities Facilitate supplier market to develop concepts and solutions that work nationally and does not require regional adaptations.
In this way, given the means to achieve a consistent functionality against road users, operations and maintenance, management and control centers. Ultimately, the Swedish Transport Administration will in this way get better effects of investments. In order to create a sustainable system park that is upgradeable and scalable, the following principal system architecture has been developed. The architecture is based on the creation of a number of levels with well-defined interfaces with the overlying and underlying level. In this way, one can introduce new functionality, upgrade or replace a system at each level without affecting other systems or activities.
TDOK 2010:21_Mall Riktlinje v. 1.0
6 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Figure 1. Principal system architecture
TDOK 2010:21_Mall Riktlinje v. 1.0
7 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
4 Purpose The purpose of this protocol is to create a standardized way to communicate between systems at the local level and systems at the regional level regardless of supplier and technology. The goal is to be able to easily add and remove signals in new facilities and applications without having to expand or change the standards and guidelines. This means that the protocol , as opposed to many other standards and protocols do not include detailed information about the signal exchange but is focused on defining the types of signals which are then described construction or items specifically. The goal is that in the long term, based on installed systems and objects, is to be able to produce signal exchange lists of type object that can be reused in new contracts so that alarm messages, commands, etc. have the same names regardless of facility or provider. The purpose of the signal exchange is to provide information relating to, for example, traffic contol managers and administrators . E.g.the information needed to monitor and control the plant, as well as the information that can be used for statistics and analysis of traffic and plant status. For instance, alarms contains sufficient information to be able to create a work order in Maximo which is then sent to the operating contractor, ie. sufficient information about the type of skills and equipment necessary to correct the error. Additional detailed information about an alarm ( e.g. which I / O card has broken, the LED chain that is out of order, etc.) can read on site via vendor-specific web interface or operator panel.
4.1
Identified requirements
In order to provide an information exchange that is not depenent of technology area or vendor specific information - four message types have been identified that cover all types of information that the Swedish Transport Administration needs. The information in each message is dynamic and is defined by facility type or specific facility in a specific signal exchange list (SXL). This list also represents the interface between the supervision system / other facilities and equipment. The four message types are: •
Alarm. System, traffic- or monitoring alarms that require action by the traffic or engineer . Usually from the facility to the monitoring system at onset
•
Aggregated status. An aggregated status that gives an overview picture of the status of the plant. Usually from the facility at the change or when connecting to a main control system
•
Status, status changes , indications and detailed information should be logged or made visible at the supervision level. Sent upon request from the supervision system / other facility or via subscription (either from a change in status or using time intervals)
•
Command. Commands sent from a supervision system or other facility to alter the equipment / object status or control principle
TDOK 2010:21_Mall Riktlinje v. 1.0
8 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
5 Applicability 5.1
Scope
This document is a generic protocol specification for RSMP interface that describes the protocol transfer mechanisms and function. The document is a specification that allows for many use cases within and outside the Swedish Transport Administration. The document is provided for those who need to implement a RSMP interface. 5.1.1
RESPONSIBILITY
The Swedish Transport Administration (STA) is providing this interface specification as information only. The STA is not responsible for any consequences that implementation of the specification can lead to for the supplier or any third party.
5.2
Object model
This protocol usess the Datex II ( datex2.eu ) meta- model for its object model. Meta model consists of a set of rules that describe how classes and objects are defined. The reason why the Datex II metamodel has been adopted is that it will eventually provide the possiblity for this protocol to become an international standard that can later be included with the object model for Datex II. The object model is technology independent, ie can be implemented in various ways such as using ASN.1 , JSON or XML. In Chapter 5.4 all examples is provided in XML format for clarity. But the communication between the facility and supervision systems / other facility uses JSON format. In Chapter 5.5 all message types in both XML and JSON are provided side by side. Objects used for message exchange is Alarm with subclasses Issue, Acknowledge and Suspend. For other objects there are classes AggregatedStatus, StatusRequest, StatusResponse, CommandRequest, CommandResponse, Watchdog, MessageAck, MessageAck, MessageNotAck. For detailed information about how these classes are used, see chapter 5.4 Basic structure .
TDOK 2010:21_Mall Riktlinje v. 1.0
9 (55)
GUIDELINE DokumentID
5.3
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Transport of data
The message flow is different between different types of messages. Some messages are event driven and sent without a request (push) , while others are interaction driven , ie . they sent in response to a request from a host system or other system ( client- server). To ensure that messages reach their destinations a message acknowledgment is sent for all messages This gives the application a simple way to follow up on the message exchange. To communicate between equpiments and supervisions systems a pure TCP connection is used (TCP / IP) , and the data sent is based on the JSON format , ie formatted text.
5.3.1
COMMUNICATION ESTABLISHMENT
When establishing communication, messages are sent in the following order. 1. 2. 3. 4.
RSMP / SXL version (according to chapter 5.4.6 ) Watchdog (according to chapter 5.4.7 ) Aggregated status (according to chapter 5.4.2) All active and blocked alarm is sent (according to chapter 5.4.1 ). The alarms that are not sent will be interpreted as non- active and non-blocked by the supervision system. 5. Any remaining messages in the equipment's outgoing communication buffer is sent 6. Any previous subscriptions to status messages are re-established ; because they automatically cease at communication disruption
5.3.2
COMMUNICATION DISRUPTION
In the event of a communications failure the outgoing messages are stored in the equipment's communication buffer. Once communication is restored all the messages in the communications buffer are sent. Any subscriptions to status messages ceases if the communication failure occurs. In the event of communications failure or power outage outgoing communication buffer of equipment not empty , this does not apply watchdog messages. The internal communication buffer of the device must at a minimum be sized to be able to store 1000 messages. At full communication buffer the FIFO principle applies.
5.3.3
TRANSPORT BETWEEN SITE AND SUPERVISION SYSTEM
Supervision system acts a socket server and waits for the site to connect. If the communication were to fail it is the site’s responsibility to reconnect. 5.3.4
TRANSPORT BETWEEN SITES
One site acts as socket server and waits for the other site to connect. If the communication were to fail it is the connecting site’s responsibility to reconnect.
TDOK 2010:21_Mall Riktlinje v. 1.0
10 (55)
GUIDELINE DokumentID
5.4
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Basic structure
Unicode (ISO 10646) and UTF-8 is used for all messages. All messages are based on the structure presented below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure.
{E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 AB+84001=860VA001 XML code 1: Basic structure for a XML message. In this example the message type is an alarm message
The following table is describing the variable content of the message: Element messageId
Value (GUID)
ntsObjectId (valbar)
(Defined in SXL)
externalNtsId (valbar)
(Defined in SXL)
Description Message identity. Generated as a GUID (Globally unique identifier) in the equipment that sent the message. Only version 4 of Leach-Salz UUID is used. Component-id for the NTS object which the message is referring to. Identity for the NTS objects in communication between NTS and other systems. The format is 5 integers (Mentioned in SL31 Object-Identity) Defined in cooperation with representatives from NTS. Unique for the site.
componentId
(defined SXL)
Component id for the object which the message is refereeing to
TDOK 2010:21_Mall Riktlinje v. 1.0
11 (55)
GUIDELINE DokumentID
5.4.1
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
ALARM MESSAGES
An alarm message is sent to the supervision system when: •
An alarm becomes active / inactive
•
An alarm is acknowledged
•
An alarm is being suspended / un-suspended
An acknowlegment of an alarm does not cause a single alarm event to be acknowledged but all alarm events for the specific object with the associated alarm code id. This approach simplifies both in implementation but also in handling - if many alarms occur on the same equipment with short time intervals. A suspsend of an alarm causes all alarms from the specific object with the associated alarm code id to be suspended. Alarm messages are event driven and sent to the supervision system when the alarm occurs. Acknowledgement of alarms and alarm suspend messages are interaction driven.
5.4.1.1 5.4.1.1.1
Message structure Structure for an alarm message
An alarm message has the same structure when it’s send regardless whether or not it is a new alarm, being acknowledged or being suspended, with the exception of “alarmSpecialisation”. The following table describes the differences: Element and value
Meaing An alarm becomes active/in-active An alarm is acknowledged Suspension of an alarm is being activated/deactivated
An alarm message has the structure according to the example below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure. {E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 AB+84001=860VA001 A001 Lampfel på lykta 1 (röd) 3143 notAcknowledged
TDOK 2010:21_Mall Riktlinje v. 1.0
12 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
active notSuspended 2009-10-01T11:59:31.571Z T 2 signalgrupp 1 färg röd XML code 2: An alarm message which contains a lamp error at the site AB+84001=860VA001.
The following table is describing the variable content of the message: 5.4.1.1.1.1
Basic (xsi:type = Alarm)
Element alarmCodeId
Value (Defined in SXL)
externalAlarmCodeId (optional)
(Manufacturer specific)
externalNtsAlarmCodeId (optional)
(Defined in SXL)
Description Alarm code id. Determined in the signal exchange list (SXL). The examples in this document are defined according to the following format: Ayyy, where yyy is a unique number. Manufacturer specific alarm code and alarm description Manufacturer, model, alarm code och additional alarm description Alarm code in order to identify alarm type during communication with NTS and other system. (Benämns i SL31 Alarm-Code)
5.4.1.1.1.2
Alarm status
Element acknowledegeState alarmState suspendState timestamp
Value acknowledged notAcknowledged inactive active suspended notSuspended (timestamp)
Description The alarm is acknowledged The alarm is not acknowledged The alarm is inactive The alarm is active The alarm is suspended The alarm is not suspended Timestamp for when the alarm either occurs, gets acknowledged or gets suspended. See the contents of alarmSpecialisation to determine which type timetamp is used. The timestamp uses the W3C XML dateTime definition with a 3 decimal places. All timestamps
TDOK 2010:21_Mall Riktlinje v. 1.0
13 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
are set at the local level (and not in the supervision system) when the alarm occurs (and not when the message is sent). All timestamps uses UTC. category
T D
A character, either ”T” or ”D”. An alarm is belongs to one of these categories: T.
Traffic alarm
D.
Technical alarm
Traffic alarm: Traffic alarms indicate events in the traffic related functions or the technical processes that effects traffic. A couple of examples from a tunnel: • Stopped vehicle • Fire alarm • Error which affects message to motorists • High level of CO2 in traffic room • Etc.
description (only in SXL, never actually sent)
(Defined in SXL)
priority
[0-9]
Technical alarm: Technical alarms are alarms that do not directly affect the traffic. One example of a technical alarm is when an impulse fan stops working. Description of the alarm. Only defined in SXL and is never actually sent. (The format of the description is free of choice but has the following requirements: • The text is unique for the object type • The text is defined in cooperation with the Purchaser before use) The priority of the message The following values are defined: 1 = alarm that requires immediate action. 2 = alarm that does not require immediate action, but action is planned during the next work shift. 3 = alarm that will be corrected during the next planned maintenance shift.
5.4.1.1.1.3 Return values Element name type (Only is SXL, not actually sent)
Value (Defined in SXL) (Defined in SXL)
Description Unique reference of the value The data type of the value. Defined in the SXLbut is not actually sent General definition: raw Value is expressed as raw value scale Value is expressed as scale value unit Value is expressed as units string Text information integer Numerical value (16-bit signed integer), [-32768 – 32767] long Numerical value (32-bit signed long)
TDOK 2010:21_Mall Riktlinje v. 1.0
14 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
real
unit (Only is SXL, not actually sent) value
5.4.1.1.2
(Defined in SXL)
(Defined in SXL)
Float (64-bit double precision floating point) boolean Boolean data type ordinal Represents index base64 Binary data expressed in base64 format According to RFC-4648 The unit of the value. Defined in SXL but are not actually sent Value
Structure for alarm acknowledgement message
An alarm acknowledgement message has the structure according to the example below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure.
{E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 AB+84001=860VA001 A001 Larmfel på lykta 1 (röd) 3143 XML code 3: An alarm acknowledgement message that acknowledges an alarm
The following table is describing the variable content of the message: 5.4.1.1.2.1 Basic (xsi:type = Alarm) Element
Value
Description
alarmCodeId
(Defined in SXL)
externalAlarmCodeId (optional)
(Manufacturer specific)
externalNtsAlarmCodeId (optional)
(Defined in SXL)
Alarm code id. Determined in the signal exchange list (SXL). The examples in this document are defined according to the following format: Ayyy, where yyy is a unique number. Manufacturer specific alarm code and alarm description Manufacturer, model, alarm code och additional alarm description Alarm code in order to identify alarm type during communication with NTS and other system. (Benämns i SL31 Alarm-Code)
TDOK 2010:21_Mall Riktlinje v. 1.0
15 (55)
GUIDELINE DokumentID
5.4.1.1.2.2
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Alarm acknowledgement (xsi:type = Acknowledge)
(no content) 5.4.1.1.3
Structure for alarm suspend message
An alarm suspend message has the structure according to the example below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure.
{E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 AB+84001=860VA001 A001 Larmfel på lykta 1 (röd) 3143 suspend XML code 4: An alarm suspend message that suspends an alarm
The following table is describing the variable content of the message: 5.4.1.1.3.1
Basic (xsi:type = Alarm)
Element
Value
Description
alarmCodeId
(Defined in SXL)
externalAlarmCodeId (optional)
(Manufacturer specific)
externalNtsAlarmCodeId (optional)
(Defined in SXL)
Alarm code id. Determined by the signal exchange list (SXL). The examples in this document are defined according to the following format: Ayyy, where yyy is a unique number. Manufacturer specific alarm code and alarm description Manufacturer, model, alarm code och additional alarm description Alarm code in order to identify alarm type during communication with NTS and other system. (Benämns i SL31 Alarm-Code)
5.4.1.1.3.2
Alarm suspend (xsi:type = Suspend)
TDOK 2010:21_Mall Riktlinje v. 1.0
16 (55)
GUIDELINE DokumentID
Element suspendAction
5.4.1.2
Value suspend resume
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Description Activate suspend of an alarm Deactivate a suspend of an alarm
Message exchange between site and supervision system
Message acknowledgement (see chapter 5.4.5) is implicit in the following figure. 5.4.1.2.1
An alarm is active/inactive
1
Överordnat system
Larmmeddelande
Vägsidesutrustning
1
5.4.1.2.2
An alarm message is sent to supervision system with the status of the alarm (the alarm is active/inactive)
An alarm is acknowledged at the supervision system
TDOK 2010:21_Mall Riktlinje v. 1.0
17 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Överordnat system
1
2
Kvitteringsmeddelande
Larmmeddelande
Vägsidesutrustning
1
An alarm acknowledgement message is sent to the site
2
An alarm message is sent to the supervision system (that the alarm is acknowledged)
5.4.1.2.3
An alarm is acknowledged at the site
1
Överordnat system
Larmmeddelande
Vägsidesutrustning
1
5.4.1.2.4
An alarm message is being sent to the supervision system with the status of the alarm (that the alarm is acknowledged)
An alarm is suspended/unsuspended from the supervision system
TDOK 2010:21_Mall Riktlinje v. 1.0
18 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Överordnat system
2
1
Blockeringsmeddelande (av/på) Larmmeddelande
Vägsidesutrustning
1
An alarm suspend message is being sent to the site
2
An alarm message is sent to the supervision system with the status of the alarm (that the suspension is activated/deactivated)
5.4.1.2.5
An alarm is suspended/unsuspended from the site
1
Överordnat system
Larmmeddelande
Vägsidesutrustning
1
5.4.2
An alarm message is sent to the supervision system with the status of the alarm (that suspension is activated/deactivated)
AGGREGATED STATUS MESSAGE
This type of message is sent to the supervision system to inform about the status of the site. Aggregated status messages are interaction driven and are sent when the state bits, functional position or functional status is changed at the site.
TDOK 2010:21_Mall Riktlinje v. 1.0
19 (55)
GUIDELINE DokumentID
5.4.2.1
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Message structure
An aggregated status message has the structure according to the example below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure.
{E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 F+40100=416CG100 2009-10-02T14:34:34.345Z Trafikstyrning Automatiskt nedsatt hastighet 1 false 2 true 3 true 4 false 5 false 6 false 7 false 8 false
TDOK 2010:21_Mall Riktlinje v. 1.0
20 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
XML code 5: A aggregated status message that informs that the site has change status bits, functional position and/or functional status.
The following tables are describing the variable content of the message: 5.4.2.1.1
Basic (aggregatedStatus)
Element aggstatusTimeStamp
5.4.2.1.2
Value (tidsstämpel)
Description The timestamp uses the W3C XML dateTime definition with a 3 decimal places. All timestamps are set at the local level (and not in the supervision system) when the event occurs (and not when the message is sent). All timestamps uses UTC.
Aggregated status (aggregatedStatusSpecialisation)
Element functionalPosition
Value (Defined in SXL)
Description Functional position
functionalState (optional)
(Defined in SXL)
Functional state
state
(see below)
Status bits (see below)
5.4.2.1.3
Status bits (state)
The status bits are a set of 8 bits that describes the state of the site for NTS. Every bit can either be true or false Element state name
Value true|false [1-8]
Description Status bit Bit nr (integer between 1 and 8)
The principle of aggregating of statuses for each bit is defined by the associated comments in the signal exchange list (SXL). A generic description of each bit is presented in the table below
Element state
Bit (name) 1
2 3 4
Description
Status
The site is out of operation by the local control system or maintenance personnel working. Supervision system has no contact with the site The site has an alarm that requires immediate action. (Priority 1) The site has an alarm that does not require immediate action but is planned during the
Light blue – local control
Purple – Communication disruption Red – High priority alarm Yellow – Medium priority alarm
TDOK 2010:21_Mall Riktlinje v. 1.0
21 (55)
GUIDELINE DokumentID
5
6 7 8
5.4.2.2
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
next work shift (Priority 2) The site has an alarm that will corrected at the next planned maintenance shift (Priority 3) The site is connected and is currently in use. The site is connected but is currently not is use The site is not connected to the supervision system.
Blue – Low priority alarm
Green - Normal operation – In use Dark grey - rest Light grey – Not Connected
Message exchange between site and supervision system
Message acknowledgement (see chapter 5.4.5) is implicit in the following figure.
1
Överordnat system
”Aggregerad status-‐”meddelande
Anläggning
(Functional state, functional position or status bits changes at the site) 1
5.4.3
An aggregated status message is sent to the supervision system.
STATUS MESSAGES
The status message is a type of message that is sent to the supervision system or other equipment with the status of one or more requested objects. The status message can both be interaction driven or event driver and can be sent during the following prerequisites: • When status is requested from the supervision system or other equipment. • According to subscription – either by using a fixed time interval or when the status change.
TDOK 2010:21_Mall Riktlinje v. 1.0
22 (55)
GUIDELINE DokumentID
5.4.3.1
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Message structure
5.4.3.1.1
Structure for a request of a status of one or several objects
A status request message has the structure according to the example below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure.
{E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 AB+84001=860VA001 S003 speed S003 occupancy XML code 6: A status request message that requests the current value of the requested object
The following tables are describing the variable content of the message: 5.4.3.1.1.1
Basic (xsi:type = StatusRequest)
Element statusCodeId
Värde (Defined in SXL)
name
(Defined in SXL)
5.4.3.1.2
Beskrivning Status code id. Determined by the signal exchange list (SXL). The examples in this document are defined according to the following format: syyy, where yyy is a unique number. Unique reference
Structure for a message with status of one or several objects
A message with status of one or several objects has the structure according to the example below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure.
TDOK 2010:21_Mall Riktlinje v. 1.0
23 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
{E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 AB+84001=860VA001 2009-10-02T14:34:34.345Z S003 speed 70 recent S003 occupancy 14 recent XML code 7: An answer to a status request that contains the current values
The following table is describing the variable content of the message: 5.4.3.1.2.1
Basic (xsi:type = StatusResponse)
Element statusTimeStamp
Value (timestamp)
Description The timestamp uses the W3C XML dateTime definition with a 3 decimal places. All timestamps are set at the local level (and not in the supervision system) when the alarm occurs (and not when the message is sent). All timestamps uses UTC.
description (Only is SXL, not actually sent)
(Defined in SXL)
Descriptionfor the status request. Defined in the SXL but is not actually sent.
5.4.3.1.2.2
Return values (returnvalue)
Element statusCodeId
Value (Defined in SXL)
name type (Only is SXL, not actually sent)
(Defined in SXL) (Defined in SXL)
Description Status code id. Determined by the signal exchange list (SXL). The examples in this document are defined according to the following format: Syyy, where yyy is a unique number. Unique reference of the value The data type of the value. Defined in the SXL but is not actually sent General definition: raw Value is expressed as raw value scale Value is expressed as scale value unit Value is expressed as units string Text information
TDOK 2010:21_Mall Riktlinje v. 1.0
24 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
integer
Numerical value (16-bit signed integer), [-32768 – 32767] long Numerical value (32-bit signed long) real Float (64-bit double precision floating point) boolean Boolean data type ordinal Represents index base64 Binary data expressed in base64 format According to RFC-4648 The unit of the value. Defined in SXL but are not actually sent
unit (Only is SXL, not actually sent) status
(Defined in SXL)
(Defined in SXL)
Value
ageState
recent
The value is up to date
old
The value is not up to date
unknown
The value is unknown and no subscription will be performed.
5.4.3.1.3
Structure for a status subscription request message on one or several objects
A message with the request of subscription to a status has the structure according to the example below. The message is used for constructing a list of subscriptions of statuses, digital and analogue values and events that are desirable to send to supervision system, e.g. temperature, wind speed, power consumption, manual control. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure.
{E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 AB+84001=860VA001 S003 speed 10 S003 occupancy 10
TDOK 2010:21_Mall Riktlinje v. 1.0
25 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
XML code 8: A message with the request of subscription of status for the requested object
The following table is describing the variable content of the message: 5.4.3.1.3.1
Basic (xsi:type = StatusRequest)
Element updateRate
5.4.3.1.4
Value (textfält)
Description Determines the interval of which the message should be sent. Defined in seconds with decimals, e.g. ”2.5” for 2.5 seconds. Dot (.) is used as decimal point. If “0” means that the value should be sent when changed.
Structure for a response message with answer to a request for status subscription for one or several objects
A response message with answer to a request for status subscription has the structure according to the example below. This response is always sent immediately after request for subscription regardless if the value recently changed or as an effect of the interval for the subscription. The reason for sending the response immediately is because subscriptions usually are established shortly after RSMP connection establishment and the supervision system needs to update with the current statuses and events. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure.
{E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 AB+84001=860VA001 2009-10-02T14:34:34.345Z S003 speed 70 recent S003 occupancy 14 recent
TDOK 2010:21_Mall Riktlinje v. 1.0
26 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
XML code 9: A message with answer to a request for subscription of status on one or several objects
The allowed content is described in chapter 0 and 5.4.3.1.2.2. 5.4.3.1.5
Structure for a status unsubscription message on one or several objects
A message with the request of unsubscription to a status has the structure according to the example below. The request unsubscribes on one or several objects. No particular answer is send for this request, other than the usual message acknowledgement. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure. {E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 AB+84001=860VA001 S003 speed S003 occupancy XML code 10: A message with the request of unsubscription of status for the requested object
The allowed content is described in chapter 0.
5.4.3.2
Message exchange between site and supervision system/other equipment - request
Message acknowledgement (see chapter 5.4.5) is implicit in the following figure.
TDOK 2010:21_Mall Riktlinje v. 1.0
27 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
2
1
Överordnat system eller annan anläggning
Anläggning
Förfrågan om status på angivet objekt Meddelande med status på angivet objekt
1 2
5.4.3.3
Request of status for an object Response with status of an object
Message exchange between site and supervision system/other equipment – subscription
Message acknowledgement (see chapter 5.4.5) is implicit in the following figure.
TDOK 2010:21_Mall Riktlinje v. 1.0
28 (55)
GUIDELINE DokumentID
1
5.4.4
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Update with status of an object
COMMAND MESSAGES
Command messages are used to give order to do something at the site. The site responds with a command acknowledgement. Command messages are interaction driven and are sent when command are requested on any given object by the supervision system or other equipment 5.4.4.1 5.4.4.1.1
Message structure Structure of a command message request
A command request message has the structure according to the example below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure. {E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 AB+84001=860VA001 M002 1 setValue Auto
TDOK 2010:21_Mall Riktlinje v. 1.0
29 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
XML code 11: A command request message with the intent to change a value of the requested object
The following table is describing the variable content of the message: 5.4.4.1.1.1
Values to send with the command (arguments)
Element commandCodeId
Value (Defined in SXL)
name command type (Only is SXL, not actually sent)
(Defined in SXL) (Defined in SXL) (Defined in SXL)
unit (Only is SXL, not actually sent) value
5.4.4.1.2
(Defined in SXL)
(Defined in SXL)
Description Command code id. Determined in the signal exchange list (SXL). The examples in this document are defined according to the following format: Myyy, where yyy is a unique number. Unique reference Command The data type of the value. Defined in the SXL but is not actually sent General definition: raw Value is expressed as raw value scale Value is expressed as scale value unit Value is expressed as units string Text information integer Numerical value (16-bit signed integer), [-32768 – 32767] long Numerical value (32-bit signed long) real Float (64-bit double precision floating point) boolean Boolean data type ordinal Represents index base64 Binary data expressed in base64 format According to RFC-4648 The unit of the value. Defined in SXL but are not actually sent Value
Structure of command response message
A command response message has the structure according to the example below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure. {E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416CG100 23055 AB+84001=860VA001
TDOK 2010:21_Mall Riktlinje v. 1.0
30 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
2009-10-02T14:34:34.345Z M002 recent 1 Auto XML code 12: An command response message that informs about the updated value of the requested object.
The following table is describing the variable content of the message: 5.4.4.1.2.1
Basic (xsi:type = CommandResponse)
Element commandTimeStamp
5.4.4.1.2.2
Value (tidsstämpel)
Description The timestamp uses the W3C XML dateTime definition with a 3 decimal places. All timestamps are set at the local level (and not in the supervision system) when the alarm occurs (and not when the message is sent). All timestamps uses UTC..
Return values (returnvalue)
Element commandCodeId
Value (Defined in SXL)
ageState
recent old unknown (Defined in SXL) (Defined in SXL)
name type (Only is SXL, not actually sent)
unit (Only is SXL, not
(Defined in SXL)
Description Command code id. Determined in the signal exchange list (SXL). The examples in this document are defined according to the following format: Myyy, where yyy is a unique number. The value is up to date The value is not up to date The value is unknown Unique reference of the value The data type of the value. Defined in the SXL but is not actually sent General definition: raw Value is expressed as raw value scale Value is expressed as scale value unit Value is expressed as units string Text information integer Numerical value (16-bit signed integer), [-32768 – 32767] long Numerical value (32-bit signed long) real Float (64-bit double precision floating point) boolean Boolean data type ordinal Represents index base64 Binary data expressed in base64 format According to RFC-4648 The unit of the value. Defined in SXL but are not actually sent
TDOK 2010:21_Mall Riktlinje v. 1.0
31 (55)
GUIDELINE DokumentID
actually sent) value
5.4.4.2
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
(Defined in SXL)
Value
Message exchange between site and supervision system/other equipment
Message acknowledgement (see chapter 5.4.5) is implicit in the following figure.
2
1
Överordnat system eller annan anläggning
Anläggning
Styrning av angivet objekt Meddelande med svar på styrning för angivet objekt
1 2
5.4.5
Command request for an object Command response of an object
MESSAGE ACKNOWLEDGEMENT
Message acknowledgement is sent as an initial answer to all other messages. This type of message should not be mixed up with alarm acknowledgement, which has a different function. The purpose of message acknowledgement is to detect communication disruptions, function as an acknowledgment that the message has reached its destination and to verify that the message was understood. There are two types of message acknowledgement – Message acknowledgment which confirms that the message was understood and Message not acknowledged which indicates that the message was not understood. The acknowledgement messages are interaction driven and are sent when any other type message are received.
TDOK 2010:21_Mall Riktlinje v. 1.0
32 (55)
GUIDELINE DokumentID
5.4.5.1
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Message structure – Message acknowledgement
An acknowledgement message has the structure according to the example below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure.
{E4FSD010-C336-41ac-BD58-5C80A72C7092} XML code 13: An acknowledgement message that confirms that the previous message was received and understood
The following table is describing the variable content of the message: 5.4.5.1.1
Basic (xsi:type = MessageAck)
Element originalMessageId
5.4.5.2
Value (GUID)
Description Message identity. Generated as a GUID (Globally unique identifier) in the equipment that sent the message. Only version 4 of Leach-Salz UUID is used. This message identity is used in order to inform about which message is being acknowledged.
Message structure – Message not acknowledged
A not acknowledgement message has the structure according to the example below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure. {E4FSD010-C336-41ac-BD58-5C80A72C7092} alarmCode: A054 does not exist XML code 14: An acknowledgement message that confirms that the previous message was received but not understood
The following table is describing the variable content of the message: 5.4.5.2.1
Basic (xsi:type = MessageNotAck)
Element originalMessageId
Value (GUID)
Description Message identity. Generated as a GUID (Globally unique identifier) in the equipment that sent the message. Only version 4 of Leach-Salz UUID is
TDOK 2010:21_Mall Riktlinje v. 1.0
33 (55)
GUIDELINE DokumentID
reason
(optional)
5.4.5.3
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
used. This message identity is used in order to inform about which message is being acknowledged. Error message where all relevant information about the nature of the error can be provided.
Message exchange between site and supervision system/other equipment
5.4.5.3.1
Supervision system send initial message
Överordnat system eller annan anläggning
2
1
Meddelande från överordnat system eller annan anläggning Kvittensmeddelande
Anläggning
1 2 5.4.5.3.2
A message is sent from supervision system or other equipment The site responds with an message acknowledgement Site sends initial message
TDOK 2010:21_Mall Riktlinje v. 1.0
34 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Överordnat system eller annan anläggning
2
1
Meddelande från anläggning Kvittensmeddelande
Anläggning
1 2
5.4.6
A message is sent from the site The supervision system or other equipment responds with an message acknowledgement
RSMP/SXL VERSION
Version of RSMP and revision of SXL are always sent directly after establishing communication. Both communicating systems send this as their first message and waits for message response until any other messages are sent. Information regarding all supported RSMP versions should be included in the version message. The version message should be implemented in such a way that is should be possible to add additional tags/variables (e.g. date) without affecting existing implementations. If any discrepancies with the version numbers are detected between the two communicating systems this should be set using a MessageNotAck. The communication is terminated after that and an internal alarm is activated in both communicating system. If both communicating systems support several RSMP versions it is always the latest version that should be used. 5.4.6.1
Message structure
A version message has the structure according to the example below. In the example below the system has support for RSMP version 1.0, 1.2 and 1.3. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure.
{E68A0010-C336-41ac-BD58-5C80A72C7092} F+40100=416
TDOK 2010:21_Mall Riktlinje v. 1.0
35 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
1.0 1.2 1.3 1.3 XML cod 15: A version message that informs which versions of RSMP that is supported, and which revision of SXL is used.
The following table is describing the variable content of the message: 5.4.6.1.1
Basic (xsi:type = Version)
Element siteId
Value (Defined in SXL)
rsmpVersion
(Defined in the guidline) (Defined in SXL)
sxlRevision
5.4.6.2
Description Site identity. Used in order to refer to a “logical” name of site. At the STA, the following format could be used: -‐ Using site id from the STAs component id standard VV:publ 2007:54 ISSN 14019612. E.g. ”40100”. -‐ It is also possible to use the complete component id (VV:publ 2007:54 ISSN 1401-9612) of the grouped object in the site if the above site id part of the component id is insufficient in order to create an unique identity. All the site id that are used are sent in the message Version of RSMP. E.g. ”1.0”, ”1.1” eller ”1.3” Revision of SXL. E.g ”1.3”
Message exchange between site and supervision system/other equipment
Message acknowledgement (see chapter 5.4.5) is implicit in the following figure. 5.4.6.2.1
The site sends a version message
TDOK 2010:21_Mall Riktlinje v. 1.0
36 (55)
GUIDELINE DokumentID
1
5.4.7
Version
[Ärendenummer]
3.1.2 (unofficial)
Version message is sent from the site
5.4.6.2.2
1
Ev. ärendenummer
Supervision system/other equipment sends version message
Version message is send from supervision system/other equipment
WATCHDOG
The primary purpose of watchdog messages is to ensure that the communication remains established and to detect any communication disruptions between site and supervision system. For any subsustem alarms are used instead. The secondary purpose of watchdog messages is to provide a timestamp that can be used for simple time synchronization. Unless other time synchronization method is used or other reasons apply, the site should synchronize its clock using the timestamp from watchdog messages – both at communication establishment and then at least once every 24 hours. Watchdog messages are sent in both directions, both from the site and from the supervision system. At initial communication establishment (after version message) the watchdog message should be sent.
5.4.7.1
Message structure
A watchdog message has the structure according to the example below. Bold text is content that are variable, e.g. message information. Non-bold text is part of the message basic structure.
{E68A0010-C336-41ac-BD58-5C80A72C7092} 2009-10-02T14:34:34.341Z XML code 16: A watchdog message
TDOK 2010:21_Mall Riktlinje v. 1.0
37 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
The following table is describing the variable content of the message: 5.4.7.1.1
Basic (xsi:type = Watchdog)
Element watchdogTimestamp
5.4.7.2
Value (tidsstämpel)
Description The timestamp uses the W3C XML dateTime definition with a 3 decimal places. All timestamps are set at the local level (and not in the supervision system) when the alarm occurs (and not when the message is sent). All timestamps uses UTC.
Message exchange between site and supervision system/other equipment
Message acknowledgement (see chapter 5.4.5) is implicit in the following figure.
5.4.7.2.1
1 5.4.7.2.2
Site sends watchdog message
Watchdog message is sent from site Supervision system/other equipment sends watchdog message
TDOK 2010:21_Mall Riktlinje v. 1.0
38 (55)
GUIDELINE DokumentID
1
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Watchdog message is sent from supervision system/other equipment
TDOK 2010:21_Mall Riktlinje v. 1.0
39 (55)
GUIDELINE DokumentID
5.5 5.5.1
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Usage of JSON COMPARISON OF ELEMENTS
The following table present a comparison of the names used in XML verses JSON. Please note that the JSON elements are formatted as JSON string elements and not JSON number or JSON boolean. Element in XML acknowledgeState ageState (statusmeddelande) ageState (styrningsmeddelande) aggregatedStatusSpecialisation aggstatusTimeStamp alarmCodeId alarmSpecialisation alarmState timestamp arguments category command commandCodeId commandTimeStamp componentId externalAlarmCodeId externalEventCodeId externalNtsAlarmCodeId externalNtsId functionalPosition functionalState message xsi:type messageId name originalMessageId priority reason returnvalue returnvalues (alarm) returnvalues (statusresponse) rsmpVersion rsmpVersions roadSideMessage ntsObjectId sideIds siteId source state status statuses statusCodeId
Element in JSON ack age q aSS aSTS aCId aSp aS ts arg cat cO cCI cTS cId xACId xECId xNACId xNId fP fS type mId n oMId pri rea rv rvs sS vers RSMP mType: rSMsg ntsOId siteId sId source se s sS sCI
TDOK 2010:21_Mall Riktlinje v. 1.0
40 (55)
GUIDELINE DokumentID
statusTimestamp suspendState sxlRevision type unit updateRate watchdogTimestamp
5.5.2
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
sTs sS SXL t u uRt wTs
WRAPPING OF PACKETS
Both Json and XML packets can be tricky to decode unless one always know that the packet is complete. Json lacks an end tag and an XML end tag may be embedded in the text source. In order to reliably detect the end of a packet one must therefore make an own parser of perform tricks in the code, which is not very good. In both Json and XML there could exist tab characters (0x09), CR (0x0d) and LF (0x0a). Are the packets serialized using .NET those special characters does not exist. Therefore it is a good practice to use formfeed (0x0c), e.g. ’\f’ in C/C++/C#. Formfeed cannot be embedded in the packets because those are encoded in UTF-8 so the parser only needs to search the incoming buffer for 0x0c and deal with every packet. Example: {"mHdr":{"mType":"rSMsg","type":"Alarm","mId":"d2e9a9a1-a082-44f5-b4e0-6c9233 a204c","ts":"2009-1002T14:34:34.345Z"},"oId":{"sId":"AB+81102=881CG001","xNId ":"","cId":"AB+81102=881DG002"},"aOId":{"aCId":"A052","xACId":"052","xNACId": "052","aSp":"Acknowledge"}}<0x0c> JSON code 1: Example of wrapping of a packet
Character between <> is the bytes binary content in hex (ASCII koden), ex <0x0c> is ASCII code 12, e.g. FF (formfeed).
TDOK 2010:21_Mall Riktlinje v. 1.0
41 (55)
GUIDELINE DokumentID
5.5.3 5.5.3.1
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
ALARM MESSAGES Structure for an alarm message
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
{E68A0010-C336-41ac-BD58-5C80A72C7092}
"cId": "AB+84001=860VA001",
F+40100=416CG100
"aCId": "A001",
23055
"xACId": "Lampfel på lykta 1 (röd)",
AB+84001=860VA001
"xNACId": "3143",
A001
"aSp": "Issue",
Lampfel på lykta 1 (röd)
"ack": "notAcknowledged",
3143
"aS": "active",
"sS": "notSuspended",
notAcknowledged
"aTs": "2009-10-01T11:59:31.571Z",
active
"cat": "D",
notSuspended
"pri": "2"
2009-10-01T11:59:31.571Z
"rvs": [
D
{
2
"n": "signalgrupp",
"v": "1"
},
signalgrupp
{
1
"n": färg",
färg
"v": "röd" }] }
röd
XML/JSON code 1: Comparison of example of alarm message XML/JSON
TDOK 2010:21_Mall Riktlinje v. 1.0
42 (55)
GUIDELINE DokumentID
5.5.3.2
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Structure for alarm acknowledgement message
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
{E68A0010-C336-41ac-BD58-
"cId": "AB+84001=860VA001",
5C80A72C7092}
"aCId": "A001",
F+40100=416CG100
"xACId": "Larmfel på lykta 1 (röd)",
23055
"xNACId": "3143",
AB+84001=860VA001
"aSp": "acknowledge",
A001
"ack": "Acknowledged",
Larmfel på lykta 1 (röd)
"aS": "active",
3143
"sS": "notSuspended",
"aTs": "2009-10-01T11:59:31.571Z",
"cat": "b",
"pri": "2" "rvs": [ { "n": "signalgrupp", "v": "1" }, { "n": färg", "v": "röd" }] }
XML/JSON code 2: Comparison of example of alarm acknowledgement XML/JSON
TDOK 2010:21_Mall Riktlinje v. 1.0
43 (55)
GUIDELINE DokumentID
5.5.3.3
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Structure for alarm suspend message
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
{E68A0010-C336-41ac-BD58-
"cId": "AB+84001=860VA001",
5C80A72C7092}
"aCId": "A001",
F+40100=416CG100
"xACId": "Larmfel på lykta 1 (röd)",
23055
"xNACId": "3143",
AB+84001=860VA001 A001
"aSp": "suspend" }
Larmfel på lykta 1 (röd) 3143 suspend
XML/JSON code 3: Comparison of example of alarm suspend message XML/JSON
5.5.4 5.5.4.1
AGGREGATED STATUS MESSAGE Message structure
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
TDOK 2010:21_Mall Riktlinje v. 1.0
44 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
XML
JSON {
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
{E68A0010-C336-41ac-BD58-
"cId": "F+40100=416CG100",
5C80A72C7092}
"aSTS": "2009-10-02T14:34:34.345Z",
F+40100=416CG100
"fP": "Trafikstyrning",
23055
"fS": "Automatiskt nedsatt hastighet",
F+40100=416CG100 2009-1002T14:34:34.345Z
"se": ["false", "true", "true", "false", "false", "false", "false", "false"] }
Trafikstyrning Automatiskt nedsatt hastighet 1 false 2 true 3 true 4 false 5 false 6 false 7 false 8 false
TDOK 2010:21_Mall Riktlinje v. 1.0
45 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
XML/JSON-‐kod 4: Exempel på motsvarighet av ”aggregerad status”-‐ meddelande XML/JSON
5.5.5 5.5.5.1
STATUS MESSAGES Structure for a request of a status of one or several objects
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
"xNId": "23055",
"cId": "AB+84001=860VA001",
{E68A0010-C336-41ac-BD58-
"sS":[
5C80A72C7092}
{"sCI": "S003"
F+40100=416CG100
”n":"speed"},
23055
{"sCI": "S003", "n":"occupancy"}
AB+84001=860VA001
S003 speed S003 occupancy
] }
XML/JSON code 5: Comparison of example of status request message XML/JSON
5.5.5.2
Structure for a message with status of one or several objects
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
TDOK 2010:21_Mall Riktlinje v. 1.0
46 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
XML
JSON {
"xNId": "23055",
"cId": "AB+84001=860VA001",
{E68A0010-C336-41ac-BD58-
"sTs": "2009-10-02T14:34:34.345Z",
5C80A72C7092}
"sS":[
F+40100=416CG100
{"sCI": "S003",
23055
"n":"1",
AB+84001=860VA001
"s": "70",
2009-10-02T14:34:34.345Z
"q": "recent"},
{"sCI": "S007",
"n":"1",
S003
"s": "0",
recent
"q": "unknown"}
1
]
70
}
S007 unknown 1 0
XML/JSON code 6: Comparison of example of status response message XML/JSON
5.5.5.3
Structure for a status subscription request message on one or several objects
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
"xNId": "23055",
{E68A0010-C336-41ac-BD58-
"cId": "AB+84001=860VA001", "sS":[
TDOK 2010:21_Mall Riktlinje v. 1.0
47 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
5C80A72C7092}
{"sCI": "S003",
F+40100=416CG100
"n": "speed",
23055
"uRt": "10"},
AB+84001=860VA001
{"sCI": "S003",
"n":" occupancy ",
"uRt": "10"}
S003 speed
] }
10 S003 occupancy 10
XML/JSON code 7: Comparison of example of status subscription message XML/JSON
TDOK 2010:21_Mall Riktlinje v. 1.0
48 (55)
GUIDELINE DokumentID
5.5.5.4
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Structure for a response message with answer to a request for status subscription for one or several objects
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
"xNId": "23055",
"cId": "AB+84001=860VA001",
{E68A0010-C336-41ac-BD58-
"sTs": "2009-10-02T14:34:34.345Z",
5C80A72C7092}
"sS":[
F+40100=416CG100
{"sCI": "S003",
23055
"n":"1",
AB+84001=860VA001
"s": "70",
2009-10-02T14:34:34.345Z
"q": "recent"},
{"sCI": "S007",
"n":"1",
S003
"s": "0",
recent
"q": "unknown"}
1 70
] }
S007 unknown 1 0
XML/JSON code 8: Comparison of example of answer of status subscription message XML/JSON
5.5.5.5
Structure for a status unsubscription message on one or several objects
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
TDOK 2010:21_Mall Riktlinje v. 1.0
49 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
XML
JSON {
"xNId": "23055",
"cId": "AB+84001=860VA001",
{E68A0010-C336-41ac-BD58-
"sS":[
5C80A72C7092}
{"sCI": "S003",
F+40100=416CG100
"n":"speed"},
23055
{"sCI": "S003",
AB+84001=860VA001
"n":" occupancy”}
] }
S003 speed S003 occupancy
XML/JSON code 9: Comparison of example of answer of status unsubscription message XML/JSON
TDOK 2010:21_Mall Riktlinje v. 1.0
50 (55)
GUIDELINE DokumentID
5.5.6 5.5.6.1
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
COMMAND MESSAGES Structure of a command message request
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
"xNId": "23055",
"cId": "AB+84001=860VA001",
{E68A0010-C336-41ac-BD58-
"arg": [
5C80A72C7092}
{
F+40100=416CG100
"cCI": "M003",
23055
"n": "1",
AB+84001=860VA001
"cO": "setValue",
"v": "Auto"
M002
}] }
1 setValue Auto
XML/JSON code 10: Comparison of example of command request message XML/JSON
TDOK 2010:21_Mall Riktlinje v. 1.0
51 (55)
GUIDELINE DokumentID
5.5.6.2
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
Structure of command response message
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
"xNId": "23055",
"cId": "AB+84001=860VA001",
{E68A0010-C336-41ac-BD58-
"cTS": "2009-10-02T14:34:34.345Z",
5C80A72C7092}
"rvs": [
F+40100=416CG100
{
23055
"cCI": "M002",
AB+84001=860VA001
"age": "recent",
2009-10-
"n": "1",
02T14:34:34.345Z
"v": "70"
}] }
M002 recent 1 Auto
XML/JSON code 11: Comparison of example of command response message XML/JSON
TDOK 2010:21_Mall Riktlinje v. 1.0
52 (55)
GUIDELINE DokumentID
5.5.7 5.5.7.1
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
MESSAGE ACKNOWLEDGEMENT Message structure – Message acknowledgement
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
{E4FSD010-C336-41ac-BD585C80A72C7092}
XML/JSON code 12: Comparison of example of message acknowledgement XML/JSON
5.5.7.2
Message structure – Message not acknowledged
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
"rea": "alarmCode: A054 does not exist" }
{E4FSD010-C336-41ac-BD585C80A72C7092} alarmCode: A054 does not exist
XML/JSON code 13: Comparison of example of message not acknowledged XML/JSON
TDOK 2010:21_Mall Riktlinje v. 1.0
53 (55)
GUIDELINE DokumentID
5.5.8 5.5.8.1
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
RSMP/SXL VERSION Message structure
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
"mId": "E68A0010-C336-41ac-BD585C80A72C7092",
{E68A0010-C336-41ac-BD58-5C80A72C7092}
"siteId":[
{"sId":"F+40100=416CG100"}],
F+40100=416CG100
"RSMP":[
{"vers":"1.0"},
{"vers":"1.2"},
1.0
{"vers":"1.3"}],
1.2 1.3
"SXL":"1.3" }
1.3
XML/JSON code 14: Comparison of example of version message XML/JSON
TDOK 2010:21_Mall Riktlinje v. 1.0
54 (55)
GUIDELINE DokumentID
5.5.9 5.5.9.1
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
WATCHDOG Message structure
The example below compares the message structure between the XML and JSON formats. Please note that some lines may be wrapped.
XML
JSON {
"wTs": "2009-10-02T14:34:34.345Z", }
{E68A0010-C336-41ac-BD585C80A72C7092} 2009-1002T14:34:34.345Z
XML/JSON code 16: Comparison of watchdog messages XML/JSON
TDOK 2010:21_Mall Riktlinje v. 1.0
55 (55)
GUIDELINE DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
6 Change log Version
Date
Change
Name (initals)
1.0
2011-05-20
DO
3.0 3.1.1 3.1.2
2011-11-04 2011-12-23 2012-02-29
Protocol clarified and watchdog revised The protocol is revised Minor revision Minor revision
DO DO DO
TDOK 2010:21_Mall Riktlinje v. 1.0
