ISO/TR 4445:2021

TECHNICAL ISO/TR
REPORT 4445
First edition
2021-09
Intelligent transport systems —
Mobility integration — Role model of
ITS service application in smart cities
Systèmes de transport intelligents - Intégration de la mobilité -
Schéma d'application des services ITS
Reference number
©
ISO 2021
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 General overview and framework . 3
5.1 Objective . 3
5.2 National variations . 3
5.3 Mandatory, optional and cooperative issues . 3
5.4 Specification of service provision . 3
5.5 Architecture options . 3
6 Concept of operations . 4
6.1 General . 4
6.2 Statement of the goals and objectives of the system . 4
6.3 Strategies, tactics, policies, and constraints affecting the system . 4
6.4 Organizations, activities and interactions among participants and stakeholders . 4
6.5 Clear statement of responsibilities and authorities delegated . 4
6.6 Operational processes for the system . 5
6.6.1 General. 5
6.6.2 Service requirements definition . 5
6.7 Appointment of an approval authority (regulatory) . 5
6.8 In-vehicle system . 5
6.9 User . 5
6.10 Application service . 6
6.11 Big data management entity . 6
6.12 Data aggregator . 6
7 Conceptual architecture framework . 6
7.1 General . 6
7.2 Actors . 6
7.3 Service definition . 8
7.4 Role model architecture . 8
7.4.1 General. 8
7.4.2 Jurisdictions . 9
7.4.3 Application service actors . 9
7.4.4 Service provider(s) .10
7.4.5 The OBE equipment installer .10
7.4.6 The OBE equipment maintainer .10
7.4.7 Approval authority (regulatory) .11
7.4.8 Security credential management system/public key infrastructure .11
7.4.9 Certification authority (digital).12
7.4.10 Application service approval .12
7.4.11 Onboard equipment OBE approval .12
7.4.12 Vehicle user .14
7.4.13 Application service provision .15
8 Communications architecture .15
9 Quality of service requirements .15
10 Test requirements .16
11 Marking, labelling and packaging .16
12 Declaration of patents and intellectual property .16
Annex A (informative) ITS data management architecture .17
Bibliography .36
iv © ISO 2021 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO’s adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
Introduction
Currently, more than 70 % of the world’s people live in cities. The proportion of people living in cities
is rising around the world as civilisations develop and congregate around cities where there are more
employment opportunities. Societies develop more innovatively and rapidly in cities, and they present
better entertainment opportunities, adding to their attraction. The Economist magazine recently
[16]
forecast that by 2045, an extra 2 billion people will live in urban areas . The resulting concentration
of population creates various issues such as road congestion due to an increase in vehicle population
and environmental pollution due to exhaust gas and tyre erosion. These issues have been attributed to
increases in the number of delivery trucks, taxis and town centre traffic and are further exacerbated by
obstacles to the effective use of urban space due to the private ownership of cars (parking lots, street
parking).
The pressures caused by scientific advice that significant action and change of behaviour is needed to
ameliorate the adverse effects of climate change require a more environmentally friendly use of the
transport system.
It is recognized that there is also road infrastructure deterioration, a lack of provision of information
on the use of public transportation, driver shortages due to the increase in the number of elderly people
and the inconvenience of multimodal fare payments, and action to improve the situation is urgently
needed.
The International Data Corporation forecasts that of the USD 81 billion that will be spent on smart city
technology in 2020, nearly a quarter will go into fixed visual surveillance, smart outdoor lighting and
[17]
advanced public transit .
Eventually, this is likely to mean high speed trains and driverless cars. Consultancy McKinsey forecasts
that up to 15 % of passenger vehicles sold globally in 2030 will be fully automated, while revenues in
the automotive sector could nearly double to USD 6.7 trillion thanks to shared mobility (car-sharing,
[18]
e-hailing) and data connectivity services (including apps and car software upgrades) .
Changing consumer tastes are also calling for new types of infrastructure. Today’s city dwellers, for
example, increasingly shop online and expect ever faster delivery times. To meet their needs, modern
urban areas need the support of last-minute distribution centres, backed by out-of-town warehouses.
Therefore, in recent years, in Europe, studies on the development of mobility integration standards have
been active to solve urban problems. There are various movements around the world making efforts to
address these issues. In the United States, ITS technology is used to try to solve these urban problems,
as in the Smart City Pilot Project. Columbus, Ohio has been selected as a smart city pilot project which
is currently being designed in detail. Important key factors here are the core architectural elements
of smart cities, and urban ITS sharing of probe data (also called sensor data), connected cars and
automated driving. In addition, new issues have been recognized with the introduction of the connected
car to the real world in respect of privacy protection, the need to strengthen security measures, big
data collection and processing measures, which are becoming important considerations.
In terms of the effective use of urban space, it is hoped that the introduction of connected cars and
automated driving can significantly reduce the requirements for urban parking lots (redistribution of
road space). If technology can eliminate congestion, the city road area usage can also be minimized and
reallocated (space utilization improvement) to improve the living environment of, and quality of life
in, the city. In addition, the environment around the road will be improved by improving enforcement
(e.g. overloaded vehicles). On the other hand, even in rural areas, it is possible to introduce automated
driving robot taxis and other shared mobility that saves labour (and is therefore more affordable) and
improves the mobility of elderly people.
To achieve this requires the realization of various issues, for example:
— cooperation with harmonization of de-jure standards such as ISO and industry de facto standards;
— recognition of the significance of international standardization (e.g. to reduce implementation
costs);
vi © ISO 2021 – All rights reserved

