Milestone 10 – Roll out Guidelines and Best Practices of ......Milestone 10 – Roll out...

Milestone 10 – Roll out Guidelines and Best Practices of Pilot Operation

Version number: 1.0

Main author: Peter Schmitting

Dissemination level: PU

Lead contractor: ERTICO

Due date: 30/11/2018

Delivery date: 05/07/2019

Delivery date updated document:

Grant Agreement No: INEA/CEF/TRAN/M2015/1143833

Action No: 2015-EU-TM-0159-S

Milestone 10 – Roll out Guidelines and Best Practices of Pilot Operation 1.0

05/07/2019 2 © InterCor Consortium

CONTROL SHEET

Version history

Version Date Main author Summary of changes

V0.1 02/11/2018 Peter Schmitting (ERTICO) First interim version,

skeleton

V0.2 10/12/2018 Fred Verweij (RWS) Revision incorporating

NL partners comments

V0.3 14/02/2019 Nuno Rodrigues (RWS) Revision incorporating UK, NL BE and FR first inputs

V0.4 26/02/2019 Peter Schmitting (ERTICO) inputs Patrick Hofman + PS and UK inputs and clean up

V0.5 15/03/2019 Peter Schmitting (ERTICO) Merged versions from FR and NL into BE version

V0.6 18/03/2019 Peter Schmitting (ERTICO)

Added UK remarks in appendices A and B,

added page header

V0.7 28/03/2019 Nuno Rodrigues (RWS) Revision incorporating UK, NL BE and FR inputs and texts

V0.8 09/04/2019 Nuno Rodrigues (RWS) Revision incorporating cost considerations scenarios

V0.9 28/04/2019 Peter Schmitting (ERTICO) Added BE, NL, FR and UK inputs

V0.10 29/04/2019 Peter Schmitting (ERTICO) Applied new clause structure

V0.11 13/05/2019 Nuno Rodrigues (RWS) Revision incorporating UK, NL BE and FR inputs and texts

V0.12 16/05/2019 Peter Schmitting (ERTICO) Review document and update executive summary

V0.13 29/05/2019 Peter Schmitting (ERTICO) Final draft version after proof reading and spell and format checking

V0.14 18/06/2019 Peter Schmitting (ERTICO) Very final draft version after inclusion of late UK comments

V0.15 28/06/2019 Peter Schmitting (ERTICO) Advisory board comment (A. Stevens)



addressed, document references added

V1.0 05/07/2019 Iuliia Skorykova, Giacomo

Somma (ERTICO) Final Quality Check

Name Date

Prepared Peter Schmitting (ERTICO) 18/06/2019

Reviewed Core Management Team, Advisory Committee,

and General Assembly 28/06/2019

Authorised Ronald Adams (NMIE-R) 05/07/2019

Circulation

Recipient Date of submission

INEA 05/07/2019

InterCor consortium 05/07/2019

Authors (full list):

Cristina Buraga (CEREMA France)

Patrick Hofman (RWS)

Nuno Rodrigues (RWS)

Peter Schmitting (ERTICO)

Richard Silvester (TFL)

Anne Verwimp (Flanders)

David Weston (WSP)



Project Coordinator

Ronald Adams

Rijkswaterstaat

Office address: Toekanweg 7, 2035 LC, Haarlem (NL)

Postal address: Postbus 2232, 3500 GE, Utrecht (NL)

Mobile: +31 6 518 480 77

Email: [email protected]

Legal Disclaimer

The information in this document is provided “as is”, and no guarantee or warranty is given that the information is fit for any particular purpose. The content of this document reflects solely the views of its authors.

The InterCor consortium members, jointly or individually, shall have no liability for damages of any kind including, without limitation, direct, special, indirect, or consequential damages that may result from the use of these materials.

Neither the European Commission nor the Innovation and Networks Executive Agency (INEA) are liable for any use that may be made of the information contained therein.



TABLE OF CONTENTS

List of Figures ........................................................................................................... 8

List of Tables ............................................................................................................ 8

Terms and abbreviations ......................................................................................... 9

1 Executive summary ......................................................................................... 10

2 Introduction ...................................................................................................... 11

2.1 Purpose of this document ...................................................................................11

2.2 Scope of Document ..............................................................................................11

2.3 Intended Audience ...............................................................................................11

2.4 Document Structure .............................................................................................11

2.5 InterCor Contractual References ........................................................................12

3 Pilot objectives, requirements and system concept ..................................... 13

3.1 Overview ................................................................................................................13

3.2 Overall vision, aims and objectives of the pilot .......................................................13

3.3 Requirements gathering .........................................................................................14

3.3.1 Communication options/considerations ............................................................. 15

3.4 System concept ......................................................................................................15

4 Pilot deployment .............................................................................................. 18

4.1 Overview ................................................................................................................18

4.2 Possible approaches ..............................................................................................19

4.2.1 “Learning by doing” ........................................................................................... 19

4.2.2 “V-model” .......................................................................................................... 20

4.2.3 "Agile" ............................................................................................................... 20

4.3 Project deliverables ................................................................................................21

4.3.1 Work Package 1 – Infrastructure and Systems Design ...................................... 21

4.3.2 Work Package 2 – Safety Governance .............................................................. 21

4.3.3 Work Package 3 – Pilot Implementation/Deployment ........................................ 22

4.3.4 Work Package 4 –Pilot Operations and Maintenance ........................................ 22

4.3.5 Work Package 5 – Evaluation ........................................................................... 22

4.3.6 Work Package 6 – Stakeholder Engagement .................................................... 22

4.4 Procurement strategy .............................................................................................22

4.5 Deployment timeline ...............................................................................................23



4.6 Acceptance test strategy considerations ................................................................24

4.7 Safety governance .................................................................................................24

4.8 Risk management plan ...........................................................................................25

4.9 Stakeholder engagement .......................................................................................26

4.9.1 Communications Action Plan............................................................................. 26

5 Site design and technical considerations ...................................................... 29

5.1 Overview ................................................................................................................29

5.2 Site design .............................................................................................................29

5.3 Communication equipment .....................................................................................30

5.3.1 ITS-G5 .............................................................................................................. 30

5.3.2 Cellular .............................................................................................................. 33

5.3.3 Hybrid ............................................................................................................... 33

5.4 Other systems and equipment ................................................................................34

5.4.1 HMI considerations ........................................................................................... 34

5.4.2 Central Unit and data access considerations ..................................................... 35

5.5 Security and privacy aspects ..................................................................................35

5.5.1 Security ............................................................................................................. 35

5.5.2 Privacy .............................................................................................................. 37

6 Pilot operation and maintenance .................................................................... 38

6.1 Overview ................................................................................................................38

6.2 Pilot governance ....................................................................................................38

6.3 Pilot site user support procedures ..........................................................................38

6.4 Pilot operations scenarios and procedures .............................................................39

6.5 Vehicle fleet provision and driver training ...............................................................40

6.6 Third party access to the pilot testbed ....................................................................41

7 Pilot evaluation ................................................................................................ 43

7.1 Overview ................................................................................................................43

7.2 General considerations ..........................................................................................43

7.3 Technical evaluation...............................................................................................43

7.4 User acceptance ....................................................................................................43

7.5 Impact assessment ................................................................................................44

8 Cost considerations......................................................................................... 45

9 Key points, main considerations .................................................................... 46



10 Bibliography ..................................................................................................... 47

Appendix A – Pilot Deliverables Matrix ................................................................ 48

Appendix B – Description of pilot Deliverables ................................................... 50



LIST OF FIGURES

FIGURE 1: ITERATIVE PROCESS OF THE LEARNING BY DOING APPROACH ............................19

FIGURE 2: SYSTEMS ENGINEERING ‘V’ MODEL FOR SYSTEMS DESIGN AND IMPLEMENTATION

..................................................................................................................................20

FIGURE 3: THE AGILE APPROACH FEATURES SEVERAL SPRINTS DURING THE DEVELOPMENT

PERIOD ........................................................................................................................21

FIGURE 4: TYPICAL CONNECTED VEHICLE AND ROADSIDE INFRASTRUCTURE. .....................30

FIGURE 5: HIGH LEVEL DIAGRAM FOR HYBRID COMMUNICATION ........................................33

LIST OF TABLES

TABLE 1: EXAMPLE OF KEY OPERATIONAL ROLES. ..........................................................27

TABLE 2: EXAMPLE RACI MATRIX ..................................................................................28

TABLE 3: POSSIBLE RSU INSTALLATION CONFIGURATIONS ..............................................32

TABLE 4: EXAMPLE OF OPERATIONAL PROCEDURES THAT MAP TO OPERATIONAL SCENARIOS

..................................................................................................................................39

TABLE 5: EXAMPLE DRIVER READINESS CHECKLIST ........................................................41

TABLE 6: ROUGH INDICATION OF COSTS FOR TWO TYPES OF PILOTS .................................45



Terms and abbreviations

Term / Abbreviation Definition

AC Advisory Committee

AL Activity Leader

ASR Action Status Report

CMT Core Management Team

EC European Commission

ETA Estimated Time of Arrival

GA Grant Agreement

GLOSA Green Light Optimised Speed Advice

GDPR General Data Protection Regulation

HMI Human Machine Interface

INEA Innovation and Networks Executive Agency

IVS In Vehicle Signage

IPR Intellectual Property Rights

MCTO Multimodal Cargo Transport Optimisation

ML Milestone Leader

MS Member State

OJEU Official Journal of the European Union

PC Project Coordinator

PVD Probe Vehicle Data

RWW Road Works Warning

SE Service Editor

TCC Traffic Control Centre

TIC Technical & Interoperability Coordinator

TMS Traffic Management System

UC Use Case



1 Executive summary

Activity 3 Pilot Operation consists of the deployment of the actual pilot operations in the four Member States (MS) of the InterCor project. The present deliverable describes roll out guidelines and best practices of pilot operation. The target audience for this document are organisations and consortia that plan to deploy C-ITS services in a pilot site on a local or national level.

The following information is provided:

Pilot objectives, requirements and system concept o Overall vision, aims and objectives of the pilot o Requirements gathering o System concept

Pilot deployment o Possible approaches o Project deliverables o Procurement strategy o Deployment timeline o Acceptance test strategy considerations o Safety governance o Stakeholder engagement

Site design and technical considerations o Site design o Communication equipment

ITS-G5 Cellular Hybrid

o Other systems and equipment o Security and privacy aspects

Pilot operation and maintenance o Pilot governance o Pilot site user support procedures o Pilot operations scenarios and procedures o Vehicle fleet provision and driver training o Third party access to the pilot testbed

Pilot evaluation o General considerations o Technical evaluation o User acceptance o Impact assessment

Cost considerations

Key points, main considerations

The final version of the present document is the report to Milestone 10 which was originally due on 30th of November 2018 according to the Grant Agreement (GA). As the last pilot operation in France is scheduled for Q2/2019, the publication has been delayed until after that pilot has been launched successfully. Indicator for the acceptance of the deliverable is the complete description of roll out guidelines and best practices for pilot operation including cost considerations for all four MS.



2 Introduction

2.1 Purpose of this document

The purpose of the present document is the presentation of roll out guidelines and best practices gathered during the deployment of the four pilot sites and the actives pilot operation in the InterCor MS:

Belgium/Flanders

France

Netherlands

The United Kingdom

InterCor (Interoperable Corridors) links the C-ITS corridor initiatives of the Netherlands C-ITS Corridor Netherlands-Germany-Austria and the French one defined in SCOOP@F [6], [7], and extending to the United Kingdom and Belgium C-ITS initiatives.

2.2 Scope of Document

The scope of the present document is describing the most important aspects of the InterCor pilot roll out. This includes the deployment approaches chosen by the MS, the guidelines and best practices developed and used during the deployment and cost considerations.

The InterCor specifications used in pilot roll out and pilot operation are listed in the bibliography of the present document.

The guidelines and best practices that are provided in this document are based on the pilot deployments by the four Member States (BE, FR, NL, UK) for the InterCor project. However, each pilot is unique and requirements will vary from pilot to pilot. Therefore, these guidelines may not cover all requirements for other projects and the guidance that is provided is not intended to be prescriptive. The reader should therefore be aware that not all of the documents defined in the following sections will be required for all Pilot deployments. Diligence in the planning stage is required to identify those documents that are relevant for each particular pilot.

2.3 Intended Audience

The document could be used in future C-ITS roll out exercises. The present document addresses organisations and consortia that plan to deploy C-ITS services in a pilot site on a local or national level and could also be relevant for the actual roll out.

2.4 Document Structure

