Common building blocks for ITS test beds and field operational tests

Final Report Summary - ITS TEST BEDS (Common building blocks for ITS test beds and field operational tests)

Executive Summary:
The ITS Testbeds project took place under the EC’s 7th framework program and was coordinated by the ITS Nationals, a network of SME-associations active in the field of Intelligent Transport Systems.
Alignment was done at both a technical and an organizational level:
Technical alignment: The ITS Test Beds project has defined an open and flexible reference architecture for constructing and running test environments for complex ITS applications, including C2X (car to infrastructure communication) scenarios. The architecture allows to seamlessly integrate pre-existing components e.g. external infrastructure. Test set-ups that follow this approach are re-usable for different test cases due to sufficient flexibility and re-configurability. The prototype implementation is following the service-oriented architecture paradigm and uses BEPL to model processes.
Figure: 1. Service-oriented architecture
Figure: 2. Processes modeled using BPEL
Organizational alignment: The partners in the ITS Test Beds project have created a valuable network for testing, each supplying its own unique knowledge areas, technologies and tools for testing. Together they cover a wide area of expertise and will be able to better support testing ITS applications and components. Customers with a test request can approach one of the partners for support. This partner will be the customer’s contact point, and will, in accordance with the customer’s wishes, be responsible for involving the other partners where needed. Hence, this partner serves as “portal” for the customer and provides the customer with an easy and transparent test process.

Project Context and Objectives:
1 Intelligent Transport Systems: realising the vision of connected vehicles
Though advances in passive and active safety technology will continue to make substantial contributions for some time, these are insufficient for the ambitious EU-wide safety, congestion and environmental targets to be met. Increasingly, the focus is therefore on Intelligent Transport Systems (ITS), a set of new technologies that allow vehicles to communicate with each other and their environment. ITS uses existing communication infrastructure such as cellular networks (GSM, GPRS, EDGE, 3G, …) and broadcast media (FM, DAB, DVB …) as well as short-range communication (Wireless LAN, microwave and infrared DSCR …) and future evolutions (such as the automotive version of Wireless LAN, 802.11p to support real-time communication between vehicles, as well as between vehicles and roadside infrastructure) to deliver a quasi-unlimited list of applications and services (as an example, footnote provides a list of applications based on real-time communication, also known as “co-operative systems” applications). Together these will have a dramatic impact on safety, traffic fluidity, security and the environment. ITS also makes it possible that vehicles act as floating sensors on roads and generate the necessary (amount of) data to enable new services such as individualised route guidance and travel time prediction. This data is expected to help create a new ecosystem of public and private organisations, for instance acting as content or service providers, as well as new markets. When fully deployed, this new ecosystem and market will generate tens of thousands of new jobs in Europe, many of which will be at SMEs as their flexibility, drive and innovation capability is needed to fill in many of the new roles.
Because of this potential, ambitious research programmes have started in Europe, Japan and the US and these have delivered the first building blocks that make it possible to realise the vision of connected vehicles and the unprecedented gains in safety, efficiency and environmental impact that it represents.
2 The indispensability of Field Operational Tests (FOTs)
ITS and co-operative systems test beds, in which applications can be seen and experienced at work, and Field Operational Tests (FOTs), in which larger numbers of drivers and vehicles participate, are indispensable prior to the introduction of this new technology. This is true because of four reasons:
1. The need for public investment and public-private partnerships: ITS and especially co-operative systems rely on private in-vehicle infrastructure as well as on investments made by the public sector. This is true for many applications such as eCall and Intelligent Speed Adaptation but is the clearest for co-operative systems as in this case real-time communication infrastructure needs to be placed along selected roads and at key intersections.
2. The need for a societal debate on selected applications: reviewing the list of possible applications running on co-operative systems infrastructure mentioned before, it is clear that some are more intrusive than others in terms of impact on driver and vehicle behaviour.
3. Privacy: Some applications, such as electronic vehicle identification or enforcement, may reveal the identity of the driver. Privacy issues therefore need to be thoroughly addressed.
4. Liability: In some cases ITS and co-operative systems technology will need to act in a pre-emptive way to be effective. Drivers may therefore no longer be in full control of their vehicle at all times. Related liability issues need to be cleared out.

3 The challenge: establish interoperable test beds first
In technical developments, 3 steps are typically followed: (1) development and testing of individual components by a company and tests in a controlled (lab) environment, (2) testing of components of different suppliers on interoperability in a controlled environment and (3) demonstration and assessment of complete systems of which the components are provided by multiple companies, in normal operating conditions. Before moving to FOTs (Field Operational Trials) in Europe, interoperable test beds based on open and validated solutions should therefore be established first. Not doing so would carry a high risk that different national approaches and technology camps will emerge throwing the prospect of deployment in Europe back by several years. This is true as interoperability – the ability of vehicles to interact in the same way with the roadside equipment in all member states – based on the emerging European standards is clearly a precondition to deployment. The involvement of the large national, established research centers in doing so is essential.
In this context, the following main goals were defined and realised in the ITS Test Beds project:
1 By defining the ITS Test Beds infrastructure and assembling a first version, the project managed to consolidate the results of previous European research. Most of this work was done in the first 6 months of the project, starting with several interactive workshops to brainstorm about the specific objectives of the ITS Test Bed and the expectations of all partners. The result of these interactive discussions is DEL 2.1 the definition of the ITS Test Bed. Closely following this definition also a first operational version was created. Every workshop, the results of the operational version were presented and demonstrated.
2 The second main goal was to safeguard the results. This was done by creating a non-profit company called Telematics INCubator (TINC). Amendment 1 of the project was initiated to transfer the development activities from one of the partners (IBBT) to this newly raised TINC.
3 Linking the components to TASC (the Test Aggregation and Service Centre) and the ITS Test Beds portal: In order to demonstrate the feasibility of the concept of TASC and of the ITS Test Beds portal, which was realised in the second phase of the project, several components from project partners were integrated into the ITS Test Bed.
4 Disseminating the work: The goal was to enable SMEs to have access to the results of the project and to make sure the results became available to companies and research organizations through the portal. For this, training sessions and interactive discussions were organized, resulting in a deployment to a few hundred people in the sector.

