deliverable d2.2: list of interfaces and specifications of ... · call id: fp7-ict-2009-4...

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 D2.1: List of interfaces and specifications of information flow

Authors: Jan Holle (Uni Siegen)

André Groll (Uni Siegen)

Reviewers: Hakan Cankaya (escrypt) Andreas Platschek (OpenTech)

Dissemination level: Public

Deliverable type: Report

Version: 1.5

Submission date: 3rd June 2011

D2.1: List of interfaces and specifications of information flow

ii

Abstract

This document contains the list of the selected interfaces for the OVERSEE platform and the description of the information flow in and through OVERSEE as determined within Task 2.1 and Task 2.2 of the OVERSEE project. Additionally, since this document is the first document of the overall OVERSEE design, information on the OVERSEE architecture are given, which are also used within the other design related task of the OVERSEE project.

Furthermore, the relation between the proposed OVERSEE architecture and well-known communication standards and models will be described.


iii

Contents

Abstract ............................................................................................................................. ii

Contents ........................................................................................................................... iii

List of Figures .................................................................................................................... vi

List of Tables .................................................................................................................... vii

List of Acronyms and Abbreviations ................................................................................ viii

Document History .............................................................................................................. x

1 Introduction ................................................................................................................1

1.1 Scope and objectives of the document ...................................................................... 1

1.2 Definitions .................................................................................................................. 1

1.3 Document Outline ...................................................................................................... 2

2 OVERSEE architecture ..................................................................................................3

2.1 Role model for the OVERSEE development and deployment process ...................... 3

2.1.1 OVERSEE development team ......................................................................... 3

2.1.2 Integrator ....................................................................................................... 4

2.1.3 Application developer .................................................................................... 4

2.2 Application view ......................................................................................................... 5

2.3 System view ................................................................................................................ 6

2.3.1 Placement of additional platform functionality ............................................ 6

2.3.2 Secure I/O Partition ....................................................................................... 7

2.3.3 System Partition ............................................................................................. 7

2.3.4 Security Services Partition ............................................................................. 7

2.3.5 HMI, Audio Partition ...................................................................................... 7

2.4 OVERSEE architecture seen with respect to the OSI model ...................................... 8

2.5 Mapping of the OVERSEE architecture to the ETSI standard for ITS

communications architecture ............................................................................. 10

3 OVERSEE Interfaces ................................................................................................... 11

3.1 Interfaces and devices on the physical layer ........................................................... 11

3.1.1 CAN – Controller Area Network ................................................................... 11

3.1.2 Bluetooth ..................................................................................................... 11

3.1.3 USB – Universal Serial Bus ........................................................................... 12

3.1.4 CEN DSRC – Dedicated Short Range Communication .................................. 12

3.1.5 ITS-G5 – Cooperative ITS communication in the 5.9 GHz spectrum ........... 12


iv

3.1.6 GPS – Global Positioning System ................................................................. 12

3.1.7 2G/3G Voice and data connection ............................................................... 13

3.1.8 Audio in/out ................................................................................................. 13

3.1.9 HMI – Human Machine Interface ................................................................ 13

3.1.10 HSM - Hardware Security Module ............................................................... 13

3.1.11 SMEM – Secure Memory ............................................................................. 13

3.1.12 WiFi – Wireless Fidelity ................................................................................ 13

3.1.13 List of interfaces on the physical layer ........................................................ 14

3.2 Interfaces and devices on the runtime environments layer .................................... 14

3.2.1 SVAS – Secure Vehicle Access Service ......................................................... 14

3.2.2 USB – Universal Serial Bus ........................................................................... 15

3.2.3 SecS – Security Services ............................................................................... 15

3.2.4 S-Mem – Secure Memory ............................................................................ 15

3.2.5 PoS – Positioning Service ............................................................................. 15

3.2.6 IPaC - Inter-partition communications ........................................................ 15

3.2.7 ITS – ITS communication .............................................................................. 15

3.2.8 IP – IP Connection ........................................................................................ 16

3.2.9 BT – Bluetooth ............................................................................................. 16

3.2.10 Cell – 2G/3G Voice Connection .................................................................... 16

3.2.11 HMI – Human Machine Interface ................................................................ 16

3.2.12 Audio ............................................................................................................ 16

3.2.13 Mapping of the interfaces and services on the runtime environments layers to the physical interfaces and devices ......................................................... 17

4 Information flow in and through OVERSEE ................................................................. 18

4.1 Introduction to the general communication means in XtratuM ............................. 18

4.1.1 Sampling ports / channels ........................................................................... 18

4.1.2 Queuing ports / channels ............................................................................. 19

4.1.3 Shared Memory ........................................................................................... 19

4.2 Information flow in OVERSEE ................................................................................... 19

4.2.1 Generic model of information flow ............................................................. 20

4.2.2 IP connection (IP) ......................................................................................... 21

4.2.3 Secure Vehicle Access Service (SVAS) .......................................................... 22

4.2.4 Positioning Service (PoS) .............................................................................. 23

4.2.5 Universal Serial Bus (USB) ............................................................................ 24


v

4.2.6 Security Services (SecS) ................................................................................ 25

4.2.7 Secure Memory (S-Mem) ............................................................................. 26

4.2.8 Inter-partition communications (IPaC) ........................................................ 27

4.2.9 ITS communication (ITS) .............................................................................. 28

4.2.10 Bluetooth (BT) .............................................................................................. 29

4.2.11 2G/3G Voice Connection (Cell) .................................................................... 30

4.2.12 Human Machine Interface (HMI) ................................................................. 31

4.2.13 Audio (Audio) ............................................................................................... 32

4.2.14 Tabular Summaries of information flow ...................................................... 33

5 Next Steps ................................................................................................................. 34

Annex .............................................................................................................................. 35

OSI model .......................................................................................................................... 35

ETSI standard for ITS architecture ..................................................................................... 36

ARINC 653 .......................................................................................................................... 37

Secure Vehicle Access Service (Native Version) ................................................................ 37

References ....................................................................................................................... 38


vi

List of Figures

Figure 1: Role model for the OVERSEE development and deployment process ....................... 3

Figure 2: OVERSEE application view (exemplary configuration) ................................................ 5

Figure 3: OVERSEE system view ................................................................................................. 6

