COOPERS Architec PDF

COOPERS
Co-operative Networks for Intelligent Road Safety
WP3000
Report on ITS framework reference Architecture
D13-B-IR3100-2
V 3.0
Release
Susanne Fuchs
Hi Tech
+43 1 7182530
sf@hitec.at
Status
Date
Draft
15-02-2008
Reviewed
07-03-2008
Approved
12-06-2008
Function
Name
Organisation
Phone
Fax
E-Mail
Approval
Prof.Thomas Richter
TU Berlin
+49 30 314 72 604
richter@ils.tu-berlin.de
COOPERS
integrated project
Contract Number:
FP6-2004-IST-4 Nr. 026814
Acronym:
COOPERS
Title:
Co-operative Networks for Intelligent Road Safety
Distribution:
Part.Nr.
short Participant name

name
Nationality
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
ATE
HIT
SEI
ARS
SWA
EYF
ASF
FAV
ORF
TUW
ASC
TRG
IPW
OBB
DOR
GEW
BRE
VEG
TUL
LUC
TRA
FHG
EFM
EFK
VTI
KTH
NET
STH
INO
APP
ICI
TUC
KYB
JAS
BMW
NAV
Austria
Austria
Austria
Netherlands
Austria
Italy
Austria
Germany
Austria
AustriaTech Gesellschaft des Bundes fr technologiepolitische Manahmen

Vereinigung High Tech Marketing
ARC Seibersdorf Research GmbH
ARS Traffic and Transport Technology B.V.
Swarco Europe GmbH
Ernst and Young Financial Business Advisors S.p.A.
ASFINAG - Autobahnen- und Schnellstraen-Finanzierungs- Aktiengesellschaft
Forschungs- und Anwendungsverbund Verkehrssystemtechnik Berlin
sterreichischer Rundfunk
Left intentionally blank
Technische Universitt Wien
Ascom Switzerland Ltd
University of Southampton
IPW Ingenieurgesellschaft Prof. Werner mbH
Oberste Baubehrde im Bayerischen Staatsministerium des Innern
Dornier Consulting GmbH
GEWI Hard- und Software Entwicklungsgesellschaft mbH
Autostrada del Brennero
VEGA Informations-Technologien GmbH
Politechnika Lodzka
Lucent Technologies Network Systems GmbH
TRANSVER GmbH
Fraunhofer-Gesellschaft zur Frderung der angewandten Forschung E.V.
EFKON mobility GmbH
EFKON AG
Statens vg- och transportforsknings-institutet
Kungliga Tekniska Hgskolan
TeamNet International S.A.
S&T Hermes Plus
INESC Inovao Instituto de Novas Tecnologias
LGAI Technological Center S.A.
National Institute for Research Development in Informatics
Technical University of Crete
Kybertec, s.r.o.
JAST Srl
Bayerische Motoren Werke Aktiengesellschaft
NAVTEQ B.V.
Reference Architecture 2.0

Page 2 of 159
Austria
Switzerland
United Kingdom
Germany
Germany
Germany
Germany
Italy
Germany
Poland
Germany
Germany
Germany
Germany
Austria
Sweden
Sweden
Romania
Slovenia
Portugal
Spain
Romania
Greece
Czech Republic
Switzerland
Belgium
Germany
Netherlands
COOPERS
integrated project
Document History:
Version
0.1
0.2
0.2
0.3
0.4
0.5
0.6
0.7
0.8
1.0
1.1
1.2
Date
20.07.2006
30.08.2006
15.09.2006
13.11.2006
22.11.2006
24.11.2006
18.12.2006
25.01.2007
01.02.2007
09.02.2007
14.09.2007
14.12.2007
Released by
Katrin Hirschmann
Alexander Froetscher
Katrin Hirschmann
Katrin Hirschmann
Katrin Hirschmann
Katrin Hirschmann
Katrin Hirschmann
Katrin Hirschmann
Katrin Hirschmann
Katrin Hirschmann
Thomas Scheider
1.3
2.0
2.0
2.0
31.01.2008
15.02.2008
15.02.2008
15.02.2008
Thomas Scheider
2.1
07.03.2008
Alexander Froetscher,
Thomas Scheider
3.0
12.06.2008
Description
Document Drafted
Revision of document
functions added and revised
revision of document
architecture relevant
finalization with first service set
finalization with COOPERS services
final version, status released
revision of the final version
service description tables (version from
6.12.2007)
Revision of chapter 2.3, 2.4,
Revision of chapter 3, several updated
Added chapter 4.2 and 9
Cooperation status added, status
released
Revision according to peer review
comments, status approved
Accepted

Page 3 of 159
COOPERS
integrated project
Executive Summary
The COOPERS project has the focus on development and implementation of co-operative systems
to make roads traffic safer, more predictable and more controllable in terms of the individual driver
behaviour. The functional objective of COOPERS is therefore to use co-operative systems of
information and communication technologies to provide infrastructure, vehicles and Traffic Control
Centers with technical intelligence to be able to develop measures to achieve safer and more
efficient traffic flow on the existing road infrastructure.This document contains the ITS System
Architecture defined in the project and is the basis for the development work.The COOPERS ITS
reference architecture was created for the following reasons:
To define a High level ITS system architecture in line with the stakeholder aspirations of the road
operators, but also other project partners, which evolve dynamically in the corse of COOPERS e.g
for adaptation to test sites, and after the project work.
To define core functionalities in line with existing systems and additional elements with reference to
standards and recognized interfaces, but also to standard tools and processes for system operation.
To be able to adapt to future technologies, standards and developments in a dynamic way.
The WP2000 group has analysed and summarised the main user needs for new services and
identified these new services called COOPERS services:
Primary services:
S1a/b/c: Accident/Incident/Wrong-way driver Warning
S2: Weather Condition Warning
S3: Roadwork Information
S4a/b/c: Lane Utilization Information
S5: Variable Speed Limit
S6: Traffic Congestion Warning
Secondary services:
S7: ISA with Infrastructure Link
S8: International Service Handover
S9: Road Charging to Influence Demand
S10: Estimated Journey Time
S11: Recommended Next Link
S12: Map Information Check
A description on the main user needs, the process how the new services were identified, and the
assessment of their potential impact can be found in [COOPERS4]. Based on this output, the
WP3000 group developed the high-level system requirement specification, which is attached to this
document in Annex 2: service description tables, and selected the user needs according to the
FRAME methodology. Additional user needs, which are not covered by the EITSFA, have been
identified and defined. They are listed in section 6.2.
The services are categorized into two groups: primary and secondary. Primary services are, because
they are mainly under control of motorway operators, those which will be implemented in the
demonstrations of the COOPERS project and address e-Safety issues directly. Secondary services
are those services which address navigation and driver/management support in a more general
sense and where a collaboration of the infrastructure operators with other partners seems likely. It
has to be stressed that categorization of "primary", and "secondary" is not for rating the importance
of the services, but rather for showing the different path to realization/implementation. For the
development of the COOPERS architecture the whole set of services is elaborated and mapped.
Page 4 of 159
COOPERS
integrated project
Starting from the fact that COOPERS has the main focus on infrastructure-to-vehicle communication
the result of the physical architecture identifies 4 locations (called sub-systems):
COOPERS Central Sub-system (P23.1)
COOPERS Roadside Unit (P23.2)
COOPERS On-board Unit (P23.3)
COOPERS-compliant Portable Device (P23.4)
For making a breakdown of these sub-systems several modules for describing the functionalities of
the services in more detail were defined. These modules can be the basis for further component
development for WP 4000. After the next process steps inside COOPERS finally also the external
ones in cooperation with other projects and the path to a EU Framework Architecture are sketched.
Page 5 of 159
COOPERS
integrated project
List of Abbreviations and Acronyms

AASHTO
ACC
ADAS
AIDE
API
ASRB
CALM
COOPERS
CVIS
D
DAB
DATEX
DSRC
DOT
EASIS
ECU
EFC
FCD
FRAME
G
GPRS
GPS
GSM
GST
HGV
HL
HMI
HOV
I
I/O
I2V
ID
IEEE
IP
ISA
ISO/IEC
ITS
ITU-T
IVI
J2EE
J2SE
KAREN
LIN
American association of state and highway transportation officials

adaptive cruise control
advanced driver assistance systems
adaptive integrated driver-vehicle interface
application programming interface
automotive safety restraints bus
communications, air-interface, long and medium range (for ITS)
co-operative networks for intelligent road safety
co-operative vehicle-infrastructure system
deliverables
digital audio broadcast
data exchange
dedicated short range communication
departments of transportation
electronic architecture and system engineering for integrated safety
systems control unit
electronic
electronic fee collection
floating car data
framework architecture made for Europe
generation
general packet radio service
global positioning unit
global system for mobile communications
global system for telematics
heavy goods vehicle
high level
human machine interface
high occupancy vehicle
infrastructure
input/output
infrastructure to vehicle
identification
institute of electrical and electronics engineers, Inc.
internet protocol
intelligent speed adaptation system
international organisation for standardisation/international electrotechnical commission
intelligent transport system
International telecommunication Union Terminals for telematic services
intelligent vehicle infrastructure
Java 2 platform enterprise edition
Java 2 platform standard edition
keystone architecture required for European networks
local interconnect network
Page 6 of 159
COOPERS
integrated project
MOST
NetBSD
NoW
OBU
OEM
OSGi
PCI
PCMCIA
PReVent
PT
R&D
RDS-TMC
RM-ODP
RSE
RSU
TCC
UDP
UMTS
USDOT
V
V2I
V2V
VEESA
VII
VMS
WILLWARN
WLAN
media oriented systems transport

network Berkeley Software Distribution
network on wheels
on-board unit
original equipment manufacturer
open services gateway initiative
peripheral component interconnection
personal computer memory card international association
preventive and active safety applications
public transport
research & development
radio data system traffic message channel
Reference Model Open Distributed Processing
roadside equipment
roadside unit
traffic control centre
user datagram protocol
universal mobile telecommunications system
United States department of transportation
vehicle
vehicle to infrastructure
vehicle to vehicle
vehicle e-safety architecture
vehicle infrastructure integration
variable message signs
wireless local danger warning
wireless local area network
Page 7 of 159
COOPERS
integrated project
Table of Contents2.1
Approved
Executive Summary
List of Abbreviations and Acronyms
Table of Contents
Introduction
14
2.1
Scope of the document
14
2.2
Reasons for ITS architecture creation
14
2.3
European ITS Framework architecture history, tools and contents
15
Other recent Cooperative Systems activities
16
3.1
Vehicle Infrastructure Integration (VII United States of America)
16
3.2
Forerunning projects in the European Union
18
3.3
3.2.1
WILLWARN (a PReVENT Project)
18
3.2.2
GST
20
3.2.3
AIDE
22
3.2.4
EASIS
23
3.2.5
SpeedAlert
24
Running projects in the European Union

3.3.1
CVIS (co-operative vehicle-infrastructure system)
25
3.3.2
SAFESPOT
27
3.3.3
COMeSafety (communication for electronical safety)
29
3.3.4
Co-oporation between projects
30
Architectural Overview
4.1
25
32
FRAME guideline
32
4.1.1
Different FRAME viewpoints
33
4.1.2
Function groups and their sub-functions within FRAME
34
Definition of COOPERS services
36
5.1
COOPERS services
36
5.2
Additional requirements of the COOPERS services
36
5.3
5.2.1
Floating Car Data (S13)
36
5.2.2
Service Acknowledgement
37
Note on COOPERS services
37
Page 8 of 159
COOPERS
integrated project
6
Defined user needs
38
6.1
User Needs for COOPERS
39
6.2
New User Needs for COOPERS
42
Functional viewpoint
43
7.1
Functions for COOPERS system
43
7.2
New Functions for COOPERS system
45
Relations between COOPERS services and FRAME viewpoints
46
System Architecture physical viewpoint
51
9.1
Definitions of physical elements
51
9.2
Overview of the P23 COOPERS
53
9.3
System context diagram of the P23 COOPERS
53
9.4
Sub-systems of the COOPERS system
55
9.4.1
P23.1 COOPERS Central Sub-system
55
9.4.2
P23.2 COOPERS Roadside Unit
57
9.4.3
P23.3 COOPERS On-board Unit
59
9.4.4
P23.4 COOPERS-compliant Portable Device
60
9.5
10
11
12
Modules of P23 COOPERS
61
9.5.1
Modules for P23.1 COOPERS Central Sub-system
61
9.5.2
Modules for P23.2 COOPERS Roadside Unit
66
9.5.3
Modules for P23.3 COOPERS On-board Unit
69
9.5.4
Modules for P23.4 COOPERS-compliant Portable Device
72
9.5.5
Physical data flows
74
Adoption of the Reference Architecture to the Demonstration Sites
81
10.1
Demonstration Site 1
81
10.2
82
10.3
82
10.4
82
Next steps
83
11.1
UML architecture (SWP3200)
83
11.2
Communication viewpoint link analysis (SWP3300)
83
11.3
In-car networks Floating Car data (SWP3400)
83
11.4
Definition of new functions and requirements (SWP3800)
83
References
85
Page 9 of 159
COOPERS
integrated project
Annex 1: Summary of the functions
87
Annex 2: service description tables
98
Page 10 of 159
COOPERS
integrated project
Table of figures
Figure 1: COOPERS Architecture development process and context ............................................... 46
Figure 2: System Context Diagram..................................................................................................... 54
Figure 3: P23.1 COOPERS Central Sub-system diagram ................................................................. 56
Figure 4: P23.2 COOPERS Roadside Unit diagram .......................................................................... 58
Figure 5: P23.3 COOPERS On-board Unit diagram .......................................................................... 59
Figure 6: P23.2 COOPERS-compliant Portable Device diagram ....................................................... 60
Figure 7: P23.1 Central Sub-system P23.1.1 Provide Incident Management module .................... 62
Figure 8: P23.1 Central Sub-system P23.1.2 Provide Traffic Management module....................... 63
Figure 9: P23.1 Central Sub-system P23.1.3 Provide Environmental Conditions Assessment
module ......................................................................................................................................... 63
Figure 10: P23.1 Central Sub-system P23.1.4 Provide Safety Support for Maintenance
Management module ................................................................................................................... 64
Figure 11: P23.1 Central Sub-system P23.1.5 Provide Support for Emergency Management
module ......................................................................................................................................... 65
Figure 12: P23.1 Central Sub-system P23.1.6 Provide Support Traffic Violation Reporting module
..................................................................................................................................................... 65
Figure 13: P23.1 Central Sub-system P23.1.7 Provide Support for Road Charging module.......... 66
Figure 14: P23.2 COOPERS Roadside Unit P23.2.1 Provide Roadside Communications module 67
Figure 15: P23.2 COOPERS Roadside Unit P23.2.2 Detect Incidents module .............................. 68
Figure 16: P23.2 COOPERS Roadside Unit P23.2.3 Monitor Environment module....................... 68
Figure 17: P23.2 COOPERS Roadside Unit P23.2.5 Identify On-board Unit module..................... 69
Figure 18: P23.3 COOPERS On-board Unit P23.3.1 Provide On-board Communication Interfaces
module ......................................................................................................................................... 70
Figure 19: P23.3 COOPERS On-board Unit P23.3.2 Provide Speed Information and FCD module
..................................................................................................................................................... 71
Figure 20: P23.3 COOPERS On-board Unit P23.3.3 Provide Vehicle Position module ................. 71
Figure 21: P23.3 COOPERS On-board Unit P23.3.4 Perform Mayday Call module ...................... 72
Figure 22: P23.4 COOPERS On-board Unit P23.3.4 Provide Charging Information module ......... 72
Page 11 of 159
COOPERS
integrated project
Figure 23: Demonstration Sites planned within COOPERS ............................................................... 81
Page 12 of 159
COOPERS
integrated project
List of tables
Table 1: COOPERS User Needs ........................................................................................................ 42
Table 2: New COOPERS User Needs................................................................................................ 42
Table 3: Functions for COOPERS ...................................................................................................... 45
Table 4: New COOPERS Functions ................................................................................................... 45
Table 5: COOPERS service system central sub-system, modules, functions ................................ 48
Table 6: COOPERS service system on-board unit sub-system, modules, functions ...................... 49
Table 7: COOPERS service system roadside sub-system, modules, functions ............................. 49
Table 8: COOPERS service system personal device sub-systems, modules, functions ................ 50
Table 9: Physical data flows functional data flows within the COOPERS system (part 1) .............. 78
Table 10: Physical data flows functional data flows within the COOPERS system (part 2) ............ 79
Table 11: Physical data flows functional data flows within the COOPERS system (part 3) ............ 80
Page 13 of 159
COOPERS
integrated project
2 Introduction
This document is the first deliverable of the architecture and design work package of the COOPERS
project. The main parts of the document are the development of the functional and physical
architecture of the COOPERS system/project depending on the guidelines and approach of the
FRAME project (Framework Architecture made for Europe) from the European Commission.
2.1 Scope of the document

This document has the scope to describe the main functions of the COOPERS High Level (HL)
System Architecture for Intelligent Transport Systems (ITS) and the findings which lead to the
definition of this solution. As the whole COOPERS project architecture is based on the results of the
KAREN and FRAME project, it will also use the developed methodology and add co-operative
systems related functionality to this Framework. This means that also new functions for FRAME will
be defined from a COOPERS and/or road infrastructure management point of view.
COOPERS focuses at the Infrastructure to Vehicle (I2V) Communication for safety related
systems. The communication between the vehicle and the infrastructure will enable systems to be
developed to warn drivers of impending conflicts and of the status of devices such as traffic signal
controllers. A link between the vehicle and the infrastructure will allow the transmission of traffic
information and other messages, and this has to be built up in an architecture framework.
2.2 Reasons for ITS architecture creation

The transportation infrastructure and its control systems need data from infrastructure sensors and
vehicle sensors for efficient traffic management and control operations. For the COOPERS project
this is especially true for safety relevant operations. More reliable data from these sensors and their
combination will enhance the traffic management. Therefore the goal of ITS architecture is to provide
guidelines for the planning, design and implementation of ITS application and especially the data
flows between them. ITS architectures occur at different levels and views. They range from specific
structures, such as the layout of a communication system or the design principles for an individual
ITS element, to high-level concepts representing the underlying framework of a whole project.
The forthcoming development of transport telematics applications and the use of advanced
telematics technologies in modern transport systems their increasing complexity and the need of
integration and interoperability between systems is making a high level framework, especially
called HL system architecture, more necessary. Architectures provide strategic guidelines, and will
not only contain the technical elements, but also the organisational, legal and business aspects.
Furthermore an overall architecture specification ensures a quick prototype development and
enables interoperability of different services and applications.
The selection of the process based approach for the definition of the COOPERS ITS System
Architecture was agreed by the project partners at a very early stage of project development and
was further elaborated as a core element of the project in the subsequent phases. This reflected the
various positions in the system design and development phase and will be used during testing and
validation. The reference to standards as far as possible and the inclusion of standard interfaces to
Page 14 of 159
COOPERS
integrated project
existing systems was a second motivation for the approach. At the same time the defined ITS
Architecture is open to be adapted to single test sites and their respective subsystems and
components as well as to future technologies and standards, e.g CALM
2.3 European ITS Framework architecture history, tools and contents

The European ITS Framework Architecture provides guidelines and an approach to the planning,
development and implementation of ITS. The first version was developed in the European
Commision funded KAREN project with the focus on road-based ITS applications with eight major
functional areas.
The European ITS Framework Architecture is a large product, especially the Function Viewpoint is a
large document with defined areas: Traveller Journey Assistance, Traffic Management, Public
Transport Operations, Freight and Fleet Operations, Advanced Driver Assistance Systems, Safety
and Emergency Facilities, Support for Law Enforcement and Electronic Payment. Each area covers
many functions, data flows and data stores.
The FRAME projects (Framework Architecture made for Europe) were funded by the European
Commission and were a follow-up to the KAREN project. The linked projects (FRAME-net, FRAMES) promote to use the Framework Architecture and give support to the user.
FRAME consists of two main parts for creating subsets of the European ITS Framework Architecture
to develop their new ITS systems based on the European ITS Framework Architecture: The
Selection Tool and the Browsing Tool, which are parts of the Navigation Tool.
The overall Navigation Tool is providing two principal features:
The opportunity to browse through the European ITS Framework Architecture with the
related elements and their definitions.
The opportunity to select a sub-set of the European ITS Functional Viewpoint that complies
a sub-set of the European ITS User Needs for creating a Physical Viewpoint of that sub-set.
The FRAME Selection Tool is working with the European ITS functional viewpoint and the defined
user needs, stored in a relational database. The tool will help to select the elements functions,
functional data flows, data stores for the own project related requirements.
The FRAME functionality, which is the basis for the COOPERS architecture, will be described in
chapter 4.
Page 15 of 159
COOPERS
integrated project
3 Other recent Cooperative Systems activities

The first following sections are describing the surrounding of the comparison field of other European
projects and the Vehicle Infrastructure Integration (VII) from the United States of America.
3.1 Vehicle Infrastructure Integration (VII United States of America)

A number of research and development (R&D) projects and initiatives which have the main focus on
communication between vehicles and also communication between the transportation infrastructure
and vehicles are existing.
In Japan and the USA the main focus of the R&D projects is the vehicle to vehicle (V2V)
communication. As an example of an V2I project the US-American Vehicle Infrastructure Integration
(VII) program shall be described. This program is looking at the vehicle-infrastructure
communication, and therefore interesting for COOPERS.
The Vehicle Infrastructure Integration program is a cooperation between State Departments of
Transportations (DOTs) through the American Association of State and Highway Transportation
Officials (AASHTO), local government transportation agencies, Original Equipment Manufacturers
(OEMs) and the US Department of Transportation (USDOT).
The technical solution of the VII program is using Dedicated Short Range Communication (DSRC) as
communication medium for supporting the functional requirements of the system. DSCR is a wireless
communication technology that realises short-range communication between vehicles, and between
vehicles and the roadside infrastructure system.
VII has three main user groups, who are the main players within the project:
Drivers: can profit by increased safety, reliable traffic information and other additional
services
OEMs or car-manufactures: can update and improve their own vehicle and in-vehicle
systems and develop new services
DOTs: can obtain data from vehicle sensors for understanding of current road surface,
weather and traffic conditions. They also can send messages to passing vehicles for better
information and warning.
There are also additional commercial users in this project: Content Service Providers (CSPs) for
providing information, financial transactions, entertainment etc. and the Communication Industry for
providing the communications infrastructure to transmit the relevant data.
The identified use cases are based on the public sector safety, operations and maintenance
applications of VII:
Safety
Infrastructure-based Signalized Intersection Violation Warning
Infrastructure-based Signalized Intersection Turn Conflict Warning
Page 16 of 159
COOPERS
integrated project
Vehicle-based Signalized Intersection Violation Warning
Infrastructure-based Curve Warning
Crash Data to Public Service Answering Point
Crash Data To TOC
Advance Warning Information to Vehicles
Highway Rail Intersection
Commercial Vehicle Safety Data
Commercial Vehicle Advisory
Commercial Vehicle Electronic Clearance
Emergency Vehicle Preemption at Traffic Signals
Operation
Vehicles as Traffic Probes
Travel Time Data to Vehicles
Transit Vehicle Priority at Traffic Signals
Public Sector Vehicle Priority at Traffic Signals
Public Sector Vehicle Fleet/ Mobile Device Asset Management
Electronic Payment
Maintenance
Vehicle Probes Provide Weather Data
Vehicle Probes Provide Road Surface Conditions Data
VII would also support the development of applications with vehicle sensor data for the needs of
OEMs and other commercials.
Architectural specification
The architectural elements within the system to implement these use cases are:
On-board Equipment (OBE): source of data and main element for communication with other
entities, providing the human machine interface (HMI) for conveying information to the driver
Communications links: transmit information/ data to and from the vehicle. The
communication technology within VII is DSRC.
Roadside Equipment (RSE): is placed strategically across the country for data collection and
transmission. RSEs are sited at intersections and high risks sections for special safety
applications.
External applications: for example traffic operations centres (connected to the VII network)
receive data from vehicles/ roadside units and also send information to drivers, such as
safety-relevant warnings and traveller advisories.
Telecommunications network: supporting the data flow between all users, routing the
relevant messages/ information.
The VII network is designed for the needs of the public sector and the OEMs and as a result there
are two types of traffic data and network support:
Page 17 of 159
COOPERS
integrated project
Private data
- communication between OEMs and individual vehicles
- communication between network operating unit for configuration and management
Public data
- messages from vehicles to VII Message Switch
- information from traffic operation centres to RSE for broadcasting to all passing vehicles
Note: There are no messages sent from the public sector to individual vehicles. The information and
messages are sent from the Traffic Control Centre (TCC) over the operators network to one or more
RSUs and the RSU broadcasts them to all OBUs of the passing vehicles. No messages from the
private sector will be sent over the VII network via broadcast these messages will always be sent
to a specific vehicle or a group of vehicles. Data transmission between two or more commercial
RSEs (tolls or gas stations) is not scope of the VII.
The OBE will collect and store traffic/ vehicle data and if the OBU is in the range of an RSU, the
stored data will be transmitted to the RSU, forwarded to the VII Message Switch and finally
distributed to the users. The VII network consists of a series of hubs, routers that provide the
connection between the message switches and the users.
In the special aspect of safety relevant messages the OBE will be responsible for handling the GPS
data together with the in-vehicle sensor data. The vehicle-to-vehicle applications and the safety
applications require low latency communication (about 100 msec). Therefore the OBU should
transmit regular safety related messages at least once every 100 msec other routine messages with
more content might be transmitted by the OBU in greater intervals.
3.2 Forerunning projects in the European Union

