pdf - Coopers

COOPERS 

Co-operative Networks for Intelligent Road Safety 

WP3000 

Report on ITS framework reference Architecture 

D13-B-IR3100-2 

V 3.0 

Status Date 

Draft 15-02-2008 

Reviewed 07-03-2008 

Approved 12-06-2008 

Release Function Approval 

Susanne Fuchs Name Prof.Thomas Richter 

Hi Tech Organisation TU Berlin 

+43 1 7182530 Phone +49 30 314 72 604 

Fax 

sf@hitec.at E-Mail 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 

name 

Participant name 

Nationality 

1 ATE AustriaTech – Gesellschaft des Bundes für technologiepolitische Maßnahmen Austria 

2 HIT Vereinigung High Tech Marketing Austria 

3 SEI ARC Seibersdorf Research GmbH Austria 

4 ARS ARS Traffic and Transport Technology B.V. Netherlands 

5 SWA Swarco Europe GmbH Austria 

6 EYF Ernst and Young Financial – Business Advisors S.p.A. Italy 

7 ASF ASFINAG - Autobahnen- und Schnellstraßen-Finanzierungs- Aktiengesellschaft Austria 

8 FAV Forschungs- und Anwendungsverbund Verkehrssystemtechnik Berlin Germany 

9 ORF Österreichischer Rundfunk Austria 

10 - Left intentionally blank 

11 TUW Technische Universität Wien Austria 

12 ASC Ascom Switzerland Ltd Switzerland 

13 TRG University of Southampton United Kingdom 

14 IPW IPW Ingenieurgesellschaft Prof. Werner mbH Germany 

15 OBB Oberste Baubehörde im Bayerischen Staatsministerium des Innern Germany 

16 DOR Dornier Consulting GmbH Germany 

17 GEW GEWI Hard- und Software Entwicklungsgesellschaft mbH Germany 

18 BRE Autostrada del Brennero Italy 

19 VEG VEGA Informations-Technologien GmbH Germany 

20 - Left intentionally blank 

21 TUL Politechnika Lodzka Poland 

22 LUC Lucent Technologies Network Systems GmbH Germany 

23 TRA TRANSVER GmbH Germany 

24 FHG Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung E.V. Germany 

25 EFM EFKON mobility GmbH Germany 

26 EFK EFKON AG Austria 

27 VTI Statens väg- och transportforsknings-institutet Sweden 

28 KTH Kungliga Tekniska Högskolan Sweden 

29 NET TeamNet International S.A. Romania 

30 STH S&T Hermes Plus Slovenia 

31 INO INESC Inovação – Instituto de Novas Tecnologias Portugal 

32 APP LGAI Technological Center S.A. Spain 

33 ICI National Institute for Research Development in Informatics Romania 

34 TUC Technical University of Crete Greece 

35 KYB Kybertec, s.r.o. Czech Republic 

36 JAS JAST Sàrl Switzerland 

37 - Left intentionally blank Belgium 

38 BMW Bayerische Motoren Werke Aktiengesellschaft Germany 

39 NAV NAVTEQ B.V. Netherlands 

Reference Architecture 2.0 

Page 2 of 159

COOPERS 


Document History: 

Version Date Released by Description 

0.1 20.07.2006 Katrin Hirschmann Document Drafted 

0.2 30.08.2006 Alexander Froetscher Revision of document 

0.2 15.09.2006 Katrin Hirschmann functions added and revised 

0.3 13.11.2006 Alexander Froetscher revision of document 

0.4 22.11.2006 Katrin Hirschmann architecture relevant 

0.5 24.11.2006 Katrin Hirschmann revision of document 

0.6 18.12.2006 Katrin Hirschmann revision of document 

0.7 25.01.2007 Katrin Hirschmann finalization with first service set 

0.8 01.02.2007 Katrin Hirschmann finalization with COOPERS services 

1.0 09.02.2007 Katrin Hirschmann final version, status released 

1.1 14.09.2007 Katrin Hirschmann revision of the final version 

1.2 14.12.2007 Thomas Scheider service description tables (version from 

6.12.2007) 

1.3 31.01.2008 Alexander Froetscher Revision of chapter 2.3, 2.4, 

2.0 15.02.2008 Alexander Froetscher Revision of chapter 3, several updated 

2.0 15.02.2008 Thomas Scheider Added chapter 4.2 and 9 

2.0 15.02.2008 Alexander Froetscher Cooperation status added, status 

released 

2.1 07.03.2008 Alexander Froetscher, 

Thomas Scheider 

3.0 12.06.2008 Accepted 