Figure 4: OVERSEE architecture seen with respect to the OSI model ....................................... 8

Figure 5: CAN and SVAS integration with respect to the OSI model ......................................... 9

Figure 6: OVERSEE architecture seen with respect to the ITS station architecture by ETSI .... 10

Figure 7; Channel in sampling mode ........................................................................................ 18

Figure 8: Channel in Queuing mode ......................................................................................... 19

Figure 9: Generic model of information flow through OVERSEE ............................................. 20

Figure 10: IP Connectivity ......................................................................................................... 21

Figure 11: Secure Vehicle Access Service (IP based) ................................................................ 22

Figure 12: OVERSEE positioning service ................................................................................... 23

Figure 13: USB integration ....................................................................................................... 24

Figure 14: Security Services ...................................................................................................... 25

Figure 15: Secure Memory ....................................................................................................... 26

Figure 16: Inter-partition communications .............................................................................. 27

Figure 17: ITS communication .................................................................................................. 28

Figure 18: Bluetooth Connectivity ........................................................................................... 29

Figure 19: 2G/3G Voice Connection ......................................................................................... 30

Figure 20: Human Machine Interface ...................................................................................... 31

Figure 21: Audio ....................................................................................................................... 32

Figure 22: OSI model ................................................................................................................ 35

Figure 23: Possible elements in the ITS station reference architecture according to[17] ...... 36

Figure 24 Secure Vehicle Access Service (native version) ........................................................ 37


vii

List of Tables

Table 1: List of interfaces on the physical layer ....................................................................... 14

Table 2: Mapping of the interfaces and services on the runtime environments layers to the physical interfaces and devices ........................................................................................ 17

Table 3: Tabular summaries of information flow ..................................................................... 33


viii

List of Acronyms and Abbreviations

2G Second generation mobile phone system

3G Third generation mobile phone system

API Application Programming Interface

ARINC Aeronautical Radio Incorporated

BT Bluetooth

CAN Controller–area Network

CEN European Committee for Standardization

CPU Central Processing Unit

DSRC Dedicated Short-Range Communications

eCall Emergency Call

ECU Electronic Control Unit

EFC Electronic Fee Collection

ETSI European Committee for Standardization

FiFo First in First out

GPRS General Packet Radio Service

GPS Global Positioning System

GPSD GPS daemon

HMI Human Machine Interface

HSM Hardware Security Module

HTTP Hypertext Transfer Protocol

HW Hardware

I/O Input Output

IP Internet Protocol

IPaC Inter-partition Communications

ITS Intelligent Transportation System

NAT Network Address Translation

NIC Network Interface Card

OBEX Object Exchange (Bluetooth Profile)

OBU On-Board Unit

OEM Original Equipment Manufacturer

OS Operating System


ix

OSI Open Systems Interconnection

OVERSEE Open Vehicular Secure Platform

PAN Personal Area Network

PC Personal Computer

PoC Proof of Concept

PoS Positioning Service

QoS Quality of Service

RFID Radio-frequency identification

RTOS Real-time Operating System

SecS Security Services

SPP Serial Port Profile (Bluetooth Profile)

SVAS Secure Vehicle Access Service

TCP Transmission Control Protocol

UMTS Universal Mobile Telecommunications System

USB Universal Serial Bus

Wi-Fi Wireless Fidelity

WLAN Wireless Local Area Network


x

Document History

Version Date Changes

1.5 03-06-2011 Final version


1

1 Introduction

The Open Vehicular Secure Platform (OVERSEE) project has produced this deliverable; therefore it contains contributions from all partners.

The present document describes the design of the integration of the communication means into the OVERSEE platform and the information flow between the external interfaces of OVERSEE and the runtime environments serving the applications.

1.1 Scope and objectives of the document

The scope of this document is the specification or at least selection – in case of reuse – of all communication interfaces of the OVERSEE platform. The interfaces which are described in this document are physical interfaces (e.g., network interfaces) and virtual interfaces/services presented towards the runtime environments (e.g., Secure Vehicle

Access Service). Sometimes, there is a one to one mapping of the virtual interfaces/services at runtime environment level (e.g., Universal Serial Bus) to an interface on physical layer, but there are also some virtual interfaces/services on runtime environment level representing more than one physical interface (e.g., IP connection) as well as some services which do not belong to a physical interface (e.g., partition to partition communication).

This document describes also the generic communication between runtime environments. Nevertheless, the logical interface to special services (e.g., security services) is out of the scope of this document and will be presented in additional deliverables within work package

2 and work package 3.

1.2 Definitions

For the purpose of the present document, the terms and definitions given in [1] and [4] apply, if not otherwise noted. Additionally, the following definitions apply:

- Partition – A partition is a runtime environment defined within the configuration of the virtualization solution. The content of a partition will be executed whenever the partition is invoked and will be halted as the assigned resources (typically CPU time) are consumed. Partitions are temporal and spatial isolated and are therefore one of the main security concepts of OVERSEE. Nevertheless, partition to partition

communication is possible through strictly restricted communication paths (see chapter 4.1 on possible communication means within the selected virtualization solution XtratuM).

- Cluster – A cluster is an OVERSEE partition which is able to enclose a set of applications (1 to N). All applications within a cluster share the same rights, e.g., concerning the available communication means, and will be executed on the same OS.

- Dynamic Cluster – A cluster which provides dynamic configuration of the enclosed applications (e.g., install, delete, run, stop). This can be achieved, e.g., by a dedicated "application store".


2

- Static Cluster – A cluster where the set of applications is fixed at deployment of the

specific OVERSEE platform. Nevertheless, an update of the whole platform including the applications could be performed.

- Application partition – A partition dedicated to serve only one application. Nevertheless, the partition could include an OS to serve the application needs. Additionally, the application and OS within this partition could be updated, too.

While these definitions help to distinguish between different uses of runtime environments, provided by OVERSEE, there is no difference between these partition types from the viewpoint of the platform.

1.3 Document Outline

The document is structured as follows: Section 1 gives an introduction on the scope and intentions. Section 2 introduces the first assumption on an OVERSEE architecture, which is used as prerequisite for the design of the information flow. Section 3 lists the selected OVERSEE interfaces according to the results of task 2.1 and section 4 shows the information

