CCAM & Connected Vehicles/C-ITS

CCAM, Connected vehicles,

C-ITS

9.0 Overview

9.0.1 Background

On the 30th of November 2016, the European Commission issued the following communication: “COM (2016) 766 final – A European Strategy on Cooperative Intelligent Transport Systems (C-ITS), a milestone initiative towards Cooperative, Connected and Automated Mobility” (CCAM), envisioning deployment of C-ITS integrated with CCAM and Mobility as a Service (MaaS) across Europe.[b9.1]

In 2019 the European Commission established the CCAM Single Platform, and the CCAM Partnership started in 2020. It will under the Horizon Europe initiative (Destination 6 -Transport and Smart Mobility services), running from 2021 and onwards, attempt to coordinate public and private research and innovation efforts, accelerating the implementation of new CCAM solutions. This includes cooperation with European standardisation bodies to ensure interoperability of new technologies being developed.

In spite of all this good work, a harmonized EU definition of the CCAM concept is still missing, and this document provides only one possible interpretation.

EU-ICIP (European ITS Communications and Information Protocols) provides a basis for information and knowledge of what communications and data standards are available to enable electronic traffic control equipment and software from different manufacturers to operate with each other as a system.

This section of the EU-ICIP document concentrates on available CCAM related standards that describes how physical infrastructure, digital infrastructure, operational infrastructure, and digital platforms can aid connected and automated vehicles in driving on public roads.

9.0.2 Overview of service

Cooperative, connected, and automated mobility (CCAM) focuses on moving people and goods along our road networks in a safe, quick, cost-effective, comfortable and environmentally friendly manner using automated vehicles, leveraging Mobility-as-a-Service (MaaS) platforms:

“Mobility is crossing a new – digital – frontier, allowing vehicles to communicate with each other, with the road infrastructure and with other road users. This will enable a coordination and cooperation between road users and managing traffic and mobility at an entirely new level.”

“CCAM enabled shared mobility services will enable seamless integration with public transport and Mobility-as-a-Service (MaaS) platforms. It will provide accessible mobility to people who cannot drive.”

“The aim is developing and implementing necessary technologies based on user and societal needs and providing scalable CCAM solutions by continuously expanding the operational design domains (ODD) so that the use cases become economically viable. This will support the uptake of innovative mobility solutions and/or logistics services using fully connected and highly automated vehicles (SAE level 4) for passenger or freight transport.”

“The vehicles and other road users, including vulnerable ones such as pedestrians and cyclists, will benefit from increased connectivity with vehicles and the infrastructure. This connectivity will allow them to better coordinate their manoeuvres, making use of active infrastructure support and enabling smart traffic and fleet management for improved throughput and increased safety. Shared, automated mobility and freight services will become widely available, providing seamless door-to-door mobility for people and goods including fully autonomous last mile deliveries, leading to healthier, safer, more accessible, greener, cost effective, demand-responsive and more sustainable transport everywhere.”

CCAM Strategic Research and Innovation Agenda, Version 1.0, 02/11/2020 [b9.2]

9.0.3 CCAM & Connected vehicles context

From the vehicle manufacturers’ point of view, it has been desirable to develop autonomous vehicles that only rely on what the vehicles can perceive with their onboard sensors (satellite navigation, cameras, lidar, radars, ultrasonics, weather, odometer, and inertial measurement unit) coupled with cellular connections to each manufacturer’s own data servers for receiving software updates, maps, and traffic alerts.

This approach has given each vehicle manufacturer full control over their own product development - and so far, this has fitted well with the established business models.

However, it assumes that the world of the automated, or connected, vehicle is the controlling master of its domain.

Figure 9.1: Typical sensor instrumentation for an automated vehicle

From the cities’ and road operators’ point of view, it may be desirable to have connected vehicles, many with automated driving functionality, cooperating with each other and with a common CCAM-MaaS platform in order to optimize the movement of people and goods by utilizing vehicles, roads, parking, and charging stations in the most efficient manner possible, while at the same time reducing pollution and the number of accidents.

From the vehicle fleet owners’ point of view (public transport organizations, taxi companies, car sharing companies, freight companies), it may be desirable to have connected and automated vehicles from different manufactures that can be integrated with their fleet management systems and with a common CCAM-MaaS platform for all road travellers.

Currently, the vehicle manufacturers’ progress in developing autonomous vehicles is slowing down due to the fact that replicating the data processing capabilities of a human driver has proven harder than it first seemed. To overcome this hurdle, the attempt to develop fully autonomous vehicles comparable to a human driver, should be toned down. Instead, we must consider the vehicles on the roads as small components in a larger mobility system, and some of these vehicles may have automated driving functionality.

Developing an autonomous vehicle that can handle all driving condition found in Europe is challenging. But we already see various levels of automated driving functionality that works well under certain conditions, or under certain Operational Design Domains (ODD) which is the term most people now use.

Achieving reliable automated driving functionality for various Operational Design Domains can be greatly simplified by leveraging public open data and having a common digital road infrastructure that can assist the vehicles with the tasks of localization, perception, prediction, planning and cyber security, improving the sense-plan-act-process of CCAM enabled vehicles.

Figure 9.2: Typical control diagram for an autonomous vehicle

Figure 9.3: Typical system modules for automated driving functionality

Merely performing the task of driving people and goods from a to b make the vehicles smaller components in the complete CCAM system. Some may be connected vehicles (CV) with a human chauffeur handling the dynamic driving task (DDT). Others may be Automated Vehicles (AV) where the onboard Robot Operating System (ROS) handles the dynamic driving task (DDT).

Figure 9.4: Actors in an automated driving system

(Source: Automated vehicles and MaaS: Removing the Barriers. Wiley/IEEE

/ CSi (UK) Ltd/IRPS Ltd ).

9.0.4 Scope of this section

CCAM incorporates all digital services and functions necessary to achieve commercially viable SAE level 4 automated driving in Europe. This covers a vast and ever-expanding range of advanced technologies.

Standards and specifications are lacking in many areas, in spite of the fact that the European Commission over the last fifteen years has sponsored hundreds of projects, found in this list:

https://knowledge-base.connectedautomateddriving.eu/projects/findproject/

Each project has produced dozens of documents in form of deliverables – many that could be harmonized and used to fill in the holes where standards and specifications are missing. C-Roads has done this to a certain extent, but mostly for specifications related to ITS-G5 from the road operators’ point of view.

This section divides CCAM into the following functional areas:

9.1 Digital Platforms: MAAS (public transport, taxi, ridesharing, carsharing, car rental, el-scooters, city bikes), parking solutions, home delivery services, digital freight platforms, online travel agencies

9.2 Digital road infrastructure: Static and dynamic digital representations of the physical world with which CCAM vehicles interact - like maps, traffic regulations, traffic and travel information. Some of this will be available at the National Access Points (NAP) for transport data, forming the Common European Mobility Data Space.

