CEN/TS 16157-4:2014

SLOVENSKI STANDARD
01-september-2014
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
upravljanju prometa in informiranju - 4. del: Objave spremenljivih prometnih
znakov (VMS)
Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 4: Variable Message Sign (VMS) Publications
Intelligente Transportsysteme - DATEX II Datenaustausch Spezifikationen für
Verkehrsmanagement und Informationen - Teil 4: Variable Verkehrszeichen (VMS)
Veröffentlichungen
Systèmes de transport intelligents - Spécifications Datex II d'échange de données pour
la gestion du trafic et l'information routière - Partie 4 : Publication de VMS
Ta slovenski standard je istoveten z: CEN/TS 16157-4:2014
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 16157-4
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
April 2014
ICS 35.240.60
English Version
Intelligent transport systems - DATEX II data exchange
specifications for traffic management and information - Part 4:
Variable Message Sign (VMS) Publications
Systèmes de transport intelligents - Spécifications Datex II Intelligente Transportsysteme - DATEX II Datenaustausch
d'échange de données pour la gestion du trafic et Spezifikationen für Verkehrsmanagement und
l'information routière - Partie 4 : Publication de VMS Informationen - Teil 4: Variable Verkehrszeichen (VMS)
Veröffentlichungen
This Technical Specification (CEN/TS) was approved by CEN on 27 January 2014 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2014 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16157-4:2014 E
worldwide for CEN national Members.

Contents Pages
Foreword .3
Introduction .4
1 Scope .5
1.1 Conformance .5
2 Normative references .6
3 Terms and definitions .6
4 Symbols and abbreviated terms .7
5 UML notation .7
6 The VMS Publication model .7
6.1 Overview of the VMS Publication model .7
6.2 The Fault Package .8
6.3 The “VmsPublication” Package .9
6.4 The “VmsUnit” Package . 10
6.5 The “VmsMessage” Package . 14
7 The VMS Table Publication model . 17
7.1 Overview of the VMS Table Publication model . 17
7.2 The “VmsTablePublication” Package . 17
Annex A (normative) Data Dictionary . 21
A.1 Overview . 21
A.2 Data Dictionary for “VMS Publication” . 22
A.3 Data Dictionary of < < datatypes > > for “VMS Publication” . 39
A.4 Data Dictionary of < < enumerations > > for “VMS Publication” . 39
A.5 Data Dictionary for “VMS Table Publication” . 51
A.6 Data Dictionary of < < datatypes > > for “VMS Table Publication” . 58
A.7 Data Dictionary of < < enumerations > > for “VMS Table Publication”. 59
Annex B (normative) Referenced XML Schema for “VmsPublication” . 62
B.1 Overview . 62
B.2 Schema . 62
Annex C (normative) Referenced XML Schema for “VmsTablePublication” . 82
C.1 Overview . 82
C.2 Schema . 82
Annex D (informative) Examples of VMS Publications and VMS Table Publications In XML . 92
D.1 Example VmsPublication (text only) . 92
D.2 Example VmsPublication (text and pictogram) . 93
D.3 Example VmsPublication (text and sequencing pictograms) . 95
D.4 Example VmsTablePublication . 97
Bibliography . 103

Foreword
This document (CEN/TS 16157-4:2014) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
DATEX II data exchange specifications for traffic management and information”:
— Part 1: Context and framework
— Part 2: Location referencing
— Part 3: Situation publication
— Part 4: VMS publication
— Part 5: Measured and Elaborated Data Publications
The following parts are under preparation:
— Traffic view publication
— Communication specifications
Other parts may be developed in the future.
As a user of the standard, attention is drawn to the resources of www.datex2.eu < http://www.datex2.eu/>.
This website contains related software tools and software resources that aid the implementation of the
CEN/TS 16157 series DATEX II.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria, Croatia, Cyprus,
Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