flow in and through OVERSEE according to the results of task 2.2. Within section 5 a short outlook towards the next steps is given. Within the annex three related standards (OSI model, ETSI standard for ITS communications architecture and ARINC 653) are shortly introduced.


3

2 OVERSEE architecture

The overall design of the OVERSEE platform architecture will be presented in [7] and is no part of this deliverable. For the purpose of this document we will use a derived version of the platform design, focusing on the building blocks which are necessary to implement the information flow and integrate the selected interfaces.

2.1 Role model for the OVERSEE development and deployment process

OVERSEE is an open platform, this means that within the OVERSEE runtime environments – called partitions – applications from OEMs and any other third party developers could be executed. The goal of the OVERSEE project is a design for an open platform and an exemplary PoC implementation to demonstrate the feasibility of such a platform, but not

the development of a final product.

These conditions leads us to the requirement of a role model as shown in Figure 1 for the development and deployment process of OVERSEE. The purpose of the role model is to highlight the different responsibilities within the OVERSEE development and deployment process. Nevertheless, a role model for a specific OVERSEE implementation would be much more detailed and complex, especially because this model has to answer a lot of questions concerning – among other– liability issues. Therefore, the current role model is mainly to determine which tasks have to be fulfilled by which group within the development and

deployment process of the generic OVERSEE design and the PoC implementation.

Figure 1: Role model for the OVERSEE development and deployment process

2.1.1 OVERSEE development team

The OVERSEE development team is responsible for the overall design of the OVERSEE platform. This means especially the building blocks, the generic services and the design of


4

the interfaces between these components. In terms of the current project these

responsibilities belong to work package 2. Furthermore, the OVERSEE developers are responsible for the development of the generic components of OVERSEE. “Generic” means implementation independent. The generic implementation tasks are mainly part of work package 3. Nevertheless, the OVERSEE development team is naturally also able to develop OVERSEE applications.

2.1.2 Integrator

The integrator is responsible for all adaption efforts which are necessary to build a complete OVERSEE platform, consisting of the generic OVERSEE components, the chosen hardware components and a configuration dedicated to the current purpose of the platform. Most of

the work of the integrator for our PoC implementation will be done in work package 5 with a restriction on the work which is necessary to provide the functions for the selected PoC use cases. Furthermore, an integrator is of course able to develop OVERSEE applications.

For real world OVERSEE implementations the integrators job is also to make a "contract" with the developers about which and how much resources they need/get and to make sure that enough resources are available.

2.1.3 Application developer

The applications developers are invited to develop OVERSEE applications which could be vehicle independent and therefore dedicated to a big market. In a real world, applications

developers would be surely divided in groups, e.g., OEM application developers, ITS application developers, and so forth. All of these groups would usually have the right to develop applications for specific clusters. Thus, the applications have different rights, especially concerning communication means. Anyway, in the OVERSEE project the application development belongs to WP5 and WP6.


5

2.2 Application view

Figure 2 shows an exemplary configuration for a specific OVERSEE platform, with a focus on the application partitions. The purpose of this figure is to present different options where the applications can be installed.

Figure 2: OVERSEE application view (exemplary configuration)

As already stated, Figure 2 only presents an exemplary configuration for an OVERSEE instance. This means that it is up to the system integrator to decide which partitions and clusters are available and which rights and options are granted to the partitions or clusters1. Furthermore, the integrator has to build an appropriate scheduling plan considering the timing requirements of the configured partitions; this is especially important for the partitions or clusters serving applications with real time requirements2.

1 In the case of clusters, applications which are installed within specific clusters are in the responsibility of the

system integrator or an organization which is in charge of this cluster, e.g., an OEM department. This includes

the responsibility for the process of application installation and certification, e.g., by use of a dedicated

application store approach.

2 OVERSEE is able to guarantee real time requirements on the level of partitions or clusters. If there is more

than one application installed within a partition or cluster the real time behaviour of the application depends

also on the scheduling within the partition or cluster. This applies also to applications which will be executed in

a partition stand-alone on top of an OS where also the timing of the OS has to be considered by the integrator.


6

2.3 System view

The following Figure 3 present the architecture of OVERSEE with a focus on the system partitions. These system partitions are an integral part of OVERSEE and offering generic services and facilities for the applications running within the configured partitions and clusters.

Figure 3: OVERSEE system view

2.3.1 Placement of additional platform functionality

The system partitions shown in Figure 3 and explained in more detail in the following

subsections, are reflecting the design decision to place additional platform functionality (e.g., communication management and security services) in additional partitions instead of integrating them into the virtualization subsystem. The reasons for this decision are:

The code size of the virtualization subsystem should be kept very small due to the needed efficiency of frequent context switches.

The dependability of the platform and the security of the platform will be improved

since the device drivers and management components are running in an isolated partition. This will reduce the threats occurring by faulty code within the device drivers, external attacks and also malicious or faulty application code.

Further functionality like additional communication services could easily be added to the OVERSEE platform since this only means to modify the concerned system partition while the core virtualization system will stay unchanged.


7

2.3.2 Secure I/O Partition

Within the secure I/O partition most of the drivers for the connectivity modules will be handled. Therefore, this partition together with the internal communication resources of XtratuM is responsible for the provision of communication connections for the partitions. Secure means that the access to the different communication means will be restricted inside the secure I/O partition. Furthermore, the different priorities of communication requests will also be enforced and - if reasonable - user and application specific message filtering will be applied.

2.3.3 System Partition

The system partition is responsible for the management of runtime environments within XtratuM, so starting, stopping and monitoring of the application partitions and clusters. Furthermore, the components to provide additional services of the OVERSEE platform (e.g., remote diagnosis) will be placed in this partition.

2.3.4 Security Services Partition

OVERSEE offers build in security services, supported by an HSM as core services, so the services which will be requested for typical use cases [1] and were described in [4] and [5] will be implemented within the security services partition. Additionally, also the secure I/O partition will rely on services which are offered by this partition.

2.3.5 HMI, Audio Partition

The management of HMI and Audio devices is no integral part of the OVERSEE platform. However for most of the USE-Cases [1] which are applicable for OVERSEE interaction with the driver or other occupants of the vehicle is a necessity. Therefore, within the PoC phase of the OVERSEE project an HMI and audio management partition will be implemented to show the feasibility of the whole concept.


