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: Prototype Demonstration

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) Hakan Cankaya (escrypt) 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 D6.2: Prototype Demonstration

Abstract

This document outlines the scenario for the final project demonstration event. Therefore, the prototype platforms that shall be presented and in particular the showcases are described. 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.

ii D6.2: Prototype Demonstration

Contents

Abstract...... ii Contents...... iii List of Figures...... v List of Tables...... vi List of Abbreviations...... vii Document History...... viii 1 Introduction...... 1 1.1 Outline...... 1 1.2 General Procedure...... 1 1.2.1 Proof-of-Concept Use Cases and Prototype Platforms...... 1 1.2.2 Agenda and Organisation...... 2 1.3 Event Location and Dates...... 2 2 Demonstration of Near-term Use Cases...... 4 2.1 Prototype Setup...... 4 2.2 eCall Showcase...... 4 2.2.1 Use Case Description...... 4 2.2.2 Demonstration Procedure...... 5 2.3 Approaching Emergency Vehicle Warning Showcase...... 5 2.3.1 Use Case Description...... 5 2.3.2 Demonstration Procedure...... 5 3 Demonstration of Long-term Use Cases on Model Cars...... 7 3.1 Prototype Setup...... 7 3.2 Active Brake Showcase...... 8 3.2.1 Use Case Description...... 8 3.2.2 Demonstration Procedure...... 8 3.3 Platooning Showcase...... 9 3.3.1 Use Case Description...... 9 3.3.2 Demonstration Procedure...... 9 4 Demonstration of OVERSEE Platform Features...... 11 4.1 Prototype Setup...... 11 4.2 Infotainment Showcase...... 11

iii D6.2: Prototype Demonstration

4.2.1 Use Case Description...... 11 4.2.2 Demonstration Procedure...... 12 4.3 Isolation Showcase...... 12 4.3.1 Use Case Description...... 12 4.3.2 Demonstration Procedure...... 13 4.4 Real-time OSEK Showcase...... 14 4.4.1 Use Case “Direction Indicators”...... 14 4.4.2 Demonstration Procedure...... 16 5 Report on the Event...... 18 References...... 19

iv D6.2: Prototype Demonstration

List of Figures

Figure 1: The model car prototype...... 7 Figure 2: Photography of the model car demo table...... 8 Figure 3: Software Architecture for media player and flash drive access use case...... 12 Figure 4: Isolation showcase architecture...... 13 Figure 5: Architecture and configuration of the real-time platform demonstration...... 15 Figure 6: Architecture of OSEK demo use case...... 16

v D6.2: Prototype Demonstration

List of Tables

Table 1: Overview of demonstration highlights...... 2 Table 2: Preliminary time schedule...... 3

vi D6.2: Prototype Demonstration

List of Abbreviations

ALSA Advanced Linux Sound Architecture 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

vii D6.2: Prototype Demonstration

Document History

Version Date Changes 0.1 Draft 21-10-2011 Initial version based on contributions to the Integration Plan (RG) 0.2 Draft 01-11-2011 Added introductive and general parts, improved demo description (RG) 0.3 Draft 24-01-2012 Improved outline and revised complete document (RG) 0.4 Draft 25-01-2012 Internal review and updates (FF) 0.5 Draft 01-02-2012 Added contributions from UniSiegen (JH) , TUB (JZ), and improvements (RG) 0.6 Draft 06-02-2012 Added contribution from OpenTech (NM) and refined contribution from TUB (JZ) 0.7 Draft 09-02-2012 Volkswagen contributed chapter 2 (MF) 0.8 Draft 13-02-2012 Added “part 2” of OpenTech (NM), improved the document, Abbr., Ref, etc. (RG) 0.9 Draft 13-02-2012 Added revision of UPV (JS), minor improvements (RG)

viii D6.2: Prototype Demonstration

1 Introduction

In this document, the plan for the OVERSEE final demonstration event is outlined. Each presented use case and its relation to OVERSEE is briefly introduced. Additionally, the demonstration procedure including all organizational and technical issues is described in detail. 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.1 Outline

The general procedure, including the scenario for the project presentation is described in the introduction. A brief description of the various prototype platforms is given. 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.2 General Procedure

1.2.1 Proof-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.

1 D6.2: Prototype Demonstration

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 eCall Near-tem Real car prototype Approaching Emergency Vehicle Warning Active Brake Long-term Model car prototype Platooning Infotainment (USB media access) Stand-alone Platform-related Isolation prototypes Real-time (OSEK)

Table 1: Overview of demonstration highlights

1.2.2 Agenda 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.3 Event 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 Volkswagen (real cars) Demonstration slot 1 10:30 TUB, FOKUS (model cars) (all demos in parallel) UPV, UniSiegen, OpenTech (platform) 12:00 Lunch break Volkswagen (real cars) Demonstration slot 2 13:00 TUB, FOKUS (model cars) (all demos in parallel) UPV, UniSiegen, OpenTech (platform) 14:30 Coffee break Volkswagen (real cars) Demonstration slot 3 15:00 TUB, FOKUS (model cars) (all demos in parallel) UPV, UniSiegen, OpenTech (platform) 16:30 Conclusion and discussion escrypt

Table 2: Preliminary time schedule

2 Demonstration of Near-term Use Cases

2.1 Prototype 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.2 eCall Showcase

2.2.1 Use 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.2 Demonstration 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.3 Approaching Emergency Vehicle Warning Showcase

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]

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]

3 Demonstration 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.1 Prototype 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.2 Active Brake Showcase

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.

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.3 Platooning Showcase

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.

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.

4 Demonstration of OVERSEE Platform Features

4.1 Prototype Setup

Some use cases are not well suited for presentation on real or model cars. The main reasons for that issue are: o 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. o 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.2 Infotainment Showcase

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

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.3 Isolation Showcase

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. 12 D6.2: Prototype Demonstration

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.

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

Control Spare Host Controlled Reference shell Partition XAL Partition Partition Linux XAL XAL Spare Guest Multiplan

Sampling Port XtratuM Queuing Port

Monitoring station Logical Analyzer

Serial Port GPIO

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.4 Real-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.1 Use 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

15 D6.2: Prototype Demonstration 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.

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.1 Demonstrator 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.

5 Report 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