top of page


Dont know where to start, and confused by all the jargon?

Then try one of these page links

6.1       Background

EU-ICIP is a European Commission funded standardisation project : SA 2019-03 : European ITS communications and information protocols



There are now several hundred standards deliverables supporting the rapidly evolving “Intelligent Transport Systems” sector. They have particular relevance as society tries to decarbonise the transport paradigm and make our transport systems fit for purpose to achieve and maintain habitable cities and an efficient and pleasurable transport experience in the 21st century and, indeed, for centuries to come.


Thanks to a combination of leading European technology expertise, and the forward looking project initiatives funded by the European Commission, Europe is at the forefront of these developments, which, in places, are showing signs of disruptive revolutionary change, and in other places, exhibiting progressive evolution, to a safer and more ecologically sound travelling paradigm.























Figure 6.1: Future Transport system as envisaged by Popular Mechanics Magazine in the 1950’s



ITS standards deliverables (Standards, Technical Specifications, Technical Reports, Recommendations, recommended practices, etc.) are developed largely by volunteer experts involved in the sector, mostly with a commercial, political or academic interest in their production, but in many cases also enabled, in Europe’s case, by European Commission funded initiatives (sometimes in direct or indirect competition with each other).


The prime Standards Deliverables are developed by CEN, ISO and ETSI, with some specialised standards deliverables from IETF, IEEE, and SAE.


On the one hand it is really beneficial to base so much of ITS developments and implementations on internationally/European member state approved Standards, but as the sector evolves and grows ever more complex, how does the erstwhile implementer know where to begin?

What standards deliverables are available to help him/her introduce/implement their project?

How do those standards fit together, and what combinations are needed?

Without guidance, even standardisation experts struggle. What chance does the local authority, National DoT, or commercial implementer have?


The EU-ICIP Guide is designed to provide that assistance, information and guidance.


6.2       Context


This part of the EU-CIP Guide provides a brief overview of EU-ICIP as well as a discussion of the motivations that lead to the adoption of ITS standards and their objectives, and discusses the ethos and issues involved. EU-ICIP provides some advice (below) on implementation/instantiation of  ITS (see also Section 5 About ITS), raises strategic issues to be considered, information issues (sources and distribution), general application issues to be considered, and ways to address communications aspects.


In short EU_ICIP is designed to be a resource and support to assist you to develop and implement your project in a cohesive way.


EU-ICIP is not designed to instruct you, but to provide guidance and advice, and most importantly, hotlinks to where you will find more information and advice on specific aspects that you determine are of interest to you, in order to help you to make a success of your ITS project, If you are a student, EU-ICIP should provide guidance and the basis for much of your research,


It is the objective that EU-ICIP will provide a basis for information and knowledge of what communications and data standards are available, and provide the basis for interoperability and regulated requirements for ITS in Europe, informing potential users of the compatibilities and incompatibility issues of various options, and provide the opportunity for training opportunities, and guidance to universities to assist training programmes for ITS experts.


But it is important to state clearly that EU-ICIP provides GUIDANCE and not necessarily requirements. Interoperability is an essential and important aspect of efficient, fully functional ITS, but it is not the only consideration, and the particular aspects of any instantiation must also be taken into account….. that said, such considerations should not be used as an excuse to build a non interoperable ‘silo’ system, just because it is easier to do in the short term.





 6.3. Understanding EU-ICIP

This section provides a general purpose technical overview of EU-ICIP and the EU-ICIP Framework. 


While architectures, such as the comprehensive ARC-IT  and the European Framework Architecture FRAME describe the ‘what’ is to be achieved (see Section 7  -ITS Architecture), the EU-ICIP guide provides ‘How to best achieve at the current time’ guidance  (and will therefore be a living and hopefully regularly revised guide). 



EU-ICIP is a natural follow on to the EU initiative of the C-ITS platform.  According to the C-ITS Platform initiated by the European Commission, “……cooperative Intelligent Transport Systems (C-ITS) use technologies that allow road vehicles to communicate with other vehicles, with traffic signals, and roadside infrastructure as well as with other road users. The systems are also known as vehicle-to-vehicle communications, or vehicle-to-infrastructure communications.” (C-ITS Platform Final Report)  















C-ITS Wheel

(source: C-ITS platform.)


The C-ITS Platform final report stated “………. The C-ITS Platform, which gathers public and private stakeholders, represents all of the key stakeholders along the value chain including public authorities, vehicle manufacturers, suppliers, service providers, telecomm companies etc., and delivered in its first phase (November 2014 – January 2016) its contribution towards a shared vision on the interoperable deployment of Cooperative Intelligent Transport Systems in the European Union.)”.