— recognition of the significance of harmonization activities by countries around the world;
— cooperation and contribution between ISO/TC 22 for in-vehicle systems and ISO/TC 204 for ITS
technology.
As mentioned above, automated driving mobility is expected to play an important role both in cities and
in rural areas. The main effects are, as described above, the reduction of traffic accidents, reduction of
environmental burden, elimination of traffic congestion, realization of effective use of urban space, etc.
ITS technology is an important element for realizing smart cities, and it is important to clearly
understand the role model of ITS service applications when developing standards to achieve these
objectives.
This document gives an important overview of the options for this objective. Considering the emerging
direction of mobility electrification, automated driving and the direction of an environmentally friendly
society, incorporating other urban data such as traffic management into the city management will
improve the mobility of urban society. It is important to consider the creation of a common open role

model for smart city data platforms (such as the ISO 15638 series service framework). Similar platforms
will be necessary for the realization of the future mobility such as automated driving and electrification
of vehicles. A common role model will be developed for all modes of vehicle, including public transport,
general passenger vehicles and heavy vehicles. The incorporation of electronic regulation is especially
important for automated vehicles and it is essential to incorporate it as a core element of urban ITS.
This document describes how ITS data can be presented, interchanged and used by smart cities. This
document does not describe smart city use cases for ITS data in any detail nor does it describe in detail
any specific ITS use cases. It is focused on the generic role model for data exchange between ITS and
smart cities.
The necessary security and data exchange protocols have now been finalized to provide a secure ITS
[5]
interface, with the approval of ISO/TS 21177 , i.e. exchange information with bi-directional protection.
The trust relation between two devices is illustrated in Figure 1.
The relation enables two devices to cooperate in a trusted way, i.e. to exchange information in
secure application sessions, and thus only access data or request data that they have the appropriate
credentials to access.
This document provides the framework within which these transactions can be undertaken.
[5]
NOTE Source: ISO/TS 21177:2019 , Figure 1.
Figure 1 — Interconnection of trusted devices
TECHNICAL REPORT ISO/TR 4445:2021(E)
Intelligent transport systems — Mobility integration —
Role model of ITS service application in smart cities
1 Scope
This document describes a basic role model of smart city intelligent transport systems (ITS) service
applications as a common platform for smart city instantiation, directly communicating via secure ITS
interfaces. It provides a paradigm describing:
a) a framework for the provision of a cooperative ITS service application;
b) a description of the concept of operations, regulatory aspects and options, and the role models;
c) a conceptual architecture between actors involved in the provision/receipt of ITS service
applications;
d) references for the key documents on which the architecture is based;
e) a taxonomy of the organization of generic procedures.
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.
1)
ISO/TS 14812, Intelligent transport systems — Vocabulary
ISO 15638-1, Intelligent transport systems — Framework for collaborative Telematics Applications for
Regulated commercial freight Vehicles (TARV) — Part 1: Framework and architecture
ISO 15638-3, Intelligent transport systems — Framework for collaborative telematics applications for
regulated commercial freight vehicles (TARV) — Part 3: Operating requirements, 'Approval Authority'
procedures, and enforcement provisions for the providers of regulated services
ISO/TS 15638-4, Intelligent transport systems — Framework for cooperative telematics applications for
regulated commercial freight vehicles (TARV) — Part 4: System security requirements
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/TS 14812, ISO 15638-1,
ISO 15638-3 and ISO/TS 15638-4 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 http:// www .electropedia .org/
1) Under preparation. Stage at the time of publication: ISO/DTS 14812:2020.
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
API application programming interface
app application programme
APDU application protocol data unit
ASD alcohol screening device
CA certificate authority
CAN controller area network
CCAM cooperative, connected and automated mobility
C-ITS cooperative intelligent transport system
CONOPS concept of operations
ECU engine control unit
[4]
ExVe extended vehicle (see the ISO 20078 series )
GNSS global navigation satellite system
ITS intelligent transport system
ITS-S intelligent transport system station
ITS-SCU intelligent transport system station communication unit
ITS-SU intelligent transport system station unit
MaaS mobility as a service
OBE on-board equipment
OEM original equipment manufacturer
PKC public key certificate
PKI public key infrastructure
RA registration authority
RAM random access memory
RSE road-side equipment
RV road vehicle
RVU road vehicle user
Rx receive
SAPDU service access point data unit
SCMS security credential management system
2 © ISO 2021 – All rights reserved