The document is comprised of ten sections and two appendices

Chapter 1 contains the executive summary.

Chapter 2, the present chapter introduces purpose, scope and structure of the document.

Chapter 3 describes the steps from an overall vision, to more concrete objectives, to gathering requirements and to develop a system concept to fulfil those requirements.

Chapter 4 focusses on the project management activities to be considered when deploying a pilot. It also includes the possible approaches.

Chapter 5 covers the technical systems to carry out the pilot.

Chapter 6 focusses on the activities to be carried out during the phase of pilot operations.

Chapter 7 describes the activities to be carried out for the evaluation of the pilot.



Chapter 8 covers the cost considerations.

The key points/main considerations section in chapter 9 summarizes the InterCor experiences and offers an outlook on future developments.

The bibliography in chapter 10 lists the specifications used in the pilot deployments.

2.5 InterCor Contractual References

InterCor is an action co-financed by the European Union under the Grant Agreement number INEA/CEF/TRAN/M2015/1143833. The Project duration is 36 months, effective from the 1st of September 2016 until the 31st of August 2019. It is a contract with the Innovation and Networks Executive Agency (INEA), under the powers delegated by the European Commission.

Communication details of the Agency:

Any communication addressed to the Agency by post or e-mail shall be sent to the following address:

Innovation and Networks Executive Agency (INEA)

Department C – Connecting Europe Facility (CEF)

Unit C3 Transport

B - 1049 Brussels

Fax: +32 (0)2 297 37 27

E-mail addresses: General communication: [email protected]

For submission of requests for payment, reports (except ASRs) and financial statements: [email protected]

Any communication addressed to the Agency by registered mail, courier service or hand-delivery shall be sent to the following address:

Innovation and Networks Executive Agency (INEA)

Avenue du Bourget, 1

B-1140 Brussels (Evere)

Belgium

TEN-Tec shall be accessed via the following URL:

https://webgate.ec.europa.eu/tentec/

All communication with the INEA or the European Commission shall be done via the Project Coordinator, Mr. Ronald Adams.

mailto:[email protected]

mailto:[email protected]

https://webgate.ec.europa.eu/tentec/



3 Pilot objectives, requirements and system concept

3.1 Overview

This section provides the steps from an overall vision to more concrete objectives, gathering requirements and developing a system concept to fulfil those requirements.

For a C-ITS pilot to be successfully deployed, all aspects of the deployment should be considered during its planning and development stages.

In addition to considering the technical aspects of the pilot (such as the design and deployment of systems, infrastructure and services), consideration should also be given to the operational aspects of the pilot. (For instance, the organisational arrangements that will be required to effectively manage the operational phase of the pilot, the key roles that will be required, how roles will be resourced, operational processes and procedures, safety governance, training, evaluation requirements, systems maintenance and stakeholder management).

Sub-section 3.2 below briefly describes several key aspects; the associated deliverables that the InterCor consortium members considered for their pilots are covered in 4.3. These are then described in greater detail in the following sections of the document and in appendices A and B.

The guidelines and best practices that are provided in this chapter are based on the pilot deployments by the four Member States for the InterCor project. However, each pilot is unique and requirements will vary from pilot to pilot. Therefore, these guidelines may not cover all requirements for other projects and the guidance that is provided is not intended to be prescriptive but is an example of best practice. The reader should therefore be aware that not all of the documents defined in the following sections will be required for all pilot deployments. Diligence in the planning stage is required to identify those documents that are relevant for each particular pilot.

3.2 Overall vision, aims and objectives of the pilot

Prior to commencing design and planning stages of the pilot, there needs to be a clear vision statement for what the pilot is looking to achieve at a strategic level that defines the overall direction and sets the context for more specific aims and objectives.

Within the boundaries of the vision statement consideration should be given to the specific aims and objectives that the pilot is looking to achieve. It is important that the aims and objectives are clearly defined, and that they are achievable and measurable, where possible, so that it can be determined if/when goals and benefits have been realised. They should be relevant in the context of the Vision Statement – contributing to the achievement of the vision – and they should address the key business, social, economic, policy and technological drivers for the responsible organisation.

It is recommended objectives are SMART, i.e.:

S - Specific

M - Measurable

A - Achievable

R - Realistic

T - Time bound

Where the pilot is being delivered by more than one organisation, it is recommended that the ‘Vision’ and its associated aims and objectives are agreed by all partners from the outset, to enable all parties to work together towards common goals. For clarity, these may also be documented within a Terms of Reference (ToR) that all parties can agree to and adhere to.

The pilot should also take into account the following aspects:



Have an appreciation of the wider C-ITS deployment objectives both locally and internationally (e.g. new use cases, interaction with other projects and neighbouring road networks);

Consider constraints and practicalities of deployment in terms of requirements for traffic management, existing devices/services and interfacing with local systems.

3.3 Requirements gathering

The Requirements gathering presents the preliminary analysis of strategic and tactical needs and the technical and operational means necessary to achieve the objectives of the pilot project.

The process for gathering main stakeholder requirements is listed below, explaining how they are captured and addressed by the Pilot, especially the conflicting requirements.

Best practices:

Prior to the studies, it would be necessary to consider re-using requirements from previous (European/interoperable) similar tests and pilots.

Focus on functional use case description and selection first.

Consider to distinguish user requirements from solution requirements. Not all user requirements can be met, but all solution requirements should be met. E.g. user requirement for the GLOSA service would be that the speed advice can easily be adapted and as such is stable. Since the incumbent intersection controllers are highly adaptive, this user requirement cannot (yet now but at further stages) be translated into a solution requirement.

Consider to relate the requirements to the project objectives. This helps avoiding imposing requirements that are not critical and impossible to meet. E.g. truck parking interoperability requires a common data-exchange standard. It does not require standardisation of requirements on the HMI.

In a global way, a best practice approach would adopt the following steps:

o Identify stakeholders (strategic, operational, technical)

o Consult appropriately with internal partner stakeholders, e.g. arrange meetings/workshops with stakeholders to obtain their requirements.

o Document and prioritise requirements using a MoSCoW methodology.

(MoSCoW = Must have, Should have, Could have and Will Not have)

o Agree the classification of requirements with all stakeholders and identify any areas of conflict/contradiction of requirements which will need to be addressed prior to any design/development is carried out.

o Review and refine requirements as the project matures.

Project requirements should be prioritised to reducing the scope of activities where time is a significant constraint. This is especially the case for delivering technical test events where timescales are immovable. Prioritising requirements focuses planning activities. It also ensures that the overall delivery is not compromised in the event of delays.

More technically, it is also about progressing in an agile way, by retroaction loops on the specs and deployment:

o To allow the pilot management team to procure equipment, appropriate sites and organise timely and regular validation, monitoring and



maintenance of the installed systems.

o The iteration method is a way to update the first studies, then to reread the changes made, before gradually reaching the finished product. This allows for example to work for each site on technical fact sheets including specifications and technical constraints, in order to adapt the needs to the actual context of implementation.

o Presentation and evaluation meetings with each manager (road networks, communications, energy) allow enriching technical file by taking into account particularities resulting from the testing and operation of equipment, to validate them or to opt for an alternative solution if necessary.

3.3.1 Communication options/considerations

During the requirements gathering step it is also important to consider which communication technologies you wish to deploy in the pilot as this largely determines the requirements off the next steps. Consider a cellular (network-based) communication versus a direct (localised) communication (like ITS-G5) or a combination of both which is often denoted as “hybrid”. The communication technology choice influences several crucial characteristics of the deployed C-ITS eco-system so bear in mind the following:

The market has not yet made a clear choice in technology.

The expected impact of delivering (critical) C-ITS messages through different communication technologies, including aspects like; assurance of message and “user experience” consistency

Service dependency to communication services operated by private services providers.

Private service providers are critical in case of service delivery over mobile cellular telecom. However, they do not (yet) clearly see or understand the business model for providing Traffic Management Information to the end-user.

Hybrid solutions enhance scalability and extend geographical availability of services for end-users

Currently there is not yet an agreed definition of hybrid communication which can be used as reference.

Avoid format conversions or translations between different communication technologies in order to avoid message inconsistencies.

The security framework that works out well for short range cannot (yet) be extended to the cellular chain at the front-end level.

International interoperability, the requirements for interoperability of the services (at the front-end level) are completely different between technologies. Message exchange for the short range chain have been standardised completely; the service-delivery chain of the mobile Service Providers are not (completely) standardised at this stage.

3.4 System concept

A recognized best practice for a Pilot setup is to approach it as the development of a system which will be used to achieve the Pilot aims and objectives. During an early system concept phase, all the necessary components and characteristics of the Pilot are identified and



described from the point of view of the “user”, including how the system is intended to be used and also external conditions expected to influence the use of system.

These aspects are usually gathered in standard documentation such as an “Operational Concept Description (OCD)” and/or “Concept of Operations (ConOps)” document. The OCD or ConOps are strategic documents that define what needs to be built and how it will be used. This is a live document that should be reviewed and revised as the project matures. It may also include operational scenarios and show the interaction between people, processes and technology. These documents build on the stakeholder requirements gathering stage and helps to inform the preliminary/concept design, including initial ideas on different architectural choices, or and communication technology type considerations and available regulations and standards.

Best practices from InterCor:

Develop a strategy for international cooperation at all organisational levels: political, functional and technical.

Define the relationship, commitments and and/or interaction between the pilot and European and neighbouring countries programs and initiatives, as for example the relationship developed between InterCor, C-Roads program and further European Commission C-ITS related activities.

Align pilot scope, needs or requirements with current national initiatives and international, example of the European network of National Access Points and the European Commission C-ITS Security Policy.

Develop and establish, as early as possible, with the pilot (international) parties a clear view on the pilot overall goals, objectives and approach, including the expected effort and commitment from all organisations.

Be aware that often pragmatic technical choices are influenced by stakeholders' political and organisational context.

Evaluation related requirements and other organisational driven specific needs like security, privacy, storage, need to be considered at the early stage of the pilot.

Balance the expected or intended innovation level of the pilot with the innovation roadmaps and capabilities of the organisations implementing it.

Develop a risk management plan for both development and operational phases.

For the definition of the services and use cases to be piloted it is strongly advised to refer and make use to C-ITS Services and use cases descriptions from the C-Roads platform.

Consider re-using experience from previous (European/interoperable) tests and pilots.

Take into consideration to define and “build up” the Pilot functionalities based in already existing components, either previously deployed C-ITS infrastructure or market available through suppliers.

Consider limiting the pilot to the necessary aspects. It is better to have a small pilot (limited services and/or geographical scope) and an extensive evaluation (to learn more), than to have a big pilot and a small evaluation (limited lessons to be learnt).

Take into consideration the need to identify and define components and scenarios (or use cases) in an early project phase (e.g. service and use case descriptions in InterCor M6).



For full hybrid pilots consider the adoption of similar parallel cellular and ITS G5 architecture in order to be able to implement one single ITS station including both technologies.

Consider making the relationship between pilot objectives and policy objectives explicit at the start of the project. An Implicit relationship can result in evolving and often increasing requirements imposed on the pilot. E.g. the piloted GLOSA service in the Netherlands was also designed to assess the potential to bring Traffic Management Information into the vehicle through a public-private value chain.



4 Pilot deployment

4.1 Overview

Chapter 4 focusses on the project management activities that need to be considered when deploying a pilot. It also includes the approaches adopted by the InterCor Member States. The possible approaches are related to the existing conditions in each Member State. Therefore, this section starts with these brief descriptions.

Conditions in the Netherlands

The sensor and actuator network of high density in the Netherlands allows a variety of tests and pilots. Also, the Dutch road authorities are willing to support new, innovative services of which the impact and added value is not yet known. For example, in October 2018 the Dutch minister of Infrastructure and Water Management wrote a letter to the ‘Tweede Kamer’ (House of Representatives of the Dutch Parliament) in which she mentions that she will support experiments to learn about the added value of new technologies to traffic and safety. This statement is supported by the Dutch ‘Experimenteerwet zelfrijdende auto’ (law governing the experimental use of self-driving vehicles) which even allows experiments with self-driving vehicles on public roads. These conditions have resulted in many pilot activities on public roads as well as in cooperation and/or development platforms. The pilot activities in the Netherlands for example, build on work already carried out in the Cooperative ITS Corridor and other (national) activities such as Talking Traffic. Over the years lots of knowledge was gained, resulting in (international) system specifications updates.

Conditions in France