However, having shared the vision, potential implementers (largely urban and other authorities or their agents) need to know what tools are available, and what standards combinations are required to implement their visions. In this respect, EU-ICIP takes into account the work of the C-ROADS platform (, and in particular the definition of C-ITS services and common specifications. 



EU-ICIP is envisaged as a natural follow-on to act as a living guide that will evolve and develop with the opportunities that technical evolution brings. But it must be remembered that while EU-ICIP embraces the C-ITS promise of C-Roads, its span is nor constrained to C-ITS but encompasses the whole paradigm of ITS and its standards deliverables.



6.4  EU-ICIP and the US NTCIP


Faced with problems to achieve cost effective and consistent instantiation across 50 US State Transportation Departments, of just the traffic management and control aspects of ITS, the US NTCIP initiative combined the development of a family of standards that provides both the rules for communicating (called protocols) and the vocabulary (called objects) necessary to allow electronic traffic control equipment from different manufacturers to operate with each other as a system, together with a path that required adoption and consistency in order to get access to federal funding.. 


NTCIP was the first set of standards for the transportation industry that allows traffic control systems to be built using a “mix and match” approach with equipment from different manufacturers. NTCIP standards reduce the need for reliance on specific equipment vendors and customized one-of-a-kind software, and combined with a requirement to comply with NTCIP standards to get Federal USDoT funding for electronic traffic control systems, US DoT has obtained consistency, interoperability, and an open market in this area.


Note: the CEN Standards deliverables:

CEN/TS 17400:2020              Intelligent transport systems - Urban ITS - Mixed vendor environments, methodologies & translators    


CEN/TR 17401:2020              Intelligent transport systems - Urban-ITS - Mixed vendor environment guide                                         

CEN/TS 17402:2020               Intelligent transport systems - Urban ITS - Use of regional traffic standards in a mixed vendor environment


CEN/TS 17466:2020               Intelligent transport systems - Urban ITS - Communication interfaces and profiles for traffic management


while not tied to funding constraints, provide specific guidance to achieving an open market in these aspects within the European context.


But, in addition to providing a route to funding projects, the NTCIP documents gave extremely valuable advice about what standards, and combinations of standards, are needed to implement a system in the USA. How to build an open, but secure, standards based implementation. Implementers have found this resource, information and advice, highly valuable to assist them to further their projects.


Move away from the access to funding, and step out from the limitation of just traffic management and control, into the wider needs of all ITS instantiation, right across the sector. EU-ICIP is designed to provide that resource, both as a technical report and, more importantly as a highly hotlinked website location where the designer, potential implementer, evaluator, inspector, actual implementer, students and operators of ITS systems, can find guidance.


EU-ICIP stands as a single website where you can research any ITS subject area where there are standards deliverables or standards under development; Find out what deliverables exist, what combinations are required, what flexibilities are (or are not) possible.


Every standards deliverable is hotlinked through to its on-board platform or abstract, and in most cases either to the full text of the document or source where you can acquire it (some documents need to be purchased to acquire the full text)..

Related organisation or summaries of organisations are directly hotlinked, and terms an abbreviations explained.


6.5       Designing ITS systems

In designing an ITS system, instantiators should try to avoid single supplier dependency – even if (because the supplier offers to take a problem away and solve the immediate problem) that seems to offer the easiest quick-fix. In this situation it is only normal for the supplier to do its best to make you dependent on it…. But when you want to change or expand the system….and you will….. you are at their mercy regarding the cost and, if the supplier has done its job most efficiently in its own interest, it will be difficult, or highly expensive for you to go out to competitive tender, so in the long term you will pay an unacceptable price or be tied into a solution which may not be the optimum solution for you in the long term.


It is even more difficult to avoid this dependency if the supplier has joined with you in a research project to develop an ITS solution to an issue, and you have achieved this project jointly. The following sections provide advice to help you avoid service provider dependency, even in these situations.


EU-ICIP offers the following steps (sections 6.6 – 6.14) to address and manage ITS design and instantiation:




6.6       How to Use EU-ICIP (generic)

There are many commercial project offerings that promise they are the best but all offer more or less the same thing- a thorough, structured and reviewed methodology. Project EU-ICIP doesn’t make any claims, but suggests that a) if you have a structured methodology that works for you, and you are familiar with, use it, if not. b) the steps below may provide a useful framework (and may need you to add one or two tweaks for the idiosyncrasies or political context of any particular project).


6.6.1 First identify your ITS Subject area and define its scope clearly

Develop the initial scope statement.

The scope statement is the document that defines what your project is setting out to achieve. Make sure you scope statement clearly identifies the limits/boundaries of the project (even to the extent of making explicit rider statements ‘this project includes W & X but excludes Y and Z). Be explicit regarding the deliverables included and excluded from a project..