Revision according to peer review 

comments, status approved 


Page 3 of 159

COOPERS 


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 


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 


List of Abbreviations and Acronyms 

AASHTO 

American association of state and highway transportation officials 

ACC 

adaptive cruise control 

ADAS 

advanced driver assistance systems 

AIDE 

adaptive integrated driver-vehicle interface 

API 

application programming interface 

ASRB 

automotive safety restraints bus 

CALM 

communications, air-interface, long and medium range (for ITS) 

COOPERS 

co-operative networks for intelligent road safety 

CVIS 

co-operative vehicle-infrastructure system 

D 

deliverables 

DAB 

digital audio broadcast 

DATEX 

data exchange 

DSRC 

dedicated short range communication 

DOT 

departments of transportation 

EASIS 

electronic architecture and system engineering for integrated safety 

ECU 

electronic systems control unit 

EFC 

electronic fee collection 

FCD 

floating car data 

FRAME 

framework architecture made for Europe 

G 

generation 

GPRS 

general packet radio service 

GPS 

global positioning unit 

GSM 

global system for mobile communications 

GST 

global system for telematics 

HGV 

heavy goods vehicle 

HL 

high level 

HMI 

human machine interface 

HOV 

high occupancy vehicle 

I 

infrastructure 

I/O 

input/output 

I2V 

infrastructure to vehicle 

ID 

identification 

IEEE 

institute of electrical and electronics engineers, Inc. 

IP 

internet protocol 

ISA 

intelligent speed adaptation system 

ISO/IEC international organisation for standardisation/international electrotechnical 

commission 

ITS 

ITU-T 

IVI 

J2EE 

J2SE 

KAREN 

LIN 

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 


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 


Table of Contents2.1 1 

Approved 1 

Executive Summary 4 

List of Abbreviations and Acronyms 6 

Table of Contents 8 

2 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 

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

3.3 Running projects in the European Union 25 

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 

4 Architectural Overview 32 

4.1 FRAME guideline 32 

4.1.1 Different FRAME viewpoints 33 

4.1.2 Function groups and their sub-functions within FRAME 34 

5 Definition of COOPERS services 36 

5.1 COOPERS services 36 

5.2 Additional requirements of the COOPERS services 36 

5.2.1 Floating Car Data (S13) 36 

5.2.2 Service Acknowledgement 37 

5.3 Note on COOPERS services 37 


Page 8 of 159

COOPERS 


6 Defined user needs 38 

6.1 User Needs for COOPERS 39 

6.2 New User Needs for COOPERS 42 

7 Functional viewpoint 43 

7.1 Functions for COOPERS system 43 

7.2 New Functions for COOPERS system 45 

8 Relations between COOPERS services and FRAME viewpoints 46 

9 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 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 

10 Adoption of the Reference Architecture to the Demonstration Sites 81 

10.1 Demonstration Site 1 81 




11 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 

12 References 85 


Page 9 of 159

COOPERS 


Annex 1: Summary of the functions 87 

Annex 2: service description tables 98 


Page 10 of 159

COOPERS 


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 


Figure 23: Demonstration Sites planned within COOPERS ............................................................... 81 


Page 12 of 159

COOPERS 


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 


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 


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, FRAME- 

S) 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 


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 


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 


• 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 Europe’s 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 


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 vehicle’s 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 


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 


• 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)n’t 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 


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 


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 


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 ECU’s 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 OEM´s 

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 


• 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 


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 


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 


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 


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 


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 COMeSafety´s 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 


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 


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 


• 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 


More information regarding the development process of the COOPERS high-level architecture in the 

project’s 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 


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 vehicle’s 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 


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 


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 

a 3 rd 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 driver’s anonymity is needed, 

and for this reason the COOPERS system/services operate with ID’s from registered vehicles. The 

COOPERS system has access to the ID’s and will transmit it to the responding provider. 


Page 37 of 159

COOPERS 


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 


6.1 User Needs for COOPERS 


Page 39 of 159

COOPERS 



Page 40 of 159

COOPERS 



Page 41 of 159

COOPERS 


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 


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 


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 


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 


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 


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 


SubSystem.name location Module.name elementID corresponding user needs 

COOPERS Center Central Provide Environmental Conditions Assessment 3.4.4 7.1.2.5 

3.4.5 

3.4.6 7.1.0.4 

Provide Incident Management 13.3.2.3 

13.3.2.4 13.1.2.1, 6.2.2.11, 7.2.2.1, 7.2.2.3, 7.2.3.1 

3.2.2 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 

3.2.5 

D3.4 

