Project acronym: oversee project title: Open Vehicular Secure Platform

Project acronym: OVERSEE

Project title: Open Vehicular Secure Platform

Project ID: 248333

Call ID: FP7-ICT-2009-4

Programme: 7th Framework Programme for Research and Technological Development

Objective: ICT-2009.6.1: ICT for Safety and Energy Efficiency in Mobility

Contract type: Collaborative project

Duration: 01-01-2010 to 30-06-2012 (30 months)
Deliverable D6.2:


Authors: Rafael Grote (TU Berlin)
Florian Friederici (Fraunhofer FOKUS)
Martin Förster (Volkswagen)
Jens Zech (TU Berlin)
Jan Holle (Uni Siegen)
Salva Peiró (UPVLC)
Jordi Sánchez (UPVLC)
Nicholas McGuire (OpenTech)

Reviewers: Martin Förster (Volkswagen)

Dissemination level: Public (The final document is public; this draft is restricted to the OVERSEE consortium, advisory board and reviewers.)

Deliverable type: Report

Version: 0.9 Draft

Submission date: 13 February 2012

Prototype Demonstration

Abstract

It contains a comprehensive description of the different demonstration elements. Those are, the in-vehicle demonstrator, the model-car testbed and the platform demonstration setup. All of those were carefully selected during the project progress; to show the most important OVERSEE key features based on possible OVERSEE applications.

The final version of this document will also include a report on the demonstration event.

Contents

List of Figures

List of Tables

List of Abbreviations

CAN Controller–area Network

eCall Emergency Call

GNU GNU's not UNIX

GPIO General Purpose Input/Output

GPS Global Positioning System

HMI Human Machine Interface

HW Hardware

I/O Input Output

IP Internet Protocol

IR Infrared

ITS Intelligent Transportation System

JRE Java Runtime Environment

LED Light-emitting diode

MILS Multiple Independent Levels of Security and Safety

NIC Network Interface Card

OS Operating System

OSEK Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug

OVERSEE Open Vehicular Secure Platform

PoC Proof of Concept

SLAP SLAP is a lightweight asynchronous Protocol

SMS Short Message Service

UDP User Datagram Protocol

USB Universal Serial Bus

V2V Vehicle-to-Vehicle

V2X Vehicle-to-X

Document History

1Introduction

The audience of this document is on the one hand the OVERSEE Consortium with the intention to synchronize and harmonize our demonstration ideas and setups. On the other hand, it is primarily directed to the OVERSEE Advisory Board and the project reviewers, to give them a deeper insight to our demonstration plans. Our main goal for writing this document is to get feedback and advices to improve the final demonstration.

1.1Outline

Chapter 2 contains the description of the in-vehicle demonstration setup.

Chapter 3 contains the description of the model-car testbed setup.

Chapter 4 contains the description of the platform feature setup.

Finally, Chapter 5 contains a report on the demonstration event.

1.2General Procedure

1.2.1Proof-of-Concept Use Cases and Prototype Platforms

The demonstration includes three classes of uses cases, which are presented on different prototype platforms and emphasize particular aspects of the OVERSEE platform. In the following, all prototype platforms are briefly described. Table 1 shows a complete overview of all demonstration use cases and their assigned prototype platforms.

Near-term ITS use cases demonstrated in real cars. Volkswagen will provide a real car that is equipped with an OVERSEE platform and an additional car that is equipped with an OVERSEE-compatible communication stack.

Long-term ITS use cases that cannot safely be demonstrated on real cars are shown on the model car platform. The model car setting will provide a 1:18 scaled down version of real cars, where the physical properties are appropriately modelled to show reactions of the vehicle based on input from the OVERSEE platform. In particular, communication based safety applications or autonomous driving applications will be of interest in this setting.

Platform-related use cases that show the particular aspects of the OVERSEE platform are demonstrated on the bare (stand-alone) platform.

Table 1 gives a complete overview of use case types, demonstration showcases and their assigned prototype platforms. The chapters 2, , and 4 introduce the showcases and prototype platforms in detail. Even more detailed descriptions (from a technical perspective) are found in the Deliverable D5.1 [1] and D5.2 [2] for the use cases and D6.1 [3] for the prototype platforms.

