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 D5.2:
Proof of Concept Use Case Specification
Authors:
Thomas Enderle (Escrypt)
Rafael Grote (TUB)
Jan Holle (Uni Siegen)
Martin Förster (Volkswagen)
Reviewers:
Florian Friederici (FOKUS)
Jan Holle (Uni Siegen)
Hakan Cankaya (Escrypt)
Dissemination level:
Public
Deliverable type:
Report
Version:
1.0 Draft – Waiting for Approval
Submission date:
16 February 2016
D5.2: Proof of Concept Use Case Specifications
Abstract
This document contains the specifications of the proof of concept (PoC) use cases selected
and described in Deliverable D5.1 in order to demonstrate the capabilities of the OVERSEE
platform.
The specified use cases include application use cases, which demonstrate the functionality of
a certain application on the OVERSEE platform, as well as validation use cases, which
demonstrate a specific property of the OVERSEE platform, such as security, isolation and
dependability properties. Each use case is specified in terms of involved data, software
modules, peripherals and the application flow.
ii
D5.2: Proof of Concept Use Case Specifications
Contents
Abstract .............................................................................................................................ii
Contents ........................................................................................................................... iii
List of Figures.................................................................................................................... vi
List of Abbreviations ........................................................................................................ vii
Document History ............................................................................................................. xi
1
Introduction ................................................................................................................1
1.1 Scope and Objective of the Document ...................................................................... 1
1.2 Document Outline ...................................................................................................... 1
2
Use Case Specifications ...............................................................................................2
2.1 USB Flash Drive Media Access .................................................................................... 2
2.1.1 Introduction ................................................................................................... 2
2.1.2 Initial State ..................................................................................................... 3
2.1.3 Involved Data ................................................................................................. 3
2.1.4 Used Modules and Services ........................................................................... 3
2.1.5 Sequence Diagram ......................................................................................... 4
2.1.6 Description ..................................................................................................... 4
2.2 Emergency Vehicle Warning ...................................................................................... 5
2.2.1 Introduction ................................................................................................... 5
2.2.2 Initial State ..................................................................................................... 5
2.2.3 Involved Data ................................................................................................. 5
2.2.4 Used Modules and Services ........................................................................... 6
2.2.5 Sequence Diagrams........................................................................................ 7
2.2.6 Description ..................................................................................................... 8
2.2.7 Notable Changes and Justification ................................................................. 9
2.3 Sending an Emergency Call ........................................................................................ 9
2.3.1 Introduction ................................................................................................... 9
2.3.2 Initial State ..................................................................................................... 9
2.3.3 Involved Data ................................................................................................. 9
2.3.4 Used Modules and Services ......................................................................... 10
2.3.5 Sequence Diagrams...................................................................................... 11
2.3.6 Description ................................................................................................... 11
iii
D5.2: Proof of Concept Use Case Specifications
2.3.7 Notable Changes and Justification ............................................................... 11
2.4 Update Partition or OVERSEE Component ............................................................... 12
2.4.1 Introduction ................................................................................................. 12
2.4.2 Initial State ................................................................................................... 12
2.4.3 Involved Data ............................................................................................... 12
2.4.4 Used Modules and Services ......................................................................... 14
2.4.5 Sequence Diagrams...................................................................................... 15
2.4.6 Description ................................................................................................... 17
2.4.7 Notable Changes and Justification............................................................... 18
2.5 Cooperative Platoon Automation System ................................................................ 18
2.5.1 Introduction ................................................................................................. 18
2.5.2 Initial State ................................................................................................... 18
2.5.3 Involved Data ............................................................................................... 19
2.5.4 Used Modules and Services ......................................................................... 20
2.5.5 Sequence Diagram ....................................................................................... 21
2.5.6 Description ................................................................................................... 22
2.5.7 Notable Changes and Justification ............................................................... 24
2.6 Active Brake.............................................................................................................. 24
2.6.1 Introduction ................................................................................................. 24
2.6.2 Initial State ................................................................................................... 25
2.6.3 Involved Data ............................................................................................... 25
2.6.4 Used Modules and Services ......................................................................... 26
2.6.5 Sequence Diagram ....................................................................................... 26
2.6.6 Description ................................................................................................... 27
2.6.7 Notable Changes and Justification ............................................................... 27
3
Validation Use Case Specification .............................................................................. 28
3.1 USB Flash Drive Media Access .................................................................................. 28
3.1.1 Introduction ................................................................................................. 28
3.1.2 Attacker Model ............................................................................................ 28
3.1.3 Additional Components ............................................................................... 28
3.1.4 Sequence Diagram ....................................................................................... 28
3.1.5 Description ................................................................................................... 28
3.2 Emergency Vehicle Warning / E-Call ........................................................................ 29
3.2.1 Introduction ................................................................................................. 29
iv
D5.2: Proof of Concept Use Case Specifications
3.2.2 Attacker Model ............................................................................................ 29
3.2.3 Additional Components ............................................................................... 29
3.2.4 Sequence Diagram ....................................................................................... 29
3.2.5 Description ................................................................................................... 29
3.3 Update Partition ....................................................................................................... 30
3.3.1 Introduction ................................................................................................. 30
3.3.2 Attacker Model ............................................................................................ 30
3.3.3 Additional Components ............................................................................... 30
3.3.4 Sequence Diagram ....................................................................................... 31
3.3.5 Description ................................................................................................... 31
3.4 Platoon ..................................................................................................................... 32
3.4.1 Introduction ................................................................................................. 32
3.4.2 Attacker Model ............................................................................................ 32
3.4.3 Additional Components ............................................................................... 32
3.4.4 Message Sequence Diagram ........................................................................ 32
3.4.5 Description ................................................................................................... 33
3.5 Active Break.............................................................................................................. 33
3.5.1 Introduction ................................................................................................. 33
3.5.2 Attacker Model ............................................................................................ 33
3.5.3 Additional Components ............................................................................... 34
3.5.4 Message Sequence Diagram ........................................................................ 34
3.5.5 Description ................................................................................................... 34
References....................................................................................................................... 35
v
D5.2: Proof of Concept Use Case Specifications
List of Figures
Figure 1: Media player sequence diagram ................................................................................. 4
Figure 2: Graphical representation of the EVW ......................................................................... 5
Figure 3: Emergency vehicle sends CAMs sequence diagram ................................................... 7
Figure 4: Proof of concept car generates warning sequence diagram ...................................... 8
Figure 5: Trigger and send an eCall sequence diagram ........................................................... 11
Figure 6: Software update sequence diagram ......................................................................... 15
Figure 7: Permission request sequence diagram ..................................................................... 16
Figure 8: Verify software update list sequence diagram ......................................................... 16
Figure 9: Execute software update sequence diagram............................................................ 17
Figure 10: Message sequence chart of the Platooning use case ............................................. 21
Figure 11: Platooning from the view of a follower vehicle ...................................................... 22
Figure 12: Detection and broadcasting of warning events ...................................................... 26
Figure 13: Incoming V2X messages lead to safety reaction ..................................................... 27
Figure 14: Attack on the software update process .................................................................. 31
Figure 15: Attack trying to hijack a platoon ............................................................................. 32
Figure 16: Replay attack to fake a hard braking vehicle .......................................................... 34
vi
D5.2: Proof of Concept Use Case Specifications
List of Abbreviations
ADAS
Advanced Driver Assistance Systems
AES
Advanced Encryption Standard
APEX
Application Executive
API
Application Programming Interface
ARINC
Aeronautical Radio Incorporated
BT
Basic Task
C2C-CC
Car to Car Communication Consortium
CALM
Communications Access for Land Mobiles
CAM
Cooperative Awareness Message
CAN
Controller–area Network
CAP
Capability
CC
Common Criteria
CEN
European Committee for Standardization
CF
Configuration File
CPU
Central Processing Unit
CT
Configuration Table
CTR
Constraint
DEN
Decentralized Environmental Notification
DENM
Decentralized Environmental Notification Message
DNS
Domain Name System
DSA
Digital Signature Algorithm
DSRC
Dedicated Short-range Communications
EAP
Extensible Authentication Protocol
ECC
Elliptic Curve Cryptography
ECDSA
Elliptic Curve Digital Signature Algorithm
ECU
Electronic Control Unit
EFC
Electronic Fee Collection
ELF
Executable and Linkable Format
ET
Extended Task
ETSI
European Telecommunications Standards Institute
EVW
Emergency Vehicle Warning
vii
D5.2: Proof of Concept Use Case Specifications
FLOSS
Free/Libre Open Source Software
FPGA
Field Programmable Gate Array
GNSS
Global Navigation Satellite System
GPOS
General Purpose Operating System
GPRS
General Packet Radio Service
GPS
Global Positioning System
GSM
Global System for Mobile Communications
HAL
Hardware Abstraction Layer
HM
Health Monitoring
HMI
Human Machine Interface
HSM
Hardware Security Module
HTTP
Hypertext Transfer Protocol
HW
Hardware
ID
Identity
IP
Internet Protocol
ISO
International Organization for Standardization
ISP
Internet Service Provider
IT
Information Technology
ITS
Intelligent Transportation System
JVM
Java Virtual Machine
LBS
Location Based Service
LDM
Local Dynamic Map
MOST
Media Oriented Systems Transport
MSD
Minimum Set of Data
NAT
Network Address Translation
NFC
Near Field Communication (see RFID)
NIC
Network Interface Card
NMEA
National Marine Electronics Association
NPS
Network Provisioning Service
OBD
On Board Diagnosis
OBEX
Object Exchange (Bluetooth Profile)
OBU
On-Board Unit
OEM
Original Equipment Manufacturer
OS
Operating System
viii
D5.2: Proof of Concept Use Case Specifications
OSEK
Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug
OSGi
Open Service Gateway initiative
OVERSEE
Open Vehicular Secure Platform
PAN
Personal Area Network
PCIe
Peripheral Component Interconnect Express
PCO
Point of Control and Observation
PER
Packed Encoding Rules
PKI
Public Key Infrastructure
PLMN
Public Land Mobile Network
PoC
Proof of Concept
POI
Point Of Interest
PoS
Positioning Service
Pos-X-Link
Positioning Data Exchange Link
POSIX
Portable Operating System Interface (for UNIX)
PP
Protection Profile
PPP
Point-to-Point Protocol
PSAP
Public-Safety Answering Point
QoS
Quality of Service
RF
Radio Frequency
RFID
Radio-frequency identification
RSA
Rivest, Shamir and Adleman algorithm for public-key cryptography
RSU
Roadside Unit
RTOS
Real-time Operating System
S&D
Security and Dependability
SAP
Service Access Point
SAR
Security Assurance Requirements
SecS
Security Service
SFR
Security Functional Requirements
SKPP
Separation Kernel Protection Profile
SLAP
SLAP is a Lightweight Asynchronous Protocol
SMP
Symmetric Multi-Processing
SMS
Short Message Service
SPP
Serial Port Profile (Bluetooth Profile)
SRS
Software Requirements Specification
ix
D5.2: Proof of Concept Use Case Specifications
SSL
Secure Sockets Layer
SVAS
Secure Vehicle Access Service
SW
Software
TC
Technical Committee
TCP
Transmission Control Protocol
TECOM
Trusted Embedded Computing
Tetra
Terrestrial Trunked Radio
TGC
Trusted Computing Group
TLS
Transport Layer Security
TOC
Traffic Operations Centre
TPM
Trusted Platform Module
UC
Use Case
UMTS
Universal Mobile Telecommunications System
USB
Universal Serial Bus
V2I
Vehicle-to-Infrastructure
V2V
Vehicle-to-Vehicle
V2X
Vehicle-to-X
VM
Virtual MachineVMM
WAVE
Wireless Access for Vehicular Environment
WEP
Wired Equivalent Privacy
WG
Working Group
Wi-Fi
Wireless Fidelity
WP
Work Package
WPA
Wi-Fi Protected Access
XML
Extensible Markup Language
Virtual Machine Manager
x
D5.2: Proof of Concept Use Case Specifications
Document History
Version
Date
Changes
0.7
09-02-2012
Corrections according to TUB review comments
0.8
10-02-2012
Merged Modification from VW
0.9
10-02-2012
Several modifications according to comments from FOKUS
1.0
13-02-2012
Final design corrections
xi
D5.2: Proof of Concept Use Case Specifications
1 Introduction
1.1 Scope and Objective of the Document
This document contains the results of Task 5.2, the specification of use cases.
In Task 5.1, use cases have been selected and described, as written in Deliverable D5.1. In
this document, the selected use cases are specified providing a detailed description for the
implementation of these use-cases.
Use cases are divided into two categories, first, application use cases, which refer to
applications running on the OVERSEE platform to demonstrate the capabilities of the
platform. The second category, validation use cases, demonstrate the security and isolation
properties of the OVERSEE platform.
1.2 Document Outline
The rest of the document is structured as follows:

Section 2 contains the application use case specifications. Each use case is specified
in terms of its initial state, involved data, which modules and services of the OVERSEE
base system are used, and a detailed sequence description.

Section 3 contains the validation use case specifications. These are similar to the
specific application use case, with the adjustment that an attacker model is included.
1
D5.2: Proof of Concept Use Case Specifications
2 Use Case Specifications
Section 2 contains the application use case specifications. The aim is to provide a detailed
description of each use case by defining the involved data, software modules, peripherals
and the application flow. These use cases will be implemented by the consortium within the
task 5.3 and prepared for the demonstration within the work-package 6.
In detail, the following information is given for each use case specification:

Introduction
The whole use case is briefly described in this section to provide an overview for the
reader.

Initial state
The initial state of the OVERSEE platform, and other preconditions that must be
fulfilled, before the use case can be started.

Involved data
Any data that is needed for the use case is listed in this section.

Used modules and services
Involved modules and services of the OVERSEE platform that are needed as
dependencies.

Sequence diagram
The exact process is described here as a sequence diagram.

Description
A detailed textual description of the use-case is provided in this section.

Notable Changes and Justification
This section serves to notify the reader of any specifications in the use case which do
not comply with previous design specifications or descriptions in other OVERSEE
documents. This may happen due to e.g. technical issues or to highlight special
properties.
2.1 USB Flash Drive Media Access
2.1.1 Introduction
One of the main goals of OVERSEE is to provide a platform which is suitable for infotainment
applications1, e.g., multimedia player. The media files, typically the focus is on audio files to
avoid driver distraction, could be provided either via wireless networks, e.g., 2G/3G or WiFi,
or on a nomadic device, typically an USB memory stick. The current use-case describes the
1
C.f. satements from the OEMs at the first Advisory Board meeting of OVERSEE.
2
D5.2: Proof of Concept Use Case Specifications
connection of an USB memory stick to the OVERSEE platform and forwarding of the access
to the media files to a partition running an appropriate media player.
2.1.2 Initial State
The OVERSEE platform is running and one of the user partitions is executing a media player,
suitable for playing audio files in MP3 format. The user partition has the appropriate access
rights to a nomadic device connected via USB and containing the audio files.
2.1.3 Involved Data
2.1.3.1 OVERSEE configuration
The configuration of OVERSEE will be used to check whether a partition is allowed to access
files on a nomadic device or not. The list of partitions, which are allowed to access nomadic
devices, will be presented to the user for selecting the favored partition.
2.1.3.2 Media files on nomadic device
The audio files on the USB storage device will be accessed and played by the media player.
2.1.3.3 User authentication and user access rights
The operator of the platform has to be authenticated (in general this is the driver with
appropriate authentication via the car key) and, according to the security policy of OVERSEE,
authorized to allow forwarding of access to USB equipped memory devices to distinct
partitions. The authentication and authorization policies have to be present and suitable for
this use-case.
2.1.4 Used Modules and Services
Module or Service
USB Module
Tasks
Will be connected with the USB equipped nomadic device
Will be informed about the new USB device
USB Manager
Assign the memory of the USB device to the selected partition
Security Service
User authentication and authorization
Virtual storage device
driver in the selected
partition
Provide access to the memory of the USB device as a legacy
mass storage device to the applications
3
D5.2: Proof of Concept Use Case Specifications
Media Player
Show the available media files and playback options to the user
Play media files from attached USB storage device
2.1.5 Sequence Diagram
Figure 1: Media player sequence diagram
2.1.6 Description
A USB flash drive will be connected to the OVERSEE platform. The user has to be either
already authenticated in this moment (e.g. by car key) or requested for authentication (e.g.
by password based authentication). The user will be asked which partition should access the
files stored on the nomadic device. Therefore, the user selects the partition serving the
media player application. Finally the media player accesses the stored files and plays the
audio content.
4
D5.2: Proof of Concept Use Case Specifications
2.2 Emergency Vehicle Warning
2.2.1 Introduction
The use case “Emergency Vehicle Warning” describes an
application running in one of the OEM partitions of the
OVERSEE platform responsible for highly reliable and
highly available functions. This V2V-application generates
a warning within the instrument cluster of the OVERSEE’s
proof of concept vehicle when an emergency vehicle
approaches. This warning, which is addressed to the
driver, includes the course and the distance of the
approaching emergency vehicle.
Figure 2: Graphical
representation of the EVW
2.2.2 Initial State
The emergency vehicle is situated at a greater distance to the proof of concept vehicle and
starts heading towards it. The “Emergency Vehicle Warning” application is running on top of
the OVERSEE platform and subscribes on the ITS Manager for incoming CAMs and on the
SVAS for its own location, heading and vehicle speed.
2.2.3 Involved Data
2.2.3.1 Cooperate Awareness Messages
The emergency vehicle sends out CAMs with its position, heading, speed and status of the
light bar and siren.
2.2.3.2 Vehicle Dynamics and Positioning
To calculate the emergency vehicle warning, the application subscribes on the SVAS to read
the following data objects:

GeoPosition

VehicleSpeed

Course
5
D5.2: Proof of Concept Use Case Specifications
2.2.3.3 Positioning Metadata
To avoid bogus warnings, more detailed information about the position of the emergency
vehicle and the proof of concept car could be needed. This information can be derived out of
the vehicle’s navigation system, also provided by the SVAS. The following data objects give
more detailed information about the vehicle’s position, e.g. street name, road number or
point of interest and roadway classification regulated by national laws, e.g. Motorway,
Freeway, Highway or Local:

PositionInfo

RoadClass
2.2.3.4 Emergency Vehicle Warning Trigger Message
To initiate the emergency vehicle warning, the emergency vehicle warning application
triggers a function call including all necessary information on the SVAS that updates a CAN
message the instrument cluster is listen to. This function call is executed when a potential
concourse with the emergency vehicle occurs within the next fifteen seconds, including the
following information read by the instrument cluster:

Distance to the emergency vehicle

Course to the emergency vehicle
2.2.4 Used Modules and Services
Module or Service
ITS Manager
Tasks
Receive CAMs
Send application specific messages
SVAS
Provides the following Information:

GeoPosition

VehicleSpeed

Course

PositionInfo (optional)

RoadClass (optional)
Provides a function call to initiate the EVW within the
instrument cluster
6
D5.2: Proof of Concept Use Case Specifications
2.2.5 Sequence Diagrams
Figure 3: Emergency vehicle sends CAMs sequence diagram
7
D5.2: Proof of Concept Use Case Specifications
Figure 4: Proof of concept car generates warning sequence diagram
2.2.6 Description
Figure 3 shows how the emergency vehicle sends out CAMs described in 2.2.3.1 every 100
milliseconds. The sending part of the emergency vehicle subscribes for emergency vehicle’s
dynamics and positioning data described in 2.2.3.2 on the Secure Vehicle Access Service. A
CAM is generated and sent out.
Figure 4 shows how the proof of concept car generates an emergency vehicle warning. CAMs
are received and checked for authenticity by the OVERSEE’s security services (not depicted).
These validated messages are filtered for relevance and provided to applications by the
OVERSEE’s ITS manager, the emergency vehicle application subscribes to.
8
D5.2: Proof of Concept Use Case Specifications
In addition, the receiving part of the emergency vehicle warning application also subscribes
for vehicle’s dynamics and positioning data described in 2.2.3.2 on the Secure Vehicle Access
Service.
Within the main loop, the application determines the siren and light bar status of the
emergency vehicle. In the case of active siren and light bars, the distance and course to the
emergency vehicle are calculated. When a potential concourse with the emergency vehicle
occurs within the next fifteen seconds, a function call as described in 2.2.3.4 is executed.
2.2.7 Notable Changes and Justification
All necessary information like distance, heading and time to concourse of the emergency
vehicle are calculated by the application running on top of the OVERSEE platform but the
warning message itself is not generated by this kind of head unit. This warning message is
generated within the instrument cluster that cares about all safety-relevant warnings and
message priorities.
2.3 Sending an Emergency Call
2.3.1 Introduction
The use case “Emergency Call” describes an application running in one of the OEM partitions
of the OVERSEE platform responsible for highly reliable and highly available functions. This
V2X-application generates an automated emergency call in case of a trigger event (e.g.
accident). All relevant data according to eCall’s minimum set of data (MSD) are transmitted
via SMS and represented on the OVERSEE’s HMI.
2.3.2 Initial State
The “Emergency Vehicle Warning” application is running on top of the OVERSEE platform
and at least the ignition of the proof of concept vehicle is turned on. The application
subscribes on the SVAS (Secure Vehicle Access Service) to receive all relevant data according
to eCall’s minimum set of data and to the NPS (Network Provisioning Service) to be prepared
to send out the eCall SMS.
2.3.3 Involved Data
2.3.3.1 Vehicle Parameters, Positioning and Driver Information
To gather all necessary data for an eCall, the application subscribes on the SVAS to read the
following data objects:

VehicleIdentificationsNumber

GeoPosition

Course
9
D5.2: Proof of Concept Use Case Specifications

LocalTime

TankLevel

SeatBeltLock
o Remark: To determine the number of passengers
2.3.3.2 Short Message Service
All pre-processed data are sent via SMS to a figurative emergency operations centre, both as
plaintext and PER-coded. To perform the SMS, the application sends a function call to the
NPS (network provisioning service) including the recipient number and the content.
2.3.3.3 HMI
To trigger the prototypic eCall, a dedicated button of the OVERSEE’s HMI sends a function
call to the eCall application. The return value of this function call includes all data in plaintext
that is sent to the emergency operations centre, visualized on the OVERSEE’s HMI.
2.3.4 Used Modules and Services
Module or Service
Tasks
NPS
Sending the SMS containing the eCall data
SVAS
Provides the following Information:
HMI

VehicleIdentificationsNumber

Course

LocalTime

TankLevel

SeatBeltLock
Initiates the eCall
Visualizes the eCall data
10
D5.2: Proof of Concept Use Case Specifications
2.3.5 Sequence Diagrams
Figure 5: Trigger and send an eCall sequence diagram
2.3.6 Description
Figure 5 shows how an eCall message gets prepared and sent. The eCall application
subscribes for different vehicle’s parameters and positioning data as described in 2.3.3.1 on
the Secure Vehicle Access Service.
Within the main loop, the eCall application pre-processes the necessary data according to
eCall’s minimum set of data, including PER-coding and ASN.1-structuring.
The HMI triggers the eCall application to send out the eCall data, visualized to the driver.
2.3.7 Notable Changes and Justification
The feature eCall in the meaning of a series product is very complex. It is not possible to
fulfill all requirements within the OVERSEE project. A realistic implementation of eCall is out
of focus; thereby this prototypic implementation of an eCall application does not include
11
D5.2: Proof of Concept Use Case Specifications
either the transmission of data via in-band modem nor handover a voice channel to the
vehicle’s passengers.
2.4 Update Partition or OVERSEE Component
2.4.1 Introduction
The OVERSEE Software Update Service provides a central place to manage updates of
complete partitions who do not implement update mechanisms for themselves. In addition
to that it serves as an example for update mechanisms implemented in more complex multiapplication partitions.
The Update Service can update 3 different parts of the OVERSEE system:

The XEF file, i.e. the whole application in case of a single-application partition, the
kernel in case of a Linux partition

The file system image in case of a Linux partition

A file archive for updating the Secure I/O partition itself
2.4.2 Initial State
Consider an XtratuM partition with an application. This partition consists of a kernel
embedded into XtratuM as a XEF file, and a disk image with a file system. Now the software
vendor has created an updated kernel, disk image, or file archive, which he wants to
distribute. He has already packaged it, and, he has noticed the OEM of the update. The OEM
has entered the update into the Update Notification List.
Before updating, the application is still running from an older version of the file system
image.
2.4.3 Involved Data
2.4.3.1 Key Infrastructure
The OEM owns a signing key with a valid certificate enabling him to sign the update
notification lists. The certificate is issued and signed by the OEM’s CA and the chain of trust
traces to a root certificate that is considered trusted by the OVERSEE platform.
2.4.3.2 Update Notification List
The Update Notification List is a list of all current update announcements.
An update announcement consists at least of

An ID identifying the partition to be updated

A version number which is machine readable
12
D5.2: Proof of Concept Use Case Specifications

A short description targeted at the vehicle owner

Information, on which updates this update depends

A cryptographic hash value of the update package