Provide Safety Support for Maintenance Management 3.5.1 2.2.0.1, 2.2.0.3, 2.2.0.5 

3.5.2 2.2.0.6 

3.5.5 

3.5.6 2.2.0.6 

D3.6 

Provide Support for Emergency Management 2.1.2.1 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 

2.1.2.4 7.2.1.2 

2.1.5 7.2.1.2 

D2.1 

Provide Support for Road Charging 1.6.1 

13.1.3.5 

D1.5 

Provide Support for Traffic Violation Reporting 13.3.1.2.9 

13.7.3.1 13.1.5.1 

13.7.3.3 13.1.5.1 

D13.3 

D13.7 

Provide Traffic Management 13.3.1.2.4 13.1.2.1, 6.1.2.6, 

13.3.1.2.5.6 13.1.6.1, 7.1.0.11, 7.1.10.1, 7.1.4.3, 7.1.5.2 

13.3.1.2.5.8 

3.1.2.3 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, 

3.1.2.5.1 7.1.5.5, 

3.1.2.5.2 7.1.0.11 

3.1.2.5.4 7.1.0.11, 7.1.7.1, 7.1.7.2, 7.1.7.3, 7.1.7.5, 7.1.7.6, 

3.1.2.5.7 7.1.3.1, 7.1.3.2, 7.1.3.3, 7.1.3.5, 

3.1.2.5.9 7.1.7.4, 7.1.8.1, 

D3.2 

D3.8 

Table 5: COOPERS service system – central sub-system, modules, functions 


Page 48 of 159

COOPERS 



COOPERS On-board Unit Vehicle Perform Mayday Call 5.11.3 

Provide charging information 13.1.3.8 

Provide On-Board Communication Interfaces 13.5.14.4 

5.12.2 8.2.5.1 

5.12.3 7.1.7.6, 8.2.2.2, 8.5.5.1 

5.12.4 8.5.5.1 

5.12.5 

6.5.3.2 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, 

Provide Speed Information and FCD 5.13.2 6.1.2.5, 6.2.2.10, 

5.13.3 8.2.5.1, 8.2.5.2, 8.2.5.4 

5.13.4 8.2.5.2 

5.13.5 8.2.5.4 

Provide Vehicle Position 5.13.1 

Table 6: COOPERS service system – on-board unit sub-system, modules, functions 


COOPERS Roadside Unit Roadside Detect Incidents 2.1.1 

3.2.1 7.2.0.1, 7.2.0.6, 7.2.5.1 

Identify On-Board Unit 1.3.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, 

13.1.3.2 

Monitor Environment 3.4.1 7.1.1.6 

3.5.4 

Provide Roadside Communications 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.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 



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, 

COOPERS-compliant portable device Personal Device Provide Infrastructure-supported Navigation 6.1 6.4.2.2, 

6.3.1 

6.3.3 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.3.6 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.3.7 6.1.2.1, 6.2.0.6, 

6.5.1 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.5.2 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.5.3.1 6.2.3.5, 6.4.0.1, 6.4.1.3, 6.4.1.4, 6.4.1.6, 7.3.0.1 

D6.1 

D6.2 

D6.3 

Table 8: COOPERS service system – personal device sub-systems, modules, functions 


Page 50 of 159

COOPERS 


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 


• 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 


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 


Figure 2: System Context Diagram 


Page 54 of 159

COOPERS 


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. Today’s 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 system’s “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 


 

& 

# !. 

#.&. 

-#&. 

&& 

 

! 

 