In France, InterCor follows the project Scoop@F [6], [7] which allowed deploying since 2016 cooperative systems based on the exchange of information between connected vehicles and the road infrastructure. The InterCor pilot aims to extend the existing spatial coverage on the North Sea-Mediterranean Corridor and to develop new use cases related to safety and freight.

The project brings together many public and private partners (road managers, providers, research centres) under the coordination of the French Ministry of Transport, with the general objectives of improving traffic and road safety and reducing management costs and nuisances (pollution, traffic jams, noise).

The challenges subtended by InterCor in France are to promote cooperative systems for sustainable mobility and to ensure the homogenization of services in the context of C-ITS projects in Europe via standardized interoperable systems.

Conditions in Belgium

InterCor was one of the first C-ITS deployment projects in Flanders and made it possible to find affiliation with ongoing C-ITS initiatives in the neighbouring countries. Since then, Flanders has been participating in other C-ITS related projects, like C-ROADS, CITRUS and Concorda and the most recently launched “Mobilidata” program. With the latter, Flanders commits to a large-scale deployment of C-ITS services based on a full commercial C-ITS ecosystem.

These ongoing projects and future commitments fit in the transition to a sustainable, safe, intelligent and multimodal mobility which is envisioned in Flanders’ long term 2050 vision and was agreed by the Flemish government in March 2016. To meet the specific needs for a clear and facilitating regulatory framework for these new technologies and innovations to be developed, temporary legislation under the name “experimentwetgeving en regelluwezones” was introduced.



Conditions in the United Kingdom

The A2M2 Connected Corridor Project is a flagship C-ITS pilot project within the UK transport industry. The project, which was established by the UK Department for Transport (DfT) and is also being led by them, is delivering a connected corridor of approximately 100km in length between Greenwich in London and Dover, Kent. The project, which is co-funded by the European Commission through the InterCor project, is being implemented in partnership with Transport for London (TfL), Highways England (HE) and Kent County Council (KCC).

The resultant C-ITS Corridor is one of two TEN-T Corridors linking London to the rest of Europe, and it includes sections of TfL’s road network within the Greater London boundary (A2 and A102) and HE’s (M2) and Kent County Council’s (A229) road networks in Kent.

The Corridor comprises a variety of urban, fast inter-urban and rural roads that provide a challenging test environment for the development, testing and evaluation of C-ITS services and it forms part of the UK’s CAV ecosystem.

In addition to enabling the UK Partners to develop, test and evaluate the potential operational, safety and end-user benefits of new C-ITS services, this test bed will help them to deliver upon their UK Roads Investment Strategy (RIS) commitment and the commitment made to the EU through the InterCor Grant Agreement.

4.2 Possible approaches

4.2.1 “Learning by doing”

The learning by doing approach is an iterative approach to develop and test services. The starting point is the availability of a broad range of (international) standards, profiles, specifications, pilot sites, devices and equipment. To ensure interoperability, existing versions of specifications, profiles, services and systems are analysed and, where necessary, re-developed to interoperable profiles and specifications. After agreeing on interoperable profiles and specifications, pilot site testing is done. As maturity and pace of development (“learning”) will differ per technology and service, the pilot sites need to support continuous redevelopment and testing (“doing”) of services, technology and equipment. To support improvements, an iterative process of testing, validation, evaluation and analysis lies at the heart of the learning by doing approach. Learning by doing also implies that you carefully manage the interests of the previous work. The harmonisation that you envisage should improve what already works.

Figure 1: Iterative process of the learning by doing approach



The learning by doing deployment approach has been used by the Netherlands, as the conditions in the Netherlands foster experimenting on public roads.

4.2.2 “V-model”

The V-model is a system engineering methodology based on the waterfall approach that can be adopted for a wide range of tasks e.g. software development, deployment of systems or project management. The V-model is a linear process which requires activities to be carried out in a sequential manner. This is particularly effective for production of documents which often develop information that feeds into subsequent documents. An example of this is shown in the figure below. The Concept of Operations document feeds into the Requirements Capture and Architecture deliverables which in turn feeds into the design documents.

The V-model is structured in such a way that documents are increasing in complexity and detail as one transitions down the left side of the diagram. For the right-hand side of the diagram this principle is reversed so that the focus of testing and verification broadens as one moves up the right-hand side from initial unit testing to system validation and finally towards operations and maintenance of the whole system.

This model allows for the verification and validation of information, requirements and assumptions at the appropriate stage of the design, deployment and testing therefore problems are identified and resolved at the early stages rather than propagating to the final stages where issues often become more complex and costly to remedy.

Figure 2: Systems Engineering ‘V’ model for systems design and implementation

Whilst there are specific topic areas relating to pilot deployment that favour the V-model approach as described above, there are also areas within the project lifecycle, such as software development, that may implement other methodologies such as Agile, Kanban, Kaizen models etc. Planners and designers of pilots should consider the best methodology to use for each stage/activity of the deployment process and may find a hybrid approach offers the best overall solution based on business imperatives, efficiency, cost and adaptability to change.

4.2.3 "Agile"

The agile approach allows for a rapid development of the end service through short iterations, which are often called “sprints” as indicated in Figure 3. With each sprint launch demonstrations and workshops are planned to get immediate feedback on the current



version, the progress made and to assure that things are still moving in the right direction. Close monitoring provides the ability to dynamically change and reprioritise end service development if required, for example, when new versions of profiles and specifications are being released or unexpected costs and events occur.

The agile approach is especially applicable for software development and should therefore be considered for the C-ITS service development phase of the pilot deployment.

Agile works well with a small dedicated team and allows the team to balance workloads. Ultimately, the development team has the final say in determining how much work can realistically be accomplished during each sprint. Furthermore, receiving feedback with each sprint launch allows the team to adjust to changing needs and in the end develop at a much faster pace. During each sprint, it is not uncommon for the development team to hold daily stand up meetings to discuss progress and brainstorm solutions to challenges.

.

Figure 3: The agile approach features several sprints during the development period

4.3 Project deliverables

To provide the reader with an overview of the broad range of areas that may need to be considered and addressed prior to and during the deployment of a C-ITS corridor, a pilot Deployment – Deliverables Matrix has been provided in Appendix A.

A best practice approach would be to identify and define those example deliverables that are relevant to a particular pilot, so that the scope, programme and cost/effort estimate are understood from the outset.

The deliverables defined in the Deliverables Matrix focus specifically on aspects of pilot

design, deployment and evaluation and excludes project management/ governance which, as shown in the Deliverables Matrix, spans across all of the Work Packages. To aid clarity, the deliverables are grouped into six Work Packages (WP) as described below. A detailed description of each deliverable and its dependencies and outputs is contained in Appendix B of this report.

4.3.1 Work Package 1 – Infrastructure and Systems Design

The set of deliverables under WP 1 relate to the design process for the systems and infrastructure to be deployed for the pilot. These deliverables are typically produced in a sequential manner.

4.3.2 Work Package 2 – Safety Governance

Naturally, safety is an intrinsic part of pilot design and deployment and needs to be considered at each stage of delivery. The Safety Governance WP contains a typical set of safety documents including a Safety Plan, Plan for Monitoring Operations, Safety Log and others. Safety Governance documents will be referred to and updated throughout the deployment and operations of the pilot as lessons are learnt that can be fed back into the governance process.



Safety Governance documents are usually required to be approved by safety officials/senior members of the project team prior to commencing any off-road/on-road trials using the testbed and therefore need to be produced prior to deployment and operations of the pilot.

4.3.3 Work Package 3 – Pilot Implementation/Deployment

WP3 contains a set of strategic documents (addressing the questions what, why and who) as well as tactical documents (addressing the questions how, where and when).

The documents in this Work Package often link to those in WP1 as the strategic document influences the design of systems and software for the pilot.

WP3 also contains planning documents such as the Implementation and Management Plan and Deployment Schedule as well as testing, commissioning and post-deployment maintenance documents which are part of the Handover and Commissioning Pack.

4.3.4 Work Package 4 –Pilot Operations and Maintenance

This WP contains those deliverables that are associated with the operations, maintenance and general day-to-day running of the pilot. These documents are based on those produced for WP3 in terms of the operating procedures and help to inform the evaluation related documents in WP5.

The installation of in-vehicle equipment and the training of drivers taking part in the pilot are covered by WP4. Similarly, if there is provision for third party organisations to use the testbed then any processes and application forms for this purpose would be contained in WP4.

4.3.5 Work Package 5 – Evaluation

This WP contains all of the deliverables relating to the evaluation of the pilot usually conducted through a series of trials, investigations and studies involving vehicles. This is different to the testing of the equipment itself, which is covered in WP3.

The comprehensive set of documents relating to evaluation cover all aspects from evaluation planning to feedback questionnaires, results analysis and finally recommendations that could be developed into a business case for further development of the pilot.

The evaluation deliverables are also key elements for providing evidence that the vision, aims and objectives of the pilot have been satisfied.

4.3.6 Work Package 6 – Stakeholder Engagement

WP6 focuses on the communications with, and management of stakeholders (both internal and external to the project). C-ITS pilots are typically multi-disciplinary projects involving people from several organisations providing a range of specialisms. To support this, a set of stakeholder focussed deliverables are recommended. During the pilot these documents will be referred to and updated accordingly as the people/organisations involved change. An important deliverable within this Work Package is the Lessons Learnt Log which collates all of the issues and suggestions for improvement during the pilot to help inform best practice for future pilot deployments.

Given the challenges of bringing together all the partners and services concerned, it is advisable to propose common tools (monitoring tables, site sheets, technical documents, reports and other project deliverables) that are accessible and easy to use by all partners.

4.4 Procurement strategy

In InterCor three deployment aspects that have been considered are procurement strategy, deployment timeline and acceptance test strategy. In this chapter InterCor considerations will be provided regarding the procurement strategy.

Consider the opportunity for cost and time efficiency in pilot deployment by identifying and engaging with ongoing initiatives with similar or overlapping piloting scope, while at the same taking into consideration potential constraints and restrictions that might imposed by those programs to own pilot needs and choices.



Consider to check whether existing contracts can be used to avoid a cumbersome procurement procedure

Consider including Market Engagement Days (MED) with potential suppliers/ the supply chain within the procurement strategy, where specialist technical services or systems are to be procured. Holding MEDs prior to the formal issuing of Invitations To Tender (ITT) can help to ensure that a range of potential specialist suppliers, with the necessary skills and capabilities, is aware of the forthcoming procurement, and that they submit quality bids. Engagement days can also be a useful networking event for prospective suppliers where the scope of the services that are to be delivered means that they will need to be delivered by a consortium.

Consider identifying (European) market needs (e.g. by organising a 'market consultation') to make sure these needs fit in the procurement strategy.

Consider whether competitive tender or direct award of contracts is appropriate. Competitive tender being the preferred best-practice method in general. However, where minor works are required (i.e. for small scale IT provision, venue facilities and ancillary equipment), use direct award and non-competitive procurement instruments when allowed by procurement legislation. This will help to ensure that the supply of low cost but vital services/products is not time intensive and does not distract from other activities.

Consider tendering the different project elements (pilot execution, evaluation, etc.) separately.

Consider for consistency, cost efficiency and to aid the continuity of services across networks, a single procurement of services and/or systems for all authorities, if the testbed/pilot is to be implemented on more than one highway/road authority's network. This is preferable to each authority undertaking its own separate procurement.

Consider procurement of specialist technical expertise to supplement in house knowledge, where there are knowledge gaps.

Consider whether to wait for (relatively) stable specifications before procurement, to avoid extra costs.

Be aware of potential vendor lock-in situations, especially when pilots include specifications and standards development activities.

Consider to incorporate sufficient time for procurement of systems or services, particularly if the OJEU applies. Due to the nature of C-ITS: technologies, standards and specifications will keep on evolving during the life cycle of the systems. Therefore consider allowing specification changes during pilot deployment and operations.

4.5 Deployment timeline

The second deployment aspect to be considered is the deployment timeline. When considering a deployment timeline, a number of aspects should be taken into account. In this chapter InterCor considerations will be provided regarding the deployment timeline.

Consider separate deployment timelines for roadside equipment and systems, if they are not critical to one another.

Consider including all stages of design, development, deployment, testing and evaluation in the timeline.

Consider incorporating flexibility for different design methodologies including the 'V'



model and agile methods.

Take into consideration to schedule regular follow-up meetings with the project team and contractor to guard the timeline.

Consider the requirement for sign-offs after each stage before progressing onto the next stage. (Gateway).

Consider involving parties not directly involved in the initial planning as it might be helpful in bringing new perspectives and offering unbiased viewpoints.