Introduction
This Technical Specification defines a common set of data exchange specifications to support the vision of a
seamless interoperable exchange of traffic and travel information across boundaries, including national,
urban, interurban, road administrations, infrastructure providers and service providers. Standardization in this
context is a vital constituent to ensure that interoperability, reduction of risk, reduction of the cost base and
promotion of open marketplace objectives are achieved that will lead to many social, economic and
community benefits as a result of more informed travellers, network managers and transport operators.
Delivering European Transport Policy in line with the White Paper issued by the European Commission
requires co-ordination of traffic management and the development of seamless pan European services. With
the aim to support sustainable mobility in Europe, the European Commission has been supporting the
development of information exchange mainly between the actors of the road traffic management domain for a
number of years. In the road sector, DATEX II has been long in fruition, with the European Commission being
fundamental to its development through an initial contract and subsequent co-funding through the Euro-
Regional projects. With this standardization of DATEX II there is a real basis for common exchange between
the actors of the traffic and travel information sector.
This Technical Specification includes the framework and context for exchanges, the modelling approach, data
content, data structure and relationships and communications specification.
This Technical Specification supports a methodology that is extensible.
The fourth part of this Technical Specification deals with the publication of variable message sign (VMS)
information. It specifies the structures and definitions of information that may be exchanged to convey details
of the messages displayed on variable message signs, and the current configuration/characteristics and
status of the variable message signs that are currently deployed on the road network.
The European Committee for Standardization (CEN) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning procedures, methods and/or
formats given in this document.
CEN takes no position concerning the evidence, validity and scope of patent rights.
1 Scope
This Technical Specification (CEN/TS 16157-4:2014) specifies and defines component facets supporting the
exchange and shared use of data and information in the field of traffic and travel.
The component facets include the framework and context for exchanges, the modelling approach, the data
content, the data structure and relationships and the communications specification.
This Technical Specification is applicable to:
— Traffic and travel information which is of relevance to road networks (non urban and urban);
— Public transport information that is of direct relevance to the use of a road network (e.g. road link via train
or ferry service).
This Technical Specification establishes specifications for data exchange between any two instances of the
following actors:
— Traffic Information Centres (TICs);
— Traffic Control Centres (TCCs);
— Service Providers (SPs).
Use of this Technical Specification may be applicable for use by other actors.
This Technical Specification includes the following types of information content:
— Road traffic event information – planned and unplanned occurrences both on the road network and in the
surrounding environment;
— Operator initiated actions;
— Road traffic measurement data, status data and travel time data;
— Travel information relevant to road users, including weather and environmental information;
— Road traffic management information and instructions relating to use of the road network.
This part of the CEN/TS 16157 series specifies the informational structures, relationships, roles, attributes and
associated data types required for publishing variable message sign information within the Datex II framework.
This is specified in two parts, a DATEX II VMS Publication sub-model and a VMS Table Publication sub-
model.
The VMS Publication supports the exchange of the graphic and textual content of one or several VMS plus
any status information on device configuration that aid the comprehension of the informational content. This
content is potentially subject to rapid change. The VMS Table Publication supports the occasional exchange
of tables containing generally static reference information about deployed VMS which enable subsequent
efficient references to be made to pre-defined static information relating to those VMS. These publications are
not intended to support the control or configuration of VMS equipment. Each is part of the DATEX II platform
independent model.
1.1 Conformance
The platform independent sub-models defined by this Part specify a DATEX II VMS Publication and a DATEX
II VMS Table Publication except for those elements that relate to location information which are specified in
CEN/TS 16157-2. The DATEX II platform independent data model of which these two publication sub-models
are a part, corresponds to the Level A model as defined in CEN/TS 16157-1.
Conformance with this Part shall require platform independent models from which platform specific models are
generated to comply with the UML modelling rules defined in CEN/TS 16157-1 and with the following
requirements of the sub-models which are expressed in this Part:
— comply with all stipulated minimum and maximum multiplicity requirements for UML elements and
relationships;
— comply with all definitions, types and ordering;
— employ optional elements as specified;
— comply with all expressed constraints.
It should be noted that conformance of a publication service with all the structural requirements stated above
does not necessarily ensure that the informational content of that service will be semantically comprehensible.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
CEN/TS 16157-1, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 1: Context and framework
CEN/TS 16157-2, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 2: Location referencing
CEN/TS 16157-3, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 3: Situation Publication
ISO 639-2:1998, Codes for the representation of names of languages — Part 2: Alpha-3 code
ISO/IEC 19501:2005, Information technology — Open Distributed Processing — Unified Modeling Language
(UML) Version 1.4.2
3 Terms and definitions
For the purposes of this document, the terms and definitions given in CEN/TS 16157-1 and in the following list
shall apply.
4.1
legend
a sequence of text characters and/or symbols that is displayed on a variable message sign
4.2
location
identifiable geographic place
[EN ISO 19112:2005]
Note 1 to entry: It is either on a road network (as a point or a linear location) or as an area. This may be provided in
one or more referencing systems.
4.3
pictogram
a representation of a graphic symbol displayed on a variable message sign by means of a (usually multi
colour capable) matrix or LED display panel
4.4
supplementary panel
an additional display panel, either physically separate or integrated with the main display panel which may
display information or regulatory instructions which are supplemental to the associated pictogram, comprising
either an additional line of text or a pictogram or both
4.5
variable message sign
VMSA sign/display panel used for the purpose of displaying one or more messages (comprising any
combination of textual, symbol or pictogram information) that may be changed or switched on or off as
required
4.6
variable message sign unit
a roadside unit which may control one or more variable message signs on a single gantry/mounting or on
closely associated separate gantries/mountings
4 Symbols and abbreviated terms
For the purposes of this document, the abbreviation of terms given in CEN/TS 16157-1 and in the following list
shall apply.
HTML Hyper Text Mark-up Language
IP Internet Protocol
RSS Really Simple Syndication
NOTE Comprises a Web feed format used to publish frequently updated sources of
information.
UML Unified Modelling Language
URL Uniform Resource Locator
VMS Variable Message Sign
5 UML notation
The UML notation used in these Technical Specifications shall be as described in ISO/IEC 19501. A short
summary explaining the notation used in this Technical Specification is provided in Annex A of
CEN/TS 16157-1.
6 The VMS Publication model
6.1 Overview of the VMS Publication model
The VMS Publication model shall comprise a top level package, “VmsPublication” and some sub-packages
from the “ReusableClasses” package. The “VmsPublication” top level package shall be one of a number which
shall be immediately subordinate to the “PayloadPublication” package and hence shall form the top of the
hierarchy in the VMS Publication sub-model.
The “VmsPublication” package shall make use of a subordinate “VmsUnit” package and a “VmsMessage”
package that together shall model the details of what is currently displayed on and the status of variable
message signs. The “VmsUnit” and “VmsMessage” packages shall reside in the “VmsRelated” package which
is within the “ReusableClasses” package because they are also used in the “SituationPublication” package.
Each “VmsPublication” instance shall contain details of a number of individual deployed VMS units, each of
which may control one or more VMSs.
Some of the individual classes used within the “VmsPublication” package, principally those for modelling the
characteristics of a VMS, also reside in the “VmsRelated” package which is within the “ReusableClasses”
package as they are also used in the “VmsTablePublication” package”.
6.2 The Fault Package
6.2.1 Overview of the “VmsPublication” Package
The “Fault Package” is introduced to manage reusable classes to provide information related to fault for
equipment and devices. Classes related to Vms are Fault VmsFault and VmsUnitFault.