The location of the update package
In addition to that, a digital signature over the whole list is attached, including all certificates
necessary to verify that signature.
For every distinct model of an OVERSEE instantiation a separate update list will be available,
but it is expected that these lists are subsets of a global update package pool, so that most
packages can be reused between different OVERSEE instantiations.
2.4.3.3 Update Package
The Update Package is a binary package consisting of two basic components:
 Meta data and machine-readable install instructions
o Version Number
o Target Partition ID
o Information about included update
 Type, one of
 XEF
 Whole file system
 File archive
 Specific data, e.g., file system ID if there are multiple file systems per
partition
o Optional: Install Scripts, Uninstall Scripts
 Compressed update data, one of:
o File system Image
o XEF file
o File Archive
2.4.3.4 Package Status Database
The package status database should contain information about every update packet that is
installed currently.

Partition ID

File system ID

Version of file system.
13
D5.2: Proof of Concept Use Case Specifications
2.4.4 Used Modules and Services
Module or Service
Communication Module
Tasks
Receiving update notifications
Downloading update package
Security Service
Secure transmission
User authentication
Update list and package authentication
HMI Service
Ask for user confirmation
Display progress
XtratuM Service
Control partition status (start/stop)
I/O-Service
Exchange raw file systems
SVAS
Engine status
14
D5.2: Proof of Concept Use Case Specifications
2.4.5 Sequence Diagrams
sd Softw are Update
Oversee Platform
Security Service
Update Manager
loop
XtratuM
IO
Manager
OEM
updateList= pollForUpdates()
ref
verifyList(updateList)
v erifyList
updatesToBeInstalled=
determineUpdates()
opt
updatePackage= downloadUpdate(updateID)
[engineOff]
verifyPackageHash(Package)
mayUpdate=
askPernission() :bool
ref
askPermission
ref
executeUpdate
Figure 6: Software update sequence diagram
15
D5.2: Proof of Concept Use Case Specifications
sd askPermission
Security Service
Owner
HMI Manager
opt
askForAuthentication()
[not Authenticated]
askForPermission()
Figure 7: Permission request sequence diagram
sd v erifyList
Security Service
verifyList(updateList)
listHash=
calculateHash(updateList)
verifyCertificate(certificate)
verifyCertificate(rootCA)
verifyCertificate(intermediateCAs)
verifySignature(listHash,
signature, certificate)
Figure 8: Verify software update list sequence diagram
16
D5.2: Proof of Concept Use Case Specifications
sd executeUpdate
IO Manager
Update Manager
XtratuM
alt
[type == XEF] replaceXEF(partitionID, XEFFile)
newXtratumObject=
linkTogether(XEFFiles)
reboot(newXtratumObject)
alt
[type == Partition]
stopPartition(partitionID)
replaceFileSystem(fileSystemID)
startPartition(partitionID)
alt
stopPartition(partitionID)
[type ==Files]
mountFileSystem(fileSystemID)
unpackFilesTo(updatePackage,
fileSystemID)
startPartition(partitionID)
Figure 9: Execute software update sequence diagram
2.4.6 Description
The Update Manager is periodically polling a dedicated server (e.g. update announcement
server), where all available updates are collected in form of a list.
After download, the list is verified against the root certificate by the security service to make
sure that the list is approved by the owner of a valid certificate that allows software
upgrades to be issued.
17
D5.2: Proof of Concept Use Case Specifications
All update announcements are checked if they apply to the current system. If yes, the
update manager waits for a suitable moment to ask the owner for approval. This should be
the next time the vehicle engine is not running.
When the owner approves the update and authenticates himself, the download of the
update package is started.
Upon completion, the update manager lets the Security Service verify the package’s hash,
that means, the Security Service calculates a hash value over the package contents, and
compares to the corresponding hash value previously downloaded list of announced
updates.
If all checks have been successful, the package is installed, that means:

The update manager stops the respective partition.

The update manager replaces the old content with the content of the update
package in such a way, that the old content can be restored.

The update manager starts the partition.

If any serious error occurs during this procedure, the procedure has to be aborted
and the partition must be restored to its state before the update.
2.4.7 Notable Changes and Justification
It is vital that the update process is very reliable, so a proven existing solution will be
adopted to provide the backbone of this use-case. It is possible that the configuration
capabilities of these solutions do not base on xml as stated in Deliverable 2.2 and hence
cannot fulfill the configuration requirements.
2.5 Cooperative Platoon Automation System
2.5.1 Introduction
The use case “Cooperative Platoon Automation System” describes a V2V-application running
on top of the OVERSEE platform. The Platooning Application enables automated velocity and
steering control of a vehicle group (platoon) in order to let the vehicles travel closely one
behind another. Driving inside a platoon promises to enhance traffic safety and to reduce
fuel consumption.
2.5.2 Initial State
The platoon should already be established. It should consist of a leading vehicle and at least
one following vehicle. The structure of the platoon and the role of each vehicle is appointed
and known to all participants. Messages of participating vehicles inside a platoon are
recognized by a vehicle id, which should be contained equally in all messages. Pseudonymchange should be locked during the lifetime of the platoon to avoid changes of the vehicle
18
D5.2: Proof of Concept Use Case Specifications
id. Alternatively, the optional update process described in section Update Procedure
(optional) may be used.
The initial state may be set by configuration or alternatively reached through the optional
join procedure described in section Join Procedure (optional).
2.5.3 Involved Data
2.5.3.1 V2X Message Types for Vehicle Coordination
Besides sensor values, a number of different V2X message types is used for coordination of
vehicles inside a platoon. In particular, vehicles are coordinated through regularly
broadcasted messages like CAMs, DENMs, and optionally additional application specific
messages, as described below.
Cooperative Awareness Messages
Most information required for coordination is already contained in regularly broadcasted
CAMs. Relevant fields for the Platooning application are:

Position

Speed

Heading

Acceleration

Confidence of the values above
Decentralized Environmental Notification Message
Several environmental notification messages indicate critical situations that are essential for
coordination. Especially, the following DENM subjects might be of special interest:

Dangerous Driving – Hard brake vehicle
Platoon Coordination Message (optional)
Additional information, which is not part of the previously described message types, might
be exchanged regularly through application specific messages. Platoon Coordination
Messages contain optional data that complements CAMs and DENMs but does not replace
them, e.g.

Lane specific information