8

2.4 OVERSEE architecture seen with respect to the OSI model

The OSI reference model is a layered model – for more details please go to page 35 – designed to describe open communication systems in a standardized way. Since one of the major goals of OVERSEE is the secure integration of a wide range of communication means, in the vehicle, it is worth to present how OVERSEE can be seen with respect to the OSI model, see Figure 4.

Nevertheless, the OSI model was not designated to present system architectures and especially the presentation of virtualization layers were not considered, so the figure is only an abstract illustration with a limited accuracy.

Figure 4: OVERSEE architecture seen with respect to the OSI model


9

While Figure 4 presents an abstract view of the whole system, Figure 5 shows a concrete

integration of the access to the CAN bus which is presented to the partitions as secure vehicle access service. For more details see chapter 3.1.1 and 3.2.1.

Figure 5: CAN and SVAS integration with respect to the OSI model


10

2.5 Mapping of the OVERSEE architecture to the ETSI standard for ITS communications architecture

Within [17] ETSI standardized the generic communications architecture for upcoming ITS systems in Europe, for more details go to page 36. One part of the standard is a high-level design of an common ITS station architecture. While OVERSEE is not proposed as an direct implementation of this architecture, it is however worth to showcase that all main building blocks of the ETSI architecture will be or at least could be implemented within OVERSEE (see Figure 6). Therefore, the OVERSEE platform will be a candidate to serve future automotive applications in Europe considering the ETSI standards.

Figure 6: OVERSEE architecture seen with respect to the ITS station architecture by ETSI


11

3 OVERSEE Interfaces

Since the OVERSEE platform provides a secure single point of access the selection of the necessary interfaces to the external world is of major interest for the OVERSEE design. Derived from the communication requirements in [4] and the vision for OVERSEE, a broad range of interfaces on the physical layer were selected. How theses interfaces would be presented towards the partitions and clusters and therefore also to the operating systems and applications will be described in section 3.2 of this deliverable.

3.1 Interfaces and devices on the physical layer

On the physical layer OVERSEE is connected to a broad range of communication media and devices. The physical access is hidden to the partitions, by use of virtualised interfaces and abstract services, and therefore the binding towards the physical layer is transparent and non part of the generic OVERSEE design. Nevertheless, the following interfaces were

considered for the design phase of OVERSEE, to be sure that corresponding interfaces and services will be present at partition level. The implementation of the adaption between the hardware modules and the services and interfaces on partition level will be under the responsibility of the integrator. So necessary adaption efforts in the current project will be done within the implementation and PoC phase of the project and only in the case they are necessary for a selected PoC use case.

3.1.1 CAN – Controller Area Network

The controller area network is still the common network within vehicles. It is widely used from comfort to also safety relevant applications in modern vehicles and most of the ECUs in a modern car are equipped with a CAN bus transceiver. Therefore, by the use of a CAN module OVERSEE will be able to communicate with all relevant ECUs of the vehicle.

Since any OEM uses different CAN identifiers and encoding schemes for the values transmitted via CAN, an abstraction layer towards the partitions will be necessary to enable vehicle independent applications. Besides this translation issues the abstraction layer will be

also responsible for the separation between the vehicle based systems (CAN network) which should be under the exclusive responsibility of the OEM and OVERSEE and the applications

executed on OVERSEE. This separation of concern is also safety relevant and recommended by the eSecurity Working Group of the eSaftey Forum, see [19].

3.1.2 Bluetooth

Is a wireless network for data transmission over short distances by creating PANs. The main use case for Bluetooth in vehicular environments is the integration of nomadic devices and especially mobile phones that are becoming more and more the key device in people's life.


12

3.1.3 USB – Universal Serial Bus

Many nomadic devices of nowadays are equipped with an USB port. USB offers different device classes to distinguish between devices with a different range of functions. For the current OVERSEE approach only devices which are compliant to the mass storage device class will be considered. This restriction fits to the usual needs of the applications which are motivated by the use cases (store and read files to and from nomadic devices) and also reduces the amount of serious security concerns caused by USB integration.

3.1.4 CEN DSRC – Dedicated Short Range Communication

CEN DSRC is a short range communication link used in many especially European countries

for payment applications, in the first place electronic toll/fee collection. There are two European and two national frequency bands reserved for CEN DSRC transmission and the size of a typical communication zone is round about 10-20 m. Typically, passive OBUs will be used.

3.1.5 ITS-G5 – Cooperative ITS communication in the 5.9 GHz spectrum

Within the European Union a spectrum in the 5GHz band was reserved for cooperative ITS communication:

5,875 GHz to 5,905 GHz for safety related ITS applications

5,855 GHz to 5,875 GHz for non-safety ITS applications

5,470 GHz to 5,725 GHz ITS applications

The standardisation work on this topic is still ongoing in CEN and ETSI but nevertheless first results can be considered, e.g., [18]. OVERSEE will provide access to ITS-G5 in a secure way. Therefore, an adaption layer towards the applications will be considered as soon as the standards are finalized. Anyway, for the PoC phase of the project ITS-G5 communication will be probably used, at least based on a trial use standard.

3.1.6 GPS – Global Positioning System

The satellite based positioning system, developed by the United States Department of Defense, is the de-facto standard for positioning systems. Although there are some

alternatives available or at least under way, e.g., Galileo, the OVERSEE consortium decided to consider only GPS in the first project step. Nevertheless, an abstraction layer will be introduced to enable alternative positioning systems in the future without changing the applications which are developed for OVERSEE and using positioning data.


13

3.1.7 2G/3G Voice and data connection

Mobile cell phone networks are a widely available communication medium in the European Union. To serve the use cases selected for OVERSEE, voice connections over 2G/3G networks are necessary and also data transmission. Nevertheless, towards the applications, which will be executed in the partitions or clusters, an abstraction layer will be introduced to avoid the necessity for connection management in each application and to hide the details of the current connection.

3.1.8 Audio in/out

As already stated OVERSEE will not include generic services for audio integration since this is

a special topic beyond the scope of OVERSEE. Therefore, the integration of audio will be only part of the PoC phase. However, the interfaces will be considered in the design phase to enable the further integration.

3.1.9 HMI – Human Machine Interface