SSP secure service provider
TARV telematics applications for ITS service applications
Tx transmit
TLS transport layer security
[3]
UML Unified Modelling Language (see ISO/IEC 19501 )
V2I vehicle-to-infrastructure (communication)
V2V vehicle-to-vehicle (communication)
VRU vulnerable road user
5 General overview and framework
5.1 Objective
This clause describes a generic framework for the provision of cooperative telematics application
services for ITS service applications.
Clause 6 provides the general CONOPS for which this architecture is designed. Clause 7 provides a
framework, role definition and summary of the architecture at a conceptual level. Clause 8 describes
the communications architecture.
5.2 National variations
The instantiation of interoperable on-board platforms for ITS service applications with common
features is expected to vary from country to country, as will the provision of regulated, or supported,
services.
5.3 Mandatory, optional and cooperative issues
5.3.1 This document does not impose any requirements on nations in respect of which services for
ITS service applications countries will require, or which they will support as an option, but provides
a generic common framework architecture within which countries can achieve their own objectives in
respect of application services for ITS-supported service applications in cities, and provide standardized
sets of requirements descriptions for the exchange of data to enable consistent and cost-efficient
implementations where instantiated.
5.3.2 Cooperative ITS application, in this context, is the use of a common platform to meet both
regulated and commercial service provision, providing collaboration between transport systems and
smart cities.
5.4 Specification of service provision
Cooperative ITS applications for ITS service applications (both commercial services and regulated
services) are specified in terms of the service provision, and not in terms of the hardware and software.
5.5 Architecture options
Architecturally, it needs to be possible for a vehicle user/OBE to use the services of different application
services. The in-vehicle system is a vehicle original equipment specification option, inbuilt at the time of
manufacture of the vehicle, with service provider selection being a subsequent service-user choice (e.g.
like selecting an internet service provider) or is aftermarket equipment that has access rights to the
required data. An ITS application service is based in the infrastructure. Other options are possible and
can be supported within the conceptual architecture. The objective of this role model is the accessibility
of the use of ITS data generated in ITS application services in smart city application services.
6 Concept of operations
6.1 General
This clause describes the characteristics of a proposed system from the viewpoint of an individual who
uses that system. Its objective is to communicate the quantitative and qualitative system characteristics
to all stakeholders.
This document describes the roles and responsibilities of the classes and actors involved in the
provision of ITS services for ITS service applications using a secure vehicle interface.
This document recognizes that there are variations between jurisdictions. It does not attempt, nor
recommend, homogeneity between jurisdictions. It is designed to provide common standard features
to enable equipment of common specification, that supports a standardized secure ITS interface to be
used, and the common features of service provision to be able to be referenced simply by reference
to an International Standard (requiring it to specify in detail only the additional requirements of a
jurisdiction).
A CONOPS generally evolves from a concept and is a description of how a set of capabilities is employed
to achieve desired objectives.
6.2 Statement of the goals and objectives of the system
The overall objective of the ITS service application in smart cities is the seamless exchange of data
between transport applications and smart city service applications.
These services are provided to meet the smart city requirements using common secure ITS interface
communications between ITS systems (including in-vehicle systems, infrastructure-based systems and
personal ITS stations) and smart city applications.
6.3 Strategies, tactics, policies, and constraints affecting the system
Strategies, tactics, policies and constraints, and indeed the services that are regulated as mandatory or
optionally supported, vary from jurisdiction to jurisdiction. Clause 7 provides details of the options of
such aspects.
6.4 Organizations, activities and interactions among participants and stakeholders
The classes, attributes and key relationships are described in this clause. Some high-level conceptual
architectural details are elaborated in Clause 7. Clause 8 provides the taxonomy of the architecture.
Clause 9 defines the communications architecture. Clause 10 defines the facilities layer and its
interoperability.
6.5 Clear statement of responsibilities and authorities delegated
Clause 5 describes the high-level options and issues. The actors, their responsibilities and authorities
are described in Clause 7. The roles are described in this clause and in Clause 7.
4 © ISO 2021 – All rights reserved