Consider scheduling regular follow-up meetings on a strategic level with the project team and contractor to guard the timeline and deliverables.

Consider including (pre) demonstrators and tests in the planning both in lab environment and in “real life” conditions, including planned and unplanned traffic operations /conditions, in order to test all situations/scenarios in a controlled manner.

4.6 Acceptance test strategy considerations

The third deployment aspect to be considered is the acceptance test strategy. When considering an acceptance test strategy, a number of aspects should be taken into account. In this chapter InterCor considerations will be provided regarding the acceptance test strategy.

Consider incorporating practice sessions or “Dry-run” events immediately prior to commencing the evaluation of services, that confirm that equipment and systems are functioning correctly prior to evaluation. The following systems: Factory Acceptance Testing (FAT) and Site Acceptance Testing (SAT).

Consider early development of a pilot test plan including a step-by-step / (bottom up) test methodology starting with test technical aspects, and grow to system integration and functional aspects: FAT-iFAT-SAT-iSAT.

Consider developing a testing environment parallel to the pilot operational system in order to be able to test, reproduce and compare systems operation both in lab and on-site conditions.

Consider establishing an operational “troubleshooting” team supporting the test facilities users.

Consider performing RSU and OBU validation by an independent party for an objective and independent validation.

It is essential that, in order to validate RSUs, to have (independent) OBUs that allow the validation of the whole chain.

4.7 Safety governance

This section describes the procedures and documents that are considered best practice for covering all aspects of safety and which need to be considered when deploying a Pilot scheme.

Establish safety governance and procedures that align with the highway/ road authority's existing arrangements – do not re-invent them for the pilot.

Where services are to be piloted on more than one highway authority's network, it is recommended that the highest safety governance requirements of the partner organisations should be adopted.



Processes and procedures governing the safe access and monitoring of all testing environments must be in accordance with the requirements of the safety governance authorities within the highway authority. Involving appropriate authorities in operational planning ensures that safety impacts can be clearly identified and the correct operations can be introduced and validated

Safety governance should be integrated within the agile development methodology of key project deliverables i.e. HMI, in order to support and not become a blocker to efficient system development.

Road authorities/organisations that provide drivers for on-road trials may wish to adopt their own established Standard Operating Procedures (SOPs) governing the safety and security of their employees. These SOPs are typically part of a Safety Management System and would include safety risks assessments, driver training requirements and instructions on what to do in the event of an emergency.

For safety reasons consider having a co-driver for testing, so that the driver can focus on driving.