eSafety is an initiative of the European Commission to accelerate the development, deployment and
use of Intelligent Integrated Safety Systems of industry and other stakeholders. The goal is to reduce
the number of accidents on Europes roads by intelligent solutions with information and
communication technologies.
Many projects have their focus on the efficient use of new technologies for improving the road safety
through making road traffic more efficient, accident prevention and injury reduction. In the following
chapter a short overview of the for COOPERS HL ITS system architecture relevant European
projects is given.
3.2.1 WILLWARN (a PReVENT Project)

WILLWARN (Wireless Local Danger Warning) that is part of the PReVENT (Preventive and Active
Safety Applications) project focuses at co-operative services for traffic warnings that are sent from
the road infrastructure to the approaching vehicles.
For the efficient usage of the communication capabilities the WILLWARN services need a
combination with other additional services. Therefore the overall architecture allows different
services to operate simultaneously on the same communication platform.
Page 18 of 159
COOPERS
integrated project
The services of the PReVENT project are based on the Open Services Gateway initiative (OSGi)
that is allowing the quick development of the platform independent service components and services.
The WILLWARN architecture was developed in co-operation with the architecture group of the
German federal governments founded Network-on-Wheels research project (NoW). The reference
architecture consists of the OSGi runtime environment, which enables a service oriented
architecture, and an IEEE 802.11(a) network adapter card. The sensor data access will be realised
by a standardised interface for bus system independent sensor information and data formats in
different vehicles. A Global Positioning System (GPS) via the serial port can scan the positioning
information and the standardised Application Programming Interface (API) provides the access of
different bus systems and sensors in a similar manner.
Access for the vehicles communication is realised with a standardised interface for providing send
and receive options. The main functionality consists of:
single hop broadcast
User Datagram Protocol (UDP) port interface
maintenance of a neighbourhood table
wireless communication hardware (Mini-PCI and PCMCIA IEEE 802.11a/b/g card [IEEE
802.11a mode used] and external antenna)
A publish-subscriber mechanism receives the messages and that allows different services to register
themselves for their message types. Because the communication channel has to be used from many
other applications this system guarantees a reasonable sharing of the channel capacity. But the
different messages have to be prioritised (for example safety relevant messages have a higher
priority than other messages), therefore this mechanism has to support a priority functionality. This
enables an optimum channel utilisation in all situations. Up to now the interface only supports a
prioritisation mechanism for one application, this functionality is sufficient if only one application class
is using the communication capability for transmitting and receiving messages of the vehicle.
When the message transmission is starting the complete message will be sent to the communication
system, this allows easy integration of IP based active safety messaging and seamless access to
different communication channels in 4G networks. The reason for this functionality is a better
architecture design for future mobile communication environments, and will ease the system
adaptation to a variety of vehicles coming from different manufacturers.
The main point of the OSGi framework supports easy enhancement of new and additional services.
When receiving a message of a special type, it is delivered to all services that have registered for
this sort of messages at the publish-subscriber, and so the system can be extended by new hazard
information types and services. The service oriented architecture enables transparent sensor access
and the selection of any kind of appropriate information technology (information via DAB, DVB-T/H,
TMC etc.). OSGi allows different services like active safety, deployment etc. that can be run in the
same framework. OSGi was developed for home automation and automobiles and it is especially
designed for small embedded systems and therefore it meets the specific requirements of embedded
automobile systems.
Page 19 of 159
COOPERS
integrated project
The standardised sensor access of the API allows suppliers to develop their own warning services
and the service oriented architecture enables an easy deployment of them.
The integration of software components for external applications in the architecture (that do not run
within an OSGi service environment) will be made by a universal UDP interface. For WILLWARN,
mathematical operations are typically realised in Matlab/SIMULINK and can therefore be used
without modification.
Since the channel access of stationary infrastructure based systems is similar to those deployed in
the vehicles, both vehicle-to-vehicle and vehicle-to-infrastructure communication is equally
supported.
3.2.2 GST
The GST (Global System for Telematics) project is developing an open standardised end-to-end
architecture for vehicles, their drivers and passengers. GST is creating an open environment by
decoupling service development, service operation, delivery infrastructure, payment, in-vehicle
software, in vehicle hardware and in-vehicle networks. The main part of Global Services for
Telematics within GST is the vehicle and its occupants for information services.
The methodology adopted by GST uses a version of Reference Model Open Distributed
Processing (RM-ODP) that offers the opportunity to decouple different business areas, business
rules, technology infrastructure and to accommodate legacy, heterogeneous and federated system
components. A viewpoints concept proposed by the ITU-T rec.X.901, ISO/IEC 10746 standards is
used to build the High Level System Architecture and the different sub-project architectures and
specifications.
RM-ODP considers the system from different viewpoints: enterprise, information, computational,
engineering, and technology. Each viewpoint produces a different abstraction of the original system,
without the need to create one large model describing it and all viewpoints together provide the
complete description of the system.
Three viewpoints have been selected for the specific needs of the GST project:
Enterprise: Functional description of the system. The stakeholders are marketing people of
service providers, car manufacturers etc.
Logical: Represents the informational and computational viewpoint and describes blocks of
functionality and the relation between the blocks. The stakeholders are system integrators.
Implementation: Actual technical implementation of the system. This viewpoint overlaps with
the technology and engineering RM-ODP viewpoints. The stakeholders are system
developers.
Reference to the enterprise view, GST is an initiative involving more than 50 key stakeholders. GST
has three main services for improving road safety via telematics services:
Rescue
Page 20 of 159
COOPERS
integrated project
Enhanced Floating Car Data
Safety Channel
One main part of the logical view is the structural aspect of the architecture and how the work needs
to go and the definition of the boundaries of the GST system (the Musts, Mays and Shoulds) in
combination with the use cases of the enterprise view.
The result of the implementation view is the detailed ITS system architecture and design
implemented by the software development team. This kind of view does not abstract the physical
conception of the system but defines the technological concepts suitable for constructing a GST
compliant framework.
3.2.2.1 GST architecture decisions

The GST architecture consists of a set of loosely coupled components with its own world view and
solves the issues from its specific problem domain. The benefit of the different decoupled
components is that they are replaceable without disturbing the correct functioning of the system and
that the communication between those components and interfaces have to be defined precisely. The
GST solution(s) do(es)nt depend on an implementation specific technology.
The GST consortium produces also software called Reference Implementation, which is realised to
the following technologies:
Java: J2SE (Java 2 Platform, Standard Edition) for client developments and J2EE (Java 2
Platform, Enterprise Edition) for server developments
The Open Systems Gateway Initiative (OSGi) framework for client side developments.
One of the main goals of GST is that different manufacturers can integrate their own modules and
the service providers can offer their own services to the end-users. Java is used because it is an
object-oriented programming environment that has widely dispersion by developers. Java
applications are compatible to nearly any operating system. Combined with OSGi Java could realise
the GST goals.
The OSGi specifications define a standardised, component oriented, computing environment for
networked services. An OSGi service platform combined with a networked device offers the
opportunity to manage the software components within the device from anywhere in the network.
These software components can be installed, updated or cancelled without interrupting the operation
of the device. The main focus of OSGi for GST is an open, standard, non-proprietary, software
component framework for manufacturers, services providers, and developers. This concept has been
taken up by the CVIS project and consequences are discussed in chapter 2.4.
Page 21 of 159
COOPERS
integrated project
3.2.2.2 Safety Channel in GST

The safety channel concept has to use previous developed travel and traffic information broadcast
dissemination systems like RDS-TMC. It uses a very simple flagging method to flag all events. Two
extensions of the flagging procedure are used:
Driver AWARENESS: Flag A

Definition according to GST: Message content is of an informative nature, which, in itself,
requires no definable action but will inform a driver to be aware of any unexpected or
unpredictable events that may affect safety. Knowledge of this message may be a
contributory factor in providing a driver with information prior to self-motivated safety related
actions.
Driver WARNING: Flag W

Definition according to GST: Message content is of a warning nature, which may require
potential actions by a driver to avoid (before message receipt) unexpected or unpredictable
events that will affect safety. Knowledge of this message should be a significant factor in
providing a driver with information prior to self-motivated safety-related actions.
The RDS-TMC event listings are modified to a list which is delivery mechanism independent,
therefore the RDS-TMC specific control messages were removed. The reduction of the RDS-TMC
list resulted in a list of 112 messages.
The referencing of location is an important part of traffic related information different categories of
applications have different requirements on location referencing. For this reason the different on the
fly location referencing methods (AGORA-C, TMC) in a safety channel message has to be stored in
a hierarchical container structure that allows different data structures.
A content centre obtains the content and transmits it to the service centre that means that the
content centre is responsible for pre-formatting the content. DATEX 2 seems to be the preferred
choice by GST for transmission between traffic centres, service providers and clients. DATEX 2
provides the necessarily flexibility for the Safety Channel requirements.
Especially the results on the safety channel in GST could be relevant for COOPERS, because of the
strong focus of road safety relevant information services. The principle of defining road safety
relevant information and messages has been taken up in COOPERS and been extended to the 12
service categories.
3.2.3 AIDE
The main focus of the AIDE (Adaptive Integrated Driver-vehicle Interface) project is to design an
adaptive integrated Human Machine Interface (HMI) for HMI-related conflict situations.
In-vehicle information systems and Adaptive Driver Assistance Systems (ADAS) interact with the
driver separately. The way of communication between these systems and the drivers operates
independently from each other. The different applications have different I/O devices that effects the
driver distractions and as a result driving safety risks. The main part of AIDE is to improve driver
system interactions (distraction and usability) to increase driving safety and improve user comfort.
Page 22 of 159
COOPERS
integrated project
For COOPERS especially the in vehicle system architecture and the priorities used for presenting
information to the driver could be of interest, this has been analysed by the partners involved in both
projects, see SWP3500 reports for further details.
3.2.4 EASIS
EASIS (Electronic Architecture and System Engineering for Integrated Safety Systems) has the main
focus on identifying an architecture framework of integrated safety systems for providing a basis for
successor work packages, which split into activities on Software Architecture, Hardware Architecture,
Dependability issues and Processes and tools.
3.2.4.1 VEESA
The EASIS architecture depends mainly on the results of VEESA (Vehicle e-safety Architecture). But
the architecture issues at the application and control level are also covered by many other projects
like AIDE and PReVENT. The VEESA study enables electronic integration by defining the
requirements of an open electronic architecture for the next generation of e-safety cars focusing on
the chassis and power train sector.
The functional viewpoint of VEESA describes a hierarchical architecture divided into different
function levels:
Basic components: the elementary functions of a vehicle with a number of basic components
(engine, transmission etc.).
Sub-systems: the basic components are bundled into sub-systems with an interface for
control functions. Each sub-system handles with specific functional aspects of the entire
systems. At this level, each sub-system has his specific functionalities, but there are no
controlling functions within the sub-system layer.
Sub-system supervision: for controlling and other functionalities. The Sub-system

supervision controls more than one sub-system and supports additional functions which are
used from every entire sub-system and also the links between them will built. Here the
functional blocks can be found.
Global systems: overall vehicle control.
The basic components of the VEESA functional architecture are systems like engine, transmission,
brake and steering and grouped to sub-systems. A group-specific middleware supports data
exchange between the basic components, the sub-systems and sub-systems supervision.
3.2.4.2 EASIS architecture

The focus of the EASIS project is to integrate the safety relevant function in a generic architecture.
These can be placed in the top-most layers (global system layer and the sub-system layer
Page 23 of 159
COOPERS
integrated project
supervision layer). It have to be noted that there could be several different global control functions
and therefore different global control interfaces. Each global system implements a specific interface
for their relevant services.
The architecture cannot be mapped on one physical Electronic Control Unit (ECU) because it will
consist of several sub-functions and one sub-function will need several ECUs. Therefore, the
functional architecture has to be mapped to a number of ECUs spanning one or more networks. The
Electric and Electronic Architecture mainly consists of three levels, which are widely independent of
each other:
Network level: different network topologies (central gateway, multi gateway, backbone) and
different network technologies (LIN, CAN, ASRB, FlexRay, MOST, IEEE-1394, telematics
network like GSM/ GPRS, UMTS, WLAN) are possible and also their combination.
ECU/ node/ hardware level
Software/ application level
The detailed analysis for in car system architecture and their future expansions by the OEMs
regarding V2I-communication could be an interesting topic for COOPERS, this will be taken into
account in the context of the Car2Car Communication Consortium.
3.2.5 SpeedAlert
The main focus of the SpeedAlert initiative is to support the implementation of in-vehicle speed alert
applications with the aim of improving road traffic safety. SpeedAlert has developed a functional
architecture for realising in-vehicle speed limit information and warnings. The architecture is divided
into several areas:
Data collection, generation and update: public authorities are the owners of speed limit data
and responsible for its quality and update.
Data processing: integration of speed limit data from map makers (static speed limits and
incremental updates), traffic control centres (variable speed limits) and service providers
(variable speed limits and incremental updates).
Communication infrastructure: communication channel supply for information of variable

speed limits and update of static speed limits by service providers and road operators.
Communication interfaces: in-vehicle interfaces for communication by system suppliers and

car manufacturers.
Speed alert applications: applications for speed limit information.
Some of the main results of SpeedAlert are:
Page 24 of 159
COOPERS
integrated project
Classification of speed limit categories relevant to speed alert applications
Definition of the End-user system and service requirements for speed alert applications
Development of the Functional architecture and associated technical building blocks
Creation of a list of recommendations to support implementation of speed alert applications
Development of a roadmap for deployment taking into account user needs, technical
feasibility and available solutions
Definition of the general business aspects for different actors and benefits
For COOPERS the variable speeds and their transmission into the vehicles as described in the
SpeedAlert project are of interest. As SpeedAlert worked on information items only several
categories of speed information have not been addressed. The various categories have been
taken up and will be coded in a standard format in COOPERS, to be able to transmit the various
speed limits, in terms of the legal nature in several member states, into the vehicle.
3.3 Running projects in the European Union

3.3.1 CVIS (co-operative vehicle-infrastructure system)
The CVIS project is coordinated by ERTICO and has its main focus on vehicle-to-infrastructure
communication for increasing the efficiency of transport systems. The project has the objective to
create a unified technical solution allowing all vehicles and infrastructure elements to communicate
with each other.
CVIS has specific core tech services:
COMM: communication and networking
FOAM: framework for open application management
POMA: positioning, maps and local referencing
3.3.1.1 CVIS communication (COMM)

In the last years the work on a new standard has seen a large effort ISO TC204 WG16 has
provided a draft standard, called CALM (continuous air interface for long and medium range). This
integrated solution will be the core for the CVIS functionalities.
The communication media actively considered in CVIS are:
Page 25 of 159
COOPERS
integrated project
1. CALM Infrared light communication
2. CALM M5 radio communication at 5 GHz frequency bands.
3. CALM MM radio communication at frequencies above 40 GHz
4. CALM 2G/3G Cellular radio technology
5. CEN Digital Short Range Communication at 5,8 GHz
Protocol functionalities considered in CVIS are:

1. Mobile IPv6 routing functionality
2. Geographically mapped IPv6 addressing
3. Fast location addressing
4. Real-time data exchange
5. CALM management CME / NME
6. CALM interface management IME.
3.3.1.2 CVIS framework for open application management (FOAM)

This part of the project will define an implementation-independent architecture that build up the
connection between the in-vehicle systems, the roadside infrastructure and the back-end
infrastructure for co-operative traffic management. FOAM will produce a technology proposal in order
to create a functional system. The main opportunities are Java/OSGi running on Unix operating
system and NetBSD (network Berkeley Software Distribution).
3.3.1.3 CVIS positioning, maps and local referencing (POAM)

The POMA subproject will research, develop and test advanced mapping and positioning solutions
and techniques depending on the CVIS entities from the services, like vehicle, roadside equipment,
service centre etc.
3.3.1.4 CVIS ITS Architecture documents

The following analysis is based on the CVIS Documents D.CVIS.3.2 High Level Architecture and
D.CVIS.3.3 Architecture and System Specifications and on discussions with colleagues from CVIS
project. In the High Level Architecture of CVIS a key component for cooperative systems is the Host
Management Center, which enables management of applications (load, renew or remove) and has
the necessity of a CVIS Central Organisation which takes care of the basic standard data modells,
basic service sets etc..
Page 26 of 159
COOPERS
integrated project
These Centers may be run by various organisations and can exist independently in unlimited
numbers in the CVIS network with the limitation that they interact through standardised HMC
interaction protocols. In physical/technical terms this means that CVIS exspects to connect all the
physical entities of the ITS Architecture via an Ipv6 Network, which is called an Internet Technology
based Network. The FRAME methodology is mentioned as a starting point for the development of
system architecture, and ongoing work collects requirements and use cases. As the basic
assumption is that full harmonisation of information modells between vehicle and road side systems
is not realistic even partial common elements are not considered as a step towards a solution. On
the other hand it is requested that meta information is available during run-time and some examples
are mentioned like XML, RDF
In the organsiational viewpoint there is a need for a central organisation/body in the cooperative
systems world with the main task to ensure inter(operability). For achieving this interoperability in the
project the stages of integration testing with alpha, beta and gamma testing are defined but no
process proposed to achieve uptake of R&D results in the deployment phase. This is documented in
the necessity of common information modelling to achieve interoperability and the request to have a
Cooperative Systems Forum. At the same time it is expressed that the future deployment
architecture will look differently from CVIS test site architectures.
For this reasons the ITS architecture work of CVIS has very little impact in the work of COOPERS.
For the communication technologies COOPERS can take CALM based media into account, if their
basic performance and availability is confirmed soon, the basic data from vehicles are not defined
yet and will probably not be elaborated in a standardised format as stated in the basic principles.
3.3.2 SAFESPOT
The SAFESPOT project has the objective to improve the autonomous systems (ADAS) and the
implementation of advanced safety applications, from ACC function to anti-collision safety function
using microware ACC radar integrated with V-V and/or V-I cooperation.
The project is divided in sub-projects:
SAFEPROBE: in-vehicle sensing and platform
INFRASENS: infrastructure sensing and platform
SINTECH: innovative technologies
SCOVA: co-operative systems applications vehicle based
COSSIB: co-operative safety systems infrastructure based
BLADE: business models, legal aspects, and deployment
SCORE: SAFESPOT core architecture
Page 27 of 159
COOPERS
integrated project
3.3.2.1 SAFESPOT in-vehicle sensing (SAFEPROBE)

The main objective of this subproject is the acquisition of in-vehicle information, their processing and
distribution to other vehicles and the infrastructure and to develop an in-vehicle platform. The data
coming from different sources like
vehicle on-board sensors
vehicle data
other vehicles through vehicle-to-vehicle communication (V2V)
infrastructure through vehicle-to-infrastructure communication (V2I)
3.3.2.2 SAFESPOT infrastructure sensing (INFRASENS)

This subproject has to define, develop, specify and validate co-operative infrastructure-based
components for the SAFESPOT applications. The defined sensing system on the infrastructure side
in combination with the information coming from the vehicle will make the detection of critical
conditions and events.
3.3.2.3 SAFESPOT technologies (SINTECH)

The main purpose of this subproject is to specify technologies for the application development in the
aspects of relative positioning, maintaining dynamic local digital maps and communication and
networking for vehicle-to-vehicle/vehicle-to-infrastructure communication. For realising this there are
three different approaches:
adapting the specified technologies from recent or running projects (e.g.: PReVENT, GST)
or standardisation initiatives (CALM, Car2Car-Communication Consortium)
exchanging technological breakthroughs between vehicle and infrastructure sectors
developing additional needed technologies
3.3.2.4 SAFESPOT co-operative applications vehicle based (SCOVA)

The focus of SCOVA is the specification and development of safety cooperative systems application
mainly based on the vehicle to vehicle communication system.
3.3.2.5 SAFESPOT co-operative systems infrastructure based (COSSIB)

COSSIB has to specify and develop a set of co-operative system applications which support the
roadside equipment (i.e. infrastructure-based sensing and actuation).
Page 28 of 159
COOPERS
integrated project
3.3.2.6 SAFESPOT business model (BLADE)

BLADE has the focus on the architecture depending on many aspects from a business perspective,
like organization, legal, responsibilities, regulations and economical.
3.3.2.7 SAFESPOT architecture (SCORE)

The main objective of SCORE is the definition of a system architecture for both the development of
new ITS safety services and the development of applications increasing the ITS traffic efficiency.
That will involve:
the specification of a high level architecture, that will consider all possible applications
(safety and traffic efficiency) and technologies coming from SAFESPOT, C2C-C (Car to Car
Communication) Consortium and other relevant European research projects
the detailed specification of SAFESPOT reference system architecture, with particular focus
on local area vehicle-vehicle-infrastructure network (based on C2C-C technology and
protocols) as communication infrastructure
the definition of architectural guidelines to design and develop vehicle and road side
infrastructure platforms (contribution to other SPs)
the definition of certification areas and associated certification modules as elements of

validation for the SPs contributing to the implementation of the SAFESPOT reference
system architecture
3.3.2.8 SAFESPOT ITS Architecture documents

As major Safespot project partners, mainly OEM manufacturer and automotive suppliers are also
members of the Car2Car CC and the development of the adhoc networks between vehicles are the
main technical element which is developed together with the C2C CC also the Manifesto of the CAR
2 CAR Communication Consortium, version 1.1 has been taken into account together with D7.3.2
Global System Reference Architecture Building Guide. As the technical systems and networks
between C2C and COOPERS are complementary in terms of the distribution of information between
infrastructure and vehicles the imminent impact of the SAFESPOT work on COOPERS is not very
high. Nevertheless there are several areas were a cooperation betweeen the projects is beneficial for
both and these are the so called highway applications in COSSIB and the area of vehicle probe data
were a common definition work in terms of content, format and data structure is a work item for both
projects. Other areas could be the technical approach on positioning and the respective matching
processes to on vehicle maps, but this needs to be further elaborated.
3.3.3 COMeSafety (communication for electronical safety)

