Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 13: Status, fault and quality requirements

The proposed Part 13 will specify a DATEX II platform-independent model for expression of intelligent transport system device status and fault data. It will follow the EN 16157-1 methodology and reuse common concepts from EN 16157-2 and EN 16157-7.
It will define a UML model with a corresponding data dictionary and XML Schema.
The model will define a device publication which identifies static data, a device status publication, and a device faults publication.
Devices in scope are any that participate in intelligent transport systems.
This specification may be used in system-to-system exchanges about device status and faults, for example a traffic management system that performs operational control of devices may provide information about the status and faults of those devices to a separate technology status and fault management system.

Intelligente Verkehrssysteme - Verkehrsmanagementsysteme - Status-, Fehler- und Qualitätsanforderungen

Systèmes de transport intelligents - systèmes de gestion du trafic - Exigences en matière d'état, de défauts et de qualité

Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri upravljanju prometa in informiranju - 13. del: Zahteve glede stanja, napak in kakovosti

Ta dokument določa podatkovne modele za stanje in napake komponent sistemov upravljanja prometa.
Podatkovni model je namenjen izmenjavi podatkov med sistemi za namene upravljanja stanja in napak naprav.

General Information

Status
Published
Publication Date
01-Apr-2025
Current Stage
6060 - Definitive text made available (DAV) - Publishing
Start Date
02-Apr-2025
Due Date
08-Jun-2025
Completion Date
02-Apr-2025

Relations

Technical specification
TS CEN/TS 16157-13:2025 - BARVE
English language
67 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)