Project Results:
1 WP 1: Project Management
A Consortium Agreement (D1.1) was created, reviewed and fine-tuned between the partners. It was then distributed for signing. The signing-process took quite some time (from May 2009 to June 2010). Besides the typical signing processes in the different large organizations, some internal changes at INRETS caused quite some delay to get the fully signed documents. Around May 2010, the internal re-organization at INRETS was consolidated, resulting in a signed copy, also from their side.
A Quality Plan (D1.2) was created, stipulating several project procedures and processes, especially focusing on administration and finance. Because of the special budget-nature in this project, a subcontract “way-of-working” document was created and agreed upon to align between the partners and the project manager/coordinator.
In order to track the project on running activities, large activities have been split into smaller sub-work packages and agreed upon between the project manager and each partner. This enables the project partners to track and report own progress on an agreed basis and helps the project manager to collect a joint status report in an easy way in an “earned value”-like graph.
Besides the Progress reports also monthly project dashboards were created to (1) consolidate the actual status between the partners and (2) update the project coordinator at the EC about the status of the project. The project dashboards were including the tracking of the completion of subtasks, based on the agreements as explained above, but also reported the cost statements from NXP, which are the justification of the project, as well as good and bad news and status of the deliverables.
From the mid-project review meeting onwards, the project management of the ITS Test Beds was extended with the communication of the updates from the mid-project review, the updates of the report and communication on the Amendment 3, as well as the preparation of the final report:
- The mid-project review was held on 17 September 2010. Some of the important feedbacks of the reviewer and the EC referred to the quality of the deliverables and the methodology. During the second period, a lot of effort was spent on increasing the quality of the deliverables and further documenting the methodology, ie the reporting of all activities needed and executed to create the results.
- As one partner, INRETS, decided to withdraw from the project, just after M18, but before the mid-project review meeting, an amendment was proposed by the consortium to shift the budget from the review-activities, planned at INRETS, to integration-activities at TNO and TINC in order to ensure integration of the TNO-tools and ATOP into the ITS Test Beds framework.
- The second periodic report was created at the end of the project to report the activities on the second period of the project.

2 WP 2.1: Consolidating the results of European research - Definition of an ITS test bed
WP2.1 aimed at defining a comprehensive ITS test bed reference architecture in relation to the selected use cases that are examined and the definition of the basic components of the reference architecture.
The approach to define a reference architecture for ITS test beds was mainly driven by the substantial analysis/consolidation of requirements derived from a large number of use-cases which are currently discussed in the field of driver assistance and automation systems in the automotive domain.
Based on this overview, a representative set of use-cases were selected as a foundation for the first definition of the scope of the aspired reference architecture.
This first draft definition of the reference architecture was refined in an iterative process. This process was guided by results derived from interviews, questionnaires, existing reference architectures from the field of computer sciences and the analysis of architectures intended for the implementation as well as the assessment/test of assistance and automation systems such as CVIS, GST, and SAFESPOT.
Below the main contributions and results are described per partner (all partners contributed to this WP throughout workshops, meetings, conference calls, reviews and interactive discussions).
2.1 WP 2.1: DLR contribution
DLR had the lead in WP2.1 and served as a main contributor on deliverable D2.1. The key contributions to the WP were:
• Research of existing architectures and projects in this domain (Section Relevant ITS projects)
• Definition of requirements which are specific for the use of a test bed (Chapter Scope of the ITS Test Bed) and assessment of a representative set of applications which was to be supported by the infrastructure (Section Defining the scope in terms of Use-Cases)
• Definition of the necessary components and the appropriate system architecture (Chapter Technical architecture)
• Definition of interfaces to the existing test bed infrastructure (Chapter Technical architecture)
• Considering Certification as a test bed objective (Section Certification)
• Defining a methodology for testing of ITS applications (Section Tests).
2.2 WP 2.1: TNO contribution
TNO has contributed to this WP as an active co-writer on deliverable D2.1 focusing on the vision on testing, and the translation of FESTA results to the ITS Testbeds project. These contributions can be found in chapter 2 (vision), 3 (scope) and 5 (organization).

2.3 WP 2.1: IMEC Contribution
In work package 2.1 IMEC focused mainly on the specific objectives on wireless communication:
• Definition of the test bed focusing on the wireless link evaluation, performance testing and signal processing algorithm optimisation
• Definition of scenarios for radio channel emulation
• Specifically link performance modelling of IEEE802.11a communication was investigated for different channel conditions, as documented in the D2.1a deliverable.
• Additionally input was provided in how to link the IMEC simulation components in the ITS-test bed.
2.4 WP 2.1: SINTEF Contribution
SINTEF’s contribution of WP2.1 was two-fold:
• A description of the vehicle unit developed as the CVIS reference platform within the CVIS project, including antenna, CVIS router, host-PC and touch screen unit was provided. Installations of the platform in vehicles in Trondheim and testing towards road side units were described. The unit was demonstrated as part of the ITS Test beds project.
• Two use cases were described. The first one was dynamic speed alert, where the driver is alerted when a vehicle enters a new speed zone when variable speed zones are in force. The second one was incident hazard warning. Both applications were demonstrated as part of the ITS Test beds project, where the messages were displayed using the CVIS in-vehicle display.
2.5 WP 2.1: IBBT Contribution
IBBT’s contributed to WP2.1 with the following actions
• Description of use cases frontal collision warning, intersection assistance, dynamic speed alert. These were presented at the Delft use cases meeting.
• Description of services and components for ITS-Testbed, based on the questionnaire provided by DLR.
• Active support for the architecture definition, e.g. participation in the architecture workshop in Trondheim, and bilateral discussions with DLR regarding possible integration mechanisms for IBBT components.
• Reviewing deliverable D2.1 Definition of the reference architecture.
3 WP 2.2: Consolidating the results of European research - Assembling and validating a first version of the ITS test bed
The main objective for TINC was the development of an ITS Test Beds prototype and the authoring of the deliverable: “Report on first operational version of the ITS Test Bed”. The idea was to make this last report the “Users Manual” for those installing, operating and using the ITS Test Beds prototype software. As a result, a first version of Test Aggregation Service Center (TASC) was installed and made ready for use. A new improved and final version of the TASC was realised by the end of month 18 in the project. At the same moment a first and initial version of the community portal was made available allowing test case developers to create new test cases and make these test cases available to the TASC. This version was completed during the fall of 2010.
Activity 2.2 was part of work package 2, being the definition of the architecture of an ITS Test Bed framework and the development of a first prototype which demonstrates the main features of this architecture. During the first three months of the 2.2 activity TINC worked very closely with DLR, the stakeholder responsible for work package 2.1 and translated the abstract architecture into an implementation view. During this first period the abstract architecture was translated into two main components:
A central repository for the definition of test cases and the storage of raw test data – this part of the system was identified as the TASC. The TASC receives on the one hand Test Case configuration descriptions and during the test process the raw test data. TASC, on the other hand, provides interfaces which allow external tools to retrieve data from the raw data database.
A Test Site Community Portal web application – this entity allows test sites to make all kinds of information available to other test sites participating in the community. Not only documents can be shared but also software or hardware components, services accessible via Web Service SOAP calls, Test Case results and even complete infrastructure descriptions. Next to the sharing of information the portal provides tools to develop test cases and upload the test case configuration files to the TASC. Finally the portal offers an easy to use query and download tool for raw test data from the database.
During a second phase in the development the best possible implementation technologies were researched and tried. These technologies include state of the art software development methodologies and frameworks such as Web 2.0 Service Oriented Architectures (SOA) and Cloud Computing. The community portal system is completely based on work done in the field of Cloud Computing and access by researchers in the field of astrophysics to super computers. The ITS Test Beds portal fulfils the same requirement namely connecting test sites to shared resources running on remote computers. An example makes this statement clear: Suppose an application receives DATEX II formatted messages. Test Site X wants to monitor the validity and conformity of these message to the standard. Instead of building a DATEX validation service, test site X simple re-uses a service already constructed by Test Site Y in the context of a previous test. This makes the overall test process much more efficient and especially cheaper to implement.
Not only did work package 2.2 work on software components, next to the software implementation TINC also proposed a procedure, supported by specific documents, for the development of Test Cases. This procedure starts with a discussion between Test Site operator and Test Case initiator or customer of the ITS Test Beds framework. At some point, an organization, be it public or private, wants to test and validate an ITS application such as for instance ISA or eCall. Together with the customer, the test site operator completes a Test Preparation form which basically holds all information necessary to conduct the test and evaluate or analyse the results. The test process is thereafter executed and terminated with a Test result report which again is discussed with the customer.
To demonstrate and evaluate the prototype implementation, two demonstrations were built. A first demonstration which emulated an eCall system, starting from the initiation of the eCall, over the processing of the Minimal Set of Data by an eCall Service Centre until the point where the eCall is transferred to the PSAP. A second demonstration shows how a test procedure on a Pay-As-You-Drive application could look like. Both demonstrations serve to show the possibilities of the ITS Test Beds Prototype and to test the functioning of TASC.

