1. technology and computing
2. internet technology
3. email

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.
<?xml version="1.0" encoding="UTF-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="Alarm">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>AB+84001=860VA001</componentId>
</message>
</roadSideMessage>
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
<alarmSpecialisation xsi:type=”Issue”>
<alarmSpecialisation xsi:type=”Acknowledge”>
<alarmSpecialisation xsi:type=”Suspend”>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="Alarm">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>AB+84001=860VA001</componentId>
<alarmCodeId>A001</alarmCodeId>
<externalAlarmCodeId>Lampfel på lykta 1 (röd)</externalAlarmCodeId>
<externalNtsAlarmCodeId>3143</externalNtsAlarmCodeId>
<alarmSpecialisation xsi:type="Issue">
<acknowledgeState>notAcknowledged</acknowledgeState>
TDOK 2010:21_Mall Riktlinje v. 1.0
12 (55)
GUIDELINE
DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
<alarmState>active</alarmState>
<suspendState>notSuspended</suspendState>
<timestamp>2009-10-01T11:59:31.571Z</timestamp>
<category>T</category>
<priority>2</priority>
<returnvalues>
<returnvalue>
<name>signalgrupp</name>
<value>1</value>
</returnvalue>
<returnvalue>
<name>färg</name>
<value>röd</value>
</returnvalue>
</returnvalues>
</alarmSpecialisation>
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="Alarm">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>AB+84001=860VA001</componentId>
<alarmCodeId>A001</alarmCodeId>
<externalAlarmCodeId>Larmfel på lykta 1 (röd)</externalAlarmCodeId>
<externalNtsAlarmCodeId>3143</externalNtsAlarmCodeId>
<alarmSpecialisation xsi:type="Acknowledge" />
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="Alarm">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>AB+84001=860VA001</componentId>
<alarmCodeId>A001</alarmCodeId>
<externalAlarmCodeId>Larmfel på lykta 1 (röd)</externalAlarmCodeId>
<externalNtsAlarmCodeId>3143</externalNtsAlarmCodeId>
<alarmSpecialisation xsi:type="Suspend">
<suspendAction>suspend</suspendAction>
</alarmSpecialisation>
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="AggregatedStatus">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>F+40100=416CG100</componentId>
<aggstatusTimeStamp>2009-10-02T14:34:34.345Z</aggstatusTimeStamp>
<aggregatedStatusSpecialisation>
<functionalPosition>Trafikstyrning</functionalPosition>
<functionalState>Automatiskt nedsatt hastighet</functionalState>
<state>
<name>1</name>
<state>false</state>
</state>
<state>
<name>2</name>
<state>true</state>
</state>
<state>
<name>3</name>
<state>true</state>
</state>
<state>
<name>4</name>
<state>false</state>
</state>
<state>
<name>5</name>
<state>false</state>
</state>
<state>
<name>6</name>
<state>false</state>
</state>
<state>
<name>7</name>
<state>false</state>
</state>
<state>
<name>8</name>
<state>false</state>
</state>
TDOK 2010:21_Mall Riktlinje v. 1.0
20 (55)
GUIDELINE
DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
</aggregatedStatusSpecialisation>
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="StatusRequest">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>AB+84001=860VA001</componentId>
<statuses>
<status>
<statusCodeId>S003</statusCodeId>
<name>speed</name>
</status>
<status>
<statusCodeId>S003</statusCodeId>
<name>occupancy</name>
</status>
</statuses>
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="StatusResponse">
TDOK 2010:21_Mall Riktlinje v. 1.0
23 (55)
GUIDELINE
DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>AB+84001=860VA001</componentId>
<statusTimeStamp>2009-10-02T14:34:34.345Z</statusTimeStamp>
<returnvalues>
<returnvalue>
<statusCodeId>S003</statusCodeId>
<name>speed</name>
<status>70</status>
<ageState>recent</ageState>
</returnvalue>
<returnvalue>
<statusCodeId>S003</statusCodeId>
<name>occupancy</name>
<status>14</status>
<ageState>recent</ageState>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="StatusSubscribe">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>AB+84001=860VA001</componentId>
<statuses>
<status>
<statusCodeId>S003</statusCodeId>
<name>speed</name>
<updateRate>10</updateRate>
</status>
<status>
<statusCodeId>S003</statusCodeId>
<name>occupancy</name>
<updateRate>10</updateRate>
</status>
</statuses>
TDOK 2010:21_Mall Riktlinje v. 1.0
25 (55)
GUIDELINE
DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="StatusUpdate">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>AB+84001=860VA001</componentId>
<statusTimeStamp>2009-10-02T14:34:34.345Z</statusTimeStamp>
<returnvalues>
<returnvalue>
<statusCodeId>S003</statusCodeId>
<name>speed</name>
<status>70</status>
<ageState>recent</ageState>
</returnvalue>
<returnvalue>
<statusCodeId>S003</statusCodeId>
<name>occupancy</name>
<status>14</status>
<ageState>recent</ageState>
</returnvalue>
</returnvalues>
TDOK 2010:21_Mall Riktlinje v. 1.0
26 (55)
GUIDELINE
DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="StatusUnSubscribe">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>AB+84001=860VA001</componentId>
<statuses>
<status>
<statusCodeId>S003</statusCodeId>
<name>speed</name>
</status>
<status>
<statusCodeId>S003</statusCodeId>
<name>occupancy</name>
</status>
</statuses>
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="CommandRequest">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>AB+84001=860VA001</componentId>
<arguments>
<argument>
<commandCodeId>M002</commandCodeId>
<name>1</name>
<command>setValue</command>
<value>Auto</value>
TDOK 2010:21_Mall Riktlinje v. 1.0
29 (55)
GUIDELINE
DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
</argument>
</arguments>
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="CommandResponse">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<ntsObjectId>F+40100=416CG100</ntsObjectId>
<externalNtsId>23055</externalNtsId>
<componentId>AB+84001=860VA001</componentId>
TDOK 2010:21_Mall Riktlinje v. 1.0
30 (55)
GUIDELINE
DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
<commandTimeStamp>2009-10-02T14:34:34.345Z</commandTimeStamp>
<returnvalues>
<returnvalue>
<commandCodeId>M002</commandCodeId>
<ageState>recent</ageState>
<name>1</name>
<value>Auto</value>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="MessageAck">
<originalMessageId>{E4FSD010-C336-41ac-BD58-5C80A72C7092}</originalMessageId>
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="MessageNotAck">
<originalMessageId>{E4FSD010-C336-41ac-BD58-5C80A72C7092}</originalMessageId>
<reason>alarmCode: A054 does not exist</reason>
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4/RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="Version">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<siteIds>
<siteId>F+40100=416</siteId>
</siteIds>
<rsmpVersions>
TDOK 2010:21_Mall Riktlinje v. 1.0
35 (55)
GUIDELINE
DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
<rsmpVersion>1.0</rsmpVersion>
<rsmpVersion>1.2</rsmpVersion>
<rsmpVersion>1.3</rsmpVersion>
</rsmpVersions>
<sxlVersion>1.3</sxlVersion>
</message>
</roadSideMessage>
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.
<?xml version="1.0" encoding="utf-8"?>
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4/RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="Watchdog">
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
<watchdogTimestamp>2009-10-02T14:34:34.341Z</watchdogTimestamp>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "Alarm",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"mId": "E68A0010-C336-41ac-BD585C80A72C7092",
RoadSideMessage_1_0_1_4.xsd">
"ntsOId": "F+40100=416CG100",
<message xsi:type="Alarm">
"xNId": "23055",
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
"cId": "AB+84001=860VA001",
<ntsObjectId>F+40100=416CG100</ntsObjectId>
"aCId": "A001",
<externalNtsId>23055</externalNtsId>
"xACId": "Lampfel på lykta 1 (röd)",
<componentId>AB+84001=860VA001</componentId>
"xNACId": "3143",
<alarmCodeId>A001</alarmCodeId>
"aSp": "Issue",
<externalAlarmCodeId>Lampfel på lykta 1 (röd)</externalAlarmCodeId>
"ack": "notAcknowledged",
<externalNtsAlarmCodeId>3143</externalNtsAlarmCodeId>
"aS": "active",
<alarmSpecialisation xsi:type="Issue">
"sS": "notSuspended",
<acknowledgeState>notAcknowledged</acknowledgeState>
"aTs": "2009-10-01T11:59:31.571Z",
<alarmState>active</alarmState>
"cat": "D",
<suspendState>notSuspended</suspendState>
"pri": "2"
<timestamp>2009-10-01T11:59:31.571Z</timestamp>
"rvs": [
<category>D</category>
{
<priority>2</priority>
"n": "signalgrupp",
<returnvalues>
"v": "1"
<returnvalue>
},
<name>signalgrupp</name>
{
<value>1</value>
"n": färg",
</returnvalue>
<returnvalue>
<name>färg</name>
"v": "röd"
}]
}
<value>röd</value>
</returnvalue>
</returnvalues>
</alarmSpecialisation>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "Alarm",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"mId": "E68A0010-C336-41ac-BD585C80A72C7092",
RoadSideMessage_1_0_1_4.xsd">
"ntsOId": "F+40100=416CG100",
<message xsi:type="Alarm">
"xNId": "23055",
<messageId>{E68A0010-C336-41ac-BD58-
"cId": "AB+84001=860VA001",
5C80A72C7092}</messageId>
"aCId": "A001",
<ntsObjectId>F+40100=416CG100</ntsObjectId>
"xACId": "Larmfel på lykta 1 (röd)",
<externalNtsId>23055</externalNtsId>
"xNACId": "3143",
<componentId>AB+84001=860VA001</componentId>
"aSp": "acknowledge",
<alarmCodeId>A001</alarmCodeId>
"ack": "Acknowledged",
<externalAlarmCodeId>Larmfel på lykta 1 (röd)</externalAlarmCodeId>
"aS": "active",
<externalNtsAlarmCodeId>3143</externalNtsAlarmCodeId>
"sS": "notSuspended",
<alarmSpecialisation xsi:type="Acknowledge">
"aTs": "2009-10-01T11:59:31.571Z",
</message>
"cat": "b",
</roadSideMessage>
"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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "Alarm",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"mId": "E68A0010-C336-41ac-BD585C80A72C7092",
RoadSideMessage_1_0_1_4.xsd">
"ntsOId": "F+40100=416CG100",
<message xsi:type="Alarm">
"xNId": "23055",
<messageId>{E68A0010-C336-41ac-BD58-
"cId": "AB+84001=860VA001",
5C80A72C7092}</messageId>
"aCId": "A001",
<ntsObjectId>F+40100=416CG100</ntsObjectId>
"xACId": "Larmfel på lykta 1 (röd)",
<externalNtsId>23055</externalNtsId>
"xNACId": "3143",
<componentId>AB+84001=860VA001</componentId>
<alarmCodeId>A001</alarmCodeId>
"aSp": "suspend"
}
<externalAlarmCodeId>Larmfel på lykta 1 (röd)</externalAlarmCodeId>
<externalNtsAlarmCodeId>3143</externalNtsAlarmCodeId>
<alarmSpecialisation xsi:type="Suspend">
<suspendAction>suspend</suspendAction>
</alarmSpecialisation>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "AggregatedStatus",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"mId": "E68A0010-C336-41ac-BD585C80A72C7092",
RoadSideMessage_1_0_1_4.xsd">
"ntsOId": "F+40100=416CG100",
<message xsi:type="AggregatedStatus">
"xNId": "23055",
<messageId>{E68A0010-C336-41ac-BD58-
"cId": "F+40100=416CG100",
5C80A72C7092}</messageId>
"aSTS": "2009-10-02T14:34:34.345Z",
<ntsObjectId>F+40100=416CG100</ntsObjectId>
"fP": "Trafikstyrning",
<externalNtsId>23055</externalNtsId>
"fS": "Automatiskt nedsatt hastighet",
<componentId>F+40100=416CG100</componentId>
<aggstatusTimeStamp>2009-1002T14:34:34.345Z</aggstatusTimeStamp>
"se": ["false", "true", "true", "false", "false", "false",
"false", "false"]
}
<aggregatedStatusSpecialisation>
<functionalPosition>Trafikstyrning</functionalPosition>
<functionalState>Automatiskt nedsatt hastighet</functionalState>
<state>
<name>1</name>
<state>false</state>
</state>
<state>
<name>2</name>
<state>true</state>
</state>
<state>
<name>3</name>
<state>true</state>
</state>
<state>
<name>4</name>
<state>false</state>
</state>
<state>
<name>5</name>
<state>false</state>
</state>
<state>
<name>6</name>
<state>false</state>
</state>
<state>
<name>7</name>
<state>false</state>
</state>
<state>
<name>8</name>
<state>false</state>
</state>
</aggregatedStatusSpecialisation>
TDOK 2010:21_Mall Riktlinje v. 1.0
45 (55)
GUIDELINE
DokumentID
Ev. ärendenummer
Version
[Ärendenummer]
3.1.2 (unofficial)
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "StatusRequest",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"ntsOId": "F+40100=416CG100",
RoadSideMessage_1_0_1_4.xsd">
"xNId": "23055",
<message xsi:type="StatusRequest">
"cId": "AB+84001=860VA001",
<messageId>{E68A0010-C336-41ac-BD58-
"sS":[
5C80A72C7092}</messageId>
{"sCI": "S003"
<ntsObjectId>F+40100=416CG100</ntsObjectId>
”n":"speed"},
<externalNtsId>23055</externalNtsId>
{"sCI": "S003",
"n":"occupancy"}
<componentId>AB+84001=860VA001</componentId>
<statuses>
<status>
<statusCodeId>S003</statusCodeId>
<name>speed</name>
</status>
<status>
<statusCodeId>S003</statusCodeId>
<name>occupancy</name>
</status>
</statuses>
]
}
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "StatusResponse",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"ntsOId": "F+40100=416CG100",
RoadSideMessage_1_0_1_4.xsd">
"xNId": "23055",
<message xsi:type="StatusResponse">
"cId": "AB+84001=860VA001",
<messageId>{E68A0010-C336-41ac-BD58-
"sTs": "2009-10-02T14:34:34.345Z",
5C80A72C7092}</messageId>
"sS":[
<ntsObjectId>F+40100=416CG100</ntsObjectId>
{"sCI": "S003",
<externalNtsId>23055</externalNtsId>
"n":"1",
<componentId>AB+84001=860VA001</componentId>
"s": "70",
<statusTimeStamp>2009-10-02T14:34:34.345Z</statusTimeStamp>
"q": "recent"},
<returnvalues>
{"sCI": "S007",
<returnvalue>
"n":"1",
<statusCodeId>S003</statusCodeId>
"s": "0",
<ageState>recent</ageState>
"q": "unknown"}
<name>1</name>
]
<status>70</status>
}
</returnvalue>
<returnvalue>
<statusCodeId>S007</statusCodeId>
<ageState>unknown</ageState>
<name>1</name>
<status>0</status>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "StatusSubscribe"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092”,
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"ntsOId": "F+40100=416CG100",
RoadSideMessage_1_0_1_4.xsd">
"xNId": "23055",
<message xsi:type="StatusSubscribe">
<messageId>{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}</messageId>
{"sCI": "S003",
<ntsObjectId>F+40100=416CG100</ntsObjectId>
"n": "speed",
<externalNtsId>23055</externalNtsId>
"uRt": "10"},
<componentId>AB+84001=860VA001</componentId>
{"sCI": "S003",
<statuses>
"n":" occupancy ",
<status>
"uRt": "10"}
<statusCodeId>S003</statusCodeId>
<name>speed</name>
]
}
<updateRate>10</updateRate>
</status>
<status>
<statusCodeId>S003</statusCodeId>
<name>occupancy</name>
<updateRate>10</updateRate>
</status>
</statuses>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "StatusUpdate",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"ntsOId": "F+40100=416CG100",
RoadSideMessage_1_0_1_4.xsd">
"xNId": "23055",
<message xsi:type="StatusUpdate">
"cId": "AB+84001=860VA001",
<messageId>{E68A0010-C336-41ac-BD58-
"sTs": "2009-10-02T14:34:34.345Z",
5C80A72C7092}</messageId>
"sS":[
<ntsObjectId>F+40100=416CG100</ntsObjectId>
{"sCI": "S003",
<externalNtsId>23055</externalNtsId>
"n":"1",
<componentId>AB+84001=860VA001</componentId>
"s": "70",
<statusTimeStamp>2009-10-02T14:34:34.345Z</statusTimeStamp>
"q": "recent"},
<returnvalues>
{"sCI": "S007",
<returnvalue>
"n":"1",
<statusCodeId>S003</statusCodeId>
"s": "0",
<ageState>recent</ageState>
"q": "unknown"}
<name>1</name>
<status>70</status>
]
}
</returnvalue>
<returnvalue>
<statusCodeId>S007</statusCodeId>
<ageState>unknown</ageState>
<name>1</name>
<status>0</status>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "StatusUnsubscribe"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092”,
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"ntsOId": "F+40100=416CG100",
RoadSideMessage_1_0_1_4.xsd">
"xNId": "23055",
<message xsi:type="StatusUnSubscribe">
"cId": "AB+84001=860VA001",
<messageId>{E68A0010-C336-41ac-BD58-
"sS":[
5C80A72C7092}</messageId>
{"sCI": "S003",
<ntsObjectId>F+40100=416CG100</ntsObjectId>
"n":"speed"},
<externalNtsId>23055</externalNtsId>
{"sCI": "S003",
<componentId>AB+84001=860VA001</componentId>
"n":" occupancy”}
<statuses>
<status>
]
}
<statusCodeId>S003</statusCodeId>
<name>speed</name>
</status>
<status>
<statusCodeId>S003</statusCodeId>
<name>occupancy</name>
</status>
</statuses>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "CommandRequest",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"ntsOId": "F+40100=416CG100",
RoadSideMessage_1_0_1_4.xsd">
"xNId": "23055",
<message xsi:type="CommandRequest">
"cId": "AB+84001=860VA001",
<messageId>{E68A0010-C336-41ac-BD58-
"arg": [
5C80A72C7092}</messageId>
{
<ntsObjectId>F+40100=416CG100</ntsObjectId>
"cCI": "M003",
<externalNtsId>23055</externalNtsId>
"n": "1",
<componentId>AB+84001=860VA001</componentId>
"cO": "setValue",
<arguments>
"v": "Auto"
<argument>
<commandCodeId>M002</commandCodeId>
}]
}
<name>1</name>
<command>setValue</command>
<value>Auto</value>
</argument>
</arguments>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "CommandResponse",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"ntsOId": "F+40100=416CG100",
RoadSideMessage_1_0_1_4.xsd">
"xNId": "23055",
<message xsi:type="CommandResponse">
"cId": "AB+84001=860VA001",
<messageId>{E68A0010-C336-41ac-BD58-
"cTS": "2009-10-02T14:34:34.345Z",
5C80A72C7092}</messageId>
"rvs": [
<ntsObjectId>F+40100=416CG100</ntsObjectId>
{
<externalNtsId>23055</externalNtsId>
"cCI": "M002",
<componentId>AB+84001=860VA001</componentId>
"age": "recent",
<commandTimeStamp>2009-10-
"n": "1",
02T14:34:34.345Z</commandTimeStamp>
"v": "70"
<returnvalues>
<returnvalue>
}]
}
<commandCodeId>M002</commandCodeId>
<ageState>recent</ageState>
<name>1</name>
<value>Auto</value>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "MessageAck",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"oMId": "F4FSD010-D587-7A3B-8BD5-5C80A72C7154"
}
RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="MessageAck">
<originalMessageId>{E4FSD010-C336-41ac-BD585C80A72C7092}</originalMessageId>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "MessageNotAck",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
"oMId": "F4FSD010-D587-7A3B-8BD5-5C80A72C7154",
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
RoadSideMessage_1_0_1_4.xsd">
"rea": "alarmCode: A054 does not exist"
}
<message xsi:type="MessageNotAck">
<originalMessageId>{E4FSD010-C336-41ac-BD585C80A72C7092}</originalMessageId>
<reason>alarmCode: A054 does not exist</reason>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0" xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"mType": "rSMsg",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
"type": "Version",
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4/RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="Version">
"mId": "E68A0010-C336-41ac-BD585C80A72C7092",
<messageId>{E68A0010-C336-41ac-BD58-5C80A72C7092}</messageId>
"siteId":[
<siteIds>
{"sId":"F+40100=416CG100"}],
<siteId>F+40100=416CG100</siteId>
"RSMP":[
</siteIds>
{"vers":"1.0"},
<rsmpVersions>
{"vers":"1.2"},
<rsmpVersion>1.0</rsmpVersion>
{"vers":"1.3"}],
<rsmpVersion>1.2</rsmpVersion>
<rsmpVersion>1.3</rsmpVersion>
"SXL":"1.3"
}
</rsmpVersions>
<sxlVersion>1.3</sxlVersion>
</message>
</roadSideMessage>
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
<?xml version="1.0" encoding="utf-8"?>
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "Watchdog",
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
RoadSideMessage_1_0_1_4.xsd">
"wTs": "2009-10-02T14:34:34.345Z",
}
<message xsi:type="Watchdog">
<messageId>{E68A0010-C336-41ac-BD585C80A72C7092}</messageId>
<watchdogTimestamp>2009-1002T14:34:34.345Z</watchdogTimestamp>
</message>
</roadSideMessage>
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