Use-case type	Prototype platform	Showcase
Near-tem	Real car prototype	eCall
		Approaching Emergency Vehicle Warning
Long-term	Model car prototype	Active Brake
		Platooning
Platform-related	Stand-alone prototypes	Infotainment (USB media access)
		Isolation
		Real-time (OSEK)

Table 1: Overview of demonstration highlights

1.2.2Agenda and Organisation

The use cases of each class are presented together, so that the demonstration event will consist of three parts:

1. 
   The in-car demonstration, which will take place outside.
   
2. 
   The long-term ITS use case demonstration, which is presented with model cars at a suitable location.
   
3. 
   The platform-related use case demonstration, which is shown on stand-alone platforms and includes three separate setups.
   

Since some of the demonstrations are restricted in the number of spectators, all use cases will be shown in parallel to small groups. After each presentation, the groups should rotate to watch the next demo. Table 2 lists a preliminary time schedule.

1.3Event Location and Dates

The final demonstration event will be located on the premises of Volkswagen at Wolfsburg. The outdoor demonstration of the in-car use cases will take place on the MobileLifeCampus.

Originally, the final demonstration was scheduled for June 2012, but due to the (pending) project extension, it will most probable take place either in the last week of September or in the first week of October 2012. It will be a one-day event.

Time	Agenda item	Presenter/Responsible
9:00	Registration and coffee	Volkswagen
10:00	Introduction and Welcome	escrypt
10:30	Demonstration slot 1 (all demos in parallel)	Volkswagen (real cars) TUB, FOKUS (model cars) UPV, UniSiegen, OpenTech (platform)
12:00	Lunch break
13:00	Demonstration slot 2 (all demos in parallel)	Volkswagen (real cars) TUB, FOKUS (model cars) UPV, UniSiegen, OpenTech (platform)
14:30	Coffee break
15:00	Demonstration slot 3 (all demos in parallel)	Volkswagen (real cars) TUB, FOKUS (model cars) UPV, UniSiegen, OpenTech (platform)
16:30	Conclusion and discussion	escrypt

Table 2: Preliminary time schedule

2Demonstration of Near-term Use Cases

2.1Prototype Setup

The OVERSEE platform that is developed within the project will be integrated in a research vehicle to demonstrate near-term use cases, in particular eCall and Emergency Vehicle Warning.

To demonstrate these use cases within realistic driving scenarios the research vehicle is extended by several components that care about safe vehicle data access, external communication capabilities and human machine interfaces.

Safe vehicle data access is ensured through an additional physical gateway that only forwards use case relevant CAN messages to the OVERSEE platform. Any access to this domain does not influence the original vehicle systems.

The vehicle antenna is extended by 802.11p capabilities and in combination with a dedicated communication hardware the OVERSEE platform gets access to cellular and ad-hoc networks.

The human machine interfaces of the research vehicle, in particular the display of the instrument cluster and the display and controls of the radio navigation system, are extended by additional hardware to utilize them for the OVERSEE platform.
[Image TBD]

2.2eCall Showcase

2.2.1Use Case Description

The use case eCall running in one isolated domain of the OVERSEE platform generates a driver triggered emergency call. All information according to European Standard EN 15722 [5] are transmitted via SMS and represented on the OVERSEE’s human machine interface. The eCall data are received by a mobile device that symbolises the emergency operations centre. To lay emphasise on this prototypical implementation, eCall is triggered by the driver through a button within the showcase.

The eCall is triggered right after a third party application, running in a different domain of the OVERSEE platform, is crashed deliberately. This demonstrates that the OVERSEE platform has the capability to isolate highly reliable and highly available functions.

[Image TBD]

2.2.2Demonstration Procedure

This use case can be demonstrated either in driving or in standing vehicle conditions. The research vehicle offers space for three additional passengers. One demonstration round will take about ten minutes.

1. 
   The ignition and engine of the car is turned on
   
2. 
   A third party application of the OVERSEE platform is started through the OVERSEE’s human machine interface
   
3. 
   The third party application is crashed remotely by one passenger
   