Figure: 4. ITS Test Beds Community Portal Screenshot
As such the following targets were realized:
• Authoring of a chapter which explains the relation between the abstract architecture developed by work package 2.1 and the implementation of the ITS Test Beds Prototype
• Research and testing of candidate technologies suitable for implementing the ITS Test Bed prototype
• Development of 2 demonstrations allowing to show and test the ITS Test Bed features and the test process
• Development of a first version of TASC
• Development of a first version of the ITS Test Beds community portal
• Integration of some Test Sites components on the prototype platform
• Authoring of a White Paper for the Busan ITS World Congress
• First training activity
• Authoring of a first version of the WP2.2 deliverable: “Report on the first operational version of the ITS Test Bed” for month 18.
• The development of the core system, being the TASC entity is completed and a version 1.0 is up and running.
• The development of the community portal was done and made available with a reduced number of components. The community portal is an extensible system; more components were subsequently added to the system as the need for these components raised.
• Development and release of an eCall reference and test system, integrated as a component in the community portal.
• Development and release of a Pay As You Drive demonstration also integrated as a component in the community portal.
• Re-packaging and improving of the Test Agent Client System as developed by the Global System For Telematics (GST) FP6 project.
• Assistance to the integration of first components which use the prototype.
• Use of the prototype by the Dominion component developed by partner DLR.
• Use of the prototype by the modelling tools of TNO.
• Use of the prototype for the configuration of the IBBT virtual wall.
• Use of the prototype by the CVIS demonstration test site operated by SINTEF.
The development of the prototype ran into a delay related to the development of the community portal application mainly due to the development of the two demonstrations. These demonstrations were necessary to show the project members what was meant with an “ITS Test Case” and an “ITS Test Bed”. The demonstrations helped to get an agreement from the project consortium regarding the core goals of the project. This delay only had a small impact on the realization of the community portal component.
All objectives were reached with only a small delay related to a periphery component, being the community portal.
3.1 Test Case SINTEF Test Site – DLR Codar Viewer
SINTEF developed a large test site in Trondheim, Norway. This test site was mainly directed towards the results of the CVIS FP7 project. The test site consisted of a traffic corridor which reaches from the Trondheim University unto the inner city of Trondheim. The idea of SINTEF was to produce test messages from vehicles which drive along this test track. These messages were sent to the Test Aggregation Service Centre (TASC). TASC stored this data into the TASC database and forwarded the test messages to a queue configured by the user of the data. This User is a tool developed by DLR: the CODAR viewer. The CODAR viewer stores the data in a local database and shows the location of the car driving in Trondheim on a map. The CODAR viewer allows to further process the data and feed it into tools such as those developed by TNO. The picture on the next page provides an overview of this Use Case.
The results of this test case were without any doubt encouraging and proved the basic concepts underlying the ITS Test Beds project. Tools from different research institutes were combined into a test set-up without the need for each and every test stakeholder to develop their own versions of the tools necessary to execute this test. This results in a reduced cost figure for ITS testing.

Figure: 5. Overview of the use case combination Trondheim Test-site and CODAR-viewer
3.2 Test Case NXP ATOP
This test case extends the simulated eCall test case which was already developed in the previous period. Instead of a simulated eCall, a device based on the NXP ATOP chip is used to produce a real, manual eCall message. This message is fed into an NXP-proprietary telematics platform and next forwarded to the ITS eCall Messenger and Viewer. The NXP ATOP device has been used in a live and real-time test project in the area of Leuven, Belgium. To support this use case, a User Guide was written which instructs third-party users how to perform and use this sample application for their proper use.
The following picture shows a screenshot of the eCall Messenger with a message received from the ATOP telematics system. The screenshot shows the Minimal Set of Data (MSD) message as described by the CEN specification.