9.3 Operational road infrastructure: Fleet and traffic management functions which facilitate the traffic flow by providing information or guidance. This also includes tele-operated driving of automated vehicles, OEM concierge services, and eCall Public Safety Answering Point (PSAP).

9.4 Physical road infrastructure: Road, road signs, road markings, physical communication infrastructure equipment, and so on that form part of the physical world where vehicles operate. This also includes enhanced positioning systems like RTK and RTLS. (It is worth noting that there is not a consensus on whether electronic equipment should be defined as physical road infrastructure).

9.5 Vehicle technologies: standardised sensing devices, infrastructure-based sensing and sensor fusion, cooperative perception, distilled AI functions for on-board decision making, standardized human machine interaction (HMI), assess chauffeur status and logging of accident data (EDR/DSSAD), automatic call for help (eCall), sharing of vehicle data with the digital road infrastructure.

9.6 Cyber security & Privacy: PKI authentication and verification of exchanged data, hardware security module (HSM) for storing of certificates, intrusion detection and response, over the air (OTA) software updates, and General Data Protection Regulation (GDPR) compliance.

Figure 9.5: The CCAM functional areas in this Guide, and their interrelationship

Most use cases will span several functional areas. Describing all possible CCAM use cases is of course beyond the scope of this Guide.

9.0.5 Overview of stakeholders/actors

The stakeholders within the CCAM functional areas are:

Industry
- Automobile Manufacturers
- Automotive suppliers
- ITS solution providers
- Telecom industry
- Mobile network operators
- Cloud providers
Government
- Transport authorities
- Road authorities
- Road operators
- Emergency responders
- Member states
Service providers
- Roadside assistance
- Public transport
- Mobility and logistics providers
- Insurance companies
- Toll road operators
- Vehicle repair and maintenance providers
- Road maintenance providers
Non-profit organizations
- Automobile associations
- Trade associations
- Technology clusters
- Road safety associations
- Environmental organizations
Standardisation bodies
- National, European and international
Academia
- Universities
- Public research institutes
- Private research institutes

9.0.6 Links to other ITS services

CCAM has links to all other sections in this Guide:

9.1 Digital Platforms

9.1.1 Purpose

The purpose of this functional area is to provide platform-based transport services for citizens, corporations, academia, and governments.

Major (mainly American) digital platforms are used on a daily basis for social networking, entertainment, shopping, travel, or just to look for information and links. Examples are Facebook, LinkedIn, Netflix, YouTube, Apple, Amazon, Uber, Airbnb, and Google.

The digital platforms typically have business-to-customer storefronts in form of websites and smartphone-apps. Then they have business-to-business back-end solutions to allow third-party companies to access the platform. Each digital platform usually service one domain, providing data and information to connect producers of products and services with the consumers for a fee. There is no sales clerk – everything is automated, and the platform scales its footprint up and down in the cloud depending on the traffic, not wasting costly resources on idle processes.

Maybe because of language issues, the digital platforms in Europe rarely achieve a global reach – not even a pan European reach. Some of the European digital platforms already provide local transport services as early forms of MAAS (public transport, taxi, ridesharing, carsharing, el-scooters, and city bikes), while the digital platforms for parking services seems to do quite well. But these services could easily be swallowed by Google Maps. The European Commission is aware of this situation and have launched both incentivized initiatives and legislative actions (REGULATION (EU) 2019/1150 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 20 June 2019 on promoting fairness and transparency for business users of online intermediation service) [b9.5]:
https://eur-lex.europa.eu/eli/reg/2019/1150/oj [b9.5] in attempts to level the playing field with the Americans.

A typical digital platform setup is running in the cloud on top of Kubernetes with images according to the Open Container initiative. The performance is constantly monitored, it has virus and intrusion detection, runs regular backups, and follows DevOps practices with 99.95% uptime or better (however some are now embracing the next paradigm called NoOps).

The most promising transport related digital platforms are related to MaaS, and integrates end-to-end trip planning, booking, electronic ticketing, and payment services across all modes of transportation.

With respect to CCAM, and in addition to MaaS and other transport related services, digital platforms can also play an important role as a marketplace for transport related information exchange and AI algorithms.

One could argue that AI algorithms for automated driving functions don’t belong in an online store, but that is exactly what Tesla is doing – allowing its customers to purchase new features and functionality for their vehicles. And with future harmonized validation of these algorithms coupled with standardized software interfaces, the end users may be able to shop around for the best options. Similarly, standardized algorithms can be developed for the infrastructure, either to improve traffic management strategies or to make the infrastructure assist the automated vehicles.

The development environments for the algorithms can be hosted in cloud services where powerful GPUs can be rented when required, and where advanced and harmonized simulation environments for various operational design domains (ODD) can be utilized, producing new validated algorithms that can be offered for free to the open-source communities or sold for profits. The simulation environments can be developed based on standardized test data uploaded to repositories in the Digital Road Infrastructure from field operational trials and living labs.

It has become clear that no single corporation can program its way out of the ODD jungle. At the same time AI has a huge potential to provide new services and solutions for automated mobility in an ecosystem of specialized digital platforms, with new opportunities for academia, governments, big corporations, and SME’s.

Developing AI algorithms for different ODD and OEDR (Object and Event Detection and Response) situations should be a coordinated industrial development effort based on harmonized simulation environments where continuous improvement of trained modules for safety critical automated driving functions can be validated according to European and international standards.

Figure 9.6: Continuous improvements of algorithms for automated driving functionality

Another possible future digital platform is a front-end system for Personal ITS Stations (C-ITS on a smartphone) for pedestrians, cyclist, wheelchair users, and vehicles without C-ITS or telemetry solutions.

Possible transport related digital platforms may be as follows:

MaaS platform
- Public transport (both scheduled and demand responsive)
- Taxi
- Ridesharing
- Carsharing
- Car rental
- El-scooters
- City bikes
Parking solutions
Online travel agencies
Accommodations
Home deliveries
Digital freight platforms
Popular map solutions like Google Maps
Possible future frontend systems for Personal ITS Station (C-ITS on a smartphone)
Automated driving simulators for AI algorithm development through crowd sourcing.

A high number of Digital Platforms will be able to leverage the European single market for transport data through National Access Points (NAP) as described in section 9.2.

9.1.2 Actors

Each Digital Platform will provide specialized services, and several similar platforms may compete for the same customers. Typical actors will be:

Government bodies
SMB
International corporations
Non-profit organizations

9.1.3 System context

The platform economy has proven successful for many aspects of our lives (social media, shopping, news, entertainment, economy, education), and several platforms already provide transport services. Building on this could give the CCAM initiative a head start, using well understood business models.

Figure 9.7: The platform economy

9.1.4 Relevant standards

Listing all relevant standards for digital platforms is beyond the scope of this document which is focussed on ITS standards deliverables, however, The European Commission has set up ICT standardisation priorities for the Digital Single Market: https://ec.europa.eu/digital-single-market/en/standards