&( 

! 

$ 

( 

(!& 

( 

! 

&!$ 

$& 

#./ 

#. 

!& 

#..! 

( 

! 

#&. 

-.&$$.. 

..&$.$. 

 

!! 

&&!$$& 

&!$$& 

#&. 

,! 

& 

 

-!#.&. 

$ 

&!$ 

(!& 

#. 

 

..&$.$. 

. !& 

#. 

 

-!#/. 

. 

 

, 

& 

 

#&!$.. 

. 

#&!$.. 

. 

-#&. 

 

) 

 

0 

 

 

#. 

.! 

... 

..! 

-#. 

+ 

$& 

# . 

.. 

 

#. 

 

#. 

! 

 

$& 

-#. 

&. 

-#&. 

.&& 

-#&. 

. 

&-. . 

&. 

 

% 

! 

#&.. 

-##". 

-#. . 

&.&& 

-##". 

.&& 

&.#"..!. 

#&. 

-#. 

& 

 

& 

&. . 

.. 

( 

& 

#. 

) 

&.#".. 

&-.#". ." 

#&. 

 

 

& 

 

#. 

 

&.!.. 

-#. 

-##" 

.. 

#.. 

. 

 

(!& 

#. 

.! 

#. 

!$./ 

#. 

 

(!& 

#. 

-"#. 

 

* 

-"##". 

. 

#. 

 

#. 

&!&." 

#.&!&. 

#&. 

% 

#. 

#. 

. 

 

#!. 

. 

#..&!&. 

-&.#"..!. 

#..&!&. 

Figure 3: P23.1 COOPERS Central Sub-system diagram 


Page 56 of 159

COOPERS 


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 


Figure 4: P23.2 COOPERS Roadside Unit diagram 


Page 58 of 159

COOPERS 


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. 

# 

# 

,! 

& 

 

1 

 

-.!.. 

& 

 

-!# 

#. 

-&#.. 

&.&. 

#. 

.! 

..! 

#. 

% 

...&.&. 

!! 

& 

-. 

-&#!!. 

#. 

.! 

&-.2 

&-. .&. 

'&( 

 

-&#. 

&! 

#* 

&& 

&-..&. 

#..&$$ 

&% 

$& 

%$& 

#.&!&. 

-.. 

....!. 

& 

#!. 

 

-.../ 

#. 

 

#&$$. 

. 

&($$ 

Figure 5: P23.3 COOPERS On-board Unit diagram 


Page 59 of 159

COOPERS 


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 


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 


• 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 


##".. 

&!&.! 

 

$& 

* 

 

& 

 

) 

 

-## 

".. 

-"## 

".. 

-##". 

.&& 

-##".. 

##".. 

##".. 

 

(!& 

##".. 

&!&.! 

-&.#"..!. 

&.#".. 

&-.#"...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 


Figure 10: P23.1 Central Sub-system – P23.1.4 Provide Safety Support for Maintenance 

Management module 


Page 64 of 159

COOPERS 


&!$ 

$& 

# 

!".!. 

# 

&!$.!. 

# 

&!$..& 

$ 

&!$(!& 

..&$.$. 

-.&$$.. 

&-.. 

-!#. 

-!#&. 

,! 

& 

 

#&!$... 

#&!$... 

-&... 

-&.. 

..&$.$... 

!& 

-!# 

/.. 

, 

& 

 

 

$& 

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 


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 


• 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 


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 


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 

vehicle’s position needed for xFCD packet generation and provision of the current speed 

limit. 


Page 69 of 159

COOPERS 


• 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 


'&( 

 

-&#.. 

&.&. 

-.!.. 

-&.#". 

!.. 

& 

 

...&.&. 

&-.#". 

.! 

..&.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 


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 



Page 73 of 159

COOPERS 


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 


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 


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 


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 


Physical Data Flows 

Consistuents 

Name Physical Data Flows Functional Data Flows 

coopers-accident_detected 

padas_accident_detected 

coopers-central_information 

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-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-position_for_mayday 

coopers-position_for_processing 

coopers-ptja_maintenance_data 

coopers-regulations_and_charge_info 

coopers-route_and_vehicle_status 

coopers-traffic_data_for_incident_detection 

coopers-traffic_data_for_incidents 

coopers-traffic_management_feedback 

coopers-traffic_management_info 

coopers-icing_incident_data 

coopers-traffic_management_feedback 

coopers-weather_condition_data 

coopers-driver_instructions 

coopers-incident_warnings 

coopers-static_traffic_regulations 

coopers-vsl 

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 

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 

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 

Table 9: Physical data flows – functional data flows within the COOPERS system (part 1) 


Page 78 of 159

COOPERS 


Physical Data Flows 

Consistuents 


coopers-traffic_status 

coopers-environmental_info_PRT 

coopers-incident_info_PRT 

mt.padas_inter-urban_traffic_status 

pepf.padas_vehicle_ID_request 

coopers-vehicle_messages 

padas.pepf_vehicle_position 

padas.psef_mayday_call_data 

coopers-vsl 

mt.padas_inter-urban_speed_settings 

coopers-weather_condition_data 

mt_weather_condition_data_inputs 







fesp.g-additional_map_data 

fesp.g-identification_response 

fesp.g-map_update 

fesp.g-data 

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 


From / To Traveller 

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 

From Emergency Systems 

fes-emergency_progress_report 

fes-emergency_services_information 

From HMI 

fv.hmi-initiate_mayday 

From Maintenance Organisation 

fmo-update_activity_status 

From Operator 






From Road Related System 

frrs-emergency_or_incident_notification 

frrs-incident_data 

frrs-traffic_data 

From Traffic 

ftrfc-inter-urban_raw_traffic_flow_data 

ftrfc-presence_indication 

From Vehicle Systems 

fv.vs-input_data 



frp-guidance_data 

frp-guidance_data 

frp-wearing_state 

frp-long_term_wearing_state 

frp-short_term_wearing_state 

frp-short_term_wearing_state_2 

frrs-data_and_management_updates 

ffrs-inter-urban_data_updates 

frrs-inter-urban_traffic_management_strategies 





frrs-traffic_data 

frrs-inter-urban_data_updates 

frrs-inter-urban_traffic_management_strategies 









fws-maintenance_conditions 

fws-long_term_maintenance_conditions 

fws-short_term_maintenance_conditions 

fws-short_term_maintenance_conditions_2 



Page 79 of 159

COOPERS 



fws-weather_conditions 

fws-ice_formation_conditions 

fws-weather_data 

fws-weather_data_for_incidents 

fws-weather_data_for_incidents 

td-mayday_acknowledgement 

td-mayday_acknowledgement 

td-output_actuation 

td-inter-urban_traffic_commands 

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 

tes-global_progress_report 

To External Service Provider 






To Maintenance Organisation 

tmo-long_term_activities 

tmo-short_term_activities 

To Operator 

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 

To Road Related System 

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-traffic_data 

trrs-inter-urban_data_updates 

trrs-inter-urban_traffic_management_strategies 

tv.hmi-current_speed_limit_from_ISA 

tv.hmi-current_speed_limit_from_ISA 

tv.hmi-traffic_messages 

tv.hmi-charging_info 

tv.hmi-traffic_regulations 

tv.hmi-traffic_status_information 



Page 80 of 159

COOPERS 


10 Adoption of the Reference Architecture to the 

Demonstration Sites 

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 


 

 

 

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 Link- 

Service. 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 


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 


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 


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 


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 


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 


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 


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 


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 


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 


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 Traveller’s 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 


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 


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 

Traveller’s 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 


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 


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 


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 


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 

Service Area 

Name of Service 

General functions 

typical event 

occurence 

S1a 

Incident management 

Accident warning 

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. 

* Location Type: spot, section 

* Lateral: lane(s), one direction 

(carriageway) 

* Movement: stationary 


Page 98 of 159

COOPERS 


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 (Heerstraße) 

User 

User 

group 

Drivers on motorways 

Other traffic information providers 

Objective To make drivers aware of the 

situation and prevent following 

accidents and congestion 

To warn other road users of the 

accident 


Page 99 of 159

COOPERS 


Message content 

Condition for 

starting the 

service 

Condition for 

terminating the 

service 

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) 

As soon as reported by an established, reliable source. 

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) 

* 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 


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 


ID 

Service Area 



typical event 

occurence 

S1b 


Incident warning 

To warn drivers of obstacles ahead with in-vehicle, dynamic information. 


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


data sources 






* emergency call box network 




* 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 


- other phone calls 

Road type applied 

Motorways (including tunnels and bridges) 

User 

User group Drivers on motorways Other traffic information providers 

Objective 

Providing 

Information/Instruction 

To make drivers aware of the 



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 incident (O) 

7) Recommendations/instructions 

[Speed, Lane] (O) 

8) time until incident scene cleared 

(O) 

9) recommended diversion route 

(O) 

10) message time-to-live (N) 

11) expected delay (O) 


incident. 






5) Lane(s) of the road sections 

affected (O) 

6) Severity of incident (O) 