A good scope statement should include the following aspects, explicitly (and tersely) made clear:


--Project objective

--Subject area and its limits

--Project Deliverables

--Key requirements

--Limits and exclusions

--Strategic impacts


The Project Deliverables section must define what exactly is in the scope of the project, while the subject area and its limits section must clarify what adjacent work is out of scope for the project.

View the scope statement as the yardstick against which your result/outcome will be judged. The clearer it is the better your result, and hopefully success, will be recognised.

Ambiguity in the scope statement, far from giving you flexibility, will give more opportunity for critics to categorise your project as a failure in some or all respects. If there are a range of possible outcomes, state these possible outcomes explicitly in the scope statement, don’t use ambiguous text.



6.6.2. Stakeholder and sponsor identification and analysis


It is important to first identify your stakeholders.

A stakeholder is a party with an interest in your project – a party that will benefit from, lose because of, or otherwise be affected, by the outcome or process of the project.

Stakeholders may be organisations, commercial or political entities and interest groups, or individuals that are affected by the activity of the project. They include:

  • Owners 

  • Managers 

  • Customers/clients/users

  • Workers 

  • Suppliers 

  • Financial backers/Sponsors

  • Community 


Stakeholders can be generally (but not always) be identified as

--Internal stakeholders (groups within the project - eg owners and workers) – and

--External stakeholders are groups outside the project - eg the local community or other actors in the paradigm, but not inside the project,


As your project evolves, you may have to take into account new stakeholders


Once you have identified the stakeholders, you need to characterise them, and particularly identify their needs and anxieties regarding the project (This is sometimes called ‘stakeholder analysis’).

Recognise too, the power and ability to influence that a stakeholder possesses. Key stakeholders in particular need to be well informed about your project objectives and progress.

Review your characterization of your stakeholders from time to time.

About 6.1 Background
fig 1 1_PopularMechanics-e1541581539449
About 6.2 Context
6.3 understanding ICIP
6.5 Designing ITS
6.6 How to use ICIP

6.6.3     Identify and resource the project team


Having a great idea is one thing, making it happen successfully, another!


Successful projects usually require the services of a project team. Who are they? What is the first guess of the skills required? How will they be able to allocate their resource to the team? and how will they/you fund provision of their resource?


We say ‘guess’ because the first attempt to identify/quantify is unlikely to be anything better than a guess. Regular review and refinement of required resources and associated costs is therefore required.



6.6.4     Identify and characterise your project plan


Involve as many of the proposed project team in this exercise as possible.

The project plan is a formal document that first identifies the project intended deliverables, and then characterises those deliverables. It then identifies, in principle at least, the processes that are used to execute and control the project, and identifies the steps to achievement. The project plan is not the project schedule. Then estimate the required budget, and work out how to fund it.


In an ITS system, specifically, the project plan needs to identify what data is necessary, who it needs to be exchanged between, identifying the sources and recipients, and identifying where suitable data concepts and their definitions already exist.


Identify the standards that can be used (the EU-ICIP Guide should hopefully be helpful here).


Outline a project management plan to explain how the project will be carried out, identifying milestones and their pass/fail criteria in order to achieve the key project management expectations. ISO 21500 may help here if you have a particularly complex project, or you might need only simpler processes especially for smaller projects.



6.6.5     Create a work content analysis / project schedule


This is the detailed project plan, with milestones, defined deliverables, timelines and budgets.


6.6.6     Review