ICT Standardisation Priorities for the Digital Single Market: “The Communication on ICT Standardisation Priorities for the Digital Single Market (COM(2016)176) aims to ensure that all these devices in the future will be able to connect and share data with each other – independently of manufacturer, operating system, or other technical details.” [b9.3]

MaaS: SAE International, with the help of the Mobility as a Service Alliance, has issued the “Taxonomy and Definitions for Terms Related to Shared Mobility and Enabling Technologies J3163_201809” [b9.4], and includes functional definitions for carsharing, bike-sharing, ride-sourcing, public transit, car rentals, shuttles, taxis, paratransit, ridesharing, carpooling, vanpooling, and pedicabs.

9.1.5 Legislation

An alternative future can be a winner-takes-all scenario where one huge international corporation seize front-end control over most transport related services in Europe, consolidating them on their own digital platform. This can grant them the power to act as private rule-makers for all these transport needs and to function as bottlenecks between governments, businesses, and consumers. The two corporations Expedia Group (which owns Expedia, Hotels.com, Travelocity, Orbitz, Trivago and Hotwire) and Booking Holdings (which owns Priceline, Kayak and Booking.com) have controlled much of travel bookings for years, but now Google is also moving into the online travel agency marketplace (https://www.google.com/travel/ ).

In an attempt to avoid winner-takes-all scenarios, the European Union has established safeguards for a fair, predictable, sustainable and trusted business environment in the online economy.

REGULATION (EU) 2019/1150 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 20 June 2019 on promoting fairness and transparency for business users of online intermediation services. [b9.5]

And on the 15th of December 2020, the European Commission proposed a set of new rules for all digital services, including social media, online marketplaces, and other online platforms that operate in the European Union.

The Digital Services Act: “The new rules are proportionate, foster innovation, growth and competitiveness, and facilitate the scaling up of smaller platforms, SMEs and start-ups. The responsibilities of users, platforms, and public authorities are rebalanced according to European values, placing citizens at the centre.” [b9.6]

The Digital Markets Act: “The DMA establishes a set of narrowly defined objective criteria for qualifying a large online platform as a so-called “gatekeeper”. This allows the DMA to remain well targeted to the problem that it aims to tackle as regards large, systemic online platforms.

Business users who depend on gatekeepers to offer their services in the single market will have a fairer business environment.

Innovators and technology start-ups will have new opportunities to compete and innovate in the online platform environment without having to comply with unfair terms and conditions limiting their development.

Consumers will have more and better services to choose from, more opportunities to switch their provider if they wish so, direct access to services, and fairer prices.

Gatekeepers will keep all opportunities to innovate and offer new services. They will simply not be allowed to use unfair practices towards the business users and customers that depend on them to gain an undue advantage.” [b9.7]

As part of the Sustainable and Smart Mobility Strategy, the European Commission is planning legislative action to enable MaaS - and integrated ticketing is one of the new action areas to be included in the revised ITS Directive, which may be adopted by the end of 2021 [b9.8].

9.2 Digital road infrastructure

9.2.1 Purpose

This functional area provides static and dynamic digital representations of the physical world with which CCAM vehicles interact - like maps, traffic regulations, traffic and travel information. This may also include datasets collected from automated driving to be used in simulators.

9.2.1.1 National Access Points

Many of these APIs and datasets will be listed on the National Access Point (NAP) for easy exchange and reuse of transport related data, forming the Common European Mobility Data Space. In combination, the data from these services will create a digital twin for all the road traffic in each country. Some data may be provided as Public Open Data, accessible for everybody for free, while other data may require subscriptions.

The National Access Points are mandated by the delegated regulations under the current ITS Directive and there is a coordination mechanism through the EU EIP project ( Monitoring and Harmonisation of National Access Points. [b9.9]. Coordination of NAPs will be a new priority action proposed in the revised ITS Directive.

Vehicles on the road can subscribe to this data from a Central ITS Station/Server, an ADASIS map server or an OEM back-end system via long range cellular communication, maintaining an electronic horizon of a couple of kilometres in radius around the vehicle. This electronic horizon can supplement the local dynamic map (LDM) generated by the vehicle’s onboard sensors and ITS-G5 or PC5 onboard unit.

9.2.1.2 Traffic information

Several standards have been developed for safety-related traffic information (SRTI), real-time traffic information services (RTTI), and traffic regulations: (see also Section 21 Traffic Management and Control, and Section 22 Traffic and Traveller information):

DATEX II (DATa EXchange)
TPEG (Transport Protocol Experts Group)
RDS-TMC (Radio Data System - Traffic Message Channel)
METR (Management for Electronic Traffic Regulations)
UVAR (Urban Vehicle Access Regulations)
C-ITS messages such as:
- CAM (Cooperative Awareness Message): Location of vehicles
- DENM (Decentralized Environmental Notification Message): Traffic and weather
- IVI (Infrastructure to Vehicle Information): Virtual road signs
- SPAT (Signal Phase and Timing): Virtual traffic lights
- MAP (Map Data): Small maps of traffic light intersections and other roads
- SAM (Service Announcement Message): Announcement of traffic related services

The message sets for C-ITS have been thoroughly standardized and tested in pilot projects all over Europe as day-1 services which includes:

RWW - Road Works Warning
IVS – In Vehicle Signage
OHLN – Other Hazardous Location Notifications
GLOSA – Green Light Optimal Speed Advisory

9.2.1.3 Geographic Information

For geographic information used in maps, there are two main competing frameworks of standards with different sets of data exchange formats:

GIS (Geographic Information System) is usually maintained by mapping authorities and road authorities.
GDF (Geographic Data Files) is provided by commercial mapping companies to the auto industry.
In addition, the auto industry uses the Navigation Data Standard (NDS) as a standardized format for automotive-grade navigation databases which can function as map servers for ADASIS (Advanced Driver Assistance Systems Interface Specification) Electronic Horizon in the vehicles.

Map data in vehicles used to be updated by replacing a CD or DVD once a year – later the updates could be downloaded several times per year, but CCAM will require continuous live updates of the HD maps, streamed over the cellular network.

9.2.1.4 Lidar point clouds

Lidar point clouds are used by automated vehicles to position themselves in city streets with centimetre accuracy. First the area is surveyed by manually driving through the city streets while a lidar on the roof is recording the data for the point cloud together with GNSS data. Then the point cloud is adjusted manually to compensate for any GNSS errors and other noise. Finally, the corrected point cloud can be downloaded into the automated vehicles navigation system and correlated with the lidar readings to find the current location. Currently it is difficult to share point clouds between different automated vehicle providers.

9.2.1.5 Weather data

For weather data the OGC Environmental Data Retrieval (EDR) [b9.10] API provides interfaces to request environmental data at a position, within an area or along a trajectory, and can accessed via the OGC Web Coverage Service (WCS) or the new interface standard OGC API.

9.2.1.6 Public transport information

ITxPT provides implementation specifications based on standards for timetables, real- time information, and journey planning related to public transport like SIRI and NETEX. The ITxPT specifications [b9.11] are publicly available and free to use by anyone. Here, public transport authorities and operators find recommendations and requirements in connection with the procurement and integration of IT services. In addition, vendors use the specifications to design ITxPT compliant equipment and services.

9.2.1.7 Parking

The DATEX II parking model and the ISO standards for parking data will be aligned with the technical specifications from the Alliance for Parking Data Standards (APDS) [b9.12].

9.2.1.8 MaaS

The MaaS Alliance [b9.13] has provided a guidebook The MaaS Guide – Data Sharing:[b9.14] with a loose list of possible data sharing concepts

9.2.1.9 Standardised test data from automated driving

One important aspect emphasised in the “CCAM Strategic Research and Innovation Agenda Version 1.0, 02/11/2020” is the need to collect test data from automated driving in a standardized way across all EU funded projects and make it available on a common platform.

There are no standards for this yet, but one established solution is ADTF (Automotive Data- and Time-Triggered Framework) [b9.15], maintained by Digitalwerk, which can synchronize data from Video/Radar/Lidar, Bus signals (CAN, LIN, MOST, FlexRay), parameter data (temperature, pressure, acceleration, etc.), positioning data (GNSS), and maps.

Another alternative is ASAM OSI (Open Simulation Interface) [b9.16] which is used in the EU funded HEADSTART project.

This data can be used to refine simulators for development, testing, and validation of new algorithms, enabling scenario-based virtual testing, reducing the high number of test kilometres on physical roads otherwise needed for safety validation - especially with more complex ODDs. This can also contribute to the development of a harmonised simulation environment for CCAM functionality, and an EU wide database of relevant scenarios for validation.

9.2.1.10 SOAP and REST Web Service API

When designing a Web Service API for sharing transport related data, one has to choose between SOAP (Simple Object Access Protocol) or REST (Representative State Transfer) architecture. Around 70% of APIs are REST based. The SOAP specifications are maintained by W3C [b9.17], while the REST specification is maintained by the Open API Initiative [b9.18].

9.2.1.11 Message Queues

Web service APIs cannot guarantee message delivery and do not support the publish-subscribe distribution model found in message queue middleware. Message queues provides better fault tolerance and better ability to handle heavy traffic or activity bursts. Here are three popular message queue solutions:

Kafka was originally developed by LinkedIn, but became open-source in 2011. It can handle enormous message streams with extremely low latency within cloud platforms in a highly scalable manner. Kafka Connectors are available for most databases, and Kafka Streams enables analysis of massive amounts of data on the fly like analysing road traffic in real time. Many different Kafka Connectors and Kafka Streams tools can tap into the same message stream, serving different purposes. The open-source and documentation is maintained by Apache Kafka [b9.19].

AMQP (Advanced Message Queuing Protocol) was developed by the banking industry and is very suitable for communication between different back-end systems. It is described in the standard ISO/IEC 194694

MQTT (Message Queuing Telemetry Transport) was developed by IBM for the US oil industry. Oil tanks and pumps are often located in remote areas with poor mobile coverage or other radio communications. The technology has now been made available to everyone and is described in the standard ISO / IEC 20922, and has become a favourite for IoT (Internet of Things) communication. It is suitable for long-range C-ITS communication between central systems and individual vehicles. ITxPT uses MQTT.

9.2.1.12 Common European data spaces

NAP, already in place in many counties since 2019, fits well with the European Strategy for Data (Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions. A European strategy for data ) [b9.20],) and the creation of nine common European data spaces:

A Common European industrial (manufacturing) data space
A Common European Green Deal data space
A Common European mobility data space
A Common European health data space
A Common European financial data space
A Common European energy data space
A Common European agriculture data space
A Common European data spaces for public administration
A Common European skills data space

9.2.2 Actors

The main actor here will be the provider of the National Access Point (NAP) for transport data.

Then there will be all the actors actually providing the data listed in section 9.2.1, typically:

Government bodies
- Road and transport authorities National mapping agencies Weather services
- Public transport
- City government
SMB
- Parking services
- MAAS providers
- Roadside assistance
International corporations
- Navigation system providers
- Auto manufactures
Non-profit organizations
- Aid organizations
- Environmental organisations

9.2.3 System context

Road and transport authorities in cities and municipalities are the most important data providers for the National Access Points (NAP) for transport data, especially for what concerns road geometry and attributes data (accurate and up-to-date static data of RTTI delegated regulation Delegated regulation 962/2015 - on the provision of EU-wide real-time traffic information services (RTTI) ). It’s for this reason that the EC is proposing to mandate the creation of static data as per the annex of the RTTI delegated regulation [9.25], through the EU EIP NAP coordination mechanism [b9.9].

Figure 9.8: National Access Point for transport data in Norway

(source: https://data.transportportal.no )

9.2.4 Relevant standards

Please refer to these sections in this Guide for relevant standards for the Digital Road Infrastructure:

The standards for Spatial Data can be hard to navigate (no pun intended). For the CCAM section of this Guide we are only interested in sharing of data in the Digital Road Infrastructure, so here is a simplified overview of some commonly used data formats for Geographic data:

GDF (Geographic Data Files)
- Data model of real-world road objects available in these formats
  - Media Record Specifications (ASCII flat file)
  - XML schema specifications
  - SQL encoding specifications

GIS (Geographic Information System)
- Raster datasets. Here are some of the available formats:
  - TIFF
  - GeoTIFF
  - MrSID (Multiresolution Seamless Image Database)
  - USGS DEM (United States Geological Survey, Digital Elevation Model)
- Vector datasets. Here are some of the available formats:
  - GeoJSON
  - GML (Geography Markup Language)
  - PostGIS
  - ESRI File Geodatabase format
  - TIN (Triangulated Irregular Network)
- OGC Web Services (to be replaced with OGC API):
  - WMS (Web Map Services) provides raster map data for the requested area in one or more image files, typically JPEG or PNG.
  - WFS (Web Feature Services) provides vector data for the requested area in GML format.
  - WCS (Web Coverage Service) provides enriched raster data for the requested area, often in GeoTIFF format, containing information like elevation data, satellite images, or weather data.

A complete list of GIS data formats can be found here: https://gdal.org/

9.2.5 Legislation

Directive (EU) 2019/1024 of the European Parliament and of the Council of 20 June 2019 on open data and the re-use of public sector information. [b9.21]

The ITS Directive of the EU (2010/40/EU) [b9.22] instructs the member states to establish a National Access Point (NAP) to make open road and transport data available. The purpose is to achieve continuous and interoperable services in Europe.This Directive has been amended by Decision (EU) 2017/2380 of the European Parliament and of the Council of 12 December 2017 amending Directive 2010/40/EU as regards the period for adopting delegated acts

The ITS Directive gives the EU Commission the authority to define delegated regulations with detailed specifications:

This Directive has been amended by Decision (EU) 2017/2380 of the European Parliament and of the Council of 12 December 2017 amending Directive 2010/40/EU as regards the period for adopting delegated acts

Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on European data governance (Data Governance Act). Brussels, 25.11.2020 COM(2020) 767 final, 2020/0340 (COD) [b9.27].

Making public sector data available for re-use, in situations where such data is subject to rights of others (data that might be subject to data protection legislation, intellectual property, or contain trade secrets or other commercially sensitive information)
Sharing of data among businesses, against remuneration in any form.
Allowing personal data to be used with the help of a ‘personal data-sharing intermediary’, designed to help individuals exercise their rights under the General Data Protection Regulation (GDPR).
Allowing data use on altruistic grounds

I'

9.3 Operational road infrastructure

9.3.1 Purpose

The purpose of this functional area is to provide fleet and traffic management functions which facilitate the traffic flow by issuing information or guidance. This also includes tele-operated driving of automated vehicles, OEM concierge services, and eCall Public Safety Answering Point (PSAP).

A Connected and Automated Vehicle (CAV) in a CCAM ecosystem will never drive around autonomously without instructions from an external operational control system. In fact, the CAV will in many cases receive instruction from multiple operational control systems at same time, systems like:

Regional Traffic Management Centres: changing traffic light status, setting speed limits, closing and opening lanes, closing and opening tunnels, issuing traffic and weather alerts, etc.
Vehicle OEM system with navigation functionality: guiding a private CAV from A to B
Fleet Management: directing the CAVs in the fleet to desired locations
Automated Road Maintenance Management Systems: coordinating automated road maintenance machines
Tele-operation: remote manual driving of CAV that strayed outside its ODD

An example of this are Ruter’s automated buses in Oslo. They are controlled both via the fleet management system’s telematics and via ITS-G5 SPAT messages (traffic light status signals) from the local traffic light controllers which in turn are orchestrated by the city’s traffic management centre.

Fleet and traffic management in a CCAM eco-system must be able to forecast, orchestrate and load-balance the traffic in different geographical regions and across national borders, using standardized communication with the CAVs.

9.3.2 Actors

In addition to the chauffeur, one automated vehicle may be controlled by several actors. Typical actors will be:

Vehicle manufactures and their providers of navigations systems
Fleet operators, including operators of automated vehicles
Tele-operation centres
Traffic management centres

9.3.3 System context

Traffic management centres have for decades controlled their road infrastructure by monitoring the traffic, adjusting speed limits, and performing planned or emergency closing of lanes and tunnels using conventional ITS, while fleet operators have dispatched their vehicles to where they have been needed.

With CCAM and vehicles with automated driving functions we may see the line between the traffic management centres and fleet operators becoming blurred. A precursor to this has been the systems providing priority for public transport in traffic light intersections, where a fleet operator of buses and trams can influence the traffic flow in the city. With the addition of privately owned fleets of automated vehicles leveraging infrastructure-based sensing, cooperative perception, and cooperative manoeuvres, many new and interesting dilemmas around responsibility will arise.

Figure 9.9: Traffic Management Centre

(Photo: the Norwegian Public Roads Administration)

9.3.4 Relevant standards

Please refer to these Sections in this guide for relevant standards for the Operational Road Infrastructure:

9.3.5 Legislation

Please refer to these Sections in this Guide for relevant legislation for the Operational Road Infrastructure:

9.4 Physical road infrastructure

9.4.1 Purpose

This functional area consists of roads, road signs, road markings, physical communication infrastructure equipment, and so on that form part of the physical world where vehicles operate. This also includes enhanced positioning infrastructure like RTK and RTLS. It is worth noting that there is not a consensus on whether electronic equipment should be defined as physical road infrastructure, however we’ve done that here because the physical location of this equipment plays an important role in order for it to perform its intended function).

The physical road infrastructure can expand the ODD of automated driving functions by providing additional sensory input for the vehicles by means of roadside mounted cameras, radars, and weather stations, as well as status information from tunnels and bridges.

Improved 4G and 5G cellular coverage along the roads provides better long-range C-ITS communication, better eCall connectivity, and also better conditions for tele-operation. As a supplement to ITS-G5 or PC5 short-range communication, 5G edge computing with virtual servers near vehicles and traffic situations can provide localized services like infrastructure-based sensing, cooperative perception, and cooperative manoeuvres. In addition, the cellular LTE Positioning Protocol (LPP) provides multiple positioning methods. Roadside Units for short-range ITS-G5 or PC5 communication removes latency for traffic light status as SPAT messages and can also make snap decisions locally (such as detecting wrong-way-driver and dangerous-end-of-queue. )

Roadside Units can also be used as positioning systems for urban canyons, parking decks, station areas, and tunnels. Regular Wi-Fi communication can also be a short-range option at home, at stations, and terminal areas (including Wireless Power Transfer (WTP) communication requirements IEC TS 61980-2). In areas without GNSS coverage, vehicle positioning can be achieved by using Realtime Location Systems (RTLS) based on various types of anchors/beacons like UWB and Bluetooth. In areas with GNSS coverage, the positioning accuracy can be enhanced by networks of RTK base-stations, preferably with support for the four main satellite constellations: GPS, GLONASS, BeiDou, and Galileo.

RTK can be supplemented with PPP-solution like the Galileo High Accuracy Service (HAS). In station and terminal areas, additional positioning methods like laser guidance (currently used by LGV: Laser Guided Vehicle) and inductive guidance wires (currently used by AGV: Automated Guided Vehicle) can be used to aid automated driving functions in leading the vehicles to the correct locations for charging, parking and boarding-quays. Service Announcement Messages (SAM) can be used to instruct the vehicles’ navigations systems about the type and configuration of such localized positioning methods.

An EU-wide harmonisation of infrastructure support for CCAM with interoperable handover between road operators and cellular network operators when vehicles cross regional and national borders, will ensure faster uptake of automated driving and enable coexistence of connected cooperative automated vehicles and all other road users.

A proposed harmonisation outline is ISAD (Infrastructure support levels for automated driving) [b9.28], developed in the EU funded Inframix project. Although not a specification or standard yet, ISAD provides a scheme with five levels to classify the physical and digital road infrastructure preparedness to aid automated vehicles (AV):

ISAD E – Conventional road infrastructure: No AV support
ISAD D – Static digital information: Digital maps including static road signs are provided to the AVs.
ISAD C – Dynamic digital Information: Same as D plus dynamic information like traffic light status, variable speed limits, lane directions, road closures, short-term road works.
ISAD B – Cooperative perception: Same as C, plus the infrastructure is capable of perceiving small traffic situations like C-ITS Day 1 services and relay the information to the AVs.
ISAD A – Cooperative manoeuvres: Same as B, plus the infrastructure is capable of perceiving vehicle trajectories and guide AVs in order to optimize the traffic flow similar to C-ITS Day 2+ services.

The five levels of ISAD are only concerned with digital communications connectivity. The CCAM Platform WG3 for physical and digital road infrastructure is in addition building a list of physical road attributes that can assist automated driving functionality. The CEF project SLAIN has also looked into this for the TEN-T road network [b9.29].

Gantries with toll stations for automated electronic fee collection are also part of the physical road infrastructure, but these may in the future be replaced with virtual geo-zones in the digital road infrastructure as part of mileage-based road user charges.

9.4.2 Actors

Anyone responsible for erecting equipment near public roads intended to provide the vehicles with data falls in this category, typically:

Transport authorities
Road operators
Road construction and maintenance contractors
Toll road operators
C-ITS infrastructure providers (ITS-G5 or PC5 RSUs)
Mobile network operators
Providers of RTK and PPP solutions
Weather services
Charging station providers
Parking providers

9.4.3 System context

This is characterized by equipment near public roads intended to provide the vehicles with the following:

Reliable long-range and short-range communication
Improved positioning, preferably with centimetre accuracy under all condition
Infrastructure-based sensing for aiding automated vehicles

Figure 9.10: ITS-G5 Roadside Unit

(Photo: Cohda Wireless)

9.4.4 Relevant standards

Please refer to these chapters in this Guide for relevant standards for the Physical Road Infrastructure:

9.4.5 Legislation

Please refer to these chapters in this Guide for relevant legislation for the Physical Road Infrastructure:

- EU-ICIP Section 10: Electronic Fee Collection/ Tolling
- EU-ICIP Section 8: Wireless Communications/ ETSI/ Internet communications, IETF

9.5 Vehicle technologies

9.5.1 Purpose

This area focuses on in-vehicle technologies for connected and automated vehicles (CAV) that will improve perception, prediction, and planning functions, enable safe collaboration with other road users, and activate protective measures in case of emergency. It will also make sure everybody has a pleasant ride and avoids motion sickness.

This includes future standardisation of sensing devices, infrastructure-based sensing and sensor fusion, cooperative perception, distilled AI functions for on-board decision making, cooperative manoeuvres, standardized human machine interaction (HMI), assess chauffeur status and logging of accident data (EDR/DSSAD), automatic call for help (eCall/ACN), and sharing of vehicle data with the digital road infrastructure.

The standard “SAE J3016 Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles” defines six levels of automate driving functionality:

Level 0 - No Automation: For example, obstacle warnings for the chauffeur
Level 1- Driver Assistance: For example, lane centering or adaptive cruise control
Level 2 - Partial Automation: For example, lane centering and adaptive cruise control
Level 3 - Conditional Automation: For example, automated traffic jam driving
Level 4 - High Automation: For example, the vehicle has no pedals and steering wheel and can perform the Dynamic Driving Task (DDT) if the driving conditions are within its Operational Design Domain (ODD),
Level 5 - Full Automation: Same as level 4, but the vehicle has no ODD restrictions and can perform the Dynamic Driving Task (DDT) anywhere at the same level as a human chauffeur or better.

An automated vehicle must also include fall-back functionality if a vehicle malfunctions or reaches the limit of its ODD, handing over the DDT to an onboard person. For a vehicle without pedals and steering wheel, the vehicle should bring itself to a state and position that is safe for any onboard passengers and other nearby road users. Alternatively, the vehicle should be brought to safety by a remote operator.

A common expectation for automated driving is that it should be safer than human drivers - some say ten times safer. But in the end, there will have to be a risk-benefit assessment. Then the question becomes: risk for whom - the investors holding Tesla stocks or a 10-year-old girl trying to cross the street?

Safety solutions must be established to bring the risks down to acceptable levels according to Automotive Safety Integrity Level (ASIL) as defined in the standard “ISO 26262 Road vehicles - functional safety”. The levels are:

ASIL-A: Least stringent
ASIL-B
ASIL-C
ASIL-D: Most stringent

Figure 9.11: Example of ISO 26262-9:2018 Automotive Safety Integrity Levels

When vehicles start using V2X communication for automated actuation of brakes to avoid accidents, automatically start driving on green traffic lights, and similar things, then ISO 26262 -9 ASIL certification of these functions will be required.

All communication with the vehicles must adhere to the standards and regulations for cybersecurity and personal privacy as outlined in section 9.6 of this Guide.

9.5.2 Actors

For vehicle technologies to achieve reliable automated driving functionality, it is important that a wide range of actors are able to participate in the development of contributing solutions.

Typical actors are:

Manufactures of vehicles with automated driving functionality
Suppliers of components and solutions for automated driving
Vehicle type approval authorities and authorized technical services organizations.
Fleet operators of automated vehicles
Road operators and road construction and maintenance contractors using automated road maintenance machines
Tele-operation centres used as fall-back solution for automated vehicles stranded outside their ODD.

9.5.3 System context

Vehicle OEMs, the automotive supply chain, and fleet operators of automated vehicles must work together to develop safe and reliable automated driving functionality that can be approved for use on public roads without special pilot project permissions.

Until recently the attempt has been to create autonomous vehicles as capable and independent as a professional chauffeur. This has proven difficult to achieve, so now many are looking at leveraging a future physical and digital road infrastructure tailored to support automated driving functionality.

Figure 9.12: Automated passenger vehicle

(Photo: Ruter AS / Nucleus AS, Daniel Jacobsen)

9.5.4 Relevant standards

9.5.4.1 Definitions and vocabulary

9.5.4.1.1 SAE J3016_201806

Title: Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles

Scope: This SAE Recommended Practice describes motor vehicle driving automation systems that perform part or all of the dynamic driving task (DDT) on a sustained basis. It provides a taxonomy with detailed definitions for six levels of driving automation, ranging from no driving automation (level 0) to full driving automation (level 5), in the context of motor vehicles and their operation on roadways.

Link: https://www.sae.org/standards/content/j3016_201806/

9.5.4.2 Functional safety

9.5.4.2.1 ISO 26262-9:2018 Road vehicles — Functional safety — Part 9: Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses

Scope: Automotive Safety Integrity Level refers to an abstract classification of inherent safety risk in an automotive system or elements of such a system.

Link: https://www.iso.org/obp/ui/#iso:std:iso:26262:-9:ed-2:v1:en

9.5.4.2.2 ISO/PAS 21448:2019 Road vehicles — Safety of the intended functionality

Scope: The absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons is referred to as the Safety of the Intended Functionality (SOTIF). This Guide provides guidance on the applicable design, verification and validation measures needed to achieve the SOTIF. This Guide does not apply to faults covered by the ISO 26262 series or to hazards directly caused by the system technology (e.g. eye damage from a laser sensor).

Link: https://www.iso.org/obp/ui/#iso:std:iso:pas:21448

9.5.4.2.3 IEC 61508:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems

Scope: Methods on how to apply, design, deploy and maintain automatic protection systems called safety-related systems

Link: https://webstore.iec.ch/publication/22273 .

9.5.5 Legislation

UNECE WP.29 GRVA ALKS (Automated Lane Keeping Systems) (under development)
eCall: See EU-ICIP Section11 in this Guide.

9.6 Cybersecurity & Privacy

9.6.1 Purpose

The purpose of this functional area is to provide PKI authentication and verification of exchanged data, hardware security module (HSM) for storing of certificates, intrusion detection and response, secure over the air (OTA) software updates, and General Data Protection Regulation (GDPR) compliance.

While the vehicle technologies described in section 9.5 will provide functional safety by making the vehicles stay on the road and avoid collisions, cybersecurity will provide defence against external threats that can compromise the vehicle’s functional safety via data hacks. Privacy protection will safeguard chauffeurs and passengers against being illegally tracked and exposed to fraud.

A C-ITS vehicle onboard unit (OBU/ C-ITS-station) or roadside unit (RSU) must be able to trust external data coming from other vehicles, from the infrastructure, and from digital platforms, via any wireless communication means including short-range ITS-G5/PC5 communication, long-range cellular communication, or copper and fibre ethernet connections.

For ITS-G5 communication, the EU CCMS (EU C-ITS Security Credential Management System) [b9.30] will be used to authenticate and verify C-ITS messages.

TLS 1.3 [b9.31] (already using X.509 certificates) is updated with RFC 8902 [b9.32], and together with ISO 21177 it will now also support the certificate format specified by the IEEE in IEEE 1609.2 and profiled by ETSI in TS-103097. This brings standardized communication protocols such as HTTP, AMQP, and MQTT into the same trust domain as EU CCMS. This will simplify C-ITS hybrid communication, combining short-range ITS-G5 communication with long-range cellular communication.

Sharing of data between systems via cellular communication over the Internet also requires authentication. Here are a few available options:

FIDO (Fast IDentity Online)
OAuth (Open Authorization)
OpenID Connect (OIDC) – based on OAuth 2.0
SAML (Security Assertion Markup Language)
TLS (Transport Layer Security)
JWT (JSON Web Token)

Many German Vehicle OEMs require ICT providers in their supply chain to obtain a TISAX (Trusted Information Security Assessment Exchange) certification every three years, which basically proves that the suppliers operate according to the standard ”ISO/IEC 27001 Information security management” in an automotive-specific context.

In addition to short-range ITS-G5/PC5 and long-range cellular communication, vehicles have many other attack vectors:

Radio communication:
- Bluetooth, used to connect phones to the vehicle for handsfree calling and audio
- NFC (Near Field Communication) used to pair the car’s Bluetooth with a phone
- Wi-Fi, used to provide Internet hotspot for gadgets, or to connect Apple CarPlay or Android Auto to the vehicles infotainment system without using USB.
- GNSS (Global Navigation Satellite System)
- ISM (Industrial, Scientific and Medical), used for remote keyless entry
- UWB (Ultra-Wide Band), used for keyless entry and precise positioning
- QI, communication protocol used for wireless charging of phones and earbuds
- TPMS (Tire Pressure Monitoring System)

Physical connections to onboard data buses:
- USB (Universal Serial Bus) used to connect phones and jump drives.
- LIN (Local Interconnect Network)
- FlexRay
- MOST (Media Oriented Systems Transport)
- Ethernet
- OBDII (On-board diagnostics)
- CAN (Controller Area Network)
- OCPP (Open Charge Point Protocol), used when charging electric vehicles

Cyber-physical systems vulnerable to sensor spoofing attacks in the analogue domain:
- MEMS microphones for voice control can be hacked by a remote pulsing laser
- Camera-based perception can be fooled by stickers on traffic signs
- The lidar can be spoofed by shining a laser at it with the correct modulation
- The radar can be jammed in the millimeter wave band or spoofed by replay-attack transmitting pre-recorded radar signals.

Automotive Hardware Security Modules (HSM) combined with a security software stacks are essential building blocks to prevent unauthorized access of in-vehicle communications and vehicle control. They also provide protected storage of cryptographic keys, and offer symmetric and asymmetric encryption mechanisms. An automotive HSM, which is involved in safety-critical functions, must support the standard “ISO 26262 Road vehicles - Functional safety”.

Figure 9.13: Automotive Hardware Security Module

(Picture: Infineon [b9.38])

The C-programming language dominates the embedded systems in the automotive industry, but poses risk introduced by major security vulnerabilities, such as division with zero, memory leak, buffer overflow, corrupted input, and code injection. Poor code quality can be mitigated by following industry standards, such as the MISRA C software development guidelines. There is also a set of guidelines called MISRA C++.

Specific functions require a high level of trust and thus introduce the need for a certain assurance level, certified by a third party. The Common Criteria for Information Technology Security Evaluation (referred to as Common Criteria or CC) is an international standard (ISO/IEC 15408) for computer equipment and software security certification. Certified products can be found here: https://www.commoncriteriaportal.org/products/

The standard “ISO SAE 21434 Road vehicles — Cybersecurity engineering” is recently approved and has focus on common security terminology, minimum security criteria, and cybersecurity assurance levels. It will serve as a reference point for regulators.

The C CEN-CENELEC Focus Group on Cybersecurity [b9.33] will support CEN and CENELEC in growing the European Digital Single market and will develop recommendations to its parent bodies for international standards setting.

The General Data Protection Regulation (GDPR) [b9.36] is a legal framework that dictates how governments, organizations, and companies collect and process personal information from individuals who live in the European Union and applies regardless of where the data collectors are located in the world. Data cannot be collected and processed unless the person has given consent or that there is a legal basis to do so.

9.6.2 Actors

Any organization exchanging data between vehicles and the infrastructure must adhere to the specifications, standards, and regulations for cybersecurity and privacy. Here are some typical examples:

Industry
- Automobile Manufacturers
- Automotive suppliers
- ITS solution providers
- Telecom industry
- Mobile network operators
- Cloud providers
Government
- Transport authorities
- Road authorities
- Road operators
- Emergency responders
Service providers
- Roadside assistance
- Public transport
- Mobility and logistics providers
- Insurance companies
- Toll road operators

9.6.3 System context

Cyber security in the context of data sharing in a CCAM ecosystem refers to all technologies, processes, and practices designed to protect digital platforms, digital road infrastructure, operational road infrastructure, physical road infrastructure, and the vehicles from cyberattack, damage, or unauthorized access.

9.6.4 Relevant standards

9.4.6.1 General cybersecurity risk management and mitigation

9.6.4.1.1 ISO/IEC 27001:2013 Information technology — Security techniques — Information security management systems — Requirements

Scope: It details requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS) – the aim of which is to help organizations make the information assets they hold more secure