More precise location information, in terms of spatial and/or time-wise accuracy
This message type is most probably not necessary for a proof-of-concept implementation.
2.5.3.2 V2X Message Types for Platoon Management
Platoon management comprises all tasks to organize a platoon including join, update, leave,
and dissolve procedures, as well as distributing the platoon structure to participants and
announce platoon information to surrounding vehicles. In contrast to vehicle coordination,
19
D5.2: Proof of Concept Use Case Specifications
platoon management cannot be mapped on standardized message formats, but must be
implemented with application specific message types.
Platoon Announcement Message
A Platoon Announcement Message describes the current platoon structure and consists of
the information below.

Ordered platoon participant list, including the following data for each participant
o Position in platoon

The leader on first position

Following vehicles on positions 2, 3, etc.
o Vehicle ID

Unique Node ID that is mapped to the vehicles signer certificate

This ID appears also in CAMs and DENMs in order to assign messages
to specific vehicles.
Platoon Request Message (optional)
A Platoon Request Message allows platoon followers to ask or notify the leader on changes
of their platoon participation. It consists of the following fields:

Request type, with one of the values
o JOIN (to indicate the wish to join a platoon as follower)
o UPDATE (to inform the leader on important changes, e.g., id change)
o LEAVE (cancel platoon participation and leave platoon)

Optional data, e.g., the new vehicle id
Platoon Advertisement Message (optional)
Platoon Advertisement Messages inform surrounding vehicles about the platoon, in
particular about its

Destination
This message type is most probably not necessary for a proof-of-concept implementation.
2.5.4 Used Modules and Services
Module or Service
ITS Communications
Tasks
Receive CAMs, DENMs, and application specific messages
Send application specific messages
Read vehicle/node id
Lock/unlock change of vehicle/node id
SVAS
Read distance sensors and/or radar
20
D5.2: Proof of Concept Use Case Specifications
Read speed, steering-angle and further values
Car Control Service
Access all available vehicle controls for automatic driving.
(Non-OVERSEE)
2.5.5 Sequence Diagram
Figure 10: Message sequence chart of the Platooning use case
21
D5.2: Proof of Concept Use Case Specifications
Figure 11: Platooning from the view of a follower vehicle
2.5.6 Description
The operation of the Platoon application is separated into two mostly independent
components: the “real-time” coordination of the vehicle’s routes and the management of
the platoon structure.
2.5.6.1 Vehicle Coordination
Vehicle coordination ensures that vehicles inside a platoon coordinate their velocity and
lateral position to stay in a line one after another. Besides (distance) sensor values, mainly
V2V messages are used for that. As described in section 2.5.3.1 several message types are
involved including conventional CAMs and DENMs. These messages are generally
unencrypted but should be signed to avoid possible attacks. Except of DENM, which are sent
only in special situations, all messages are sent periodically with preferably high frequency
(at least 1 message per second). Figure 10 visualizes the process.
22
D5.2: Proof of Concept Use Case Specifications
Coordination messages are always broadcasted. Hence, each vehicle must know the
structure of the platoon to filter incoming messages and regard only that ones from vehicles
inside the platoon, which are driving ahead. Consequently, participants of a platoon must
maintain a platoon map that consists of an ordered list of all platoon participants. The next
section describes the process to keep the list up to date. Figure 11 shows an overview to the
Platooning application from the view of a follower vehicle.
2.5.6.2 Platoon Management
Platoon management comprises the whole organization of the platoon including join, leave,
and update procedures.
The platoon leader sends Platoon Announcement Messages (PAM) on changes of the
platoon to inform participants about the current platoon structure. Addressees are only the
following vehicles inside the platoon, so that instead of broadcasting PAMs, encrypted multicast communication (respectively encrypted single-cast to each participant, if multi-cast is
not available) may be used in order to increase privacy of the platoon participants.
Each of the following procedures, results in sending an updated announcement message (at
least if it was successful). The announcement is also a confirmation for the according
requests.
Join Procedure (optional)
Vehicles who want to join a platoon execute the following procedure:

The vehicle sends a join request (Platoon Request Message of type JOIN) to the
platoon leader.

If the leader accepts the vehicle to be a member of the platoon, he sends an updated
Platoon Announcement Message to the platoon participants including the newly
joined vehicle.

The vehicle takes its position in the platoon and switches to automatic driving
following the vehicles ahead.
Leave Procedure (optional)
A following vehicle may leave the platoon with the following procedure:

The vehicle sends a leave request to the platoon leader.

The platoon leader sends an updated Platoon Announcement Message to the
platoon participants, which does not contain the leaving vehicle any longer.

The vehicle leaves the platoon.
Update Procedure (optional)
An update request is needed in particular on changes of the vehicle id of a platoon
participant. Since other vehicles are not able to map messages with a changed id to a
platoon member, the id-change has to be published to the platoon leader who updates the
platoon announcement. In detail the procedure is:

A vehicle recognizes a pending id-change. Before the id-change takes place, the
vehicle sends an update request (Platoon Request Message of type UPDATE)
23
D5.2: Proof of Concept Use Case Specifications
containing the new id to the platoon leader. This request is still signed with the old
id.

The id-change is performed. Afterwards, the vehicle confirms the id-change by
resending the update request to the platoon leader. This time it is signed with the
new id.

The platoon leader sends an updated Platoon Announcement Message to the
platoon participants, which contains the new vehicle id.
Dissolve Procedure (optional)
The platoon leader may dissolve the platoon at any time, at the latest when arriving at its
destination. To avoid safety critical situation the platoon should be stopped before
dissolving. The following process dissolves the platoon:

The platoon leader sends an empty Platoon Announcement Message.
A more sophisticated approach would allow dissolving a moving platoon by warning drivers
through HMIs and ensuring that each driver takes the control over his vehicle back.
Nevertheless, this proof-of-concept implementation/specification is suited for model cars
without drivers and HMIs and does not regard this issue.
2.5.7 Notable Changes and Justification
This use case was not part of the initial use case list, which was defined in D1.1. The reason
behind that fact is that D1.1 concentrated on near-term use cases and excluded safety
critical use cases. Within work package 5, the need of long-term use cases was recognized
and as a result D5.1 introduced the Platooning use case. Since then the use case remained
unchanged; even the optional parts were maintained. However, these optional parts
(including join, leave, and update procedures) will most probably not be implemented for
the demonstrator, because the focus is more on the main part that is required for the
validation use cases.
In order to implement autonomous driving manoeuvres, this use case makes use of an
automatic driving component, which is not part of the OVERSEE platform. This component is
pre-existing knowledge as part of the model car platform and will not be delivered together
with the use case implementation.
2.6 Active Brake
2.6.1 Introduction
The use case Active Brake is an application running on top of the OVERSEE system. The use
case demonstrates how V2X-messages may lead the vehicle to a safety reaction. Therefore,
Decentralized Environmental Notification Messages (DENM) are broadcasted to surrounding
(in particular following) vehicles, which indicate a road hazard (e.g., an hard braking vehicle).
Based on these notifications and/or sensor values (e.g., distance sensors or radar), drivers in
the relevance area are warned and in case of emergency their cars are actively braked to
avoid a crash.
24
D5.2: Proof of Concept Use Case Specifications
2.6.2 Initial State
The Active Brake Application subscribes on the ITS Communications Service for incoming
“hard brake vehicle” events. Additionally, it registers on SVAS to observe the brakes for an
emergency braking.
2.6.3 Involved Data
2.6.3.1 Decentralized Environmental Notification Message
The DENM is broadcasted via V2X and delivered internally (in a more abstract form) to the
Active Brake Application. Based on the ETSI specification [1], it contains at least the following
values:

Situation information, including
o
Cause code and sub cause code, e.g.

101 (Dangerous Driving)
 1 (Hard brake vehicle)

102 (Intersection violation)
 1 (Stop sign violation)
 2 (Traffic lights violation)
o Severity level, with


1 for relatively low safety impact

4 for high safety critically events
Location information, including
o Exact geographic event position
o Relevance area

Management information, including
o Generation time
o Expiry time
2.6.3.2 HMI Warning Message
The warning message should be displayed visually or acoustically on an HMI device. The
message contains the following data values:

Reason, e.g., “Hard brake vehicle” or “Stop sign violation”

Distance in meters to the hazardous location
25
D5.2: Proof of Concept Use Case Specifications
2.6.4 Used Modules and Services
Module or Service
ITS Communications
Tasks
Receive Decentralized Environmental Notification Messages
Send Decentralized Environmental Notification Messages
HMI
Display visual or acoustic warning message
SVAS
Read distance sensors and/or radar
Read brake status
Car Control Service
Trigger emergency brake
(Non-OVERSEE)
2.6.5 Sequence Diagram
Figure 12: Detection and broadcasting of warning events
26
D5.2: Proof of Concept Use Case Specifications
Figure 13: Incoming V2X messages lead to safety reaction
2.6.6 Description
Various events, such as a hard breaking of a vehicle, may cause a road hazard warning. These
warnings are encoded as and broadcasted via the V2X network. Events regarded for the
Active Brake use case are “Emergency electronic brake lights” and for the alternative variant
“Signal violation warning”. Receiving vehicles analyse these event notifications for relevance
according to their actual position, driving direction, and speed. If the vehicle is located in the
relevance area, a warning message is delivered to the driver. After falling below certain
distance to the event, the Active Brake Application triggers an automatic emergency brake
and broadcasts an additional emergency brake notification to following vehicles.
2.6.7 Notable Changes and Justification
The first description of this use case in D1.1 was not meant to be a long-term use case.
Hence, all safety relevant parts were excluded. However, work package 5 decided to include
also the long-term aspects such as real active breaking instead of only displaying warning
messages.
In order to implement automatic emergency braking, this use case makes use of an
automatic driving component, which is not part of the OVERSEE platform. This component is
pre-existing knowledge as part of the model car platform and will not be delivered together
with the use case implementation.
27
D5.2: Proof of Concept Use Case Specifications
3 Validation Use Case Specification
3.1 USB Flash Drive Media Access
3.1.1 Introduction
The availability of access to nomadic devices usually causes a high risk of attacks, by using
manipulated files opened by the unaware user of the platform. Indeed, manipulated files
could be provided to the media player of OVERSEE. Nevertheless, due to the isolated
runtime environments and the protected interfaces between the OVERSEE components; the
effects will be limited to the partition executing the media player.
3.1.2 Attacker Model
An external attacker (could be also the user of the platform) is assumed to be able to
manipulate files (e.g., audio files) which will be stored on a nomadic device, which will be
probably connected to the OVERSEE platform in a reasonable amount of time.
3.1.3 Additional Components

Manipulated files
These files are stored on a nomadic device equipped with an USB interface which will be
probably connected to the OVERSEE platform. Thus, access to the modified files will be
provided to the media player installed in one partition of the OVERSEE platform. The files
are modified by the attacker to harm either other partitions or the platform with its
capabilities, e.g., in terms of in-vehicular communication.
3.1.4 Sequence Diagram
See Figure 1 concerning the connection of nomadic devices via USB, consider the files stored
on the attached device as manipulated.
3.1.5 Description
An attacker modifies media files which will be provided to the medial player, executed in
one partition of the OVERSEE platform, by use of an USB equipped nomadic device. Due to
the isolation properties and the protected interfaces in OVERSEE, the consequences will be
limited to the partition executing the media player. Thus, no serious safety or security
problems will occur.
28
D5.2: Proof of Concept Use Case Specifications
3.2 Emergency Vehicle Warning / E-Call
3.2.1 Introduction
Functions with the requirement of high reliability and availability like Emergency Vehicle
Warning and E-Call have to be executed in isolated domains of OVERSEE.
This is done in order to eliminate influences of other applications with different security and
dependability requirements.
To validate the isolation mechanisms of OVERSEE, an exemplary scenario with a faulty third
party application, which causes a crash of an operating system within the open domain, will
be assumed.
Mechanisms to identify attacks against V2X-Communications or insertion of manipulated
software are shown in other use cases within the model car demonstration and the platform
demonstration.
3.2.2 Attacker Model
Not applicable. It is assumed that the third party application that crashes the operating
system behaves unintentionally faulty.
3.2.3 Additional Components

Faulty third party application
This application is installed and executed in the partition responsible for third party
applications (open domain).
As an example, this application will provide additional information to the navigation
system in order to find free parking lots in one’s proximity.
3.2.4 Sequence Diagram
The procedures of Figure 4 and Figure 5 remain unchanged. The third party application is
executed in parallel.
3.2.5 Description
The third party application is executed right before the use cases start. The faulty behavior
of the third party application is triggered remotely. Due to the isolation properties of
OVERSEE, the consequences will be limited to the partition executing the faulty application.
Assuming that the isolation capabilities of the OVERSEE platform work correctly, the
behavior of EVW and E-Call remain unchanged.
29
D5.2: Proof of Concept Use Case Specifications
3.3 Update Partition
3.3.1 Introduction
In this misuse case an attacker aims to inject malicious software into an OVERSEE partition
via the update functionality.
3.3.2 Attacker Model
An external attacker is assumed. He has control over the environment of the vehicle (i.e.
wireless communication), but he has no internal access to the vehicle systems or the OEM’s
systems. He may therefore manipulate external communication.
3.3.3 Additional Components