As already stated OVERSEE will not include generic services for HMI integration, since this is a special topic beyond the scope of OVERSEE. Therefore, the integration of HMI will be only part of the PoC phase. However, the interfaces for a graphical output, a pointing device and a keyboard will be considered in the design phase to enable the further integration.

3.1.10 HSM - Hardware Security Module

To serve reliable and trustworthy security services OVERSEE will be equipped with an HSM. As the HSM will probably be a reused building block, an adapted interface to the hardware module will be necessary. The integration of the HSM will be implemented within the security services partition and will be therefore transparent to the applications. Thus, the exact interface towards the HSM is only part in the integration process of OVERSEE and therefore in case of the project part of the PoC phase of the project.

3.1.11 SMEM – Secure Memory

The secure memory is no real physical device of OVERSEE. It will be simply a protected area

within the memory of the OVERSEE platform, which will be handled by the security services partition. Therefore, no further details are given at this layer.

3.1.12 WiFi – Wireless Fidelity

WiFi refers to a range of connectivity technologies including WLAN based on the 802.11 standards. In the design of OVERSEE WiFi access will be included. To hide the details of the connection and hence unburden the partitions or clusters the WiFi access will be managed within the secure I/O partition and only a simple network connection (IP based) will be presented on runtime environments layer to the configured partitions and clusters.


14

3.1.13 List of interfaces on the physical layer

No. Interface Placement of management component

1 CAN – Controller Area Network Handled within the secure I/O partition

2 Bluetooth Handled within the secure I/O partition

3 USB – Universal Serial Bus Handled within the secure I/O partition

4 CEN DSRC – Dedicated Short Range Communication"

Handled within the secure I/O partition

5 ITS-G5 – Cooperative ITS communication in the 5.9 GHz

spectrum

Handled within the secure I/O partition

6 GPS – Global Positioning System Handled within the secure I/O partition

7 2G/3G Voice and data connection Handled within the secure I/O partition

8 Audio in/out Handled within the HMI and audio partition (only in the PoC phase)

9 HMI (In/Out) – Human Machine Interface

Handled within the HMI and audio partition (only in the PoC phase)

10 HSM - Hardware Security Module Handled within the security services partition

11 SMEM– Secure Memory (No real physical device)

12 WiFi – Wireless Fidelity Handled within the secure I/O partition

Table 1: List of interfaces on the physical layer

3.2 Interfaces and devices on the runtime environments layer

In this section the interfaces are "virtual" and their presentation towards the partitions and hence the applications will be listed and briefly described. Furthermore, the mapping of this

interfaces and devices to the physical interfaces and devices will be mentioned.

3.2.1 SVAS – Secure Vehicle Access Service

The SVAS is a service which offers access to the vehicle based systems, e.g., get current speed and mileage or getting and setting the volume of the in car sound system. The service abstracts from the details of the necessary access to the vehicle internal networks (currently only CAN) and also guarantees the enforcement of the communication policies.


15

3.2.2 USB – Universal Serial Bus

The USB service on runtime environment layer is a very small subset of the current USB support – known from desktop PCs etc. For now, the service only supports mass storage devices and offers access to such devices towards the partitions which are allowed to use external mass storage devices connected via USB.

3.2.3 SecS – Security Services

The security services of OVERSEE will offer access to generic cryptographic functions (e.g., encryption, signing) as well as high level security services (e.g., authentication) towards the applications, which will be executed in the partitions, through a standardized API. The

specification of the security services will be presented in [6].

3.2.4 S-Mem – Secure Memory

The secure memory is a service which is required by a wide range of applications (e.g., EFC, driver logbook). To keep the application development simple, a secure memory area will be presented towards the applications as a common block device or memory area via a special driver. As an alternative the SecS API offers a file based usage of the S-Mem service. The detailed specification of the Secure Memory Service will be presented in [6].

3.2.5 PoS – Positioning Service

The current position of the vehicle is an essential information for many automotive applications, from intelligent traffic management to safety applications. Since this information should be available in any vehicle – which is equipped with an OVERSEE ECU – positioning will be a generic service of OVERSEE, independent from the vehicle systems.

3.2.6 IPaC - Inter-partition communications

The communication between partitions will be generally achieved by using the XtratuM inter-partition communication means (channels in queuing and sampling mode) which are the realization of the communication means described in ARINC 653 [21]. In terms of application specific communication only these communication options are available.

Nevertheless, for the realization of high performance interface integration (e.g., Audio, HMI) also advanced techniques like shared memory will be used.

3.2.7 ITS – ITS communication

ITS communication in Europe can be divided according to [18] by the used frequency range into different classes, e.g., safety and non safety related communication. Since the standards describing the upper layers of the cooperative ITS protocol stack are still work in progress, the OVERSEE design considers the integration of ITS communication by integrating an abstract ITS communication management component within the secure I/O partition. The


16

details about this component and the communication of partitions with this component will

be specified as soon as the European standards are available. (ITS communication includes communication according to CEN-DSRC, also if this communication maybe is infrared based while this interface is no part of OVERSEE yet.)

3.2.8 IP – IP Connection

Availability of IP based communication is a requirement of many applications especially for comfort and entertainment purposes. Generally, such applications don't care and even shouldn't care (according to the OSI model) which underlying network provides the network connection for the IP layer. Hence, OVERSEE simply provides IP based communication on partition level and cares for routing of the IP packets over an suitable network link

(according to information on priority, QoS etc. provided by the upper layers).

3.2.9 BT – Bluetooth

Most recent nomadic devices are equipped with a Bluetooth interface to achieve easy to establish connectivity with a wide range of other Bluetooth equipped devices. Since Bluetooth is a widely accepted standard, no further assumptions on the connected device are necessary. Bluetooth specifies a lot of different profiles to characterize the devices which are connected. The connected devices will be managed in the secure I/O partition, while the upper layers of the Bluetooth communication stack will be placed in the application partitions. In the first project step OBEX (Object Exchange) and SPP (Serial Port Profile) will be considered in the design and if necessary for the PoC use cases implemented.

3.2.10 Cell – 2G/3G Voice Connection

Building a voice connection over the cell phone network is a special requirement of the eCall