Figure 1 — The “Fault” package class model
6.2.2 Semantics of the “Fault” Package
6.2.2.1 “Fault” Class
Fault Class is defined in Fault package and is used to supply information about a fault relating to a specific
piece of equipment or process. It provides information about fault start time, fault identification and description
and severity. Fault may vary and update time is used to provide the period since the fault is unmodified. Fault
Class is specialized for VMS Unit and VMS.
Attribute “faultCreationTime” may be used to provide the time the fault has been reported or recorded
Attribute “faultDescription may be used to provide a natural language description of the fault
Attribute “faultIdentifier may be used to provide a unique identifier of the fault
Attribute “faultLastUpdateTime may be used to provide the time the fault has been reported or recorded as
updated
Attribute “faultSeverity” may be used to provide the severity of the fault
6.2.2.2 “VmsUnitFault” Class
VmsUnitFault class is used to provide information of faults related to VMSUnit
Attribute “VmsFault” shall be used to provide the detail of the fault
6.2.2.3 “VmsFault” Class
VmsUnitFault class is used to provide information of faults related to VMS
Attribute “VmsFault” shall be used to provide the detail of the fault
6.3 The “VmsPublication” Package
6.3.1 Overview of the “VmsPublication” Package
The “VmsPublication” package shall be immediately subordinate to the “PayloadPublication” package and
shall comprise the sub-model for defining a publication which identifies the visual and textual content
displayed on individual VMSs and the status and settings of those VMSs, where each VMS is controlled by an
associated VMS unit (see Figure 2). The information shall be published in sets where each set relates to a
particular VMS unit which may control one or more VMSs.