SLOVENSKI STANDARD
01-junij-2025
Nadomešča:
SIST-TS CEN/TS 17241:2019
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
upravljanju prometa in informiranju - 13. del: Zahteve glede stanja, napak in
kakovosti
Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 13: Status, fault and quality requirements
Intelligente Verkehrssysteme - Verkehrsmanagementsysteme - Status-, Fehler- und
Qualitätsanforderungen
Systèmes de transport intelligents - systèmes de gestion du trafic - Exigences en matière
d'état, de défauts et de qualité
Ta slovenski standard je istoveten z: CEN/TS 16157-13:2025
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TS 16157-13
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
April 2025
TECHNISCHE SPEZIFIKATION
ICS Supersedes CEN/TS 17241:2019
English Version
Intelligent transport systems - DATEX II data exchange
specifications for traffic management and information -
Part 13: Status, fault and quality requirements
Systèmes de transport intelligents - systèmes de Intelligente Verkehrssysteme -
gestion du trafic - Exigences en matière d'état, de Verkehrsmanagementsysteme - Status-, Fehler- und
défauts et de qualité Qualitätsanforderungen
This Technical Specification (CEN/TS) was approved by CEN on 3 February 2025 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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16157-13:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Symbols and abbreviated terms . 6
5 UML notation . 6
6 The FaultAndStatus namespace . 6
6.1 Overview of the FaultAndStatus nameapce . 6
6.2 Device publication . 7
6.2.1 Overview . 7
6.2.2 DevicePublication . 8
6.2.3 DeviceTable . 8
6.2.4 Device . 8
6.2.5 PhysicalDeviceDetails . 8
6.2.6 Component . 9
6.3 Device status publication . 9
6.3.1 Overview . 9
6.3.2 StatusPublication . 9
6.3.3 StatusOfAllDevicesFromTable . 10
6.3.4 Status . 10
6.3.5 OperationalState . 11
6.3.6 DevicePower . 11
6.4 Device faults publication . 11
6.4.1 Overview . 11
6.4.2 FaultPublication . 12
6.4.3 FaultsOfAllDevicesFromTable . 12
6.4.4 AllFaultsOfSingleDevice . 12
6.4.5 DeviceFault . 13
6.5 Classes . 13
6.5.1 Overview . 13
6.5.2 DeviceTableReference . 14
6.5.3 GeneralDeviceTableReference . 14
6.5.4 VmsUnitTableReference. 15
6.5.5 MeasurementSiteTableReference . 15
6.5.6 DeviceReference . 15
6.5.7 GeneralDeviceReference . 15
6.5.8 VmsUnitReference . 15
6.5.9 MeasurementSiteReference . 15
6.5.10 CatalogueInformation . 15
6.6 DataTypes . 15
Annex A (normative) Data Dictionary . 17
Annex B (normative) XML Schema . 40
Annex C (normative) Additional common datatypes . 65
Bibliography. 67
European foreword
This document (CEN/TS 16157-13:2025) 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 shall not be held responsible for identifying any or all such patent rights.
The CEN 16157 series consists of several parts under the general title “Intelligent transport systems —
DATEX II data exchange specifications for traffic management and information”.
This document supersedes CEN/TS 17241:2019.
CEN/TS 16157-13:2024 includes the following significant technical changes with respect to
CEN/TS 17241:2019:
• The status and faults model has been upgraded to improve fit with other parts in the CEN 16157
series, avoiding duplication, to add further functionality, and to clarify concepts.
• The illustration of quality and performance criteria included in CEN/TS 17241:2019 (as Clause 5) is
not included here.
• The explicit ASN.1 specifications of CEN/TS 17241 are not included here (equivalent ASN.1
specifications can be derived from this CEN/TS).
• The annex on management of electronic traffic regulations is not included here.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the
United Kingdom.
Introduction
This document defines a common set of data exchange specifications to support the vision of a seamless
interoperable exchange of road 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 interoperability, reduction of risk,
reduction of the cost base, promotion of open marketplaces and many social, economic and community
benefits to be gained from more informed travellers, network managers and transport operators.
Deploying intelligent transport systems in line with European Sustainable and Smart Mobility Strategy
as issued by the European Commission requires co-ordination of traffic management operation and
development of seamless pan-European information services. These jointly aim at contributing to the
transformation of the European transport system for the objectives of efficient, safe, sustainable, smart
and resilient mobility.
In this context the European Commission has been supporting the development of information
exchange between the actors of road traffic management and related services for several 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 of the further evolution of the
standard and user support ecosystem. With this standardization of DATEX II, there is a real basis for
common exchange between the actors of the traffic and travel information sector both in the
collaboration between traffic management organisations and their systems, as well as in coherent
information provision to service providers. DATEX II supports the requirements of the stakeholder
organisations involved in the road traffic and travel domain in compliance with the EU policy and legal
frameworks aimed at the sector.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
1 Scope
This document specifies a data model for the status and faults of components of traffic management
systems.
The data model is intended for use in system-to-system data exchanges for device status and fault
management purposes.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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.
EN 16157-1:2018, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 1: Context and framework
EN 16157-2:2019, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 2: Location referencing
EN 16157-7:2018, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 7: Common data elements
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1) — Part 1: Specification
of basic notation
ISO/IEC 9834-1, Information technology — Procedures for the operation of object identifier registration
authorities — Part 1: General procedures and top arcs of the international object identifier tree
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 16157-1:2018,
EN 16157-2:2019, EN 16157-7:2018, ISO/IEC 8824-1, ISO/IEC 9834-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1
device
logical object, realised by physical equipment, at a known location, that is desired to deliver a service
Note 1 to entry: the definition does not apply in the context of the term “physical device”.
Note 2 to entry: in the context of this document a device is a logical object which could be realized by different
physical objects at different points in time, for example if a faulty item is replaced by a spare of the same type.
3.2
status
capability of a device or system to perform its functions at a given point in time, considering its inherent
technical condition, the externally determined operational setting, and the state of any essential
support systems
3.3
fault
failure or deficiency in a device or system that indicates a potential or actual change of status in which
the capability to perform functions is reduced
4 Symbols and abbreviated terms
UML Unified Modelling Language
XML eXtensible Markup Language
5 UML notation
This document includes diagrams using the UML notation as defined in ISO / IEC 19505-1 [1].
NOTE Some introductory guides to UML 2 are provided in the Bibliography of EN 16157-1:2018
6 The FaultAndStatus namespace
6.1 Overview of the FaultAndStatus nameapce
The < > named FaultAndStatus shall be as defined in this Clause 6 and the Annex A.
The namespace shall reside in the PayloadPublication package defined in EN 16157-1:2018.
The short namespace prefix that may be used in platform-specific realizations is “fst”.
The namespace relies on elements from both the Common namespace defined in EN 16157-7:2018 and
the LocationReferencing namespace defined in EN 16157-2:2019, as illustrated in Figure 1.