application and also may be of interest for other applications, e.g., integration of hands free calling capabilities in business applications. OVERSEE will provide the voice input and output channel towards the partitions and offer generic functions for the handling of the voice calls through its API.

3.2.11 HMI – Human Machine Interface

As already mentioned the HMI will be no integral part of the OVERSEE design and the HMI integration will only be done within the demonstrator and therefore not been specified yet.

3.2.12 Audio

As already mentioned Audio integration will be no integral part of the OVERSEE design and the audio integration will only be done within the demonstrator and therefore not been specified yet.


17

3.2.13 Mapping of the interfaces and services on the runtime environments layers to the physical interfaces and devices

No. Abbr. Interface / service runtime environment layer

Physical interfaces or devices

1 SVAS Secure Vehicle Access Service CAN-Transceiver

2 USB Universal Serial Bus Universal Serial Bus module

3 SecS Security Services Hardware Security Module

4 SMem Secure Memory Protected memory area within the OVERSEE memory

5 PoS Positioning Service GPS receiver, vehicle sensor if applicable

6 IPaC Inter-partition communications No physical representation

7 ITS ITS Communication ITS G5, CEN-DSRC transceivers

8 IP IP Connection WiFi, GPRS, UMTS modules

9 BT Bluetooth Bluetooth module

10 Cell 2G/3G Voice Connection GSM, UMTS module

11 HMI Human Machine Interface Graphic output, keyboard, pointer device

12 Audio Audio Audio in/out device

Table 2: Mapping of the interfaces and services on the runtime environments layers to the physical

interfaces and devices


18

4 Information flow in and through OVERSEE

OVERSEE will be designed as a single point of access from the environmental networks into the vehicle. Nevertheless, within OVERSEE there are three partitions which are responsible for the device driver handling and the communication with external networks/devices, see Figure 3:

Secure I/O Partition

Security Services Partition

HMI/Audio Partition

In the following sections the information flow from the partitions with access to the external interfaces/devices towards the partitions or clusters serving the OVERSEE applications will be described in detail.

4.1 Introduction to the general communication means in XtratuM

XtratuM provides inter-partition communications by channels between the partitions. A channel is a logical path between one source and one or more destinations and would be accessed by the partitions through access points called ports. The hypervisor is responsible for the unchanged and atomic transport of the messages while the content of the messages are transparent to the hypervisor. The partitions have to agree on the format of the messages.

All channels and channel endpoints have to be defined in the XtratuM configuration file, see [22]

4.1.1 Sampling ports / channels

Channels in sampling port mode are suitable for broadcast, multicast and unicast communication. To put it simple a message in a sampling channel remains in the channel until a new message is written to the channel by the sender. Therefore, all partitions with ports configured to the channel are able to read the last message. All operations are non-blocking, see [22].

Figure 7; Channel in sampling mode


19

4.1.2 Queuing ports / channels

Channels in queuing port mode are suitable for unicast communication. The channels are able to buffer messages and deliver the messages in FIFO (First in First out) order. Therefore, within the sending operation the message will be copied into the queue and within the receiving operation the received message will be deleted from the queue. If the queue is full (in case of the sending operation) or empty (in case of the receiving operation) an error occurs and has to be handled within the code which is executed within the partition. The writing and receiving partitions have to provide buffers from where the messages could be copied in the queue (in case of the sending operation) and to which the message could be copied from the queue (in case of the receiving operation). The message copy operation is performed by the interpartition communication subsystem, which also applies some checks to the transmitted message.

Figure 8: Channel in Queuing mode

4.1.3 Shared Memory

Shared memory is an advanced concept for high performance inter-partition

communication. Since this technology is still a work in progress the description will be updated as soon as documentation is available.

4.2 Information flow in OVERSEE

Generally, all devices and interfaces will be handled by a device driver in a dedicated partition – in most cases within the secure I/O partition. The functions of the devices and

interfaces will be offered to the other partitions by services or virtualized devices. How the information will be transported within the OVERSEE platform will be presented for each service in the following sections.

Although within the following sections the information flow is described for each service it's worth to mention, that within the OVERSEE project only some of the services will be implemented (at least the services which are required for the selected PoC use cases).


20

4.2.1 Generic model of information flow

As already stated, the device management and the corresponding device drivers will be placed in the system partitions, namely the secure I/O partition, the HMI & audio partition and the security services partition. The partitions serving the applications access the external communication interfaces by invoking the services offered by these system partitions through the communication resources of XtratuM. This approach results in the generic model of information flow presented in Figure 9.

Figure 9: Generic model of information flow through OVERSEE

The application of this generic model leads to a design for the information flow of each

(communication) service offered by the OVERSEE platform and presented in the following subsections. The flexibility of this approach enables also the consideration of further communication interfaces in the future.3

3 An example could be the integration of an RFID reader, which was not considered for the current version of

the OVERSEE platform since it was not motivated by the selected use cases.


21

4.2.2 IP connection (IP)

IP connection service could be easily achieved similar to solutions in desktop virtualization. Within the secure I/O partition the drivers for the communication means, which are able to offer IP connections, will be managed and the IP traffic will be routed towards the destination partitions.

Techniques like NAT (Network Address Translation) and DHCP (Dynamic Host Configuration Protocol) within the secure I/O partition will enable an easy integration of IP connections for the application partitions. The connections between the partitions and the secure I/O partition will be established by use of shared memory for each partition that is allowed to use the network capabilities.

Since the virtual NICs are based on XtratuM communication means, it is possible to proof

which partition is assigned to a specific IP connection. This capability is the prerequisite for further security measures.

Figure 10: IP Connectivity


22

4.2.3 Secure Vehicle Access Service (SVAS)

The secure vehicle access service is a service which allows the communication with vehicle internal components connected to OVERSEE through a vehicle internal network (currently only CAN). Therefore, within the secure I/O partition a SVAS component will be established. The SVAS service provides access to the vehicle internal information in a vehicle and brand independent format, through the SVAS API in the application partition. The SVAS API and the SVAS management component in the secure I/O partition are connected through IP connections bounded to the virtual NICs introduced in section 4.2.2. So the secure vehicle access service will be an additional abstraction layer, which also enables the application of advanced user policies on information level.

Figure 11: Secure Vehicle Access Service (IP based)