Consider opportunities to use envelopes / tolerances of risk to work within (in support of working within agile development). Outline what will have the greatest impact on safety and define their envelope / tolerance (i.e. project safety can be controlled to stay within agreed tolerances.

Examples of safety-related documents that may be produced as part of the safety governance:

o Plan for Monitoring Operations (PfMO); o Safety Plan; o Hazard Log; o Driver Distraction Safety Principles Report

The purpose of these four key documents is to describe the safety governance methodology and procedures to enable the Hazard Assessment process to be undertaken.

4.8 Risk management plan

Once the Pilot has entered the Operations stage, the procedures and operational governance models that have been developed in the design and implementation stages are put into practice. Various operational documents may support the management of pilot operations including the Concept of Operations (ConOps), Implementation and Management Plan (IMP), Plan for Monitoring Operations (PfMO) and Combined Hazard and Safety Log.

Best practices considerations:

Consider establishing appropriate operational governance for the pilot, to enable it to be managed efficiently, effectively and safely. Where multiple stakeholders will be involved in the pilot, this may include the establishment of a regular (e.g. monthly) Steering Committee that is attended by stakeholders, which will guide the pilot, ensuring that stakeholder requirements are incorporated, where appropriate, and that the pilot delivers the desired outcomes and return on investment for all participants.

Operational governance of technical test events must not be overly complicated. Overly complicated procedures for participation will increase the likelihood of mistakes being made that impact the quality of test scenarios or even lead to safety



events.

It is recommended that operational procedures during pilot operations are formalised and documented within core documents such as the ConOps, IMP and PfMO. This is particularly important when describing operational and safety procedures that are to be observed. Documentation should also identify and outline key roles and responsibilities of personnel involved in the pilot.

It is recommended that a risk management plan is developed for the pilot that not only states what the risks are, but the process for identifying new ones and for managing risks status and mitigation measures throughout the Pilot. This should also consider procedures that are required if risks become issues, including escalation points and paths. The Risk Management Plan also considers how risks will be identified, recorded and managed throughout the pilot.

4.9 Stakeholder engagement

It is important to identify and engage stakeholder during all different stages of your pilot preparation and deployment. Following aspects need to be kept in mind:

Consider approaching all stakeholders as early as possible to prevent unexpected risks (e.g. to make sure all components work properly at the start of the pilot).

Consider involving end users in an early development stage to understand better end user needs.

TESTFESTs are the perfect occasions to invite stakeholders for a live demo and increase their involvement.

During the planning stages it should be encouraged to include stakeholders with different viewpoints and specialisms (i.e. operational and technical). This is equally applicable to stakeholders within partner organisations that have different specialisms or operational roles; as different perspectives will help identify and validate certain project aims and/or issues.

Scheduling regular opportunities for partner collaboration; particularly when there are major decisions to be made. Ensuring that there are regular opportunities for partners to inform major decisions is vital so that no one single viewpoint colours the end-product.

Communication is essential for reinforcing collaboration; thereby reducing the potential for silos to develop. It is therefore highly recommended to develop a Communications Action Plan.

4.9.1 Communications Action Plan

A well thought out communications action plan is necessary to ensure regular contact with stakeholders and reflect changes in operations/processes that are being executed during the pilot. The communications action plan should state, for each stakeholder, the method of communication to be applied, frequency of communication and level of detail that the communication needs to have. It is good practice to regularly revisit it during the project and revise when appropriate. Following guidelines apply:

Consider a clear, easy mechanism for notifying of changes by stakeholders.

Clearly stated roles and responsibilities (see for example table 5) are vital to ensure that all involved in the project are aware of their obligations to the project and the relationships they must maintain. This also allows relationships to be drawn between activities and encouraged better communications to enable issues to be more readily



resolved. These roles and responsibilities can be represented by a RACI matrix (see for example table 6).

Consider to revisit the roles and responsibilities of all stakeholders on occasion to check their validity, also regularly communicate (changes to) the roles and responsibilities to the project team.

During pilot operations and on-street testing, consider communication tools such as the WhatsApp groups, for the communication of live traffic info / service issues.

Table 1: Example of Key Operational Roles.

Role Responsibilities

Pilot Project Sponsor The Pilot Project Sponsor is a Partner/client-side role whom liaises with the Pilot Operations Coordinator about operational and business aspects of the pilot. Also acts as an escalation point within each Partner organisation for raising risks and issues.

Pilot Operations Coordinator The Pilot Operations Coordinator is a central role for the pilot to operate effectively. The Pilot Operations Coordinator liaises with all parties regarding trial operations and assesses concerns/risks/issues raised by Partners/stakeholders. The Pilot Operations Coordinator is also responsible for following up any matters at Board level to ensure a decision is reached and that this is communicated back down to the relevant teams.

Safety Coordinator The Safety Coordinator ensures all safety checks are completed and that the safety documentation is consistently followed by all Partners throughout the trial. The Safety Coordinator is experienced in dealing with safety related matters and will liaise with the necessary people within the Partners/stakeholders organisations.

Fleet Coordinator The Fleet Coordinator ensures driver and vehicle checks and training are completed prior to commencing the trials and coordinates responses to the Fleet with the Fleet Driver.

Fleet Driver The Fleet Driver drives the equipped vehicles during the pilot and raises any safety or security concerns with the Fleet Coordinator and/or Safety Coordinator.

Roadside Maintenance Coordinator The Roadside Maintenance Coordinator maintains and updates the on-board units and assesses any roadside incidents that involve infrastructure damage.

Roadside Maintenance Responder The Roadside Maintenance Responder undertakes equipment maintenance upgrades and reports any potential security breaches.

Traffic Control Centre The Traffic Control Centre identifies or is informed of any collisions or infrastructure damage, and notifies the Emergency Services and Traffic Control Media Team.

System Engineer

The System Engineer liaises with the Pilot Operations Coordinator about technical considerations affecting



systems and provides maintenance and upgrades on the back-office system.

Emergency Responder (Emergency services/Traffic Office Service)

The Emergency Responder responds to incidents reported by the Traffic Control Centre, member of the project team or a member of the public.

Table 2: Example RACI matrix

Role Responsible Accountable Consulted Informed

Pilot Project Sponsor

Pilot Operations Coordinator

Safety Coordinator

Fleet Coordinator

Fleet Driver

Roadside Maintenance Coordinator

Roadside Maintenance Responder

System Engineer

Traffic Control Centre

Emergency Responder



5 Site design and technical considerations

5.1 Overview

This chapter focusses on the site design phase and the equipment necessary for pilot operations.

5.2 Site design

When considering the site design, a number of aspects need to be taken into account on a macroscopic and microscopic level. In general, it is important to select a representative stretch of road for the project e.g. stretches with high traffic throughput, complex traffic situations and/or cross border traffic so lessons can be learned from real life traffic situations.

Looking into the specific site, the following geographical, technical, cost and policy considerations should be taken into account:

Road usage, operation and safety;

Traffic management and authorization;

Consider the existing CEN-DSRC tolling network, the presence of mobile units and mobile enforcement units.

Topography (mainly the slope and height difference of the trajectory)

Use cases of the C-ITS pilot;

Other (C-ITS) projects;

Coverage, availability and throughput of wireless and/or fibre communication networks. The transmission’s quality in each location has to be checked before validating the choice of the site. A radio survey is recommended to test the signal strength available from the various network service providers at the site locations;

Using the existing road operators data network can reduce costs and time to deploy the network infrastructure and helps to ensure that connectivity to back office systems is in place (along with the required SLA's to guarantee minimal levels of availability and resilience to meet operational needs).

Radio frequency and interference;

Existing equipment and road infrastructure, available cabinet space and adjacent networks;

Availability of power supply (mains or autonomous);

Accessibility of the site for testing and maintenance purposes (for instance select sites with maintenance access bays close by).

It is advisable to have site visits to asses all of the above aspects. For GLOSA sites there are some additional considerations to take into account:

When selecting sites for GLOSA C-ITS service deployment, consider to start with relatively simple sites, because demand dependency, banned movements, bus priority and phase delays can all cause issues for ideal GLOSA operation.

However, if the technical performance of the GLOSA C-ITS service is to be fully evaluated and its potential operational limitations is to be assessed, then consider sites that are in a variety of operational environments, e.g. open roads vs urban canyons where signal propagation and GPS performance may vary; isolated sites vs sites in close proximity to one another, congested urban areas where service



performance may be affected, etc.

Test GLOSA operations under a variety of control modes e.g. fixed timing, dynamic timing (SCOOT), bus priority, hurry call etc.

Intersection topology is a relatively new C-ITS element in the urban context that

requires ample time for its deployment, due to both necessary technical and

organisational aspects.

5.3 Communication equipment

Communication between all C-ITS pilot equipment and systems will be necessary in order to exchange messages and provide services. The InterCor communication solution is based on a hybrid communication approach, which is a combination of a cellular (network-based) communication and a direct (localised) communication.

The figure below shows a hybrid system architecture diagram. In this case the hybrid communication relies on a combination of ITS-G5 and cellular technologies. In the next paragraphs best practices are listed concerning the equipment for both these communication technologies.

Figure 4: Typical connected vehicle and roadside infrastructure.

5.3.1 ITS-G5

Transmission of ITS-G5 signals happens through local antennas, so called road side units (RSUs) which are mounted alongside the road and on-board units (OBUs) installed in the vehicle.

5.3.1.1 RSU considerations

Consider carrying out local telecommunications performance testing for ITS-G5 equipment rather than rely on manufacturer's published information about signal strength, signal-to-noise ratios etc. This improves the on-site design of telecommunications equipment and ensures that communications blackspots are identified and resolved earlier in the design process

Consider bench (off-road) testing using the same equipment that is deployed. This enables any incompatibilities between supplier's equipment to be identified early in the deploying stage. This helps to prevent issues during the actual pilot (on-road),



which are generally more problematic / costly to resolve when located next to a ‘live’ carriageway.

In the current initial market conditions, RSU suppliers are still very much dependent on capacity and availability of own suppliers for parts and components, so pilot planning needs to consider (current) delivery times of RSUs which can take up to several months, even if they are marketed as off-the-shelf.

Because RSUs are often mounted in a motorway environment, installation safety guidelines are important and pilot planning needs to take in account appropriate (operational) traffic management measures. Consider for example to carry out the installation at night with shock absorbing trucks (impact protection vehicles) or midpoint fold-down masts. These structures allow installers to work at ground level without the need for Mobile Elevated Working Platforms (MEWP). This also reduces the need to gain approval from overseeing organisations for mounting on existing structures.

Installation configurations depend on the possibilities of deployment in urban suburban or interurban environments, on existing support infrastructure or standalone solutions, on modes of power supply and data transmission. Some possible configurations are listed in Table 3:

RSUs should be installed according to the installation guidelines of the supplier, generally they need to be mounted at a height between 8m-10m, in order to allow a good coverage of the RSU and to protect against vandalism, but still accessible for operation and maintenance. For configurations on mast it will be preferable to use tilting or telescopic mast to facilitate the installation and maintenance. Midpoint tilts allows both installers and maintainers to work at ground level without the need for Mobile Elevated Working Platforms (MEWP). This also reduces the need to gain approval from overseeing organisations for mounting on existing structures.

The type of directional or omnidirectional antennas depends on the location:

o On a road in current section: directional antennas are more appropriate to cover long lengths

o At a junction: omnidirectional antennas allow the signals coming from the different axes to be received.

However, the following must be taken into account for antennas:

o Omnidirectional antennas: the diffusion of waves near houses and masks to the transmissions that can be created by the solid central ground (e.g. of a roundabout) and will likely need shorter spacing between them.

o Directional antennas have implementation and maintainability constraints because of a greater sensitivity.

It is preferable to place the RSU in a secure location e.g. near a parking location so maintainers can safely reach the RSU for maintenance or routine checks.

Before installation, it is necessary to make sure that RSU are separated as much as possible from other existing equipment, by isolating them electrically (circuit-breaker) and by computer (switch), to establish real service boundaries between maintenance contracts.

The relevant area for positioning a RSU is located upstream of sensitive areas (accidents, dangerous bends, pedestrian crossings, congestion, interchanges, tunnels, bridges, etc.), at the last intersection, considering field constraints and penetration rate of equipped vehicles that will increase.

In order to have maximum efficiency, the installation of an RSU should be carried out in a clear zone, without obstacles to the wave propagation e.g. vegetation.



The spacing between RSU depends on the level of service desired. For example, on sub/interurban network one can plan the RSU density according to different level zones: risk area (accidents, traffic jams), traffic management (interchanges, travel time), services of exploitation (logistics and multimodal sites).

In case of dynamic lane signalling, spacing of RSUs should be adapted to the spacing and update frequency of the gantries. An IVS service coverage which has gaps will cause vehicles to present outdated speed or lane status information.

It must be considered that tunnels can generate masks to transmissions and the geo location by GNSS does not work, this case requires "fixing" the RSU position. For short tunnels, it is recommended to favour RSU positioning at the input and/or output if possible.

Table 3: Possible RSU installation configurations

N° Configurations Support Power supply Transmission Roadway

1 on VMS gantry wired

transmission

on VMS gantry mains power supply*

optic fibre highway

2 on VMS gantry cellular

transmission

on VMS gantry mains power supply

cellular highway

3 on existing mast cellular

(requires a design calculation note)

existing candelabrum or camera’s pole

mains power supply

cellular urban and suburban

4 on mast to install near a point of

energy

mast to install

(near traffic or weather station,

etc.)

mains power supply

cellular interurban

(equipped secondary

roads)

*In the case of wired telecommunications, given the low power required to operate the device, the energy supply can be made by Ethernet: Power over Ethernet (PoE), via cables that electrically provide equipment while allowing transmission data.

5.3.1.2 OBU considerations

The current OBU market is not yet mature in terms of suppliers. Available choices for functionalities and specifications are still limited.

OBUs should be easy to fit and remove from any vehicle type. Fitment of equipment in vehicle must be non-invasive (requiring no permanent modifications to the vehicle) and should not affect the integrity of the vehicle e.g. seal.

When procuring equipment, ensure that sufficient equipment will be available during pre-testing, testing and evaluation of services.

Consider the procurement of OBUs that have a remote software upload and remote data logging download capability.

It is advisable to include a separate 'developer mode' in OBUs with which, if desired, more (technical) information can be displayed. For example, in a regular 'user mode' it will not be visible why a particular image is not shown (e.g. wrong direction or security reasons) or which specific channel (e.g. ITS-G5 or cellular) is used. This insight will often be desirable for analysis and debugging.



5.3.2 Cellular

For most Day-1, I2V use cases the existing long range cellular network is deemed to be sufficient. However, consider the following points;

Consider cellular coverage and bandwidth during busy periods and/or at key locations (e.g. peak times outside railway stations).

Some on board unit (OBU) devices have issues with roaming handover, when there is a change of cellular service provider. This can lead to manually resetting the OBU’s in order to re-establish connection to the cellular C-ITS service when crossing borders.

Consider the use of multi network SIM cards to maximise service availability.

5.3.3 Hybrid

If you choose a hybrid implementation, it will be necessary to develop a high level system description that supports interoperability between cellular and other (ITS-G5) communication solutions. Below the InterCor hybrid communication solution is explained as an example on how interoperability could be achieved.

InterCor developed a high-level system description that supports interoperability between hybrid communication solutions via information exchange between back-office systems of road authorities, data providers and service providers, called IF2. Figure 5 provides a simplified functional architectural view of the usage of IF2 in the high-level system description in which a vehicle from country one is visiting country two. This architecture is applicable to multiple countries, service providers and vehicles.

Figure 5: High level diagram for hybrid communication

The IF2 specifications in InterCor Milestone 4 [2] deliverable specify the technical details of the interface itself (not the complete system in which the interface will be implemented). The InterCor IF2 supports at least the information exchange for the services RWW, IVS, PVD and GLOSA. Note that IF2 has not yet been tested with other services and therefore it cannot be confirmed that the current specifications fully support other services.

The IF2 specifications leave it open how these specifications have to be implemented. Three different implementation models have been identified, which differ on how data is aggregated and distributed amongst countries:



1. Implementation model A is based on national nodes servicing national data only. Service providers can obtain data from the data of its country of origin;

2. Implementation model B is based on national nodes exchanging data. A single point of contact per country can aggregate all data from other countries and forward the data to its local service providers;

3. Implementation model C is based on a central EU node. A single central aggregation point can be established in which all data from countries is gathered and redistributed to service providers.

A more detailed description of these implementation models and the advantages and disadvantages can be found in the InterCor deliverable “Next steps for hybrid communication” [5].

The implementation models are not mutually exclusive, and it is possible to implement mixed forms. On the other hand, if multiple models are deployed and supported at the same time, it can become more complex to figure out where to obtain which information. Therefore, for the long term it is preferable to have a common approach for selecting one of the deployment models. As long as it is not clear what that common approach should be, support for multiple models and migration in a later stage seems to be the best approach for now.

5.4 Other systems and equipment

In this section we briefly touch upon HMI, central back office unit and data access considerations.

5.4.1 HMI considerations

On the Human Machine Interface (HMI), drivers can ultimately receive C-ITS messages. A well-designed HMI is therefore essential for enhancing drivers’ experience:

The HMI functionality and its configuration, has a very dominant role in the perception of the quality of service delivered. Therefore, clear specifications are needed, to facilitate the expected delivery of public traffic management services in a controlled and responsible manner. The in-vehicle equipment should follow best practice relating to HMI design, placement and driver distraction.

Related to the HMI / OBU choice is also the need for establishing a cooperation between public (road operators) and private service providers (automotive and navigation), to define the conditions for interaction and coordination of public and private service and answer the question: to what extent can a public (road operator) influence the service that is delivered through a (private) HMI/OBU?

Consider a HMI design which does not require manual input from the driver which can distract them from driving actions. Therefore, develop minimal driver distraction principles to provide as an overarching framework to guide HMI requirements capture/ system development and use as a validation tool to approve the HMI.

The HMI must be fit to be used in specific testing environments i.e. different requirements apply when testing during a TESTFEST (with co-driver available) and pilot operations (with no co-driver available).

It is advisable that the HMI has clear signal strength indicators and a heartbeat showing connection to the OBU (if applicable).

Consider developing a HMI design with input from end users and involve ergonomist.

Consider a HMI (prototype) taking into account, as much as possible, (already) known future releases of HMIs.



5.4.2 Central Unit and data access considerations

A lot of data will be flowing through the central back office system. The main considerations for the back-office system and data access are listed below:

Consider using a system integrator approach for delivery of all components (RSU, CU) which can be advantageous for effective risk management purposes, however be aware of vendor lock-in risks (lack of CU-RSU open communication standard) and the fact that “nothing is so permanent as a temporarily solution”.

Consider keeping current central systems operating parallel to C-ITS central unit and only engage in integration activities with current operations after a stable C-ITS central unit system to keep current systems and operations integrity.

Consider the political (international) dimension of traffic data access (often considered open data) and the relation with the international developments and constraints: how is (open) data access organised in each country?

Consider data storage in secure cloud-based repositories (data lakes) for ease of data upload/download particularly when multiple parties are accessing and submitting data to/from the data lake ensuring free access to the server and data ownership. Actually, it must be taken into account that cloud-based systems have the disadvantage of involving a third party cloud operator and the road manager may lose control of the data.

Be aware that it can take a long time to get users access to systems (authentication/certificates etc.).

In the case of automatic data logging uploads (via cellular) e.g. to a data lake it needs to be ascertained that there is no degradation in service as a result of the additional uploads.

5.5 Security and privacy aspects

This section covers the security and privacy aspects of the end-to-end system from in-vehicle systems to the back-office servers and the communication network in between. Due to the transient nature of communication between vehicles passing by roadside devices, a high-speed certification technology is required to authenticate in-vehicle systems to prevent connection to roadside devices by unauthorised and/or malicious users.

Data privacy is also a key consideration in deploying Pilots to ensure confidential information about vehicles and drivers is kept secure. In the UK a data policy (known as GDPR) contains directives for ensuring data is handled securely and is an example of a best practice approach.

5.5.1 Security

Following are ‘best practice’ considerations in relation to security:

It is good practice to use a certificate issuing authority (CA) for the provision of digital certificates. If one does not already exist, then consider establishing one for the pilot. Using a CA as part of a Public Key Infrastructure (PKI) help to ensure people are not trying to masquerade as an authorised user by issuing their own fake certificates for malicious purposes. This is particularly relevant where external parties are to be allowed to participate in the pilot.

Where, as part of the pilot, testing is to be undertaken on more than one highway authority's network or cross-border, consider having a single Certificate Authority /



Trust List for pilot. This will minimise potential compatibility issues when implementing C-ITS services against immature PKI standards.

Where there are multiple organisations involved in the pilot (e.g. several highway authorities), consider establishing a security working group as early as possible, and establish security standards that all parties agree to comply with.

There are several security procedures that need to be adhered to by all Partners to ensure access to the test bed is granted and the C-ITS system remains secure.

Documents to be considered for this section are:

o high-level security architecture;

o baseline security specification;

o data requirements.

Communication channels should use encryption algorithms, particularly in cases where wireless protocols are used for transmitting data between vehicles (V2V) and between infrastructure and vehicles (I2V).

Current tests showed that implementation of PKI services within currently available systems will reduce their performance considerably due to processing power constraints. Systems need to be specified with appropriate levels of processing power and be scalable to accommodate the latest security technologies.

Please be aware to use the appropriate security ETSI standard, for example ETSI TS103 097. "Security header and certificate profile" V1.2.1 is not compatible with the EU required V1.3.1.

According to the Delegate Act approved on 13 March 2019, a PKI must be used. This applies also for cellular communications.

OBU security: Enable logs to be easily accessible or copied off without exposing the rest of the OBU's Operating System.

Where new C-ITS services interface with existing live operational systems, consider seeking third party assurance (e.g. penetration testing) to minimise additional security risks to the existing system.

5.5.1.1 Example of a Member State Security Policy

Implement a security policy that complies with national and international best practice guidelines e.g. as defined at https://www.gov.uk/government/publications/security-policy-framework).

Adopt security best practices based on EU published guidelines that considers the following:

o Boundary firewalls and internet gateways - these are devices designed to prevent unauthorised access to or from private networks, but good setup of these devices either in hardware or software form is important for them to be fully effective.

o Secure configuration – ensuring that systems are configured in the most secure way for the needs of the organisation

o Access control – Ensuring only those who should have access to systems to have access and at the appropriate level.

o Malware protection – ensuring that virus and malware protection is installed and

https://www.gov.uk/government/publications/security-policy-framework



is it up to date

o Patch management – ensuring the latest supported version of applications is used and all the necessary patches supplied by the vendor been applied.

5.5.2 Privacy

Compliance with General Data Protection Regulations (GDPR) is an important consideration when operating and managing the testbed so that personal data is gathered, stored and used correctly. Since the pilot will be gathering data on the vehicle driver’s details, vehicle and location this data must be stored and handled sensitively to comply with GDPR.

The careful management of personal data was crucial to safeguarding the privacy of participants involved in the InterCor pilot. GDPR were followed during the evaluation stage when third parties were involved. For instance, test fleet vehicle driver information was anonymised, and drivers were made aware of the information collected about their vehicles/locations, and agreed to this and the potential use and storage of personal data in accordance with GDPR regulations.

Some key ‘best practice’ considerations:

When developing C-ITS systems, consider “Privacy by design” as an approach to fulfil the requirements of the current European regulation framework (GDPR)

Please consider that within the current C-ITS European context, specifically concerning ETSI and GDPR, it is at this moment unclear if privacy is sufficiently guaranteed based on GDPR and if not, who is responsible for additional corrective measures.

When collecting location data from test drivers, ensure that there is a data processing agreement in place.

Drivers should remain anonymous, wherever possible, e.g. when testing/ evaluating C-ITS services, it should not be possible to attribute driver X to vehicle Y. Where personal data is to be used and stored as part of the pilot evaluation process, drivers may need to sign a disclaimer that permits their personal information to be used.

It is highly recommended to remove all personal information at RSU/National Node level.



6 Pilot operation and maintenance

6.1 Overview

In this section we review general recommendations about the pilot operations and maintenance: pilot governance, user support, operational procedures, provisioning and driver training. Best practices from InterCor:

There will be a requirement for a technology maintenance plan (e.g. RSU/OBU) and a plan for roadside structures that clearly defines operational processes/scenarios.

o The maintenance plan defines who needs to be contacted when a fault arises and for process for undertaking planned/unplanned maintenance activities.

Apart from the operations that can be easily shared (for example, the repair and refurbishment of supports: masts or gantries), it is better to establish service limits between maintenance contracts, in order to allow a follow-up adapted according to the devices and the projects concerning the same site.

Maintenance plans should align with existing maintenance best practice and procedures that exist within the host highway authority. Particular attention must be paid to regulations and procedures to ensure the safety of operators and users during maintenance work.

It is also good practice to define and agree a Service Level Agreement (SLA) with equipment suppliers as part of a supply and maintain contract to help ensure quality and efficiency expectations of the customer/client are met.

6.2 Pilot governance

This can include the governance structure, change management, Terms of Reference / Project Board / Working Group structure (Governance Structure diagram e.g.)

In terms of pilot governance, it is essential to ensure continuous and transversal monitoring by different coordinators for the main stages of the pilot project: specifications, deployment and validation.

The governance structure depends on the organisation set up by each member country, its mobility policy and its innovation strategy.

However, roles and responsibilities need to be identified and outlined through clearly defined governance plans that also show lines of communication and escalation.

This should be described in governance documents, e.g. Pilot Terms of Reference, and may include the roles and responsibilities of technical working groups, focus groups and the overall management structure for the pilot.

6.3 Pilot site user support procedures

This section concerns the description of user related pre-pilot activities: webinars, pilot site user’s engagement, plans of action, etc.

To ensure proper data collection and information dissemination, one could consider creating a common mailbox that serves as a first point of contact/support.

Note: when there are only a limited number of users, this is quite manageable and so no separate procedures are needed.



In parallel it is necessary to consider the provision of a service help desk during pilot operations as a key contact point for the reporting and escalation of issues during pilot operations.

To facilitate the technical monitoring of operations, it is necessary to ensure that there are clear, defined line of escalation / fault reporting, and that key roles and responsibilities have been identified and outlined.

Technical support staff should be clearly identifiable to participants and other operational staff to save time and prevent confusion when technical issues occurred or simply to facilitate technical discussions.

Procedures for data collection should be included as part of driver training, that will cover trouble shooting for equipment and who to contact and when for scenarios and issues.

6.4 Pilot operations scenarios and procedures

Operational procedures are handy in both foreseen (business as usual) and unforeseen circumstances like unplanned maintenance interventions or other issues that can be encountered during the pilot. The operational scenarios define a non-exhaustive set of events that may occur during pilot operations.

When defining scenarios of events that could happen during the pilot (for instance accidents, incidents or congestion) the use of 'swim lane' diagrams to clearly show the interactions and passing of information between roles may be beneficial.

Video demonstrations and GPS mapping can also be used to supplement test scenarios descriptions at scenario briefing sessions.

The management and operation of the pilot according to the defined operational scenarios, requires the adoption of procedures and processes relating to the safety governance, infrastructure deployment and evaluation activities.

The processes include (but are not limited to) such topics as incident management, security procedures, commissioning/ decommissioning process, maintenance arrangements as well as health & safety considerations.

The procedures include the specific roles, trigger points and communication/decisions needed to safely “resolve” the event and return to a business-as-usual state. Flow diagrams make it possible to follow the adapted procedures.

Consider to produce a checklist for each operational scenario to help ensure that each step of the flow diagram has been completed and nothing has been overlooked, as part of the procedure for dealing with a particular scenario.

For instance, for the InterCor project the UK identified several operational scenarios categorised into three distinct groups to generate 10 procedures (P1-P10), that will be followed during pilot operations i.e.:

Business as usual (Normal operations);

Incident;

Maintenance. Table 4: Example of Operational procedures that map to Operational Scenarios

Business as usual (Normal Operations)

P1 OS1: Normal operations during live on-road trials

P2 OS2: Pre on-road trial vehicle and driver checks

P3 OS3: Process for allowing third-parties to use the connected



corridor

Incident

P4 OS4 & OS5: Reports of a serious or fatal collision potentially involving one or more fleet vehicles during on-road trial or involving pilot roadside infrastructure

P5 OS6: Item(s) of pilot roadside infrastructure falls onto carriageway

P6 OS7: Adverse weather occurs with the extent of the pilot during live on-road trials

P7 OS8: Safety Coordinator is made aware of a safety concern affecting the pilot

P8 OS9: A fleet driver receives a notification of intended prosecution during live on-road trials

Maintenance

P9 OS10, OS11, OS12: System and Equipment faults and security breaches

P10 OS13 & OS14: Maintenance upgrade to roadside unit, on-board unit or back-office System

6.5 Vehicle fleet provision and driver training

Below follow some indications concerning the vehicle fleet also the driver training criteria and pre-drive assessment process Best practices:

As part of the fleet provision, consideration should be given to the following:

Vehicle types (e.g. consistent fleet) and Vehicle Insurance: Consider test fleet requirements e.g. the early identification of the number of vehicles/ drivers and the types of vehicle that will be required, and ensure that there is adequate vehicle insurance to cover the scope of testing.

Driver and vehicle booking: Also consider the early identification of fleet source and engage with fleet operators early on, to get buy in.

Technology installed to vehicles: Consider logistics and installation requirements for technology that is to be installed in vehicles.

Vehicle checks / safety assessments: This should include completion of a Risk Assessment Method Statements (RAMS) for the pilot. The RAMS should consider participants with different driving capabilities and experience, and the potential impact of this on safety. Ensuring that participants observe the correct behaviours and are aware of safety procedures through adequate training, ensures that this impact can be suitably managed.

Driver suitability:

Engage with fleet providers to develop driver training. It is recommended that driver training includes safety, operations and risk awareness, as well as trouble shooting for equipment and who to contact and when for scenarios and issues. The use of video demonstrations and GPS mapping helps to familiarise participants with test locations so that time is not wasted getting lost.

Record the people having taken part in a training and ensure that they sign a GDPR contract and declaration to confirm driver checks and training has been undertaken and will be followed by drivers during the pilot.

Terms and conditions for participation must be accepted by participants and enforced by the operator of the pilot.

It is better at first to recruit drivers to the professional network by:



o looking for volunteers within your organisation/company; o approaching colleagues that regularly have to patrol on the road, as part of

their job to participate in the pilot. The following are examples of element to considers for a driver training:

Required driver details and sign in procedures;

Vehicle and driver safety assessments;

Driver briefings and information packs e.g. Completion of Questionnaires, Operational Scenarios familiarisation, what to do in the event of a breakdown or collision.

Agreed driving routes;

Data collection using the OBU;

Installation and setup of OBU/HMI (to be provided by equipment supplier);

Also, drivers should be aware and trained what to do if there is a fault with the HMI and/or vehicle during the trials (failure mode) e.g. if a fault occurs does the driver interact or pull over at earliest opportunity and turn off?

Familiarize drivers with the Golden Rule (below) and the Driver Distraction Principles (e.g. Driver Readiness Checklist in table below):“The driver treats the information provided by the system as advisory only and continues to drive in accordance with the current roadside signs/signals and road rules”

Table 5: Example Driver Readiness Checklist

Item Description Checked

when complete

Being an approved driver

Internal process for each Partner and will vary based on their requirements.

Process for taking a pool car out.

Checking the vehicle (e.g. checking the OBU, HMI and Antenna/Aerial fixtures);

Baseline User Acceptance Questionnaire

For Evaluation to see if there is a step change once they have experience and knowledge of the technology.

Training

Provision of training for Partner operational staff (including provision of materials for future reference), covering (but not limited to): o Installation of OBUs and HMIs. o The data extraction process (as required). o Troubleshooting and service support

processes. o HMI functionality.

Safety Processes and Scenario processes (i.e. what to do in the event of…)

User Acceptance Evaluation and Interviews

As part of the trial evaluation, drivers will be periodically interviewed and required to complete questionnaires to elicit feedback.

6.6 Third party access to the pilot testbed

If it is anticipated that third party organisations, such as automotive manufacturers, equipment suppliers and research bodies may wish to use the test bed for testing of C-ITS equipped vehicles, telecoms equipment, safety/driver behaviour or other aspects, then third-



party access procedures and supporting documentation may be required in order to manage this effectively, efficiently and safely.

Best practices:

An application process may be needed along with a policy document that sets out how third parties can apply for access to the testbed along with cost models, process for applying and any supporting documentation that the applicant is required to provide.

Agreements should include time/ date of operation and how access and testing will be regulated and procedures enforced.

Due to safety, security and intellectual property considerations, the use of the test bed would be tightly controlled and any request to access the test bed scrutinised to understand the reasons for and purpose of the request (i.e. to answer the why?, what?, when?, how? and who?).



7 Pilot evaluation

7.1 Overview

This section focusses on activities that need to be carried out for the evaluation of the pilot. Evaluation is central to achieving the goals of any pilot project. Three aspects of evaluation that are considered within InterCor are ‘technical evaluation’, ‘user acceptance’ and ‘impact assessment’. Depending on the nature of the pilot, focus can be put on any of the three. Here we will provide some general considerations before starting evaluation and some guidelines for each of the aspects.

7.2 General considerations

Consider what evaluation/trial needs to take place.

Consider the timing of the evaluation (start date, duration, etc.).

Consider how to carry out the evaluation/trial. Keep in mind the expected outcomes.

Make sure to involve all parties concerned with the evaluation/trial.

Consider the use of focused test events and scripted scenarios that can be used to collect and evaluate data for specific aims/tests, in a controlled environment, to focus on specific aspects of the services.

Confirm with the responsible entity that all necessary data can and will be collected.

Make sure you align the evaluation with the objectives/goals of the project.

7.3 Technical evaluation

The technical evaluation measures the effects of implemented technologies on system performance and quality of services and includes: Interoperability, compliance, performance of security measures, (hybrid) communication, positioning and application triggers, performance (accuracy, location, timeliness and reliability) of advices and information provided to drivers and other users like traffic operators, fleet operators and service providers, assessment of the quality of collected data,….

Data logging must be consistent for both participants and partner systems. Requiring that participant attendees adopt common logging formats will ensure consistency. Ensuring data logs are consistent helps with data analysis activities and reduces the amount of time required to “cleanse” the data obtained. This allows results of evaluations to be more readily provided.

Reduce potential ambiguity of data formats and restrict the inclusion of “optional features” of data logs.

Use a consistent format for data that is collected from OBUs and other devices. This will aid the later integration and interpretation of data.

7.4 User acceptance

User acceptance is paramount for the fast deployment of C-ITS services. It is therefore common that pilots involve dummy users to collect their feedbacks through questionnaires or during the driving.

Consider a limited and focused number of evaluation questions in order to be able to



clearly identify the cause of observed effects.

Use representative drivers based on the objectives of the project.

Consider a broader range of users for user acceptance. Drivers are only a (quite important) part of the ecosystem. Other stakeholders like road authorities or transport companies can provide useful feedback.

7.5 Impact assessment

The impact assessment of certain applications and services includes the identification of the rate of advice, follow-up and their impact on indicators such as speed adaptation, route choice, travel times and traffic efficiency and safety.

Consider the use of video recording of piloted situations in order to help interpreting, validating and evaluating the collected data.

Consider also to collect and record pilot context information like weather and traffic information in order to be able to justify or filter out special days and situations in the data set.

Take in consideration the need for a good data administration system which is able to integrate different information sources, such as videos, handwritten notes and log data, in order to be able to combine them for development of integrated data insights.

Use a control group to compare behaviour with C-ITS to behaviour without C-ITS. This control group can be a representative separate group, the test drivers before the introduction of C-ITS or alternating C-ITS-on with C-ITS-off for the test drivers.

Make sure to gather enough observations during multiple controlled test runs. The level of validation increases with the number of test runs. If the number of test runs drops below a minimum level then impact evaluation (and to a certain extent user acceptance) will be limited. For further guidance, see the “Detailed evaluation methodology” document produced by InterCor Activity 4.



8 Cost considerations

With regards to guidelines and best practices from the InterCor project for the costs of pilots, it is important to notice that the pilots developed and operated in the four participating MS of InterCor differ considerably. Each pilot had its own specific scope and characteristics. There are differences regarding the duration of the pilot, the pilot area (km / number of intersections), the type of road network (urban, regional or motorway), the piloted services and scenarios, the duration of the pilot, the number of pilot users or participants, the number of equipped vehicles, the number of organizations involved as well as the approach to realise the pilots (see also the InterCor M9 Deliverable).

In addition, the context and level of experience with C-ITS at the start of the pilots was different in the four MS. In some cases it was possible to build on already available or deployed systems, or existing services and facilities from previous projects, pilots or deployments. In other cases the pilots had to be realized from scratch.

Because costs are very much dependent on the scope, characteristics and context of the pilot, it is very hard to provide reliable cost estimations, which will be useful for the planning of future pilots. Based on the experience from the InterCor project, it is only possible to give a rough indication of the total costs. In order to do this, the actual reported pilot costs per MS has been considered as well as the pilot scope and characteristics per MS. Based on this, a rough indication of the costs has been determined for two fictitious, but realistic pilots: a pilot on a motorway and a pilot in an urban environment.

Table 6: Rough indication of costs for two types of pilots

pilot use cases communication #RSU # vehicles pilot

duration

rough cost

indication

motorway RWW,

IVS, PVD

ITS-G5 and

cellular

15 15 6 months 2,5 – 3,5 M.

Euro

urban GLOSA ITS-G5 and

cellular

10 15 6 months 1,5 – 2,5 M.

Euro

The rough indication of costs covers the building of the pilot site and after it is ready, keeping it operational during a period of six months. This indication is based on the price level in the InterCor MS. It is including the costs for personnel (also personnel from the road operator itself) and other directly related costs, such as road safety measures to install equipment along the road.

In addition to the realisation of the pilots, much attention will be necessary for the evaluation of the pilots. Based on the experience in InterCor, this will result in around an additional 15% of the pilot costs.

Further best practices on costs considerations:

Take into consideration the use of current and planned projects/ contracts for (life cycle) upgrades of infrastructure in order to deploy pilot

Consider making use of market prototypes and concepts which can still be further developed (with less costs than full development) based on pilot needs and requirements.

Consider an early start of the system design (guidelines) in order to have a wide outlook on total costs of pilot deployment and operation.



9 Key points, main considerations

The following key points and main considerations have emerged from this document:

At the start of a pilot project, or even better before the start, it is recommended to define a clear vision statement for what the pilot is looking to achieve at a strategic level that defines the overall direction and sets the context for more specific aims and objectives. In this context it is recommended to consider relationships, commitments and/or interaction with other (European and neighbouring countries) programs and initiatives.

It is important that the aims and objectives are clearly defined, and that they are achievable and measurable, where possible, so that it can be determined if/when goals and benefits have been realised. Doing so, will also allow relating requirements to the project objectives, which helps avoiding imposing requirements that are not critical and impossible to meet.

There are a lot of geographical, technical, cost and policy considerations to be taken into account when selecting an appropriate pilot site. It is therefore advisable to always perform a site visits to asses all of the above aspects.

Consider which communication technologies you wish to deploy early on in the pilot planning as this largely determines the equipment requirements. Consider a cellular (network-based) communication versus a direct (localised) communication (like ITS-G5) or a combination of both.

In terms of pilot operation and maintenance, it is essential to ensure continuous and transversal monitoring of project stages especially for deployment and working, with clearly identified roles and responsibilities.

Particular attention must be paid to interactions and interventions of external stakeholders (users, drivers, partners) during tests and validations.

Evaluation is central to achieving the goals of any pilot project. It is therefore crucial to develop an evaluation plan early in the pilot planning phase to get it aligned with the objectives of the pilot. Automation can much facilitate the data collection and analyses of the extensive data sets.

In order to deploy the pilot in an cost-efficient manner, take into consideration the use of current and planned projects/ contracts for (life cycle) upgrades of infrastructure, as well as to make use of market prototypes and concepts which can still be further developed an configured based on your pilot needs and requirements.



10 Bibliography

[1] InterCor Milestone 3 report: “Milestone 3 – Common set of upgraded specifications for ITS-G5”, V1.1, 20/10/2017

[2] InterCor Milestone 4 report: “Milestone 4 – Common set of upgraded specifications for Hybrid communication”, V1.0, 23/03/2018

[3] InterCor Milestone 5 report: “Milestone 5 – Common set of upgraded specifications for PKI and Common Certificate Policy (CP)”, V1.0, 24/09/2018

[4] InterCor Milestone 6 report: “Milestone 6 – Common set of upgraded specifications for Services”, V1.0, 15/10/2018

[5] InterCor document "Next steps for hybrid communication”

[6] Scoop deliverable 2.4.2.1: “SCOOP R-ITS-S specifications 2.4.2.1_H”, V1.14, 29/01/2019

[7] Scoop deliverable 2.4.2.1_bis: “SCOOP R-ITS-S deployment and installation_2.4.2.1_bis”, V0.10, 01/02/2019



Appendix A – Pilot Deliverables Matrix



Appendix B – Description of pilot Deliverables

Note: the deliverable descriptions contained in Appendix B are provided for guidance purposes only. Each testbed deployment should decide which deliverables are relevant as not all deliverables are necessarily required in all cases.



Work Package 1 – Infrastructure and Systems Design

Deliverable Title Concept Design / Requirements Gathering Ref ID: WP1.1

Description Initial concept of the pilot in terms of location of testbed, what C-ITS services are to be implemented and what communication equipment may be needed. High level outline plans are used to obtain requirements from stakeholders and helps to inform the Concept of Operations and Preliminary Design.

Outputs Outline/concept design

List of initial high-level requirements

Dependencies/inputs WP6.1 Communications Plan

WP6.2 Responsible, Accountable, Consulted, Informed (RACI) Matrix

WP6.3 Stakeholder Communications Log

Deliverable Title Preliminary Design Ref ID: WP1.2

Description A more complete design compared with the concept design that shows indicative equipment locations for roadside infrastructure and communications network to back-office systems.

Outputs Preliminary design drawings

Interoperability considerations between organisations and networks

Dependencies/inputs WP1.1 Concept Design / Requirements Gathering

WP3.1 Concept of Operations

Deliverable Title Detailed Design Ref ID: WP1.3

Description Detailed design showing accurate location of equipment to be installed along with power and communications ducting and network splice diagrams. Also radio survey should be included if utilising wireless communications technology.

Topographical survey of the equipment sites is also carried out as part of detailed design.

Outputs Detailed design drawings

Fibre splice diagrams (if applicable)

Results of radio survey/interference testing (if applicable)

Topographical survey results

Conflict analysis with existing buried services e.g. electrical cables

Dependencies/inputs WP1.2 Preliminary Design

Deliverable Title System Architecture Ref ID: WP1.4

Description System design including software Unified Modelling Language (UML) diagrams, software architecture diagrams and system model diagrams.

UML diagrams to include: message sequence diagrams, class diagrams and security considerations (PKI, encryption etc.)

Outputs Network architecture

High/low level systems diagrams



End-to-end systems design

Rack space diagrams

Power, cooling, storage, server requirements

Software architecture and UML use case diagrams

UML message sequence/class diagrams

Software/system testing methods

Dependencies/inputs WP1.3 Detailed Design


Deliverable Title Security Model/Architecture Ref ID: WP1.5

Description Security model considerations for systems and software deployed as part of the pilot. Needs to include physical and cyber security measures, remote access to systems, user access control, single sign-on, Public Key Infrastructure (PKI), encryption etc.

Outputs Clearly defined security architecture

Safety and security measures

Trusted user access controls

Physical and software security measures

Encryption requirements

Dependencies/inputs WP1.4 System Architecture

Deliverable Title Agile Sprint Planning/Story Boarding Ref ID: WP1.6

Description If adopting an agile approach to software/systems development then sprint planning needs to be carried out and documented. Also, user requirements need to be converted to user stories for inclusion in one or more sprints.

Outputs User requirements grouped into one or more user stories

Planned sequence of sprints stating which user stories are contained within and the duration of the sprint cycle

Allocated agile roles including Product Owner, Scrum Master, Lead Developer, etc. need to be agreed and documented

Dependencies/inputs WP1.1 Concept Design / Requirements Gathering

WP1.4 System Architecture

WP1.5 Security Model/Architecture


Deliverable Title Construction Design Management (CDM) Documents

Ref ID: WP1.7

Description A suite of relevant CDM documents to support the detailed design. Needs to cover pre-installation planning, installation and removal (end-of-life) procedures. Also needs to document maintenance of the equipment deployed and that safety aspects have been considered and built into the design at each design stage.

Outputs Suite of CDM documents that meet the latest standards/requirements




Work Package 2 – Safety Governance

Deliverable Title Safety Plan Ref ID: WP2.1

Description The purpose of the Safety Plan is to describe the safety governance

methodology to enable the Hazard Assessment process to be

undertaken. It seeks to address the question “What is the impact of the

Connected Corridor trial on safety risk and is the proposed operation of

the trial acceptably safe?”

Outputs Safety Plan document detailing safety management activities, risk assessment activities, approval processes e.g. Safety Hold Points and safety standards to be followed.

Dependencies/inputs None

Deliverable Title Combined Safety and Hazard Log Ref ID: WP2.2

Description The purpose of this report is to demonstrate that an appropriate level of safety governance has been applied to assess the expected safety performance for the implementation of the Connected Corridor Pilot.

Outputs Document detailing how the trial addresses the key hazards and safety aspects and in what circumstances additional measures/interventions are required.

Dependencies/inputs WP2.1 Safety Plan

Deliverable Title Driver Distraction Principles Ref ID: WP2.3

Description Report detailing the main causes of driver distraction during the pilot and how these can be reduced or removed from the design to minimise risk to the designated fleet driver(s) and other road users.

Outputs Set of driver distraction principles which must be adhered to throughout the design and implementation of the trial to reduce risk to drivers and other road users.


WP2.2 Combined Safety and Hazard Log

Deliverable Title Plan for Monitoring Operations Ref ID: WP2.4

Description Plan for Monitoring Operations (PfMO) sets out how safety performance of the on-road testing will be monitored during pilot.

The PfMO provides a description of the process to be followed to

enable the validation of the safety assessment for pilot on-road

testing. It describes how monitoring will be used to identify significant

occurrences (“Trigger Events”) and respond appropriately.

Outputs Report defining the trigger events that may occur during pilot, how these will be monitored and the action to take if a trigger event occurs.




WP2.2 Combined Safety and Hazard Log

Deliverable Title Safety Log and Reports Ref ID: WP2.5

Description The Safety Log records any safety issues/risks/events that occur or are raised during the pilot evaluation. The Safety Report is a summary of the issues contained in the Safety Log for dissemination to relevant parties.

Outputs Safety Log and detailed report based on information captured in the Safety Log.

Dependencies/inputs WP2.4 Plan for Monitoring Operations

Work Package 3 – Pilot Implementation/Deployment

Deliverable Title Concept of Operations Ref ID: WP3.1

Description The Concept of Operations (ConOps) documents who the main stakeholders are and their involvement in the pilot. The ConOps also captures the operational needs of stakeholders and sets out how these are implemented during the pilot through a series of high-level architecture diagrams and operational scenarios to allow the evaluation of C-ITS services to take place.

Outputs Concept of Operations report (including stakeholder requirements and operational scenarios).




Deliverable Title Operational Processes/Procedures Ref ID: WP3.2

Description A set of existing and newly defined processes (if required) that control the implementation, operations, safety and evaluation aspects of the pilot. The processes need to state what actions need to be carried out when, how and by whom.

Outputs Operational processes that feed into the Implementation and Management Plan.

Dependencies/inputs WP3.1 Concept of Operations

Deliverable Title Implementation and Management Plan Ref ID: WP3.3

Description The Implementation and Management Plan (IMP) extends the Concept of Operations (ConOps) document by converting the operational requirements defined in the ConOps into an operational plan that drives the implementation programme, operations and evaluation of the trial. The IMP helps to ensure there is a sufficient level of coordination and collaboration between stakeholders to enable integration and seamless operation of equipment and C-ITS services.

To enable this coordination, the IMP seeks to formalise and ratify the implementation, operational and safety aspects of the pilot. This is because the safe management and operation of the live pilot requires



detailed production and collation of operational level procedures and processes to support the pilot’s strategic outcomes.

Outputs Implementation and Management Plan that


WP3.2 Operational Processes/Procedures

Deliverable Title Procurement Strategy Ref ID: WP3.4

Description Document outlining the possible approaches to procurement of systems and services that will be deployed on and for the pilot and the relative advantages/disadvantages of each approach. The Procurement Strategy considers the risk to the project of each procurement approach and provides recommendations to a purchasing department of the optimum method. The strategy considers such factors as openness to the market, fair competition, conflict of interest and any legal/commercial constraints that may be imposed on potential bidders.

Outputs A strategy document that may contain estimated costs for procuring systems/equipment/services based on market research and analysis.

Dependencies/inputs WP1.2 Preliminary Design


WP1.6 Agile Sprint Planning/Story Boarding


Deliverable Title Deployment Schedule Ref ID: WP3.5

Description The Deployment Schedule documents what needs to be deployed, where and when to maximise efficiencies thereby reducing the costs involved.

Outputs The Deployment Schedule may take the form of a Gantt Chart (programme) or a set of drawings/maps that show change to the area over time – or a combination of the two approaches.



WP3.3 Implementation and Management Plan

WP3.4 Procurement Strategy

Deliverable Title Acceptance Testing Ref ID: WP3.6

Description This item covers all aspects of acceptance testing including factory acceptance testing (FAT), product acceptance testing (PAT) and site acceptance testing (SAT). Each of these stages of testing will require a test specification that details i) what is to be tested, ii) how it will be tested, iii) any pre-requisites to the testing and iv) the expected and observed results from the testing. The test specification should reference each user requirement individually so that they can be tested comprehensively at the various test stages (i.e. FAT, PAT, SAT).