At regular agreed periods (weekly, fortnightly, monthly. Quarterly, half-yearly, and whenever milestones or key dates are passed, each aspect of the project should be reviewed, preferably in a meeting involving key stakeholders and contributors.


6.6.7     Keeping track

Keeping track of actions, issues, risks and key decisions is an administrative challenge/chore, but is essential. Do this very regularly.  Ensure that minutes are properly recorded for all meetings. Minutes should include a list of Action items recorded, together with who is responsible to deliver and to what timelines.



6.6.8     Review the critical path


Whenever the schedule is updated, or at regular intervals, you should examine the critical path to determine if any tasks that directly impact a key milestone. key date, or achievement of a deliverable, have changed, particularly if they have slipped.


6.7       Procurement for ITS projects

6.7.1    General procurement principles

General procurement principals are well known and should be followed. For example:

Step 1 – Identify Goods or Services Needed. ...

Step 2 – Issue a ‘request for supply/ call for tender

Step 3 - Consider a List of Suppliers. ...

Step 4 – Negotiate Contract Terms with Selected Supplier(s). ...

Step 5 – Finalise the Purchase Order. ...

Step 6 – Receive Invoice and Process Payment. ...

Step 7 – Delivery and Audit of the Order. ...

Step 8 – Maintain Accurate Record of Invoices.

This is not the place to debate general procurement procedures and processes.

for more information see sources such as:





But the following subsections provide some specific advice in respect of ITS projects:




6.7.2    Situations to avoid in ITS project procurement


ITS projects often involve leading edge technology, or the first phase may even be a research project. In these cases it is often not possible to issue a call for tender in a competitive environment.


In these circumstances, in order to avoid long term single supplier dependency, the contract should include the development of generic standards as a reference to open long term supply.


In ITS projects in general, you should first search for relevant Standards. EU-ICIP, the bulk of which is topic/subject based, is designed to help you to do this. Having identified relevant standards deliverables, specify compliance to them by explicit reference to them in your call for tender/request for proposals.



The CEN Standards deliverables:

CEN/TS 17400:2020              Intelligent transport systems - Urban ITS - Mixed vendor environments, methodologies & translators  


CEN/TR 17401:2020              Intelligent transport systems - Urban-ITS - Mixed vendor environment guide                                         


CEN/TS 17402:2020               Intelligent transport systems - Urban ITS - Use of regional traffic standards in a mixed vendor environment


CEN/TS 17466:2020               Intelligent transport systems - Urban ITS - Communication interfaces and profiles for traffic management


while focussed on traffic management systems, provide good general advice for ITS procurement to enable and provide for a mixed vendor environment. 

These deliverables provide specific guidance to achieving an open market in the European context.

6.7 ITS Procurement
Implementing ITS

6.8       Implementing ITS systems


Following the advice in sections 6.5 – 6.7 above, systems implementers, including software and hardware developers for ITS, and especially CITS/Mobility Integration/Urban-ITS) will assist both vehicle-facing systems and infrastructure facing systems; software and hardware developers and systems integrators to implement a successful system.


However, vehicle-facing systems potentially have a further layer of complexity. If the system is aftermarket it will likely be complementary to anything in the vehicle, and in a similar paradigm to most infrastructure facing systems. But OEM fit vehicle-facing systems, or aftermarket systems that utilise the OBD-II port or otherwise connect to the core vehicle network. This may only require access to data that is legally required to be accessible (currently in a form declared by the auto-manufacturer, but, hopefully, in the near future to a format in accordance with ISO 21184. If greater interaction is required it will be necessary to negotiate with the vehicle-manufacturer directly.

Some of the lessons learned and common pitfalls encountered during actual ITS deployments are discussed and shared below.







6.9       Strategic level aspects


6.9.1      Strategic level aspects of ITS Systems

The following links provide useful information on a range of strategic aspects concerning ITS Systems and Standards deliverables:

CEN/TR 17143:2017 Intelligent transport systems - Standards and actions necessary to enable urban infrastructure coordination to support Urban-ITS.

The scope of this project was to undertake a pre-study providing stakeholder mapping, framework identification, gap analysis and identification of standards and related actions required to address the urban infrastructure aspects: the provision of


a) multimodal information services;

b) traffic management;


c) urban logistics, that are required to support the provision of Urban-ITS.


Specifically, the scope of this pre-study was to produce a technical report that will (by December 2015), for each area, specifically address the standardisation requirements to meet the following technical challenges:

- stakeholder engagement;

- common/interoperable data;

- multimodality;

- creation of (multimodal) transport datasets;

- multiple means of communication;

- urban logistics management

- creation of urban-interurban interfaces;

- use of open standards, architectures and specifications;

- enable rather than prescribe or proscribe.


While the formal deliverable of this pre-study was be a technical report, that the project team also identified areas for draft ‘New Work Item Proposals’ (and justifications) for work items to fill the identified gaps, where those gaps can be filled by Standards deliverables, and that the pre-study will also consider and make recommendations for any other support measures that are considered important or essential in order for the successful implementation, management and support of Urban-ITS in an environment where this is an administration controlled and led activity and not a community-wide managed or controlled activity.


The pre-study report, in addition to its submission to the European Commission, was a format suitable for adaptation to a European standardisation deliverable on Use Cases addressing the three areas of this request and highlighting their possible interdependencies. Specifically, a gap analysis identifying additional requirements and priorities for:


a) Architecture: high level proposals outlining the parameters for a European standardisation deliverable for Urban-ITS architecture integrating the three areas of this request and highlighting connexions or interfaces with surrounding ITS applications as well as compatibility or coherence with existing standards, technical specifications, data models.


b) Multimodal Information Services: Standardisation deliverables in support of new mobility services, such as car sharing, car-pooling, public bike sharing services, park & ride, bike & ride, etc. Alternative fuel infrastructure, including information on location and availability of stations, charging models and capacity at stations, (integrated) payment schemes, etc. A European standardisation deliverable on reference data model, common data dictionary and metadata structure for multimodal information services.