4. 
   The eCall is triggered through the graphical user interface of the eCall application visualized on the display of the radio navigation system
   
5. 
   The eCall data is sent and visualized on the same display
   
6. 
   The eCall data is received by the mobile device
   
7. 
   Meanwhile, the partition of the OVERSEE platform that holds the third party application and the third party application itself is restarted
   

[Image TBD]

2.3Approaching Emergency Vehicle Warning Showcase

2.3.1Use Case Description

The use case Emergency Vehicle Warning running in one isolated domain of the OVERSEE platform generates a warning within the instrument cluster of the research vehicle when an emergency vehicle approaches. This warning includes the course and the distance of the approaching emergency vehicle.

Within the showcase the emergency vehicle approaches right after a third party application, running in a different domain of the OVERSEE platform, is crashed deliberately. This is nearly the same scenario described in 2.2 and lay emphasis on OVERSEE’s capabilities to isolate highly reliable and highly available functions.

[Image TBD]

2.3.2Demonstration Procedure

This use case can be demonstrated either in driving or in standing vehicle conditions. The research vehicle offers space for three additional passengers. One demonstration round will take about ten minutes.

1. 
   The ignition and engine of the car is turned on
   
2. 
   A third party application of the OVERSEE platform is started through the OVERSEE’s human machine interface
   
3. 
   The third party application is crashed remotely by one passenger
   
4. 
   The emergency vehicle starts heading toward the research vehicle and/or vice versa
   
5. 
   The warning for an approaching emergency vehicle is visualized on the display of the instrument cluster
   
6. 
   Meanwhile, the partition of the OVERSEE platform that holds the third party application and the third party application itself is restarted
   

[Image TBD]

3Demonstration of Long-term Use Cases on Model Cars

The model car demonstration involves the long-term use cases, i.e., Active Brake and Platooning. These use cases will be presented together in a joined model car demonstration. Active Brake will then affect the whole platoon (all cars will stop, if the platoon leader does).

3.1Prototype Setup

The model car setting will provide a scaled down version of real cars, where the physical properties are appropriately modelled to show reactions of the vehicle based on input from the OVERSEE platform. In particular, communication based safety applications or cooperative automated driving applications will be of interest in this particular setting. The model car prototype platform is designated to present long-term use cases, which could not be easily or safely shown in real vehicles.



Figure 1: The model car prototype

The model car demonstration requires a specific setup. The usual operating place of the model cars is indoors with the result that conventional GPS-based positioning systems are unsuitable. Also, the reduced form factor (1:18) requires a substantially higher precision compared to real-sized cars. As a solution, an indoor navigation system is utilized. It consists of a camera mounted on the ceiling above the testing area and markers on top of the model cars.

The demonstration will be shown on two or more model cars. All of them can be controlled remotely – either manually or following a predefined trace. Additionally, they have the option to drive autonomously to certain degree, depending on use- and test-case.

Figure 2: Photography of the model car demo table

3.2Active Brake Showcase

3.2.1Use Case Description

The use case Active Brake exploits V2V communications to slow down vehicles automatically in dangerous situations. It demonstrates how V2X messages may lead the vehicle to a safety reaction. Based on these messages and additional sensor values (e.g., distance sensors or radar), drivers are warned and in case of emergency their cars are actively braked to avoid a crash.

Each vehicle reacts on its own on obstacles detected by a built-in sensor. Whenever an obstacle is recognized, the vehicle stops automatically in a safe distance and broadcasts warning messages via the V2X network to other vehicles in the area. Model cars receiving the warning message indicate the reception through red lighting. Their velocity is reduced distinctly in the region of the obstacle.

3.2.2Demonstration Procedure

For demonstration, this use case can be triggered through the front IR distance sensors, which detect obstacles. The presenter could place an obstacle in in front of a model car, which would trigger an emergency brake and result in broadcasting a V2X warning message. Consequently, the following vehicles should stop, too.

The model cars are setup according to the common platform setup. Each vehicle drives along a predefined route. All involved model cars are enabled to support active brake as well as platooning.

The demonstration scenario comprises the following steps:

1. 
   The vehicles drive autonomously on the predefined routes, keeping a sufficient distance and a constant velocity.
   