Outputs Test specification and test results sheet/document.






Deliverable Title Handover and Commissioning Pack Ref ID: WP3.7

Description The handover and commissioning pack contains a set of documents that will allow a third-party organisation to take over the maintenance and operations of a service, a system or piece of equipment.

Outputs The pack includes such documents as design documents, detailed drawings, test documents, maintenance plans and construction & design management (CDM) documents.

Dependencies/inputs WP1.7 Construction Design Management Documents

WP3.6 Acceptance Testing

WP4.6 Maintenance/Fault Management Plan

Work Package 4 – Pilot Operations and Maintenance

Deliverable Title Operations Plan Ref ID: WP4.1

Description The operations plan details how the trial will be managed on a day-to-day basis and calls on the processes and scenarios present in the Concept of Operations and Implementation and Management Plan to help achieve this.

The Operations Plan helps to ensure all operational elements of the pilot are in place to allow the evaluation to run smoothly and gather useful data.

Outputs Operations Plan document



WP4.3 Risk Management Plan

WP5.3 Evaluation Plan

Deliverable Title Governance Structure/Plan Ref ID: WP4.2

Description To execute an effective pilot there needs to be a well-defined governance structure than can resolve issues quickly and effectively. The Governance Plan defines the escalation route to be followed if/when issues cannot easily be resolved and the named representatives of key roles within the overall governance structure and the duties they are required to carry out.