Figure 2 — The “VmsPublication” package class model
6.3.2 Semantics of the “VmsPublication” Package
6.3.2.1 “VmsPublication” package semantics - general
The “VmsPublication” class shall be a specific realizable case of a “PayloadPublication”. Each
“VmsPublication” may contain any number of separate sets of information, each relating to a set of VMSs
which shall be controlled by the same VMS unit.
The information relating to each VMS in the “VmsPublication shall specify the message/s that have actually
been set on the VMS at a specified time .
6.3.2.2 “VmsPublication” Class
The “VmsPublication” class shall be the base class for containing the published VMS information.
6.3.2.3 “HeaderInformation” Class
Each instance of a “VmsPublication” shall have associated metadata contained in an instance of the
“HeaderInformation” class which shall allow the supplier of the publication to specify how the recipient of the
“VmsPublication” should treat the information contained in it. For “HeaderInformation” class refer to
CEN/TS 16157-3.
6.4 The “VmsUnit” Package
6.4.1 Overview of the “VmsUnit” Package
The package, “VmsUnit”, shall comprise a sub-model for defining information about the settings, status, and
characteristics of VMS units and their component VMSs which are deployed on the road network (see Figure
3 — The “VmsUnit” package class model).
Each VMS unit controls one or more VMSs, where a VMS may display one message or a sequence of
messages each comprising a combination of textual, symbol or pictogram information.
A VMS can display only one message at a time where each individual message shall comprise zero or one
text component and zero or more pictograms components (see Clause 6.5).

1 ) The information in the “VmsPublication” should relate to the current state of VMSs deployed on the road,
and not to any state information at the control centre, such as “pending” or “queued” or to any prioritized lists
of messages which may be displayed at some point in the future.

2) Variable Message Sign (VMS) units are mostly static installations but some may be mobile changing their
locations from time to time. Matrix signs used by some countries are classed in DATEX II as a simple type of
VMS with limited display capabilities.