The COMeSafety project supports the eSafety Forum with respect to all issues related to vehicle-tovehicle and vehicle-to-infrastructure communications as the basis for cooperative intelligent road
transport systems. The main task of ComEsafety is the Communication Architecture and the
Page 29 of 159
COOPERS
integrated project
interaction with standardisation bodies. COMeSafety provides a platform for exchanging information
between projects and presenting the results. For the common work with COMeSafety see next
chapter.
3.3.4 Co-oporation between projects

As described in the previous chapters the running projects from the sixth framework program have
different focus:
CVIS: core technologies
SAFESPOT: car-to-car communication
COOPERS: vehicle-to-infrastructure communication
COMeSafety: support platform for the other projects, standardisation
The started projects may provide a real step forward in the safety impact on road traffic, if they
realise synergies between the projects and contribute actively to the common elements of work.
First of all the development of the architectures from every project will be built on the European ITS
Framework Architecture KAREN/FRAME that was created and supported by the European
Commission. The purpose of this high level architecture is to provide guidelines for planning and
implementing of ITS services. If the main High Level ITS Architectures with the different
communication aspects would be designed with KAREN/FRAME it is possible to compare the project
specific results and functionalities and extend the existing version of FRAME with a cooperative
systems view.
Common services of co-operative systems have the need of standardisation, the involvement of
different actors from various fields and the necessity of a common basic understanding. Depending
on this there is a huge potential to work together between the projects for the same standard solution
of communication. The standardisation initiative related to CALM hereby could provide a viable path
towards standardisation and is needed to make sustainable business models possible.
As the mentioned projects are all formal commitments (contracts) of the project consortia with the
European Commission, DG Information Society and Media, the collaboration between the projects
needed also to be reflected in the formal contract documentation of every single project to make an
exchange of information, documentation possible. Coopers had to include an additional chapter in
the Consortium Agreement and define a cooperation agreement with the other projects, which
needed to be signed by the respective coordinators. This was achieved by all projects by November
2007 and exchange of documents and information started from that point on.
It is COMeSafetys responsibility to elaborate the Communication Architecture and the other projects
have regularly contributed to that task, for the overall ITS Architecture CVIS, SAFESPOT and
COOPERS have agreed to produce a common requirements document, which will be defined till the
1st Quarter 2008. Based on that result the further steps for a next version of an EU framework
architecture including cooperative systems functionality need to be defined.
Hereby two specific aspects related to the in vehicle environment, which are not the core work
content of COOPERS are of specific interest in the co-operation with the other projects. First a
Page 30 of 159
COOPERS
integrated project
standardised interface to in-vehicle electronics (in car vehicle gateway in CVIS terms) and a common
and standardised set of messages send from the vehicles to the other vehicles in the surrounding
environment.These messages need to be common to all the vehicle manufacturers to have the
potential to really improve road safety and efficiency of traffic flows. And this is valid for the regular
transmitted messages and for the event triggered ones, which are even more important from an
operators point of view.
In COOPERS version 2.0 of this document has been produced to include the main work items from
the discussions with the other projects, and this document will be further adapted to the progress
achieved till the start of the demonstrations.
From a process point of view the possibility to incorporate common elements of work with the other
projects in the development work of COOPERS is decreasing becauise of the rapid progress in the
development work packages, and here the cooperation and the results achieved need to improve.
Page 31 of 159
COOPERS
integrated project
4 Architectural Overview
The COOPERS project planned from the beginning to elaborate the project ITS Architecture based
on the FRAME and to proceed with the detailed design and developement work with the help of UML
modelling and industry standard tools in traffic telematics. Hereby it was also conceived to define the
additional elements of FRAME in the project and to contribute to a new version of FRAME which
incorporates also cooperative systems functionalities as a consecutive step.
The FRAME architecture covers the areas:
Traveller Journey Assistance,
Traffic Management,
Public Transport Operations,
Freight and Fleet Operations,
Advanced Driver Assistance Systems,
Safety and Emergency Facilities,
Support for Law Enforcement and
Electronic Payment.
Each of these areas includes many functions, data flows and data stores in hierarchical structure
and nodes within the COOPERS system as well as to the outside world.
The architecture approach of COOPERS is based on KAREN and FRAME. A special focus is given
to the traffic information collection on infrastructure basis and the communication to the vehicles for
information exchange. The communication from infrastructure to the vehicles (I2V) is the most
important aspect in this case. *
Further areas of importance for the completion of this information chain on architecture level are the
technical network development with migration scenarios and the in-car presentation of this
information to drivers (in-car human machine interface). Topics covered partly by the COOPERS
approach are the vehicle to infrastructure (V2I) communication link and the traffic information service
provider, which will get access to enhanced traffic information.
4.1 FRAME guideline

The user handbook of the FRAME Selection Tool provides a step-by-step guideline to build up the
own functional architecture:
Identify the user needs that define the services to be provided.
Page 32 of 159
COOPERS
integrated project
Select functions form the trace table, which provide a cross reference from user needs to the
functions that help to satisfy them.
Identify their functional areas or sub-functional group.
Confirm that the selected functions are reasonable.
Confirm that those functions nearby but not selected, should be omitted.
Select the data flows needed by the selected functions.
Select the data stores needed by the selected data flows.
Select the additional data flows needed by the selected data stores.
Identify the terminators (node to outside world) with all these data flows.
For the development of the physical viewpoint on basis of the defined functional viewpoint following
steps are necessary:
Allocate the functions and data stores to physical locations.
Define the physical data flows between the sub-systems, modules and the outside world.
More information about the methodology and an explanation of the terms used in this context can be
found in [FRAME2] and [FRAME3].
4.1.1 Different FRAME viewpoints

The Functional Viewpoint defines the functionality for the ITS System for realising the user needs
and interfaces to the outside world. The input and output data used by the system are defined. There
are functional areas, which are divided into functions. The data flow diagrams show how the
functions relate to each other, to data stores and to the terminators (the outside world) through the
data flows.
The physical viewpoint is describing the next layer to the functional architecture where the
functionalities are grouped into physical locations. If user needs contain physical requirements, they
have to be linked to this viewpoint. The resulting physical modules and sub-systems are the basis for
procurement and development of components while the physical data flows represent the actual,
physical links within the COOPERS system.
The communications viewpoint describes the kind of communications links needed in a system in
order to support its physical data flows. It may include some requirements from the User Needs,
where they relate to specific communication requirements. It consists of an analysis of the
communications requirements of the reference system which is described in the physical viewpoint.
Furthermore, it describes the communication technologies and standards. The communication link
analysis is provided in a separate report called [COOPERS2].
Page 33 of 159
COOPERS
integrated project
More information regarding the development process of the COOPERS high-level architecture in the
projects context can be found in section 8.
4.1.2 Function groups and their sub-functions within FRAME

The functional architecture consists of eight functional areas with a unique number and a description.
Each of them contains functions for its purpose. The functional areas are:
Provide Electronic Payment Facilities
Provide Safety and Emergency Facilities
Manage Traffic
Manage Public Transport Operations
Provide Advanced Driver Assistance Systems
Provide Traveller Journey Assistance
Provide Support for Law Enforcement
Manage Freight and Fleet Operations
There are two types of functions that may be found in these areas high-level and low-level
functions. High-level functions are very complex and for this reason they consist of lower-level
functions to fulfil the user needs.
4.1.2.1 Provide Electronic Payment Facilities

This area is providing the functionality to perform the electronic payment for different services
provided by other functional areas within the architecture. It shall have an interface with the financial
clearinghouse terminator to enable actual payment transactions to be made. If payment violations
are detected, any details that are available shall be passed to functionality in the Law Enforcement
Area.
4.1.2.2 Provide Safety and Emergency Facilities

This area comprises the management of what response is provided when an emergency occurs and
the notifications of stolen vehicles.
4.1.2.3 Manage Traffic

The area functionality will manage the traffic flows in an efficient way to use the road space and
minimize the impact of vehicles on the environment. The communication possibility and including the
provision of priority for their vehicles with emergency services is also provided is this area.
Page 34 of 159
COOPERS
integrated project
4.1.2.4 Manage Public Transport Operations
This area is responsible for managing the public transport services in a geographical way
and to use
4.1.2.5 Provide Advanced Driver Assistance Systems

The area functionality is providing the communications facilities between the vehicles systems and
other vehicle system and/ or the road infrastructure.
4.1.2.6 Provide Traveller Journey Assistance

The main focus of this area is planning and completing trips of travellers and the opportunity to make
requests for travel information.
4.1.2.7 Provide Support for Law Enforcement

Area 7 is responsible for reporting of violations to the law enforcement agencies, but without the
detection of over-weight vehicles and individual vehicle pollution levels.
4.1.2.8 Manage Freight and Fleet Operations

This area is providing facilities for the management of freight and fleet operations for:
A static freight and fleet operations centre, where the route will be chosen and this may
involve the use of modes other than that provided by road transport.
The managing of the operation of a fleet of freight vehicles with scheduling and specification
of drive duties and vehicle maintenance.
Providing functionality for freight and fleet management that is positioned on-board of a
freight vehicle for receiving instructions about route plans and schedules or other
information.
Page 35 of 159
COOPERS
integrated project
5 Definition of COOPERS services

The developed COOPERS architecture on the basis of FRAME has not the focus on extending the
FRAME architecture about co-operative systems and their applications and functionality. The
COOPERS architecture should show how the European framework architecture can be upgraded to
realize the defined safety relevant services during the COOPERS project. The final COOPERS
architecture would not be European framework architecture for co-operative systems and
applications, but it will be a first step for further work in the future.
To ensure the logical consistency of the architecture as in the FRAME architecture the predefined functions and sub-functions should be used. New additional functions are a potential source
of errors during the architecture conceptual phase.
5.1 COOPERS services

Previous work within the COOPERS project (WP2000) has identified 12 different COOPERS
services which are listed in the Executive Summary.
A description on the main user needs, the process how the new services were identified, and the
assessment of their potential impact can be found in [COOPERS4]. Based on this output, the
WP3000 group developed the high-level system requirement specification, which is attached to this
document in Annex 2: service description tables
5.2 Additional requirements of the COOPERS services

5.2.1 Floating Car Data (S13)
During the service description process it became evident that the simple inclusion of xFCD as an
additional data source is not enough. A separate description is needed to enable detailed description
and discussion of the process and breakdown of xFCD generation and data fusion. Furthermore, the
V2I message set and specific requirements can be provided in well-structured manner.
The aim of this process is to update the TCC data base with real-time xFCD. This benefits the
COOPERS services by improved event detection and area coverage due to the complementary
nature of data sources compared to established roadside sensors.
The detection of accidents, hazardous road conditions, fog or the tail end of congestions are some
examples which are either not reliably detectable or only with heavy investments in road detection
technology upgrades.
Page 36 of 159
COOPERS
integrated project
Extended floating car data are gathered by monitoring of the CAN in-vehicle bus, sensors which
have been integrated in the on-board unit or, in case of specialised applications, additional sensors
with external interfaces to the on-board unit. At present, it is difficult to monitor the CAN bus of
different vehicles as all types use different data formats. It is essential for successful xFCD support
to provide either an open, intermediate format or to harmonise the CAN matrices of the different
vehicle types and brands.
Vehicle data is categorised in either periodic data or event-triggered data depending on the added
value of information content. For example, vehicle position data, heading and speed are useful when
provided periodic, while it is more effective to report ESP activation or heavy braking activities only
when they are happening.
This strategy can also be seen in context with the requirement for economic transmission of xFCD
packets. Depending on the transmission technology transmission costs can arise. Whenever a
terminal free-of-charge is available all data shall be sent immediately. If the transmission is done via
rd
a 3 party e.g. GSM/GPRS provider only directly safety relevant data shall be transmitted.
Therefore, algorithms have to be implemented into the on-board unit to ensure economic use of
xFCD packet transmission and implement measures to verify correctness and relevance.
5.2.2 Service Acknowledgement

Another requirement which came up during discussions on the detailed break-down of the service
was to provide means to ensure that drivers got specific messages from the infrastructure. This is
the case for all services which give or are planned to give legal advice such as variable speed limit
and lane banning instructions. Furthermore, as the ISA service is planned to provide optimum speed
limits to the ISA facilities of the vehicle correct data transmission also needs to be verifiably ensured.
Within COOPERS this functionality will only be implemented for demonstration purposes, but has
nevertheless to be covered by the architecture. To address privacy issues it is also required that the
ID which is needed for acknowledgement can not be linked to the vehicle or driver and has to be
separately generated for each trip.
5.3 Note on COOPERS services

The first six (S1 S6) defined services are mainly network information services with real-time
information on the status of the road network and the environment and the second part of the
services should also provide information and should assist the driver.
For further information about the COOPERS services, please take the results and definitions from
WP2000 work packages.
Many of the COOPERS service need a whole set of different data sources, for example output data
from other COOPERS services or already implemented systems like MAYDAY systems, information
from historical databases or event databases.
For some COOPERS services a special payment system to aware the drivers anonymity is needed,
and for this reason the COOPERS system/services operate with IDs from registered vehicles. The
COOPERS system has access to the IDs and will transmit it to the responding provider.
Page 37 of 159
COOPERS
integrated project
6 Defined user needs

The list of the European User Needs in FRAME is divided into 10 areas:
1. General
2. Infrastructure Planning and Maintenance
3. Law Enforcement
4. Financial Transactions
5. Emergency Services
6. Travel Information and Guidance
7. Traffic, Incidents and Demand Management
8. Intelligent Vehicle Systems
9. Freight and Fleet Management
10. Public Transport Management
For
detailed
description
of
the
areas
please
visit:
http://www.frameonline.net/BrowsingTool/BrowsingTool_Version3/HomePage.html. The different areas have some
identical user needs, and so also twice in the COOPERS list.
To keep the FRAME systematic also the new COOPERS User Needs got a unique number starting
with 13. This 13 will help to identify new user needs within all overview tables and graphs.
Page 38 of 159
COOPERS
integrated project
6.1 User Needs for COOPERS
Page 39 of 159
COOPERS
integrated project
Page 40 of 159
COOPERS
integrated project
Page 41 of 159
COOPERS
integrated project
Table 1: COOPERS User Needs
6.2 New User Needs for COOPERS

Table 1: COOPERS User Needs shows the selected FRAME user needs and how they are linked to
each of the COOPERS services. Several new user needs were needed to cover the requirements of
all 12 services. The identified new user needs are listed below together with their link to the
respective services.
Table 2: New COOPERS User Needs
Page 42 of 159
COOPERS
integrated project
7 Functional viewpoint
For the functional viewpoint it is important to identify the services to be provided first and to clear
what main functionality stands behind. The FRAME results are providing a high number of functions
and sub-functions. If the needed specific function is not defined in the framework, a new one has to
be defined. But it should be tried to combine different functions for reaching the goal functionality.
Depending on the selected user needs from the FRAME framework and the additionally defined
COOPERS user needs listed in section 6.2, the needed functions for realisation of these user needs
have been specified. An overview about the functionality of each element listed in 7.1 and 7.2 can be
found in Annex 1: Summary of the functions.
7.1 Functions for COOPERS system

1.3.1
Detect User
1.6.1
Manage Tariffs
2.1.1
Acquire Mayday Call on Roadside
2.1.2.1
Identify and Classify Emergencies
2.1.2.4
Process Emergency Progress Reports
2.1.5
Provide Access and Maintain Data for Emergency
3.1.2.3
Provide Inter-urban Traffic Forecasts and Strategies
3.1.2.5.1
Provide Inter-urban Traffic Management
3.1.2.5.2
Provide Planned Inter-urban Traffic Management Facilities
3.1.2.5.4
Provide Inter-urban Traffic Speed Management
3.1.2.5.5
Provide Inter-urban Output Actuation
3.1.2.5.7
Provide Operator Inter-urban Traffic Management Facilities
3.1.2.5.9
Manage Inter-urban Static Traffic Data
3.2.1
Detect Incidents
3.2.2
Identify and Classify Incidents
3.2.5
Provide Incident Management Operator Interface
3.4.1
Monitor Weather Conditions
Page 43 of 159
COOPERS
integrated project
3.4.4
Predict Environmental Conditions
3.4.5
Provide Environmental Conditions Operator Interfaces
3.4.6
Manage Environmental Conditions Data
3.5.1
Evaluate Short Term Maintenance Needs
3.5.2
Evaluate Long Term Maintenance Needs
3.5.4
Evaluate De-icing Need
3.5.5
Provide Operator Maintenance Operations Interface
3.5.6
Manage Maintenance Data Store
5.11.3
Provide Mayday Call
5.12.2
Provide Communications with In-Vehicle Systems
5.12.3
Collect Road Infrastructure Data
5.12.4
Provide Traffic Regulations
5.12.5
Provide Vehicle ID
5.13.1
Provide Vehicle Position Determination
5.13.2
Prepare Floating Car Data
5.13.3
Provide ISA Facilities
5.13.4
Provide ISA Speed Limits
5.13.5
Provide Current Speed Limit
6.1
Define Traveller's GTP
6.3.1
Track Traveller and Implement Trip Plan
6.3.3
Inform Traveller
6.3.6
Provide Traveller Guidance
6.3.7
Assess the need for Trip Plan Changes
6.5.1
Define Traveller Trip Preferences
6.5.2
Provide Trip Planning Interface
Page 44 of 159
COOPERS
integrated project
6.5.3.1
Plan Traveller Trip
6.5.3.2
Collect Road Traffic Data

Table 3: Functions for COOPERS
7.2 New Functions for COOPERS system

Table 4: New COOPERS Functions gives an overview about the functionality which has either been
added or modified to address the new user needs raised by COOPERS. If a function has only been
modified, the number 13 representing the COOPERS category for new elements has been
attached in front. If a function has been designed from the scratch, the most similar category
together with a new, non-occupied index number at the last digit has been chosen.
13.1.3.2
COOPERS Identify User
13.1.3.5
COOPERS Compute Service Fee
13.1.3.8
COOPERS Provide Charging Information
13.3.1.2.1
COOPERS Collect Inter-urban Traffic Data
13.3.1.2.4
COOPERS Manage Inter-Urban Traffic Data
13.3.1.2.5.6
COOPERS Provide Inter-urban Lane Management
13.3.1.2.5.8
COOPERS Detect Inter-urban Traffic Violations
13.3.1.2.6
COOPERS Sample traffic data
13.3.1.2.7
COOPERS Collect floating car data
13.3.1.2.8
COOPERS Gather Traffic Status
13.3.1.2.9
COOPERS Manage FCD
13.3.2.3
COOPERS Assess Incidents and Determine Responses
13.3.2.4
COOPERS Manage Incident data and validation
13.5.14.4
COOPERS Provide Traffic Status
13.7.3.1
COOPERS Manage Traffic Violator Notifications
13.7.3.3
COOPERS Provide Violator Notifications Interface

Table 4: New COOPERS Functions
Page 45 of 159
COOPERS
integrated project
8 Relations between COOPERS services and FRAME

viewpoints
Figure 1 describes the FRAME methodology as it has already been used for several national ITS
architectures [FRAME4], together with the COOPERS specific context.
"#
"#
&&
'
&
&&
!
Figure 1: COOPERS Architecture development process and context

First, a selection of EITSFA user needs has been made according to the identified COOPERS
services in [COOPERS4]. User needs have a harmonized syntax and provide requirements in a
written, formalized language, which sentences are linked to functional elements of the EITSFA.
Table 1 provides the list of standard EITSFA user needs which have been selected for the
COOPERS system. This allows discussions with stakeholders that have no technical or telematics
background on the basis of unambiguous user needs instead of functional designs. During the
discussions with the variety of different stakeholders, a lack of standard EITSFA user needs to
describe the COOPERS system has been identified. The newly defined user needs are listed in
Table 2.
Once the whole set of selected EITSFA and newly defined COOPERS user needs is completed and
accepted by all stakeholders the functional viewpoint can be derived with the support of the FRAME
selection tool. It basically consists of a database in which all user needs, functional elements and
their logical link are maintained. The selection tool provides a set of functions which is directly linked
Page 46 of 159
COOPERS
integrated project
to the set of selected user needs. Each function has a set of input and output data flows, which are
logical links to the other elements in the functional viewpoint: functions, terminators, actors (a
subclass of terminators) and data stores. A subset of these functional elements can be selected by
hand to form a consistent and efficient system. A consistency check ensures that all links of the
selection are connected and no necessary element is missing. The functional viewpoint is finished
when it passed the consistency check and all user needs have been met.
The functional viewpoint is also the proper level of abstraction to discuss common elements with the
other projects and national ITS architectures. For COOPERS, this discussion is currently ongoing
with the other integrating projects CVIS and SAFESPOT and the support of the COMeSafety
initiative.
The next step towards a more realistic representation of the future system is to create the physical
viewpoint. Hereby, the selected functions have to be grouped into locations (e.g. vehicle, roadside
and central), sub-systems and modules.
Functional data flows within a component are only virtual as the component will be provided fully
integrated, whereas the other data flows become physical ones. Therefore, smart and representative
grouping of functions is crucial for an efficient system. State-of-the-art and best-practice sub-system
designs can serve as models, but in COOPERS the focus is to represent the actual test site system
implementations where applicable, to utilize existing equipment as much as possible.
The trace tables shown in Table 5 to 8 document the link between Sub-system, location, module,
functional elements and corresponding user needs. Together with the user need tables provided in
Table 2 it is possible to link each component to the COOPERS service which uses it.
Some physical links require more attention. This is especially true for the link between the
roadside/central sub-systems to the vehicle sub-system because it is obviously the centerpiece of an
I2V service and has additional bandwidth constraints. Following the FRAME approach it was
possible to identify all high-level data that needs to be exchanged via this physical link.
One other sub-work package of COOPERS dedicated its work to analyze and define the related
requirements, identify and evaluate possible wireless bearers [COOPERS2]. Additionally,
organizational aspects such as operational or data transmission costs, external operators have been
taken into account.
Page 47 of 159
COOPERS
integrated project
SubSystem.name
COOPERS Center
location
Central
Module.name
Provide Environmental Conditions Assessment
Provide Incident Management
Provide Safety Support for Maintenance Management
Provide Support for Emergency Management
Provide Support for Road Charging
Provide Support for Traffic Violation Reporting
Provide Traffic Management
elementID
3.4.4
3.4.5
3.4.6
13.3.2.3
13.3.2.4
3.2.2
3.2.5
D3.4
3.5.1
3.5.2
3.5.5
3.5.6
D3.6
2.1.2.1
2.1.2.4
2.1.5
D2.1
1.6.1
13.1.3.5
D1.5
13.3.1.2.9
13.7.3.1
13.7.3.3
D13.3
D13.7
13.3.1.2.4
13.3.1.2.5.6
13.3.1.2.5.8
3.1.2.3
3.1.2.5.1
3.1.2.5.2
3.1.2.5.4
3.1.2.5.7
3.1.2.5.9
D3.2
D3.8
corresponding user needs

7.1.2.5
7.1.0.4
13.1.2.1, 6.2.2.11, 7.2.2.1, 7.2.2.3, 7.2.3.1
5.1.0.3, 7.2.0.1, 7.2.0.6, 7.2.0.7, 7.2.2.1, 7.2.2.2, 7.2.5.1
2.2.0.1, 2.2.0.3, 2.2.0.5