Figure: 6. eCall Messenger parsing eCall received from NXP ATOP
3.3 ITS Test Bed Prototype User Guides
To support users while using the ITS Test Bed prototype components, a number of User Guides have been written. These User Guides explain some important aspects from TASC in a more practical format. The following User Guides have been authored:
• Running the eCalll Demo – As explained above this User Guide explains how to perform and use the eCall test suite
• Using the TASC analyzer tool – The Analyzer tool is an easy to use application which allows downloading test result data from TASC and dumping this data to a CSV file, with or without post processing.
• Developing Test Cases – Provides an introduction into the “art” of developing ITS test cases. Amongst other topics, this user guide explains the Test Case Developer tool and the schema of the test case configuration XML file.
• TASC and the Test Process – Describes the overall test definition process and how to interpret the result data.
• Using the Test Agent – The Test Agent is a Java SDK which facilitates the creation of client side test code.
• Using test message forwarding – Gives an overview on how messages are handled and how an output queue can be configured for retrieving messages in real time from TASC.
3.4 ITS Test Bed Helpdesk
TINC provided a helpdesk function throughout the project. During this time end-users were supported when elaborating the test cases and project partners such as TNO and IMEC were assisted while integrating their tools in TASC.
4 WP 3.1: Technical developments - Interoperability testing of key components
WP3.1 deals with interoperability testing of C2X communication equipment. For this purpose a layered approach has been chosen, where the interoperability on each ISO OSI-stack layer between two radio components is checked. Within this WP key parameters have been identified, test purposes and test cases have been defined and a set of tools, the testing platform, were presented in order to create a compact testing handbook for interoperability testing of C2X equipment.
At the end of the 12 months WP two deliverables, namely D3.1.1 “Report on interoperability testing platform” and D3.1.1 “Report on the interoperability tests of the communication components”, were delivered.
Kickoff of this WP has been in early February 2010. The main work on lowest layer interoperability testing, i.e. interoperability on physical and data link layers, was realized and a first version of D3.1.1 and D3.1.2 containing this work was presented at the beginning of June 2010.
Moving upwards the OSI stack, the Networking layer has been analyzed in the following months. Based on the latest ETSI standards for the ITS networking and transport layer, a set of over 15 test cases to prove interoperability have been designed. The tools developed for generating network traffic have been applied on two independent implementations of the networking layer developed in the frame of another EU project.
In the last period of the WP, interoperability at the level of the ITS application layer has been analyzed. 6 applications developed PreDrive C2X were checked for interoperability. For this purpose the concept of interoperability on ITS application layer was defined and a set of test cases were presented. DLR’s CODAR Viewer tool has been enhanced to help the tester perform interoperability assessment during field operational tests.
In May 2011 the WP has come to an end. Two documents, D3.1.1 and D3.1.2 were delivered where the different test cases and test tools are presented, along with the results on the prototypical implementations of the communication components.
5 WP 3.2: Technical developments – Simulation and evaluation
Task 3.2.1 Management and preparation: three systems were selected for further analysis in this work package, namely road pricing, smart parking and speed alert. An internal kickoff meeting of WP3.2 and further WP3.2 meetings have been held to coordinate activities within this WP and to strengthen the connections between the tools developed in the WP. These tools concern traffic simulation, cost-benefit analysis and business modeling. The interactions between the tools and the process flow through the tools have been identified for several types of uses of the test bed environment. For the road pricing application, the setup of the analysis has been discussed with NXP as an interested party from within the consortium.
Some activities that were performed beyond the original description of work are:
• Presentation of the project at various venues: a workshop organized by Connekt (the Dutch ITS National) and a workshop at the Intertraffic event in Amsterdam in March 2010.
• Interviews with Connekt, NXP and Technolution regarding their view and expectations towards the testbed.
• Two published and presented papers (one together with DLR) at ITS Europe 2011:
o Jonkers, van Noort, de Kievit, Berkers, Integrated assessment of societal impacts of intelligent transport systems in the ITS Test Beds project, ITS Europe, Lyon, 2011
o Beckmann, van Noort, Integrated architecture for the assessment of ITS in a test bed, ITS Europe, Lyon, 2011
• Two published and presented papers at the ITSC Conference in Washington DC,
o van Noort, Jonkers, van den Haak, Ouboter, Scaling up impact assessment results through statistics and simulation, ITSC, Washington DC, 2011
o Jonkers, van Noort, van der Veen, Parking guidance – modelling, simulation and impact assessment, ITSC, Washington DC, 2011
• A published and presented paper (in Dutch) at the Dutch congress on traffic theory (verkeerskundecongres)
o Jonkers, de Kievit, van Noort, Opschaling – van impact assessment naar kosten-batenanalyse, Verkeerskundecongres, 2010.
Task 3.2.2 Simulation: the traffic simulation tool ITS Modeller was used to assess the impacts of the selected systems on efficiency, safety and/or environment. The simulation tool has been described, and a functional description of the three systems has been created. For each system, an experimental setup was developed that describes the goals of the analysis and the way in which the analysis was to be performed. Simulations have been performed for two of the three systems. A deliverable containing these elements was authored.
The traffic simulation tool ITS Modeller has been used to assess the impacts of the selected systems (road pricing, smart parking and speed alert) on efficiency, safety and/or environment. This task has produced as final result a public deliverable (DL 3.2.1) describing the simulation tool, the three systems, the experimental setup, the simulations and the analysis and results.
Task 3.2.3 Cost benefit analysis: a methodological framework has been created for the cost benefit analysis. The framework builds on various previous projects such as HEATCO, REFIT, eIMPACT and FESTA. Furthermore a stakeholder analysis was performed to describe stakeholder roles and interests. A preliminary cost benefit analysis was performed for one of the applications. A deliverable containing these elements was authored.
Task 3.2.4 Business modeling: in the Business Blueprint methodology used in this project, business modeling comprises the four aspects of Services, Organization, Technology and Finance, and the relations and dependencies between these aspects. A methodological framework for the definition of ITS business models has been set-up based on the Business Blueprint methodology. The three selected systems have been described from a service oriented viewpoint. An analysis of the technological and organizational aspects was done. A deliverable containing these elements has been created.
6 WP 3.3: Technical developments - Wireless roadside and on-board communications
6.1 WP 3.3.1: Specify and develop modules for the Pilot Vehicle Unit
The hardware and software architecture of the current and next generation in-vehicle unit was described in detail. The next generation of the unit includes only two modules. The roof-top antenna contains all the routing functions, while the applications runs on a small touch computer located on the dashboard within the vehicle. The two units are connected through an Ethernet cable.
The two applications Intelligent Speed Adaptation and Incident Hazard Warning were implemented on the CVIS platform. The applications were demonstrated with simulated input data as well as at ITS test sites using data received from data bases via road side units or via the 2G/3G network.
All applications follow the key architectural concept for CVIS, using the service oriented OSGi framework. Special adaptation was done in order to use data from local data bases. Interoperability with other test sites was obtained through the use of common well-defined interfaces.