Outputs Governance Plan document containing an organisation chart and a roles and responsibilities matrix.



WP6.1 Communications Plan



Deliverable Title Risk Management Plan Ref ID: WP4.3

Description This document defines the process for identifying, recording and managing risks throughout the pilot. The document also contains information about assigning risks to groups/individuals as ‘risk owner’ and the method for escalating risks (when required) before those risks become issues.

Outputs Risk Management Plan document containing a risk register of identified risks. Note: that after the Risk Management Plan has been published the risk register contained within remains a live document and will be updated periodically whilst the pilot is still ongoing.



WP4.1 Operations Plan

WP4.2 Governance Structure/Plan


Deliverable Title OBU/HMI Installation Instructions Ref ID: WP4.4

Description This document contains detailed step-by-step instructions on the installation of the On-Board Unit (OBU) and Human Machine Interface (HMI) that are installed within vehicles taking part in the pilot.

Outputs Detailed step-by-step guidance document.





Deliverable Title Driver Training/Briefing Pack Ref ID: WP4.5

Description Driver training is needed to ensure that drivers are aware of the safety and operational aspects of the trial, are informed of their involvement in it, and are advised about the role and responsibilities drivers have during the trial evaluation. The training can take many forms including classroom based presentations, handout leaflet, webinar, workshop/seminar or a combination of these approaches.