The OVERSEE consortium considered also a native SVAS implementation, avoiding the additional overhead of the IP communication via the virtual network cards in the partitions, see Figure 24.


23

4.2.4 Positioning Service (PoS)

Knowledge of the current position of the vehicle is a requirement for a lot of applications (e.g., navigation system or emergency call). Since many applications already exist, OVERSEE tries to offer the position information in various kinds in order to avoid changes in legacy applications that are expecting the position information in a specific format or via a specific interface.

Figure 12: OVERSEE positioning service

In general, OVERSEE offers the positioning information via the PoS API, which will be probably a reused and already well known API (e.g., GPSD). As an alternative, OVERSEE provides positioning information using a virtual communication (COM) port, which is a well known concept from PCs and mobile devices. Thus, legacy applications expecting the positioning information via these interfaces4 could be probably executed in an OVERSEE partition without any modifications.

4 There will also be the capability to receive the current position via the SVAS that is not presented in Figure 12.


24

4.2.5 Universal Serial Bus (USB)

Integrating a USB interface into the vehicle electronic will cause a lot of security weaknesses. Therefore, the whole USB stack will be managed within the secure I/O partition of OVERSEE and only USB mass storage devices will be supported. The memory of the devices will be presented to the partitions as a dedicated shared memory area (in case of an OS a modified block device driver will be a suitable implementation on partition side).

Figure 13: USB integration


25

4.2.6 Security Services (SecS)

The security services will be offered by the security services partition which uses the generic cryptographic and security functions offered by an HSM. For the applications running within the partitions the use of the HSM is transparent. The security services API will send the control and data messages through channels in queuing mode for each partition which is allowed to use the services. More information about the capabilities and internal structure of the security services are presented in [6].

Figure 14: Security Services


26

4.2.7 Secure Memory (S-Mem)

For the applications which will be executed within the partitions a secure memory area is an ordinary memory area. Therefore, no changes to the applications are necessary. The memory becomes secure by application of the dedicated cryptographic mechanisms – e.g., encryption and adding of cryptographic checksums - while writing and reading the data content from and to the persistent memory of OVERSEE. To provide this function these security extensions have to be transparent and therefore the necessary functions will be executed within the secure I/O partition. The secure memory will be provided towards the partitions by shared memory, while the exchange of control messages will be done through queuing ports. For partitions with OS a virtual block device driver could be used to present the protected memory. As an alternative the SecS API offers also an interface to use the secure memory functionality on a per file base.

Figure 15: Secure Memory


27

4.2.8 Inter-partition communications (IPaC)

Application specific communication between partitions will be achieved by use of XtratuM channels in queuing mode, filled with application specific data and control information. Since channels in queuing mode are a generic communication mean of XtratuM, only an application specific communication protocol and suitable API are necessary.

For security reasons it might be interesting to bind each partition only to the secure I/O partition and route the messages to the destination partition through the secure I/O partition. The benefit of this solution is the option of an advanced filtering within the secure I/O partition. Since this filtering would probably need a deep insight of the transferred data, this filtering maybe only reasonable in a few cases, especially because the additional overhead would be excessive high. That's why usually OVERSEE only ensures that only the configured partitions are able to participate at a dedicated communication connection

without applying additional filtering in the secure I/O partition. Thus, also direct connections between partitions are possible. Both options are presented in Figure 16.

Figure 16: Inter-partition communications


28

4.2.9 ITS communication (ITS)

The access to ITS networks (ITS-G5 and CEN-DSRC) will be controlled by the "ITS communication management" within the secure I/O partition. Each partition which is allowed to use this service uses channels in queuing mode to access this service. Since ITS-G5 communication is not fully standardized yet, the service is for now only abstract and will be presented in more detail as soon as the standards are available.

Figure 17: ITS communication


29

4.2.10 Bluetooth (BT)

The Bluetooth integration will be conducted by reusing a well established Bluetooth stack in the secure I/O partition and forwarding the access to services of distinct devices towards a selected partition. As already mentioned only a few Bluetooth profiles will be supported to limit the possible security leakages.

The data exchange between the application partitions and the secure I/O partition will be fulfilled by using queuing ports for each partition which is permitted to use Bluetooth devices.

Figure 18: Bluetooth Connectivity


30

4.2.11 2G/3G Voice Connection (Cell)

The applications which will be executed within the partitions are usually uninterested in the type of cell network (2G/3G), which is used to establish a voice connection. Therefore, the whole management of the 2G/3G networks will be done in the implementation specific module and driver and the management layer of the secure I/O partition. The application within the partitions which are authorized to establish a voice call (e.g., eCall) will receive the incoming audio and transmit the outgoing audio signal via a shared memory area (because of performance issues). Nevertheless, channels in queuing mode will be used between the ordinary partitions and the secure I/O partition to exchange control information for the call management (e.g., phone number).

Figure 19: 2G/3G Voice Connection


31

4.2.12 Human Machine Interface5 (HMI)

Interaction with the driver or other occupants of a vehicle is necessary for many innovative automotive applications. The prototypical implementation of an HMI for OVERSEE will be achieved by transferring the graphical data and the necessary control information through a shared memory area. Nevertheless, OVERSEE is about security and reliability and not about HMI, therefore the HMI is no generic part of OVERSEE.

Figure 20: Human Machine Interface

5 Please keep in mind that building an HMI is not in the project scope of OVERSEE. Therefore, only a

prototypical implementation will be realized within the PoC phase of the project.


32

4.2.13 Audio6 (Audio)

Similar to the HMI, also the option to present information via audio output to the driver and the occupants of a vehicle is a necessity. OVERSEE will provide access to the audio system via a shared memory area for the audio data and the control information for the audio output. As already stated OVERSEE is about security and reliability, therefore the implementation of the audio access will only by prototypically achieved within the PoC phase.

Figure 21: Audio

6 Please keep in mind that Audio integration is not in the project scope of OVERSEE. Therefore, only a

prototypical implementation will be realized within the PoC phase of the project.


33

4.2.14 Tabular Summaries of information flow

No. Abbr. Interface / service runtime environment layer

XtratuM communication resources

1 PoS Positioning service Channel in sampling mode or based on IP communication (shared memory)

2 SVAS Secure Vehicle Access Service Shared memory for each partition using the SVAS – transporting IP packets containing SVAS requests and responses; in case of native SVAS messages (not IP based) channels in queuing mode will be used