2.2.0.6
2.2.0.6
5.1.0.2, 5.1.0.3, 7.2.0.5, 7.2.0.7, 7.2.2.1, 7.2.2.2, 7.2.2.3
7.2.1.2
7.2.1.2
13.1.5.1
13.1.5.1
13.1.2.1, 6.1.2.6,
13.1.6.1, 7.1.0.11, 7.1.10.1, 7.1.4.3, 7.1.5.2
2.1.2.1, 7.1.0.13, 7.1.2.2, 7.1.2.4, 7.1.6.1, 7.1.8.1,
2.1.2.2, 2.1.3.1, 7.1.0.11, 7.1.0.12, 7.1.0.13, 7.1.0.4, 7.1.0.5, 7.1.0.6, 7.1.4.8,
7.1.5.5,
7.1.0.11
7.1.0.11, 7.1.7.1, 7.1.7.2, 7.1.7.3, 7.1.7.5, 7.1.7.6,
7.1.3.1, 7.1.3.2, 7.1.3.3, 7.1.3.5,
7.1.7.4, 7.1.8.1,
Table 5: COOPERS service system central sub-system, modules, functions
Page 48 of 159
COOPERS
integrated project
SubSystem.name
COOPERS On-board Unit
location
Vehicle
Module.name
Perform Mayday Call
Provide charging information
Provide On-Board Communication Interfaces
Provide Speed Information and FCD
Provide Vehicle Position
elementID
5.11.3
13.1.3.8
13.5.14.4
5.12.2
5.12.3
5.12.4
5.12.5
6.5.3.2
5.13.2
5.13.3
5.13.4
5.13.5
5.13.1
8.2.5.1
7.1.7.6, 8.2.2.2, 8.5.5.1
8.5.5.1
6.1.2.5, 6.2.0.4, 6.2.2.10, 6.2.2.5, 6.2.3.3, 6.2.3.4, 6.4.1.3, 6.4.1.4,
6.1.2.5, 6.2.2.10,
8.2.5.1, 8.2.5.2, 8.2.5.4
8.2.5.2
8.2.5.4
Table 6: COOPERS service system on-board unit sub-system, modules, functions
SubSystem.name
COOPERS Roadside Unit
location
Roadside
Module.name
Detect Incidents
Identify On-Board Unit
Monitor Environment
Provide Roadside Communications
elementID
2.1.1
3.2.1
1.3.1
13.1.3.2
3.4.1
3.5.4
13.3.1.2.1
13.3.1.2.6
13.3.1.2.7
13.3.1.2.8
3.1.2.5.5

7.2.0.1, 7.2.0.6, 7.2.5.1
4.1.1.1, 4.1.1.2, 4.1.1.3, 4.1.3.1, 4.1.0.4, 4.1.2.1, 7.3.2.1, 7.3.2.2,
7.1.1.6
7.1.0.11, 7.1.0.3, 7.1.0.5, 7.1.3.4,
Table 7: COOPERS service system roadside sub-system, modules, functions
Page 49 of 159
COOPERS
integrated project
SubSystem.name
COOPERS-compliant portable device
location
Module.name
Personal Device Provide Infrastructure-supported Navigation
elementID
6.1
6.3.1
6.3.3
6.3.6
6.3.7
6.5.1
6.5.2
6.5.3.1
D6.1
D6.2
D6.3

6.1.0.4, 6.1.0.5, 6.2.3.1, 6.2.3.2, 6.2.3.3, 6.2.3.4, 6.2.3.5, 6.2.3.6, 6.4.1.4,
6.4.2.2,
6.1.2.3, 6.2.0.4, 6.2.0.5, 6.2.0.6, 6.2.2.4, 6.2.2.5,
6.2.3.1, 6.2.3.2, 6.2.3.3, 6.2.3.4, 6.2.3.5, 6.4.0.1, 6.4.0.4, 6.4.1.2,
6.1.2.1, 6.2.0.6,
6.1.0.5, 6.1.2.6, 6.2.3.1, 6.2.3.2, 6.2.3.3, 6.2.3.4,
6.1.2.6, 6.2.3.1, 6.2.3.2, 6.2.3.3, 6.2.3.4, 6.2.3.5, 6.4.1.3, 6.4.1.4, 7.3.0.1
6.1.2.5, 6.1.2.6, 6.2.0.4, 6.2.2.10, 6.2.2.5, 6.2.3.1, 6.2.3.2, 6.2.3.3, 6.2.3.4,
6.2.3.5, 6.4.0.1, 6.4.1.3, 6.4.1.4, 6.4.1.6, 7.3.0.1
Table 8: COOPERS service system personal device sub-systems, modules, functions
Page 50 of 159
COOPERS
integrated project
9 System Architecture physical viewpoint

The physical viewpoint, and also called physical architecture is the outcome of grouping together the
defined functions in the functional architecture from every single service into physical entities. For
creating the physical architecture, defined physical elements are used to make the relationship to the
functional architecture.
The following chapter describes these used physical elements.
9.1 Definitions of physical elements

systems
To cover all the feasible opportunities in the physical architecture it would make it very large and
unmanageable. And so it is possible to generate a physical architecture depending on the functions
of the functional architecture as different systems, for example P23 COOPERS. These present how
the functional viewpoint/architecture can be used to create an example of a particular application of a
system.
Each system will have its own context diagram with the relevant terminators (see Figure 2).
sub-systems
Each system consists of two or more sub-systems and each sub-system could be consisting of one
or more element types of the functional architecture (functions, data stores) and to communicate with
other sub-systems and terminators, called physical data flows. It is important that each sub-system
will include all of the parts within the functional architecture existing in the same physical location.
The work in the KAREN project has defined the following generic locations for sub-systems:
Central the place that is used by parts of a system to collect and manage the storage of
traffic data, toll payments, freight shipping orders, and/or the generation of traffic
management measures, or fleet management instructions, with or without human
intervention, e.g. TCC, or TIC, or freight and fleet management centre.
Roadside the place that is used by parts of a system for the detection of traffic, vehicles
and pedestrians, or the collection of tolls, and/or the generation of traffic management
measures, and/or the provision of information and commands to drivers and/or pedestrians.
Vehicle a device that is capable of moving through the road network and carrying one or
mere people (bicycles, motorcycles, cars, public transport vehicles) and/or goods (vans and
any other form of road going freight carrying vehicle) in which parts of system can be
installed during manufacture or can be added to later.
Personal device a device in which part of the system can be installed so that it can be
easily used (and possibly carried) by travellers as one of their personal possessions.
Page 51 of 159
COOPERS
integrated project
Freight device a device in which part of the system can be installed so that it is an integral
part of a freight carrying unit, e. g. freight container, trailer, or vehicle body.
Kiosk a device usually located in a public place, into which part of the system can be
installed to enable travellers to have limited and controlled access to some of its facilities.
An overall location can have more than one sub-system, for example more than one sub-systems
within the central location because of the different physical places. But a sub-system may not exist in
two or more different locations. Sub-systems that provide the same service in different locations will
be two separate sub-systems, with different identification.
modules
A sub-system could consist of two or more modules and each module has the same properties as
the sub-system but its own separate physical identity. The main difference between modules and
sub-systems is that each module is more likely to contain functionality from a single area of the
function architecture. Another reason for using modules is to create physical components that
contain a grouping of functionality that is more logical from a manufacturing or physical design view
point. Modules will communicate with each other using physical data flows.
terminators
A terminator is the link between the outside world and the architecture system. It defines the needed
functionality and data in the architecture from the outside world. A terminator may be a system, a
human entity and a physical entity.
physical data flows

Physical data flows are the communication links within a system between sub-systems, modules
and to/from terminators. Each physical data flow may consist of one or more functional data flows.
terminator data flows

The terminator data flows provide the communication links between sub-systems/modules and the
outside world terminators.
Page 52 of 159
COOPERS
integrated project
9.2 Overview of the P23 COOPERS

The P23 COOPERS system, that will be described in this chapter, has analyzed the needed
functions for realization of every defined service within the COOPERS project. Some functions are
needed in more than one service. The physical architecture shows the potential regulation of the
functionality progresses.
9.3 System context diagram of the P23 COOPERS

The context diagram of the P23 COOPERS system describes the links from the system to the
outside world called terminators. Used terminators within the P23 COOPERS:
Operator
Emergency Systems
Maintenance Organisation
Vehicle
Road Pavement
Driver
Road Related System
Weather Systems
Traveller
External Service Provider
Traffic and Travel Information Provider
Monitor Environment
Road Network Operator
Broadcaster
Road Network Operator
Geographic Information Provider
General Information Provider
Financial Clearinghouse
Page 53 of 159
COOPERS
integrated project
Figure 2: System Context Diagram

Page 54 of 159
COOPERS
integrated project
9.4 Sub-systems of the COOPERS system

The system P23 COOPERS obtains three four sub-systems dependent on the location roadside,
central, vehicle and portable device. Within the COOPERS project, the main focus is on
infrastructure-to-vehicle communication, meaning the data flows from Roadside Unit to On-board unit
and from Center to On-board-unit . The sub-system at the portable device location is different
compared to the others as it is not within the scope of development work in COOPERS.
Nevertheless, it is covered by the architecture because certain functionality and compliance is
required in order to address all COOPERS services.
9.4.1 P23.1 COOPERS Central Sub-system

The central sub-system has a vital role in the COOPERS concept. Todays high capacity backbone
communication networks allow a highly centralised system design, which has a lot of beneficial
aspects:
Decrease costs of roadside and on-board equipment

COOPERS requires high data processing and storage capacities at the central location,
but lowers the requirements and therefore costs of other, non-central equipment. This is
crucial for the on-board unit, if end users need to accept the costs.
Central data fusion

The roadside sensor data will be fused with extended floating car data, resulting in more
comprehensive information of the current road network status. Furthermore, it enables
effective interfaces and information exchange with external information service providers.
The more different data sources are gathered at a single location the more possibilities for
sophisticated data fusion algorithms arise.
Central data maintenance

In COOPERS, the road operator is responsible for data maintenance which is also the
entity legally responsible for traffic information. This ensures that the entity responsible for
data maintenance has experience and established organisational means for responsible
data maintenance. The centralised data maintenance and fusion approach enables also
easier system upgrades as most of the systems intelligence is focused on a single
location compared to an upgrade of all on-board units.
Single source of data