Link: https://www.iso.org/isoiec-27001-information-security.html

9.6.4.1.2 ISO/IEC 27002:2013 Information technology - Security techniques - Code of practice for information security controls

Scope: It gives guidelines for organizational information security standards and information security management practices including the selection, implementation and management of controls taking into consideration the organization's information security risk environments.

Link: https://www.iso.org/standard/54533.html

9.6.4.1.3 ISO/IEC 27005:2018 Information technology - Security techniques - Information security risk management

Scope: This document supports the general concepts specified in ISO/IEC 27001 and is designed to assist the satisfactory implementation of information security based on a risk management approach.

Link: https://www.iso.org/standard/75281.html

9.6.4.1.4 ISO/IEC 15408-1:2009 Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model

Scope: It establishes the general concepts and principles of IT security evaluation and specifies the general model of evaluation given by various parts of ISO/IEC 15408 which in its entirety is meant to be used as the basis for evaluation of security properties of IT products.

Link: https://www.iso.org/standard/50341.html

9.6.4.2 Automotive cybersecurity risk management and mitigation

9.6.4.2.1 SAE J3061_202112 Cybersecurity Guidebook for Cyber-Physical Vehicle Systems

Scope: This recommended practice provides guidance on vehicle Cybersecurity and was created based off of, and expanded on from, existing practices which are being implemented or reported in industry, government and conference papers.

