SIST-TS CEN/TS 17380:2019

SLOVENSKI STANDARD
SIST-TS CEN/TS 17380:2019
01-december-2019
Inteligentni transportni sistemi - Mestni ITS - Upravljanje „nadzorovane cone“ za
UVAR z uporabo C-ITS
Intelligent transport systems - Urban-ITS - 'Controlled Zone' management for UVARs
using C-ITS
Intelligente Verkehrssysteme - Urbane ITS - Urbane ITS - Steuerung in einer
"kontrollierten Zone" unter Verwendung von C-ITS
Systèmes de transport intelligents - ITS urbain - Gestion des zones contrôlées à l'aide du
système C-ITS
Ta slovenski standard je istoveten z: CEN/TS 17380:2019
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
SIST-TS CEN/TS 17380:2019 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
SIST-TS CEN/TS 17380:2019

---------------------- Page: 2 ----------------------
SIST-TS CEN/TS 17380:2019


CEN/TS 17380
TECHNICAL SPECIFICATION

SPÉCIFICATION TECHNIQUE

October 2019
TECHNISCHE SPEZIFIKATION
ICS 03.220.20; 35.240.60
English Version

Intelligent transport systems - Urban-ITS - 'Controlled
Zone' management for UVARs using C-ITS
Systèmes de transport intelligents - ITS urbains - Intelligente Verkehrssysteme - Urbane ITS - Urbane
Gestion des zones contrôlées à l'aide du système C-ITS ITS - Steuerung in einer "kontrollierten Zone" unter
Verwendung von C-ITS
This Technical Specification (CEN/TS) was approved by CEN on 26 August 2019 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, Turkey 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
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 17380:2019 E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Symbols and abbreviations . 6
5 'Controlled Zone' management . 6
6 Use cases . 13
7 Elements of the CZRTM data dictionary . 15
8 Messages and related security . 18
Annex A (normative) ASN.1 module of the CZ data dictionary . 19
Annex B (normative) Service announcement for the ITS application “CZ Management” . 24
Annex C (normative) LDM data objects for CZ management . 25
Bibliography . 26
2

---------------------- Page: 4 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)
European foreword
This document (CEN/TS 17380:2019) 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.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
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, Turkey and the United
Kingdom.
3

---------------------- Page: 5 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)
Introduction
This document is part of a set of standards related to Urban ITS (U-ITS). An overview on U-ITS
[3]
requirements is provided in CEN/TR 17143 , which was developed under the European Commission's
[1]
mandate M/456 . Technologies already developed for Cooperative ITS (C-ITS) under the European
[2]
Commission's mandate M/453 are applicable for U-ITS.
Management of traffic in a “Controlled Zone” (CZ) is relevant for at least the following reasons:
— Movement of vehicles in cities producing traffic congestion and overcrowding on public transport at
peak periods are issues that a jurisdiction may wish to control in order to allow cities to better
manage the flow of traffic.
— As cities and urban complexes expand, and there is a significant trend from rural areas to cities
around the world, pollution and congestion in these urban areas becomes an ever more significant
problem. Traffic, i.e. vehicle movements within the urban complex, is not the only polluter but is
considered to be a source of pollution; other causes are e.g. air conditioning, central heating systems,
coal and wood burning heating, factories.
A CZ, also referred to as an “Urban Vehicle Access Restriction” (UVAR) zone, is the enactment of a traffic
restriction to adhere to a permanent or temporary regulation applicable in a defined area.
It is recognized that different jurisdictions will design and introduce their own CZ paradigms of different
method and construct. However, independent of the goal to be achieved or the political objective, the
basic technical requirements to manage road traffic in a CZ is similar, and the basic methodologies are
the same.
The methodology specified in this document is referred to as geofencing, i.e. the creation of a virtual
geographic boundary, which, in a strict sense, is part of “Access Control and Enforcement Systems”
(ACES).
4

