Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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.
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
x
Document History
Version Date Changes
1.5 03-06-2011 Final version
D2.1: List of interfaces and specifications of information flow
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".
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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).
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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.
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications 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.
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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]
D2.1: List of interfaces and specifications of information flow
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)
D2.1: List of interfaces and specifications of information flow
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
D2.1: List of interfaces and specifications of information flow
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