The architecture ensures that there is only a single data collection source of a specific
type within the system. Combined with the before mentioned benefits it ensures
compliance of all information which can still be provided customised via different output
streams. The avoidance of duplication of data stores saves system costs.
Figure 3 shows the seven modules of the Central sub-system which are described in section 9.5.1.
Page 55 of 159
COOPERS
integrated project
,
&(
!
&
!
&
(
!
(
!
#
#
!.
.&
-!#
.&
.
-
.& $
$.
.& $.
$.
.& $. $.
! &
$
(
(
! &
& !
$
$ &
& & !
#&
&&
&
,
&
& !
-
$ $
$ $
$
& !
(
! &
&
.
#&
-! # /
.
.
#&
!
#
.
#
. /
.
#
# & !
.
$. .
! &
#
#&
.!
# & !
.
! !
.
#
.!
+
$
&
&
&&
&
#
&.
&.
&
&
!.
-
&
#
.
.
#
.
.
-"#
#
!$. /
&
-
#
.
.
&&
#
.
-
# "
#
.
# "
&&
!.
# "
! .
#
.
# "
.&
# "
"
! &
&
&-
#
.
# "
(
#&
-"#
&.
# "
! &
&.
&
&
-
! &
&
.
.
.
!
&
.
&
.
&-
&
-
.
.
$. .
! &
.
"
-& .
.
#
#
. !
.&
! &
# "
.
#&
Figure 3: P23.1 COOPERS Central Sub-system diagram
Page 56 of 159
! .
.&
! &
COOPERS
integrated project
9.4.2 P23.2 COOPERS Roadside Unit

This sub-system contains all elements of the COOPERS system which are located at the roadside.
Different to the other sub-systems of COOPERS it is likely that the various modules it contains are
not integrated but at physically separate locations.
The roadside sub-system is responsible for establishing the bi-directional communication between
vehicle and infrastructure. This includes also basic local processing such as grouping or verification
of extended floating car data packets. Furthermore, local data fusion is processed in case there are
real-time restrictions. Beside traffic flow monitoring, weather and environmental conditions are also
monitored at neuralgic points to enhance the information provided to the central system by an
external service provider. This is needed to address local weather system dynamics and data which
is only relevant for the road operator and therefore not provided by external parties.
Page 57 of 159
COOPERS
integrated project
Figure 4: P23.2 COOPERS Roadside Unit diagram
Page 58 of 159
COOPERS
integrated project
9.4.3 P23.3 COOPERS On-board Unit

In the in-vehicle sub-system the messages from the infrastructure are decoded and processed. This
includes the management of the HMI display of messages to the driver. A key strategy of the
COOPERS system is to provide messages only at the area where the driver needs it. Therefore a
vehicle positioning module is obligatory, although the Provide Vehicle Position module may be a
separate device and not integrated within the COOPERS OBU. The compilation of xFCD packets is
also an important task of the OBU which includes to interface the in-vehicle bus and positioning
module.
,
#
!.
!
&
&
-!#
- &#
& .
.
&.
%
.
.
.
. & .
&.
! !
&
- &#
#
. !
! !.
.
&-
&-
' &
- &#
&
!
#*
&-
&&
.
.
2
&
&
#
.
.
&%
$ &
&
#
.&
#!
! &
.
-
. /
&
#& $
.
$.
&( $
Figure 5: P23.3 COOPERS On-board Unit diagram
Page 59 of 159
!.
.& $
COOPERS
integrated project
9.4.4 P23.4 COOPERS-compliant Portable Device

The scope of the COOPERS project is not to design a new navigation system, but to provide an
interface to an external navigation system, which could cover the positioning and navigation
functionalities to support the COOPERS services. Nevertheless, it is part of the physical viewpoint
because the device is needed in order to support the full range of COOPERS services and
corresponding user needs. This implies that a certain functionality is expected by the navigation
system which is represented by the functional elements it includes.
The COOPERS system will provide road network status information such as journey time delays,
route recommendations and availability of map updates via an open interface which the navigation
units can access and use to provide better services for the end user.
Figure 6: P23.2 COOPERS-compliant Portable Device diagram
Page 60 of 159
COOPERS
integrated project
9.5 Modules of P23 COOPERS

The four sub-systems are divided into modules to gain flexibility in component procurement and
integration. The defined modules within the COOPERS project are chosen due to their specific field
of application and functionality.
9.5.1 Modules for P23.1 COOPERS Central Sub-system

The central sub-system consists of seven modules:
P23.1.1 Provide Incident Management

This module contains functionality to detect and identify incidents by processing a number of
different sources including data from roadside sensors, floating cars or external providers.
Detectable incidents include:
o
o
o
o
Accident/Incidents/Wrong-way-drivers
Hazardous weather conditions
Maintenance activities
Traffic congestion warning
After assessment and selection of the proper response the incident warning is forwarded to
the different dissemination channels including broadcaster, external traffic information
provider and other modules within the system such as Provide traffic management.
P23.1.2 Provide Traffic Management

This module provides means to manage and control traffic, especially traffic flow by
controlling lane use and variable speed limits. Static and dynamic traffic and infrastructure
data is collected and maintained centrally to provide the current and predicted traffic status.
The main distribution channels utilised by this module are VMS and on-board unit.
P23.1.3 Provide Environmental Conditions Assessment

This module mainly collects and monitors weather conditions to provide the current and
predicted weather situation for the road network. This functionality is needed by the incident
management to detect hazardous conditions and the traffic management to determine the
legal and optimal speed limits.
P23.1.4 Provide Safety Support for Maintenance Management

In this module all relevant maintenance activities are stored. Current and near-future
maintenance activities are sent to the incident management module to ensure a proper
warning is disseminated to raise user awareness and increase safety.
P23.1.5 Provide support for emergency management

This module provides an interface to emergency systems to obtain updates on emergency
progress reports. The additional data is used to improve the Accident warning service
Page 61 of 159
COOPERS
integrated project
P23.1.6 Provide Support for Traffic Violation Reporting

This module provides functionality to log violators of lane banning and legal speed limit
instructions for statistical purposes to assess the acceptance and efficiency of dynamic legal
restrictions. Violations are reported by the traffic management module and stored into the
D13.7 COOPERS Traffic Violator Notifications data store from which the operator can
request surveys.
P23.1.7 Provide Support for Road Charging

This module computes the road charging fee based on dynamic parameters such as traffic
status or environmental conditions. It is also responsible for maintaining the data store of
charging tables which are provided by an external service provider. The calculated dynamic
fee is forwarded to the driver to influence behaviour on route and travel time selection during
peak periods in the long term.
&.
&.
#
.
-& .
.
&
&.&
!.
&.&
-& .
&.
# "
&.
&.
.
.
Figure 7: P23.1 Central Sub-system P23.1.1 Provide Incident Management module
Page 62 of 159
COOPERS
integrated project
#
&
# " .
! & .
.
!
&
)
# "
# "
#
# " .
! & .
&
# "
# "
&&
#
#
.
&
-"#
"
" .
#
.
#
.
! &
-& .
# " .
&.
# " .
&.
# " .
&.
# " .
.
&&&.
&.
&.
&.
&.
&.
&.
&.
! .
.3
.
# " .
!$. /
#
#
#
#
. /
.&
.
!. .
.
.&
.
.
! &
! &
"
.
. !
.
.
!
. &&
.3
.&
! & . /
. &&
. &&
" .
.
.
# "
.
# "
" .
" .
" .
" .
.
#
# "
.
.
.
# "
# "
# "
# "
# "
# "
# "
&.
&.
&-
&-
&-
&.
.
.
.
&.
# "
.&
&.
# "
.
Figure 8: P23.1 Central Sub-system P23.1.2 Provide Traffic Management module
Figure 9: P23.1 Central Sub-system P23.1.3 Provide Environmental Conditions Assessment

module
Page 63 of 159
COOPERS
integrated project
Figure 10: P23.1 Central Sub-system P23.1.4 Provide Safety Support for Maintenance
Management module
Page 64 of 159
COOPERS
integrated project
& !
$.
& !
& !
$
$ &
.& $.
$.
.& $
&-
$.
$.
#
!
&
#
! " .
-!#
& !
$
$(
.
-!#&
! &
!
&
.
.
.
.& $. $.
! &
-& .
$. .
$. .
-& .
# & !
# & !
-! #
.
,
&
.
.
&
Figure 11: P23.1 Central Sub-system P23.1.5 Provide Support for Emergency Management
module
Figure 12: P23.1 Central Sub-system P23.1.6 Provide Support Traffic Violation Reporting
module
Page 65 of 159
COOPERS
integrated project
Figure 13: P23.1 Central Sub-system P23.1.7 Provide Support for Road Charging module
9.5.2 Modules for P23.2 COOPERS Roadside Unit

The roadside sub-system consists of three modules:
P23.2.1 Provide Roadside Communications

This module collects raw traffic data from attached sensors and extended floating car data
packets. Basic processing of xFCD is performed in this module to verify and organise
incoming data. Raw traffic data from attached sensors must be processed locally to meet
real-time restrictions and to save bandwidth. After pre-processing, data such as traffic flow,
occupancy level, or vehicle classification, is forwarded to the center.
This module is also responsible to forward messages of relevance for the respective area to
the on-board units bypassing vehicles and to control the VMS output.
P23.2.2 Detect Incidents

This module processes sensor and closed-circuit video data in real-time to detect possible
occurrences of incidents such as accident or objects on the road.
P23.2.3 Monitor Environment

Weather and environmental conditions are also monitored at neuralgic points to address
local weather system dynamics and data which is only relevant for the road operator and
therefore not provided by external parties.
Page 66 of 159
COOPERS
integrated project
P23.2.4 Identify On-board Unit

This module is able to detect and identify bypassing on-board units and the respective
vehicle type. This information is used by the Provide Support for road charging module to
calculate the corresponding dynamic charging fee which has to be transmitted back to the
addressed vehicle.
Figure 14: P23.2 COOPERS Roadside Unit P23.2.1 Provide Roadside Communications
module
Page 67 of 159
COOPERS
integrated project
Figure 15: P23.2 COOPERS Roadside Unit P23.2.2 Detect Incidents module
Figure 16: P23.2 COOPERS Roadside Unit P23.2.3 Monitor Environment module
Page 68 of 159
COOPERS
integrated project
Figure 17: P23.2 COOPERS Roadside Unit P23.2.5 Identify On-board Unit module
9.5.3 Modules for P23.3 COOPERS On-board Unit

The vehicle sub-system consists of four modules:
P23.3.1 Provide On-board Communication Interfaces

This module contains the wired interface to the in-vehicle bus system and the wireless
interface to the infrastructure. Furthermore it manages the HMI display of warning messages
to the driver and provides the corresponding trip delays to the external navigation device via
an open interface.
P23.3.2 Provide speed Information and FCD

This module is responsible for the provision of the current speed limit to the in-vehicle
intelligent speed adaptation facilities and to the HMI. The other main task is the compilation
of extended floating car data packets which contain not only the vehicle position provided by
P23.3.3, but also the vehicle status information derived from the in-vehicle bus in module
P23.3.1.
P23.3.3 Provide Vehicle Position

This module contains the positioning and map-matching functionaliy to determine the
vehicles position needed for xFCD packet generation and provision of the current speed
limit.
Page 69 of 159
COOPERS
integrated project
P23.3.4 Perform Mayday Call

This module provides basic mayday call functionality by triggering the transmission of an
extended floating car data packet in case of accident event detection via in-vehicle bus data
such as airbag activation.
P23.3.5 Provide Charging Information

This module provides charging information to the driver. This can be information about the
current section or the cumulative sum of the charges paid so far on the current trip.
Figure 18: P23.3 COOPERS On-board Unit P23.3.1 Provide On-board Communication
Interfaces module
Page 70 of 159
COOPERS
integrated project
' &
-& .
!.
- &#
& .
# "
.
!.
.
&.
.
.
&
.
. & .
&.
&.
.
# "
!
.
.
. & .3
Figure 19: P23.3 COOPERS On-board Unit P23.3.2 Provide Speed Information and FCD
module
Figure 20: P23.3 COOPERS On-board Unit P23.3.3 Provide Vehicle Position module
Page 71 of 159
COOPERS
integrated project
Figure 21: P23.3 COOPERS On-board Unit P23.3.4 Perform Mayday Call module
Figure 22: P23.4 COOPERS On-board Unit P23.3.4 Provide Charging Information module
9.5.4 Modules for P23.4 COOPERS-compliant Portable Device

The complaint Portable Device sub-system consists of on module:
P23.4.1 Provide Infrastructure-supported Navigation
In order to realize additional navigation services like estimated journey time, route navigation or
map update an external device will be needed. This device shall provide routing and navigation
functionality, while the On-board Unit provides dynamic route information like incidents and their
estimated journey time delay via an open interface (e.g. bluetooth, USB2.0, WiFi) to support the
calculations. Additionally, this COOPERS-compliant portable device could also be able to
receive data from other information service providers as well.
Page 72 of 159
COOPERS
integrated project
Page 73 of 159
COOPERS
integrated project
9.5.5 Physical data flows

This section describes the resulting physical data flows on system layer as depicted in Figure 2. For
more detailed information about the physical data flows the trace tables in Table 9 to 11 can be
used. A detailed description of the contained functional data flows can be obtained from [FRAME5].
coopers-central_information
This data flow consists of information about incidents and perturbations which are relevant for on-trip
planning or trip re-routing if delays are above a predefined tolerance level.
coopers-central_info
This data flow consists of the dynamic and static speed limits as well as copies of all other static
traffic signs along the motorway.
coopers-collected_roadside_data
This data flow consists of all data collected at the roadside unit which is relevant for the COOPERS
center including preprocessed xFCD, traffic conditions, detected incidents, local weather conditions
and may day calls.
coopers-fcd
This data flow contains the composed extended floating car data packets including vehicle ID,
position and status information from the in-vehicle bus system.
coopers-messages_for_road_users
This data flow contains all messages for the road users of the respective segments including incident
warnings, lane instructions and the legal dynamic speed limits for the variable message signs.
coopers-route_and_vehicle_status
This data flow contains information about the planned route including floating car data to reconstruct
the previous motion characteristics to assess the need for trip plan changes.
coopers-traffic_status
It contains the warnings, information and lane commands that are forwarded from the roadside unit
to the vehicle on-board unit. Furthermore, the roadside unit can request the ID of the on-board unit.
coopers-vehicle_messages
This data flow contains the vehicle position which is needed to calculate the current dynamic tolling
fee. Additionally, in case the vehicle is involved in an accident, this link is used to provide mayday
call data.
fae-weather_inputs
Page 74 of 159
COOPERS
integrated project
It contains analogue data about the weather that may be general and apply to the geographic area
served by the System, or be from individual points at or near the road network.
fd-incident_notification
It contains details of an incident that are being provided by a Driver to the Center. In this case the
Driver may be from any of the actors that make up this terminator.
fd-mayday_call
It contains a mayday call realised by a static traveller on a roadside system. Mayday call must
contain : time, location, involved vehicles and status, involved people and health status, and any
relevant information for emergency.
fesp.g-additional_map_data
It contains all data from a geographic information provider which is needed by the COOPERS center.
This includes mainly map updates.
fesp.g-data
It contains geographic data from which, given a set of co-ordinates, a named location can be
identified.
fesp-tariff_grids
It contains all the elements necessary to determine the tariff for a given service and contract. The
data flow includes the following elements: date, service provider ID, service ID, and for each service
ID the tariff for every combination of parameters defining the service, and for various contract types
flds-psef_location_data
It contains location information for emergency vehicle
flds-ptja_location
It contains analogue or digital data from which functionality within the Area can determine the current
location of a Traveller.
flds-vehicle_location
It contains the current position of the vehicle in co-ordinate units.
From Traffic
It contains raw analogue sensor data that will be used to detect the presence of a vehicle and to
calculate traffic flow.
From/To Emergency Systems
Page 75 of 159
COOPERS
integrated project
This bidirectional data flow between the COOPERS center and emergency systems contains
information about the emergency process progress to co-ordinate the corresponding actions.
From/To Financial Clearinghouse
It contains the pseudonymous vehicle ID and the amount of money to be charged, the timestamp
and location ID provide information to manage the revenue of the different motorway operators.
From the clearinghouse to the COOPERS center it contains the receipt of the transaction request.
From/To Maintenance Organisation
This data flow contains requests for maintenance operations to be carried out as well as updates on
maintenance activities from the maintenance organisation to the COOPERS center.
From/To Operator
This bidirectional dataflow represents the interface between the road network operator and the
COOPERS system including all commands and requests and their relating responses of the system.
From/To Road Related System
Via this bidirectional data flow incident and traffic data are exchanged with other instances of the
COOPERS system to realise the international service handover.
From/To Traveller
This bidirectional dataflow represents mainly the interface between the navigation device and its
user. It includes preference settings, route requests and alternatives, notification on track changes
and their approval.
frp-current_conditions
It contains analogue data from which sensors within a Function can determine the current state of
the pavement in terms of its temperature and moisture content. This will be used to decide whether
or not de-icing treatment will be needed.
frp-wearing_state
It contains analogue data from which sensors within a Function can determine the need for
maintenance of the road pavement.
ft-incident_notification
It contains details of an incident that are being provided by a Traveller. In this case the Traveller may
be a Pedestrian, a Static Traveller, or a Dynamic Traveller.
Page 76 of 159
COOPERS
integrated project
fv-incident_notification
It contains details of an incident that are being provided automatically by a Vehicle. In this case the
Vehicle may be a Pedestrian from any of the actors that make up this terminator.
fv-vehicle_characteristics
It represents the Vehicle physical characteristics that are used by the detection sensors of the
system in the "Detect User" Function.
fws-maintenance_conditions
It contains information about weather conditions and is to be used in the determination of
maintenance activity.
fws-weather_conditions
It contains data about current and forecast weather conditions and icing formation over the
geographic area managed by the System.
td-mayday_ack
It contains the response given by the system to a static traveller that the mayday call is processed.
td-output_actuation
If contains output from the traffic management Functions that serve the inter-urban road network.
This output will direct all types of Drivers to take actions so that the progress of their vehicles will
make best use of the inter-urban road network.
To External Service Provider
This data flow contains all data of the COOPERS system to external information provider which is to
be broadcasted either via radio channels or web services.
tv-hmi_messages
It contains the warnings, road network status information, toll charging information and lane
instructions to be displayed at the HMI.
Page 77 of 159
COOPERS
integrated project
Physical Data Flows
Name
coopers-accident_detected
coopers-central_information
Consistuents
Physical Data Flows
Functional Data Flows

padas_accident_detected
coopers-ptja_maintenance_data
mt.ptja_incident_information_AP
mt.ptja_inter-urban_network_perturbations
mt.ptja_weather_information_AP
coopers-collected_roadside_data
coopers-icing_incident_data
coopers-traffic_management_feedback
coopers-weather_condition_data
mt_inter-urban_preprocessed_single_fcd
pepf.mt_inter-urban_infra_usage_info
pepf_vehicle_data_CSF
psef_roadside_may_day_call
mt_inter-urban_lane_commands
mt_inter-urban_lane_commands_2
mt_inter-urban_speed_commands
mt_inter-urban_traffic_management_requests
mt_environmental_incident_inputs
mt.ptja_pollution
mt.ptja_weather_information_PRT
padas.mt_inter-urban_floating_car_data
padas.pepf_vehicle_ID
padas_current_time_2
padas_status_data_for_fcd
padas_vehicle_ID_for_fcd
mt.psle_inter-urban_fraud_notifications_2
mt_inter-urban_request_violators
mt_icing_incident_data
psef.mt_incident_data
psef.mt_incident_data_update
mt_incident_detection_data
mt.ptja_incident_information_PRT
mt.psef_incident_notification
mt_inter-urban_incident_strategy_request
mt_inter-urban_incident_warning_commands
mt_inter-urban_incident_warning_commands_2
mt_inter-urban_road_use_data
mt_inter-urban_traffic_maintenance_conditions
mt_long_term_maintenance_data
mt_short_term_maintenance_data
coopers-driver_instructions
coopers-environmental_incidents
coopers-environmental_info_PRT
coopers-fcd
coopers-fcd_content
coopers-fraud_notifications
coopers-icing_incident_data
coopers-incident_data
coopers-incident_detection_data
coopers-incident_info_PRT
coopers-incident_notification
coopers-incident_strategy_request
coopers-incident_warnings
coopers-maintenance_conditions
coopers-maintenance_data
coopers-messages_for_road_users
coopers-driver_instructions
coopers-incident_warnings
psef_roadside_may_day_call_first_acknowledgement
padas_vehicle_position_for_mayday
padas_vehicle_position_for_fcd
padas_vehicle_position_for_ISA
mt.ptja_long_term_maintenance_data
mt.ptja_short_term_maintenance_data
coopers-position_for_mayday
coopers-position_for_processing
coopers-ptja_maintenance_data
coopers-regulations_and_charge_info
coopers-static_traffic_regulations
coopers-vsl
pepf_current_charge
padas.ptja_floating_car_data
ptja_store_road_trip_planning_data
mt_inter-urban_traffic_data_for_incident_detection
mt_inter-urban_traffic_data_for_incidents
mt_collected_inter-urban_traffic_data
mt_inter-urban_actuator_status
mt_inter-urban_floating_car_location
mt_inter-urban_traffic_flow_management_data
mt_inter-urban_traffic_management_responses
mt.padas_inter-urban_traffic_regulations
mt.ptja_inter-urban_network_conditions
mt.ptja_inter-urban_traffic_predictions
coopers-route_and_vehicle_status
coopers-traffic_data_for_incident_detection
coopers-traffic_data_for_incidents
coopers-traffic_management_feedback
coopers-traffic_management_info
Table 9: Physical data flows functional data flows within the COOPERS system (part 1)
Page 78 of 159
COOPERS
integrated project
Physical Data Flows
Name
coopers-traffic_status
Consistuents
Physical Data Flows
coopers-environmental_info_PRT
coopers-incident_info_PRT
mt.padas_inter-urban_traffic_status
pepf.padas_vehicle_ID_request
padas.pepf_vehicle_position
padas.psef_mayday_call_data
mt.padas_inter-urban_speed_settings
mt_weather_condition_data_inputs
fae-weather_inputs
fd-mayday_call
fesp.g-identification_response
fesp.g-map_update
fesp.g-data
fo.rno-environmental_conditions_commands
fo.rno-fraud_information_commands
fo.rno-incident_inputs
fo.rno-inter-urban_traffic_commands
fo.rno-maintenance_commands
ft-change_approval
ft-factual_parameters
ft-general_trip_preferences
ft-secondary_criteria
ft-trip_selection
tt-itinerary_changes
tt-output_GTP_data
tt-request_preferences
tt-route_guidance_info
tt-trip_alternatives
fes-emergency_progress_report
fes-emergency_services_information
fv.hmi-initiate_mayday
fmo-update_activity_status
coopers-vehicle_messages
coopers-vsl
coopers-weather_condition_data
fae-weather_inputs
fd-mayday_call
fesp.g-additional_map_data
fesp.g-data
From / To Traveller
From Emergency Systems

From HMI
From Maintenance Organisation
From Operator
From Road Related System
From Traffic
frrs-emergency_or_incident_notification
frrs-incident_data
frrs-traffic_data
ftrfc-inter-urban_raw_traffic_flow_data
ftrfc-presence_indication
From Vehicle Systems

frp-guidance_data
frp-wearing_state
fv.vs-input_data
frp-guidance_data
frp-long_term_wearing_state
frp-short_term_wearing_state
frp-short_term_wearing_state_2
ffrs-inter-urban_data_updates
frrs-inter-urban_traffic_management_strategies
frrs-incident_data
frrs-inter-urban_data_updates
frrs-inter-urban_traffic_management_strategies
fws-long_term_maintenance_conditions
fws-short_term_maintenance_conditions
fws-short_term_maintenance_conditions_2
frrs-data_and_management_updates
frrs-incident_data
frrs-traffic_data
fws-maintenance_conditions
Page 79 of 159
COOPERS
integrated project
Name
fws-weather_conditions
fws-weather_data_for_incidents
td-mayday_acknowledgement
td-output_actuation
tesp.b-incident_data
tesp.b-inter-urban_traffic_data
tesp.gip-request_for_identification
tesp.ttip-incident_data
tesp.ttip-inter-urban_traffic_data
To Emergency Systems
To External Service Provider
Physical Data Flows
To Maintenance Organisation
To Operator
To Road Related System

fws-ice_formation_conditions
fws-weather_data
fws-weather_data_for_incidents
td-mayday_acknowledgement
td-inter-urban_traffic_commands
tes-global_progress_report
tmo-long_term_activities
tmo-short_term_activities
To Emergency Operator
to.rno-environmental_condition_responses
to.rno-fraud_information_responses
to.rno-incident_outputs
to.rno-inter-urban_traffic_responses
to.rno-maintenance_responses
trrs-emergency_or_incident_notification
trrs-incident_data
trrs-traffic_data
trrs-data_and_management_updates
trrs-inter-urban_data_updates
trrs-inter-urban_traffic_management_strategies
trrs-incident_data
trrs-inter-urban_data_updates
trrs-inter-urban_traffic_management_strategies
tv.hmi-current_speed_limit_from_ISA
tv.hmi-charging_info
tv.hmi-traffic_regulations
tv.hmi-traffic_status_information
trrs-incident_data
trrs-traffic_data
tv.hmi-current_speed_limit_from_ISA
tv.hmi-traffic_messages
Page 80 of 159
COOPERS
integrated project
10 Adoption of the Reference

Demonstration Sites
Architecture
to
the
The defined Reference Architecture will not only be the basis for the architecture and development of
the single components, but needs also to be reflected within the single Demonstration Sites. This
needs to be done to guarantee the interoperability and to ensure continuous services within the
single Test Sites. One goal of the demonstration needs to show, that for the end user (driver) there is
no difference if he is driving in France, Germany or Italy he will receive the same services and will
not be aware of the different communication technologies used for the transmission of the
messages.
Figure 23: Demonstration Sites planned within COOPERS
10.1 Demonstration Site 1

This Demonstration Site needs to have a very special focus on the Reference Architecture, as here 3
different countries (Austria, Italy and Germany) will demonstrate a continuous service provision to
the driver including the service handover between the included road operators. Hereby it must be
ensured, that even if the data sources and data quality are different, the service and information that
will be presented to the driver needs to be similar. So the driver will not recognise if the information
comes from Autostrada del Brennero, ASFINAG, OBB or someone else.
Along this Demonstration Site also different communication technologies will be used:
Page 81 of 159
COOPERS
integrated project
Broadcasting technologies (DAB, DVB-H)
Cell based technologies (GSM, GPRS)
Dedicated Short Range Communication Technologies (Microwave, Infrared)
By using the FRAME methodology to generate the Reference Architecture it is ensured that all
services are described technology independent. Therefore the choice of one or the other
communication technology will have no impact on the service itself.

This Demonstration Site is located between Rotterdam and Antwerp and will also cover two different
countries (Netherlands, Belgium). Similar to Demonstration Site 1 the driver will not recognise any
differences in the services by driving in Belgium against driving in the Netherlands
For this Demonstration Site it is planned that a Traffic Information Service Provider (TISP) will collect
the input data from the Dutch and Belgium Road Operator and generate out of them the COOPERS
messages. So here the location of the service generation is different to the other demonstration
sites, where the service generation is done at the Traffic Control Centre (TCC). However it needs to
be ensured, that even if the process chain is different, the transmitted data are similar and the data
processing is performed at comparable physical entities (compare to chapter 1 physical viewpoint).
It has been decided on January 2008 that on test site 2 also WIMAX will be included in the
demonstration to evaluate the performance of that commmunication technology for the transmission
of safety relevant traffic information into the vehicle.

Also in the Berlin Test Site very specific points have to be taken into account by realising the
COOPERS services. As in Berlin the unidirectional Digital Audio Broadcast (DAB) will be the main
dissemination medium for the COOPERS messages, a back link for the acknowledgement, as it is
requested for some services (e.g.: Variable Speed Limit Information), needs to be established.
Additionally a solution needs to be found, how it can be verified, that all drivers in a specific section
have received the valid messages as it is a requirement e.g. for the ISA with Infrastructure LinkService. This needs to be taken into account in the development work.

Demonstration Site 4 consists of several parts of motorways spread all over France. Even if the
Motorway Operators are different and the implementation of the COOPERS services will be for sure
different, the functions of the Reference Architecture need to be followed to ensure a common view
on COOPERS services.
Page 82 of 159
COOPERS
integrated project
11 Next steps
11.1 UML architecture (SWP3200)
The COOPERS high-level architecture which has been developed with the FRAME methodology is
used for discussion and communication with project partners as well as external stakeholders.
Furthermore, its use ensures compliance with other projects and operational systems, but on the
other hand, it is too abstract to derive patterns for the hard- and software development.
Therefore an additional layer in between had to be implemented. COOPERS uses UML defined
models that are based on the FRAME-compliant high-level architecture and Annex 2: service
description tables, but offer a higher degree of detail for developers and procurement. Moreover, it is
the proper tool to track changes and results of discussions about specific parts of the architecture.
The UML model contains use case, activity and sequence diagrams which enable it to better
describe the chronology of events compared to FRAME architecture. The user needs and
descriptions of frame functional elements are included in the descriptions of the use cases and
activity elements of the UML diagrams. The model is currently provided in draft version 1.6 and
included in the draft report IR3200.
11.2 Communication viewpoint link analysis (SWP3300)

Together with partners of SWP3300 and 3400 many feedback cycles have been established to
ensure that the high-level architecture and the service descriptions meet all the requirements to
assess the communication links. In SWP3300 several promising wireless transmission technologies
such as IR-MR, CALM-IR, DSRC, WLAN derivates, Bluetooth, broadcast media like DAB/DVB and
cellular media such as GPRS/UMTS or WiMAX are analysed regarding their link capabilities such as
latency, throughput, link costs or coverage to assess if they are able to provide the services and their
specified content to the vehicle. For further information see IR3300-2.
11.3 In-car networks Floating Car data (SWP3400)

The COOPERS high-level architecture includes the extended floating car data concept which utilises
data from the in-vehicle bus systems. SWP3400 assesses the potential of vehicle sensor data and
data fusion to detect events and provide additional information to the infrastructure. In cooperation
with the FP6 IP SAFESPOT it is aimed to provide a common set of messages from the vehicle either
to other vehicles or the infrastructure.
11.4 Definition of new functions and requirements (SWP3800)

The work on the COOPERS high-level architecture is carried on by SWP3800 which has the task to
define new functions and requirements that were not already covered by the EITSFA. Therefore, the
service descriptions are analysed in detail to extract new, additional requirements. New functional
elements have to be designed to cover all needs, such as integration of extended floating car data or
verifiable message transmission. Chapter 4.2 describes the main new functionality which has to be
developed. After the definition of functionality and requirements is done an update of the COOPERS
Page 83 of 159
COOPERS
integrated project
high-level architecture is necessary to ensure proper integration into the system. The resulting
update will be documented and added to this report.
Furthermore, a common catalogue of new requirements and functionality of cooperative systems is

developed by collaboration with the other FP6 IPs CVIS and SAFESPOT and will be forwarded with
a request to standardisation. Another area of cooperation at system architecture level is the definition
of a harmonised map update service.
Page 84 of 159
COOPERS
integrated project
12 References
[EASIS]: Deliverable D0.2.4, General Architecture Framework, Version 1.1, 13. 8. 2004
[FRAME1]: European ITS Framework Architecture, FRAME Selection Tool, User Handbook, Version
1, April 2004
[FRAME2]: European ITS Framework Architecture, Functional Viewpoint, D3.1 Main Document,
Version 3, November 2004
[FRAME3]: European ITS Framework Architecture, Physical Architecture, Annex 1 Descriptions of
example Systems, Annex 1 of D3.2 - Issue 1, August 2000
[FRAME4]: Jan Willem Tierolf, Richard Bossom, Planning a modern transport system A guide to
intelligent transport architecture, Issue 2, April 2004
[GST1]: DEL_GST_SAF_CHAN_3_1 Architecture and Interface Specifications, Version 1.1,
15.12.2005
[GST2]: High Level Architecture, DEL_IP_3.1, 8/11/2004
[GST3]: GST Safety Channel System and Messages specification, DEL_GST_SAF_CHAN_3.2,
Version 1.0, 15/03/2006
[IJPO] ITS Joint Program Office, US Department of Transportation: Vehicle Infrastructure Integration
(VII), VII Architecture and Functional Requirements, Version 1.1, July 2005
[PREVENT]: Willwarn, SP Deliverable, D22.54 Communication Architecture and Simulation
Environments, V.10, January 2006
[SAFESPOT1] Project Outline: SIXTH FRAMEWORK PROGRAMME, FP6-2004-IST-4, Strategic
Objectives Addressed, September 2005
[SPEEDALERT] SpeedAlert: D4, Work Package 4, Version 2.0, July 2005
[COOPERS1] COOPERS: IR3200, Delivery of UML specification documents, Draft 1.6, October
2007
[COOPERS2] COOPERS: IR3300-2, Analysis of impact on communication links, Final v4.7,
December 2007
[COOPERS3] COOPERS: IR3400-1, State of the art of in-car networks and on-board Intelligence,
Final v1.1, February 2007
[COOPERS4] COOPERS, Summary report on safety standards and indicators to improve the safety
on roads, COOPERS D5-2100, September 2007
Page 85 of 159
COOPERS
integrated project
Internet sources
[FRAME5] http://www.frame-online.net/BrowsingTool/BrowsingTool_Version3/HomePage.html
www.car-to-car.org
www.comesafety.org
www.cvisproject.org
www.frame-online.net
www.gstproject.org
www.safespot-eu.org
Page 86 of 159
COOPERS
integrated project
Annex 1: Summary of the functions

1.3.1
Detect User
This Low Level Function shall detect the approaching traveller or vehicle. When
detected, the Function shall trigger the other Functions in the Provide Electronic
Payment Facilities Area.
1.6.1
Manage Tariffs
This Low Level Function shall maintain the "tariffs" Data Store with information
from the (public transport) operators or service providers. It shall be able to
modify these tariffs with messages from the Manage Traffic Area.
2.1.1
Acquire Mayday Call on Roadside

This Low Level Function shall provide facilities to enable any traveller to send a
mayday call from a roadside system. It shall include a human/machine interface
to receive information from a traveller and to give them the information contained
in the mayday call acknowledgement. It shall also include functionality that sends
and receives messages from an emergency centre.
2.1.2.1
Identify and Classify Emergencies

This Low Level Function shall be in charge of collecting incident notification,
mayday call and alarm. It shall filter and gather them to complete the associated
information (location, cargo status, identification of vehicle and traveller...) in
order to produce an emergency ready to be planned. It shall also give an
immediate acknowledgement to mayday call and transmit every incident/mayday
call for traffic management purpose.
2.1.2.4
Process Emergency Progress Reports

This Low Level Function shall include all functionality related to co-ordination of
the emergency services and traffic authorities. It shall provide also informed
acknowledgement to mayday call originator.
2.1.5
Provide Access and Maintain Data for Emergency

This Low Level Function shall include all functionality that enable it to
acquire/update data that is useful during incident/emergency processing and that
can be prepared before. This data shall comprise but not be limited to road
network map, predefined emergency road, emergency services references and
roles, plus emergency procedures. This Function is the mandatory interface with
the Common Emergency Data Store.
3.1.2.3
Provide Inter-urban Traffic Forecasts and Strategies

This Low Level Function shall provide predictions of traffic conditions and traffic
management strategies for the inter-urban road network. It shall use current and
historical traffic data for the inter-urban road network as input to algorithms that
enable it to predict what the traffic flow shall be like and produce the new
strategies. These predictions and strategies shall be produced periodically or at
the request of the Operator. When completed the predictions shall be sent to
Page 87 of 159
COOPERS
integrated project
other Functions and to other Areas within the System. The traffic management
strategies shall be sent to the inter-urban traffic control Function.
3.1.2.5.1
Provide Inter-urban Traffic Management

This Low Level Function shall provide traffic control facilities for the inter-urban
road network. It shall enable the traffic to be controlled so that the most efficient
use is made of the inter-urban road network. The Function shall be able to
implement control strategies in a planned sequence according to the time of day
and day of week. It shall be possible for these strategies to include control of
access to the inter-urban network (ramp metering), plus lane use and speed
control commands. Facilities shall be provided to enable these strategies to be
overridden by the Operator, as well as by inputs from the incident, demand and
access management Functions. It shall be possible for the Function to use
current, historic and predicted traffic data from the inter-urban network and to
change its actual control commands to take account of this data in real-time. This
shall enable the Function to continuously adapt its control of the inter-urban road
network to suit the actual traffic conditions if so required. The Operator interface
Function shall be able to obtain details of the current and previous modes of
control on some or all parts of the inter-urban road network. Feedback of the
results of commands sent to the output actuation Function shall be monitored so
that if necessary corrective action can be taken if commands are not followed.
3.1.2.5.2
Provide Planned Inter-urban Traffic Management Facility

This Low Level Function shall provide facilities that enable inter-urban traffic
control strategies to be implemented automatically by a timed sequence. This
sequence mechanism within the Function shall permit the implementation to be
by any combination of time of day, day of week, day of month, or day of year.
The sequences shall be received from the Operator interface Function which
shall also be able to request output of the sequences currently available for use.
Requests for implementation of control strategies shall be sent to the inter-urban
traffic and access control Functions.
3.1.2.5.4
Provide Inter-urban Traffic Speed Management

This Low Level Function shall provide the management of vehicle speed settings
within the inter-urban road network. It shall receive commands to implement
speed settings from either the Operator interface or the inter-urban traffic control
Functions. The Operator request shall take priority and shall override that from
the inter-urban traffic control Function. Speed settings shall be sent by the
Function to the inter-urban output actuation Function and the Provide Advanced
Driving Assistance Systems Area.
3.1.2.5.5
Provide Inter-urban Output Actuation

This Low Level Function shall provide output of commands to travellers that
enable the inter-urban road network to be managed in a safe and efficient way.
These commands shall be provided by the inter-urban traffic control Function.
Output of the commands shall be possible in a variety of ways such as single
indications, and/or multiple indications, and/or text messages. It shall be possible
for the output to be read and acted upon by all types of drivers, cyclists and
pedestrians using the inter-urban road network. Facilities shall be provided by
Page 88 of 159
COOPERS
integrated project
the Function so that incorrect action the commands can be reported to the
maintenance management Function.
3.1.2.5.7
Provide Operator Inter-urban Traffic Management Facility

This Low Level Function shall enable the Operator to manage the control of
traffic in the inter-urban road network. It shall be possible for the Operator to
change the current inter-urban traffic control strategy, except when it is imposed
as part of an incident or demand management strategy, or to provide selective
vehicle priority. The Operator shall be informed of the success or failure of the
requested change. It shall also be possible for the Operator to examine and
update the sequence of inter-urban traffic control strategies that are implemented
automatically, and to see the "log" of previously implemented inter-urban traffic
control strategy changes. The Operator shall be able to provide input through a
keyboard, some form of "point and click" based data collection, an electromechanical device, or audio converter. It shall be possible for the output can be
sent to the Operator using an audio device, a visual device, a mechanical device,
as printed material, or any combination of these. Output shall also be available
on electronic storage devices at the request of the Operator.
3.1.2.5.9
Manage Inter-urban Static Traffic Data

This Low Level Function shall be responsible for managing the store of static
data that is used by the inter-urban traffic management Function. It shall be able
to receive updates from the Operator and shall make all data available to the
inter-urban traffic management Function. Data about charges and vehicle access
regulations for the urban road network shall also be sent to Functions in the
Provide Electronic Payment Facilities Area. When vehicle location data is
received, the Function shall send data about traffic regulations that apply to the
geographic area relevant to the location to Functions in the Provide Advanced
Driver Assistance Area.
3.2.1
Detect Incidents
This Low Level Function shall detect that possibly incidents have occurred. It
shall provide facilities that enable the use of both data provided by other
Functions and video image data as inputs. Both types of data shall be analysed
for patterns that suggest the occurrence of an incident. Details of an incident
occurrence shall be sent to another Function for classification storage.
3.2.2
Identify and Classify Incidents

This Low Level Function shall identify and classify incidents. It shall use data
about incidents that is provided by another Function, the functionality in other
Areas of the System and received from terminators. The data shall be identified
and classified as a particular type of incident according to its source using
internal "rules" within the Function. It shall then be sent for storage and
subsequent assessment.
3.2.5
Provide Incident Management Operator Interface

This Low Level Function shall provide the interface through which the Operator
can control the management of incidents and the implementation of incident
management strategies. It shall enable the Operator to confirm the
Page 89 of 159
COOPERS
integrated project
implementation if needed, to input and update incident data, and to provide
incident management strategies. The Function shall also enable statistical
reports on the occurrence of incidents and the use strategies to be provided to
the Operator on request. The Operator shall be able to provide input through a
3.4.1
Monitor Weather Conditions

This Low Level Function shall collect data about weather conditions. It shall be
possible for the data to come from Weather Systems or to be detected using
sensors within the road network. The data shall be forwarded to another Function
for storage.
3.4.4
Predict Environmental Conditions

This Low Level Function shall use collected data to predict the environmental
conditions that will occur in and around the road network managed by the
System. The collected data shall be provided by another Function. It shall be
used with an algorithm and static data to produce the predictions. These shall be
sent to another Function for storage.
3.4.5
Provide Environmental Conditions Operator Interface

This Low Level Function shall provide the interface through which the Road
Network Operator shall be able to manage the collection of environmental data
and its use by other functionality within the System. As part of this activity it shall
be possible for the Operator to obtain output of the data currently being collected,
prediction of environmental conditions and historical data. It shall also be
possible for the Operator to update the static data used in the prediction of
environmental conditions. The Operator shall be able to provide input through a
3.4.6
Manage Environmental Conditions Data

This Low Level Function shall manage the Data Store of environmental data. In
performing this activity, it shall collect and collate data provided by other
Functions and from other System(s) and load them into the Data Store. When
requested by the Operator, or at periodic intervals, the Stored data shall be sent
to the prediction function. The resulting environmental conditions predictions
shall be added by the Function to the contents of the Data Store. Data shall be
sent to other Functional Areas and other parts of the Manage Traffic Area again
at periodic intervals, or at the request of the Operator.
3.5.1
Evaluate Short Term Maintenance Needs

This Low Level Function shall evaluate the short term maintenance needs of the
Page 90 of 159
COOPERS
integrated project
road network and shall request any needed repair activities. It shall use data
about the amount of traffic that has been using the road network and weather
information. This shall be compared against what it means in terms of required
short term maintenance and from this recommended activities shall be derived. If
these are confirmed by the Operator then the Maintenance Organisation shall be
requested to carry out the work.
3.5.2
Evaluate Long Term Maintenance Needs

This Low Level Function shall evaluate the long term maintenance needs of the
road network and shall request any needed repair activities. It shall collect data
about the use that traffic has been making of the road network and weather
information. This shall be compared against what it means in terms of required
long term maintenance and from this recommended activities shall be derived. If
the application of these activities are confirmed by the Operator then the
Maintenance Organisation shall be requested to carry out the work.
3.5.4
Evaluate De-icing Need

This Low Level Function shall evaluate the need for the de-icing of roads and
pavements. It shall collect data about the current state of the road and pavement
surfaces and evaluate these against criteria for the need to apply de-icing. When
de-icing is found to be required, the Function shall request the Maintenance
Organisation to carry out the activity.
3.5.5
Provide Operator Maintenance Operations Interface

This Low Level Function shall provide the interface through which the Operator
can control maintenance activities. It shall enable the Operator to confirm or
reject both short term and long term maintenance activities, to review and update
the criteria by which the need for maintenance and repair is decided and to
monitor maintenance activities. The Operator shall be able to provide input
through a keyboard, some form of "point and click" based data collection, an
electro-mechanical device, or audio converter. It shall be possible for the output
can be sent to the Operator using an audio device, a visual device, a mechanical
device, as printed material, or any combination of these. Output shall also be
available on electronic storage devices at the request of the Operator.
3.5.6
Manage Maintenance Data Store

This Low Level Function shall be responsible for the management of the store of
maintenance data. This store shall contain databases of maintenance operations
and of the road network, infrastructure and road-side equipment. It shall be
possible for other maintenance Functions to obtain data from the store and for its
contents to be changed through the operator interface Function. The Function
shall update the data about maintenance activities based using input from other
Functions and from the Maintenance Organisation.
5.11.3
Provide Mayday Call

This Low Level Function shall make a Mayday Call to the emergency services,
and provide some basic information on the reason for it. The call to be both
manually by an occupant of the vehicle, or automatically by the driver monitoring
Page 91 of 159
COOPERS
integrated project
system or the accident sensor.
5.12.2
Provide Communications with In-Vehicle Systems

This Low Level Function provides an interface between the systems inside the
vehicle, usually Advanced Driver Assistance Systems (ADAS), and the
functionality contained within the Framework Architecture.
5.12.3
Collect Road Infrastructure Data

This Low Level Function collects data from the infrastructure of two forms.
Copies of the traffic signs are sent to a display for the driver, and also to other
vehicles. Guidance signals are received from the road pavement, together with
an indication of their integrity, and passed on to the relevant in-vehicle systems.
5.12.4
Provide Traffic Regulations

This Low Level Function receives the current traffic regulations for this section of
the road and displays them to the driver.
5.12.5
Provide Vehicle ID
This Low Level Function shall read the vehicle ID from the vehicle system and
send it to other functions on request.
5.13.1
Provide Vehicle Position Determination

This Low Level Function shall provide the capability for the vehicle to determine
its position. This shall be determined with the accuracy required by the service
provider to really dispatch the specific service to the vehicle.
5.13.2
Prepare Floating Car Data

This Low Level Function shall make available to the Manage Traffic Functions
(Area 3) data collected by the vehicle. The Function shall transmit this data at
periodic intervals so that the vehicles become probes within the road network.
5.13.3
Provide ISA Facilities

This Low Level Function shall provide support for the driver to keep the vehicle
below a mandatory speed limit automatically.
5.13.4
Provide ISA Speed Limits

This Low Level Function shall provide speed limits for ISA directly. These will
override the speed limits held in the ISA Data Store (D5.2) if it exists.
5.13.5
Provide Current Speed Limit

This Low Level Function receives the current speed limit and display it to the
driver.
6.1
Define Travellers GTP

This Low Level Function shall construct a set of factual data and general trip
preferences. This shall be done once as a preparation to full personalisation,
although this part shall not be absolutely necessary in all applications. The
Function shall also activate measures to reduce the amount of information
generated. The following parts can or have to be defined: Each time a new trip is
initiated this set can be adapted for the trip at hand; also during trip evaluation
Page 92 of 159
COOPERS
integrated project
this set can be changed, this time for all trips.
6.3.1
Track Traveller and Implement Trip Plan

This Low Level Function shall follow the progress of the Traveller and implement
each part of the trip plan. It shall be possible for a variety of tracking methods to
be used by the Function to determine the actual location of the Traveller. If none
are available, the Function shall follow the time schedule. i.e. use a form of dead
reckoning. As the Traveller moves through the travel network, the Function shall
monitor progress against the trip plan. Based on this data the Function shall
request assessment of any perturbations in the travel network. If required by the
trip plan, the Function shall activate the route guidance Function.
6.3.3
Inform Traveller
This Low Level Function shall inform the moving traveller any perturbations to
the travel network and the eventual consequences to the trip plan. Any feedback
given by the Traveller shall be used to update the data in the trip file Data Store.
The results of the implementation of the trip plan shall be sent by this Function to
the evaluation Function.
6.3.6
Provide Traveller Guidance

This Low Level Function shall provide route guidance to Travellers. The
guidance will be provided regardless of the mode of travel, provided that the
Traveller has a means of receiving the instructions. It shall be possible for the
information to be it based on the original or the adapted trip plan and route. The
information shall take account of the latest traffic information so that congestion
and other problems can be avoided. Initially if the Traveller does not appear
follow instructions the Function will repeat the guidance information to
compensate for the mistake.
6.3.7
Assess the need for Trip Plan Changes

This Low Level Function shall assess any perturbations to conditions in the travel
network and the way in which the Traveller is following the Trip Plan. The
conditions assessment shall be performed against the latest information about
perturbations in the road network conditions. Deviations from the Trip Plan shall
be calculated by comparing the current position of the Traveller with the
expected location according to the Trip Plan. If necessary the Function shall
request the preparation of a revised Trip Plan for the remaining portion of the
journey. Any revised Trip Plan must be sent to another Function so that the
Traveller can be consulted before it is implemented.
6.5.1
Define Traveller Trip Preferences

This Low Level Function shall compose the set of factual data and preferences
for the actual trip. If available the Function shall use the definition of this data in
GTP. Otherwise, or if the trip deviates from GTP data or it involved pedestrian
and/ or cycling modes the data shall be produced by the Function. The data shall
comprise but not be limited to the destination, any necessary bookings, the
schedule, and whatever else is deemed interesting for trip satisfaction. It shall
enable Support Trip Function to react in the correct way when perturbations
Page 93 of 159
COOPERS
integrated project
occur with the travel network.
6.5.2
Provide Trip Planning Interface

This Low Level Function shall initiate the actual trip planning process using the
parameters collected by F6.5.1. When the trip planning process has been
completed, the Function shall present the results to the Traveller. If necessary
the Function shall initiate the trip planning process several times so that it can
present a number of alternative itineraries to the Traveller. These alternatives
may comprise but not be limited to possible perturbations of the schedules,
journey times and costs. The Function shall provide the Traveller with the
opportunity to refine the current parameters to produce alternative trip plans. It
shall work in an iterative way to produce more and more accurate trip plans.
Successive trip plans shall be stored internally so that they can be re-called by
the Traveller if later versions turn out to be unsatisfactory. Once a trip plan has
been accepted by the Traveller, the Function shall send the details to the
Function responsible for producing the travel itinerary, or to the Function
responsible for making any bookings that are included in the trip plan.
6.5.3.1
Plan Traveller Trip

This Low Level Function shall manage the production of trip plans based on data
provided by the Traveller through other Functions. The Function shall check the
criteria provided by the Traveller and obtain information for the specified modes,
for the requested trip. Where required it shall use data from the Road Trip
Planning Data Store (D6.3) and/or the PT Trip Planning Data Store (D6.4). It may
also request information from other modes where specified by the Traveller, or
due to transport policy requirements. Road trips for cyclists and pedestrians shall
be produced by the Function using the road network data and related
perturbations, but disregarding traffic incident information. If required by the
Travellers criteria, the Function shall obtain travel information for other transport
modes. It shall also obtain information about tolls and other charges if they will
be required in order for the Traveller to complete the trip. The Function shall also
be able to revise a part completed trip plan when a Traveller departs in any way
from its contents, or travel conditions change. In these circumstances the
Function will perform processing similar to that for a new trip plan, but start from
the new Traveller location and/or mode of travel.
6.5.3.2
Collect Road Traffic Data

This Low Level Function shall collect road based travel data for use in the
preparation of trip plans for Travellers, as well as for Freight and Emergency
Vehicles. The data shall be collected as it arrives from functionality in the
Manage Traffic Functional Area (3) and entered into the Road Trip Planning Data
Store (D6.3).
13.1.3.2
COOPERS Identify User

This Low Level Function shall identify the traveller, driver or the vehicle. It shall
also inform other Functions about the use that is being made of various parts of
the road transport infrastructure, e.g. parking occupancy, time of travel between
Page 94 of 159
COOPERS
integrated project
toll gates, etc.
13.1.3.5
COOPERS Compute Service Fee

This Low Level Function shall calculate the fee corresponding to the service
required by the user, based on the characteristics of this service, and on the
contract established by the user. The general tariffs for the service are held in a
data store, and the Function may vary the fee depending on the current situation.
13.1.3.8
COOPERS Provide Charging Information

This Low Level Function shall provide charging information to the driver. This can
be information about the current section or the cumulative sum of the charges
paid so far on the current trip.
13.3.1.2.1
COOPERS Collect Inter-urban Traffic Data

This Low Level Function shall collect sampled data from the road network and
fuse it with collected FCD to ensure consistent and reliable traffic.
13.3.1.2.4
COOPERS Manage Inter-urban Traffic Data

This Low Level Function shall manage the Inter-urban Traffic Data Store. It shall
receive inter-urban traffic and service area data from other Functions in the
Manage Traffic Area and from other Systems. This data shall be loaded into the
Store and also sent to other Functions and Areas for their use. The data in the
Store shall be divided into three parts, current, historic and predicted. If needed,
data from another independent source shall be used for validation to prevent
false alarms.
13.3.1.2.5.6
COOPERS Provide Inter-urban Lane Management

This Low Level Function shall provide management of the lanes on roads in the
inter-urban network. The Function shall enable the management of the lanes so
that the most efficient use can be made of the available road space. It shall
enable the use of lanes to be changed in a way that is safe for vehicle operation
and that causes the minimum disruption to all forms of inter-urban road traffic.
Implementation of commands to alter the use of lanes shall be sent to the urban
output actuation Function.
13.3.1.2.5.8
COOPERS Detect Inter-urban Traffic Violations

This Low Level Function shall detect violations of inter-urban traffic control
commands and report them to functionality in the Provide Support for Law
Enforcement Area. Reporting of a violation shall only occur when it is detected
that a vehicle does not follow the current inter-urban traffic commands. Details of
these commands shall be provided by the inter-urban traffic management
Function.
13.3.1.2.6
COOPERS Sample Traffic Data

This Low Level Function shall sample traffic data from the inter-urban road
network. This data shall be provided as raw input by sensors within the Function
that are capable of detecting the presence of all types of road vehicle, from
bicycles to heavy freight vehicles. This raw input shall be processed to provide
actual traffic flow data, e.g. flow, speed, etc. It shall be passed to other Functions
Page 95 of 159
COOPERS
integrated project
for collation and use in traffic control.
13.3.1.2.7
COOPERS Collect Floating Car Data

This Low Level Function shall gather floating car data and extended floating car
data from vehicles. It shall include a filter mechanism to prevent that unusual
behaviour of one driver or vehicle influences the predictions.
13.3.1.2.8
COOPERS Gather Traffic Status

this Low Level Function shall manage the database access of the FCD store. It
shall also be able to implement filter & deletion algorithms to ensure the effective
storage of only relevant floating car data.
13.3.1.2.9
COOPERS Manage FCD

This Low Level Function shall manage the database access of the FCD store. It
shall also be able to implement filter & deletion algorithms to ensure the effective
storage of only relevant floating car data.
13.3.2.3
COOPERS Assess Incidents and Determine Responses

This Low Level Function shall manage the assessment and response to
incidents that have been detected by other Functions. Periodically it shall review
the data that has been collected about incidents and decide if any action is
needed. When action is needed the Function shall search for an appropriate
incident strategy, for which it shall obtain Operator confirmation before
implementing. It shall be possible for an incident strategy to involve revisions to
the current traffic management strategy, output of warning messages (locally and
globally), plus notification of the Manage Public Transport Operations and
Provide Safety and Emergency Services Areas. If the Function finds that there is
no appropriate strategy the Operator shall be informed so that either a strategy
can be produced, or the Operator can take action by direct intervention using
other Functions. Updates about the progress of dealing with current incidents
received from the Emergency Services shall be assessed and any current
incident strategies refined to accommodate changes.
13.3.2.4
COOPERS Manage Incident Data and Validation

This Low Level Function shall be responsible for the management of data about
incidents and the production of statistical reports. It shall receive data about
reported incidents and updates to that data from other Functions and incident
data from other Systems. All the data shall be Stored and retrieved when
requested by another Function for assessment. When requested by the
Operator, the Function shall retrieve the data from the Store and produce the
required incident statistics reports. If needed, data from another independent
source shall be used for validation to prevent false alarms.
13.5.14.4
COOPERS Provide Traffic Status

This Low Level Function receives the current traffic warnings and information for
this section of the road and displays them to the driver.
13.7.3.1
COOPERS Manage Traffic Regulations Violators Notifications

This Low Level Function shall organize and store incoming traffic violations for
Page 96 of 159
COOPERS
integrated project
statistical usage.
13.7.3.3
COOPERS Provide Violator Notifications Interface

This Low Level Function shall provide an interface to access fraud notification
data for operators.
Page 97 of 159
COOPERS
integrated project
Annex 2: service description tables

Based on the identified services in [COOPERS4] the high-level system requirements specification
has been elaborated in WP3000. The result of this work is listed in this chapter of the annex. The
same table structure as provided from WP2000 has been used.
ID
S1a
Service Area
Incident management
Name of Service
Accident warning
General functions
To warn drivers of a road accident ahead with in-vehicle, dynamic

information. No direct, automated message link to inform an emergency
service provider is foreseen.
typical event
occurence
* Location Type: spot, section

* Lateral: lane(s), one direction
(carriageway)
* Movement: stationary
Page 98 of 159
COOPERS
integrated project
data sources
DIRECT DATA SOURCES:

* TCC Decision Support System
* Road Operator
INDIRECT DATA SOURCES:
* roadside traffic sensors and detection technologies
* emergency call box network
* CCTV (closed-circuit television)
-> video stream
-> automated image processing analysis
* police or highway authorities (e.g. patrols, toll gate staff)
-> position, direction
-> traffic situation
-> lane bans, instructions
-> accident scene cleared
* vehicle(s)
- phone call
- FCD (event based, notification latency < 10sec)
-> airbag activations
-> longitudinal acceleration
-> average speed (feedback if speed profile is adequate)
-> position
-> brake force
-> brake status
* external sources:
- eCall
- TISP
- other phone calls
Road type applied
Motorways (including tunnels and bridges) and INDIRECT road network in

Berlin (Heerstrae)
User
Drivers on motorways
User
group
Objective To make drivers aware of the

situation and prevent following
accidents and congestion
Other traffic information providers
To warn other road users of the

accident
Page 99 of 159
COOPERS
integrated project
Message content
1) Service identifier (N) 2) detailed

cause of trigger (O)3) Current time
(N)4) Location and direction of the
road sections affected (N)5) Lane(s)
of the road sections affected (O)6)
Severity of accident (O)7)
Recommendations/instructions
[Speed, Lane] (O)8) time until
accident scene cleared (O)9)
recommended diversion route (O)10)
message time-to-live (N)11) expected
delay (O)
1) Service identifier (N) 2) detailed