Figure: 7. ITS Test Beds Community Portal Screenshot
The applications have access to high accuracy GPS coordinates using the navigation feature in CVIS, called POMA. Position data was used to extract data from the TRIP (Transport Related Information Platform) developed by the Norwegian Research Council project WiseCar.
7 WP3.3 Task 3 - Positioning
Work performed under task 3 of WP3.3 concentrated on design and accuracy assessment of a positioning system built of low-cost, consumer-grade sensors independent of the navigation sensors on-board the vehicle. The objective was to design, build and test such a low-cost positioning system and, if required, investigate the methods to improve its performance, with the general idea being that when the prototype is capable to provide the required accuracy for the ITS applications it can be integrated into the PVU.
First, a study of the available positioning technologies was performed to be used as a basis for sensor selection. The following sensors/technologies were considered:
GNSS
• High-sensitivity GPS
• Multi-constellation GNSS (GPS/GLONASS).
Inertial sensor types and combinations
• Full IMU (3-axis gyro, 3-axis accelerometer)
• Reduced IMU (vertical gyro, 3-axis accelerometer)
• Full IMU (3-axis gyro, 3-axis accelerometer) used in a combination with a 3-axis magnetometer.
To assess the accuracy and the ability to provide continuous positioning service, a number of tests in different operating environments (open sky areas, semi-urban and urban areas) have been performed in Trondheim, Norway, using different GNSS receivers (HSGPS LEA-5T receiver from ublox and an AsteRx2i GPS/GLONASS receiver from Septentrio). The choice of the inertial sensor configuration was performed based on an extensive literature review. Based on the analysis of the test results and the state-of-the-art of the MEMS sensors used for positioning, it has been concluded to use a combination of a HSGPS receiver and a full (3-axis gyro, 3-axis accelerometer) IMU.
As a next step, a hardware prototype consisting of a HSGPS receiver and a full low-cost MEMS IMU was built by Q-Free (Figure: 8), whereas several sensor integration algorithms have been implemented in MATLAB and evaluated by SINTEF.
For the prototype implementation, it has been chosen to integrate the HSGPS and the IMU using a closed-loop loosely-coupled integration strategy. To improve the integrated system performance an algorithm based on vehicle motion constraints was implemented to reduce the growth of the inertial sensor errors during the periods when the HSGPS receiver is not capable to provide a position fix.
Finally, the designed positioning system was tested and the implemented sensor integration software verified by performing two field tests in downtown of Oslo, Norway, considering different environment scenarios: open sky and urban area including sections with tunnels.
Test results have shown that the integrated HSGPS/MEMS IMU system was clearly outperforming HSGPS in a stand-alone mode both in terms of accuracy and continuity of positioning. However, the achieved positioning accuracy was considered to be not sufficient for the integrated system to be used in its current implementation as a part of the PVU. It was concluded that it was necessary to either support the system by using other auxiliary sensors or implement a more advanced sensor fusion algorithm.
The feasibility of using a reduced IMU (vertical gyro, 3-axis accelerometer) was also tested by using the so-called pseudo-signal approach implying replacing the unavailable IMU sensors (the horizontal gyros) by pseudo signals that have constant values (zeros plus white noise). Due to a more rapid IMU sensor error accumulation, results obtained by using this system configuration were less accurate than the ones obtained using a full IMU. Thus, the same conclusion was drawn, stating that the accuracy achieved by using a positioning system consisting of HSGPS receiver integrated with a reduced IMU is not sufficient.

Figure: 8. The Incident and Hazard warning application shown in the driving simulator
From the studies performed during D3.3.3 it has been observed that the accuracy of the final positioning solution provided by the integrated HSGPS/MEMS IMU system strongly depends on the accuracy of the velocity estimates obtained from the HSGPS receiver. To be more specific, these measurements are used not only to update the IMU, but also to determine vehicle's heading. Therefore, it was desirable to improve the accuracy of the velocity information provided by the HSGPS receiver. In GNSS receivers, velocity of the user is estimated by using Doppler observables. As a part of the performed study, a theoretical model of the Doppler frequency jitter in hardware HSGPS receivers was derived. An article "An Approach to Improving the Accuracy of the GNSS-derived Velocity", discussing the approach was submitted and presented at the European Navigation Conference (ENC) 2012.
WP3.3 Task 4 HMI for the PVU
SINTE,F in cooperation with DLR, developed software and procedures for linking the driving simulator in Trondheim, and the PVU with DLR's CODAR Viewer in real-time, which was demonstrated in real-life during one of the dissemination meetings. This activity proved the interoperability mechanisms provided from TASC (Test Aggregation Service Center).
7.1 WP 3.3.2: Development PHY simulation model and optimization of signal processing algorithms
For WP3.3.2 following activities were carried out, in line with the description of work:
IMEC created a complete (IEEE802.11p) simulation environment, including:
o a time-varying channel, based on real-time measurement campaign, proposed in this work package
o OFDM modulation
o front-end non-idealities
An initial challenge was that most real time measurement studies do not publish usable parameters to derive a Matlab channel model. The work of Sen and Matolak of 2008 provides such data, for several channel conditions, and is used as a basis to model representative vehicular conditions.
A block diagram of the resulting model is shown below, and documented in the D3.3.4 report.

Figure: 9. Block diagram of the IMEC IEEE802.11p Matlab model
In a next step the IMEC IEEE802.11p Matlab model was used to investigate signal processing enhancements, in line with the description of work.
Conventional OFDM (à la 11a/g) was designed for static environments and re-used for 802.11p. In mobile environments, Doppler spread causes significant inter-carrier interference (ICI)
ICI creates BER degradation, and channel estimation is also degraded by ICI
Therefore IMEC developed specific algorithms for 802.11p in order to:
o “robustify” the channel estimation
o cancel the ICI and improve the BER performance
o Track the channel and synchronization offsets by means of the pilot sub-carriers
The simulation model, including a channel model for time-varying channels is used to support the algorithmic development and evaluate their performances (BER, PER, preamble detection/mis-detection probability, …)
The simulations confirm that a conventional IEEE802.11p signal processing results in poor packet error rates due to inter carrier interference and variation of the channel due to higher mobility. The proposed improvements remedy these shortcomings to a large extent, resulting in improved performance over the entire communication range.