Link:

https://www.sae.org/standards/content/j3061_202112

9.6.4.2.2 ISO/SAE DIS 21434 Road vehicles — Cybersecurity engineering

Scope: This document specifies requirements for cybersecurity risk management regarding engineering for concept, development, production, operation, maintenance, and decommissioning for road vehicle electrical and electronic (E/E) systems, including their components and interfaces.

Link: https://www.iso.org/standard/70918.html

9.6.4.2.3 ISO/AWI 24089 Road vehicles — Software update engineering

Scope: It describes implementation of UNECE WP.29 GRVA OTA (Over-the-air updates)

Link: https://www.iso.org/standard/77796.html

9.6.4.3 C-ITS security standards

9.6.4.3.1 ISO/TS 21177 Intelligent transport systems — ITS station security services for secure session establishment and authentication between trusted devices

Scope: This document contains specifications for a set of ITS station security services required to ensure the authenticity of the source and integrity of information exchanged between trusted devices operated as bounded secured managed ITS stations as specified in ISO 21217.

Link: https://www.iso.org/obp/ui/#iso:std:iso:ts:21177

9.6.4.3.2 IEEE 1609.2-2016 IEEE Standard for Wireless Access in Vehicular Environments--Security Services for Applications and Management

Scope:This standard defines secure message formats and processing for use by Wireless Access in Vehicular Environments (WAVE) devices, including methods to secure WAVE management messages and methods to secure application messages. It also describes administrative functions necessary to support the core security functions.