2. 
   The presenter places an obstacle on the table.
   
3. 
   The first vehicle detects the obstacle based on its sensor values. It stops right ahead the obstacle and sends V2X warning messages.
   
4. 
   Oncoming vehicles will show a red light once entering the message area and will reduce their speed visibly, when closing in to the obstacle. Ultimately, they will stop autonomously in a safe distance.
   

3.3Platooning Showcase

3.3.1Use Case Description

The Platooning use case enables automated lateral and longitudinal control of a vehicle group (platoon) in order to let the vehicles travel closely one behind another in a safe manner. Driving inside a platoon promises to enhance traffic safety, to reduce fuel consumption and to better use available road space. Besides sensor values, a number of different V2X message types is used for coordination of vehicles inside a platoon.

3.3.2Demonstration Procedure

To demonstrate the Platooning use case, the leading vehicle is controlled remotely. Vehicles following this vehicle will automatically try to form a platoon by closing in on the leader vehicle. The platoon (which consists of at least one additional vehicle) follows autonomously. As an option, people from the audience could take over the remote control of the leading vehicle – giving routing instructions directly to the leader (making turns, possibly adjusting the speed).

The model cars are setup according to the common platform setup. Each vehicle is controlled manually. All involved model cars (i.e. two) are enabled to support active brake as well as platooning.

The demonstration scenario comprises the following steps:

1. 
   The model cars are controlled remotely and drive around the table.
   
2. 
   As soon as one vehicle reaches a position closely behind another vehicle, the platooning function can be activated.
   
3. 
   As vehicles negotiate the Platoon, a blue blinking light is visible.
   
4. 
   If the negotiation is successful, die follower vehicles close the gap to the leader, forming the platoon.
   
5. 
   As soon, as the platoon is established, a constant blue light will be visible to the audience, symbolizing the platoon.
   
6. 
   Instructions given to the leader vehicle will be followed by all other platooning vehicles.
   

4Demonstration of OVERSEE Platform Features

4.1Prototype Setup

Some use cases are not well suited for presentation on real or model cars. The main reasons for that issue are:

• 
  Avoiding mixing of research results with current products of some partners in public by showing them in one demonstrator, e.g., a real world vehicle with a crashing component highlighting demonstration capabilities.
  
• 
  Requirement to connect a large screen for visualization, e.g., to demonstrate a software update, or to display the system resources
  

For these use cases a third prototype platform is assembled that is not installed to any vehicle. We will prepare multiple stand-alone platforms, so that there is a separate platform for each use case, which fits its requirements perfectly.

The basic setup of the stand-alone prototype consists of a minimal OVERSEE platform (just the Kontron and I/O boards, as well as a screen), but does not comprise any peripheral components (CAN-bus, Hardware Security Module, Mobile Router). The screen may be replaced by a larger display. The software configuration should contain the complete set of OVERSEE services, even if some of them (e.g., ITS Services or Positioning Service) might not work properly due to missing peripheral hardware components. Depending on the demonstration showcase, the setup may be different.

4.2Infotainment Showcase

4.2.1Use Case Description

As indicated by the Advisory Board, one of the main features of OVERSEE should be the support for parallel execution of infotainment and ITS applications on the same platform. Current and also upcoming infotainment applications will require access to files – provided on a personal nomadic device – of the vehicle driver/user. Hence, it is one obligation of OVERSEE to allow access to these files by the installed infotainment applications, while at the same time ensuring that these access will not endanger the platform security.

The Figure 3 presents the software architecture used to demonstrate the infotainment showcase (secured access to flash drives and media player). Further information could be obtained from the setup guide [4] available with the OVERSEE documentation.

Figure 3: Software Architecture for media player and flash drive access use case

4.2.2Demonstration Procedure

During the demo event, the visitors are invited to connect either their own memory stick or a prepared memory stick containing some media files to the platform. First, it is shown that the attached memory stick could only be assigned to a partition, which is within the list of granted partitions as stated within the platform configuration (policy) file. Furthermore, the selection of the assigned partition will be done by the current vehicle driver/user. This will prevent malicious software on the memory stick from being executed in a security/privacy (from the point of view of the driver/user) sensitive runtime environment