c) Traffic Management: Standardisation deliverables in support of European standards for: a set of traffic management measures (encompassing the necessary infrastructure / static road data, dynamic road status data, traffic data or traffic control data, weather data), a set of traffic re-routing, traffic prioritisation and access regulation measures including intersections management (supplemented by vehicle identification data). In particular, the different types of road user charging models set up in various cities as well as the modalities of shared use of dedicated lanes by different types of vehicles (e.g. freight, public transport, emergency vehicles) should be considered. European standards or European Standardisation deliverables on reference data model, common data dictionary and metadata structure for traffic management including access regulation.


 d) Urban Logistics (Including parking management): Standardisation deliverables in support of European standards for: Intelligent parking for light vehicles, commercial vehicles and trucks. (...)



The following deliverables are also considered useful in respect of implementing ITS projects:

ISO 17427-1 Intelligent transport systems (ITS) — Co-operative systems — Roles and responsibilities in the context of co-operative ITS architecture(s)

Cooperative Intelligent Transport Systems (C-ITS) are a promising advancement of Intelligent Transport Systems (ITS). Numerous applications, made possible only, or most efficiently, by the cooperation of actors (other vehicles, the infrastructure, service providers, even bystanders), are being devised that open up new possibilities to make traffic safer, more efficient and smarter. Technologies are being developed and improved to realize and support those new services and applications. But, to finally implement C-ITS and to achieve the benefits of greater safety and better mobility, multiple actors will have to cooperate with each other in a completely new way. Actors that have to date worked in isolation, i.e. in so called “silos”, will have to find a way to achieve these possibilities. New actors may also be required for the provision of some services. This requires a clear definition and assignment of behaviours, responsibilities and liabilities. Therefore a general, abstract organizational architecture with the description of the single roles, their behaviour, and the corresponding responsibilities, is an essential prerequisite for the deployment of C-ITS.


The organizational relationships with the description of roles and responsibilities, is a crucial part of the whole C-ITS architecture. C-ITS is not an objective in itself, it is a means to achieve the potential of service provision through the cooperation of actors involved in the ITS sector. The architectural viewpoint comprising the organizational architecture has extensive influences on the deployment and implementation of C-ITS.


This document describes the high level roles and responsibilities of a C-ITS service provider and aligns it with other C-ITS standards and specifications.


This document contains a detailed description of the (actor invariant) roles nd responsibilities required to deploy and operate Cooperative-ITS (C-ITS).


The organization/organization of actors / roles described in this document are designed to be appropriate for any fully operational system that uses the C-ITS concepts and techniques in order to achieve its service provision. This document is presented in terms of an organizational or enterprise viewpoint as defined in ISO/IEC 10746-1.


This document is for all types of road traffic of all classes, and for any other actors involved in the provision of applications and services which use C-ITS techniques to achieve service provision. The description of roles is technology agnostic and, in terms of C-ITS, agnostic in respect of communication modes and embraces vehicle-vehicle communications, vehicle-infrastructure communications and infrastructure-infrastructure communications.


This document provides a methodology for the identification of service specific roles and their corresponding responsibilities based on a process oriented approach. Additionally, the methodology is used to identify the roles and responsibilities for C-ITS in general. Both the methodology as well as the roles and responsibilities for C-ITS are deduced from ISO/IEC 10746-1ISO/IEC 10746-2, ISO/IEC 10746-3, the reference model of Open Distributed Processing. Open Distributed Processing offers five viewpoints of which the enterprise viewpoint corresponds with the organizational architecture and its roles and responsibilities.


To limit the scope of the document to the core of C-ITS, the roles are separated into external and internal. Considered to be internal are all roles that are highly relevant for the purpose of achieving service provision by means of C-ITS. Considered to be external are all roles involved in C-ITS, but not set up only for the purpose of C-ITS.


This document provides a description of a high-level architectural viewpoint on C-ITS. It is designed to be used as a blueprint when implementing service provision systems that use C-ITS, and the corresponding organizational structures. The characteristics of C-ITS entail a huge number of data/ information exchanges. Therefore the implementation stringently respects privacy and data protection as it is defined in ISO/TR 12859 and in national laws and regulations (where instantiated). Privacy and data protection affects all roles defined in this document due to these characteristics and all actors occupying roles in C-ITS respects the corresponding standards and regulations.


ISO TR 17427-2 Intelligent transport systems - Cooperative ITS - Framework Overview

 This Technical Report characterizes and provides an overview of the framework which enables collaborative and cooperative ITS to operate and defines the characteristics and components of a Cooperative-ITS (C-ITS), its context and relevance for ITS service provision, and provides references to International Standards deliverables where specific aspects of C-ITS are defined. The objective of this Technical Report is to raise awareness of and consideration of such issues and to give pointers, where appropriate, to International Standards deliverables existing that provide for all or some of these aspects. This Technical Report does not provide specifications for solutions of these issues.