Link: https://standards.ieee.org/standard/1609_2-2016.html

9.6.4.3.3 ETSI TS 103 097 V1.9.1 (2020-10) Intelligent Transport Systems (ITS); Security; Security header and certificate formats

Scope: This document specifies the secure data structure including header and certificate formats for Intelligent Transport Systems

Link: https://www.etsi.org/deliver/etsi_ts/103000_103099/103097/01.09.01_60/ts_103097v010401p.pdf

9.6.4.3.4 ITEF RFC 8902 TLS Authentication Using Intelligent Transport System (ITS) Certificates

Scope: This document defines an experimental change to TLS to support IEEE/ETSI certificate types to authenticate TLS entities.

Link: https://www.ietf.org/rfc/rfc8902.pdf

For more EU CCMS related standards for ITS-G5 communications in Section 8 of this guide ,and ISO 5616 in Section 15 (Mobility Integration) re Governance.

9.6.4 Legislation

UNECE WP.29 GRVA CS/OTA (Cybersecurity and Over-the-air updates) (work in progress)

EU 2019/881 CSA: ENISA New rules for cybersecurity certification [b9.34]

EU 2019/2144 GSR: EU 2019/2144 GSR: Advanced Vehicle Safety Systems [35].

Also mandates inclusion of UNECE WP.29 Cybersecurity) [b9.35]