Finally yet importantly, one of the prepared sticks should contain a malicious file, which crashes the media player and its partition. Anyway, the rest of the OVERSEE platform should provide the expected system behaviour; see the next section for more details on the demonstration of the isolation properties.

4.3Isolation Showcase

4.3.1Use Case Description

One of the main features of the OVERSEE platform is the isolation of several runtime environments, this is crucial for the OVERSEE platform, as is required by MILS (Multiple Independent Levels of Security) which is the selected architecture on which the OVERSEE platform is based.

This use case is in charge of showing the partition isolation properties of the XtratuM hypervisor, so the behaviour of one partition cannot affect the other partitions. The Partition Isolation properties enforced by the hypervisor are:

1. 
   Spatial Isolation: The spatial isolation refers to the ability to protect the memory areas of a partition from unauthorized memory accesses by others partitions.
   
2. 
   Temporal Isolation: The temporal isolation refers to the ability to protect the partitions temporal execution from the interferences cause by other partitions.
   

4.3.2Demonstration Procedure

In order to show the isolation properties, a system has been prepared with the following architecture:



Figure 4: Isolation showcase architecture

The demo is based on the use of two external observers. Each partition is assigned a GPIO pin. When a partition is scheduled, its GPIO pin will be raised. Therefore, the GPIO signals will show in run-time how the XtratuM scheduler is performing.

The second observer will be another PC connected to the serial port of the Kontron board. This way, the “monitoring station” will be able to show the logging messages thrown through the serial port.

Based on the previous setup, a program running on the controlled partition will allow the control partition to force it some memory access operations. These operations will have the following syntax:

1. 
   Operation. Read or write.
   
2. 
   Location. Memory address in hexadecimal notation.
   
3. 
   Data. In the case of a read operation, the amount of bytes to read. In the case of a write operation, a character string to write to memory.
   

Then two things can happen:

• 
  The partition is granted access to that memory. The operation succeeds and the partition dumps the contents of the accessed memory through the serial port.
  
• 
  The partition is not allowed to access the memory. This invalid access is detected by XtratuM and a Virtual Trap is delivered to the partition that attempted the invalid access.
  

When the partition is denied access to the requested memory location, the hypervisor will deliver a trap to the partition. The default trap handler will halt the partition, and this will be seen by the external observers. First, the partition will dump a message through the serial port and, second, the partition will halt itself, and this will be seen in the GPIO, as the line corresponding to that partition will stop toggling.

During the demo event, the visitors are invited to use the control partition, in an interactive way, in order to perform operations on the running system to check the isolation properties. In addition, multiple scheduling plans will be configured, and it will be possible to switch between them and track the results with the GPIO.

4.4Real-time OSEK Showcase

The goal of this showcase is to demonstrate the real-time capabilities of the OVERSEE platform. As Linux is not a real-time operating system, we selected OSEK to run our real-time proof-of-concept use case. On top of OSEK, an application for lighting control will be deployed. As a result, we are able to switch the vehicle lights on and off in real-time. The demonstration will show in particular blinking lights steered by the OSEK light control application. The blinking frequency is supposed to be absolute evenly.

4.4.1Use Case “Direction Indicators”

There is little doubt that there is a wealth (literally) of code and solutions that where build around OSEK in the automotive industry. To allow re-use of these components and the IP behind it, OVERSEE is providing a OSEK partition to effectively demonstrate the feasibility of migrating a OSEK based application to an integrated platform based on partitioning, a typical OSEK application is to be included in the OVERSEE demonstrator.


Figure 5: Architecture and configuration of the real-time platform demonstration
While the application itself may seem trivial, the intention is to demonstrate key qualities of the integrated approach:

• 
  composability
  
• 
  re-use of OSEK applications
  

The application proposed for inclusion in the OVERSEE demonstrator is a software implementation of direction indicator control. Basically, this is a timer application and some simple I/O. However, while the functional requirements seem trivial a few side conditions make this a bit more complex.

• 
  direction indication and emergency flashers share the same resource but at different priorities - these priorities must be respected
  