cause of trigger (O)3) Current time
(N)4) Location and direction of the
road sections affected (N)5) Lane(s)
of the road sections affected (O)6)
Severity of accident (O)7)
Recommendations/instructions
[Speed, Lane] (O)8) time until
accident scene cleared (O)9)
recommended diversion route (O)10)
message time-to-live (N)11) expected
delay (O)
Condition for
starting the
service
As soon as reported by an established, reliable source.
Condition for
terminating the
service
* Police call
* Passenger call (verified)
* Automatic detection of accident scene cleared through monitoring of the
impact on traffic flow by TCC (verified)
* Scene clearing validated by operator via CCTV
Key Requirements * TCC -> OBU

- System latency: 1min average, 5min maximum
- OBU message has to be consistent with VMS
- message frequency < 3min
- Information wether the service is currently supported has to be given to the
OBU/user.
* OBU/RSU/Sensor -> TCC
- reliable data sources for detection/validation
- event has to be detected within 10sec
* OBU
- drivers have to be informed at least 2km before the accident scene
- drivers should be pre-warned early enough to exit the motorway before the
accident scene
- The information provided are understood by all road users ( via a language
independent format)
- The information should be provided well designed in terms of format and
amount to avoid overloading and distracting
* message display requirements
locality: longitudinal: 30m, transversal: lane-specific
content: consistent with VMS display + eventual additional information
priority: correct according to specification (to be defined)
user: correct message filtering according to vehicle type
Break-Down
Step 1: Information/data about the accident can be collected from various

internal/external sources including driver report (automatically or manually),
CCTV or others.
Step 2: Traffic condition is analysed/diagnosed by processing the collected
Page 100 of 159
COOPERS
integrated project
data.
Step 3: Data confirmed by 2nd source
Step 4: Based on the results from data processing, an action (or set of
actions) is automatically executed or provided to the road operator for
confirmation.
Step 5: Road operator confirms action, if needed.
Step 6: Transmit the warning/information to the affected drivers on the
specific road segments via a language independent format. At mean time,
providing the information to TISP for warning other road users (e.g. through
web information for pre-trip planning).
Step 7: Display message at the OBU according to priority and requirements
Step 8: Retransmit message according to requirements to ensure that new
vehicles also get the information
Step 9: Update message content when new information is available.
Step 10: Stop service if terminating condition is valid
Link with other
services
The following services may need to be operated parallelly:

* service triggers:
- Variable speed limit
- Traffic congestion warning
- Lane banning
* service gets triggered by:
--
Exeption
Page 101 of 159
COOPERS
integrated project
ID
S1b
Service Area
Incident management
Name of Service
Incident warning
General functions
To warn drivers of obstacles ahead with in-vehicle, dynamic information.
typical event
occurence

* Lateral: lane(s), one direction (carriageway), complete road
data sources

* Road Operator
* emergency call box network
-> video stream
* police, fire brigade, or highway authorities (e.g. patrols, toll gate staff)
* vehicle(s):
- passenger calls
-> brake status
-> brake force
-> position
-> ESP, ABS
-> average speed
* external sources:
- eCall
- TISP
Page 102 of 159
COOPERS
integrated project
- other phone calls
Road type applied
Motorways (including tunnels and bridges)
User
User group
Objective
To make drivers aware of the


incident.
Providing
1) Service identifier (N)
Information/Instruction
2) detailed cause of trigger (O)