---------------------- Page: 6 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)
1 Scope
This document provides information and specifications enabling management of road traffic in controlled
zones applying geofencing. Specifically, this document provides
— a “Controlled Zone Data Dictionary” (CZDD) for management of controlled zones providing an
extendible toolkit that regulators can use e.g. to inform potential CZ users, e.g. vehicles, about
— the CZ area, i.e. the geographical boundaries of the CZ;
— CZ access conditions including exempts;
— time windows indicating when these CZ access conditions are applicable, allowing the potential
CZ users to select an appropriate routing, either by pre-trip planning or ad hoc re-routing,
— and illustrations and guidelines on how to use this toolkit.
The toolkit is designed in compliance with the general ITS station and communications architecture
[8]
specified in ISO 21217, and optionally applicable C-ITS protocols and procedures, e.g. ISO 22418:2018
[5]
on “Service Announcement”, EN ISO 18750 on the “Local Dynamic Map”, and EN ISO 17419 on globally
unique identifiers.
Enforcement is out of scope of this document.
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 ISO 18750:2018, Intelligent transport systems — Co-operative ITS — Local dynamic map
ISO 21217:2014, Intelligent transport systems — Communications access for land mobiles (CALM) —
Architecture
1
CEN ISO/TS 21177 , Intelligent transport systems — ITS station security services for secure session
establishment and authentication between trusted devices
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.1
controlled zone
area for which access conditions are applicable

1
Under preparation. Stage at the time of publication: FprCEN ISO/TS 21177
5

---------------------- Page: 7 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)
3.2
CZ area
geographical location of a CZ in terms of precisely defined boundaries
Note 1 to entry: In the context of this document, a CZ area not necessarily is a two-dimensional area, but may be
a location identified with any kind of location referencing method (linear, two-dimensional, three-dimensional).
3.3
CZ user
physical entity, typically a vehicle, that intends operating in a CZ or is already operated in a CZ
3.4
geofencing
creation of a virtual geographic boundary by applying information and communication technologies such
as specified for ITS
3.5
in-vehicle system
ITS-station unit or a navigation device or mobile phone application used in a vehicle being capable to
handle the control zone system transactions
4 Symbols and abbreviations
C-ITS cooperative ITS
CZ controlled zone
ITS intelligent transport systems
ITS-SU ITS station unit
IVI in-vehicle information
IVS in-vehicle system
NOTE Examples are ITS station units or navigation devices
U-ITS urban its
UVAR urban vehicle access restriction
5 'Controlled Zone' management
5.1 General
Central management of traffic flows in a “Controlled Zone” (CZ) is complex, and to date has proven
difficult, and may technically involve downloading data to an “In-Vehicle System” (IVS), e.g. an ITS station
unit (ITS-SU) specified in ISO 21217 or a navigation device, or may be undertaken by control of traffic
signals (for example in a ferry: boarding and customs-controlled zone), or by a combination of both.
Controlling access to urban zones, i.e. applying respective access restrictions, is also referred to as “Urban
Vehicle Access Restriction” (UVAR).
At the time of writing this document, the European Commission is developing a Delegated Regulation
that, for reasons of safety of life issues, will enable or enforce new vehicles to be equipped with ITS-SUs,
from which point ACES geofencing becomes a practical and cost-effective option.
6