Figure: 10. Evaluation of the IMEC signal processing improvements (blue) versus a conventional signal processing (red). Thanks to improved signal tracking functionality the receiver is less prone to error flooring, also at elevated speeds.
The WP3.3.2 activities were finalized with following results:
• An update of D3.3.4 “IEEE 802.11p simulation model”, taking into account feedback of the mid project review.
• Completion of D3.3.5 “Report on IEEE802.11p algorithmic solutions”. This task provided the key functionality needed for WP3.3.3 .
7.2 WP 3.3.3: Mapping of the proposed algorithms on IMEC’s wireless test bed
In WP3.3.3 the proposed algorithmic enhancements was mapped on IMEC’s wireless testbed, which consists out of a software defined radio prototype. Preparing activities took place first to map the algorithms onto this platform. To start a IEEE802.11p conventional tracking scheme was ported to the software defined radio part. Algorithmic enhancements were mapped onto the platform after task 3.3.2 was finalized.

Figure: 11. Component overview of IMEC's software defined radio
The signal processing enhancements of WP 3.3.2 were evaluated on a Software Defined Radio-based platform. This was done by extending an existing IEEE802.11a physical layer with the proposed tracking and multiple antenna processing enhancements. We found that more advanced processing nearly doubles the processing load, and quadruples in case of optimal multiple antenna reception. Since the bandwidth of IEEE802.11p is lower than for IEEE802.11a extra margin is available in the receiver to handle such modes real-time. These results were reported more in depth in D3.3.6 “report on IEEE 802.11p algorithms mapped on the wireless test-bed”.

Figure: 12. Block Processing vs. peak computational load
7.3 WP 3.3.4: ATOP
Already before the project, NXP Semiconductors started to develop the ATOP-chip, which is an integration of GPRS, GPS and secure memory, supporting Intelligent Transport System applications such as road tolling, eCall, Pay-as-you-drive, etc.
In the SRE (Samenwerkingsverband Regio Eindhoven – cooperation-platform region Eindhoven) the ATOP was in its first versions trialed out and demonstrated to be a mature and fruitful concept.
Figure: 13. The ATOP-based On-Board unit
For this trial, the first ATOP-chips were integrated in On-Board units and with the support from partner /subcontractor Magicview, and an end user application was developed.
The SRE-trial helped out NXP Semiconductors to further develop and improve the functions and quality of the concept as well as supporting and helping conceptual discussions with Dutch governmental authorities to set out guidelines on road tolling.
Through the Flemish NextGenITS project the ATOP-platform was further analyzed to define legal, privacy and security implications when integrating multiple applications on a single chip on board unit. Also first investigations were executed on the business model around on-board units being used to run a mix of governmentally mandated and commercially pushed applications.
The ITS test beds project further worked on these results and mainly generated the service software stacks, the support for dedicated advanced ITS applications and service deployment. The project generated the necessary reference designs (HW and SW) and worked on the integration of services. This resulted in a show case-proof of concept, on the axis Brussels-Leuven, where for the first time , and as a world primeur, an integrated ITS secure service environment was exposed combining roadpricing, ecall and networked car2 car secure information services. In cooperation with the Leuven city government, several mobility research activities were executed making use of road tolling and other applications on the ATOP-platform. The Test Aggregation service center and other concepts and components were used during the trial. Also eCall-application and potentially parking applications were trialed out.
The NXP contribution to ITS test beds also included the extension to new services that need broadband connectivity, especially targeted to Far East Markets. A first prototype was first made available on lab scale and then further deployed in test beds starting in Q4 2010.

Figure: 14. The ATOP
In cooperation with a special eCall working group, NXP Semiconductors and ITS Belgium discussed the certification of eCall products conform the European guidelines for eCall. These certification-steps were in line with the initial intentions of the ITS Test Beds project.
During the second period of the project, NXP Semiconductors continued the development and validation of the ATOP chip, finalizing developments that were done during the first period and especially validating that the implementation is ready to use in actual field trials.
A second key emphasis was on further development and validation of a re-usable reference design application and development kit that is now available as a standard product from NXP (via resellers) at per-unit costs that are very affordable to SMEs for their own, stand-alone products and projects. This allows SMEs to greatly save on hardware development cost prior to launching an ITS product or participating in a field trial. To date, almost 2000 Telebox boards have been produced, most of which were distributed to numerous companies – mostly SMEs – and to researchers involved in ITS projects.
Finally, driven by demand from ATOP users, NXP performed a short mini-study to investigate the possibility of extending the ATOP platform with a future pin-compatible 3G version. This enables companies – especially resource-constrained SMEs – to easily select a platform version that matches their actual ITS Test Bed needs and – even more interesting –to change the underlying platform – be it to increase performance or to reduce OBU cost – in function of the outcome of a ITS Test Bed without having to re-engineer their entire solution.
7.3.1 Field trials
As a follow up on the Brussels-Leuven show case reported on in the previous section, a long- term ATOP-based trial involving members of the general public was set up in the city of Leuven, in which the ATOP reference design developed by the project was used. In this trial several mobility research activities have been executed. This trial was a first roll-out step of the ITS Test Beds project.
In November 2010, NXP, together with partner companies, conducted a high profile pan-European trial of e-Call technologies implemented on top of ATOP and its Telebox reference design. The event was kicked off on the Electronics 2010 conference in Munich on November 10 with three cars starting from Madrid, Athens, and Helsinki. All cars then drove to Brussels, where the closing event of the EU eSafety Forum was held on November 25, 2010.
During the 16.000 kilometre journey through sixteen different EU countries, the ATOP-based telematics boxes sent out 15.000 e-Calls. The trial conclusively showed that e-Call is not dependent on the present standards used; that it functions reliably across all European borders; the telematics solution is compatible with given EU e-Call standards and that the EU's objective to have e-Call deployed in all cars in Europe as soon as possible is indeed realistic.
The EU drives solutions based on an in-band modem. During this trial, the in-band modem implementation developed on ATOP during the first reporting period was used to great success.