8) time until incident scene cleared 

(O) 

9) recommended diversion route 

(O) 



Condition for starting 

the service 

Condition for 

terminating the service 

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. 

* Police or fire dept. call 


* Automatic detection of incident scene cleared through monitoring of 

the impact on traffic flow by TCC (verified) 



Page 103 of 159

COOPERS 


Key Requirements 

* TCC -> OBU- System latency: 1min average, 5min maximum- warning 

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. 



- 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 


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) 



services 






* service gets triggered by:- - 

Exeption 


Page 105 of 159

COOPERS 


ID 

Service Area 



typical event 

occurence 

S1c 


wrong-way driver warning 

To warn drivers of oncoming wrong-way drivers with in-vehicle, dynamic 

information. 

* Location Type: section, area 

* Lateral: one direction (carriageway), complete road 

* Movement: downstream/upstream (speed) 

data sources 









* police or highway authorities 



-> instructions 

-> wrong-way driver left motorway 

* passing vehicle(s) 

- phone calls 

* other external sources 

- TISP 

Road type applied 


User 


Objective 

To make drivers aware of the 




wrong-way driver. 


Page 106 of 159

COOPERS 


Providing 

Information/Instruction 



















Condition for starting 

the service 

Condition for 

terminating the service 

Key Requirements 