• 
  direction indicators can fail (broken cabling or light-bulb/LED failure) and so a monitoring functionality needs to be provided
  
• 
  the turn angle of the wheels, respectively the turning back of the wheels is an indicator for stopping direction indicators automatically
  

Thus this use-case should demonstrate that a simple function can be cleanly modularized by abstracting signal inputs to inter-domain communication primitives and thus de-coupling functions from the physical implementation, that is, it is not relevant if the failure of the lights is detected by physical circuit and signalled to the application level or if it is generated in software by some form of sensor application, essentially the integrated approach allows to provide a simple and sound implementation of direction indicator control, satisfying safety demands, under consideration of security requirements and retaining composability by de-coupling from specific implementation details.


Figure 6: Architecture of OSEK demo use case

Due to the constraint of implementing this use-case in a demonstrator setup, some of the signals that would be delivered by other units will be generated by software and delivered by a generic interdomain-communication method. Thus a simple, well isolated, and due to OSEK compliance, portable application, can be demonstrated on the OVERSEE platform.

4.4.2Demonstration Procedure

As the goal of this demonstrator is to show composability based on existing OSEK code, we propose to demonstrate it by integration of a seemingly trivial OSEK application based on abstract signal descriptions (abstracted to "ports"). The key issue of the demonstration is to show the integration process and the running OSEK instance independent of the other partitions, thus the demonstration is by integrating a simple direction indicator controller in a partition setup that included a general purpose OS (GNU/Linux) and adheres to the security concept of running all signals through a secure I/O partition. The demonstration could be run on a real car though the effort to do so seems considerable, thus we propose to run it on either a model car or a stand-alone platform.

As an OVERSEE platform outside a real car does not have all the inputs (i.e. the lever for turning on/off the direction indicator) these signals will be emulated by a user-space application that generates this signal in a user-space application (presumably on the Secure I/O partition) and sends it to the OSEK partition. Aside from resolving the issues of signals not being available on the stand-alone platform, this also shows the capabilities with respect to development and system testing to some extent.

4.4.2.1Demonstrator Setup

• 
  An OSEK partition is integrated with a time slot of 50ms/sec in the overall system, indiscriminate of the other partitions.
  
• 
  Port settings at the OSEK partition side are according to the functional specification
  
• 
  Port settings of sources/destination from the OSEK partition will be redirected to emulated sensors/actuators as needed (depending on the physical availability of actual signals).
  
• 
  The demonstration would be on a running OVERSEE system with the OSEK partition active and timer/counters could serve as monitoring for the functional correctness of the generated outputs (basically direction indicator selected and status of the same (on/off)).
  
• 
  A connection of the outputs to actual indicator lights would be ideal but it is currently not clear if this is realizable short term with the used prototype platform.
  

5Report on the Event

The demonstration event is scheduled for September/October 2012 (originally June 2012). Afterwards, a report on the event will be inserted here.

References

1. 
   OVERSEE: D5.1 PoC use case selection report. Feb 2011
   
2. 
   OVERSEE: D5.2 PoC specification report. Feb 2012
   
3. 
   OVERSEE: D6.1 Platform integration and testing. Jul 2012
   
4. 
   OVERSEE: Setup guide for USB flash drive media access and audio sharing on the OVERSEE platform. Feb 2012
   
5. 
   DIN: EN 15722, Intelligent transport systems – eSafety – eCall minimum set of data (MSD); German version EN 15722:2011. Oct 2011

   

   
   

Directory: docs -> projects -> cnect
docs -> From Warfighters to Crimefighters: The Origins of Domestic Police Militarization
docs -> Borzoi Club of America Register of Merit Program I. What is a Register Of Merit
docs -> Protecting the rights of the child in the context of migration
docs -> United Nations E/C. 12/Esp/5
docs -> 9th May 1950 the schuman declaration
docs -> Getting To Outcomes® in Services for Homeless Veterans 10 Steps for Achieving Accountability
cnect -> Version number: Version 0 Final
cnect -> Version number: Version 4 Main author
cnect -> 1 Pilot operation preparation report Version number

Download 90.3 Kb.

Share with your friends: