FprCEN/TS 16157-12

• Abstract:

  The proposed CEN/TS 16157-12 of the CEN TS/EN 16157 series will specify publication sub-models within the DATEX II model that support the publication of information about facilities. This is specified as a DATEX II "Facilities" namespace, which is part of the DATEX II platform independent model and hence follows the EN 16157-1 methodology and reuse common concepts that are specified in EN 16157-2 (Location referencing) and EN 16157-7 (Common data elements).; It will define a UML model with a corresponding data dictionary and XML Schema.; These publications of CEN/TS 16157-12 will contain informational structures, relationships, association ends, attributes and associated data types required for publishing information about facilities within the DATEX II framework.

• Status: Not Published
• Publication Date: 11-Nov-2026
• Technical Committee: CEN/TC 278 - Road transport and traffic telematics
• Drafting Committee: CEN/TC 278/WG 8 - Road traffic data (RTD)
• Current Stage: 5060 - Closure of Vote - Formal Approval
• Start Date: 17-Sep-2026
• Due Date: 23-Apr-2026
• Completion Date: 17-Sep-2026
• Directive: Not Harmonized2010/40/EU - Directive 2010/40/EU of the European Parliament and of the Council of 7 July 2010 on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport Text with EEA relevance
• Directive:

  ---

  Not Harmonized2023/1804 - Regulation (EU) 2023/1804 of the European Parliament and of the Council of 13 September 2023 on the deployment of alternative fuels infrastructure, and repealing Directive 2014/94/EU
• Directive:

  ---

  Not Harmonized2023/1804-1 - Regulation (EU) 2023/1804 of the European Parliament and of the Council of 13 September 2023 on the deployment of alternative fuels infrastructure, and repealing Directive 2014/94/EU
• Directive:

  ---

  Not Harmonized2023/1804-2 - Regulation (EU) 2023/1804 of the European Parliament and of the Council of 13 September 2023 on the deployment of alternative fuels infrastructure, and repealing Directive 2014/94/EU
• Ref Project: kSIST-TS FprCEN/TS 16157-12:2026 - Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 12: Facility related publications

• Revises: CEN/TS 16157-12:2022 - Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 12: Facility related publications
• Effective Date: 05-Nov-2024

Overview

FprCEN/TS 16157-12: Intelligent Transport Systems - DATEX II Data Exchange Specifications for Traffic Management and Information - Part 12: Facility Related Publications is a technical specification developed by CEN under the DATEX II suite of standards. This standard defines how information about facilities-such as parking sites, alternative fuel infrastructure, and service facilities-can be published and exchanged within the DATEX II framework. Facility-related data is structured through a dedicated "AfirFacilities" namespace and integrated with other core DATEX II models, enhancing the interoperability, transparency, and accessibility of transport infrastructure information.

Standardization using the DATEX II data model underpins efficient, safe, and sustainable mobility, supporting the European Union’s goal for seamless road traffic and travel information. It facilitates consistent data sharing among road authorities, traffic operators, infrastructure providers, and service providers.

Key Topics

• DATEX II "AfirFacilities" Namespace: A dedicated model supporting comprehensive, structured facility information exchange.
• Facility Class Structure: Provides abstract and concrete ways to define facility characteristics, including status, dimensions, associated supplemental services, and dynamic attributes such as operating hours.
• Integration with Existing Standards: Utilizes methodologies from EN 16157-1 (context and framework), EN 16157-2 (location referencing), and EN 16157-7 (common data elements) for consistency and interoperability.
• Publication Sub-models:
  • Facility and FacilityObject: Define core properties such as identifiers, descriptions, accessibility, location, operating hours, rates, and associated organisations.
  • Dimension: Enables specification of size and capacity attributes (e.g., length, width, height, area).
  • OrganisationPublication: Captures information about owners, operators, and other relevant organisations, with facilities for referencing previously published data.
  • RatesPublication: Supports detailed tariffs and payment structures for facilities, integrating eligibility criteria according to different user types or vehicle characteristics.
  • SupplementalFacility: Documents additional services and equipment (e.g., charging stations, restrooms), including their operational status.