OEM Impersonation
The attacker has to be able to intercept and fake the necessary communication, for
example by providing a Wi-Fi access point with a fake DNS server and a fake server
for updates and update announcements.

Malicious update package
The attacker has to build a malicious update package by changing a legitimate
package or by creating one from scratch.
The hashes, cryptographic signatures and certificates can be omitted or faked to a
certain degree:
o Simple omission
o Hash does not fit to package
o Changed update list
o Certificate with different public key
o Different Intermediate certificates
o Different Root certificate
30
D5.2: Proof of Concept Use Case Specifications
3.3.4 Sequence Diagram
sd Softw are Update Misuse
Oversee Platform
Security Service
Update Manager
XtratuM
IO
Manager
OEM
Attacker
loop
updateList= pollForUpdates()
ref
v erifyList
verifyList(updateList)
updatesToBeInstalled=
determineUpdates()
opt
updatePackage= downloadUpdate(updateID)
[engineOff]
verifyPackageHash(Package)
Must Fail
ref
askPermission
mayUpdate=
askPernission() :bool
ref
executeUpdate
Figure 14: Attack on the software update process
3.3.5 Description
The process is very similar to the process described in section 2.4, except that the attacker
impersonates the OEM.
He provides a fake update announcement list and provides fake update packages.
The OVERSEE platform will recognize this at one of the two verify steps, as the attacker
cannot fake full valid cryptographic signatures or hashes.
31
D5.2: Proof of Concept Use Case Specifications
3.4 Platoon
3.4.1 Introduction
In this misuse case, an attack against the V2X communication is assumed.
3.4.2 Attacker Model
The attacker has access to V2X communication, but not to internal components. To bypass
security mechanisms he may use different approaches, which differ in their prospect of
success:

Usage of a self-signed certificate

Replay of already signed messages

Misuse of a valid certificate
3.4.3 Additional Components

ITS Communication stack
The attacker needs to own a complete OVERSEE ITS Communication stack, including
hardware and software components or a compatible equivalent.

Certificates
To bypass ITS security mechanisms messages have to be signed. Therefore, valid
certificates are necessary.

Application logic/messages
Manipulation of an actual application needs understanding of the application logic.
For simple attacks, a manipulated application specific message may be sufficient.
3.4.4 Message Sequence Diagram
Figure 15: Attack trying to hijack a platoon
32
D5.2: Proof of Concept Use Case Specifications
3.4.5 Description
Figure 15 givers an overview how to hijack a platoon. Note that position updates are always
broadcasted, but here only relevant receivers are shown that navigate based on this data.
The attacker tries to impersonate the role of the platoon leader. The approach would be:
1. Send a faked Platoon Announcement message that contains a manipulated list of
platoon participants with the attacker as platoon leader. This step is vital for the
success of the attack; if any receiver figures out that the platoon leader is not the
sender of the announcement message, he will reject it. Possible approaches are:
a. Use a self-signed identity
b. Manipulate a captured message
c. Use a stolen identity
2. The platoon members recognize the changed platoon structure and start following
the attacker.
3. Broadcast manipulated position updates that lead the platoon on the desired route.
Countermeasures: OVERSEE verifies incoming messages, with the result that
a. invalid sender identities are recognized by verifying the certificate,
b. manipulated messages are detected by verifying its signature, and
c. stolen identities are invalidated by revocation.
Hence, the receiver detects and discards manipulated messages and the attack should fail
after step 1.
3.5 Active Break
3.5.1 Introduction
In this misuse case, a replay attack against the V2X communication is assumed.
3.5.2 Attacker Model
The attacker has access to V2X communication, but not to internal components. To bypass
security mechanisms, the attacker captures messages that are already signed by other
communication participants. The attacker may replay a message in order to pretend a
situation, which was specified within the captured message. The attacker is not able to
change the content of the signed message without invalidating it. Hence, the location of the
attack must be the initial location of the event. To prevent the attack from being revealed, a
message should never be sent twice to the same vehicle. Additionally, the attacker has only
a short time window in which the message is regarded as being valid.
33
D5.2: Proof of Concept Use Case Specifications
3.5.3 Additional Components

Wireless communication module
The attacker needs to own a wireless communication module that is compatible to
OVERSEE ITS communications and allows capturing and replaying specific messages.
3.5.4 Message Sequence Diagram
Figure 16: Replay attack to fake a hard braking vehicle
3.5.5 Description
The attack against the Active Brake use case proceeds as shown in Figure 10:
1. The attacker captures a DENM with the cause “Hard brake vehicle”. This could
happen just by randomly observing vehicles or by provoking an emergency brake,
e.g., physically or by using this attack.
2. Later the DENM can be replayed to vehicles in the DENM’s relevance area that did
not capture the original message. In this manner, the replay-attack will not be
recognised.
3. The attacked vehicle will trigger automatically an emergency brake.
4. If step 3 was successful, the attacked vehicle will broadcast a DENM indicating the
hard-brake event. Using this newly generated DENM, the attack may be repeated
recursively.
Countermeasures: OVERSEE verifies incoming messages, with the result that
a. message hashes are stored to detect replay attacks, and
b. timestamps are checked to discard old messages.
Hence, the receiver detects and discards the replayed messages and the attack should fail
after step 2.
34
D5.2: Proof of Concept Use Case Specifications
References
[1]
ETSI: TS 102 637-3 V1.1.1. Intelligent Transport Systems (ITS); Vehicular Communications; Basic
Set of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic
Service. Sep 2010.
[2]
DIN: EN 15722, Intelligent transport systems – eSafety – eCall minimum set of data (MSD);
German version EN 15722:2011. Oct 2011
[3]
OVERSEE: D5.1 Proof of Concept Use Cases. 2011
[4]
OVERSEE: D2.1 List of interfaces and specifications of information flow. 2011
[5]
OVERSEE: D2.4 Specification of Secure Communication. 2011
35