This Technical Report is agnostic in respect of technology and operates with whatever communications and hardware technologies can support its functionalities.


NOTE Other deliverables in this family of C-ITS standards will define specific aspects of technology and behaviour and the roles and responsibilities within the context of C-ITS.



ISO TR 17427-3 Intelligent transport systems - Cooperative ITS – Concept of operations (CONOPS) for ‘Core’ systems


This Technical Report provides the high-level generic requirements for the “Concept of operations” for a ‘Core System’ (CorSys) to support C-ITS service delivery. It is intended as an input to the planning and development elaboration of core functions that will support the deployment of cooperative intelligent transport systems (C-ITS) in a connected vehicle-highway paradigm


The objective of this Technical Report is to raise awareness of and consideration of such issues and to give pointers, where appropriate, to standards existing that provide specifications for all or some of these aspects. This Technical Report does not provide specifications for solutions of these issues.


This Technical Report is agnostic in respect of technology and operates with whatever (and probably multiple) communications technologies and hardware technologies that can support its functionalities.





ISO TR 17427-4 Intelligent transport systems - Cooperative ITS - Minimum system requirements and behaviour for core systems


The scope of this Technical Report is, as an informative document, to identify potential critical minimum system requirements and behaviour for core systems issues that C-ITS service provision may face or introduce, to consider strategies for how to identify, control, limit or mitigate such issues. The objective of this Technical Report is to raise awareness of and consideration of such issues and to give pointers, where appropriate, to subject areas and, where available, to existing standards deliverables that provide specifications for all or some of these aspects. This Technical Report does not provide specifications for solutions of these issues.


ISO TR 17427-5 Intelligent transport systems - Cooperative ITS - Common approaches to security;

This TR was superseded by ISO TS 21177. (See also ITS Communications- Cybersecurity)



ISO TR 17427-6 Intelligent transport systems - Cooperative ITS - ‘Core system’ risk assessment methodology


The scope of this Technical Report is to identify critical technical and financial risks that can impact the core system deployment supporting C-ITS vehicle and highway systems service provision and to provide means to evaluate such risks.


This Technical Report is designed to embrace C-ITS vehicle and highway systems where there is some institutional involvement and support, by the direct or indirect provision of core system support, and it is the risks associated with the deployment of ‘Core Systems’ that provide the focus of this Technical Report.


This Technical Report does not provide a calculated ‘global’ risk assessment for C-ITS, but identifies the principal causes of risk, and provides a consistent methodology for a jurisdiction, core system operator, or application service provider, to assess the risks that they face. The objective of this Technical Report is to raise awareness of and consideration of such issues and to give pointers, where appropriate, to standards deliverables existing that provide specifications for all or some of these aspects. This Technical Report does not provide specifications for solutions of these issues.



ISO TR 17427-7 Intelligent transport systems - Cooperative ITS - Privacy aspects

The scope of this Technical Report is as an informative document to identify potential critical privacy issues that C-ITS service provision may introduce; to consider strategies for how to control, limit or mitigate such privacy issues; and to give pointers, where appropriate, to standards deliverables existing that provide specifications for all or some of these aspect and to limit the risk of exposure to the financial consequences of privacy issues.

The objective of this Technical Report is to raise awareness of and consideration of such issues. This Technical Report does not provide specifications for solutions of these issues.

NOTE: In Europe this document predates, and  is largely superseded by the General Data Protection Regulation

6.9 Strategy Aspects

6.9.2      Relative impact of ITS Projects

While some ITS projects have only very local import (and simply make a process more efficient or provide a better service), other  ITS services have strategic import.


Sometimes that import is obvious. For example, the benefits of a blind spot warning system, or adaptive cruise control system are clear, and at the same time limited in extent. The instantiation of automated vehicles will require strategic decisions about the situations where they can be used and infrastructure and management changes that will be required.

However, sometimes the strategic consequences are not thought through, and either unforeseen consequences occur as a result. One example of this has been the development of contactless/’touch and go’ ticketing systems. When London Transport introduced its ‘oyster card’ system, or the Brussels metro system introduced its payment card, where users topped up a prepay card, which decremented on exit from each journey, they were hailed as revolutionising public transport payment. This beneficially impacted the systems cash flow (they were prepayment systems), but required the equipping of all station ingress/egress points with proprietary technology both different, but both turning out to be expensive to maintain. Topping up the cards was slow and created its own queues (particularly with the automated card-based top-up system in Brussels, an international city, but recognising only Belgian payment card). But touchless payment card systems (debit and credit cards)  had been standardised in the 1990’s (ISO 14443 )but were not considered for either system. As touchless payments using bank payment cards or smartphone apps became predominant payment systems, these not so long ago revolutionary payment systems quickly looked dated, and the transport authority has had, in both cases, to completely re-equip every ingress and egress point across the whole network. Long term maintenance costs will be significantly reduced, but there was a very significant conversion cost that a good initial strategic assessment may have avoided.