---------------------- Page: 8 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)
5.2 CZ manager
In order to identify a CZ and to achieve control of it, an authority, i.e. an entity or body or person, has to
manage the CZ. Within this document that role is called the “Controlled Zone Manager”. In administrative
terms there are many ways this can be instantiated, and that is a matter of local policy, and not
determined in this document.
Every CZ created by a CZ manager shall be globally uniquely identified by a CZ identifier. The CZ identifier
is designed as a universal object identifier (OID).
NOTE Organisations acting as a CZ manager need an OID assigned to them. Subsequent branches, e.g. used for
CZ purposes, are managed by the organization itself. That enables globally unique CZ identifiers without the need
for creating a respective registration authority.
The CZ manager is in charge of disseminating information on existence of its CZs and the related CZ access
conditions such that potential road users are informed in due time about restrictions to access CZ areas.
5.3 Controlled zone
A CZ is defined as a physical location which has restricted access defined by CZ access conditions, see 5.4,
and optional CZ exemptions, see 5.5, including information on timely validity. The location of a CZ, i.e. the
CZ area, may be defined quite differently, e.g. being:
— a linear location, e.g. a street identified by the street name;
— a contiguous two-dimensional area, optionally with “holes”;
— a contiguous three-dimensional space, optionally with “holes”;
— a set of non-overlapping contiguous locations / areas / spaces with or without “holes”;
— one or several identified streets or segments thereof;
— a complete city;
— any other reasonable definition.
However, once the definition of a CZ area changes, the previously valid CZ identifier shall become invalid,
and a new CZ identifier shall be assigned.
The boundary of a CZ shall be designed such that it is outside of the CZ area.
NOTE 1 The examples used in this document are provided as examples of how CZs can be applied and do not
represent accurate representations of current regulations in place at the time of the development of this document.
EXAMPLE The centre of the city of Ulm in Germany is surrounded by streets and segments of streets, see
Figure 1. The boundary of the CZ “centre of the city of Ulm” is given by (1) Bahnhofsplatz, (2) segment of Olgastrasse
between Bahnhofsplatz and Salzstadelgasse, (3) segment of Salzstadelgasse between Olgastrasse and car park
“Salzstadel”, (4) segment of Olgastrasse between Salzstadelgasse and Frauenstrasse, (5) segment of Frauenstrasse
between Olgastrasse and Neue Strasse, (6) segment of Neue Strasse between Frauenstrasse and Friedrich-Ebert-
Strasse, (7) segment of Friedrich-Ebert-Strasse between Neue Strasse and Bahnhofsplatz. CZ users, disregard of the
given CZ access conditions, are allowed to use these streets that define the CZ boundary. This allows also accessing
the car parks located at the boundary of this CZ, e.g. from “Olgastraße” following “Salzstadelgasse” up to “Museum
der Brotkultur”, below which the car park “Salzstadel” is located.
7

---------------------- Page: 9 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)

Figure 1 — Example of CZ “centre of the city of Ulm”
CZs may be
— located adjacent to each other,
— overlapping with other CZs for other control purposes; thus, multiple CZs can exist in the same
physical geographical location.
There may be exemptions applicable for explicitly identified CZ users or CZ user groups, i.e. for preferred
CZ users; see 5.5.
Figure 2 provides an example of three different and overlapping CZs in a city.
8

---------------------- Page: 10 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)

Figure 2 — Co-located control zones
Figure 2 shows a geographical area with three CZs:
— The first, and largest, in this example, is a “diesel engine control zone”, where there is a ban on the
use of diesels prior to Euro Class 5, and time-of-day limitations on the use of any diesel.
— The second CZ is a “vehicle size-controlled zone” that covers an area both inside and outside of the
“diesel engine control zone” (but not all of the “diesel engine control zone”) and prohibits both tall
and heavy or wide vehicle traffic because of narrow roads and low bridges.
— The third CZ is a “zero tailpipe emission zone” in the historic city centre and its main shopping street.
It is located entirely within the two other CZs and controls on the single parameter of zero tailpipe
emissions.
In this example, Folly Ln and Verulamium Park would be associated with three CZ identifiers so that the
route enquiry would work through the three CZ requirements, whilst most of Camp road and part of
Victoria street would be associated with two CZ identifiers, and Redbourn Road and most of Prospect
Road would be associated only with one CZ identifier as would Harpenden road and most of Sandpit lane.
Note that, in this example, the “diesel engine control zone” covers multiple factors in respect of diesel
vehicles. The “vehicle size-controlled zone” covers height, weight, and width restriction in a common zone
that is in part within the “diesel engine control zone” and part outside the “diesel engine control zone”.
(overlapping CZs).
The CZ user thus has to evaluate up to three sets of CZ access conditions, see 5.3, of up to three CZs. The
result will be the granted access conditions.
This document does not impose any design requirements on CZ managers. Thus, CZ managers have the
free choice on how to define CZs and the related CZ access conditions, e.g. whether they define a new CZ
per CZ access condition, or whether they define several CZ access conditions per CZ, if applicable. With
9