3) Current time (N)
3) Current time (N)
4) Location and direction of the

road sections affected (N)

5) Lane(s) of the road sections

affected (O)
5) Lane(s) of the road sections

affected (O)
6) Severity of incident (O)
6) Severity of incident (O)
7) Recommendations/instructions
[Speed, Lane] (O)
[Speed, Lane] (O)
8) time until incident scene cleared 8) time until incident scene cleared
(O)
(O)
Condition for starting

the service
9) recommended diversion route

(O)
9) recommended diversion route

(O)
10) message time-to-live (N)
11) expected delay (O)
As soon as reported by an established, reliable source.

In case of a Heavy Goods Transport the warning strategy starts
according to the trip start.
Condition for
* Police or fire dept. call
terminating the service * Passenger call (verified)
* Automatic detection of incident scene cleared through monitoring of
the impact on traffic flow by TCC (verified)
Page 103 of 159
COOPERS
integrated project
Key Requirements
* TCC -> OBU- System latency: 1min average, 5min maximum- warning
message has to be consistent with VMS - message frequency < 3minInformation wether the service is currently supported has to be given to
the OBU/user.

- event has to be detected within 10sec
* OBU
- drivers have to be informed 2km before the accident scene
- drivers should be pre-warned early enough to exit the motorway before
the accident scene
- The information provided are understood by all road users ( via a
language independent format)
- The information should be provided well designed in terms of format
and amount to avoid overloading and distracting

locality: longitudinal: 30m,
transversal: lane-specific
Page 104 of 159
COOPERS
integrated project
Break-Down
Step 1: Information/data about the accident can be collected from

various internal/external sources including driver report (automatically or
manually), CCTV or others.
Step 2: Traffic condition is analysed/diagnosed by processing the
collected data.
Step 3: Data confirmed by 2nd source
confirmation.
specific road segments via a language independent format. At mean
time, providing the information to TISP for warning other road users
(e.g. through web information for pre-trip planning).
Step 7: Display message at the OBU according to priority and
requirements
Step 8: Retransmit message according to requirements to ensure that
new vehicles also get the information
Step 9: Update message content when new information is available
(e.g. update HGV position regularly)
Link with other

services

* service triggers:
- Lane banning
* service gets triggered by:- Exeption
Page 105 of 159
COOPERS
integrated project
ID
S1c
Service Area
Incident management
Name of Service
wrong-way driver warning
General functions
To warn drivers of oncoming wrong-way drivers with in-vehicle, dynamic

information.
typical event
occurence
* Location Type: section, area

* Lateral: one direction (carriageway), complete road
* Movement: downstream/upstream (speed)
data sources

* Road Operator
-> video stream
* police or highway authorities
-> instructions
-> wrong-way driver left motorway
* passing vehicle(s)
- phone calls
* other external sources
- TISP
Road type applied
User
User group
Objective
To make drivers aware of the


wrong-way driver.
Page 106 of 159
COOPERS
integrated project
Providing
Information/Instruction
Condition for starting

the service

3) Current time (N)
3) Current time (N)


[Speed, Lane] (O)
[Speed, Lane] (O)
As soon as an wrong-way driver is reported
Condition for
* Police or fire dept. call
terminating the service * Passenger call (verified)
* Automatic detection of incident scene cleared through monitoring of
the impact on traffic flow by TCC (verified)
Key Requirements
* TCC -> OBU

- System latency: < 1min
- warning message has to be consistent with VMS
- message frequency < 10sec
- Information wether the service is currently supported has to be given to
the OBU/user.
* OBU
- drivers should be pre-warned early enough to exit the motorway before
the accident scene
- if information is unreliable, warn both directions (human error in phone
call report possible)
- The information provided are understood by all road users ( via a
language independent format)
- The information should be provided well designed in terms of format
and amount to avoid overloading and distracting
locality: longitudinal: 30m, transversal: lane-specific
* Priority
- wrong-way driver warning has the highest priority and shall be passed
Page 107 of 159
COOPERS
integrated project
to the beginning of the queue
Break-Down
Step 1: Information/data about the accident can be collected from

various internal/external sources including driver report manually),
CCTV or others.
confirmation.
specific road segments via a language independent format. At mean
time, providing the information to TISP for warning other road users
(e.g. through web information for pre-trip planning).
Step 5: Display message at the OBU according to priority and
requirements
Step 6: Retransmit message according to requirements to ensure that
new vehicles also get the information
Step 7: Update message content when new information is available.
Link with other

services

* service triggers:
- Lane banning
--
Exception
Page 108 of 159
COOPERS
integrated project
ID
S2
Service Area
Weather condition
Service Name
Weather condition warning
General functions
Provide in-vehicle, dynamic information to warn drivers of hazardous

conditions ahead caused by weather conditions
typical event
occurence
* Location Type: spot, section, area

data sources

* Road Operator
* infrastructure weather sensors
* external weather information provider
* incl. predicted data (hourly, 72h horizon)
* all data sources can provide parts or all of the following content:
- air temperature
- dew point
- rel. Humidity
- road surface temperature
- sustained wind
- peak wind
- wind direction
- snow line
- precipitate (type, amount)
- fresh snow
- visibility
- cloud base
- barometric pressure
- hourly prediction for next 72h
* vehicle sensor data (event based, <10sec, dT)
- fog lamps
Page 109 of 159
COOPERS
integrated project
- temperature
- wiper activity
- location
* police
* road maintenance centre
User
Objective To increase driving safety by making

drivers aware of the situation and be
prepared for the hazard condition
To provide other road users with

weather warning
Message 1) Service identifier (N)

2) detailed cause of trigger (e.g.
content
weather condition type)
3) Current time (N)
4) Location and direction of the road
sections affected (N)
--> point, section, direction (N)
--> lane (O)
--> length (O)
5) Severity of current weather
condition (O)
--> severity (O)
--> reduced sight indicator (O)
--> slip hazard (O)
--> appearance [full, partial, direction]
(O)
--> passable [yes/no, vehicle type
restriction] (O)
--> damage hazard to vehicle (O)
6) Severity of predicted conditions
incl. time indicator (O)
--> see 5)
7) estimated delay (O)
8) message time-to-live
1) Service (N)
Condition for
starting the
service
Condition for
terminating the
service
2) detailed cause of trigger (e.g.

weather condition type)
3) Current time (N)
sections affected (N) --> point,
section, direction (N)--> lane (O)-->
length (O)
5) Severity (O)
6) estimated delay (O)
7) message time-to-live* link to VSL,
lane management services for
recommendations/instructions
* link to VSL, lane management

services for
recommendations/instructions
As soon as possible weather hazard is reported by a reliable (either
established source, or verified FCD messages) source
Terminated by TCC on the basis of reliable sources.
Page 110 of 159
COOPERS
integrated project
Key Requirements * TCC -> vehicle:
- warn only severe weather conditions that could affect safety or if there is a
link to a different legal speed
- system latency < 30 sec
- system latency via FCD path < 3min
- update frequency < 3min
- warning message has to be consistent with VMS
OBU/user.
* vehicle -> TCC:
- data-limiting algorithm has to be implemented to prevent floating the TCC in
case of wide area weather hazards (e.g. don't send FCD warnings if similar
warning message has been received)
* TCC:
- accuracy and correctness of warning message > 97%
- perform plausibility check to ensure correctness of warning message
* OBU:
- drivers have to be informed at least 2km in front of weather hazard scene.
- Consider locationing and tracking difficulties of various weather conditions
and adapt information range
independent format)
* weather warning types include:
- rain
- snow
- ice
- hail
- wind
- fog
- thunder storm
Page 111 of 159
COOPERS
integrated project
Break-Down
Step 1: Information/data about the accident can be collected from various,

reliable internal/external sources including driver reports (automatically or
Step 2: Weather condition is analysed/diagnosed by processing the collected
data.
confirmation.
Step 8: Update message content when new information is available.Step 9:
Stop service if terminating condition is valid
Link with other

services

* service triggers:
- Lane banning
- Roadwork information (in case of winter maintenance)

-Exeption
Page 112 of 159
COOPERS
integrated project
ID
S3
Service Area
Roadwork information
Name of
Service
Roadwork information
General
functions
To warn drivers of roadworks ahead with in-vehicle, dynamic information.
typical event
occurence

* Movement: stationary, downstrem/upstream (speed)
data sources

* Road Operator
1) short-term / long-term scheduled roadworks:
- road maintenance plan
- scheduled events (daily, weekly, monthly)
- road maintenance centre phone call
2) roadwork monitoring:
-> video stream
3) roadwork trailers, winter maintenance or heavy load vehicles
- provide regularly updated position
- trajectory
- size and vehicle type
* passenger call
* police (reports heavy load vehicles)
Road type
applied
Page 113 of 159
COOPERS
integrated project
User group
Objective
To make drivers aware of the situation To warn other road users of the
and prevent following accidents and
roadwork
congestion caused by bottleneck road
specific interface
Message
content
3) Current time (N)
3) Current time (N)
4) Location, direction, length and lane

of the road sections affected (N)
4) Location, direction, length and lane

of the road sections affected (N)
5) Recommendations/instructions [link 5) Recommendations/instructions [link

to VSL, Lane management services]
to VSL, Lane management services]
(O)
(O)
6) time when roadwork installation
starts (O)
6) time until roadwork scene cleared

(O)
7) time until roadwork scene cleared

(O)
7) recommended diversion route (O)

8) recommended diversion route (O)

Condition for
starting the
service
The warning strategy starts according to the roadwork trip start or notification
from the maintenance centre.
Condition for
terminating
the service
* Call / Message from Roadwork Trailer or Maintenence Centre that

roadworks are finished.
* Roadwork scene clearing validated by operator via CCTV
* Service timeout for planned roadworks for TISP (e.g. 1 month)
Page 114 of 159
COOPERS
integrated project
Key
* TCC -> OBU
Requirements
- System latency for planned roadworks: < 30 sec
- System latency for unplanned roadworks: 1min average; 5min maximum
- message frequency < 3min
OBU/user.
* TCC
* OBU
- drivers have to be informed at least 2km before the roadwork scene
independent format)
* message display requirementslocality:

longitudinal: 30m,
content: consistent with VMS display + eventual additional informationpriority:
correct according to specification (to be defined)
Page 115 of 159
COOPERS
integrated project
Break-Down Step 1: Information about roadworks is given by plan, roadwork trailer or

maintenance centre.
Step 2: Generate warnings according to planned warning strategy.
Step 3: Transmit the warning/information to the affected drivers on the specific
road segments via a language independent format. At mean time, providing
the information to TISP for warning other road users (e.g. through web
information for pre-trip planning).
Step 6a: Monitor roadwork on a regular basis or continously
Step 6b: Update message content when new information is available (e.g.
update roadwork position regularly)
Link with
other
services
* service triggers:
- Lane banning- Auxiliary lane
- recommended next link
*service gets triggered by:

- Accident warning
- Incident warning
Exeption
Page 116 of 159
COOPERS
integrated project
ID
S4a
Service Area
Lane utilization
Service Name
Lane banning
General functions
According to the type of vehicle and the network condition, it provides drivers
with in-vehicle information about lanes which are not accessible, e.g. on
HGV are not allowed to drive on the off-side lane on motorways. Also, some
network section has dedicated lanes for HOV or Public transport.
typical event
occurence
* Location Type: section

data sources

* Road Operator
-> video stream
* status of local autonomous VMS
* TCC
- static lane (restriction) database
- scheduled/planned lane restrictions
- historical data (traffic flow diagrams)
* vehicle sensor data (periodic, every 30sec)
- vehicle type
- location (lane)
- occupants
* other COOPERS services
- weather condition warning
- traffic congestion warning
- roadwork information
- accident warning
Page 117 of 159
COOPERS
integrated project
- incident warning
* external sources
- police
Highly occupied vehicles (HOV)
Heavy goods vehicles (HGV)
User
Objective To increase driving safety by making drivers aware of the situation and be
prepared for early lane change or diversion to avoid the closed lane/road
Message 1) Service identifier (N)

content
3) Current time (N)
4) Location, direction of the referred lane restriction (N)
5) length of lane restriction (N)
6) Number and position of banned lanes (N)
7) Vehicle type (N)
8) Reason for Lane ban (HOV, HGV, other services)
9) message time-to-live (DAB, GPRS?)
10) distance-to-live (short range, GPRS?)
Condition for
starting the
service
1) scheduled plan of lane banning operation
Condition for
terminating the
service
1) scheduled plan of lane banning operation
2) Operator command; triggered by other services
2) Operator command, when reason for lane ban does not apply anymore.
Validation via CCTV or other reliable source
Page 118 of 159
COOPERS
integrated project
Key Requirements
* TCC -> vehicles:

- System latency: < 1min (incremental changes)
- Update frequency: < 5min
OBU/user.
* ACK link:
- ACK has to be received within 15min
- ACK should have low data volume
- ACK received by > 99% of addressed vehicles (this requirement is not
evaluable for DAB))
* OBU
- lane restriction has to be filtered correctly according to vehicle type and
segment (N)
- Lane restrictions must be displayed as long as they apply. Display out-oforder message if service can't be guaranteed.
- lane restriction has to be consistent with roadside signs
- lane instruction has to be unambigous
- driver and vehicle type has to be configured
- in case of lane restrictions, accessible lanes have to be indicated as well
Break-Down
Step 1: Lane restrictions are static or triggered by other services or external

sources.
Step 2: Code lane restrictions to segments (position, length, vehicle type,
lane, direction) according to a standardized protocol.
Step 3: Transmit lane restrictions to vehicles and VMS.
Step 4: Processing of lane restriction
Step 5: Transmit application-level ACK back to TCC.
Step 6: Display of unambigous lane restriction.
vehicles also get the information (broadcast media)
Page 119 of 159
COOPERS
integrated project
Link with other

services

* service triggers:
-* service gets triggered by
- accident warning
- incident warning
- wrong-way driver warning
- auxiliary lane
Exeption
locally controlled VMS
Page 120 of 159
COOPERS
integrated project
ID
S4b
Service Area
Lane utilization
Service Name
Lane keeping
General
functions
To provide in-vehicle advice for drivers not to overtake to stabilize traffic

flow.
data collection
method

data sources

* Road Operator
- traffic congestion warning (this service monitors & predicts traffic flow.
S4b warning can be triggered before actual traffic congestion warning is
distributed)
-> video stream
- average speed
- location
Road type
applied
User group
Objective
To increase traffic flow by making drivers aware of the situation.
Page 121 of 159
COOPERS
integrated project
Message content 1) Service (N)
3) Current time (N)
3) Location, direction, length of the lane keeping advice (N)
4) Vehicle type (O)
Condition for
starting the
service
1) As soon as critical traffic flow density is monitored/reported by a reliable

(either established source, or verified FCD messages) source.
2) Operator command
Condition for
terminating the
service
1) As soon as congestion fading is reported by a reliable (either

established source, or verified FCD messages) source.
2) Service timeout (insert empirical value from road operator)
3) Operator command
Key
Requirements
* TCC -> vehicles:

- Update frequency: < 5min * OBU
- Keep in lane advice has to be filtered correctly according to segment (N)
and vehicle type (O).
- Keep in lane advice must be displayed as long as they apply.
- Keep in lane advice has to be consistent with roadside signs, if available
- vehicle type has to be configured
Page 122 of 159
COOPERS
integrated project
Break-Down
Step 1: Keep-in-lane advice is triggered by critical traffic flow density or

road operator.
Step 2: Code keep-in-lane advice to segments (position, length, vehicle
type, direction) according to a standardized protocol.
Step 3: Transmit keep-in-lane advice to vehicles and VMS, if possible.
Step 4: Processing of keep-in-lane advice message
Step 5: Display keep-in-lane-advice incl. reason (increase traffic flow)
Link with other

services

* Service is triggered by:
* Service triggers:
--
Exeption
Page 123 of 159
COOPERS
integrated project
ID
S4c
Service Area
Lane utilization
Service Name
Auxiliary Lane Accessibility
General
functions
Provide in-vehicle information to inform drivers on a specific motorway section

about the availability of auxiliary lanes for driving.
typical event
occurence

* Lateral: lane(s)
data sources

* Road Operator
-> video stream
* TCC
- static lane database
- scheduled/planned auxiliary lane accessibility
- average speed
- location
* external sources
- police
- operator cars
Road type
applied
User group
Highly occupied vehicles (HOV)
Heavy goods vehicles (HGV)
Objective
To increase driving safety by making drivers aware of the situation and be
Page 124 of 159
COOPERS
integrated project
prepared for the availablility of the auxiliary lane.
Message
content

3) Current time (N)
4) Location, direction of the referred auxiliary lane (N)
5) length of auxiliary lane (N)
5) Number and position of auxiliary lane (N)
6) Reason (O)
7) Vehicle type (HOV) (N)
Condition for
starting the
service
Operator command (scheduled plan of auxiliary lane operation)
Condition for
terminating
the service
Operator command (scheduled plan of auxiliary lane operation)
Key
Requirements
* TCC -> vehicles:

- System latency: < 30sec
* OBU
- Auxiliary lane has to be filtered correctly according to vehicle type and
segment (N)
- Auxiliary lanes must be displayed as long as they apply. Display out-of-order
message if service can't be guaranteed.
- Auxiliary lanes have to be consistent with roadside signs
- Auxiliary lanes have to be unambigous with respect to other direction
- vehicle type has to be configured
Page 125 of 159
COOPERS
integrated project
Break-Down
Step 1: Free auxiliary lane is validated via TCC. The whole length has to be
monitored simulateously to ensure that lane is non-occupied.
Step 2: Auxiliary lane service is triggered by operator.
Step 3: Code auxiliary lane to segments (position, length, vehicle type, lane,
direction) according to a standardized protocol.
Step 4: Transmit auxiliary lane availability to vehicles and VMS.
Step 5: Processing of auxiliary lane message.
Step 6: Display of unambigous auxiliary lane availability.
Link with
other services
* Service triggers:
- lane banning
* Service gets triggered by:

Exeption
locally controlled VMS
Page 126 of 159
COOPERS
integrated project
ID
S5
Service Area
Traffic management
Service Name
In-Vehicle Variable Speed Limit Information
General
functions
Provide drivers with in-vehicle information on legal speed for current

segment. Legal speed is correlated to traffic, environmental and infrastructure
conditions as well as the input parameters from other services. It contains static
and dynamic speed limits.
typical event
occurence

data sources

* Road Operator
-> video stream
* infrastructure equipment
- VMS (driver output actuation, status feedback to TCC)
- section control
* TCC
- speed profile
- static speed limit database
- average speed
- location
- congestion warning
- accident warning
Page 127 of 159
COOPERS
integrated project
- incident warning
* external sources
- police
Road type
applied
User group
Objective
To inform drivers of current legal speed limit and help them to support the
timely adaptation of their speed to upcoming driving conditions.
Message content
1) Service (N)
2) Current time (N)
3) Location, direction, lane and length of the referred speed limit zone (N)
4) legal speed limit (N) and type advised/mandatory (N)
5) Vehicle type (N)
Condition for
starting the
service
Service is continuously provided for motorways.
Condition for
terminating the
service
Leaving motorway.
After entering the motorway (DAB, GPRS) or the first connection setup (DSRC,
IR) the legal speed limit has to be displayed.
Time/distance to live exceeded (indication of system error)
Page 128 of 159
COOPERS
integrated project
Key
Requirements
* TCC:
- every segment has at least 1 legal speed limit
* TCC -> vehicles:
OBU/user.
* VMS -> TCC:
- System latency: < 10 sec
* ACK link:
evaluable for DAB)
* OBU
- speed limit has to be filtered correctly according to vehicle type and position
(segment (N), lane (O))
- Entering/Leaving the motorway has to be detected
- Legal speed limit must be displayed all the time. Display out-of-order message
if service can't be guaranteed.
- speed limit signs must be displayed at specified positions (+- 30m)
- speed limit has to be consistent with roadside signs
- speed limit has to be unambiguous (lane, unit)
- speed limits have to be displayed according to vienna convention
- plausibility check has to be performed
Break-Down
Step 1: Speed profile is generated by TCC software

Step 2: Code speed limits to segments (position, length, vehicle type, lane,
direction) according to a standardized protocol and ensure that all segments
are covered.
Step 3: Transmit speed limits to vehicles and VMS.
Step 4: Processing of speed messages
Step 6: Display of unambiguous speed limit.
Page 129 of 159
COOPERS
integrated project
Link with other
services

* Service triggers:
- ISA with infrastructure link
* Service gets triggered by:
- incident warning
- accident warning
- wrong-way driver warning
Exeption
Locally controlled VMS or roadwork trailer could trigger VSL service.
Page 130 of 159
COOPERS
integrated project
ID
S6
Service Area
Name of
Service
General
functions
Provide in-vehicle, dynamic information to warn drivers of congested traffic

ahead
typical event
occurence

* Movement: stationary, downstream/upstream (speed)
data sources

* Road Operator
-> video stream
* historical & predicted data
- traffic flow diagrams
* police, fire dept. and highway authorities (e.g. patrols)
* vehicle(s):
- passenger calls
-> average speed
-> position
Road type
applied
Page 131 of 159
COOPERS
integrated project
User group
Objective
To increase driving safety by making To provide other road users with

drivers aware of the congested traffic traffic congestion information
and be prepared for the condition.
Message
content
1) Service (N)
3) Current time (N)
3) Current time (N)
4) Severity [classification,
estimated/observed queue length,
delay time, average speed]

sections affected (N)
5) location of congestion tail end,

estimated propagation speed
5) Severity [classification,
estimated/observed queue length,
delay time, average speed]
6) location of congestion tail end,
[link to VSL, Lane management
estimated propagation speed
services, recommended next link] (O)
7) Estimated time to congestion
[link to VSL, Lane management
fading (O)
services, recommended next link] (O)
8) Estimated time to congestion

fading (O)
Condition for
starting the
service
As soon as an congestion is reported by a reliable (either established

source, or verified FCD messages) source.
Condition for
terminating
the service
*As soon as congestion fading is reported by a reliable (either established

source, or verified FCD messages) source.
* Service timeout (insert empirical value from road operator)
Page 132 of 159
COOPERS
integrated project
Key
* TCC -> OBU
Requirements
- System latency: 1min average, 5min maximum
- if congestion is displayed via VMS, OBU warning has to be consistentmessage frequency < 3min
- Information whether the service is currently supported has to be given to
the OBU/user.

* OBU
- drivers have to be informed 4km before the congestion end
independent format)
* message display requirementslocality:

longitudinal: 30m,
Page 133 of 159
COOPERS
integrated project
Break-Down Step 1: Information/data about the congestion can be collected from various
reliable internal/external sources including driver reports (automatically or
Step 2: Traffic condition is analysed/diagnosed by processing the collected
data.
confirmation.
Step 8: Update message content when new information is available (e.g.
update queue end position regularly)
Link with
other
services
* service triggers:
- Keep in lane
- Lane banning
- Auxiliary lane
- Recommended next link
- Estimated journey time
Page 134 of 159
COOPERS
integrated project
- accident warning
- incident warning
Exeption
Page 135 of 159
COOPERS
integrated project
ID
S7
Service Area
Speed Limit Information
Service Name ISA with infrastructure links

General
functions
Inform drivers of the current recommended speed limit and provide support
to match their automatic speed control to prevailing traffic, weather and road
conditions.
typical event
occurence

data sources

* recommended speed limit profile

* Variable speed limit profile
* static speed limit database

-> video stream
* infrastructure equipment
- VMS (driver output actuation, status feedback to TCC)
- section control
* TCC
- average speed
- location
* vehicle sensor data ("continous")
- current speed
Page 136 of 159
COOPERS
integrated project

- congestion warning
- accident warning
- incident warning
* external sources
- police
Road type
applied
User group
Objective
To guide drivers applying the current recommended speed limit. After

confirmation by the driver at the beginning of the service, the vehicle speed
should be adapted to the recommended speed limit automatically.
Message
content
1) Service (N)
2) Current time (N)
3) Location, direction, lane and length of the referred speed limit zone (N)
4) recommended speed limit (N)
5) Vehicle type (N)
Condition for
starting the
service
Service is continuously provided for motorways.
Condition for
terminating
the service
Leaving motorway.
After entering the motorway (DAB, GPRS) or the first connection setup
(DSRC, IR) the service can be activated by manual confirmation of the driver
Time/distance to live exceeded.