Figure 1 — Namespace dependencies of the FaultAndStatus namespace
The FaultAndStatus namespace contains the following sub-packages:
— “Classes” package, defining classes that may be used in other sub-packages,
— “DataTypes” package, defining new datatypes,
— “DevicePublication”, defining the structure of device publications,
— “Enumerations”, defining enumerated types,
— “FaultPublication”, defining the structure of device fault publications,
— “StatusPublication”, defining the structure of device status publications.
6.2 Device publication
6.2.1 Overview
The DevicePublication package contains classes defined in this subclause 6.2, as illustrated in Figure 2.
The DevicePublication constructs are designed for use when no more specific kind of device publication
(such as a VmsPublication as defined in EN 16157-4) is needed.

Figure 2 — DevicePublication
6.2.2 DevicePublication
A DevicePublication contains information on a collection of devices, either directly or via one or more
DeviceTable objects. The DevicePublication identifies devices that exist and provides their location and
optionally further static (or infrequently changing) information.
A single device may use this structure to transmit information about itself to a central system by a
DevicePublication containing exactly one Device object.
In a centre-to-centre communication use case, one or more DeviceTable objects may be used to group
device information along with metadata. Each version of a DeviceTable shall always contain a snapshot
of all relevant devices for this table. Devices no longer included in the DeviceTable are treated as no
longer existent.
A single DevicePublication object should contain either DeviceTable objects or Device objects directly
without DeviceTables, not both.
A DevicePublication inherits the properties of the PayloadPublication class defined in EN 16157-7:2018
and shall include header information in the format defined in that document.
6.2.3 DeviceTable
A DeviceTable contains one or more objects describing devices. It may also include a name for the table,
and it may include identification of the authority accountable for the table, if different from the
information manager identified within the PayloadPublication.
The class DeviceTable is < > as defined in EN 16157-1:2018.
6.2.4 Device
A Device object contains static (or infrequently changing) information about a logical device that
delivers a service. For example, if one physical device fails and is replaced at the same location by
another physical device of the same kind that had been held as a spare, then these are not two separate
Device objects, they are only physical devices that are at different times associated with the same single
logical Device. A Device object may include one PhysicalDeviceDetails object to describe the physical
device that currently realizes the logical service.
Where this document says “device” without saying “physical device”, it intends to signify the logical
device that delivers the service.
The class Device is < > as defined in EN 16157-1:2018, which allows device
objects to be referenced in fault publications and in status publications.
A Device object may identify one or more other Devices upon which it depends to deliver its service.
A Device object may identify an accountable authority, if different from that specified for the table or
publication.
A Device object shall provide its location as a PointLocation as defined in EN 16157-2:2019.
A Device object shall identify the type of Device, which shall be selected from the list defined for
DeviceTypeEnum in Annex A.
A Device object may provide one or more Component objects that each describes a component of the
device.
A Device object may identify an IP address and port number, using datatypes defined in Annex C.
6.2.5 PhysicalDeviceDetails
A PhysicalDeviceDetails object contains information that is specific to the physical device that realizes a
logical device service. The information aids identification and may include dates of manufacture and
installation.
6.2.6 Component
A Component is a part of a Device, and is itself a kind of Device, so it is possible to express multiple
levels of composition. A Component object shall identify the type of component, which shall be selected
from the list defined for ComponentTypeEnum in Annex A. Since a Component object is a kind of Device
it can include the same kinds of information as can be expressed for a Device. Its typeOfDevice will
typically be “other”, with the more specific type of component is as expressed in its componentType
property.
6.3 Device status publication
6.3.1 Overview
The StatusPublication package contains the classes defined in this subclause 6.3, illustrated in Figures 3
and 4, which concern the status of devices.