• Structured Data: All informational structures, semantics, and relationships are defined in a UML model and corresponding XML schema, ensuring clarity for software implementations.

Applications

• Traffic Management Systems: Enables real-time sharing of facility statuses, tariffs, and operating hours for road operators and authorities.
• Intelligent Transport Solutions (ITS): Facilitates integrated mobility platforms, improving route planning and user information by including reliable facility data.
• Alternative Fuel Infrastructure: Supports the requirements of Commission Implementing Regulation (EU) 2025/655 for publishing and updating information on alternative fueling stations, enhancing compliance and transparency.
• Parking Management: Standardizes the communication of parking facility data, including eligibility, accessibility, and rates, promoting efficient urban mobility.
• Public and Private Sector Collaboration: Enhances data sharing between public road authorities and private service providers, supporting innovative mobility services and applications.

Related Standards

• EN 16157-1:2018 – DATEX II Data Exchange Specifications for Traffic Management and Information – Part 1: Context and Framework
• EN 16157-2:2019 – DATEX II Data Exchange Specifications for Traffic Management and Information – Part 2: Location Referencing
• EN 16157-7:2018 – DATEX II Data Exchange Specifications for Traffic Management and Information – Part 7: Common Data Elements
• ISO/IEC 19505-1:2012 – UML (Unified Modeling Language) Infrastructure
• ISO 5206-1:2023 – Related to rate structures, referenced for rates model integration

---

FprCEN/TS 16157-12 provides a robust, interoperable facility data model within the DATEX II framework, enabling seamless data exchange for intelligent transport systems, compliance with EU regulations, and fostering open, efficient, and sustainable mobility services across Europe.

SLOVENSKI STANDARD
01-september-2026
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
upravljanju prometa in informiranju - 12. del: Publikacije v zvezi z objekti
Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 12: Facility related publications
Intelligente Verkehrssysteme - Datex-II-Datenaustauschspezifikationen für
Verkehrsmanagement und Verkehrsinformationen - Teil 12: Publikationen von Anlagen
und Einrichtungen
Ta slovenski standard je istoveten z: FprCEN/TS 16157-12
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.

FINAL DRAFT
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
June 2026
ICS
English Version
Intelligent transport systems - DATEX II data exchange
specifications for traffic management and information -
Part 12: Facility related publications
Intelligente Verkehrssysteme - Datex-II-
Datenaustauschspezifikationen für
Verkehrsmanagement und Verkehrsinformationen -
Teil 12: Publikationen von Anlagen und Einrichtungen

This draft Technical Specification is submitted to CEN members for Vote. It has been drawn up by the Technical Committee
CEN/TC 278.
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.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a Technical Specification. It is distributed for review and comments. It is subject to change
without notice and shall not be referred to as a Technical Specification.

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
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. FprCEN/TS 16157-12:2026 E
worldwide for CEN national Members.