Driver disables service manually.
Page 137 of 159
COOPERS
integrated project
Key
* TCC:
Requirements - every segment has at least 1 legal speed limit
* TCC -> vehicles:
- System latency: < 10 sec (incremental changes)
- Update frequency: < 30 sec
the OBU/user.
* VMS -> TCC:
- System latency: < 10 sec
* ACK link:
evaluable for DAB)
* OBU
- Recommended speed limit has to be filtered correctly according to vehicle
type and position (segment (N), lane (O))
- Entering/Leaving the motorway has to be detected
- Recommended speed limit must be provided all the time. Display out-oforder message and disable ISA if service can't be guaranteed.
- Recommended speed limits must be triggered at specified positions (+30m)
- Recommended speed limit has to be consistent with roadside signs
- Recommended speed limit has to be unambiguous (lane, unit)
- speed limits have to be displayed according to vienna convention
- plausibility check has to be performed.
* RPU
- RPU must be able to determine the current lane
* vehicle:
- adaptive cruise control
Page 138 of 159
COOPERS
integrated project
Break-Down Step 1: Speed profile is generated by TCC software

Step 2: Code recommended speed limits to segments (position, length,
vehicle type, lane, direction) according to a standardized protocol and
ensure that all segments are covered.
Step 3: Transmit speed limits to vehicles and VMS.
Step 4: Processing of speed messages
Step 6: Display of unambiguous speed limit.
========================
2nd breakdown: user's viewpoint
Step 1: Driver starts service manually
Step 2: Recommended speed limit is received by OBU
Step 3: Plausibility check performed by OBU
Step 4: Provide recommended speed limit to Adaptive Cruise Control
Step 5: Service is disabled either manually by driver or follow-up speed data
is missing or leaving the motorway.
Link with
other
services

Service gets triggered by:
* Variable Speed Limit
Service triggers:
--
Exeption
Locally controlled VMS or roadwork trailers transmit speed data to TCC.
Page 139 of 159
COOPERS
integrated project
ID
S8
Service Area
Service continuity
Service Name
International service continuity
General
functions
Exchange static and dynamic network information based on standard

protocols between neighbouring control centres (internationally or
regionally) to ensure continuity of services for travellers.
Road type
applied
Motorways
User group
Traffic information centres or control centres
Objective
Data exchange for providing continued service
Message/display I2I
content
Copies of coded warning messages as defined in the services S1-S7
I2V
1) Originator
2) list of supported services
Condition for
starting the
service
Starts as defined in the interchange agreements between the road

operators or traffic information providers.
Condition for
terminating the
service
Ends as defined in interchange agreements between the road operators

or traffic information providers.
1. regular/scheduled static information exchange
Completion of information exchange is acknowledged.
2. dynamic information exchange.
Receipt of warning message is acknowledged.
Page 140 of 159
COOPERS
integrated project
Key
requirements
* Warning event content shall be provided in a ready-to-send format.

Situational data must not be interpreted by the receiving TCC
* Warning message generation to partner distribution latency < 10 sec, if
no or predefined strategy is realized.
* If needed, the database model has to be extended to manage the
extended area
* Information about the currently supported services has to be given to
the OBU/user.
* Message filtering shall be possible
* OBU has to transmit ACKs to the source TCC
* The communication link between the TCCs has to be reliable (>99%
transmissions successful within distribution latency)
* The user shall not recognise any difference in service provision during
and after the service handover.
* Events have to be classified and described in a standardised way.
* The OBU needs to provide valid service information also during the
handover. (no HMI service provision break)
* Locations shall always be referenced in the same way.
* The OBU shall be able to combine events if they are transmitted
separately due to different TCC responsibilities or information providers.
* Static information exchange:- Information will be exchanged on a
regular, scheduled basis as defined in the interchange agreements (e.g.
daily)
* Dynamic information exchange:
- Copies of warning messages are sent to the partner TCCs as soon as
they are generated (event based).
Page 141 of 159
COOPERS
integrated project
Breakdown
1) Warning message is generated in TCCsource.

2) Check interchange agreements between neighbouring TCCs and
determine if information is relevant for them.
3) Design/Use joint traffic management strategy if necessary
4) TCCsink: apply spatial and content filtering
5) Determine relevant segments the information needs to be sent to
6) Feed into queue. Take joint strategy into account.
Link with other

COOPERS
services
service triggers:
- S1-S7
service is triggered by:
- S1-S7
Page 142 of 159
COOPERS
integrated project
ID
S9
Service Area
Road Charging
Name of Service Road Charging to influence on demand

General
functions
The main focus is "to influence demand" by displaying the current, dynamic toll
directly to the user. The service will focus on demonstration of dynamic road
charing schemes and implement other parts of an EFC system only as far as
they are necessary to this functionality.
typical event
occurency

* Lateral: lane(s), one direction
(carriageway), complete road
data sources
DIRECT DATA SOURCES

* high-level road network status and prediction unit
* environmental sensors (e.g. pollution, noise)
* dynamic charging scheme data base
* historical database (environmental, traffic conditions)
* vehicle
- timestamp
- ID
- vehicle type
- location
- occupants
- route information (e.g. targeted motorway exit)
User
Driver
Fleet operator
Objective
To make the driver aware to protect

the environment and to optimize traffic
load on motorways.
To optimize HGV traffic load on

motorways by provision of dynamic
tolling information to fleet dispatchers
to support their pre-trip and on-trip
planning.
Page 143 of 159
COOPERS
integrated project
Message
content
I2V Link:
1) toll amount of current segment
2) current charging scheme (c/km,
dynamic parameters used)
3) prediction for next segments
according to travel time
V2I Link:
1) timestamp (N)
2) location: segment (N)
3) location: lane (O)
4) vehicle type (N)
5) number of occupants (O)
6) route information (e.g. targeted
motorway exit) (O)
Condition for
starting the
service
After entering the motorway (DAB,

GPRS) or the first connection setup
(DSRC, IR) the service can be
provided.
Condition for
terminating the
service
Leaving motorway.
Driver disables service manually.
I2I Link:
A database is maintained by the road
operator and accessible to fleet
operators. It contains all motorway
segments each of them providing the
following information:
1) segment ID
2) active charging parameters (e.g.
traffic load, vehicle type, time,
environmental)
3) current toll amount per vehicle type
4) short-term toll amount forecast (02h) according to dynamic parameter
predictions (time, traffic load,
environment) and vehicle type
5) mid-term forecast (2-24h) according
to dynamic parameter predictions
(time, traffic load, environment) and
vehicle type
always on
Page 144 of 159
COOPERS
integrated project
Key
Requirements
Requirements OBU:
The OBU shall store a geo object database consisting of a set of coordinates of
tolled road links
(this may be part of COOPERS navigation services).
It shall be possible to perform an update of the geo object database (-> Service
Check map update)
for newer information about the position, the attributes of the roads on the
planned route,
for planning purposes and for incidents like dynamic road work if the
environmental aspect is concerned.
The OBU shall be able to detect if vehicle is on toll road within 600 m or 1/3 of
length of road link
(whatever happens first) after entering the according road link (requirement
from [MISTER]).
The error rate in not detecting a tolled road link shall be below 10-4
(requirement from [MISTER]).
The rate of erroneously detecting a road link as being used shall be below 10-6
relative to all correctly
detected segments (requirement from [MISTER]).
The OBU shall be able to be configured according to vehicle type (passenger
car, HGV ).
The OBU shall support HMI for input of current vehicle configuration (e.g.
number axes, weight ).
The OBU shall store the passed toll road link IDs together with current
date/time, vehicle configuration (e.g. number axes, weight ).
The OBU shall send the stored data (toll road link ID ) together with vehicle
configuration to the EFC provider.
The OBU shall receive current toll and display it on the HMI.
Optional: The OBU shall sum up the toll of the driven road links and display the
sum.
Optional: The OBU shall be able to send a list of road link IDs (planned route)
with a time schedule
together with vehicle configuration to the EFC provider (link to navigation
services).
Optional: The OBU shall receive the sum of the toll which must be paid for the
planned route and display it on the HMI.
When using lane specific tolling:
The OBU shall record the (mostly?) used lane on a road link.
Requirements geo object database
The coordinates shall be accurate enough to distinguish roads (toll road from
toll road, toll road from other road).
When using lane specific tolling:
The coordinates shall be accurate enough to distinguish lanes.
Page 145 of 159
COOPERS
integrated project
Break-Down
Service breakdown for displaying current toll:
Step1) OBU: Detect road link on which vehicle just drives.

Step2) OBU -> TCC: Send road link ID and vehicle configuration (type/class )
to TCC.
Step3) TCC (EFC provider): Calculate toll based on vehicle configuration, time,
road demand
Step4) TCC -> OBU: Send calculated toll to OBU.
Step5) Display toll for road link OR value in cent/km on HMI.Step6) Display
accumulated toll for current trip on HMI.
Service breakdown for displaying toll for planned route:

Step1) Get information about route from COOPERS navigation service.
Step2) OBU -> TCC: Send list of road link IDs, time schedule and vehicle
configuration (type/class ) to TCC.
Step3) TCC (EFC provider): Calculate accumulation of toll based on vehicle
configuration, time, road demand
Step4) TCC -> OBU: Send calculated accumulation of toll to OBU.
Step5) Display toll for planned route on HMI.
Link with other -services

Exeption
Page 146 of 159
COOPERS
integrated project
ID
S10
Service Area
Estimated Journey Time
Name of Service Estimated Journey Time

General
functions
Provide in-vehicle, dynamic information on the estimated journey time of

motorway segments of the planned route to enable dynamic navigation.
typical event
occurence
1. route based
2. link based
data sources

* predicted travel times from TCC database
- roadside unit
- tolling unit
- Floating Car Data
- historical travel times
- highway patrols
- external service provider (e.g. vehicle fleet, GSM provider)
User
Objective
To increase road safety by optimizing

use of the road capacity and allowing
drivers to select more efficient routes
on the basis of real time information.
To provide road users with journey

time estimates
Message
V2I:
1) ID
2) timestamp
3) vehicle type
4) route information (e.g. array of
segments)
1) Identification of the road sections for

which journey times are provided (N)
I2V:
1) target ID
2) service identifier
3) estimated journey time deviations
for requested segments (estimations
based on predicted journey progress)
3) Journey time predictions, time

series (short-term, mid-term, longterm)
Estimated Journey time service is

activated by user (menu option).
Estimated Journey time is always on.
Condition for
starting the
2) Identification of date and time period

for which estimated journey times are
provided
Page 147 of 159
COOPERS
integrated project
service
Condition for
terminating the
service
Deactivation by user.
Key
Requirements
* TCC -> OBU

- System latency: 30 s average, 2 min maximum
- if journey time is displayed via VMS, OBU display has to be consistent
- message frequency depending on requests
- Information whether the service is currently supported has to be given to the
OBU/user.
- journey time deviations of requested segments > 3min shall be transmittedjourney time predictions for routes shall take predicted journey progress into
account (time window for estimation of follow-up segments)
* OBU
- drivers have to be informed if changes to route planning occur
independent format)
- Automated route requests can be activated/deactivated at OBU
- map database with default journey times has to be available
- The routing algorithm shall be able to handle incoming deviations

locality: longitudinal: 30m
Page 148 of 159
COOPERS
integrated project
BreakDown
In case of a broadcast mode, the TCC will send a coded list of road sections
and estimated travel times and periods for which these estimations are valid.
No message management is applied, though only the estimated journey times
are broadcasted that depart from the free flow condition.
In case of a personalized journey time estimation, the approach will be the
following:
Step 1: prepare route information based on current planned route
Step 2: transmit request for estimated journey times of the prepared route
Step 3: Check continously updated journey time estimations at TCC for
deviations
Step 4: Transmit deviations of requested segments back to requester
Step 5: update route at OBU based on new journey times
Step 6: Inform driver of route changes
note: feedback of actual journey time (FCD) is now covered by S13!

Link with other
services
The following services may need to be operated parallelly:* service triggers:Variable speed limit* service gets triggered by:- accident warning- incident
warning- roadwork information- traffic congestion warning
Exeption
Not applicable
Page 149 of 159
COOPERS
integrated project
ID
S11
Service Area
Recommended next link
Name of Service
Recommended next link
General functions Provide in-vehicle, dynamicm, public recommendations on motorway links

selected by the road operator.
typical event
occurence
1. route based
2. link based
data sources

* road operator
* TCC decision support system
- road network status map
- high-level road network map database
- travel time database
- roadwork database
- highway authorities
- police
- rescue services
Road type
applied
motorway
User group
Objective
To increase road safety and efficiency by optimizing use of the road capacity
via operator selection of more efficient routes on the basis of real time
information.
Page 150 of 159
COOPERS
integrated project
Message content

3) Current time (N)
4) vehicle type restriction (N)
5) location / affected route (N)
6) validity period (N)
7) alternate route (N)
8) details on alternate route [e.g. travel times] (O)
9) information type [informative/recommendation/binding] (N)
Condition for
starting the
service
Recommended next link is always on if dynamic data is available.
Condition for
terminating the
service
Recommended next link is always on if dynamic data is available.
Page 151 of 159
COOPERS
integrated project
Key
Requirements
* TCC -> OBU

- System latency: 30 s average, 2 min maximum
- if recommended next link is displayed via VMS, OBU information has to be
consistent
the OBU/user.
* TCC
- The application shall provide means for the road operator to define
information dissemination strategy (local area, vehicle type, information
provided to every x. vehicle)
* OBU
- drivers have to be informed during route planning and during the trip- The
information provided are understood by all road users ( via a language
independent format)
- The user shall be able to set the level of impact for route planning (e.g. take
only legal/legal+recommended/all information into account)

locality: longitudinal: 30m
Page 152 of 159
COOPERS
integrated project
Break-Down
1) Motorway link level of service drops below treshold

2) Identify route alternatives on high-level network and select best option
3) Route, target group (e.g. HGV, PT, driver) and level (informative,
recommendation, binding instruction) confirmed by road operator
4) Message transmission according to selected strategy
5) update route at OBU based on road operator recommendations according
to user settings in case of information/recommendation.
Link with other

services

* service triggers:
- Estimated Journey time
- accident warning
- incident warning
ID
S12
Service Area
Map update
Name of Service
Map update
General functions Provide up-to-date non-dynamic information for digital maps. This includes
structural alteration, static speed limits and default journey times. The
service is complementary to dynamic update services such as S5 and S10.
typical event
occurence
1. map updates on planned routes
data sources
* in-vehicle digital map database

* TCC digital map database
* road operator construction plans (digital)
* historical journey time database
* static speed limit database
Page 153 of 159
COOPERS
integrated project
User
Digital map providers
To increase road safety and efficiency by

ensuring that drivers always have the
latest static road network infromation
available.
To increase road safety and

efficiency by ensuring that
provided maps have up-to-date
non-dynamic information
implemented.
Providing
V2I:
Information/Instru
ction
2) ID
3) standardised version number of nondynamic content
4) requested area restriction (route,
specific motorway, segment, area)
I2V:
Infrastructure operator to map

provider:
1) standardised Version number
/ period of included changes (N)
2) Update on road infrastructure
geometry and attributes
3) Update on static speed limits
incl. location reference
4) Update on default travel times
incl. Link reference
2) target ID / request reference
3) version number of update
4) Update on road infrastructure geometry
and attributes
5) Update on static speed limits incl.
location reference
6) Update on default travel times incl. Link
reference
Condition for
starting the
service
Map updates are provided on request of

the OBU
Condition for
terminating the
service
The service is terminated if the map update request is completed or

terminated.
Page 154 of 159
Based on bilateral agreement

between infrastructure operator
and map provider.
COOPERS
integrated project
Key
Requirements
* TCC -> OBU

- System latency: 1 min average, 10min maximum (depending on size of
map update)
- message frequency depends on OBU request
the OBU/user.
* TCC update data:

- standardised representation of non-dynamic content
- representation shall support update of infrastructure (motorway) geometry
and related attributes
- representation shall support update of static speed limits- representation
shall support update of default segment travel times
* OBU and map database

- user shall be able to activate/deactivate service
- implementation of content is NOT focus of COOPERS, but has to be done
by map provider algorithm
- in-vehicle map needs to maintain a standardized version format regarding
the non-dynamic content
Page 155 of 159
COOPERS
integrated project
Map update process with map provider:
Break-Down
1) TCC: prepare and provide updates of non-dynamic content in a

standardized format in regular intervals according to agreements
2) Map provider: Implement updates provided by infrastructure operators
into next map database version.
3) Map provider: Provide new version of digital map database to
infrastructure operators and end users according to agreements
===========================
Map update process with end user:
1) OBU requests map update for specified version and geographical region
2) TCC checks for non-dynamic content changes and prepare update
according to request
3) Transmit update via I2V link
4) ACK reception
5) ACK successful map update
The following services may need to be operated in parallel:
Link with other

services
* service triggers:
--* service gets triggered by:
- user
Not applicable
Exeption
ID
S13
Service Area
FCD
Name of
Service
Floating Car Data
General
functions
Update TCC data base with accurate, real-time Floating Car Data to improve
traffic status knowledge and event detection.
Page 156 of 159
COOPERS
integrated project
typical event
occurence
periodic FCD (fixed sample interval)

e.g.:
* Timestamp
* Vehicle Position
* Vehicle heading
* Vehicle speed
* Vehicle ambient temperature
event-triggered FCD
e.g.:
* Collision Warning System
* Hazard warning flasher
* Break status
* ABS/ESP status
* Wiper status
data sources
CAN accessible in-vehicle sensors

(car kinematics eg wheel speeds, ABS/ASR/ESP state, rain sensor)
OBU internal sensors
(eg. Temperature or acceleration sensor)
additional sensors attached to OBU (eg. Fog light status and emergency flasher
- if not coded on CAN)
see chapter 2.4.1 Car Data in IR_3400_V1_1_0.PDF for possible In-Car data
sources and their relation to services
(e.g. ESP status, ABS status, Wiper status, Hazard Warning Flasher, Brake
status, Speed, Collision Warn. System)
Road type
applied
Complete road network
User group
TCC
Objective
Enhance TCC data base with FCD to improve event detection and area
coverage due to complementary nature of FCD (accident detection, hazardous
road conditions, end of traffic jam, fog,..).
Page 157 of 159
COOPERS
integrated project
Message
content
Periodic Messages :
1) Temporary randomised Vehicle ID (N)
2) Vehicle Type (N)
3) Vehicle Position (N)
4) Timestamp (N)
5) Vehicle Speed (N)
6) Vehicle Heading (N)
7) Vehicle ambient temperature (O)
Event triggered Messages:
1) Temporary randomised Vehicle ID (N)
2) Vehicle Type (N)
3) Vehicle Position (N)
4) Timestamp (N)
5) Type of Trigger Sensor (e.g. ESP activation) (N)
6) Value of Trigger Sensor (N)
7) Type and Value of other accessable in-vehicle sensors specified in "Data
sources" (O)
Condition for
starting the
service
powering on the OBU.
Condition for
terminating
the service
power off.
Key
* communication from OBU ->TCC
Requirements - System latency: <1min average
- Acknowledge is required for wireless data transmission
- The data shall be buffered to reduce message overheads (ring buffers)
- Every data type must have a priority tag field.
- Data shall be transmitted immediately, when a terminal free of charge is
available (DSRC).
- If buffer is full, try transmission via dial-up connection (GPRS) where the priority
flag is set. Data without priority flag shall be overwritten.
- Buffers shall be split in event-based and periodic messages.
- Buffer sizes shall be configurable, with a starting value of 100 elements each.
- Logfiles shall be generated, which allows debugging (e.g. Transmission log with
acknowledge of the used transport medium)
- Programming must be done in a modular way to enable later implementation of
sensors and services.
- Each data set must contain a unique vehicle ID, which is newly generated for
each session to ensure privacy issues.
- Vehicle equipped with CAN-Bus, Signal formats must be known.
- A vehicle classification (truck, car, bus,...) must be included in the vehicle ID or
Page 158 of 159
COOPERS
integrated project
can be transmitted in a separate field. (class ID from 0 .. 99)
Break-Down
The gathering of floating car data shall be done permanent and cyclically.
Step 1: read data from in-car network
Step 2: read data from OBU internal and external sensors.
Step 3: combine/associate/calculate the various data to extract the wanted
information.
Step 3: do a plausibility check at OBU
Step 4: transmit the data according to the Key Requirements
Step 5: ACK transmission at TCC or RSU
Step 6: Collect data at TCC or RSU and fuse with Infrastructure sensors or other
FCD sets
Step 7: If extacted information (traffic flow, road surface...) is verified, update
TCC data base
Link with
other
services

* service triggers:
- only indirect triggerend trough improved TCC data base. This service is a data
input for S1(a,b,c), S4b, S5, S6, S9, S10
- Timer (periodic messages)
- Events (ESP, ABS, Wiper, as specified in "data sources" and "typical event
occurency"
Exeption
Data transmission is rejected, if plausibility checks fail.

(e.g. invalid speed information: not fitting to GPS position change within time)
Page 159 of 159

COOPERS Architec PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

COOPERS Architec PDF

Uploaded by

Copyright:

Available Formats

COOPERS

Co-operative Networks for Intelligent Road Safety

short Participant name

AustriaTech Gesellschaft des Bundes fr technologiepolitische Manahmen

Reference Architecture 2.0

Reference Architecture 2.0

Reference Architecture 2.0

Reference Architecture 2.0

List of Abbreviations and Acronyms

American association of state and highway transportation officials

Reference Architecture 2.0

media oriented systems transport

Reference Architecture 2.0

List of Abbreviations and Acronyms

Scope of the document

Reasons for ITS architecture creation

European ITS Framework architecture history, tools and contents

Other recent Cooperative Systems activities

Vehicle Infrastructure Integration (VII United States of America)

Forerunning projects in the European Union

WILLWARN (a PReVENT Project)

Running projects in the European Union

CVIS (co-operative vehicle-infrastructure system)

COMeSafety (communication for electronical safety)

Co-oporation between projects

Different FRAME viewpoints

Function groups and their sub-functions within FRAME

Definition of COOPERS services

Additional requirements of the COOPERS services

Floating Car Data (S13)

Note on COOPERS services

Reference Architecture 2.0

Defined user needs

User Needs for COOPERS

New User Needs for COOPERS

Functions for COOPERS system

New Functions for COOPERS system

Relations between COOPERS services and FRAME viewpoints

System Architecture physical viewpoint

Definitions of physical elements

Overview of the P23 COOPERS

System context diagram of the P23 COOPERS

Sub-systems of the COOPERS system

P23.1 COOPERS Central Sub-system

P23.2 COOPERS Roadside Unit

P23.3 COOPERS On-board Unit

P23.4 COOPERS-compliant Portable Device

Modules of P23 COOPERS

Modules for P23.1 COOPERS Central Sub-system

Modules for P23.2 COOPERS Roadside Unit

Modules for P23.3 COOPERS On-board Unit

Modules for P23.4 COOPERS-compliant Portable Device

Physical data flows

Adoption of the Reference Architecture to the Demonstration Sites

UML architecture (SWP3200)

Communication viewpoint link analysis (SWP3300)

In-car networks Floating Car data (SWP3400)

Definition of new functions and requirements (SWP3800)

Reference Architecture 2.0

Annex 2: service description tables

Reference Architecture 2.0

Reference Architecture 2.0

Reference Architecture 2.0