Local authorities who quickly took up the opportunity for escooters use in cities on the well intentioned premise to reduce traffic pollution almost universally failed to see the impact of escooters abandoned and littering streets, causing mess and hazards to pedestrians and VRU’s.

If you slide back up the page to 6.6.1, you will see that the suggested scope statement includes a strategic impact assessment. It is recommended to conduct this exercise at an intellectual level at the start of the project, while you are strategically scoping out the project, for every project, even for projects where you can’t obviously see a strategic impact. Indeed this exercise is even more important where there is no major strategic impact foreseen. Understanding strategic impacts at the start of the project significantly improves the chances to adapt the project or mitigate adverse impacts.


6.10    Information level aspects


Intelligent transport systems are about exchanging or providing data upon which service provision decisions can be taken.

In-vehicle systems may be mechanical, electronic use sensor information or data, but are in essence self contained within the system of the vehicle (and these aspects are standardised by CEN TC301 and ISO TC22).

A key feature of ITS is that either the data is exchanged between different systems, or between part of a system on-board and part of a system offboard, or between the on-board system and another system offboard. In this context, offboard may mean the infrastructure, or a system on another vehicle.

The common feature of all these systems, whatever their application purpose, is that the system depends on the exchange of data,  viz information, between one point (in ITS we call them ITS-Stations), although many, particularly legacy,  systems have used and continue to use point-to-point communications using a range of, usually standardised protocols. ITS may use wired or wireless media, or a combination of media; and communications involving vehicles and other entities are almost by definition wireless when the vehicle is outside of the workshop.

See section 8 regarding ITS communications, section 7 regarding ITS system architectures, and section 9 regarding cooperative ITS/CCAM systems.


Regardless of the communications medium, system service is enabled/provided by the exchange of data, so the security and veracity of that data and its transfer is crucial. See section 9.6 Cybersecurity.






6.11    Application level aspects 

See the application sections of this guide:


Section 10: EFC

Section 11: eSafety/eCall

Section 12: Freight & fleet

Section 13: Kerbside

Section 15: Mobility integration


Section 16: Parking


Section 17: Public transport


Section 18: Railway Information


Section 19: Spatial and Geographic


Section 20: Stolen vehicles


Section 21: Traffic control & Management


Section 22: Traffic and Traveller information


For aspects that are likely to involve local authorities, see also:


Section 14: Local authority aspects


6.12    Communications aspects

See Section 8: ITS communications



6.13    Testing

Testing is the essential tool for successful deployment of services provided by means of technical equipment and software. Testing is about validating implementations with respect of

  • proper consideration of standards and specifications;

  • interoperability between equipment provided by different vendors;

  • performance at the service level;

  • reliable exception handling.


Basically, several different complementary test approaches are known:

  • Conformance testing using standardized TTCN-3 test suites.

TTCN-3 is a standardized test specification language enabling identical and comparable testing in different test laboratories. A test suite specification typically consists of three parts:

  1. Protocol Implementation Conformance Statement (PICS) or Implementation Conformance Statement (ICS), which is a check-list with tick-boxes used to declare which features of a specification are supported in an Implementation under Test (IUT), which is contained in a System under Test (SUT).

  2. A natural language description of test cases, referred to as "Test Suite Structure and Test Purposes".

  3. An Abstract Test Suite (ATS) specification with TTCN-3 executable test code.


This testing approach allows to check details of an IUT.

Conformance testing is a pre-requisite for interoperability testing.

  • Interoperability testing.

Equipment from different vendors is tested in a laboratory environment for interoperable performance, with a possibility to look into some details of an IUT.

Interoperability testing is a pre-requisite for field trials.

  • Field trials