Contents
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Symbols and abbreviations . 7
5 Conformance . 7
6 UML notation . 7
7 «D2Namespace» AfirFacilities. 7
7.1 Overview . 7
7.2 «D2Package» Facilities . 8
7.3 «D2Package» Dimension . 13
7.4 «D2Package» OrganisationPublication . 13
7.5 «D2Package» RatesPublication . 16
7.6 «D2Package» SupplementalFacility . 21
7.7 «D2Package» OperatingHoursPublication . 25
7.8 Data types . 28
7.9 «D2Class» Duration value . 29
7.10 «D2Class» AfirFacilityLocation (Address) submodel . 30
Annex A (normative) Data Dictionary for «D2Namespace» AfirFacilities . 32
A.1 Overview . 32
A.2 Data Dictionary for "AfirFacilities" . 33
A.2.1 "DataValues" package . 33
A.2.2 "Dimension" package . 34
A.2.3 "Eligibility" package . 35
A.2.4 "Extensions" package . 40
A.2.5 "Facility" package . 42
A.2.6 "OperatingHoursPublication" package . 48
A.2.7 "OrganisationPublication" package . 52
A.2.8 "Payment" package . 58
A.2.9 "Rates" package . 60
A.2.10 "RatesPublication" package . 69
A.2.11 "Right" package . 70
A.2.12 "SupplementalFacility" package . 73
A.3 Data Dictionary of <> for "AfirFacilities" . 77
A.3.1 Introduction . 77
A.3.2 The <> "AmountOfMoney" . 77
A.3.3 The <> "CurrencyCode" . 77
A.3.4 The <> "Duration" . 77
A.3.5 The <> "SquareMetres" . 77
A.3.6 The <> "TimeZone" . 77
A.4 Data Dictionary of <> for "AfirFacilities" . 77
A.4.1 Introduction . 77
A.4.2 The <> "AccessibilityEnum". 77
A.4.3 The <> "AvailabilityEnum" . 78
A.4.4 The <> "CredentialTypeEnum" . 78
A.4.5 The <> "EnergySourceEnum" . 79
A.4.6 The <> "EquipmentTypeEnum" . 80
A.4.7 The <> "FacilityTypeEnum" . 83
A.4.8 The <> "ImageFormatEnum" . 83
A.4.9 The <> "MeansOfPaymentEnum". 83
A.4.10 The <> "NutsCodeTypeEnum" . 85
A.4.11 The <> "OpeningStatusEnum" . 85
A.4.12 The <> "OperationStatusEnum" . 85
A.4.13 The <> "OrganisationTypeEnum" . 86
A.4.14 The <> "PaymentBrandsEnum". 86
A.4.15 The <> "PaymentModeEnum" . 87
A.4.16 The <> "RateAvailabilityTypeEnum" . 87
A.4.17 The <> "RateLineTypeEnum" . 87
A.4.18 The <> "RateLineUsageConditionsTypeEnum" . 88
A.4.19 The <> "RateTypeEnum" . 88
A.4.20 The <> "RefundTypeEnum" . 89
A.4.21 The <> "ReservationTypeEnum" . 89
A.4.22 The <> "RightTypeEnum" . 89
A.4.23 The <> "ServiceFacilityTypeEnum" . 90
A.4.24 The <> "SurchargeTypeEnum" . 92
A.4.25 The <> "TypeOfIdentifierEnum" . 92
A.4.26 The <> "TypeOfIdentifierEnumExtended" . 92
A.4.27 The <> "UnitOfTimeEnum" . 92
A.4.28 The <> "UserTypeEnum" . 93
Bibliography . 95

European foreword
This document (FprCEN/TS 16157-12:2026) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
This document is currently submitted to the Vote on TS.
This document will supersede CEN/TS 16157-12:2022.
16157-10:2022:
— adding elements to provide support for COMMISSION IMPLEMENTING REGULATION (EU)
2025/655 - Rules for the application of Regulation (EU) 2023/1804 of the European Parliament and
of the Council as regards specifications and procedures relating to the availability and accessibility
of data on alternative fuels infrastructure
— introducing the new namespace AfirFacilities (afac) because of non-backwards compatible model
changes
— further model improvements
— correction of different bugs.