Figure 3 — StatusPublication
6.3.2 StatusPublication
A StatusPublication contains information on the status of one or more devices. It may do this either by
providing one or more Status objects directly or by providing a collection of status for one or more
whole tables of devices using the StatusOfAllDevicesFromTable class.
Each object conveying dynamic status shall include a reference to a static information counterpart: a
Status object refers to a Device via a DeviceReference, while a StatusOfAllDevicesFromTable object
refers to a DeviceTable via a DeviceTableReference.
A StatusPublication inherits the properties of the PayloadPublication class defined in EN 16157-7:2018
and shall include header information in the format defined in that document.
6.3.3 StatusOfAllDevicesFromTable
A StatusOfAllDevicesFromTable provides the status of all devices in a device table. It refers to the device
table via a DeviceTableReference object and should include one Status object for every device in the
corresponding device table.
6.3.4 Status
A Status object holds dynamic information on the status of a device, as illustrated in Figure 4. This shall
include at least a classification of health (ability to provide the service), selected from the list defined for
DeviceHealthEnum in Annex A, and the date and time of the last status update.

Figure 4 — Status, part of StatusPublication
A Status object shall identify one associated device using a DeviceReference object.
A Status object may also provide an OperationalState object with a classification of operational state, a
CatalogueInformation object linking to status information via an external catalogue, and/or one or more
DevicePower objects - potentially one for each kind of alternative power source possessed by the
associated device.
A Status object may also link to information on faults of the associated device, via one or more
versioned references to specific objects of type Fault, using the versioned reference scheme defined in
EN 16157-1:2018.
A Status object may also provide textual descriptions of the device status, and/or the time of the last
status change.
6.3.5 OperationalState
OperationalState concerns the operational state into which a device has been placed, which is distinct
from the health of the device. An operational state is typically reached after a decision, whether by a
human or a machine, in contrast to device health which may be the result of some unintended and
unexpected fault or other occurrence. The operational state classification shall be selected from the list
defined for OperationalDeviceStateEnum in Annex A.
An OperationalState object may also provide textual descriptions of the operational state, time
metadata, and/or a CatalogueInformation object linking to operational state information via an external
catalogue.
6.3.6 DevicePower
DevicePower provides a classification of the health of the power source for a Device, for a specified kind
of power source. The classification of health shall be selected from the list defined for
DeviceHealthEnum, while the classification of kind of source shall be selected from the list defined for
PowerSourceEnum, both in Annex A.
6.4 Device faults publication
6.4.1 Overview
The FaultPublication package contains the classes defined in this subclause 6.4, illustrated in Figures 5
and 6, which concern faults of devices.
Figure 5 — FaultPublication
6.4.2 FaultPublication
A FaultPublication contains information on faults of one or more devices. It may do this either by
providing fault information for a whole DeviceTable, or directly for one or more individual devices. In
both cases the fault information is provided via the AllFaultsOfSingleDevice class.
A StatusPublication inherits the properties of the PayloadPublication class defined in EN 16157-7:2018
and shall include header information in the format defined in that document.
6.4.3 FaultsOfAllDevicesFromTable
A FaultsOfAllDevicesFromTable provides faults for all devices in one device table. It refers to its device
table via a DeviceTableReference object and should include one AllFaulltsOfSingleDevice object for
every device in the corresponding device table.
6.4.4 AllFaultsOfSingleDevice
An AllFaultsOfSingleDevice object shall provide a snapshot of all current fault information for the single
device identified via an associated DeviceReference object, as illustrated in Figure 6.
Figure 6 — AllFaultsOfSingleDevice
6.4.5 DeviceFault
A DeviceFault object describes a single fault of a single Device. DeviceFault inherits the properties of the
Fault class defined in EN 16157-7. In addition a DeviceFault object shall indicate the type of fault
selected from the list defined for FaultTypeEnum in Annex A. It may also provide information on the
impact, the affected component, and even instructions on how the fault can be rectified. A DeviceFault
object may also link to a fault information entry in an external catalogue.
6.5 Classes
6.5.1 Overview
The FaultsAndStatus sub-package entitled “Classes” contains classes for linking objects in device, fault
and status publications to other data. With one exception, these links are to other DATEX II objects
which may be contained in other DATEX II publications. The facilities allow status and faults to be
expressed not just for devices defined in a DevicePublication, but also for devices in other kinds of
publications for more specific kinds of devices. These use the VersionedReference mechanism defined
in EN 16157-1:2018. This means that while there is no direct coupling from this FaultAndStatus sub-
model to peer sub-models Vms (EN 16157-4:2021) and RoadTrafficData (EN 16157-5:2020) there is an
intention that constructs from those models are targets as defined in the following subclauses.
Figure 7 — Classes subpackage
6.5.2 DeviceTableReference
A DeviceTableReference provides a reference to a device table. It is an abstract class, so instances must
be created as instances of a specialized subclass. DeviceTableReference is itself a subclass of the
GlobalReference class defined in EN 16157-7:2018.
6.5.3 GeneralDeviceTableReference
GeneralDeviceTableReference is a concrete subclass of DeviceTableReference which provides a
VersionedReference attribute to reference a device table which may be in another publication. The
intended target class of the reference is DeviceTable.
6.5.4 VmsUnitTableReference
VmsUnitTableReference is a concrete subclass of DeviceTableReference which provides a
VersionedReference attribute to reference a table of VMS controllers which may be in another
publication. While there is no direct coupling, the intended target class of the reference is
VmsControllerTable (EN 16157-4:2021).
6.5.5 MeasurementSiteTableReference
MeasurementSiteTableReference is a concrete subclass of DeviceTableReference which provides a
VersionedReference attribute to reference a table of measurement sites which may be in another
publication. While there is no direct coupling, the intended target class of the reference is
MeasurementSiteTable (EN 16157-5:2020).
6.5.6 DeviceReference
A DeviceReference provides a reference to a device. It is an abstract class, so instances must be created
as instances of a specialized subclass. DeviceReference is itself a subclass of the GlobalReference class
defined in EN 16157-7:2018.
6.5.7 GeneralDeviceReference
GeneralDeviceReference is a concrete subclass of DeviceReference which provides a
VersionedReference attribute to reference a device object which may be in another publication. The
intended target class of the reference is Device.
6.5.8 VmsUnitReference
VmsUnitReference is a concrete subclass of DeviceReference which provides a VersionedReference
attribute to an object representing a VMS controller which may be in another publication. While there is
no direct coupling, the intended target class of the reference is VmsController (EN 16157-4:2021).
6.5.9 MeasurementSiteReference
MeasurementSiteReference is a concrete subclass of DeviceReference which provides a
VersionedReference attribute to an object representing a measurement site which may be in another
publication. While there is no direct coupling, the intended target class of the reference is
MeasurementSite (EN 16157-5:2020).
6.5.10 CatalogueInformation
CatalogueInformation objects also provide links to other information, but unlike the other classes in the
package, the links do not use the DATEX II referencing mechanism but instead uses an ASN.1 object
identifier conforming to ISO/IEC 8824-1 and ISO/IEC 9834-1. An external information resource that is
indexed by such object identifiers can be considered an information catalogue; a CatalogueInformation
object provides a single object identifier, and a further textual specification of a single element within
the catalogue, the format of text depending on the conventions of the catalogue.
6.6 DataTypes
The DataTypes package contains the datatype ObjectIdentifier. As illustrated in Figure 8,
ObjectIdentifier is a specialization of the String datatype defined in EN 16157-7:2018. An
ObjectIdentifier shall use the dot notation defined in ISO/IEC 9834-1 and ISO/IEC 8824-1.
Figure 8 — DataTypes
Annex A
(normative)
Data Dictionary
A.1 Overview
This data dictionary identifies the definitions and characteristics of the different classes, attributes,
association ends, data types and enumerations appearing in the data model defined in Clause 6. The
data dictionary is specified as a whole, for the whole “FaultAndStatus” package.
The generic data types which are used throughout all publications are defined in EN 16157-7:2018.
The first part of the data dictionary is partitioned into subclauses which relate to each of the UML model
packages and each subclause defines the contained classes, their attributes and any association ends
defined for associations between the classes within that package. Definitions of datatypes and
enumerations follow.
The data dictionary tables use the following columns:
1) Column Class name provides the symbolic name (upper camel case) given to the corresponding
class.
2) Column Association end provides the symbolic name (lower camel case) given to the
corresponding association end.
3) Column Attribute name provides the symbolic name (lower camel case) given to the
corresponding attribute of a class.
4) Column Enumerated value name provides the symbolic name (lower camel case) given to the
corresponding enumerated value.
5) Column Designation provides the corresponding name in natural language of the corresponding
class, attribute, association end or enumeration value.
6) Column Definition provides a comprehensive definition detailing the class, attribute or association
end.
7) Column Stereotype provides a statement of the stereotype that is assigned to the class, if any - see
EN 16157-1:2018, 6.2 for further details.
8) Column Abstract provides a statement as to whether the class is abstract (non-instantiable) or
concrete (instantiable).
9) Column Multiplicity provides a statement of the allowed multiplicity for the attribute or
association end.
10) Column Target provides the name of the class which is at the end of the association to which the
association end applies.
11) Column Type provides the name of the class used to define the data type relating to the attribute of
the class 1.
A.2 Data Dictionary for “FaultAndStatus”
A.2.1 “Classes” package
A.2.1.1 Location of “Classes” package
The location of “Classes” package is:
— D2Payload/PayloadPublication/FaultAndStatus/Classes
A.2.1.2 Classes of the “Classes” package
Table A.1 — Classes of the “Classes” package
Class name Designation Definition Stereotype Abstract
CatalogueInformation Catalogue A reference to specific additional information by means of a D2Class no
information predefined element out of a catalogue. The type of reference
information depends on the data structure this class is aggregated
to.
DeviceReference Device reference A reference to a single device, either by using the VMS-structure or D2Class yes
the MeasurementSitePublication structure or the
DevicePublication structure.
DeviceTableReference Device table A reference to a device table, either by using the VMS- or the D2Class yes
reference MeasurementSitePublication structure or the DevicePublication