The General Data Protection Regulation (GDPR). Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data [b9.36]

The Data Protection Law Enforcement Directive. Directive (EU) 2016/680 on the protection of natural persons regarding processing of personal data connected with criminal offences or the execution of criminal penalties, and on the free movement of such data [b9.37].

9.7 Bibliography

[b9.1] COM (2016) 766 final – A European Strategy on Cooperative Intelligent Transport Systems (C-ITS), a milestone initiative towards Cooperative, Connected and Automated Mobility:
https://ec.europa.eu/energy/sites/ener/files/documents/1_en_act_part1_v5.pdf

[b9.2] CCAM Strategic Research and Innovation Agenda, Version 1.0, 02/11/2020:
https://www.ertrac.org/uploads/images/CCAM%20Partnership%20SRIA%20v1.0%2002-11-2020.pdf

[b9.3] COMMUNICATION FROM THE COMMISSION TO THE EUROPEAN PARLIAMENT, THE COUNCIL, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE AND THE COMMITTEE OF THE REGIONS. ICT Standardisation Priorities for the Digital Single Market:
http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=15265

[b9.4] Taxonomy and Definitions for Terms Related to Shared Mobility and Enabling Technologies J3163_201809:
https://www.sae.org/standards/content/j3163_201809/

[b9.5] REGULATION (EU) 2019/1150 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 20 June 2019 on promoting fairness and transparency for business users of online intermediation services:
https://eur-lex.europa.eu/eli/reg/2019/1150/oj

[b9.6] The Digital Services Act: ensuring a safe and accountable online environment:
https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/digital-services-act-ensuring-safe-and-accountable-online-environment_en

[b9.7] The Digital Markets Act: ensuring fair and open digital markets:
https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/digital-markets-act-ensuring-fair-and-open-digital-markets_en

[b9.8] The Sustainable and Smart Mobility Strategy:

ttps://transport.ec.europa.eu/transport-themes/mobility-strategy_en

[b9.9] EU EIP, Monitoring and Harmonisation of National Access Points:
https://www.its-platform.eu/achievement/monitoring-harmonisation-of-naps/

[b9.10] http://docs.opengeospatial.org/DRAFTS/19-086.html

[b9.11] https://itxpt.org/technology/itxpt-specifications/

[b9.12] Alliance for Parking Data Standards (APDS):
https://www.allianceforparkingdatastandards.org/apds-versions

[b9.13] https://maas-alliance.eu/library/

[b9.14] hhtps://maas.guide/common-responsibilities/data-sharing.html

[b9.15] https://support.digitalwerk.net/adtf/v3/adtf_html/index.html

[b9.16] https://www.asam.net/standards/detail/osi/