8 WP4: Demonstrations
This work package started after M18.
For WP4.2 TNO already however performed this task at an earlier stage: For the M20 deliverable, the TNO tool chain including the ITS Modeller was presented to the consortium at a consortium meeting in Delft in 2009. It was also described in a tool chain document in April 2009 and distributed to the consortium. For the M27 deliverable, this was expanded further with the results of the simulations.
As a part of WP4, DLR has successfully presented the integration of the CODAR Viewer, a tool for visualization and monitoring of field tests, into the ITS TestBeds architecture. On a Training Session in Trondheim in May 2011 the CODAR Viewer was used to monitor SINTEF’s ITS applications, namely Intelligent Speed Adaptation (ISA) and Incident Hazard Warning (IHW). By connecting the Viewer to the Test Aggregation Service Centre (TASC) the trial running in Trondheim could be followed from any location. On the CODAR Viewer the test vehicles and their parameters could be tracked and the tester could see when ISA or IHW warnings were given to the driver. D4.1 describes the integration of the tools in detail.
TNO has created a public deliverable (DL 4.2) demonstrating the ITS Modeller simulation tool that was used in work package 3.2. The deliverable describes how the tool was used to simulate the smart parking ITS system, and illustrates this with several images. An accompanying presentation containing some movies was made available on the ITS test beds website.
The HMI applications developed in WP 4 has been demonstrated at several occasions, the most important one being the ITS Test Beds training session in Trondheim in May 2011. During this session one of the applications developed was demonstrated in the driving simulator for the participants. The application showcased was Incident and Hazard Warning as shown in Figure: 15.

Figure: 15. The Incident and Hazard warning application shown in the driving simulator
This demonstration also showed the integration between SINTEF's CVIS-based cooperative infrastructure and Codar Viewer developed by DLR. The integration was done using TASC and data can be viewed in real-time using TASC's message queue feature, or historically using the TASC database system.
In addition to this demonstration, a movie showing the HMI applications (both Incident and Hazard Warning and Intelligent Speed Adaptation in use in the CVIS-equipped Pilot Vehicle Unit on the road network as well as in the simulator) was made. The film was shot and edited at SINTEF. The film has been shown on several occasions, for example at the Norwegian ITS conference. The movie can be found on Youtube, on the following URL: http://www.youtube.com/user/itstestbeds#p/a/u/0/5IKj2XiTv6A.

Figure: 16. The software-defined radio
The software-defined radio mapping of the IEEE802.11p enhancements was integrated in a demonstration by IMEC. The main results were summarized in D4.3.1.

9 WP5: Other activities
For the dissemination activities, a plan was created to elaborate on the activities in a structured way.
The internal dissemination took a start with sharing and demonstrating each other’s infrastructures and tools during Workshops and General Assembly meetings. The summary of this is reported in DEL 5.1 Training material.
A Brochure was designed, made electronically available and samples were printed for all partners. Upon this, several partners wanted to order more printed version and at ITS Belgium, a batch print was planned.
Besides this, and executed on top of the proposal, the creation of a product catalogue was initiated in which all partner’s components were shortly described. This gives a good view to other parties on which components are available from the ITS Test Bed.
An online collaboration-tool was developed and demonstrated to the partners which has led to several fruitful user interface and usability discussions. It has become a dedicated desktop with applications and was populated with components from the different partners in the project.
The online-collaboration tool proved to be a living and continuously-changing application. The actual deliverable D5.3 On-line collaboration tool (M6) was exactly meant to set this up and thus delivered.
Part of the work in WP5 is to create a forum of discussions. In practice, this was set up by bilateral contacts between partners in the project and their affiliates. Several subjects were brought on the table in this constellation. The expectations on both the project and the actual testbed were collected through several interviews executed by ITS Belgium and TNO. These were used as input to create DEL 2.1 the specification of the ITS Test Bed.
Initial versions of DEL2.1 have been shared with partners and feedback was received.
During plenary meetings, several demonstrations were given to the partners to discuss functionality and expectations of the online collaboration tool and the top architecture.
The project has the policy to rotate locations for the plenary meetings to enable the different partners to demonstrate their local infrastructure and equipment, which is very useful in the definition of the testbed and operates as a discussion-forum in itself to align the thoughts of the partners.
Besides the above mentioned activities, several partners visited different events on the subject of ITS test beds and shares their findings during conference calls and plenary meetings. One of the general assembly meetings was actually organized at the ITS World Congress in Stockholm. But also visits to the FOTNET-meetings, CVIS closing event, NextGenITS closing event, Intertraffic and many other congresses and events contribute to the dissemination of ITS Test Beds.
This work-package therefore contributed different results:
o Training
o Dissemination of results
o Knowledge management and IPR protection
o Exploitation plans
The training and dissemination activities were combined in one mainstream activity.
9.1 Training and dissemination
Coordinated by the project manager, all partners created sets of slides to explain their component towards all potentially-interested persons. In this way, the presentations formed, after an introduction of the concept and framework, extensive descriptions of all components connected to the ITS Test Bed.
For each of the components the presentation described the component, explained the added- value it can bring during execution of ITS-related tests and indicated how/to which conditions the component could be used by others.

Figure: 17. Top view of the training material and structure of the ITS Test Bed
Facilitated by the ITS-nationals, several sessions were organized where this training package was given. These sessions are listed below. This process was very fruitful as the project managed to reach over a hundred contacts in the market who are specifically dealing with testing ITS-components or applications. The training presentation (incl. some movies) are available on the ITS Test Beds website.
The training sessions were always including a live demonstration of DLR’s CODAR-viewer, integrated to ITS Test Beds with the live Testsite of Trondheim, through the ITS Test Beds portal/TASC. This is a very visual demonstration and is, besides a proof of the feasibility, also giving a practical example of where the concept of ITS Test Beds materialized in immediate benefit.
DEL 5.4 Knowledge management and IPR protection was created.
Through D5.5 Exploiting ITS TEST BEDS results, a lot of work was done on the setup of a non-for-profit organization. The non-profit-organization has been put to live on June 15th, 2009 and is named Telematics INCubator (TINC). Through amendment 1 of the project, the newly created organization has become partner in the project and several activities have been shifted from IBBT to TINC, as planned during the setup of the project.
Already in the first period of the project, the IPR and knowledge management document was initiated as Deliverable 5.4. The creation of the document generated useful discussions between project partners on making available components to other organizations and companies. Two major obstacles were observed during this exercise:
1. Research organizations are not yet in a full mode of making license conditions for their components to others. It is somewhat easier for smaller research organizations to come up with licensing conditions than for the larger organizations. Although the project initiated the discussions, several research organizations did not yet manage to describe their licensing conditions.
2. In the time of generating the proposal for this project, it was assumed that components could easily be made available to others. During the discussions and elaborations as part of the project, it was detected that the experts are a crucial key in the operation of these tools. For instance: it is not straightforward for a technical researcher or engineer in a company to use the business modeler tools from TNO, as one really needs the expertise and knowledge to operate the tools. Likewise, it is not straight forward for an integrator in a company to use the software-defined radio as, also here, specific expertise is mandatory to be able to properly run the tools and interpret the results.
It is good to note, and a worthy result of the project, that the pressure of the companies and ITS-Nationals caused the (start of the) creation of these licensing models.
The IPR-document generated is a good start and can only be completed when more interaction between potential customers and research organizations is happening on the licensing and use of the components. This interaction will help the research organizations in concentrating the elaboration of licensing models according to their customer’s needs.
9.2 Exploitation Plans
Already at an early stage of the project, the exploitation of ITS Test Beds was realized by the creation of TINC, a new RTD focusing on the exploitation of the ITS Test Beds framework and portal. The organization was formed as a non-for-profit organization with formal statutes. These statutes were considered as the first version of the exploitation plan.
The strategic vision of operation of these kind of organizations were laid down by TINC as an example to the others and then discussed between partners resulting in several updates of the document. For different (types of) organizations, the exploitation plans typically have different strategic viewpoints. The vision described is those of the ITS-Nationals and SMEs who are represented in the project. The document was then finalized by the author.