Introduction
This European Standard 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.
Standardisation 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 standardisation 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 sub-model elements within the DATEX II framework that support the
publication of generic information about facilities (e.g. operating hours, rates, information on owners or
operators for facilities like e.g. energy infrastructure stations or parking sites). These model elements
are intended to be used by other publications defined in the CEN/TS / EN 16157 series.
In normative Annex A, the data dictionary for the «D2Namespace» AfirFacilities is specified.
These publications are intended to support the exchange of informational content from road traffic
authorities issuing traffic regulation orders and organisations implementing these orders to other
organisations providing ITS services or onward information exchange.
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 19505-1:2012, Information technology — Object Management Group Unified Modeling Language
(OMG UML) — Part 1: Infrastructure
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 16157-1, EN 16157-2,
EN 16157-7 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.1
facility
any kind of site, building, structure, including also service- or supplemental facilities and equipment
4 Symbols and abbreviations
BLE Bluetooth Low Energy
EU European Union
GUID  Globally Unique Identifier
IP  Internet Protocol
QR code Quick Response code
UML  Unified Modeling Language
URL  Uniform Resource Locator
5 Conformance
This document specifies DATEX II information for facilities, except for the elements that relate to
location information which are specified in EN 16157-2:2019 and the common elements (i.e., shared
between several publications) which are defined in EN 16157-7:2018.
The DATEX II platform independent data model, of which this publication sub-model is a part,
corresponds to the level A model as defined in EN 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 EN 16157-1 and with the
following requirements of the models which are expressed in this part.
6 UML notation
The UML notation used in these Technical Specifications shall be as described in ISO/IEC 19505-1:2012.
NOTE Some introductory guides to UML 2 are provided in the Bibliography of EN 16157-1:2018
7 «D2Namespace» AfirFacilities
7.1 Overview
This namespace shall define a facility class structure with properties that are related to all kind of
facilities, for example, parking sites or energy infrastructure stations.
For some of the elements it shall be possible to specify a separate publication. By this construct, it will
be possible to predefine sets and to reference them later.
The following elements are included in this namespace:
— «D2Package» Facility – An abstract facility class structure that utilises the elements of the hereafter
following packages;
— «D2Package» Dimension – Dimensions of facilities;
— «D2Package» OrganisationPublication – Organisation data with contact information;
— «D2Package» RatesPublication – A generic structure for tariffs and payment;
— «D2Package» SupplementalFacility – Equipment and service facilities supplemental to some origin
facility, offering all facility properties themself;
— «D2Package» OperatingHoursPublication – Operating hours of facilities.
The namespace includes further data types, data values and enumerations that are integral part of the
above model parts.
The prefix of the namespace shall be "afac".
Some of the packages and individual classes used within the “AfirFacilities” namespace reside in the
namespaces “Common” and "Location" defined in EN 16157-7 and EN 16157-2.
The classes, attributes, data types and enumerations that are specific to the namespace "AfirFacilities"
are defined in the normative Annex A.
The classes, attributes, data types and enumerations that are specific to two additional extensions
specified in clause 8 are defined in the normative Annex B.
The XML schema corresponding to this namespace is provided in the normative Annex C.
7.2 «D2Package» Facilities
7.2.1 Overview
The "Facility" and "FacilityObject" class shall form an abstract class structure that utilises the elements
of the hereafter following clauses. Classes from other namespaces may specialise the Facility class to
inherit the features of a facility described in this document – see Figure 1.
Figure 1 — The facility class structure
Example: An EnergyInfrastructureSite from Namespace AfirEnergyInfrastructure (specified in CEN/TS 16157-10)
is a specialisation of a Facility, and thus information on its location, operating hours, specific images and more can
be specified.
The distinction between FacilityObject and Facility (which is a specialisation of FacilityObject) shall
avoid recursion by the means of a SupplementalFacility, which is a specialisation of a FacilityObject
itself.
The "FacilityStatus" and "FacilityObjectStatus" class shall form an abstract class structure in the same
sense described above, focussing on dynamic status information for a facility – see Figure 2.