---------------------- Page: 11 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)
reference to the example in Figure 2, instead of defining three overlapping CZs, the CZ manager could also
specify four CZs:
1) Diesel engine CZ access condition (black-only);
2) Height and weight CZ access condition (blue-only);
3) Diesel engine and height and weight CZ access conditions (only black and blue);
4) Diesel engine and height and weight and zero emissions CZ access conditions (black, blue and red).
NOTE 2 It is assumed that calculating the presence in a CZ is more time-consuming than evaluating several CZ
access conditions.
5.4 CZ access conditions
Identification of CZ access conditions is, at its uppermost simple core a binary option of “allowed” or
“prohibited”. However, a more complex approach is favourable, indicating one or several reasons why
access to a CZ is restricted. This approach enables conditional access to a CZ, dependent on the CZ access
conditions and the properties of a CZ user. CZ access conditions include:
— “allowed”:
This indicates that there are currently no access conditions applicable for the given CZ.
— “prohibited”:
This indicates that currently the access to the CZ is prohibited in general without mentioning a
specific reason.
— “prohibited for CZ users (vehicles) with given properties”:
This shall be used to indicate one or several conditions under which operation in a CZ is prohibited.
Only if all presented conditions result in a final “access is allowed”, or appropriate exemptions are
given, the CZ user may operate inside the CZ.
— “unknown”:
This is not an operational CZ access condition to be presented by the CZ manager to CZ users. It
complements the operational ones and can be useful in software for different purposes.
EXAMPLE 1 The CZ access condition “prohibited for CZ users (vehicles) with given properties” can contain a
restriction related to emissions of a vehicle and a restriction for vehicles with a total weight exceeding a defined
limit. Operation in the CZ thus is only allowed if neither the emissions of the CZ user are above the given limit, nor
the total weight of the CZ user exceeds the given limit.
EXAMPLE 2 Powertrain management is a special case of air quality management. In the case of hybrid vehicles,
the CZ manager or the CZ regulation can set up a CZ access condition that hybrid vehicles can enter and operate
within the CZ, but only in a tail-pipe emission free mode (i.e. electric).
EXAMPLE 3 A CZ may be generally closed due to an event.
Further access conditions may be defined at a later stage as amendment to this document or in a revision
of this document.
Although in case CZ access conditions indicate access restrictions for a specific CZ user or CZ user group,
access to the CZ may be granted on the basis of explicit CZ exemptions, see 5.5. Every CZ access condition
10

---------------------- Page: 12 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)
presented by a CZ manager thus also shall contain information on whether CZ exemptions are applicable
for a specific CZ access condition.
EXAMPLE 4 A CZ defined for a public festivity may be closed for all kinds of CZ users with the exemption of
public transport, suppliers' registered vehicles, ambulance, fire brigade and police.
CZ access conditions shall be made available to potential CZ users, e.g. vehicles or their operators, by CZ
managers allowing the CZ users to have a respective routing decision, see 5.6. This involves
communications, e.g. either for pre-trip planning using the Internet, or for real-time routing using
wireless communications between central stations or roadside furniture and mobile stations such as ITS-
SUs or navigation devices, or observations of message signs by vehicle operators.
A change of CZ access conditions shall not invalidate the respective CZ identifier. However, the time of an
update of access conditions shall be reported, see 7.2, such that a receiver of this information can
distinguish between a previous reception of information on this CZ and a subsequent update of this
information.
A certain complexity can lie in the evaluation of CZ access conditions presented by CZ managers to the
potential CZ users and the decision process that determines the finally applicable granted access
conditions (“allowed” / “prohibited”) for a specific geographic location, which might also include real-
time measurements of parameters of a vehicle, e.g. parameters related to the emissions of a vehicle's
engine. This process may require evaluation of several sets of CZ access conditions received from one or
several CZ managers for different CZs.
NOTE How such an evaluation and decision process is to be implemented is out of scope of this document.
5.5 CZ exemptions
The term “exemption” is used in this document for two slightly different circumstances, both resulting in
the fact that a CZ user may operate in a CZ although basically applicable access restrictions are defined
by means of the CZ access conditions:
a) the properties of a CZ user do not violate the CZ access conditions, i.e. no access restrictions apply,
which is an “implicit exemption”;
b) the properties of a CZ user indicate a conflict with the CZ access conditions, however an exempt is
granted by the CZ manager for a given CZ access condition, which is an “explicit exemption”; such CZ
users are referred to as 'preferred CZ users'.
Explicit exemptions may be applicable for any CZ user, or may be granted to individual CZ users or CZ
user groups. Possible explicit exemptions are e.g.:
— “allowed to leave the CZ”;
— “allowance is subject to a fee”;
— “allowed for a maximum time being in the CZ starting from the time when entering the CZ”;
Possible explicit exemptions applicable for specific CZ user groups are:
— “allowed for vehicles of special type or with special characteristics”, e.g.
— police;
— ambulance;
— fire brigade;
11