As soon as an wrong-way driver is reported 

* Police or fire dept. call 


* Automatic detection of incident scene cleared through monitoring of 

the impact on traffic flow by TCC (verified) 


* 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 


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. 



services 







- - 

Exception 


Page 108 of 159

COOPERS 


ID 

Service Area 

Service Name 


typical event 

occurence 

S2 

Weather condition 

Weather condition warning 

Provide in-vehicle, dynamic information to warn drivers of hazardous 

conditions ahead caused by weather conditions 

* Location Type: spot, section, area 



data sources 





* 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,

COOPERS 


- 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 

content 


2) detailed cause of trigger (e.g. 

weather condition type) 


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) 

2) detailed cause of trigger (e.g. 

weather condition type) 



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 

Condition for 

starting the 

service 

Condition for 


service 

* 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 


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 





* weather warning types include: 

- rain 

- snow 

- ice 

- hail 

- wind 

- fog 

- thunder storm 


Page 111 of 159

COOPERS 


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 


services 





- Roadwork information (in case of winter maintenance) 


- - 

Exeption 


Page 112 of 159

COOPERS 


ID 

Service Area 

Name of 

Service 

General 

functions 

typical event 

occurence 

S3 

Roadwork information 

Roadwork information 

To warn drivers of roadworks ahead with in-vehicle, dynamic information. 



* Movement: stationary, downstrem/upstream (speed) 

data sources 





1) short-term / long-term scheduled roadworks: 

- road maintenance plan 

- scheduled events (daily, weekly, monthly) 

- road maintenance centre phone call 

2) roadwork monitoring: 





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 



Objective 

To make drivers aware of the situation 

and prevent following accidents and 

congestion caused by bottleneck road 


roadwork 

specific interface 

Message 

content 




4) Location, direction, length and lane 

of the road sections affected (N) 

5) Recommendations/instructions [link 

to VSL, Lane management services] 

(O) 

6) time when roadwork installation 

starts (O) 

7) time until roadwork scene cleared 

(O) 

8) recommended diversion route (O) 






4) Location, direction, length and lane 

of the road sections affected (N) 

5) Recommendations/instructions [link 

to VSL, Lane management services] 

(O) 

6) time until roadwork scene cleared 

(O) 

7) recommended diversion route (O) 



Condition for 

starting the 

service 

Condition for 

terminating 

the service 

The warning strategy starts according to the roadwork trip start or notification 

from the maintenance centre. 

* 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 


Key 

Requirements 

* TCC -> OBU 

- 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 





* 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 


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 





- Lane banning- Auxiliary lane 

- recommended next link 

*service gets triggered by: 

- Accident warning 

- Incident warning 

Exeption 


Page 116 of 159

COOPERS 


ID 

Service Area 

Service Name 


typical event 

occurence 

S4a 

Lane utilization 

Lane banning 

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. 

* Location Type: section 



data sources 









* 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 


- incident warning 

* external sources 

- police 

User 


Highly occupied vehicles (HOV) 

Heavy goods vehicles (HGV) 

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 

content 




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 

Condition for 


service 

1) scheduled plan of lane banning operation 

2) Operator command; triggered by other services 

1) scheduled plan of lane banning operation 

2) Operator command, when reason for lane ban does not apply anymore. 

Validation via CCTV or other reliable source 


Page 118 of 159

COOPERS 


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 



services 



-- 

* service gets triggered by 



- wrong-way driver warning 

- auxiliary lane 




Exeption 

locally controlled VMS 


Page 120 of 159

COOPERS 


ID 

Service Area 

Service Name 

General 

functions 

data collection 

method 

S4b 


Lane keeping 

To provide in-vehicle advice for drivers not to overtake to stabilize traffic 

flow. 




data sources 





- traffic congestion warning (this service monitors & predicts traffic flow. 

S4b warning can be triggered before actual traffic congestion warning is 

distributed) 







- 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 


Message content 1) Service (N) 



3) Location, direction, length of the lane keeping advice (N) 

4) Vehicle type (O) 



Condition for 

starting the 

service 

Condition for 


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 

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 


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) 





services 


* Service is triggered by: 


* Service triggers: 

- - 

Exeption 


Page 123 of 159

COOPERS 


ID 

Service Area 

Service Name 

General 

functions 

typical event 

occurence 

S4c 


Auxiliary Lane Accessibility 