Potential Impact:
1 Socio-economic impact
Below, the most important roles in the ITS ecosystem are described, and some examples are given of the companies that are assuming these roles. Together, they make it possible that users subscribe to new services and applications as they become available (pull model) or that updates of applications and services are deployed to handsets and in-vehicle systems (as well as to roadside units) in the background when needed (push model) - much as is the case on the fixed Internet today. As all interfaces in this architecture are being standardised, any organisation that can add value to the ecosystem - also and particularly SMEs - will be able to play a role on this market.
Figure: 18. The ITS ecosystem (1)
At the highest level a distinction can be made between “content centres”, “service centres” and providers of “client systems” or devices. A Service Centre is an abstract entity representing the back-end parts of a distributed service. It is here that any of the services mentioned before are supported. A Client System is the system hardware & software that hosts services on the handset or within the vehicle (this entity includes I/O devices and the telematics control unit).
The “feedback loop” between client systems and content centres in the above figure is of key importance. This is true as the large quantity and high quality of data that will automatically be fed back from devices to content centres are an important factor in the development of the telematics market. This data is also known as “floating (vehicle) data”. An example of floating car data is (anonimised) travel time data from “intersection to intersection”, that allows an accurate estimation of travel times, enabling many new services such as individualised route guidance.
Examples of content centres are the data centres operated by Assistance organisations (such as ANWB or ADAC), public traffic centres, the Police, telecom operators such as France Télécom or Vodafone (floating car data based on traffic generated on their networks), fleet operators (floating car data based on freight and fleet management systems), makers of digital maps (Navteq, Tele Atlas), etc. Examples of service centres are “freight and fleet management” companies (Transics, Punch), navigation providers (TomTom, ViaMichelin), roadside assistance providers (Touring ANWB or ADAC), leasing companies (such as Athlon and Leaseplan), insurance companies (Allianz, AG Insurance, Corona Direct ...) public authorities (acting, for instance, as a provider of traffic information), etc. Examples of producers of client systems are the makers of PNDs (Personal Navigation Devices such as TomTom, Mio, Garmin), integrated navigation systems, smartphones, “on-board units for freight and fleet management” etc. Apart from this, a wide range of companies are technology providers to this ecosystem (such as NXP, Alcatel-Lucent, Siemens, IBM, Thales, Logica CMG, Septentrio … - in fact, we consider almost all technology providers within the national ITS organisations as suppliers of this ecosystem, and therefore as potential partners and in test beds).
Looking more closely the ecosystem is more complex, with more actors playing a role in it such as “content aggregators” and “service aggregators”. A Content Aggregator combines content from different sources. An example of such a new player is the company Be-Mobile that has successfully positioned itself as one of the first data aggregators (of dynamic content) in Belgium. A Service Aggregator combines services therefore possessing a collection of functionalities of a system management nature (examples are a billing centre, user subscriptions, authentication and authorisation, and client system remote management).

Figure: 19. The ITS ecosystem (2)
The figure below extends the ecosystem even more and also refers to the banking sector as well as certificate authorities. A Payment Centre is an entity that provides a generic access to various payment services.
Figure: 20. The ITS ecosystem (3)

2 Wider societal implications of project so far
In the same timeframe (2010) that vehicle-kilometres are expected to increase by some 26% and goods transport by some 38%, Europe has set itself ambitious targets in terms of safety (-50% fatalities as compared to 2001), congestion (-20% as compared to 2000) and the environment (C02 emissions 30% lower than 1990 levels by 2020). The ITS Test Beds project contributes to the realisation of ITS services that have an important impact on these targets - safety, congestion, and the environment. It will however take a number of years before these services – such as eCall and road charging – are fully deployed and their implications will become fully visible.
3 Main dissemination and training activities
As chapter 1.3.9.1 Final publishable summary report explains, the training and dissemination activities were captured as a separate task with specific deliverables.
Also the different training sessions are explained and listed up in 2 Use and dissemination of foreground .
4 Exploitation of results
The ITS Test Beds project set-out on the ambitious task to investigate, document and develop test infrastructure that can help accelerate the deployment of telematics services within EU Member States. Thanks to huge efforts made in the project, not only a common architecture but also common test infrastructure has been developed, that allows to support almost any ITS-related test activity, and it has been successfully applied to a number of use cases. Apart from the technical viability of the approach the financial viability has been investigated as well, and first projects using the results of the ITS Test Beds project have been started.
An important element in the take-up of ITS Test Beds results is the need to support the development of licensing and certification, for which testing is essential.
The figure below summarises European and national developments towards the conclusion of licensing agreements:
• At the European level, standards have been developed and legislation has been introduced that obliges Member States to open-up roles to the private sector
• This legislation is being translated into national (and regional) legislation, at which stage Member States often refer to the need to develop license models that will govern the public-private interaction
• These license models are then developed and fine-tuned to each major domain in mobility.
All steps above strengthen the need for test beds that have a capability to check compliance with the developed license models.

Figure: 21. Model license agreements
The next figure shows more in detail how a private service centre can obtain access to public content via licensing and certification:
• A service centre requests certification to show that it can comply with the license model developed by a content centre
• A certification provider, typically appointed by a national ITS organisation (or the ITS organisation itself), carries out the needed tests; if passed, the content centre is requested to approve access to its data
• If this approval is given, the certificate is forwarded to the service centre which can start accessing the data involved.

List of Websites:
It was http://www.itstestbeds.org but has been removed

Final Report Summary - ITS TEST BEDS (Common building blocks for ITS test beds and field operational tests)

Verwandte Dokumente

Diese Seite teilen

Herunterladen