---------------------- Page: 13 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)
— military;
— vehicles with even licence plate number;
Possible explicit exemptions applicable for specific CZ users are:
— “allowed for users (vehicles) with a registered exemption”, e.g.
— resident of a CZ;
— disabled driver.
Explicit exemptions may be stored in an IVS in a secure way, or just certified by means of a written
document.
Preferred CZ users shall be allowed on any route within the CZ regardless of any CZ access condition
other than those limiting the physical capabilities of a route, e.g. weight, height, width or exceptional
conditions that are not specified in this document.
An online database containing registered exemptions allows for different types of enforcement. A CZ user
should be prepared to prove that its operation in the CZ is allowed.
Some of these explicit exemptions, in order to be enforceable by an enforcement system authorized by
the CZ manager, can require e.g.
— proof of initial conditions of the CZ user, e.g. its start location;
— contracts, e.g. for payment of fees;
— CZ user (vehicle) registration;
— proof of start time of trip and time of leaving the CZ.
However, enforcement options are out of scope of this document and may be provided in other standards
deliverables. However, in any event enforcement options are the subject. of requirements of regulations.
5.6 Resultant behaviour
The action to be taken upon awareness of a specific CZ and its related CZ access conditions and
exemptions is that a CZ user:
— may continue with its originally intended routing, or
— shall re-plan and change its routing in order not to violate regulatory access restrictions.
Basic routing paradigms are identified in 5.7. However, how re-routing is achieved is beyond the scope
of this document.
5.7 Routing paradigms
There are three principal paradigms of vehicle routing to follow predetermined or dynamically advised
regulatory information on CZs:
a) (MANUAL): manual routing by the CZ user, e.g. the driver of a vehicle, using devices that are not
connected to the vehicle, such as smart phones;
b) (AUTOMATIC): routing based on final decisions performed by an “In-Vehicle System” (IVS), i.e. an
electronic device installed in the vehicle;
12

---------------------- Page: 14 ----------------------
SIST-TS CEN/TS 17380:2019
CEN/TS 17380:2019 (E)
c) (CZM): routing performed by the operator of a vehicle as requested by the CZ manager, i.e. accepting
the routing requirement presented by the CZ manager.
NOTE 1 The term “vehicle routing” basically includes all types of vehicles that may be operated on roads.
For all three paradigms, the basic information on routing is provided by the CZ manager.
Paradigm a) (MANUAL) allows a human to come to the final routing decision, which easily enables
violation of access restrictions.
Paradigm b) (AUTOMATIC) uses the IVS to come to a final routing decision. Respective routing software
shall correctly implement CZ access conditions such that no violation of access restrictions occurs, and
may follow a routing proposal optionally presented by the CZ manager.
In Paradigm c) (CZM), which is a variant of paradigms a) and b), the operator of the vehicle accepts an
optional specific routing proposal provided by the CZ manager.
NOTE 2 “Operator of a vehicle” can be a human or an electronic device in an automated or autonomous vehicle.
For all three routing paradigms, the routing decision may depend on measurements. Measurements can
be applicable e.g. to CZs for air quality management.
5.8 Controlled zone road traffic management data dictionary
This document provides a “Controlled Zone Data Dictionary” (CZDD) as a general toolkit of standardized
data sequences that can be selected, complemented, and used by a jurisdiction to enable that jurisdiction
to develop and implement its control objectives (rather than to provide a single use-case dependent
solution). Complementary and associated standards deliverables may extend this general toolkit to
provide specific data sequences for particular aspects of CZ management.
One or several data sequences may be combined in a message. Respective messages being exchanged
between communication devices are part of the general urban traffic management message set specified
[4]
in CEN/TS 17241 .
The ASN.1 specification of the CZDD is provided in Annex A. Additional explanations and specifications
are provided in Clause 7.
6 Use cases
6.1 General
Clause 6 illustrates in a non-comprehensive way several use cases of road traffic management for CZs.
For some use cases, appropriate data and messages are specified in this document.
6.2 Pre-trip planning
Many ways of pre-trip planning exist, and thus different approaches for communicating CZ access
conditions from CZ managers to CZ users can apply such as:
a) human investigations, using e.g. street maps printed on paper and Internet access to a server
providing CZ access conditions;
b) routing software, such as Internet map services for routing, that get CZ
...