Provide in-vehicle information to inform drivers on a specific motorway section 

about the availability of auxiliary lanes for driving. 


* Lateral: lane(s) 


data sources 









* TCC 

- static lane database 

- scheduled/planned auxiliary lane accessibility 



- location 


- police 

- operator cars 

Road type 

applied 

User group 

Objective 



Highly occupied vehicles (HOV) 

Heavy goods vehicles (HGV) 

To increase driving safety by making drivers aware of the situation and be 


Page 124 of 159

COOPERS 


prepared for the availablility of the auxiliary lane. 

Message 

content 




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 

Condition for 

terminating 

the service 

Key 

Requirements 

Operator command (scheduled plan of auxiliary lane operation) 

Operator command (scheduled plan of auxiliary lane operation) 


- 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 


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 



- lane banning 

* Service gets triggered by: 



Exeption 

locally controlled VMS 


Page 126 of 159

COOPERS 


ID 

Service Area 

Service Name 

General 

functions 

typical event 

occurence 

S5 

Traffic management 

In-Vehicle Variable Speed Limit Information 

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. 




data sources 









* infrastructure equipment 

- VMS (driver output actuation, status feedback to TCC) 

- section control 

* TCC 

- speed profile 

- static speed limit database 




- location 



- congestion warning 




Page 127 of 159

COOPERS 




- 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) 


3) Location, direction, lane and length of the referred speed limit zone (N) 

4) legal speed limit (N) and type advised/mandatory (N) 




Condition for 

starting the 

service 

Condition for 


service 

Service is continuously provided for motorways. 

After entering the motorway (DAB, GPRS) or the first connection setup (DSRC, 

IR) the legal speed limit has to be displayed. 

Leaving motorway. 

Time/distance to live exceeded (indication of system error) 


Page 128 of 159

COOPERS 


Key 

Requirements 

* TCC: 

- every segment has at least 1 legal speed limit 





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 



services 



- ISA with infrastructure link 

* Service gets triggered by: 






- wrong-way driver warning 

Exeption 

Locally controlled VMS or roadwork trailer could trigger VSL service. 


Page 130 of 159

COOPERS 


ID 

Service Area 

Name of 

Service 

General 

functions 

typical event 

occurence 

S6 



Provide in-vehicle, dynamic information to warn drivers of congested traffic 

ahead 



* Movement: stationary, downstream/upstream (speed) 

data sources 









* 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 



Objective 

Message 

content 

To increase driving safety by making 

drivers aware of the congested traffic 

and be prepared for the condition. 




4) Severity [classification, 

estimated/observed queue length, 

delay time, average speed] 

5) location of congestion tail end, 

estimated propagation speed 

To provide other road users with 

traffic congestion information 





sections affected (N) 

5) Severity [classification, 

estimated/observed queue length, 

delay time, average speed] 


[link to VSL, Lane management 

services, recommended next link] (O) 

7) Estimated time to congestion 

fading (O) 

6) location of congestion tail end, 

estimated propagation speed 


[link to VSL, Lane management 

services, recommended next link] (O) 


8) Estimated time to congestion 

fading (O) 


Condition for 

starting the 

service 

Condition for 

terminating 

the service 

As soon as an congestion is reported by a reliable (either established 

source, or verified FCD messages) source. 

*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 


Key 

Requirements 

* TCC -> OBU 

- 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 





* message display requirementslocality: 

longitudinal: 30m, 






Page 133 of 159

COOPERS 


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 




- Keep in lane 


- Auxiliary lane 

- Recommended next link 

- Estimated journey time 



Page 134 of 159

COOPERS 





Exeption 


Page 135 of 159

COOPERS 


ID 

Service Area 

S7 

Speed Limit Information 

Service Name ISA with infrastructure links 

General 

functions 

typical event 

occurence 

Inform drivers of the current recommended speed limit and provide support 

to match their automatic speed control to prevailing traffic, weather and road 

conditions. 




data sources 


* recommended speed limit profile 


* Variable speed limit profile 

* static speed limit database 





* infrastructure equipment 

- VMS (driver output actuation, status feedback to TCC) 

- section control 

* TCC 




- location 

* vehicle sensor data ("continous") 

- current speed 


Page 136 of 159

COOPERS 




- congestion warning 





- police 

Road type 

applied 

User group 

Objective 

Message 

content 



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. 



3) Location, direction, lane and length of the referred speed limit zone (N) 

4) recommended speed limit (N) 




Condition for 

starting the 

service 

Condition for 

terminating 

the service 

Service is continuously provided for motorways. 

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 


Key 