3 USB Universal Serial Bus Shared memory transporting control information and data for each partition with USB access

4 SecS Security Services Channels in queuing mode for each partition using the security services – transporting protocol and data messages. Additional shared memory communication for big data chunks.

5 SMem Secure Memory Shared memory plus reuse of channels for the ordinary security services (see above)

6 IPaC Inter-partition

communications

Communication channels in queuing mode

for each connection between the partitions – transporting application specific data and control information

7 ITS ITS Communication Communication channels in queuing mode, for each connection between the partitions

8 IP IP Connection Shared memory for each partition using IP connections

9 BT Bluetooth Communication channels in queuing mode, for each partition using Bluetooth devices

10 Cell 2G/3G Voice Connection Shared memory area for audio data, channels

in queuing mode for exchange of control information

11 HMI Human Machine Interface Shared memory area for graphic data and control information

12 Audio Audio Shared memory area for audio data and control information

Table 3: Tabular summaries of information flow


34

5 Next Steps

Starting from the finalized design of OVERSEE, the detailed specification (e.g., message format and API calls) and corresponding implementation will be done in WP3 from January 2011. The OVERSEE consortium is aware that the implementation process could lead to the need to revise some of the design decisions presented in this document. Hence, the further process is more or less an iterative development process.


35

Annex

OSI model

The OSI model was developed by the International Organization for Standardisation (ISO) and is published in [23]. The model was developed to sub-divide communication systems in smaller parts, called layers.

Within the model a layer provides services for the layer above and uses services from the layer below. Entities on the same layer interact by exchanging protocol data units (PDU) specified for this layer. Entities which are placed on different systems, which are connected

via a subjacent layer, forward their PDUs to the layer below, where they are received as Service Data Units (SDU). Henceforth this layer is responsible for the transmission. Therefore, the current layer adds additional information, e.g., addresses, and encapsulates the received SDU together with the new header information in a new PDU, for the next layer

below. This process is repeated until a physical transmission between the systems can be conducted. On receiver side the inverse operations are performed until the original layer is reached.

Within the OSI model the layers in Figure 22 are defined, for more details please consult the original standard which is available free of charge via the ISO website [23].

Figure 22: OSI model


36

ETSI standard for ITS architecture

In [17] the European Telecommunications Standards Institute published a specification for the global communications architecture for communication in Intelligent Transport Systems (ITS) particularly in the context of road transport. The standard defines mandatory elements on an implementation independent level.

The interesting part of [17], related to OVERSEE, is the specification of a generic ITS station architecture where all reasonable components of ITS stations are described. An ITS station could be a vehicle or a road side unit and even a handheld device or backend system. For sure the characteristics and implementations would differ between the mentioned ITS stations.

The ITS station architecture as described in [17] is presented in Figure 23.

Figure 23: Possible elements in the ITS station reference architecture according to[17]


37

ARINC 653

The "Avionics Application Standard Software Interface" is originally a software specification for space and time partitioning in safety-critical avionics systems with real time capabilities. The specification allows hosting of multiple applications, which could be also on different software levels on the same hardware.

Although ARINC is originally developed for avionics industry, systems which are developed according to this specification could be used in other domains, too. The specification is managed by “Aeronautical Radio Incorporated” which is a private company in the US.

Secure Vehicle Access Service (Native Version)

Figure 24 Secure Vehicle Access Service (native version)


38

References

[1] OVERSEE Project: D1.1 Use Case Identification. 2010

[2] OVERSEE Project: D1.2 Initial Version of the Functional, Dependability and Security

Requirements Document. 2010

[3] OVERSEE Project: D1.3 Initial version of the non-functional requirements and constraints

document. 2010

[4] OVERSEE Project: D1.4 Functional Requirement Analysis. 2010

[5] OVERSEE Project: D1.5 Non-functional requirement analysis. 2010

[6] OVERSEE Project: D2.2 Specification of security services incl. virtualization and firewall

mechanisms

[7] OVERSEE Project: D2.3 Description of building blocks, interfaces and localization of building

blocks

[8] OVERSEE Project: D2.4 Specification of secure communication

[9] XtratuM, http://www.xtratum.org/

[10] https://www.oversee-project.com/internal/wiki/index.php/Main_Page

[11] OSEK/VDX, http://osek-vdx.org

[12] OSEK Operating System Specification 2.2.3, http://portal.osek-

vdx.org/files/pdf/specs/os223.pdf

[13] OSEK/VDX Operating System Test Plan, http://portal.osek-

vdx.org/files/pdf/modistarc/ostestplan20.pdf

[14] ETSI: TS 102 637-1 V1.1.1. Intelligent Transport Systems (ITS); Vehicular Communications; Basic

Set of Applications; Part 1: Functional Requirements. Sep. 2010

[15] ETSI: TR 102 893 V1.1.1. Intelligent Transport Systems (ITS); Security; Threat, Vulnerability and

Risk Analysis (TVRA). Mar. 2010

[16] ETSI: TR 102 638 V1.1.1. Intelligent Transport Systems (ITS); Vehicular Communications; Basic

Set of Applications; Definitions. Jun. 2009

[17] ETSI: EN 302 665 V1.1.1. Intelligent Transport Systems (ITS); Communications Architecture

[18] ETSI: ES 202 663 V1.1.0. Intelligent Transport Systems (ITS); European profile standard for the

physical and medium access control layer of Intelligent Transport Systems operating in the 5

GHz frequency band

[19] eSecurity Working Group: Vulnerabilities in Electronics and Communications in Road

Transport: Discussion and Recommendations. Jun. 2010

[20] National Marine Electronics Association: NMEA 0183 Standard. http://www.nmea.org

[21] ARINC: Avionics Application Software Standard Interface

[22] M. Masmano, I. Ripoll, A. Crespo, V. Brocal: XtratuM Hypervisor for LEON2 Volume2: User

Manual. Sep. 2009


39

[23] ISO IEC: 7498-1: Information Technology – Open Systems Interconnection – Basic Reference

Model, http://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-

1_1994(E).zip. 1996-06-15

deliverable d2.2: list of interfaces and specifications of ... · call id: fp7-ict-2009-4...

Documents