Field trials aim on validating proper performance at the service level (system performance in real operational environment. It is a black-box testing based on the assumption, that conformance and interoperability tests already were passed successfully.

Field trials are based on specifications developed by projects, rather than standard deliverables.

An introduction to conformance and interoperability testing in ITS is provided in the ETSI EG 202 798 on "Framework for conformance and interoperability testing" (, providing a general high-level overview. EG 202 798 is complemented by the CEN/ISO TS 20026 on "Test Architecture" (, facilitating implementation of test interfaces in an SUT to connect the IUT to the test computer.

Most test suites available for ITS so far were developed at ETSI's competence Centre for Testing and Interoperability (CTI); see However, development of test specifications is also within the scope of ISO/TC 204 and CEN/TC 278. ETSI CTI is also performing plug-test events for interoperability testing.



6.15    EU-ICIP Maintenance

 The WG secretary is responsible to electronically supply, or get the Project Leader to supply to the EU-ICIP administrator

 at the following document, completed

  1. When the project is approved as a new work item (not PWI)

   2. When the project is approved as a standards deliverable (or abandoned)






CEN is committed to keep the EU-ICIP up to date on a regular basis. 

6.10 Information aspects
6.11 App level aspects
new project notification ti EU-ICIP.PNG
6.14 Testing
6.15 maintenance
6.16 About the team

6.16    EU-ICIP : About The Team


Team Leader: Dr R Williams

 Following line management responsibility, Bob Williams has many years experience of Management, Strategy, Behaviour and Technology Consultancy. A qualified accountant and marketeer by profession, and with experience in organisation development and the behaviour sciences, his practical approach to opportunity and problem solving has been internationally recognised. He has successfully fulfilled positions as a full time director, and has fulfilled part time and non executive directorship roles in several companies. 


He is a leading expert in ISO, CEN, & BSI standardisation processes and has led and participated in Project Teams in areas of Automatic Identification, RFID and other technologies, and, over the last 20 years has focussed on  Intelligent Transport Systems, where he has led and participated in many EC funded Project Teams. He is currently Convenor of CEN TC278 WG15 (eSafety) and Coordinator of CEN TC278 WG17/ISO TC204 WG19 (Mobility Integration). He has been the project leader/editor of nearly 150 European and International Standards and is the author of  “ITS Standards” (Artech House: 2008), “Automated Vehicles and MaaS- Removing the Barriers” (Wiley:2021) and several other technical publications.

Architecture Expert: F. Caneschi

Has over 40 years experience in systems architecture and ICT, including OSI and ODP standards; has been actively involved in the development of  EFC standards for more than 20 years; has been involved in C-ITS for more than 15 years and in urban ITS and mobility integration since their inception as areas of standardisation


Communications Expert: Dr HJ Fischer

With over 30 years experience in leading edge communications technology, Dr Fischer has been the team leader, editor or significant contributor to most of the C-ITS communications standards developed over the last 20 years.


CCAM Expert: B. M. Elnes

Hands on experience using ITS-G5, is the Lead Engineer for Nordic Way 2, and other relevant projects and has over 25 years relevant experience.


Local Authority Expert: S. Hoadley

With more than 20 years experience first working within the local authority environment, then coordinating local authority representation across Europe and with the European Commission, Suzanne brings an in depth knowledge of how local authorities function and provide and introduce transportation innovation, and their needs from transportation standardisation, and measures to coordinate these activities across the continent. Currently working with POLIS in Brussels.


Application Area Experts:

L. Blaive

After a career leading and being a major contributor to Government transportation projects in various entities of French Ministry of Public Works and Transport, Loic has now focussed a career as an independent consultant specialising in projects bringing ITS potential into reality. He has more than twenty years of experience in standardisation and led the French delegations to CEN/TC 278 and ISO/TC 204 for several years. He also has been Convenor of the Working Group in CENTC278 for "ITS spatial data" for five years.


P. Burton

An experienced Programme Director with more than twenty years experience in traffic management and traveller information  and with an extensive international network, Paul has been, among other things, the Convenor responsible for leading the Standardization work for Traffic and Traveller Information using ALERT C, TPEG, Binary and other techniques over a period of more than 20 years.


M. Cartwright

An expert in traffic management solutions, Mark is a founder director of Centaur Consulting Limited. He has broad-ranging consulting expertise in the development of business processes and the cost-effective application of technology to them. In the public sector he has worked for UK Government Departments, non-Departmental Agencies, emergency services, and European bodies. In the private sector, he has supported energy utilities, telecommunications operators, retailers and financial services.


J. Engdahl

Involved in microelectronic communications since the early 1990’s, Jesper has been involved in CEN TC278 since its inception and Convenor of the Electronic Fee Collection standardisation working groups on worldwide and European levels in ISO and CEN for most of that period. With Rap Trans Ltd since 2003, he has wide experience of a wide range of ITS applications.


J. Harrod Booth

Over a period of more than 25 years Jon has extensive experience in standardisation and data modelling activities related to a wide range of ITS and TM systems and is the current Convenor of WG8 (RTD) and has played a significant role the evolution of the DATEX specifications. He has perhaps a unique exposure to the standardisation domains of C-ITS, freight and fleet, traffic and traveller information systems, traffic management systems, parking data, location referencing and spatial/digital map standardisation and is active in the current standardisation work of numerous CEN and ISO Working Groups.

bottom of page