6.6 Operational processes for the system
6.6.1 General
The description given in 6.6.2 of operational processes is at a high abstracted level (above that of any
application service). Specific services have additional requirements not described herein.
6.6.2 Service requirements definition
A smart city application service provides a “service” (a benefit that a service user receives or a duty
that a service user provides) to a service user using exchanges of data, in this case using a secure ITS
interface. (Smart cities also use other communications means appropriate to the context of their use.)
The interface is wired or wireless, but is likely to be the latter, in which case the latency of the system
limits the ability to provide/capabilities of the application service.
An ITS application service provides an ITS “service” (a benefit that a service user receives or a duty that
a user provides) to a service user using a secure ITS interface. The interface is wired or wireless, but is
likely to be the latter, in which case the latency of the system limits the ability to provide/capabilities of
the application service.
Wireless communications between a vehicle and its OEM (commonly known as “ExVe”) are separate
and complementary to, and out of the scope of, this document.
6.7 Appointment of an approval authority (regulatory)
This document is based on the premise that a smart city develops its own regulation base (in consort
with national government and other smart cities). The term used in this document to describe this
organization and its regulation base is the “jurisdiction”, and this body creates or appoints an authority
to approve and audit the process. The “process” in this context is a smart city application service, and
the assumption is made that there is some form of approval process to control smart city application
services and their cybersecurity (at a minimum to protect privacy and avoid fraud, and to minimize
risks of terrorism or other disruption). The structure of that authority or authorities is a matter for
the jurisdiction, and it is a separate appointed organization or a department of the jurisdiction. Within
the context of this document, it is the actor role of the approval authority that is important, not its
structure, ownership or business model.
An approval authority (regulatory) only presides over the instantiation and operation of one application
service or presides over the instantiation and operation of many application services (at the discretion
of the jurisdiction).
The approval authority (regulatory), where appropriate, approves service providers (or delegate the
approval of service providers), and provides an audit as described in Clause 5, in accordance with the
requirements of the jurisdiction.
6.8 In-vehicle system
In ITS service applications, the OBE that provides the application service is an ITS trusted device that
[1]
meets the requirements of ISO/TS 5616 .
6.9 User
An ITS application service provides a service to a service user using a secure ITS interface. Within the
context of mobility integration, while most of ITS services are being provided to/from a road vehicle/
road vehicle user (RV/RVU) to another RV/RVU, or between an RV/RVU and a service provider or service
receiver, the application service is also between the RV/RVU and another transport system using entity,
such as a VRU, micro mobility user, public transport service provider, MaaS service provider, etc.
6.10 Application service
An application service is provided on request or is cyclical to a pre-agreed cycle.
In an “on request” implementation, an ITS trusted device, offering the appropriate credentials via the
secure ITS interface requests pre-specified information from the client OBE, which on confirmation of
the credentials of the requestor for the requested information provides it via the secure ITS interface.
An OBE is or is not set up to deal with one or both cyclical and on request demands for information.
The nature and definition of the information supplied is the subject of a specification or regulation.
6.11 Big data management entity
The big data are connected to other smart city data entities and share the data for the efficient smart
city operation in a manner approved and authorized by the jurisdiction. This role is required to support
privacy requirements and to fairly manage any business case issues.
6.12 Data aggregator
The data aggregator provides timely and value-added data to the service provider for its ITS service
application provisioning. Data collected for sharing are generally not forwarded in the same formats
or data timing so there is a need to have an entity that can provide standardized data to the service
[6]
provider in a standard data format and data timing. This role is similar to the ISO/TS 21184 role
between ITS entities, but in this case is between ITS entities and smart city entities. Artificial
intelligence (AI) can be deployed to create such structured value-added data for service providers.
The role of big data/data aggregation in smart cities is out of the scope of this document.
7 Conceptual architecture framework
7.1 General
Clause 6 provides the generic CONOPS which these actors and classes enact to provide the application
service(s). To specify a generic framework standard of the ITS service platform exchange of data with
smart cities, this framework standardization deliverable identifies core actors and classes as described
in 7.2 to 7.4, which are described as elements independent of any specific application.
7.2 Actors
This document defines a role model where the roles and responsibilities of three key actor classes are
defined to provide an entity known as an “application service”:
— the service users;
— the service provider(s);
— for any regulated applications: the jurisdiction(s).
The role model provides the general attributes and the responsibilities of the parties. These aspects are
described in this document. Figure 2 illustrates a conceptual role model architecture for application
service provision.
6 © ISO 2021 – All rights reserved