Figure 2 — The facility status class structure
Example: The class EnergyInfrastructureSiteStatus from Namespace AfirEnergyInfrastructure (specified in
CEN/TS 16157-10) is a specialisation of FacilityStatus, and thus status information on updated operating hours,
faults and more can be specified.
The distinction between FacilityObjectStatus and FacilityStatus (which is a specialisation of
FacilityObjectStatus) shall avoid recursion by the means of a SupplementalFacilityStatus, which is a
specialisation of FacilityObjectStatus itself.
The class FacilityObject shall be of type «D2VersionedIdentifiable». Thus, each facility may be
referenced by id and version. In class FacilityObjectStatus, the mandatory attribute reference of type
VersionedReference shall form the link between static and the dynamic part of the facility model.
NOTE All further classes depicted in Figure 1 and Figure 2 that are not denoted in 7.2.2 will be described in
the later clauses.
7.2.2 Semantics
7.2.2.1 «D2Class» Facility and «D2VersionedIdentifiable» FacilityObject
By the Facility class and its inheritance of the FacilityObject class, a facility may be described with the
following features:
— Basic information: A name, alias, timestamp of last update, a description, information on
accessibility and some additional information;
— Supplemental facility: Some associated service facility or equipment, being itself characterised as a
facility, see 7.6.
— Dedicated parking spaces for this facility with their number and user-specific, if applicable
— URLs of information websites and photos;
— Photos (in binary format);
— Operating hours (including closure information), see 7.7;
— Location reference, as specified in EN 16157-2;
— Owner and operator information, using the Organisation structure, see 7.4;
— Associated facility: A reference to another facility or a short indication of it;
— Rates: Tariffs and payment information, see 7.5;
— Applicable vehicles, as specified by VehicleCharacteristics in EN 16157-7;
— Dimension, i.e. basic information on height, width, length or usable area;
— Amenities, like information on illumination and roof ;
— External identifier
NOTE: For the external identifier, the type of identifier points to the empty enumeration TypeOfIdentifierEnum.
This enumeration may be extended national specific to support national identifiers.
7.2.2.2 «D2Class» FacilityStatus and «D2Class» FacilityObjectStatus
By the FacilityStatus class and its inheritance of the FacilityObjectStatus class, a facility status may be
described with the following features:
— Basic status information: The reference to the static facility object, timestamp of last update, the
opening status, a status description;
— Operating hours (will replace formerly defined operating hours);
— Rates (will replace formerly defined rates);
— A fault;
— Supplemental facility status. As a supplemental facility is a facility itself, each supplemental facility
can be addressed and referenced by the versioned-identifiable mechanism of the FacilityObject.
7.3 «D2Package» Dimension
7.3.1 Overview
The “Dimension” class (see Figure 1) shall support provision of dimension information for a facility or
object.
7.3.2 Semantics
7.3.2.1 «D2Class» Dimension
Each instance of the “Dimension” class may be used to define dimensions (length, width, height, usable
area) of some facility or object, including length, width, height and the usable area.
7.4 «D2Package» OrganisationPublication
7.4.1 Overview
The “OrganisationPublication” package shall support the specification of organisation related
information such as organisation unit and contact information. The information may be specified
directly or by reference (see Figure 3).
By using the «D2Class» "OrganisationPublication", it shall be possible to define tables of organisation
information in advance and reference them later (see Figure 4).
Figure 3 — The “Organisation” class model
Figure 4 — The “OrganisationPublication” package class model
7.4.2 Semantics
7.4.2.1 «D2Class» Organisation
An instance of the abstract "Organisation" class shall be connected to some organisational role
described by the calling association end, for example, 'operator' or 'serviceProvider'.
It shall be specialised by:
— the class "UnknownOrganisation" to specify that the organisation fulfilling this role is unknown;
— the class "UndefinedOrganisation" to specify that organisation fulfilling this role is not (yet) defined;
— the class "OrganisationByReference" to reference previously published organisation information;
— or by the class "AnOrganisation" to specify the corresponding organisation information.
7.4.2.2 «D2Class» AnOrganisation / «D2VersionedIdentifiable» ReferenceableOrganisation
An instance of this class may specify basic information about an organisation, like its name, a
description or its type. An Organisation may have organisation units with further information.
Only in case AnOrganisation was specialised by “ReferenceableOrganisation”, it may be referenced by
using the class "OrganisationByReference".
7.4.2.3 «D2Class» OrganisationUnit
An instance of this class may specify the name and function of an organisation unit, which can be
physically or logically divided. A location (including address), operating hours and contact information
may be supplied.
7.4.2.4 «D2Class» ContactInformation and «D2Class» ContactPerson
An instance of the “ContactInformation” class shall describe detailed information to contact the
organisation unit, like telephone, E-Mail, etc. It may be specialised to specify a specific contact person.
7.4.2.5 «D2Class» OrganisationPublication
By using this class, it is possible to specify information on multiple organisations in the form of a
payload publication to reference it later. The information shall be published by using one or more tables
(class "OrganisationTable").
7.5 «D2Package» RatesPublication
7.5.1 Overview
The “RatesPublication” package shall support provision of information about Rates. The information
may be specified directly or by reference (see Figure 5 and Figure 6).
By using the «D2Class» "RatesPublication", it shall be possible to define tables of rates information in
advance and reference them later (see Figure 7).
NOTE Parts of the Rates-Publication sub-model have been derived/imported from ISO 5206-1:2023, also
known as "APDS-model". For the DATEX II import, some slight adaptions had to be made on this model.
Figure 5 — The “Rates” package class model
Figure 6 — The “Eligibility” class model
Figure 7 — The “RatesPublication” class model
7.5.2 Semantics
7.5.2.1 General semantics
The “RatesPublication” package provides a model for tariffs/fees, for example, for a parking or energy
infrastructure site, including reservations and season tickets. Different rate tables can be defined and
linked with periods and eligibility and quality criteria such as specific users or types of vehicles.
7.5.2.2 «D2Class» Rates
An instance of the abstract "Rates" class shall be specialised by:
— the class "UnknownRates" to specify that the rates are not known;
— the class "UnspecifiedRates" to specify that rates are not (yet) defined;
— the class "FreeOfCharge" to specify the absence of specific rates (no fees to pay);
— the class "GeneralRateInformation" to specify payment methods without defining a specific rate
table;
— the class "RateMatrixByReference" or “RateTableByReference” to reference previously published
rates information;
— or by the class "RateTable" to specify the corresponding organisation information.
7.5.2.3 «D2VersionedIdentifiable» RateTable and Eligibility structure
NOTE This description is basically based on ISO 5206-1:2023.
A RateTable represents a set of charges that are applied to a single set of criteria and a single
RightSpecification for parking or other operations (e.g. delivery permits, rideshare access, etc) at the
Place. Examples of a RateTable are a weekday charge rate scales in a public multi-storey car park. Other
related RateTables might be evening rates and weekend rates. The validity start and end define the
period of validity of a RateTable. If the validity end is not set, the RateTable is considered to be valid
until it is replaced. The rateSupercedeLink attribute may be used to indicate a reference to a previous
RateTable that is being temporarily superseded.
A RateMatrix is defined as an aggregation of instances of RateTable. There are no specific constraints to
the construction of a RateMatrix – it is simply an aggregation of instances of RateTable the data supplier
wishes to provide together. It cannot be assumed that the RateTable in a RateMatrix relate to only one
Place or that they provide any particular semantic meaning as an aggregation of RateTable.
To support the transmission of a RateTable that may contain multiple charging elements, a RateTable
contains one to many RateLineCollection(s). An example could be a RateTable that contains a flat rate
fee for e.g. reservation, plus a tiered time-based rate structure for charging over the time of the session.
Each RateLineCollection represents one of those charging elements. A RateLineCollection is constructed
of one-to-many RateLine.
The RateLine concept is flexible and supports a range of different characterisations, which include:
— Flat rate – where the RateLine is active the applied fee charge is a flat rate, unrelated to the duration
or timing of the parking or other type of session; An example is a flat rate reservation fee for a
session. Flat rate RateLine are defined by use of defining a value, but no use of the durationStart,
durationEnd or incrementingPeriod attributes.
— Flat rate tier – where the applied fee charged is charged in full if the parking or other type of session
indicates that that specific RateLine is active.
Example: in the second hour of a session the fee is 1€ – for any part of that hour.
For a flat rate within a tier the RateLines are defined the time boundary of the tier by use of the
durationStart and durationEnd attributes and the value attribute to define the charge amount. If
used, the incrementingPeriod attribute, in this case, shall be the same as the period between the
durationStart and durationEnd (i.e. there is one increment). Charging is assumed to occur at the
start of each increment.
— IncrementingRate – where the applied fee charged is related to the duration of this specific tier that
has been activated by the parking or other type of Session. This charge type supports a RateTable
that applies for short incrementing periods or time-based small increments of charge.
Example: in the second hour of a Session, charging is done at a rate of 0,05 € every 3 minutes.
For an incrementing rate within a tier, the RateLine defines the time boundary of the tier by use of the
durationStart and durationEnd attributes. The incrementingPeriod and the value attribute indicate the
charge amount of each increment (e.g. 0,05 € each 3 minutes). Charging is assumed to occur at the start
of each increment.
Under most circumstances the start and end of charging periods are fixed and relative to local time (e.g.
between 08:00 and 17:00 weekdays). In some instances, the charging period and related tiers may be
relevant to a specific event. This is indicated by the use of the relativeTimes set to TRUE in the
RateLineCollection and the use of the RelativeTimeRates class. All times are defined relative to the
referenceTimeStart.
The applicable currency is defined in the RateLineCollection.
Individual RateLine support indication of whether tax is applicable within the defined RateTable or
applied in addition to the defined Rate. The level of tax, if included, can be specified as either a
monetary amount or a percentage rate. Taxes may also be applied to a RateLineCollection in a similar
manner. It is common practice for taxes to be applied at the RateLine level – for example, the
application of Value Added Tax (VAT) in Europe which is added to a basic parking fee and declared in
the cost of the parking to the end user.
A RateLineCollection indicates whether the child RateLine are a chargeable tariff or represent a
surcharge, which may be partially or fully refundable.
Each RateTable is applicable to a singular set of criteria and a single RightSpecification. The
specification of the qualifying criteria is specified using Eligibility, see Figure 6.
Eligibility is specified as a collection of individual Qualifications. A Qualification is specified as a test
with any of the attributes in the Qualification class set. In addition, Qualifications can be specified for
other qualifications like for vehicle characteristics as defined in EN 16157-7.
Eligibility may be related or defined by membership. Typically, the Qualification in this case is defined
by the withMembership attribute set to TRUE and the membershipName attribute set to the names of
the relevant memberships (e.g. J-Park frequent users club, shoppers, cinema attendees, event ticket
holders, military, industry specific vehicle, etc).
Additionally, Eligibility may be defined by the use of another RateTable (memberofOtherRateTable set
to FALSE), or if the parker is a member of another specific RateTable (memberofOtherRateTable set to
TRUE), and the rateTableMember set to identify the earlier linked RateTable.
7.6 «D2Package» SupplementalFacility
7.6.1 Overview
The “SupplementalFacility” package (see Figure 8) may support providing detailed information about
available supplemental service facilities or equipment.
By using the class "SupplementalFacilityStatus" it shall be possible to define dynamic status information
on the specified equipment or service facilities (see Figure 2).
Figure 8 — The “SupplementalFacility” package class model
7.6.2 Semantics
7.6.2.1 General semantics
The package “SupplementalFacility” shall describe exactly one type of available supplemental
equipment or one type of service facility.
Available equipment is some infrastructure element that provides a service or capability to users;
Examples are toilets, elevators, internet access or waste bins. Example of service facilities are
restaurants, petrol stations or a truck wash.
The class “SupplementalFacility” shall be abstract and shall be specialised by one instance out of
“SupplementalEquipment” or “SupplementalServiceFacility”.
In the dynamic part of the model, a versioned reference to each element (inherited from FacilityObject,
see 7.2.2.1) may be used to give explicit information about the availability of the specific element.
7.6.2.2 «D2Class» SupplementalFacility
Each instance of the “SupplementalFacility” class shall describe exactly one type of available
supplemental equipment or one type of service facility (here within further called ‘element’).
The element may be enhanced with additional information (sometimes by inheritance of
FacilityObject), for example:
— its number or its availability;
— a description and a comment;
— the name or brand of the service provided;
— accessibility information (e.g. persons with disabilities or wheelchair accessible);
— restriction to particular users;
— operating hours (class “OperatingHours”, see 7.7);
— a fee (class “Rates”, see 7.5);
— its location (class “LocationReference”, defined in EN 16157-2);
— or applicable vehicles, defined by their characteristics (class “VehicleCharacteristics”, defined in EN
16157-7).
The number of the element – with respect to the restrictions mentioned above - may be defined for each
element by the attribute “quantity”.
EXAMPLE 5 toilets, 1 restaurant, 2 toilets for persons with disabilities, 2 toilets for men; note that for each
example one instance of the class “SupplementalFacility” is necessary.
Operating hours for the element may be specified (i.e. a regular time schedule, at which the element
should be available or open). Examples would be the operating hours of toilets or restaurants. Please
note that different operating hours (e.g. for more than one restaurant) require multiple instances of the
“SupplementalFacility” class.
The current availability of the element may be specified in a dynamic model by using the class
“SupplementalFacilityStatus”.
NOTE For supplemental service facilities, it is possible to define the amount of subitems within the
specialisation class. Thus, for example, it is possible to define that there are 5 restaurants with 300 restaurant
places in total or 1 medical facility with 2 surgeries. See Table 1 for details.
For a reference-link between instances of "SupplementalFacility" and "SupplementalFacilityStatus" the
versioned identifiable mechanism and the attribute "reference" of class FacilityObjectStatus shall be
used.
7.6.2.3 «D2Class» SupplementalEquipment
Each instance of the “SupplementalEquipment” class shall define exactly one type of equipment (e.g.
toilets, elevators, wireless internet etc.).
7.6.2.4 «D2Class» SupplementalServiceFacility
Each instance of the “SupplementalServiceFacility” class shall define exactly one type of service facility
(e.g. restaurants, shops etc.) available on or accessible from some origin facility to which it is clearly
related (typically a larger facility, e.g. a parking site). For the latter case, the distance between the origin
facility and this supplemental service facility may be specified with the attribute
“distanceFromOriginFacility”.
The number of subitems for this service facility may be specified (example: total number of restaurant
places). Table 1 shall specify the usage of the attributes “quantity” and “numberOfSubitems” for each
literal of “ServiceFacilityTypeEnum”. If there is a hyphen character in the table, use of the
“numberOfSubitems” attribute is not permitted in this case.
Table 1 — Semantics of the number of additional service facility subitems

7.6.2.5 «D2Class» SupplementalFacilityStatus
An instance of the “SupplementalFacilityStatus” class (see Figure 2) may override the quantity values
for supplemental equipment and/or service facilities of the static part of the model. It may include
current availability information.
EXAMPLE The number of toilets can be temporarily reduced to 5; The number of vacant restaurant seats can
be set to 100.
For a reference-link between instances of "SupplementalFacility" and "SupplementalFacilityStatus" the
versioned identifiable mechanism and the attribute "reference" of class FacilityObjectStatus shall be
used.
7.7 «D2Package» OperatingHoursPublication
7.7.1 Overview
The “OperatingHoursPublication” package uses and extends the “Validity” package defined in
EN 16157-7 to provide a generic structure for operating hours. The information may be specified
directly or by reference (see Figure 9).
By using the «D2Class» "OperatingHoursPublication", it shall be possible to define tables of operating
hours information in advance and reference them later (see Figure 10).
Figure 9 — The “OperatingHours” class model
Figure 10 — The “OperatingHoursPublication” package class model
7.7.2 Semantics
7.7.2.1 General semantics
The “OperatingHoursPublication” package shall support provision of information to describe a time
sch
...