Outputs A suite of documents including slides, documents, videos etc. to support the chosen training approach.


WP2.4 Plan for Monitoring Operations


WP4.1 Operations Plan





Deliverable Title Maintenance/Fault Management Plan Ref ID: WP4.6

Description This document defines the process for managing maintenance (planned/unplanned) during the pilot and how faults/issues are dealt with regarding systems and equipment deployed.

Outputs Document detailing the maintenance regime for the pilot.





WP4.4 OBU/HMI Installation Instructions

Deliverable Title Third Party Access to the Testbed Ref ID: WP4.7

Description Allowing third party organisations (e.g. equipment suppliers, automotive companies, telecommunications equipment providers) to use the testbed can have major benefits to the success and outcomes of the pilot. These benefits can include commercial, technological, innovation as well as filling gaps in expertise and resources. To allow third parties to engage with the pilot a set of policies and guidelines needs to be developed along with a documented application process.

Outputs Document containing the application form and guidance notes to third parties wishing to apply for access to the testbed.






Work Package 5 – Evaluation

Deliverable Title Evaluation Requirements Ref ID: WP5.1

Description A documented list of requirements that address the evaluation needs of the pilot. The requirements could take the form of a set of research questions (hypotheses) that needs to be answered as part of the pilot. The questions help to inform the type, format and amount of data that needs to be captured during the pilot evaluation activities.

Outputs Document containing set of requirements that the evaluation should address.








Deliverable Title Evaluation Methodology Ref ID: WP5.2

Description This strategic document contains the methodology or process that will be followed to address the evaluation requirements. In other words, the methodology defines what will be addressed from the evaluation requirements and the approach that will be taken e.g. short time-boxed periods of intensive testing or more continuous ad-hoc testing over a longer time period.

Outputs A document defining the methodology/approach that will be adopted for the evaluation stage of the pilot.

Dependencies/inputs WP5.1 Evaluation Requirements

Deliverable Title Evaluation Plan Ref ID: WP5.3

Description The Evaluation Plan expands on the information contained in the Evaluation Methodology to state how the evaluation will take place, provision of drivers, location of testing, what data will be collected, how the data will be analysed etc…The Evaluation Plan will also define a timeline for the evaluation activities and dependencies on other pilot work streams e.g. operations, safety governance, systems etc.

Depending on the scale of the pilot, it may be beneficial to divide the Evaluation Plan into multiple distinct sections/documents that cover specific aspects of the evaluation such as technical, traffic impact and user perception.

Outputs A comprehensive plan for how the evaluation will be executed.

Dependencies/inputs WP5.2 Evaluation Methodology

Deliverable Title Driver Feedback Ref ID: WP5.4

Description Capturing driver feedback throughout the evaluation is important to ensure that non-technical aspects of the pilot are considered and analysed. Driver feedback may take the form of participant questionnaires, interviews, forums etc. and a range of methods should be considered to suit the communication style of participants in order to

Outputs Raw data in questionnaires, spreadsheets, recordings and meeting notes.

Dependencies/inputs WP5.3 Evaluation Plan

Deliverable Title Evaluation Results Analysis Ref ID: WP5.5

Description The raw data from the Driver Feedback activity will be analysed and formatted to allow conclusions about the driver feedback to be made. Statistical methods should be applied to the data to ensure any conclusions are statistically significant and not biased or skewed due to random variances and/or outliers.

Outputs Results and conclusions that will feed into the Evaluation Final Report.

Dependencies/inputs WP5.1 Evaluation Requirements




WP5.4 Driver Feedback

Deliverable Title Evaluation Final Report Ref ID: WP5.6

Description A document summarising the conclusions, lessons learnt and recommendations from the technical and non-technical aspects of the evaluation. This document also states whether the original evaluation requirements have been met and how this was achieved. This document is essential to understand the outcomes and benefits that the pilot has realised and to identify the business case for subsequent pilots.

Outputs Document detailing the conclusion, outcomes, and recommendations from running the pilot.

Dependencies/inputs WP3.3 Implementation and Management Plan

WP5.1 Evaluation Requirements

WP5.2 Evaluation Methodology


WP5.5 Evaluation Results Analysis


WP6.4 Lessons Learnt Log

Deliverable Title Business Case Ref ID: WP5.7

Description A Business Case defines the need for a pilot (or extension to a pilot) based on business drivers and considers the strategic options available based on feasibility, cost and the benefits that could be realised.

A business case will most likely be needed to continue a pilot beyond the current scope/programme for which a budget has already been secured.

Outputs A business case document with cost/benefit analysis and cost models.

Dependencies/inputs WP2.5 Safety Log and Reports



WP5.6 Evaluation Final Report


WP6.5 Stakeholder Information / Newsletter

Work Package 6 – Stakeholder Engagement

Deliverable Title Communications Plan Ref ID: WP6.1

Description This document provides details about the stakeholder groups that need to be kept informed during the pilot and the method and frequency of this communication.

The scope of this document could include:

The identification of key stakeholders as well as recording other

stakeholders;

A RACI (Responsible, Accountable, Consulted, Informed) matrix



detailing key scheme activities and assigning responsibilities (see

WP6.2 below);

A schedule of stakeholder meetings to be held during these

phases;

A question bank as a basis for information gathering from

stakeholders.

Outputs Communications Plan document.

Dependencies/inputs None

Deliverable Title Responsible, Accountable, Consulted, Informed (RACI) Matrix

Ref ID: WP6.2

Description A table defining who the stakeholders are and their level of involvement/responsibility within the context of the pilot.

Outputs Completed RACI matrix.


Deliverable Title Stakeholder Communications Log Ref ID: WP6.3

Description A means of recording communication with stakeholders during the pilot.

Outputs A completed document showing the time, date, parties involved and the key outcomes/points from the communication.



Deliverable Title Lessons Learnt Log Ref ID: WP6.4

Description A record of lessons learnt during the pilot to help inform current and future pilot implementations. The lessons learnt can be categorised to help with information filtering and dissemination to third parties:

Trial management and governance processes;

Stakeholder liaison and interfacing between stakeholders;

Any issues affecting the implementation and maintenance of equipment deployed;

Operational aspects, working practises, procedures etc.;

Resources and training requirements.

Outputs A document containing all lessons learnt which is updated throughout the pilot.


Deliverable Title Stakeholder Information / Newsletter Ref ID: WP6.5

Description A Connected Corridor pilot involves people from disparate fields including, but not limited to, engineering, mathematics, operations, safety and human factors. Information flow between these disciplines is vital to keep stakeholders informed of relevant topics that may be of interest to



them. A newsletter or e-Bulletin is one way of presenting this information in an easily accessible format. An e-Bulletin can be published periodically online or via email to target specific groups involved in the pilot.

Outputs Published newsletter/e-Bulletin.





Milestone 10 – Roll out Guidelines and Best Practices of ......Milestone 10 – Roll out...

Documents

Transcript of Milestone 10 – Roll out Guidelines and Best Practices of ......Milestone 10 – Roll out...