Figure 2 — Role model conceptual architecture — Smart city ITS application service
Using a UML approach, the relationships between the classes can be represented as shown in Figure 3.
Figure 3 — UML model overview of the classes
7.3 Service definition
The service definition for each application service comprises:
a) a clear description of the service provided and its inputs, outputs and results;
b) basic vehicle data content and quality that an OBE must deliver;
c) core application data content to meet the requirements of the service and meet any requirements
of the jurisdiction;
d) any additional application specific data content for the provision of that service;
e) service elements (such as retrieve data from OBE, map data to a map with access conditions, report
non-compliance, etc.);
f) rules for the approval of OBEs and application services.
7.4 Role model architecture
7.4.1 General
This subclause considers the roles of the actors defined in 7.2 and their interrelationship in greater
detail, and their relationship to the provision of the applications service(s).
8 © ISO 2021 – All rights reserved

7.4.2 Jurisdictions
The jurisdiction is the body that has official power to make legal decisions and impose regulations.
How this operates varies from country to country according to their constitution or legal structure.
Countries have a single jurisdiction or delegate such authorities to their constituent states or, as in the
case of Europe, independent states concede part of their independent national jurisdiction to a common
jurisdiction union (e.g. European Union) to achieve common goals and interoperability within common
conditions, while retaining independent jurisdiction in other matters.
Regardless of the differences between jurisdictions, what is common for the purposes of this document,
is the concept that at any specific location, and time, there is a single jurisdiction that has official power
to make legal decisions and where it deems applicable to impose regulations in respect of the regulation
of ITS service applications.
ITS service applications and smart city applications vary. In some jurisdictions, some application
services are mandatory or voluntary (but if implemented are implemented in a specific way). Most
services envisaged are safety services, mobility-related services or commercial services.
Within the context of this document, the role of the jurisdiction is to:
— determine which application services are mandatory, which are optional and which are prohibited;
— define any regulated application services;
— pass legislation to determine and regulate;
— manage and regulate the provision of the regulated application services.
Without prescribing the domestic arrangements within any jurisdiction, the management and
regulation of the provision of the regulated application services can be architecturally described as:
— laws and regulations;
— adopted standards;
— adjudication and mediation;
— auditing;
— approval of equipment;
— approval of service providers (where appropriate);
— approval of application services;
— trusted third party.
At the specific jurisdiction level, this architecture can be elaborated in greater detail, and specifically
to the instantiation of an ITS or smart city application service within that jurisdiction. For the purposes
of this document, however, abstracting to the level of Figures 2 and 3 provides a generic common
framework that can be instantiated with variations from jurisdiction to jurisdiction, yet remains a
generic common framework to which equipment can be built and application services specified.
7.4.3 Application service actors
Application services, whether or commercial or regulated, therefore need a clear definition in terms of
the requirements on the OBE.
It also falls to the service provider to provide an accurate enough specification of what is required from
the vehicle to enable the OEM, or aftermarket provider, to design the OBE.
Application services can be architecturally described as involving seven further classes/subclasses of
actors in addition to the jurisdiction:
— the jurisdiction;
— the SCMS;
— the certificate issuer;
— the OBE;
— the equipment installer (subclass);
— the OBE equipment maintainer (subclass);
— the approval authority (regulatory);
— the service user.
Single entities perform the roles of multiple classes of actor (e.g. the SCMS and the certificate authority
are the same actor). Other actors are also embraced within these key roles (such as a communications
provider), but these are regarded as additional subclasses that support one of the key actor roles.
7.4.4 Service provider(s)
A service provider, within the context of this deliverable, can be described as a party which is providing
safety, commercial or regulated ITS or smart city services. Application services are certified by the
certification authority (regulatory) as suitable.
7.4.5 The OBE equipment installer
This is the actor which installs the OBE into the vehicle and connects it to additional equipment that is
required, so that it can perform the application service.
If this is part of the original equipment specification for the vehicle, the OBE equipment installer is the
vehicle manufacturer or his/her agent.
In all circumstances where the OBE is not part of the original equipment, it is expected that these
equipment installers in most jurisdictions have to be registered with, and approved by, the approval
authority (regulatory).
The OBE equipment installer has the role not only to install the OBE communications equipment but to
connect it to other equipment required to deliver the application service.
7.4.6 The OBE equipment maintainer
Once installed, the OBE equipment is maintained. Functionality and capabilities are checked from time
to time, and the equipment is recalibrated and recertified from time to time in accordance with the
regime imposed by the jurisdiction or to conform to International Standards, to enable interoperability.
Several business models for this can be envisaged. Maintenance is a service provided by:
— the service provider;
— the equipment installer;
— the vehicle maintainer;
— the vehicle inspector used for vehicle safety test approval, etc.
Regardless of the business model operating within a particular jurisdiction, the OBE equipment
maintainer can also architecturally be considered as a subclass of the equipment installer.
10 © ISO 2021 – All rights reserved