structure.
GeneralDeviceReference General device A reference to a device of any type. D2Class no
reference
GeneralDeviceTableReference General device A reference to a table of devices of any type. D2Class no
table reference
MeasurementSiteReference Measurement A reference to a measurement site. D2Class no
site reference
Class name Designation Definition Stereotype Abstract
MeasurementSiteTableRefere Measurement A reference to a measurement site table. D2Class no
nce site table
reference
VmsUnitReference VMS unit A reference to a VMS unit record. D2Class no
reference
VmsUnitTableReference VMS unit table A reference to a VMS table. D2Class no
reference
A.2.1.3 Specializations of the “Classes” package
Table A.2 — Specializations of the “Classes” package
Class name Parent Class Name
DeviceReference Common.GlobalReference
DeviceTableReference Common.GlobalReference
GeneralDeviceReference FaultAndStatus.DeviceReference
GeneralDeviceTableReference FaultAndStatus.DeviceTableReference
MeasurementSiteReference FaultAndStatus.DeviceReference
MeasurementSiteTableReference FaultAndStatus.DeviceTableReference
VmsUnitReference FaultAndStatus.DeviceReference
VmsUnitTableReference FaultAndStatus.DeviceTableReference
A.2.1.4 Associations of the “Classes” package
There are no defined associations in the “Classes” package.
A.2.1.5 Attributes of the “Classes” package
Table A.3 — Attributes of the “Classes” package
Class name Attribute name Designation Definition Multiplicit Type
y
CatalogueInformatio catalogueElement Catalogue element A reference to a specific element within 1.1 Common.String
n the specified catalogue. The notation of
this reference also depends on the
specified catalogue.
catalogueReferenceB Catalogue reference The reference to a catalogue by its OID 1.1 FaultAndStatus
yOID by o i d according to ISO/IEC 8824-1:2015 using .ObjectIdentifie
the dot-notation (example: "1.2.250.1"). r
GeneralDeviceRefere deviceReference Device reference A reference to a device of any type. 1.1 Common.Versi
nce onedReference
(fst:Device)
GeneralDeviceTableR deviceTableReferenc Device table A reference to a table of devices of any 1.1 Common.Versi
eference e reference type. onedReference
(fst:DeviceTabl
e)
MeasurementSiteRef measurementSiteRef Measurement site A reference to a measurement site. 1.1 Common.Versi
erence erence reference onedReference
(roa:Measurem
entSite)
MeasurementSiteTab measurementSiteTab Measurement site A reference to a measurement site table. 1.1 Common.Versi
leReference leReference table reference onedReference
(roa:Measurem
entSiteTable)
Class name Attribute name Designation Definition Multiplicit Type
y
VmsUnitReference vmsUnitReference VMS unit reference A reference to a VMS controller record. 1.1 Common.Versi
onedReference
(vms:VmsContr
oller)
VmsUnitTableRefere vmsUnitTableRefere VMS unit table A reference to a VMS controller table. 1.1 Common.Versi
nce nce reference onedReference
(vms:VmsContr
ollerTable)
A.2.2 “DevicePublication” package
A.2.2.1 Location of “DevicePublication” package
The location of “DevicePublication” package is:
— D2Payload/PayloadPublication/FaultAndStatus/DevicePublication
A.2.2.2 Classes of the “DevicePublication” package
Table A.4 — Classes of the “DevicePublication” package
Class name Designation Definition Stereotype Abstract
Component Component Components of a device which have some special interest such as D2Class no
having status and faults of their own
Device Device Static information about a logical device that delivers a service. A D2Versione no
device can announce itself, or the information can be enriched by dIdentifiabl
operators. e
DevicePublication Device publication This publication provides static information about devices, including D2Class no
its point-location. It can be used in case no specific publication for the
type of device is available or suitable. Fault- and StatusPublication can
reference to the specified devices.
Class name Designation Definition Stereotype Abstract
DeviceTable Device table A table of devices grouped by any logical criteria, e.g. all traffic lights D2Versione no
within a certain administrative area. dIdentifiabl
e
PhysicalDeviceDetail Physical device Details of a specific physical device D2Class no
s details
A.2.2.3 Specializations of the “DevicePublication” package
Table A.5 — Specializations of the “DevicePublication” package
Class name Parent Class Name
Component FaultAndStatus.Device
DevicePublication Common.PayloadPublication
A.2.2.4 Associations of the “DevicePublication” package
Table A.6 — Associations of the “DevicePublication” package
Class name Association end Designation Definition Multiplicit Target
y
Device accountableAuthority Accountable Information about the authority 0.1 Common.Intern
authority accountable for this device. Use this ationalIdentifie
attribute only in case it differs from the r
accountable authority of the table of
devices or the information manager
declared within the PayloadPublication.
component Component Components of this device which have 0.* FaultAndStatus
some special interest such as having .Component
status and faults of their own
dependsOn Depends on Other devices (other than components of 0.* FaultAndStatus
this device) whose services this device .DeviceReferen
depends on in order to deliver its service ce
Class name Association end Designation Definition Multiplicit Target
y
physicalDeviceDetail Physical device Physical device details for the associated 0.1 FaultAndStatus
s details Device .PhysicalDevice

Details
pointLocation Point location Point location for the associated Device 1.1 LocationRefere
ncing.PointLoc
ation
DevicePublication device Device Device for the associated 0.* FaultAndStatus
DevicePublication .Device
deviceTable Device table Device table for the associated 0.* FaultAndStatus
DevicePublication .DeviceTable
headerInformation Header information Header information for the associated 1.1 Common.Head
DevicePublication erInformation
DeviceTable accountableAuthority Accountable Information about the authority 0.1 Common.Intern
authority accountable for this table of devices. Use ationalIdentifie
this attribute only in the case where it r
differs from the information manager
declared within the PayloadPublication.
device Device Device for the associated DeviceTable 1.* FaultAndStatus
.Device
A.2.2.5 Attributes of the “DevicePublication” package
Table A.7 — Attributes of the “DevicePublication” package
Class name Attribute name Designation Definition Multiplicit Type
y
Component componentType Component type Type of device component 1.1 FaultAndStatus
.DeviceCompon
entEnum
D
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...