Figure 3 — The “VmsUnit” package class model
6.4.2 Semantics of the “VmsUnit” Package
6.4.2.1 “VmsUnit” package semantics - general
The “VmsUnit” package shall comprise a “VmsUnit” class which has one or more indexed components where
each component shall model the details of an individual VMS that is controlled by the VMS unit.
The static characteristics of each VMS shall be identified by using an indexed reference into a specified record
in a “VmsUnitTable” published in a “VmsTablePublication” (see Clause 7). Alternatively where a VMS’s
characteristics are more dynamic these may be given directly in this publication which, if provided, shall
override any static characteristics defined in the referenced record in the “VmsUnitTable”. The “VmsUnit” class
shall be a specialization of the “VmsSetting” class which may be used in a Situation Publication to provide
details of VMSs which are set as a direct result of the situation that is defined in the “SituationPublication” (see
CEN/TS 16157-3, 7.23).
6.4.2.2 “VmsUnit” Class
An instance of the “VmsUnit” class shall represent a single VMS control unit at the roadside which may control
one or more VMS. It shall be possible to associate fault information with each “VmsUnit” class instance via the
“VmsFault” class.
Each VMS controlled by a VMS unit is referenced by its “vmsIndex” qualifier. The “vmsIndex” qualifier
provides an index into the specific “VmsRecord” within the relevant “VmsUnitRecord” (see
VmsTablePublication in Clause 7) from where the static VMS characteristics that are relevant for the VMS can
be obtained. These VmsUnitRecords are contained in a referenced VmsUnitTable that is published in a
VmsTablePublication.
— Attribute “vmsUnitTableReference” shall be used to provide a reference to an instance of a
“VmsUnitTable” that is published in a “VmsTablePublication” which contains a set of VMS unit records
where each record holds details of the characteristics and configuration data relating to a VMS unit and
its controlled VMSs. This reference shall point to the relevant table which holds the record containing the
details for this VMS unit.
— Attribute “vmsUnitReference” shall be used to provide a reference to an instance of a
“VmsUnitRecord” within the referenced “VmsUnitTable” that is published in a “VmsTablePublication”. The
“VmsUnitRecord” shall contain the relevant characteristics and configuration details relating to this VMS
unit and its controlled VMSs.
6.4.2.3 “VmsUnitFault” Class
An instance of the “VmsUnitFault” class shall allow a supplier of information via a DATEX II interface to
provide fault information relating to a variable message sign control unit. More than one type of fault may exist
at the same time. Each instance of a “VmsUnitFault” inherits fault details from the “Fault” class which, at a
minimum, shall contain the time that the fault information was last updated.
6.4.2.4 “Vms” Class
An instance of the “Vms” class shall represent a single VMS and shall allow a supplier of information via a
DATEX II interface to define what textual legend and pictograms are being displayed, its dynamic
characteristics/configuration and any current fault status of the VMS.
A VMS may be set to display a sequence of messages in a defined order where each message comprises a
combination of text pages and pictograms. In this case the “messageIndex” qualifier shall be used to
distinguish the individual messages and their order of display.
Each VMS has a location which will normally be defined in the referenced record of a specific “VmsUnitTable”.
Note that it is the location of the individual VMSs which is to be provided, not the location of the VMS unit
which controls them.
Where the location of a VMS is dynamic or has changed recently, the current location shall be provided as an
aggregation (“vmsLocationOverride”) to the “Vms” class instance which shall override any location given in a
referenced “VmsUnitTable”. Similarly any location which a VMS is used to manage such as a car park or a
road junction, that has changed recently, can be provided via the “managedLogicalLocationOverride”
aggregation, again which shall override any managed location given in the relevant “VmsUnitTable” entry.
6.4.2.5 “VmsFault” Class
An instance of the “VmsFault” class shall allow a supplier to provide fault information relating to a VMS. More
than one type of fault may exist at the same time. Each instance of a “VmsFault” class inherits fault details
from the “Fault” class which, at a minimum, shall contain the time that the fault information was last updated.
6.4.2.6 “VmsDynamicCharacteristics” Class
An instance of the “VmsDynamicCharacteristics” class shall allow a supplier to associate dynamic
characteristics with a VMS which shall override any characteristics given in the referenced record of the
“VmsUnitTable”. The characteristics for each pictogram display area on the VMS shall be referenced by the
area’s “pictogramDisplayAreaIndex” qualifier which provides a notional indication of the importance of the
pictogram display area (“1” indicating the highest “importance”) as perceived by the supplier of the
information. Note. “Importance” in the previous sentence refers to conventional semantic logic associated to
interpretation and comprehension of information related to pictograms and text messages, e.g. in case of 2
pictos associated to a diaply text area, the 2 pictos can be at same side of VMS or one at left and the other at
right side of the display text area, the highest relevance for occidental writing is the one on the left to the
display text area, the other is the less relevant, normally is used to display complementary information such as
cause or additional information.
6.4.2.7 “VmsTextDisplayCharacteristics” Class
An instance of the “VmsTextDisplayCharacteristics” class shall allow a supplier to identify the text display area
characteristics currently being used on the VMS which, if provided, shall override those defined in the
referenced record of the “VmsUnitTable”.
The characteristics for the text display area optionally include area dimensions (in pixels and metric
measurements), font sizes, number of characters and rows, details of text area positioning on the VMS panel
and the maximum luminance level.
— Attribute “textPageSequencingCapable” may be used to provide an indication of whether the VMS is
capable of displaying a number of text pages which are automatically displayed in a defined sequence
and at a defined rate.
— Attribute “legendCodeListIdentifier” may be used to identify what list of legends or texts are being
used by the VMS. Usually specific deployments of VMS across a road network or part of a network will
use defined sets of legend or text which are specified by the road authority/operator and are consistent
with the display capabilities of the particular VMS. This attribute allows the identity of this list to be
promulgated.
6.4.2.8 “VmsPictogramDisplayCharacteristics” Class
An instance of the “VmsPictogramDisplayCharacteristics” class shall allow a supplier to identify the pictogram
display characteristics currently being used on the VMS within a particular display area which, if provided,
shall override those defined in the referenced record of the “VmsUnitTable”.
The characteristics for the pictogram display area include area dimensions (in pixels and metric
measurements), details of the positioning of the area on the VMS panel and the maximum luminance level.
— Attribute “pictogramSequencingCapable” may be used to provide an indication of whether the VMS is
capable of displaying a number of separate pictograms in the particular pictogram display area which are
automatically displayed in a defined sequence and at a defined rate.
— Attribute “pictogramCodeListIdentifier” may be used to identify what list of pictograms is being used
by the VMS. Usually specific deployments of VMS across a road network or part of a network will use
defined sets of pictograms which are specified by the road authority/operator and are consistent with the
display capabilities of the particular VMS. This attribute allows the identity of this list to be promulgated.
6.4.2.9 “VmsSupplementaryPanelCharacteristics” Class
Each pictogram display area may have associated with it a maximum of one supplementary panel for
displaying additional information or regulatory instructions that qualify what is being displayed in the particular
pictogram display area. Supplementary panels are managed as part of the pictogram display area that they
support.
An instance of the “VmsSupplementaryPanelCharacteristics” class shall allow a supplier to identify
supplementary panel display characteristics currently being used on the VMS which, if provided, shall override
those defined in the referenced record of the “VmsUnitTable”.
The characteristics for the supplementary panel include area dimensions (in pixels and metric measurements)
and details of area positioning on the VMS panel.
6.4.2.10 “TextDisplayAreaSettings” Class
An instance of the “TextDisplayAreaSettings” class shall allow a supplier to identify the current settings
applicable to the distinct text display area. These are settings such as luminance level and whether lanterns
are on which are normally independent of the text message currently being displayed.
6.4.2.11 “PictogramDisplayAreaSettings” Class
An instance of the “PictogramDisplayAreaSettings” class which is referenced by its
“pictogramDisplayAreaIndex” qualifier shall allow a supplier to identify the current settings applicable to a
distinct pictogram display area. These are settings such as luminance level and whether lanterns are on which
are normally independent of the pictogram currently being displayed in that area.
6.5 The “VmsMessage” Package
6.5.1 Overview of the “VmsMessage” Package
The package, “VmsMessage”, shall comprise a sub-model for defining information about individual messages
displayed on a VMS. Individual messages displayed at a given time are modelled as comprising zero or one
text component and zero or more pictograms components where each component is displayed in a specific
display area on a VMS.
Each text component shall comprise one or more text pages, multiple text pages being sequenced. Each
pictogram component shall comprise one or more sequenced pictograms each with possible additional
supplementary information or regulatory instructions that qualify the displayed pictogram. Multiple text pages
and pictograms shall be sequenced in a specified order and at a specified interval.
Figure 4 — The “VmsMessage” package class model
6.5.2 Semantics of the “VmsMessage” Package
6.5.2.1 “VmsMessage” package semantics - general
The “VmsMessage” package shall comprise a “VmsMessage” class which has a number of indexed
components which either model pages of text displayed in a single text display area or a number of
pictograms and supplementary information displayed in one or more pictogram including a possible
supplementary display area on the VMS.
Where multiple text pages are specified for display in the text display area the order in which they are
displayed is identified by the “pageNumber” qualifier order.
For each pictogram display area used by a VMS message a sequence of separate pictograms may be
specified as being displayed in that area. A pictogram display area which is specified as displaying a
sequence of pictograms may be specified as having the pictograms sequenced in synchronism with the set of
sequenced text pages (see Clause 6.5.2.5).
6.5.2.2 “VmsMessage” Class
An instance of the “VmsMessage” class which is referenced by its “messageIndex” qualifier shall allow a
supplier of information via a DATEX II interface to identify the details of the message currently being displayed
on the VMS’s text display area, the various pictogram display areas and the supplementary panel display
areas which may exist to support the pictogram display areas.
The “messageIndex” qualifier on the association with the “Vms” class shall indicate the order of display of the
messages if there are multiple messages specified, the sequence continuously cycling. If there is only one
message being displayed the “messageIndex” shall have a value of “1”.
6.5.2.3 “VmsText” Class
An instance of the “VmsText” class shall allow a supplier of information via a DATEX II interface to identify
what text is displayed in the text display area and what it looks like on the VMS.
— Attribute “vmsLegendCode” shall identify the code of the legend/text from the legend code list
referenced in the “VmsTextDisplayCharacteristics” class (see Clause 6.4.2.7). Typically this will use the
individual road authority’s/operator’s coding scheme for the different text messages. It does not give any
indication of the line breaks in the displayed text. Line break detail is specified by providing an indexed
sequence of instances of the “VmsTextLine” class which gives the actual text strings for each line.
The “pageNumber” qualifier shall be used to indicate the order of sequencing of the pages of text, the value of
“1” indicating the first page of text. Sequencing, if used, shall be assumed to continuously cycle through the
ordered pages of text at a constant rate (the sequencing interval can be specified in the “VmsMessage” class).
6.5.2.4 “VmsTextLine” Class
An instance of the “VmsTextLine” class shall allow a supplier to identify what text is displayed on a single line
in the text display area, or in the supplementary panel area. It also allows the language and the colour of the
text line to be specified, and whether it is flashing or has any special formatting applied to it. Each line of text
can potentially be in a different language which supports the use of multilingual displays.
The “lineIndex” qualifier shall be used to indicate the order of the lines of text, the value of “1” indicating the
top or first line of the text.
6.5.2.5 “VmsPictogramDisplayArea” Class
An instance of the “VmsPictogramDisplayArea” class shall allow a supplier to associate a pictogram or
sequence of pictograms that are being displayed with a specific pictogram display area on the VMS.
— Attribute “synchronizedSequencingWithTextPages” shall be used to indicate that the sequence of
pictograms defined for display on this pictogram display area is sequenced in synchronism with the
sequence of text pages on the text display area. If there is a mismatch in the number of text pages and
pictograms, the sequences shall be assumed to resynchronize at the start of each sequence.
The “pictogramDisplayAreaIndex” qualifier shall be used to indicate which pictogram display area is being
referenced, the value of “1” notionally indicating the most important pictogram display area. (for the meaning
of importance refer to Note on 6.3.2.6)
6.5.2.6 “VmsPictogram” Class
An instance of the “VmsPictogram” class shall allow a supplier to identify the pictogram which is currently
displayed or which is in a sequence of pictograms that are currently being displayed in the specified pictogram
display area on the VMS.
— Attribute “viennaConventionCompliant” shall be used to indicate that the pictogram is consistent with
one defined in the Vienna Convention on road signs and signals as modified by “UNECE Consolidated
Resolution on Road Signs and Signals”.
The “pictogramSequencingIndex” qualifier shall be used to indicate the order of sequencing of the pictograms,
the value of “1” indicating the first pictogram in the sequence. Sequencing, if used, shall be assumed to
continuously cycle through the ordered sequence of pictograms at a constant rate (the sequencing interval
can be specified in the “VmsMessage” class).
6.5.2.7 “VmsSupplementaryPanel” Class
An instance of the “VmsSupplementaryPanel” class shall allow a supplier to identify what is displayed on the
panel which is supplementary to a pictogram display area (normally below it). A supplementary panel may
display one line of text and/or a single supplementary pictogram. A textual description of what is displayed in
the supplementary panel may be provided in this class.
6.5.2.8 “VmsSupplementaryPictogram” Class
An instance of the “VmsSupplementaryPictogram” class shall allow a supplier to identify what pictogram is
displayed on the supplementary panel. This will normally be one from a limited set.
7 The VMS Table Publication model
7.1 Overview of the VMS Table Publication model
The VMS Table Publication model shall comprise a top level package, “VmsTablePublication” which utilizes
some classes from the “ReusableClasses” package. This package is one of a number which are immediately
subordinate to the “PayloadPublication” package and hence forms the top of the hierarchy in the VMS
Table Publication sub-model.
The “VmsTablePublication” package shall model the normally static characteristics of VMS units and their
controlled VMSs.
Each “VmsTablePublication” instance shall contain one or more instances of a “VmsUnitTable”, each table
containing a number of “VmsUnitRecords” which relate to deployed VMS units. Each “VmsUnitRecord” shall
contain one or more “VmsRecords” each of which relates to a specific VMS that is controlled by the VMS unit.
Although the characteristics of VMSs and VMS units modelled in this publication are normally static,
sometimes these characteristics change over a period of time. For instance changes do occur in the location
of VMSs when they are of a mobile type or in the number of lines of text if the sign supports variable font
sizes. In these cases, some of the characteristics defined in this publication may be overridden by more up-to-
date information promulgated in a “VmsPublication”. VMS characteristics information provided
...