Requirements 

* TCC: 

- every segment has at least 1 legal speed limit 


- 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 


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 


ID 

Service Area 

Service Name 

General 

functions 

Road type 

applied 

User group 

Objective 

Message/display 

content 

S8 

Service continuity 

International service continuity 

Exchange static and dynamic network information based on standard 

protocols between neighbouring control centres (internationally or 

regionally) to ensure continuity of services for travellers. 

Motorways 

Traffic information centres or control centres 

Data exchange for providing continued service 

I2I 

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 

Condition for 


service 

Starts as defined in the interchange agreements between the road 

operators or traffic information providers. 

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 


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 


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. 


COOPERS 

services 

service triggers: 

- S1-S7 

service is triggered by: 

- S1-S7 


Page 142 of 159

COOPERS 


ID 

Service Area 

S9 

Road Charging 

Name of Service Road Charging to influence on demand 

General 

functions 

typical event 

occurency 

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. 


* 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 


Message 

content 

Condition for 

starting the 

service 

Condition for 


service 

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) 

After entering the motorway (DAB, 

GPRS) or the first connection setup 

(DSRC, IR) the service can be 

provided. 


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 (0- 

2h) 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 


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 


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. 


services 

-- 

Exeption 


Page 146 of 159

COOPERS 


ID 

Service Area 

S10 

Estimated Journey Time 

Name of Service Estimated Journey Time 

General 

functions 

typical event 

occurence 

data sources 

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

motorway segments of the planned route to enable dynamic navigation. 

1. route based 

2. link based 


* 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 Drivers on motorways Other traffic information providers 

Objective 

Message 

Condition for 

starting the 

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. 

V2I: 

1) ID 

2) timestamp 

3) vehicle type 

4) route information (e.g. array of 

segments) 

I2V: 

1) target ID 

2) service identifier 

3) estimated journey time deviations 

for requested segments (estimations 

based on predicted journey progress) 

Estimated Journey time service is 

activated by user (menu option). 

To provide road users with journey 

time estimates 

1) Identification of the road sections for 

which journey times are provided (N) 

2) Identification of date and time period 

for which estimated journey times are 

provided 

3) Journey time predictions, time 

series (short-term, mid-term, longterm) 

Estimated Journey time is always on. 


Page 147 of 159

COOPERS 


service 

Condition for 


service 

Key 

Requirements 

Deactivation by user. 

* 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 





- 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 



Break- 

Down 

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! 


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 


ID 

Service Area 


S11 

Recommended next link 

Recommended next link 

General functions Provide in-vehicle, dynamicm, public recommendations on motorway links 

selected by the road operator. 

typical event 

occurence 

data sources 

1. route based 

2. link based 


* 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 

User group 

Objective 

motorway 


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 


Message content 




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 

Condition for 


service 

Recommended next link is always on if dynamic data is available. 

Recommended next link is always on if dynamic data is available. 


Page 151 of 159

COOPERS 


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 




- 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 


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. 


services 




- Estimated Journey time 





ID 

Service Area 


S12 

Map update 

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 

data sources 

1. map updates on planned routes 

* 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 


User Drivers on motorways Digital map providers 

Providing 

Information/Instru 

ction 

To increase road safety and efficiency by 

ensuring that drivers always have the 

latest static road network infromation 

available. 

V2I: 


2) ID 

3) standardised version number of nondynamic 

content 

4) requested area restriction (route, 

specific motorway, segment, area) 

I2V: 


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 

To increase road safety and 

efficiency by ensuring that 

provided maps have up-to-date 

non-dynamic information 

implemented. 

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 

Condition for 

starting the 

service 

Map updates are provided on request of 

the OBU 

Based on bilateral agreement 

between infrastructure operator 

and map provider. 

Condition for 


service 

The service is terminated if the map update request is completed or 

terminated. 


Page 154 of 159

COOPERS 


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 


Break-Down 

Map update process with map provider: 

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 


services 

The following services may need to be operated in parallel: 


--- 


- user 

Exeption 

Not applicable 

ID 

Service Area 

Name of 

Service 

General 

functions 

S13 

FCD 

Floating Car Data 

Update TCC data base with accurate, real-time Floating Car Data to improve 

traffic status knowledge and event detection. 


Page 156 of 159

COOPERS 


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 

User group 

Objective 

Complete road network 

TCC 

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 


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 

Condition for 

terminating 

the service 

powering on the OBU. 

power off. 

Key 

Requirements 

* communication from OBU ->TCC 

- System latency:

COOPERS 


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 



- 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

pdf - Coopers

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?