7.4.7 Approval authority (regulatory)
An approval authority (regulatory) is appointed by the jurisdiction and it is a separate appointed
organization or a department of the jurisdiction. Within the context of this document, it is the actor role
of the approval authority that is important, not its structure, ownership or business model.
An approval authority (regulatory) presides over the instantiation and operation of one application
service or presides over the instantiation and operation of many application services for ITS or smart
city service applications (at the discretion of the jurisdiction).
“Approval” refers to the confirmation of certain characteristics of an object, person or organization.
In this context, approval applies to both the application(s) behind the service provision and the OBE
for which requirements need to be formulated. These requirements need be described as tests to be
passed. Each requirement leads to a verdict (passed or failed) on which the approval is based. This
document does not prescribe the specific requirements to achieve approval, nor its procedures nor pass
criteria, nor evaluation methods, which are deemed to be within the provenance of each jurisdiction.
7.4.8 Security credential management system/public key infrastructure
The SCMS is a central part of the secure vehicle interface. The SCMS, and PKI, encode the trust
relationships and governance structures for identity and authority management, and thus lie at the
technical heart of this secure ITS interface. In this document when referring to the management of
asymmetric keys, the term “SCMS” is synonymous with the term “PKI”.
The SCMS of itself plays no part in the message security solution for vehicle-to-vehicle (V2V) and
vehicle-to infrastructure (V2I) communication, rather it facilitates the secure communication by
ensuring that all participants in the system have access to the messag
...