sp2 – infrasens – safespot infrastructure platform final … · 2010-10-26 · task no....

Deliverable N. D2.4.2 Dissemination Level (PU) Copyright SAFESPOT

Contract N. IST-4-026963-IP

SF_D2.4.2_Final Report-Implementation&Prototypes_v4.8.doc of 102 INFRASENS

SAFESPOT INTEGRATED PROJECT - IST-4-026963-IP

DELIVERABLE

SP2 – INFRASENS – SAFESPOT Infrastructure

Platform

Deliverable No. D2.4.2

SubProject No. SP2 SubProject Title Infrastructure Platform

Workpackage No. WP2.4 Workpackage Title Implementation and Prototypes

Task No. T2.4.1-T2.4.7 Task Title

Authors (per company, if more than one company provide it together)

Angela Spence (MIZAR)

Status (F: final; D: draft; RD: revised draft): F

Version No: 4.8

File Name: SF_D2.4.2_Final Report- Implementation&Prototypes_v4.8.doc

Planned Date of submission according to TA: 30/09/2008

Issue Date: 16/04/2009

Project start date and duration 01 February 2006, 53 Months

Final Report: Implementation and prototypes for infrastructure-based components




Revision Log Version Date Reason Name and Company

V1.0 15.07.2008 First draft and Introduction A. Spence

V2.0 14.112008 Inclusion of input based on SP3 Workshop material.

T. Schendzielorz, S. Zangherati; D. Zagari MIZAR), K.Wevers (Navteq)

V3.0 16.11.2008 Overall objectives and Functional Architecture A. Spence (MIZAR)

V4.0 10.03.2009 Update of Situation Refinement Modules: TEC; Environmental Consolidator, ECAID

A. Lautier (SODIT), N. Hautière (LCPC), Stefano Marco (CSST)

V4.1 12.03.2009 Update of Physical Architecture description and Router information

S. Zangherati (CRF)

V4.2 09.03.2009 Update of Pre-Data Cooperative Fusion Module F. Ahlers (IBEO)

V4.3 26.03.2009 Update of Data Fusion Logic, Traffic Data Calculator, RSU

T. Schendzielorz, E. Bergmann (TUM), D. Zagari (MIZAR)

V4.4 04.04.2009 Editing and update of details regarding TS implementations A. Spence (MIZAR)

V4.5 16.04.2009 Details on implemented prototypes. Integration of comments from peer reviewers

S. Zangherati (CRF), A. Spence

V4.6 04.05.2009 Addiiton of seciton on Black Spot Recognition M. Mann (PTV)

V4.7 16.07.2009 Modifications requested in the Consensus Report

A. Spence, T. Lovas, S. Zangherati

V4.8 20.12.2009 Updated template, headers & footers; added captions for figures 19, 20, 21, 22

G. Vivo (CRF)




Abbreviation List Term Definition API Application Programming Interface

DB Data Base

DR Data Receiver

ECAID Extended Cooperative Algorithms Incident Detection

ESPOSYTOR SAFESPOT SYSTEM MONITOR FW Framework

GNSS Global Navigation Satellite System

GPS Global Positioning Satellite

LDM Local Dynamic Map

OR Object Refinement

OS Operating System

OSGI Open Service Gateway Initiative

RSU Road-Side Unit

RFID Radio Frequency Identification

SOAP Simple Object Access Protocol

SP Sub-Project

SR Situation Refinement

TMC Traffic Management Centre

UDP User Datagram Protocol

UTC Urban Traffic Control

VANET Vehicle Adhoc Network

VMS Variable Message Sign

WSN Wireless Sensor Network




Table of contents Revision Log ............................................................................................................................................2 Abbreviation List......................................................................................................................................3 Table of contents ......................................................................................................................................4 List of Figures ..........................................................................................................................................6 List of Tables............................................................................................................................................7 List of SP2 partners ..................................................................................................................................8 List of SP2 partners ..................................................................................................................................8 EXECUTIVE SUMMARY ......................................................................................................................9 1. Introduction ....................................................................................................................................10

1.1. Innovation and Contribution to the SAFESPOT Objectives ...............................................10 1.2. Methodology .......................................................................................................................10 1.3. Deliverable structure ...........................................................................................................11

2. Principal characteristics and innovative features of the INFRASENS Platform ............................12 3. Physical implementation and HW components ..............................................................................16

3.1. Roadside Unit (RSU Main PC) ...........................................................................................17 3.2. Roadside Sensing Systems ..................................................................................................19 3.3. GPS receiver........................................................................................................................20 3.4. VANET Router....................................................................................................................21 3.5. WLAN card .........................................................................................................................22 3.6. Ethernet Switch ...................................................................................................................22 3.7. LDM (Local Dynamic Map) ...............................................................................................23 3.8. ESPOSYTOR......................................................................................................................23

4. Functional model and SW Components .........................................................................................25 4.1. Data sources ........................................................................................................................25

4.1.1. Roadside sensing systems...............................................................................................27 4.1.2. SAFESPOT vehicles.......................................................................................................28 4.1.3. External sources..............................................................................................................28 4.1.4. COSSIB Applications.....................................................................................................28

4.2. Data Fusion Process ............................................................................................................28 5. Data Receiver and Object Refinement Modules.............................................................................31

5.1. Cooperative pre-data fusion module....................................................................................31 5.2. Data Fusion Logic ...............................................................................................................32

5.2.1. DFL – Pre-Conditions ....................................................................................................32 5.2.2. DFL – Installation..........................................................................................................33 5.2.3. DFL – Features ...............................................................................................................35 5.2.4. DFL –Configuration .......................................................................................................36 5.2.5. DFL –Results and LDM Handling..................................................................................41

6. Situation Refinement Modules .......................................................................................................42 6.1. Vehicle-related information.................................................................................................42

6.1.1. Manoeuvre estimator ......................................................................................................42 6.2. Traffic-related information..................................................................................................42

6.2.1. Traffic Data Calculator ...................................................................................................42 6.2.2. ECAID: Extended Cooperative Automatic Incident Detection ......................................44 6.2.3. Traffic Event Calculator .................................................................................................46

6.3. Environmental conditions....................................................................................................49 6.3.1. Environmental consolidator............................................................................................49

6.4. Safety-related information...................................................................................................51 6.4.1. Dynamic Black Spot Recognition...................................................................................51

7. Roadside Sensing and Warning Systems........................................................................................53 7.1. CCTV for ice and wet road detection..................................................................................53 7.2. Thermal camera for living object detection.........................................................................57 7.3. RFID system for ghost driver detection ..............................................................................60 7.4. CCTV for visibility assessment...........................................................................................62 7.5. Laserscanner for tracking of road users...............................................................................65 7.6. CCTV for vehicle positioning .............................................................................................68 7.7. Wireless Sensor Network (WSN)........................................................................................70




8. Conclusions ....................................................................................................................................77 References ..............................................................................................................................................78 ANNEX 1: Implemented prototypes ......................................................................................................79 ANNEX 2 : Planned installations of the SP2 modules ...........................................................................81 ANNEX 3 : Installation of the LDM....................................................................................................101




List of Figures Figure 1 – Basic functional blocks of the INFRASENS Platform............................................. 13 Figure 2 – RSU building components and subsystems........................................................... 16 Figure 3 – RSU main PC ......................................................................................................... 17 Figure 4 – Single PC vs multiple PC configurations................................................................ 19 Figure 5 – Functional model of the Infrastructure Platform ..................................................... 26 Figure 6 – Laserscanner based Cooperative Pre-Data Fusion system components.............. 31 Figure 7 – Screenshot of the LINUX file browser after installing the DFL program. ............... 34 Figure 8 – The DFL terminal window with typical output......................................................... 34 Figure 9 – Data flow from sensors via the LDM, traffic data calculation to ECAID ................. 43 Figure 10 – TDC: Display of traffic parameters (example: simulated data) ............................ 44 Figure 11 – Traffic information data flow from sensors to ECAID incident alarm ................... 45 Figure 12 – ECAID Graphical User Interface .......................................................................... 46 Figure 13 – Components involved in the TEC Module............................................................ 47 Figure 14 – TEC module tray icon........................................................................................... 48 Figure 15 – TEC module tray menu ........................................................................................ 48 Figure 16 – TEC module log screen........................................................................................ 49 Figure 17 – Integration of Environmental Consolidator with other modules ........................... 50 Figure 18 – Data Flow from external sources and sensors via LDM for Dynamic Black Spot Recognition.............................................................................................................................. 52 Figure 19 – Scheme of the Wireless Sensor Network system................................................ 70 Figure 20 – Layout of two Wireless Sensor Networks, on a two-way road section ................ 71 Figure 21 – Self configuration for the Wireless Sensor Network............................................. 72 Figure 22 – LED warning system for the adopted Wireless Sensor Network system............. 74 Annex2 - Figure 1 – G-D1 Dortmund, Germany..................................................................... 82 Annex2 - Figure 2 – I-TC1 Torino-Caselle, Italy..................................................................... 83 Annex2 - Figure 3 – I-TC2 Torino-Caselle, Italy..................................................................... 84 Annex2 - Figure 4 – I-CRF1 Test Track, Orbassano, Italy ..................................................... 85 Annex2 - Figure 5 – I-CRF2 Test Track, Orbassano, Italy ..................................................... 86 Annex2 - Figure 6 – N-1 Helmond Nethrelands ..................................................................... 87 Annex2 - Figure 7 – N-2 Helmond Netherlands ..................................................................... 88 Annex2 - Figure 8 – N-3 Helmond Netherlands ..................................................................... 89 Annex2 - Figure 9 – S-1 Gothenborg, Sweden ...................................................................... 90 Annex2 - Figure 10 – W-VS1 Vivy Saumur, France............................................................... 91 Annex2 - Figure 11 – W-VS2 Vivy Saumur, France............................................................... 92 Annex2 - Figure 12 – W-VS3 Vivy Saumur, France............................................................... 93 Annex2 - Figure 13 – W-VS4 Vivy Saumur, France............................................................... 94 Annex2 - Figure 14 – W-VS5 Vivy Saumur, France............................................................... 95 Annex2 - Figure 15 – W-VS6 Vivy Saumur, France............................................................... 96 Annex2 - Figure 16 – W-EM1 Etables sur Mer, France .......................................................... 97 Annex2 - Figure 17 – W-EM2 Etables sur Mer, France .......................................................... 98 Annex2 - Figure 18 – W-S1 Satory track, France .................................................................. 99 Annex2 - Figure 19 – W-B1 Bourbriac, France ..................................................................... 100




List of Tables Table 1: Technical specifications of the DIGICOM Ethernet Switch ....................................... 23 Table 2: List of all LINUX shared libraries needed by DFL. .................................................... 33 Table 3: LDM tables storing the results of the fusion processes............................................. 41 Table 4: CCTV for ice and wet road detection ........................................................................ 56 Table 5: Thermal camera for living object detection................................................................ 59 Table 6: RFID system for ghost driver detection ..................................................................... 61 Table 7: CCTV for visibility assessment.................................................................................. 64 Table 8: Laserscanner for tracking of road users.................................................................... 67 Table 9: CCTV for vehicle positioning ..................................................................................... 69 Table 10: Wireless Sensor Network for vehicle count and passage....................................... 76




List of SP2 partners

Short name Full name

CRF Centro Ricerche Fiat - CRF

ANAS ANAS SpA

MIZAR MIZAR Automazione S.p.A.

IBEO IBEO Automobile Sensor GmbH

NAVTEQ NAVTEQ Europe B.V.

PTV AG Planung Transport Verkehr AG - PTV

TA Tele Atlas NV

VTT VTT Technical Research Centre of Finland

CIDAUT Desarrollo en Automoción

CSST Centro Studi sui Sistemi di Trasporto

CERTH Centre for Research and Technology - HELLAS

LCPC Laboratoire Central des Ponts et Chaussées

ISMB Istituto Superiore Mario Boella

SODIT Société pour le Développement de l'Innovation dans les Transports

TUM Technische Universitaet Muenchen

BME Budapest University of Technology and Economics

PEEK Peek Traffic




EXECUTIVE SUMMARY This report presents the prototype Infrastructure Platform developed and implemented by INFRASENS as part of the SAFESPOT cooperative system. It describes the hardware and the software modules making up the platform, as well as the physical and functional characterization providing the underlying framework. The report begins by providing a general introduction, describing the main characteristics of the Platform and highlighting the most innovative aspects. This is followed by detailed technical information of interest to those wishing to set up any of the components of the Platform, e.g. in the SAFESPOT Test Sites. Descriptions are provided for:

• the physical equipment which needs to be installed on the roadside, including the roadside unit (RSU) and the sensing systems.

• the Data Receiver, which is the common interface to the data sources.

• the SW modules which are part of the Data Fusion process.

Among the main achievements underlined in the report are:

- the integration within the Platform of the common components developed by the SINTECH subproject for both the Infrastructure and Vehicle Platforms (i.e. the LDM and the routing software for the Ad Hoc Vehicle Network – referred to as the VANET);

- the ‘Data Fusion logic which is the ‘core’ of the Platform. This undertakes the complex data fusion processes which fall into two categories: the Object Refinement and the Situation Refinement, each consisting of a number of separate modules. It can deal with data of many different types and relevant for road safety – dangerous vehicle manoeuvres, slippery roads, fog and icy weather conditions, the presence of obstacles on the roadway, etc.

- the open architecture which makes it possible to interface a wide range of sensing systems and also other data sources, including SAFESPOT vehicles and external traffic systems, with the Data Fusion block. The Platform is able, as a result of the fusion process, to make available all the necessary information for the CoSSIB applications. Details of the planned implementations of SP2 components in the SAFESPOT Test Sites can be found in the Annex.




1. Introduction The INFRASENS subproject is responsible for specifying and developing the Infrastructure Platform which is a fundamental part of the SAFESPOT Cooperative System. This document presents the components of the Infrastructure Platform whose development was undertaken in Work Package 2.4 (Implementation and Prototypes). It includes descriptions of both the HW and SW modules of the prototypes. The development work itself was based on the specifications which can be found in the deliverable D2.3.2 [1]. All the elements of the Infrastructure Platform will be subject to a process of testing and validation - as part of Work Package 2.5 - in order to evaluate their performance and ensure their correct operation before being installed in the SAFESPOT Test Sites.

1.1. Innovation and Contribution to the SAFESPOT Objectives

This report is intended to serve as a reference document which provides a description of the key characteristics of the Infrastructure Platform as well as the information required by those wishing to implement the platform. The document begins by outlining the principles underlying the design of the Platform, then describes in a concise way all the constituent elements, giving indications relating to their implementation. This same information has already presented to the partners involved in the SAFESPOT Test Sites in a workshop in November 2008. During this workshop, detailed descriptions and practical demonstrations of all the key components of infrastructure platform were given, going from HW components to SW modules and installation guidelines (operative system to data fusion). An explanation was also given of how to install the software in the roadside unit (RSU), including the Local Dynamic Map (LDM) and the Router (which permits communication between the RSU and the SAFESPOT vehicles through the Ad hoc Vehicle Network or VANET).

In some cases, further technical details relating to the installation of specific components are provided in manuals prepared by the developers (these can be downloaded from the SAFESPOT server).

1.2. Methodology

The development of the prototypes described in this report was based on the specifications set out in D2.3.2 [1], which in turn reflect the user needs and requirements presented in D2.2.2 [2]. To support the prototyping, a variety of instruments has been used, including modeling tools, simulation environments, and data players. A crucial aspect of the development process has been the constant and close collaboration with




other subprojects, especially SINTECH which was responsible for developing the LDM and VANET. One of the most critical joint tasks, involving all the technical subprojects, and led by the SCORE subproject, was the definition of the format for all the data messages to be exchanged internally within the SAFESPOT system. This has been a process of considerable complexity, but essential to the achievement of a truly cooperative platform. INFRASENS has contributed by defining the message output of the sensing systems and also coordinating the definition of the data messages required by the Test Sites from external sources, such as Traffic Centres and Weather Stations.

1.3. Deliverable structure This report is organised as follows: Chapter 2 gives an overview of the main features of the Infrastructure Platform and the way in which it responds to the objectives initially set out. Chapter 3 focuses on the physical elements, i.e. the hardware components which need to be installed on the roadside in order to implement the Platform. Chapter 4 describes the functional blocks which make up the Platform. It explains the underlying framework, i.e. the functional characteristics and then briefly introduces the SW modules required for the Data Fusion process. Chapter 5 and Chapter 6 provide information on the SW modules which are part of the Object Refinement process and the Situation Refinement process respectively. Chapter 7 consists of a set of data sheets providing technical details of the roadside sensing systems. Chapter 8 offers some concluding remarks on the planned implementations of the Infrastructure Platform, and comments on its potential future exploitation. Annex 1 provides indication of the implemented prototypes, as scheduled. Annex 2 indicates the implementation of the INFRASENS modules planned in the various Test Sites. Annex 3 provides instruction for the installation of PostgreSQL database and the creation of the LDM developed by TeleAtlas.




2. Principal characteristics and innovative features of the INFRASENS Platform Objectives The challenge faced by INFRASENS has been to permit the infrastructure to play an active role in preventive road safety as part of a ‘cooperative’ system. This involved finding a way of integrating data coming from roadside sensors with data from equipped vehicles (considered in this context as ‘mobile sensors’) to generate information which could be used to produce safety-related warnings for drivers. The response has been to develop an Infrastructure-based Platform which is complementary to the Vehicle-based Platform, SAFEPROBE, so that they offer a cooperative approach to the prevention of road accidents. The Platform is designed to run in roadside units (RSU) installed at critical parts of the road network (“black spots”) and to exchange data with passing vehicles. The Platform integrates two other key elements of the SAFESPOT system, the LDM and the VANET, which were developed by the SINTECH subproject. Role of the infrastructure in SAFESPOT SAFESPOT vehicles use the data provided by a range of on-board sensors to build up a dynamic database (the Local Dynamic Map) which provides a representation of the surrounding road conditions, potential hazards, and the behaviour of neighbouring vehicles. This information is exchanged between vehicles through the VANET. The support of additional data gathered from the infrastructure permits an ‘extended perception’ of the road environment and helps to produce safety-critical information of greater precision and reliability. It is especially valuable when the traffic density is low and in the early stages of market introduction when there is not a high percentage of equipped vehicles. Such an approach requires a processing unit on the roadside which is able to acquire data from a range of different sources and undertake the necessary processing and refinement to produce the information which is required by the SAFESPOT Applications. An open architecture An important requirement for achieving the above objectives was the definition of an ‘open’ architecture, which would be suitable for different types of safety application and for different road environments (motorways, urban and rural roads). The solution was to define a common interface between the RSU and the various data sources. This consists of a multi-source Data Receiver which is able to acquire data not only from the roadside sensing systems, but also any legacy system (e.g. Urban Traffic Control system, Traffic Information Centre) which sets up the appropriate gateway. The INFRASENS platform is technology independent, in the sense that it imposes no constraints on the type of sensing technologies employed. This means that, as long as the data output is formatted in the correct way, the same platform could be used to incorporate innovative sensing approaches.




Figure 1 shows the overall framework consisting of the data sources on the left, the interface for acquisition of the data, known as the Data Receiver (DR), and the two main components responsible for the processing of this data: the Object Refinement and Situation Refinement blocks.

SP5 Feedback

VANET

SP2 SENSORS

DR = Data Receiver

Local Dynamic Map (DB)

EXTERNALGATEWAYS SITUATION

REFINEMENT

OBJECT REFINEMENT

DR

Data Fusion

Figure 1 – Basic functional blocks of the INFRASENS Platform

The Data Fusion process Central to the INFRASENS platform is the Data Fusion Block which consists of numerous modules, each undertaking a specific processing task. Its aim is to use the data form the sensors and other sources to produce high quality and reliable safety-related information. This is ‘written’ on the Local Dynamic Map, i.e. the dynamic data base in the roadside unit, so that it is available for the SAFESPOT Applications. The Data Fusion block consists of two main parts: the Data Receiver, Object Refinement and Situation Refinement. While the aim of the former is to increase the level of detail and accuracy regarding specific detected objects (e.g. an obstacle or a vehicle), the latter consists of a set of modules whose output helps to provide a picture of the overall driving environment, e.g. traffic events, vehicle manoeuvres, and weather conditions (e.g. visibility levels). It is possible for the Data Receiver, the Object Refinement and the Situation Refinement modules to write on the LDM, while only the latter can query or update data items. (This differs from the Vehicle Platform where a single module - the Data Provider - is responsible for this task). The most important implication of this solution is that one single (Situation Refinement) module must be given responsibility for updating any given data item in the LDM.




Acquisition of data from multiple sources A fundamental feature of the Data Fusion Module is the common interface (Data Receiver) which permits input of data from a wide variety of sources, the most important being:

• Roadside sensing systems which provide data relating to safety-critical events or conditions regarding the driving environment;

• SAFESPOT-equipped vehicles which communicate data from onboard sensing systems via the VANET.

It is also possible by setting up special gateways to acquire data from external systems, such as Traffic Control Systems or Traffic Management Centres.

The roadside sensing systems which - for experimental purposes - have been integrated within the INFRASENS platform, include an innovative network of micro-sensors as well as more conventional systems. In combination with the other data sources, their role is to extend the drivers’ field of view. All of these systems include pre-processing modules to convert the raw data into useful measures for the Data Fusion modules. Innovative aspects of the Infrastructure Platform The principal innovations incorporated in the platform are outlined below.

1. The definition of a functional model (described above) which permits the integration of road-based and vehicle-based sensing, and the communication of data between roadside units and equipped vehicles.

2. The development of a prototype sensing network consisting of a set of nodes using microsensors to detect the presence of passing vehicles, algorithms to interpret these signals, and wireless communication to ‘hop’ data between the nodes and send the output to a roadside unit.

3. The development of modules designed to refine data received from very different types of roadside sensor, from external sources and from vehicles. This has involved defining techniques for dealing with non-homogeneous data (combining data from fixed and mobile sources, and conventional and non conventional measurements), including:

- the implementation of an Extended Cooperative Automatic Incident Detection (ECAID) prototype which combines data from the Wireless Sensor Network with vehicle data to enhance the performance of traditional traffic incident detection algorithms

- the modelling of vehicle manoeuvres, on the basis of data from a laserscanner system, as input for the detection of hazardous driving behaviour of vehicles.

4. The implementation of an interface to a traffic light controller which makes it possible to acquire data, such as information on the current and next signalling phase, and to combine this with data captured by existing roadside detectors.




5. The development of enhanced detection algorithms able to interpret the signals and measurements produced by conventional sensing systems to produce data useful for preventive safety. These include: "personalised" algorithms which implement innovative approaches to image processing, making it possible to use the output of surveillance camera systems (normally employed for traffic flow management or for enforcement purposes) to generate information on dangerous driving conditions, e.g. low visibility (fog) and slippery road surface (ice).




3. Physical implementation and HW components This section presents the physical implementation of the Infrastructure Platform. It describes the constituent hardware elements and explains how these relate to the software modules. The main physical components of the platform are the:

• Roadside Unit (RSU) in one or more PCs (which carries out the data processing)

• Roadside Sensing Systems (data sources) • GPS receiver • VANET Router (which permits communication

with SAFESPOT vehicles over VANET) • Esposytor (SAFESPOT system monitoring tool). • Gateways towards legacy systems, e.g. traffic light

controllers, traffic information centres, and remote control system (for modifying the system set up).

These components are shown in Figure 2.

Figure 2 – RSU building components and subsystems

Ethernet / UDP

WARNING SYSTEMS

ESPOSYTOR

CCTV Firewire

Thermal camera Firewire

NIR camera

Firewire

Wireless Sensor Network

RSU MAIN PC

RFID reader

Router VANET

Data Fusion LDM

Applications Message Manager

Pre-processing PC

Pre-processing PC

Pre-processing PC

Test site dependent

GPS

LAN

/ SWITC

HIN

G RS232

Sensing Systems 1

Sensing Systems 2

USB

Gateways LaserScanner + ECU

TRAFFIC CONTROL CENTRE




In Figure 2, the roadside sensing systems are shown with a green background. Each has a pre-processing PC which prepares the output in a suitable form to be transferred to the Data Fusion process in the RSU. The components of the INFRASENS Platform are connected within a Local Area Network (LAN) (due to the number of network nodes a switch is needed); data messages are exchanged over the Ethernet using the UDP protocol. These messages need to be formatted according to the specifications defined by the SCORE subproject [3]. Each of the components is described in greater detail below.

3.1. Roadside Unit (RSU Main PC) The core of roadside equipment is the RSU MAIN PC. This represents the principal “intelligence” of the Platform where all the complex data from the infrastructure and/or from the vehicles sensors is undertaken. Figure 1 shows the components contained in the RSU. It should be noted that not only the INFRASENS Data Receiver, Data Fusion block and the LDM, but also the COSSIB Applications maybe installed in the RSU. RSU software configuration LINUX was chosen as the Operating System (OS) and to develop the software for the Roadside Unit software because:

• It is relatively stable and robust; • The same OS has been used for the VANET, which also adopted C++

as the development language; • The parallel Cooperative Systems projects CVIS and COOPERS are

also using LINUX for the RSU. This facilitates interoperability and makes it easier to implement joint applications in the common test sites.

For detailed descriptions of the specific modules see Chapter 5. RSU hardware configuration

Figure 3 – RSU main PC




RSU main PC consists of an industrial PC1 with the following features:

• CPU: LGA 775 Intel (for Pentium 4 or Core2);

• System Chipset: Intel® 945G+ICH7;

• System memory: no less than 1GB;

• Ethernet: 1;

• USB: 2;

• VGA/ Keyboard/Mouse: 1 x DB-15 VGA Connector, 2 x PS/2 for keyboard & mouse;

• Audio: AC’ 97 Line-in / Line-out (optional);

• Serial Port: Serial Port 1 x RS-232;

• Storage: 3.5” HDD or 2.5" HDD + Slim CD-ROM module (optional);

• Chassis Construction: Front bezel: XXX Chassis: heavy duty metal;

• System Cooling:

• Power Supply: Internal DC-to-DC power converter, input voltage: 19VDC External power adaptor, input voltage: 100VAC ~ 240VAC@50~60Hz, 150W;

• Operating Shock: 3G acceleration peak to peak (11ms)

• Operating Vibration: MIL-STD-810F 514.5C-1

• Operating Temperature: 0~50°C

• Operation Humidity: 10% ~ 90%

• Dimensions (DxWxH): 258mm x 210mm x 65 mm

• EMC: meets EC, FCC Class A • The main PC needs a cabinet for protection and a switch, • Cabled power supply is required.

Single main PC or multiple PC solutions? The aim, where possible, is to host the INFRASENS Data Fusion, the LDM and the SP5 Applications in the same PC (RSU MAIN PC). When this is not possible – either due to capacity constraints or because the processes use incompatible operating systems – they will have to be installed in separate PCs which must be connected to the LAN. Many of the COSSIB Applications have been developed in Windows, which means that a Test Site wishing to implement such an Application will need to use two PCs: one for the LDM, Data Fusion and Data Receiver module, and the other for the Application(s).

1 For temporary installations, e.g. for demonstrations, the use of a non industrial PC may be adequate. The system memory required will depend on the Applications, i.e. the SW modules, to be installed (Data Fusion Logic, LDM and CoSSIB Applications). See details in Chapter 5.




The two possible configurations are presented below:

A. The RSU is composed of 1 PC – running in a Linux environment - in which all SW modules, including the CoSSIB applications, are hosted.

B. The RSU is composed of 2 PC: one using Linux, hosting the Data Receiver, Data Fusion and LDM, and another, using Windows, dedicated to the CoSSIB application(s).

Figure 4 – Single PC vs multiple PC configurations

3.2. Roadside Sensing Systems These are systems responsible for monitoring the local ‘safe spot’ (usually a stretch of road of from 10-20m to several hundred metres in length) and gathering safety-related information which is fed to the Data Fusion process. The sensing systems are composed of two elements:

• the sensor itself and • the pre-processing PC.

Note: Since SAFESPOT is a research platform, it was decided to keep the pre-processing separate from the main SAFESPOT framework in order to avoid integration constraints. The pre-processing is carried out in a dedicated PC connected to the sensing system. This solution gave sensor developers the freedom to use the most convenient interface (USB, firewire, etc.) between the sensor and the pre-processing PC. There is nevertheless a common (UDP) interface towards the SAFESPOT environment for transferring the results of the sensing operation to the RSU. The only exception is the Wireless Sensor Network which is connected to the MAIN PC directly via USB. The advantage of this approach is that potentially, any type of sensing technology could be integrated within the INFRASENS Platform. The seven sensing systems developed in INFRASENS are described in the next Chapter, and a Technical Data Sheet provided in Chapter 6.

DR + DF LDM COSSIB Apps

DR + DF LDM

COSSIB Apps

1 PC = RSU MAIN PC

2 PC = RSU MAIN PC

Linux

Linux Windows




3.3. GPS receiver Although the RSU has a fixed position, and hence the reference coordinates are known a priori, a GSP receiver is needed in the RSU in order to have a common reference time for all the processing modules and with regard to the vehicles (essential for V2I applications). As shown in figure 2, all Infrastructure platform components are connected over the LAN, therefore a timing reference is essential. The receiver needs to provide a Precise Positioning Service (PPS – pulse per second). The GPS receiver could be connected and handled directly to Main PC via RS232 or USB port. During site installation a specific attention for “antenna installation” is suggested in order to have a good satellite visibility. This means that it is preferable for the antenna to be located outside the cabinet containing all RSU components. The following system is recommended: GPS receiver - uBlox ANTARIS EvalKit. For further information: http://www.u-blox.com/products/evalkit.html Two possible solutions are recommended for achieving synchronization: 1. GPS handled by RSU MAIN PC

• It is important to correctly install NTP server into Main PC (Linux based) – this operation it is not trivial

• To configure NTP client in each PC part of RSU LAN 2. Use of the “positioning SW” developed in SINTECH (in order to simplify

task 1a). • The use of this solution implies the presence of 2 RSU PC: 1 Main PC

(Linux based) and 1 PC (Windows based hereafter called Application PC) shared for application and positioning sw.

• Connect GPS receiver to Application PC and install positioning sw on this PC. Use guidelines provided by SINTECH in order to configure such software.

• Install NTP server and NTP service monitor on Application PC: http://www.meinberg.de/english/sw/ntp.htm

• Each PC connected to Application PC shall have a NTP client correctly configured in order to receive time reference from Application PC




3.4. VANET Router The RSU is part of the VANET, as it has a bidirectional exchange of data with equipped SAFESPOT vehicles. This means that a specific component, the “VANET Router” needs to be included in the implementation of the INFRASENS platform. Like all the other components previously described, the “VANET Router” has HW and SW parts. From the physical point of view the router is an embedded PC integrating IEEE 802.11p wireless module and hosts all the software related to “communication”. Note: From the system point of view, the router could in future be integrated into the MAIN PC. However, for convenience of installation, since the location of the antenna is extremely important, it is convenient, at least for the prototype demonstrations, to separate the router from the MAIN PC. The VANET Router provides Beaconing, Location Lookup and Neighbour Table functions. These are used to offer various information distribution schemes, especially Single Hop Transmissions, Geocast and Stored Geocast. For the roadside infrastructure as a whole, the LDM represents the central point which permits different entities to share data by “writing on” and “reading from” the LDM using T-API and Q-API. The VANET Router itself uses a dedicated Q-API to update header fields of the transmitted messages, especially the EGO information NL_NodeInfo. Normally only the NL_NodeInfo fields are processed by the VANET modules. Other object data as specified by the LDM or application subprojects are handled simply as Payload inside the VANET modules. The LDM builds up a neighbour table filled of information coming from detection systems and from the passing vehicles. Messages generated by RSU are: BeaconMsg and EventMsg. The beacon message is composed of three parts: the beacon header, beacon payload and beacon security. The beacon header contains information relating to the RSU itself, available from LDM or from a initial configuration file. The beacon payload consists of application data parameters. This data is managed by the Message Generation (MG) Module of the VANET. The same structure is valid for the EventMsg. Messages sent by RSU are generally Single Hop Broadcast packets that will be received and processed by all nodes in direct communication range. But reception is not guaranteed. All the software and functionalities of the router have been developed, tested and released by the SINTECH subproject. The router PC which has been selected is: - ALIX3C3 Board equipped by 1 LAN and 2 miniPCI, LX800, 256 MB, USB, VGA, audio. The choice of this board means it is possible to choose the casing for an indoor or outdoor environment.




More details are available at the following link: http://www.mini-box.com/Alix-3C-Board-3-LAN-1-MINI-PCI-1_2 A specific document prepared by the SP7 subproject presents and specifies the messages exchanged over the VANET [3]. The VANET characteristics and functionalities are described in a document released by SINTECH. [4]

3.5. WLAN card The WLAN kit that is used for SAFESPOT purposes is the following: Q-Free CALM M5/IEEE 802.11 WLAN Radio Basic Features:

PC Interface: MiniPCI Protocols supported: 802.11a/b/g/p Modification to enable the DSRC synchronization input line (only used

in CVIS reference platform) Modification to enable GPS time synchronization input line (only used

in CVIS reference platform) IEEE 802.11 Radio front end

• Frequencies: 5,85-5,95 GHz (802.11p), 2,4-2,5 GHz and 5,2-5,8 GHz with normal ABG operation

• Channel bandwidth: 10 and 20 MHz selectable • Power setting: Adjustable from 0 dBm to +18 dBm in steps of

maximum 1 dB resolution. No high accuracy • Spectrum mask: 802.11p class C • Rx sensitivity: 802.11p

3.6. Ethernet Switch

Each road side unit platform will be composed by a number of different PC unit connected each other among Ethernet. It is clear the need of the specific switch; however there aren’t any particular requirements to be respected. For example a reference model used by Italian partner is: Switch Fast Ethernet 10/100 – DIGICOM Model Dual Speed Switch 16D.




Technical specification

Gates: 16 porte RJ-45 10/100 autosense and autoconfigure (MDI-X e MDI)

Working conditions: Half/Full duplex on every port, technology Store & Forward

Access method: CSMA/CD, full speed filtering and forwarding rate Memory: 1,5 Mbit per table with 4096 addresses

Compliant: spec. IEEE 802.3, IEEE802.3u Support: IEEE 802.3x flow control per full duplex

Table 1: Technical specifications of the DIGICOM Ethernet Switch

3.7. LDM (Local Dynamic Map) The LDM is the central “sharing place” which stores the data output from internal SP2 processes and makes it available to CoSSIB Applications. The latter ‘queries’ this dynamic data base (DB) to obtain input data. Within SAFESPOT, both Navteq and TeleAtlas/Bosch have provided implementations of the LDM. It is left to the user to select the preferred solution. Both versions have API in Java and C++. The LDM is characterized by four layers:

layer 1 - the static map database (preferably enhanced for Advanced Driver Assistance Systems - ADAS)

layer 2 - additional static information not present in the standard map database

layer 3 - temporary and dynamic information (e.g. weather and traffic conditions)

layer 4 - dynamic objects (e.g. a single vehicle) Layers 1 – 2 are specific to a given test site, as they are based on local cartographic details. Full details about the LDM are available in [5].

3.8. ESPOSYTOR ESPOSYTOR is an Integrated PC-based tool providing Super User/ Developer oriented monitoring / diagnostics & management features. A dedicated page for Infrastructure allows the visualization of the dynamic information coming from the LDM, dynamic events located on the map, and warnings from SP5 applications, as well as an overall view of RSU information and vehicles or static obstacles present on the road. ESPOSYTOR Specifications are available in D. 4.3.5.




In response to some frequently asked questions about implementations of the the Platform, a brief summary is given below of the main steps.

Preliminary steps for defining the necessary modules

1. Analyse the planned Application(s) to establish the data input required. 2. Select the appropriate sensing system and other data sources. 3. With regard to roadside the sensing system chosen, take note of any

installation constraints and requirements (e.g whether the sensor needs to be mounted in a specific way in order to work properly). These constraints can be found the Data Sheets in Chapter 7. In case of doubt contact the sensor provider.

4. A pre-processing PC will be provided by the sensor system provider in a “ready to use” state. The Test Site is not required therefore to use a specific operative system nor to install a specific framework in order to use a given sensor as the interface is standardised from the point of view of the RSU main PC.

5. For other data sources, ensure the necessary gateway is set up. 6. Identify the necessary Data Fusion modules and check their

requirements (se Chapters 5 and 6 in this report).

How should a Road Side Unit be set up?

1. Note that, from the HW point of view, it is the responsibility of the Test Site to purchase a suitable PC after studying the requirements in terms of memory and performance.

2. From the SW point of view, INFRASENS will provide: - the module needed to acquire data from the sensors, i.e. the Data Receiver - the modules required for undertaking the data fusion process and writing the data output on the LDM.

3. Download from http://bscw.safespot-eu.org/bscw/bscw.cgi/178040 the necessary SW modules and installation guide.

4. Establish whether the SW for the CoSSIB Application(s) concerned run in a Linux or Windows environment. In the case of the latter, it will be necessary to have an additional PC dedicated to the Application(s).

5. Identify the data input necessary for the Application, and hence the data sources required, i.e. the type of roadside sensing system, and any gateways to external systems.

6. Be sure to have a GPS receiver able to provide “time pulse” needed for time reference and install NTP server.

7. Obtain the LDM and static map which provides the static geometry of your test site.

8. Ensure you have the latest correct version of the LDM suitable for the operative system of your RSU MAIN PC. See: http://bscw.safespot-eu.org/bscw/bscw.cgi/81958




4. Functional model and SW Components This section describes the functional (logical) model of the Infrastructure Platform developed by INFRASENS. It indicates all of the SW modules which are found within each of the principle functional blocks already described in Chapter 2. These are illustrated in Figure 4. It should be pointed out that this functional model, which includes all possible data sources and data fusion processes, represents a Reference Framework. The deployments of the SAFESPOT system will always consist of a subset of these elements (it is highly unlikely that they will ever all be present in a single implementation). According to the data requirements of each application, different types of data will be required and hence different data sources (sensing systems or other sources). In order to process this data, different data fusion modules will be required. This means that, within the Infrastructure Platform in a roadside unit, each application will implement a different ‘data chain’. The only two elements always present are the Data Receiver and the LDM. A set of ‘maps’ indicating the modules required by each implementation foreseen in the SAFESPOT Test Sites can be found in Annex 1.

4.1. Data sources The modules on the left of the diagram consist of all the possible types of data source. These are:

roadside sensing systems SAFESPOT equipped vehicles external sources, roadside legacy systems such as Traffic Controllers

or Traffic Information Centres the COSSIB Applications (when it is necessary to update the LDM with

data generated by the Application, e.g. a dynamic speed limit). As long as data messages from these four kinds of data sources is formatted in the correct way or, in the case of external sources, the necessary gateways set up, the messages can be ‘fed’ into the Data Fusion process through the Data Receiver.

In order to provide a practical demonstration of this possibility, INFRASENS has developed the necessary detection algorithms and pre-processing modules for seven different types of roadside sensing systems which are available for use in the Test Sites.




SAFESPOT RSU System 08.04.2008

SP2 - Data Fusion

Object Refinement

Data Receiver

Manoeuvre Estimator

Object Matching

Traffic Information Consolidator

Traffic Data Calculator

ECAID

Map Matching

LDM DB

Q- / T-API Q- / T-API

Message Generator

VANET Messages

EnvironmentalConsolidator

Dynamic Black Spot Recognition

CCTV for Positioning (Preprocessing Unit)

Gateway to Safety Centre

Gateway to Traffic Control Centre

NIR Camera for Ice Detection (Sensor, Preproc. Unit)

Thermal Camera f. Living Objects (Preprocessing Unit)

RFID for Ghost Driver Detection (Preprocessing Unit‏

Wireless Sensor Network (Preprocessing Unit)

Gatetway to Traffic Light Controller

CCTV for Visibility(Preprocessing unit)

Laserscanner (Infrastructure Sensor)

Data Receiver

Laserscan

Message Router (VANET)

Data Receiver

WSN, RFID

IBEOCooperative

Pre-DataFusion

Object RefinementWSN,RFID

SP5 Application

Traffic Environment

Q-API

Q-API

IRIS specific

Vehicle Safety

Situation Refinement

Figure 5 – Functional model of the Infrastructure Platform




In addition, the necessary interfaces have been implemented to permit data to be acquired from SAFESPOT vehicles and from a number of external sources gateways. All of these data sources are listed below with a brief description. A detailed technical data sheet for each sensing system can be found in Chapter 5.

4.1.1. Roadside sensing systems Fog sensing (visibility) module – CCTV The fog sensing module consists of a CCTV camera and the related image processing algorithms. It is able to detect the presence of fog in a local area and to estimate the visibility distance. Living object sensing module – NIR system The living object detection system consists of a thermal imaging system and detection algorithms designed to identify an animal or pedestrian. Its provides an integer which indicates whether such an object has been detected. Vehicle sensing module – RFID The RFID system consists of roadside device which reads the tags installed onboard a set of specially equipped vehicles. It can be used with a single reader to produce a vehicle count, traffic flow classification or for detecting the presence of specific types of vehicle. With two (or more) RFID readers it can also detect Ghost Drivers (i.e. vehicles travelling in the wrong direction). Ice detection module – CCTV The ice detection system consists of a CCTV which monitors the road surface and acquires images which are polarised to detect the presence of ice. This information is used to provide a slippery road warning to approaching drivers. Road user tracking module – Laserscanner Sets of laserscanners (two or four) can be used for example at traffic junctions to detect, track and classify road users in the vicinity of the intersection. They are able to estimate the relative position, velocity, classification, dimension and orientation of vehicles and pedestrians. Moving vehicle positioning module – CCTV This camera system consists of an imaging system (camera + frame grabber) plus a processing unit that runs an algorithm which extracts information from the images. The detection module locates vehicles in the images, and the positioning module provides the geographic coordinates plus an estimation of the speed of the objects (vehicles) detected. Vehicle sensing module – WSN The Wireless Sensor Network consists of a set of sensing nodes (composed of microsensors) able to detect the passage of vehicles. Special sioftware (the local detection algorithms) permit the calculation of the speed and direction of passing vehicles.




4.1.2. SAFESPOT vehicles Beaconing messages and safety messages sent via the VANET (802.11p) can be received by the roadside unit from any SAFESPOT equipped vehicle. The roadside unit also broadcasts data messages to the vehicles, but this functionality is developed by the COSSIB subproject.

4.1.3. External sources

An important external source consists of the possibility of acquiring data from local traffic controllers (information on the current and next signalling phase). This has been implemented for an intersection in Helmond in the Netherlands, and at an intersection at Dortmund in Germany. Although it was not originally foreseen to develop interfaces for other data input from external systems, in response to requests from the Test Sites, it was decided to implement a gateway to permit data acquisition from a number of different sources. These include the following: - from Traffic Control Centres: information on road conditions, the presence of road works and of a broken down vehicle on the road; - from a Weather Centre: meteorological data (simulated data).

4.1.4. COSSIB Applications Although it is possible in theory for any COSSIB Application installed in a roadside unit (RSU) to update the LDM in the same RSU, the implementation of this functionality has been requested only for the Speed Alert Application. The necessary function in the Data Receiver has therefore been implemented to allow the application to transfer a data message consisting of an updated safe speed calculation to the LDM.

4.2. Data Fusion Process As the name implies, data fusion is a technique for `merging` data from different sources in order to produce an output which could not be obtained from a single data source. Within INFRASENS, the definition of data fusion is as follows:

Data Fusion is the merging of data from multiple sensors or detection sources (roadside and in-vehicle), as well as external sources, in order to obtain higher level data and information that are not possible from a single sensor or source.

The principal aim is to improve the quality of data in terms of its reliability, accuracy, and consistency.




Secondly, data fusion techniques are used to close gaps in detection, so that the potential impact of a breakdown of single sensor can be mitigated. Thirdly, data fusion provides information which cannot be measured directly by a sensor, because the appropriate sensor or technology is not available. There is a further advantage relating not so much to the quality of the data but to its quantity. The data fusion process will lead to a reduction in the volume of data to be passed on to the database referred to as the Local Dynamic Map (LDM), which will significantly `lighten` and speed up this operation. The Data Fusion process is made up of two main blocks: Object Refinement and Situation Refinement. Within these blocks are a number of different processes, each is briefly described below. The Object Refinement process consists of three main functions: Cooperative Pre-Data Fusion, Object Matching and Map Matching. The Cooperative Pre-Data Fusion module is specifically associated with the laserscanning system. It undertakes a first stage of pre-processing in which the output data of this sensing system is merged with information received from the equipped vehicles. The Data Receiver module is the ‘front end’ for the data processing. It is the standard interface responsible for acquiring data from the different data sources so that they can be made available to the data fusion process. The Object Matcher matches the moving objects captured by different kind of sensors. The aim is to identify the information originating from different sources being associated with the same moving object. The result of this process is a unique view of the moving objects in the monitored area which is stored in the LDM. The Map Matcher assigns the detected moving objects (vehicles) to an entity of the static layer of the LDM, i.e. a road element, lane are a reference track. The map matcher only deals with individual moving vehicles, not with traffic events. The Situation Refinement process is divided into four categories according to the type of data concerned:

- Vehicle: information relating to the manoeuvre of a detected vehicle - Traffic: information relating to traffic conditions and the presence of an

obstacle (accident, stopped vehicle, queue, etc) - Meteorological information: relating to visibility (presence of fog), icy or

wet road conditions. - Safety information: relating to the so-called ‘dynamic black spots’.

Each category may contain one or more processing module.




The Situation Refinement modules normally acquire data input from the LDM through a query mechanism. However in one case, the Manoeuvre Estimator, data is acquired directly from the Object Refinement block. Relationship between the data fusion modules and the LDM Both Object Refinement or Situation Refinement modules write their output data on the LDM using the relevant T-API (specified by the developers of the LDM as part of the SINTECH subproject). It should be noted that, unlike the Vehicle Platform, there is not a single ‘Data Provider’ block with this function.

In order to keep to a minimum the number of internal interfaces and to avoid possible conflict and inconsistencies in the LDM, only one module is responsible for updating a specific data item, e.g. the position of vehicles. More than one component however can query a specific item.




5. Data Receiver and Object Refinement Modules This section describes in detail the modules which constitute the core data fusion processes carried out in the roadside unit: the Data Receiver and the Object Refinement, including the Cooperative Pre-Data Fusion module. While this last module is specifically required by the laserscanner sensing system, due to the complexity of this sensor’s output data, the Data Receiver and the Object Refinement process provide key functions for all implementations. They are combined in a single application referred to as the Data Fusion Logic, which also includes the Manoaeuvre Estimator module.

5.1. Cooperative pre-data fusion module The Cooperative Pre-Data Fusion (CPDF) is a subsystem which is specific to implementations involving the roadside Laserscanning system. Its objective is to provide information about objects sensed by the Laserscanner to the main INFRASENS data fusion system, and in particular to the central level fusion module but also to the situation refinement. It fuses vehicle information transferred to the infrastructure (V2I communication data) with static map information and Laserscanner data at sensor level in order to provide more reliable and robust tracking and classification. The related components are depicted in Figure 6.

Laserscanner + ECU(inside road-side housing)


Laserscanner PC

(for cooperativepre-data fusion)

INFRASENS-System

- LDM (incl. static map)- VANET system- Data Fusion system

Legend: Arcnet Ethernet Figure 6 – Laserscanner based Cooperative Pre-Data Fusion system components

Developer:

- IBEO Components:

- 2 IBEO AlascaXT Laserscanner - 2 infrastructure mounting device and protective housing - 2 Laserscanner ECUs - 1 Laserscanner PC (performing the Cooprative Pre-Data Fusion)




Dependencies: - Hardware: MainPC (receives output) - Hardware: VANET Router (provides input) - Software: Data receiver (running on Ubuntu Linux) - Software: LDM (static map data)

Installation: - The Laserscanner system shall be mounted on opposite corners of

the intersection on the sidewalk having an unblocked view on the intersection. (see Figure 6)

- Power supply and Ethernet connection to the INFRASENS system (MainPC) shall be connected.

- The Cooperative Pre-Data fusion software is pre-installed and starts automatically at power-on.

5.2. Data Fusion Logic

The application DFL (=data fusion logic) is the software realisation of the main SAFESPOT data fusion part for the road-side unit (RSU). DFL receives UDP or SOAP messages, processes them and writes the data fusion results into the LDM database. Messages that are not trajectory related are written on the LDM without being further process in the object refinement. DFL comprises the following components: (1) the data receiver, (2) the object matching, (3) the map matching and (4) the manoeuvre estimator.

5.2.1. DFL – Pre-Conditions DFL is a LINUX terminal program (without user interface). It has been developed in a LINUX UBUNTU 8.04 environment. We recommend using the same environment to run the software. You can download LINUX UBUNTU 8.04 by following this link http://www.ubuntu.com/getubuntu/download. Take care that the shared libraries, dependencies of the DFL program, listed in the Table 2 below are installed on your computer. As the DFL installation is delivered as a “debian package”, dependencies are resolved automatically if possible. Indissoluble inconsistencies will force the installation process to abort with according warnings.




Table 2: List of all LINUX shared libraries needed by DFL.

Furthermore, a distribution of the PG-LDM or the NAVTEQ LDM needs to be installed on your computer, because the DFL program reads data from the LDM database and writes its results there. Thus the installation of one of these data bases is mandatory. The LDM scheme must be version 10.0.9. DFL – Restrictions of Version 1.0 - Message “VanetBeaconFromVehicle”: The only tag that is taken into account is “TAG 35” (positionTimestamp). - “GenericMessageFromVanetNode”: Is not considered.

5.2.2. DFL – Installation The program can easily be installed by the use of the debian installation package. The program will be installed in the directory “/opt/Safespot/DFL”. Necessary sub folder will be created automatically. Unpack it anywhere in your home directory branch. After unpacking you will find a directory structure as is illustrated in picture below.

libstdc++.so.6 => /usr/lib/libstdc++.so.6 libm.so.6 => /lib/tls/i686/cmov/libm.so.6 libgcc_s.so.1 => /lib/libgcc_s.so.1 libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 libc.so.6 => /lib/tls/i686/cmov/libc.so.6 libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 libkrb5.so.3 => /usr/lib/libkrb5.so.3 libcom_err.so.2 => /lib/libcom_err.so.2 libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 libtasn1.so.3 => /usr/lib/libtasn1.so.3 libgcrypt.so.11 => /lib/libgcrypt.so.11 ld-linux.so.2 => /lib/ld-linux.so.2 libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 libkeyutils.so.1 => /lib/libkeyutils.so.1 libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 libsasl2.so.2 => /usr/lib/libsasl2.so.2 libgpg-error.so.0 => /lib/libgpg-error.so.0




Figure 7 – Screenshot of the LINUX file browser after installing the DFL program.

The executable program is the script “DFL”. Make sure that it is executable (it should be, otherwise change the rights). To start the DFL, just double-click the DFL file. A terminal window should appear as is illustrated in Figure 8. Alternatively you could start the application in a terminal with the command “./DFL”. DFL runs in an endless loop with time period = 500 msec. Once per loop step the current time together with some overview information will be written in the terminal window.

Figure 8 – The DFL terminal window with typical output




5.2.3. DFL – Features

The current version of the programme (v.1.0) has the following features: 1. Data receiver for: - „VanetBeaconFromVehicle“ (NB at the time of writing, only the beacon

header and standard payload and TAG 35 are taken into account) - „GenericMessageFromVanetNode“ (at the time of writing, this has not

yet been taken into account) - „LaserSensorObjects“, - „CameraObjectDetection“, - „CameraIceDetection“, - „CameraMeteoConditionDetection“, - „InfrastructureWeatherStation“, - „InfrastructureDBSInformation“, - „DatexIIMessage“, - „CameraNumberPlateDetection“, - „RoadWorkPresence“, - „SafetyCenterInformation“, - „StatusTrafficLight&PedestrianDetector“, - „RawRoadDetectorData“.

2. Object matching with - Sensor trajectory matching algorithm: realises the assignments of sensor

trajectories (and raw detector data) to real moving objects (vehicles and bikers) by taking into account the known inaccuracies of their positions. This can be seen as the pre-processing step for the computation of fused trajectories (see next bullet).

- Computation of fused trajectories algorithm: One trajectory per real moving object is calculated out of the sensor trajectories. The fused trajectory can be regarded as the most probable and meaningful trajectory of the object.

3. Map Matching - The map matching only takes moving objects such as vehicle into

account. - The DFL will not map any other items such as foggy areas or traffic

event which locations are defined as a geometric object or any other referencing. No AGORA-C algorithms are implemented.

4. Manoeuvre Estimator - The manoeuvre estimator computes the most likely manoeuvre a vehicle

is up to make at the intersection. This an important input for the CoSSIB application IRIS.




5. LDM database (for more details see last paragraph in this chapter) - The results of the fusion processes are written on the LDM. - The data received from sensors or gateway for which no further data

fusion at the object level is required are also stored in the LDM.

5.2.4. DFL –Configuration There is a comprehensive configuration file in order to control the relevant parameters of the DFL application. Comments and explanation are inside the DFL_config file, which you will find in /opt/Safespot/DFL/config after installing DFL successfully. Do not change the parameter in the mark like this: These are special parameters for the vehicle manoeuvre estimation and the IRIS application respectively: These parameters you need to configure your system: Summary of the parameters for configuration:

- In the beginning you will find some logging opportunities. The default setting is 0 (=no logging). If logging is active (=1) the DFL application writes all received sensor or gateway info in ASCII csv-files that can be found in the sub-directory “DFL/out”. This is to support preliminary tests that relates to system integration. The structure of the csv-files reflects one-to-one the message structure that is defined in [3]. The following log files are written:

- Camera detection (e.g. cameradetection_2008-Aug-07 19:17:43.csv)

- Camera ice detection (e.g. ice_2008-Aug-07 19:17:43.csv) - Laser scanner (e.g. laser_2008-Aug-07 19:12:43.csv) - Camera meteo detection (e.g. meteo_2008-Aug-07

19:12:43.csv) - Vanet (e.g. vanet_2008-Aug-07 19:12:43.csv)

Note that the file name always contains a time stamp. In addition to that, the results of the trajectories computation can also be logged.

- Data receiver for sensor data sources and gateways to legacy systems configures the port numbers. The settings are already aligned with the definition in [3].

- Absolute position of the laser scanner in degree defines the reference point for the laser scanning system

- Local area of the RSU defined as rectangle. This is the area the RSU covers and should be inside the short-range communication area. DFL only accepts measurements of moving objects, which are inside this rectangle. If a moving object leaves this area it will be deleted from the LDM. In addition to that, the object will be deleted, too, if there




is no longer than 30 sec any data about the object. This value is hardcoded. Main propose of the second rule is to omit moving objects from the LDM in case of e.g. a breakdown of the communication.

- Presence of trajectory related sensor subsystems that are connected to DFL. This indicates which data sources send information on moving objects.

- Configuration of the presence of other sensor subsystems or gateways that are connected to DFL.

- Sensor info: frequencies, variances, penetration rates: Here you need to define attributes of the data sources providing information on moving objects.

- LDM related parameters. In this section you need to define basic setting for the LDM connection.

- Which modules shall be active? In the last section you can choose which of the modules you like to use.




The DFL configuration file: MAINLOOP_FREQUENCY 2.0 # frequency in Hz to perform the object refinement algorithms CLOCKCHECK_FREQUENCY 0.001 # frequency in Hz to check and synchronize clock differences

SENSOR_LOG 0 # logging of all incoming sensor data in external file "out/*.csv" TRAJECTORY_LOG 0 # logging of all fused and predicted trajectories in external file "out/*.csv" DEBUG_OUTPUT 0 # source code debug outputs data in external file "out/*_debug.out" # Parameters related to the DFS/DFH test environment DFH_REMOTE_CTRL 1 # Remote control from DFH allowed DFL_RCTRL_PORT 55554 # port number for remote control messages from DFH DFL_AUTOSTART 1 # activate start-button automatically at program start (for standalone use of DFL) DFH_UDP_PORT 55553 # Communication with DFH DFH_IP_ADDR "0.0.0.0" # "0.0.0.0" bind to all local interfaces # Data receiver for sensor data sources and gateways to legacy systems DFL_IP_ADDR "0.0.0.0" # "0.0.0.0" bind to all local interfaces DFL_UDP_PORT_CAMERAS 50008 # UDP port number camera (living, moving, ice, weather

and number plate detection) DFL_UDP_PORT_LASER 50004 # UDP port laser scanner DFL_UDP_PORT_VANET 50003 # UDP port VANET DFL_UDP_PORT_SCENTER 50011 # UDP port safety center DFL_UDP_PORT_DBS 50002 # UDP port dynamic blackspot DFL_UDP_PORT_RWP 50002 # UDP port road work presence DFL_UDP_PORT_DATEX 50012 # UDP port traffic control center datexII DFL_SOAP_PORT_RAWDET 8080 # UDP port traffic light controller, raw detector data DFL_SOAP_PORT_AGGDET 8080 # UDP port traffic light controller, aggregated detector data DFL_SOAP_PORT_STATUSTL 8080 # UDP port traffic light controller, states traffic lights # IRIS interface DFL_IP_ADDR_IRIS "0.0.0.0" # IPv4 address DFL_UDP_PORT_IRIS_TRAJ 50901 # UDP port number trajectories DFL_UDP_PORT_IRIS_PED 50902 # UDP port number pedestrian detectors DFL_UDP_PORT_IRIS_TL_STATE 50903 # UDP port number traffic light states # Some algorithm related parameters OM_ALGORITHM 1 # Number of object matching algorithm to be used # Absolute position of the laser scanner in degree POS_LASER_LONG 7.477975 # longitudinal in degree POS_LASER_LAT 51.514575 # lateral in degree # Local area of the RSU defined as rectangle (should be inside the short-range communication area) CLIP_TL_LONG 7.4766965 # rectangular clipping range top left longitudinal in degree CLIP_TL_LAT 51.5157265 # rectangular clipping range top left lateral in degree CLIP_DR_LONG 7.4794865 # rectangular clipping range down right longitudinal in degree CLIP_DR_LAT 51.513112 # rectangular clipping range down right lateral in degree # Presence of trajectory related sensor subsystems that are connected to DFL SEN_VEH_VANET 1 # 1=VANET messages will be received SEN_LASER 1 # 1=laser scanner messages will be received SEN_CAMERA 1 # 1=camera (living, moving or ice) mess. will be received SEN_TLC_RAWDET 0 # 1=raw detector data will be received from TLC # Presence of other sensor subsystems / gateways that are connected to DFL SEN_TLC_TLIGHTS 0 # 1=traffic light states to be received from TLC SEN_TLC_RAWDET 0 # 1=agg. detector data to be received from TLC SEN_TLC_AGGDET 0 # 1=agg. detector data to be received from TLC SEN_SCENTER 0 # 1=data to be received from safety center # Sensor info: frequencies, variances, penetration rates FREQ_LASER 12.5 # in Hz as float (max. 12.5 Hz) FREQ_VANET 2.0 # in Hz as float (max. 2 Hz) FREQ_CAMERA 2.0 # in Hz as float (max. 2 Hz) FREQ_RAWDET 2.0 # in Hz as float (max. 2 Hz) VAR_LASER 0.1 # normal distribution variance in meter VAR_VANET 0.5 # normal distribution variance in meter VAR_CAMERA 1.0 # normal distribution variance in meter PENETRATION_LASER 100 # penetration rate in % as integer (currently not used) PENETRATION_VANET 100 # penetration rate in % as integer (currently not used) PENETRATION_CAMERA 100 # penetration rate in % as integer (currently not used) # LDM related parameters LDM_USE 1 # Flag: shall DFL use the LDM database? LDM_INI_FILE "ldm_sl.ini" # LDM database ini file (ldm.ini or ldm_sl.ini) LDM_DB_TYPE "SL" # PG=postgres, SL=SQLite




INTERSECTION_ID 1 # 0 = no intersection LDM_APP_RELEMENT_1 "20" # id of the 1. approaching road element of the intersection LDM_APP_RELEMENT_2 "69" # id of the 2. approaching road element of the intersection LDM_APP_RELEMENT_3 "26" # id of the 3. approaching road element of the intersection LDM_APP_RELEMENT_4 "28" # id of the 4. approaching road element of the intersection LDM_APP_RELEMENT_5 "" # id of the 5. approaching road element of the intersection LDM_APP_RE_DIRECTION_1 1 # direction of app. road element vector: 1=towards intersection, 0=away from intersection LDM_APP_RE_DIRECTION_2 0 # direction of app. road element vector: 1=towards intersection, 0=away from intersection LDM_APP_RE_DIRECTION_3 0 # direction of app. road element vector: 1=towards intersection, 0=away from intersection LDM_APP_RE_DIRECTION_4 0 # direction of app. road element vector: 1=towards intersection, 0=away from intersection LDM_APP_RE_DIRECTION_5 0 # direction of app. road element vector: 1=towards intersection, 0=away from intersection LDM_DEP_RELEMENT_1 "61" # id of the 1. departing road element of the intersection LDM_DEP_RELEMENT_2 "65" # id of the 2. departing road element of the intersection LDM_DEP_RELEMENT_3 "26" # id of the 3. departing road element of the intersection LDM_DEP_RELEMENT_4 "28" # id of the 4. departing road element of the intersection LDM_DEP_RELEMENT_5 "" # id of the 5. departing road element of the intersection LDM_DEP_RE_DIRECTION_1 0 # direction of dep. road element vector: 1=towards intersection, 0=away from intersection LDM_DEP_RE_DIRECTION_2 0 # direction of dep. road element vector: 1=towards intersection, 0=away from intersection LDM_DEP_RE_DIRECTION_3 1 # direction of dep. road element vector: 1=towards intersection, 0=away from intersection LDM_DEP_RE_DIRECTION_4 0 # direction of dep. road element vector: 1=towards intersection, 0=away from intersection LDM_DEP_RE_DIRECTION_5 0 # direction of dep. road element vector: 1=towards intersection, 0=away from intersection # Object Matching Parameters DFL_OM_ALPHA 0.6 # algorithm parameters (don't change) DFL_OM_EPSILON 0.000027 # algorithm parameters (don't change) DFL_OM_C 1.0 # algorithm parameters (don't change) # Parameters for computation of fused trajectories DFL_FT_WITH_PROJECTION 1 # project points that are off the road back to the road frontier DFL_FT_CONSIDER_SPEED 1 # use speed info to adjust trajectory points # Which modules shall be active? DFL_OBJECT_REFINEMENT 1 DFL_TRAJ_PREDICTION 0 DFL_MAPMATCHING 1

Some examples for typical configurations Postgres database (Dortmund): # LDM related parameters LDM_USE 1 LDM_INI_FILE "ldm.ini" LDM_DB_TYPE "PG" INTERSECTION_ID 61 LDM_APP_RELEMENT_1 "702760065225084" LDM_APP_RELEMENT_2 "702760048118031" LDM_APP_RELEMENT_3 "702760065225082" LDM_APP_RELEMENT_4 "702760065225085" LDM_APP_RELEMENT_5 "" LDM_APP_RE_DIRECTION_1 1 LDM_APP_RE_DIRECTION_2 1 LDM_APP_RE_DIRECTION_3 1 LDM_APP_RE_DIRECTION_4 0 LDM_APP_RE_DIRECTION_5 0 LDM_DEP_RELEMENT_1 "702760065225091" LDM_DEP_RELEMENT_2 "702760048118043" LDM_DEP_RELEMENT_3 "702760065225082" LDM_DEP_RELEMENT_4 "702760065225085" LDM_DEP_RELEMENT_5 "" LDM_DEP_RE_DIRECTION_1 0 LDM_DEP_RE_DIRECTION_2 0 LDM_DEP_RE_DIRECTION_3 1 LDM_DEP_RE_DIRECTION_4 0 LDM_DEP_RE_DIRECTION_5 0




The postgres “ldm.ini” file is also in the “config” directory. Example: 127.0.0.1 5432 LDM_Dortmund_New postgres postgres

SqLite database (Helmond): # LDM related parameters LDM_USE 1 LDM_INI_FILE "ldm_sl.ini" LDM_DB_TYPE "SL" INTERSECTION_ID 101 LDM_APP_RELEMENT_1 "20" LDM_APP_RELEMENT_2 "69" LDM_APP_RELEMENT_3 "26" LDM_APP_RELEMENT_4 "28" LDM_APP_RELEMENT_5 "" LDM_APP_RE_DIRECTION_1 1 LDM_APP_RE_DIRECTION_2 0 LDM_APP_RE_DIRECTION_3 0 LDM_APP_RE_DIRECTION_4 0 LDM_APP_RE_DIRECTION_5 0 LDM_DEP_RELEMENT_1 "61" LDM_DEP_RELEMENT_2 "65" LDM_DEP_RELEMENT_3 "26" LDM_DEP_RELEMENT_4 "28" LDM_DEP_RELEMENT_5 "" LDM_DEP_RE_DIRECTION_1 1 LDM_DEP_RE_DIRECTION_2 0 LDM_DEP_RE_DIRECTION_3 0 LDM_DEP_RE_DIRECTION_4 0 LDM_DEP_RE_DIRECTION_5 0

The sqlite “ldm_sl.ini” file is also in the “config” directory. Example: [NQ_CLIENT] Server=127.0.0.1 Port=3333

No trajectories (only event messages shall be written into the LDM): DFL_OBJECT_REFINEMENT 0 DFL_TRAJ_PREDICTION 0 DFL_MAPMATCHING 1




5.2.5. DFL –Results and LDM Handling Following table provides an overview of the LDM content in which the results of the fusion processes and the data provided data by the sensors and gateways are stored.

UDP Message / Data Sources / Fusion Process LDM table Data Sources (without further fusion) CameraIceDetection - roadconditionevent CameraMeteoConditionDetection - meteodetection

CameraNumberPlateDetection

- from <-> motorvehicle/geom - unNumber <-> motorvehicle/goodstype

Gateways StatusTrafficLight&PedestrianDetector - signalgroupstate AggregatedRoadDetectorData - dynamicsensorattributes RawRoadDetectorData - dynamicsensorattributes

SafetyCenterInformation

- accidenthotspot - environmentalevent - trafficevent - gatewaycommunication

InfrastructureWeatherStation - environmentalevent InfrastructureDBSInformation - dynamicblackspot

DatexIIMessage

- DatexIIWeatherInformation <-> environmentalevent - DatexIIRoadConditionInformation <-> roadconditionevent - DatexIISpeedLimit <-> dynamictrafficsigninformation - DatexIIObstacleWarning <-> trafficevent

RoadWorkPresence - trafficevent (eventcause) Moving objects (after object matching) VanetBeaconFromVehicle - motorvehicle CameraObjectDetection - motorvehicle LaserSensorObjects - motorvehicle Moving objects (after map matching) result of map matching and manoeuvre estimation - alongroadelement Moving objects (after trajectory prediction – IRIS) result of trajectory prediction - trajectory

Table 3: LDM tables storing the results of the fusion processes The objects stored in the LDM are handled in the following way:

- data related to moving objects will be updated as soon as new information is available and as long the moving object is in the area of the RSU

- all other data is updated as soon as new information is available. The DFL does not maintain the LDM data base and remove objects, except moving objects. This because the DFL has no knowledge of constraints which determine when to eliminate e.g. a traffic event.




6. Situation Refinement Modules The modules belonging to the Situation Refinement process fall into several different categories, i.e. those dealing with: vehicle-related information, traffic-related information, environmental information, and black spot recognition (safety) information. They are described below.

6.1. Vehicle-related information

6.1.1. Manoeuvre estimator This module has calculates the likely future driving manoeuvre (straight on, left or right turn) of a vehicle which has been detected at an intersection. A given probability is assigned to each manoeuvre. The module is an essential part of the SP5 IRIS application on the SP2 data fusion side. The details required for its installation and set up have already been described in section 5.2, as it is part of the Data Fusion Logic.

6.2. Traffic-related information

6.2.1. Traffic Data Calculator This module has the purpose of calculating traffic parameters for specified road segments. The calculation is mainly based on data coming from fixed sensors. The results generated will be used by the incident detection module (ECAID). However, the input data (sensor data) as well as the calculated traffic data will be stored in the LDM, where this module will pull the required data for its procedure and write the results back into the LDM. Developer: TUM Language: Java Memory required: 4MB are needed on the disk plus the space necessary for the installation of Java Version 1.6. The runtime memory is 100MB RAM. Manual or guidelines available: Module software and installation instructions on SAFESPOT server: http://bscw.safespot-eu.org/bscw/bscw.cgi/221464 Installation details: The Java Runtime Environment needs to be installed to run the traffic data calculation module. To install the traffic data calculation module the user shall




• Decompress the files into the wished folder

• Configure the properties-files

• Start the program by executing run.bat/run.sh Input data: Input data is traffic data coming from different data sources (number of vehicles, speed of vehicle(s)) for each sensor /detection area read each step from the LDM. Output data: Output data are traffic parameters (flow, speed, density) for each road section written into the LDM to provide input data for ECAID. Relationship with other modules (data source and destination): The module traffic data calculation uses traffic data, which is provided by roadside sensors and written into the LDM. This input data is read from the LDM. The generated traffic parameters are returned to the LDM and there available for further modules (e.g. ECAID) (see figure below).

Figure 9 – Data flow from sensors via the LDM, traffic data calculation to ECAID

Other information: Following picture depicts density, speed and flow for each segment and time step. The graphs show that the simulation tool has to run several time steps before getting robust results.




Figure 10 – TDC: Display of traffic parameters (example: simulated data)

6.2.2. ECAID: Extended Cooperative Automatic Incident Detection The purpose of this module is to recognise dangerous situations (e.g. stationary or slow vehicles, e.g. caused by congestion or accidents) through the analysis of traffic patterns along a motorway. The system makes use of the traffic parameters produced by the SAFESPOT subsystem, the Traffic Data Calculator, on the basis of the data sent by the available traffic sensors, either fixed (roadside sensors) or mobile (probe vehicles). Developer: CSST Language: Python Memory required: 4MB are needed on the disk plus the space necessary for the installation of Python 2.5 (already present with the default installation of Linux Ubuntu). The runtime memory footprint is 6MB RAM. Manual or guidelines available: Module software and installation instructions on SAFESPOT server: http://bscw.safespot-eu.org/bscw/bscw.cgi/215451 Installation details: To install the ECAID module the user shall decompress the file ECAID-1.0.0.linux-i686.tar gz into the installation folder (es. /home/ecaid). The configuration of the file named ecaid.ini, containing the following parameters, is then required:

• Connection string to the LDM database

• Road topology

• Interval (in seconds) between each step




Input data: Input data are traffic parameters (flow, speed, density) for each road section read each step from the LDM. Output data: Traffic events written in the LDM: for each road section and each step of elaboration ECAID supplies the information of incident presence / absence. Relationship with other modules (data source and destination): ECAID uses, as an input, the traffic parameters values (flow, speed, density) available in LDM, provided by the data fusion module TDC.

Figure 11 – Traffic information data flow from sensors to ECAID incident alarm

Other information: Graphical User Interface The ECAID module is a console process that can be configured to run without output to the screen, like Unix daemons. A simple Graphical User Interface was developed in python in order to plot the inputs and outputs involved. In the following picture the algorithm signal is plotted in red, the average traffic speed in blue, the traffic density in yellow.




Figure 12 – ECAID Graphical User Interface

The GUI acquires data from ECAID by means of a TCP connection and therefore can be used from any pc connected to the RSU.

6.2.3. Traffic Event Calculator The TEC Module is an application developed to watch the traffic event records of the LDM database. If a new traffic event is added, the TEC module will look for other traffic events with the same event cause and create a copy of the most reliable. This record is called a “consolidated” traffic event. It will have the same id and will keep the link to ConceptualAlongRoadElement table. In order to complete the outputs (average section speed, average section density, and statistical information) provided by TDC “Traffic Data Calculation” module, it is necessary to consider inputs related to the traffic event provided by other modules: SP2 sensors, ECAID, traffic and safety centres, and the SMAEV1 HMI. Consequently, the principal aim of the TEC “Traffic Event Consolidator” is to consolidate the information on traffic events and incidents. Developer: SODIT (Contact person: [email protected])

Language: This module runs in the Windows environment.

Memory required: The TEC application uses less than 20MB memory.

SW and guidelines available: Module software and installation instructions

on SAFESPOT server: http://bscw.safespot-eu.org/bscw/bscw.cgi/203111.

Installation details

To install the TEC module, it is necessary to run the setup (SP2-TEC) that will install the program and files. This installation contains an ldmClient.ini file that needs to be configured with the IP address and port number of the LDM database server.




Data input The TEC Module works with the TrafficEvent table; the following fields are used in particular:

Is-raw : 1 - Traffic Event not consolidated. 0 - Consolidated Traffic Event.

Provider :

1 - SMAEV1 2 - Traffic and safety centres 3 - ECAID & SP2 Sensors

The provider SMAEV1, when available, is the most reliable source as it is based on direct evidence of an event, e.g. an accident. ECAID and the SP2 Sensors rely on sensed data or detection algorithms. This field is used during the consolidation process to find the record on which the consolidated one will be based.

Eventcause:

The eventcause and provider fields are used to identify a unique trafficevent.

Relationship with other modules (data sources and destination): The following figure depicts the relationship of the TEC with other fusion components also performing in the field of traffic event consolidation.

Figure 13 – Components involved in the TEC Module

Traffic Event Consolidator

Data from Traffic CentreComing via the Data Receiver

Data from Safety Centre

Coming via the Data Receiver

Sensor Data / FCD via the

Data Receiver

LDM

All the Consolidated Informationconcerning Traffic Event Information

stored in the LDM

Data fromSMAEV1 HMIComing via the Data Receiver




HMI screen This application runs in the background, but an HMI screen is provided to display the consolidation logs.

Figure 14 – TEC module tray icon

This screen is accessible with the “Display” button of a tray icon menu. This menu also contains a button (“Exit”) that closes the TEC module The close button (in upper right corner) of the TEC screen will only hide the window, the application will still be running.

Figure 15 – TEC module tray menu

The TEC module log screen is empty when launched, but waits for new traffic event notifications. When the TEC receives add notifications, it analyses the records and creates (or not) consolidated traffic events in the LDM database. The log of these traffic event consolidations is displayed with their creation time. Users can clear this log with a contextual menu accessible with a right mouse click on the log display area.




Figure 16 – TEC module log screen

6.3. Environmental conditions 6.3.1. Environmental consolidator

Brief description: The purpose of this module is to produce environmental information in the LDM based on the notification of a meteorological event (rain, fog, road conditions) by one or several SP2 sensors. It refines this event, or creates a new event by combining the outputs of the different SP2 sensors. By querying the status of vehicle sensors with respect to their past locations, it is also able to extend or reduce the detection area of this environmental event. Developer: LCPC Language: C++ (Linux Ubuntu 8.04) Memory required: 8MB needed on the disk. The runtime memory footprint is negligible. Manual or guidelines available: no official documentation has been released. When the final software is available for installation with the NAVTEQ LDM, a manual will be posted on the SAFESPOT server. (The current prototype version has been developed for use with the TA LDM).




Installation details: This installation contains an ldm.ini file that needs to be configured with the IP address and port number of the LDM database server. Input data:

- ‘CCTV for Visibility’ camera - Infrastructure weather station - Fog lights status of SAFESPOT vehicles - Wipers status of SAFESPOT vehicles

Output data: - Environmental events written in the LDM.

Relationship with other modules (data source and destination):

Figure 17 – Integration of Environmental Consolidator with other modules

Other information: There exist a very large number of potential situations to ‘refine’. In order to demonstrate this module, software development has been restricted to the Use Cases demonstrated in the West Test Site, i.e. rain and fog presence.




6.4. Safety-related information

6.4.1. Dynamic Black Spot Recognition The objective of this module is to identify Dynamic Black Spots on motorways, and inter-urban or rural roads. The calculation is based on data coming from SAESPOT sensing systems and applications as well as on external sources, such as accident databases, the police and infrastructure operators. All data – static and dynamic – used by the algorithm is provided through the LDM. The output of the Dynamic Black Spot recognition algorithm is written into the LDM. Developer: PTV Language: Java, required version 1.6 Memory required:

- ~ 20 MB of runtime memory - ~ 80 MB of disk space (for installation including required space for Java

Manual or guidelines available: Module software and installation instructions are provided on the SAFESPOT server, together with the most recent version of the binaries and configuration files. Installation details: The Java Runtime Environment needs to be installed to run the traffic data calculation module. It is part of the CVIS Linux distribution. To install the dynamic black spot recognition module the user shall

• Install the most recent version of the FOAM SDK (V 1.5 minimum)

• Add a reference to startDBS.xargs to init.xargs, i.e. the following line: -initlevel 10 -xargs startDBS.xargs

• The service will start automatically on the next startup of the Knopferfish framework, with the following command java –jar framework.jar –init

Input data: Input data is coming from different data sources like SAFESPOT sensing systems providing weather information like rain/hail, surface information like ice and information about the visibility like fog as well as the input from other SAFESPOT applications providing information about ghost drivers and obstacles on road and last not least external sources, such as accident databases, the police and infrastructure operators. All this data is read from the LDM.




Output data: The output of the Dynamic Black Spot recognition algorithm is the localisation of areas in the road network with a certain level of risk for the road user. The output data is written into the LDM. Relationship with other modules (data source and destination): The module the dynamic black spot recognition uses sensor data which is provided by roadside sensors, traffic data which is provided by other SAFESPOT modules and written into the LDM. This input data is read from the LDM. The generated risk level for are returned to the LDM and there available for further modules (see figure below).

Figure 18 – Data Flow from external sources and sensors via LDM for Dynamic Black

Spot Recognition

Other information: None.




7. Roadside Sensing and Warning Systems This section consists of a set of data sheets which describe the basic features of the roadside sensing systems interfaced with the INFRASENS Platform. The majority of these are existing technologies. The Wireless Sensor network (WSN) which also incorporates a warning system, is a prototype and has therefore been described in greater detail.

7.1. CCTV for ice and wet road detection

CCTV SYSTEM FOR ICE AND WET ROAD DETECTION

Partner responsible: VTT Technical Research Centre of Finland

HARDWARE DESCRIPTION The road state monitoring system has been developed by VTT in order to provide slippery road information to the co-operative SAFESPOT infrastructure system.

The components included by the icy/wet road detection system are:

• Two cameras with the Micron MT9V022 Automotive design CMOS imager. The cameras (STH-DCSG) were bought from the Videre Design LLC company from U.S.A

• IEEE 1394, FireWire cables, 10 m • IEEE 1394 PCI Host Interface Board • Two NIR Polarizers 750-800 nm from Edmund Optics Ltd. • Ernitec CHN-350M, IP67 camera housing with heating element • Mini-PC computing unit

COSTS AND LICENSES Total cost of system: 2600 Euro

The machine vision based analyzing software has been developed by VTT. The software runs in the Microsoft Windows XP operating system. Thus, the project partners do not need to pay any reimbursements to use it.




The software driver for capturing images from Videre Design LLC. cameras, is accompanied by the camera procurement and is royalty free.

SENSING AREA AND CHARACTERISTICS

The system is able to detect area which corresponds approx. two lanes in a road. The sensed area is about 8 m width and 25 m height when the camera is tilted.

DATA OUTPUT WRITTEN ON LDM (AFTER DATA FUSION) The system output is available via an Ethernet interface or optionally a CAN bus can be activated. The output message includes five different status categories:

• icy road • snowy road • wet road • dry road • unknown

The output message also contains confidence value of the detection result to be used by the data fusion modules. The location field of the output message gives centre position of the detected area in GPS latitude and longitude coordinate values. Time stamp defines the detection moment in seconds and milliseconds. All the messages are tagged with a specific number code in order to identify the sensor connected to the traffic data controller and camera ID tells which of the cameras is sending the message. The messages are sent only when a change in road condition is detected.




INSTALLATION

The camera system has to be installed 3-5 metres above ground. The image analysis software can be configured to run on side or above of the road.

Cabling

A cabin is needed for installing a computer unit and it should not locate furhter than 60 m away from the camera (max. FireWire cable length is 72 m). The cabin must be enclosed against rain and dust and temperature must remain above -10 °C.

The road state monitoring PC is connected to the roadside Main PC with an Ethernet cable.

Power supply The camera enclosure requires 230 V power supply to available for heating as well as the computer unit in the road side cabin.

Remote diagnostics The system provides an opportunity to remotely supervise when internet connection is available. The connection is highly preferred since it allows system adaptation and failure analysis to be done remotely from the control centre.

CONSTRAINTS

According the evaluation the system is effective only on daytime. Moreover, the performance of the ice and snow monitoring is better than wet road detection.




LOCATION

The system is implemented to the Swedish test site as a main infrastructure side component. The slippery road data will be sent to the vehicles via V2I communication channel.

Table 4: CCTV for ice and wet road detection




7.2. Thermal camera for living object detection

THERMAL CAMERA FOR DETECTION OF ANIMALS AND PEDESTRIANS

Partner responsible: VTT Technical Research Centre of Finland

HARDWARE DESCRIPTION

The application monitors living obstacles on a road. In addition, the system can be used to detect passing vehicles.

The hardware components of the implemented pedestrian/animal detection system are:

• Thermal imaging camera, FLIR Systems ThermoVision A20-M • IEEE 1394, FireWire cable, 4,5 m • IEEE 1394 Host Interface Board, PCI • Heated GHKit-230, IP67 class camera housing • Standard office-PC for executing image analysis

COSTS AND LICENSES

Total cost of system is about 6000 Eur




The software for video acquisition, detection and GUI has been developed by VTT in the SAFESPOT project and the video acquisition uses FLIR systems SDK which is free of charges when compiled to distribution mode. Hence there are no additional software costs for deploying the system among the SAFESPOT consortium.

DATA OUTPUT WRITTEN ON LDM (AFTER DATA FUSION)

The output of the system is written to the Ethernet interface:

• no objects detect

• animal

• pedestrian

• vehicle

When an object has been detected the system sent to the centre position of the object in the WGS-84 coordinate system.

For the data fusion modules also the confidence level of the object detection is applied.

INSTALLATION The camera system has to be installed 3-5 m above the ground. The analysing software can be configured to run on the side or above the road. The output message is available via the Ethernet interface of the data processing PC.

Estimated size of the sensing area covered by the camera system when properly installed is approx 10 x 10 m.

Cabling: The roadside unit is needed for installing the data processing computer unit. The RSU cabin should be located a max. distance of 4.5 m from the camera location. The cabin must be well shielded against rain and dust and temperature must remain above -10 °C. Connection between the data processing PC and the RSU Main PC is done with the Ethernet cable.




Power supply: The data processing PC, heated camera housing and camera needs 230 V power supply.

Remote diagnostics Internet access to the data processing PC is highly recommended since it allows remotely change supervise performance of the system and execute periodic maintenance.

CONSTRAINTS

The system was originally designed to temperature ranges below 25 ºC which is reasonable assumption in Finland. Performance of the system decreases in very hot climate (in the natural human temperature, 37 ºC).

LOCATION

The system will be implemented to the test site in Italy for demonstration purposes as part of the Hazard and Incident Warning COSSIB Application (Torino-Caselle expressway).

Table 5: Thermal camera for living object detection




7.3. RFID system for ghost driver detection

RFID FOR TRAFFIC FLOW DETECTION AND GHOST DRIVER (WRONG WAY DRIVING ) DETECTION

Partner responsible: BME


Antenna RFID Card reader

1. RFID readers (PCMCIA) 2. RFID antennas (both omnidirectional and directed) 3. RFID tags (active tags)

The above is commercially available equipment. The products purchased for SAFESPOT are supplied by Identec.

COSTS AND LICENSES The costs of the equipment (approximate prices in EUR/HUF):

1. Reader: 2.830 EUR (744.096,- HUF) 2. Omni-directional antenna: 830 EUR (217.800,- HUF) 3. Directed antenna: 435 EUR (113.520,- HUF) 4. Active tag: 130 EUR (33.408,- HUF) 5. Passive tag: 54 (13.848,- HUF)

Total cost is approximately 7000 EUR (including 2 readers).

By purchasing the readers, the basic software is included, therefore no specific license is needed. The software used for the Ghost driver detection has been developed for SAFESPOT by BME.





The antenna range is up to 100 m. Antennas are to be put on motorway bridges or on high poses on roadside.


Vehicle passage. Vehicle classification. Presence of ghost driver

INSTALLATION Traffic flow detection:

A single antenna is needed above the lane(s) to be monitored. According to the desired applications the RFID tag IDs should be scanned (e.g. for traffic count) or the data stored in the tags are to be downloaded (e.g. for traffic flow classification).

Ghost driver detection:

In the test site, two RFID readers are to be installed. Each reader connects to a pre-processing PC, the detection algorithm runs on one of the PCs. The result of the detection (Ghost driver alert) is transmitted from the dedicated PC to the RSU.

The Antennas and the PCs must be installed on the roadside in order to ensure the unblocked, open view to the vehicles. Antennas can be mounted also in higher view position, e.g. freeway bridge, poses etc. The pre-processing PCs are to be within 3 meters to the Antennas (limited antenna cable length).

Cabling: The communication between the pre-processing PCs and between the dedicated PC and RSU can be solved either by WLAN or Ethernet cable. WLAN routers can be deployed 100m apart from each other.

Power supply: RFID readers and antennas use the computers’ power supply, no separate power is needed. Routers need 220V.

CONSTRAINTS

Clear visibility between vehicles and antenna has to be ensured. Based on the initial results the Ghost driver detection system detects more than 90% of the ghost drivers. Errors in detection can occur in case of wrong or especially shadowed tags.

In case of applications that require data download from the tags (e.g. traffic flow classification) detection is robust only under certain circumstances (e.g. below particular speed limit), see test and validation results.

LOCATION

Installed in local site (Budapest) for validation and testing purposes. Planned for use in the Italian Test Site (Torino-Caselle Expressway) as part of the Hazard and Incident Warning Application.

Table 6: RFID system for ghost driver detection




7.4. CCTV for visibility assessment

CCTV FOR VISIBILITY ASSESSMENT

Partner responsible: LCPC (France)


The detection system is composed of a roadside camera and of a pre-processing PC. All the hardware components are commercial ones. We have developed software components which enables different simultaneous detections on a single camera which runs on the RT-Maps platform. The latter manages the multi-threading of the different components.

COSTS AND LICENSES Component Recommended

commercial products Cost (€ VAT not included)

Camera pole Petitjean BM 2160 1300 Camera + power outlet Dalsa Genie M1400 1710 4.5 mm lens without auto-iris - 112 Giga Ethernet card (Chipset Intel PRO/1000 GT)

- 98

GigaEthernet Cat.6 cable 10m - 54 Outdoor protection box - 110 Camera driver Sapera LT library 297 Specific software RT-Maps runtime licence 3000 Pre-processing PC Windows XP 1200 Total 7881

A specific licence is needed for the use of this software.

Detection system

UDP messages





The system is normally able to assess the visibility range up to 400m, depending on the road geometry (in particular its gradient). The figure on the right shows the recommended installation scheme of the system.


The output data depends on day-time/night-time use. This is summarised in table below.

Output Day/night Accuracy Reliability Mobilized visibility distance (for vehicle)

Day and night 10% at 400m ++

Meteorological visibility distance

Day 10% at 400m +

Fog detection Day and night Good (day) / (night) N/A

+ (day) / (night) N/A

Rain detection Day N/A N/A INSTALLATION The following factors must be taken into account in the installation of the detection system:

1. To be able to estimate the visibility range until 400m, the road must be in the field of view of the camera until 400m. If the road is in the field of view of the camera until the horizon line, this is much better.

2. The road must be as flat as possible to avoid a strong calibration procedure. 3. The night fog detection and the visibility range estimation by night can operate if

the monitored road section is equipped with a lighting installation. Otherwise, the camera can not operate.

Cabling

The communication between the camera and the pre-processing PC is done using Gigabit Ethernet connection (max length 100m). The communication between the pre-processing PC and the RSU is done using an Ethernet connection (max length 100m).

Power supply

The pre-processing PC and the heated camera housing need 230 V power supply. The




camera needs only 12 V power supply. An external 230V/12V transformer is used to supply the camera.

CONSTRAINTS

Usually, outdoor CCTV cameras are equipped with an auto-iris lens. This device regulates the amount of light entering the sensor to avoid overexposed or surexposed images. The high resolution cameras used for SAFESPOT, however, do not currently have an auto-iris connector, because they are not primarily designed for an outdoor usage. Thus, LCPC has developed software to act on the camera (exposure time and/or gain) to obtain a well exposed image.

The software for daytime visibility range estimation and daytime fog detection for fixed cameras are relatively mature. For night-time fog and rain detection, however, which are new areas, LCPC is prototyping detection algorithms to perform these tasks. At present, for effectively testing these developments, actual fog video sequences are lacking.

For rain detection, LCPC is currently grabbing video sequences. At present it is thus difficult to judge the reliability of this software. Based on first tests, hard rain shower and hail are well detected. Small rain shower may be problematic.

LOCATION

Currently installed in LCPC laboratories for validation and testing. It is planned to use the system for demonstration in the West Test Site in France. The results will be fused with a conventional weather station.

Table 7: CCTV for visibility assessment




7.5. Laserscanner for tracking of road users

LASERSCANNER FOR ROADSIDE USE Partner responsible: IBEO (Germany)




Laserscanner PC

(for cooperativepre-data fusion)

INFRASENS-System

- LDM (incl. static map)- VANET system- Data Fusion system

Legend: Arcnet EthernetLegend: Arcnet Ethernet

1. Alasca XT Laserscanners, commercially available at Ibeo Automobile Sensor GmbH

2. For each Laserscanner, one ECU (built and available from Plug-In GmbH).

3. The same HW used for the ECUs is also used for the Laserscanner PC perfoming the Cooperative Pre-Data Fusion

4. Any commercial 100Mbit/s Ethernet switch is required to connect the ECUs and the Laserscanner PC

5. One housing per Laserscanner (see below)

Required mounting bolts:




COSTS AND LICENSES

Per ECU/ Laserscanner:PC: 1298,- €

Per Laserscanner: - currently: 4504,-€ - series production as of 2012: about 980,-€

Used switch: 150,-€

Laserscanner housing: 2535,-€

The necessary software has been developed by IBEO for the SAFESPOT project. Project partners therefore have the right to use the analyzing executable without reimbursements.


The maximum detection range of a single sensor system is 200 metres. The maximum field of view has an opening of 240° (-120°..120°). Intelligent arrangement of multiple Laserscanners increase the field of view and minimizes the size of occluded areas.


Relative position, velocity, classification, dimension and orientation of road users: vehicles/pedestrians.

INSTALLATION Typical applications of the Laserscanner system are at traffic junctions. In case of a typcial four armed junction, two Laserscanner (and their ECU) can be used simultaneously, installed on opposite corners of the intersection in order to detect, track and classify road users in the vicinity of the intersection. The scanners have to be mounted in robust housings on solid platforms (e.g. on the sidewalk). Due to their price and sensitivity, the scanners need to be protected against theft, dust and weather conditions, as well as the risk of being hit by vehicles. The switch as well as the Laserscanner PC need to be installed into a central housing containing other INFRASENS components such as the Main PC.

Power supply: Each element needs a separate power supply by the infrastructure:

• 12V per “Laserscanner + ECU” component

• 12V for the Laserscanner PC

• 12 V for the switch

Cabling: As described above, the “Laserscanner + ECU” components as well as the Laserscanner PC are connected to a switch via Ethernet. The Laserscanner PC is also connected to the SAFESPOT system.

Mounting: Each “Laserscanner + ECU” unit needs to be mounted on 4 bolts fixed to the surface of e.g. sidewalk.




CONSTRAINTS

With larger intersections, more Laserscanners might be needed to reduce a drop in performance by increasing occlusions. As this is foreseen, it is currently planned to install 4 Laserscanners at the TS-Dortmund.

As the Laserscanners need to be connected via Ethernet, it is required to have access and permission to use the cable ducts at the intersection. Furthermore, the installation of the mounting bolts shall be performed/ authorized by the local authorities/ Test-Site leaders.

LOCATION

The system has been set up for validation purposes at a medium-sized intersection in Hamburg. It is planned to install a 4-scanner system in Dortmund (German Test Site) until the end of 2008 and an implementation at an intersection in Helmond for the demo in May 2009.

Table 8: Laserscanner for tracking of road users




7.6. CCTV for vehicle positioning

CCTV FOR VEHICLE POSITIONING

Partner responsible: CIDAUT (Valladolid, Spain)


• CAMERAS x4:

- Output data: Voltage 1.0V [p-p] PAL / CCIR – Composite 75 Ω / BNC connector.

- Refresh: Horizontal 15,625 KHz Vertical: 50 Hz

- Resolution: Horizontal: 540 lines Vertical: 480 lines.

• Optics: 2x Varifocal, 2x fixed focal length: 14” and 16” • Mounting pole. 15m height. • PC1: PIV 1.6 GHz, 1Gbyte Ram, 19” Rack Outdoor: +50 ºC, -10 ºC, PCI cards,

Ethernet • Electrical Cabinet • Digital Video Recorder. Camtronics. 8x video inputs (used only for logging

purposes, no need for the processing)

COSTS AND LICENSES

All devices are commercially available.

Cost estimation. Full systems > 30 k€, including installation. Due to the high cost, Motion Detection System is intended for already installed systems.


Each camera can cover up to approx 100 metres of road section, providing the right optics and positioning is chosen.


Position of vehicles relative to the pole (example: x: +125 m, y: -5 m) and geocoded (Latitude, Longitude).

Speed of vehicles: IS units (example 15 m/s, heading: 15ºN, 12ºW).

INSTALLATION

The location of the camera is important due to the constraints of the optics. The higher the range to be covered by the camera, the lower the quality of the images at a long distance. It is therefore necessary to locate the camera so that the whole zone of interest is monitored and produces good quality images.




It is recommended that the camera is installed in a high position (15 m is a standard), and with the least perspective possible. When the optics have been chosen and the camera located, it is necessary to calibrate the scene, taking several points of the geometry of the road to correlate these points with the coordinates in the image.

The processing unit needs 220V AC power supply, and connects to the cameras via coaxial cable. The cameras themselves need 12V DC supply.

CONSTRAINTS

The calibration process is complex, therefore setting up the system in new locations for demonstrations could require considerable time.

The cameras does not have the necessary sensititivity to work at night, so the system us offline under this conditions. Other meteorological conditions that affect visibility also diminish the performance of the system.

The system is foreseen for interurban roads junctions with low to medium traffic density. In urban scenarios with high density traffic conditions, the performance is too low to be effective.

LOCATION

Currently installed. for demonstration purposes, at an intersection near Valladolid in Spain which is one of the West test Site locations.

Table 9: CCTV for vehicle positioning




7.7. Wireless Sensor Network (WSN) General description The objective of the WSN system is to provide a way of acquiring traffic data which can be used to detect safety-critical situations consisting of ‘obstacles’ on the road such as accidents, slow-moving traffic, and “ghost drivers”, i.e. vehicles travelling in the wrong direction.

The aims were to develop a system which:

- is low cost and also has low maintenance requirements;

- achieves greater precision than conventional systems with regard to the longitudinal location of obstacles on the road, as well as faster and more reliable detection;

- can operate in a wireless mode (i.e. without cabling);

- can also integrate data from equipped vehicles (via the VANET);

- can be interfaced with the ECAID modules.

It is foreseen that the WSN could be installed on inter-urban roads or motorways with fast flowing traffic where the rapid detection of the presence of obstacles on the road and the possibility of sending an immediate warning to the drivers of approaching road users is extremely important for safety reasons.

The Wireless Sensor Network system has been designed and developed jointly by Mizar Automazione and ISMB (in the TRM and Chilab laboratories). ISMB developed the signal acquisition HW and processing prototypes and interfacing solutions (three different versions) and SW (that runs on the TinyOS operating system) necessary to create the wireless network. The role of Mizar was to develop the Local Detection Algorithms, i.e. the software able to process the signals produced by the sensors and derive information on passing vehicles (speed and direction).

Sensing nodes As indicated below, the network consists of 10 sensing nodes and a gateway. The sensors are mounted on a Base Board each of which consists of an Anisotropic Magneto-Resistive (AMR) and a Pyroelectric (Pyro) sensors and the conditioning circuitry. The Base Board collects the analogue signals coming from the Sensor Boards, converts them into digital information, stores it in a memory and processes it with a Local Detection Algorithm (FW_LDA).

Figure 19 – Scheme of the Wireless Sensor Network system




The network The nodes and the gateway node are installed along a road section and therefore have a linear topology. The distance between any two adjacent nodes must be below a maximum distance, which depends on multiple factors:

• The node’s transmission power (typically set to the maximum, 0dBm)

• The antenna range

• The position and environment in which the nodes are deployed

The distance adopted for the current prototype implementation is 25m. The figure below shows two networks, one on each side of a two-way road section.

Figure 20 – Layout of two Wireless Sensor Networks, on a two-way road section

Sensor Node 1

Sensor Node 2

Gateway

Sensor Node n

Sensor Node k-

sn3+GN-RSU

sn1

sn9sn8 sn7 sn6

sn5

sn4

sn2

sn11

sn19 sn18 sn17

sn16

sn15

sn14

sn12

sn13




Networking process The nodes communicate with each other by a multi-hop technique to send the data to the RSU. The network is self-configurable. Nodes can be added to the network (or substituted) or avoided in the case of damage or malfunctioning.

Path redundancy and communication reliability can be obtained choosing node deployment and inter-node distance in such a way that the radio coverage of a node includes more than a single node in each direction. Two nodes therefore do not need to be within direct radio range of each other to be able to communicate.

Polling is carried out every 5 secs (the Gateway node sends a request for data to each sensing node). The technique means that data is not necessarily sent to the gateway in the same order. An algorithm in the RSU makes it possible to ‘reorder’ the data before further processing.

The illustration below shows only three nodes, but the same principle applies to the whole network.

Figure 21 – Self configuration for the Wireless Sensor Network




Software components The software components (FW = firmware) developed are as follows:

• FW_D This driver manages all the node resources, such as memory, converter and especially the interfaces with both the FW_LDA and the FW_AS.

• FW_AS The serial application manages the sensor - radio modules interface.

• FW_AR The radio application is installed into both the SNs and the GN. It manages ‘get’ and ‘put’ data requests.

• FW_C The communication firmware is able to manage the node-to-node and node-to-gateway communication.

• FW_DR The driver able to acquire the data coming from the network. Moreover this FW could apply a General Detection Algorithm.

• FW_LDA (Local Detection Algorithm) The Local Detection Algorithm is integrated within each sensor node. It processes the raw data coming from sensors. The process is carried out by two Signal Status Machines (SSM) which analyse the signals acquired by each node. The first stage determines the signal status:

• Stable (no vehicle detected); • Growing signal; • Decreasing signal.

The second stage analyses the results of the last two categories to calculate the direction and speed of the vehicle by calculating.

– Space = distance between measurement points; – Time = difference between samples of a same status

transaction between the signals of the first and second sensor. In the RSU further stages of processing are undertaken: Map Matching: to enable the geo-referencing of the obstacle detected Object Refinement: this is necessary when a given application involves the installation of other systems, e.g. the RFID and the IR systems (used for vehicle passage/ghost driver and pedestrian detection respectively). ECAID: this Situation Refinement module processes the data on vehicle speed and direction to detect the occurrence of an incident (accident or other interruption to the traffic flow).




Integration of LED warning lights

The following illustration shows the LED warning light which is integrated in the sensor ‘box’ mounted on the roadside barrier. There is one on each side of the box in order to be visible to vehicles travelling in each direction. They operate on flashing mode when an obstacle is detected.

nodo1

nodo2

Figure 22 – LED warning system for the adopted Wireless Sensor Network system




WIRELESS SENSOR NETWORK FOR VEHICLE COUNT AND PASSAGE Partner responsible: ISMB/MIZAR

HARDWARE DESCRIPTION The hardware consists of

• Sensor nodes (sn)

• A Gateway Node (GN)

An host PC, the RSU (Road Side Unit).

(See figure above)

Every sensor node is composed of three devices: two sensor device (sd) each one containing two sensors (a pyrometer and a magnetometer), and the base device (bd) both for collecting and elaborating data and for communicating with other elements of the network. Communication among sensor nodes and the gateway node is based on a multi-hop scheme finally delivering traffic data to the RSU. The network is self-configurable: at any time nodes can be added to or removed from the network (or even replaced: for instance, in case of damage or malfunctioning).

COSTS AND LICENSES

Not a commercial product (prototype developed by ISMB and MIZAR).

No license is needed for use of prototype version for SAFESPOT.


Sensing nodes and the gateway node are deployed along the road section under monitoring, thus they result in a linear topology. In order not to have the network completely disconnected, the distance between any two adjacent nodes must be below a maximum distance, which depends on multiple factors:

• Node transmission power (typically set to the maximum, 0dBm)

• Nodes antenna features

• Nodes position and environment in which nodes are deployed

In addition, path redundancy and communication reliability can be obtained choosing node deployment and inter-node distance in such a way that the radio coverage of a node includes more than a single node in each direction.


Vehicle count, speed and direction.




INSTALLATION

Typical installation foreseen is on a motorway or inter-urban road. The nodes required to cover the monitored area must be a distance of 14-40 metres.

Two nodes do not need to be within direct radio range of each other to be able to communicate. In general system should be mounted on the roadside close to the overtaking lane. The nodes need a physical support, e.g. roadside barrier. See diagram below for further indications.

Power supply: Each sensor node needs a DC stabilized Power supplier 8-15V, 100mA.

Cabling: Concerning the Italian Test Site the installation of supply cable and of an additional DC power supplier (30W, 15V, stabilized) is foreseen in order to continuously guarantee the requested amount of energy during the 1-year period of extensive measures and tests.

CONSTRAINTS

No specific constraints reported.

Daytime/night time.

Type of road (no of lanes)

LOCATION

Installation on CRF Test Track for demos in May 2008 consists of 3 sensing nodes with autonomous power supply (batteries) plus the gateway node connected to a PC also powering it.

Permanent test sites: Torino-Caselle link road and Brescia-Padova motorway.

Table 10: Wireless Sensor Network for vehicle count and passage




8. Conclusions The development work carried out by INFRASENS in Workpackage 2.4 has resulted in the implementation of a large number of software prototypes, i.e. the modules which carry out all of the data processing steps required by the Infrastructure Platform. These fit within the underlying physical and functional model which was already defined in an earlier stage of the project. One of the most demanding and innovative aspects of this work concerned the definition of the data fusion process, which involved the refinement of data from many very different sources. This required the fusion of conventional, non-conventional and measurements from roadside sensing systems, as well as data from static and mobile sources. A further important and critical part of the work consisted in the integration of the key components of SAFESPOT developed by the SINTECH subproject: the VANET and the LDM. After the conclusion of the test and validation phase (Workpackage 2.5), these elements are available for the integration within the SAFESPOT Applications (CoSSIB and SCOVA) in the different Test Sites. All of the SAFESPOT Test Sites are intending to implement the INFRASENS platform, though with numerous variations, since the applications foreseen require different data sources and therefore different sensing systems and different processing modules. In some cases the data input will be provided by external systems, but thanks to the gateways which have been implemented, can still be ‘acquired’, validated and processed by the Platform so it can be written on the Local Dynamic Map and made available to the applications. The variety of the implementations being planned illustrates the flexibility of the Infrastructure Platform and its ability to provide a reference framework which is highly adaptable. This is crucial not only in the context of the SAFESPOT project, but also for potential future deployments. An illustration - from the point of view of the infrastructure - of the proposed demonstrations of the SAFESPOT concept in the test sites (in Germany, the Netherlands, Sweden France and Italy), are provided in Annex 1. These show the INFRASENS modules which will be involved in each application.




References [1] SAFESPOT deliverable, INFRASENS, D2.3.2 Final Report: Specifications

for Infrastructure-based Components, Sept 2007. [2] SAFESPOT deliverable, SCOVA, D4.3.5 On-Vehicle diagnostics and

monitoring specification, March 2008. [3] SAFESPOT document, SCORE, SF_SP7_Data_format&messages,

version 2.14, February 2008. [4] SAFESPOT document, SINTECH, D3.3.4 Vehicular Ad Hoc Networks

Specifications, November 2007. [5] SAFESPOT document, SINTECH, D3.3.3 Local Dynamic Map

Specification, April 2008. [6] SAFESPOT document, SINTECH, D3.4.2 Router Hardware Specification,

March 2009. [7] SAFESPOT document, SINTECH LDM data model_v10 0 8




ANNEX 1: Implemented prototypes In accordance with the indications given in the Technical Annex, the SP2 (INFRASENS) deliverables relating to WP4 (Prototypes and Implementation consist of two reports and five prototypes. Whereas in subprojects SP1 and SP4 the prototypes are specific vehicles equipped with SAFESPOT components, the SP2 prototypes are components of the reference platform. In fact some are detection systems and others are software modules which are used to set up the road side unit. D2.4.3: Sensing networks and systems The seven roadside sensing systems developed within INFRASENS have been described in chapter 7 of D2.4.2. For all of these system, except one, the prototype consists of the algorithms developed specifically to improve the performance of the system and the quality of the data output with respect to safety-related information. The systems have been implemented and tested within developer facility and the integrated/installed in different test site. For a better explanation of the functionalities offered, video and multimedia material is available. Multimedia material concerning roadside sensing systems includes:

• the RFID system, for ghost driver detection, developed by BME (Budapest)

• the CCTV camera system for visibility assessment developed by LCPC (Paris)

• the CCTV camera system for vehicle positioning developed by CIDAUT (Valladolid)

• the CCTV system for ice/wet road detection developed by VTT (Helsinki)

• the NIR camera system for pedestrian/animal detection by VTT (Helsinki)

• the laserscanner for road user detection by IBEO (Germany)

• the Wireless Sensor Network (WSN) for vehicle passage and speed by ISMB/MIZAR (Turin).

D2.4.4 Algorithms for detection of safety-related events These algorithms are responsible for the processing of data generated by detection system or provided by road operator legacy system. With reference to the description provided in Chapter 6 of D2.4.2, the algorithm refers to:

• pre-processing algorithm related to detection systems

• situation refinement components




Part of the implementation will be available during the review in Helmond; while there is multimedia material dedicated to ECAID Extended Automatic Incident Detection System. D2.4.5 Data fusion methods Data fusion implemented is described in depth in Chapter 5 or D2.4.2, including the different configurations adopted in each test site. D2.4.6 Distributed actuation systems The actuation strategy is the ‘visible’ output of the road side unit chain, i.e. the stage at which the processed information provided by the detection systems is used by the CoSSIB applications. It is delivered to the road user in various ways: a. the VANET to provide EventMessage to SAFESPOT equipped vehicles b. through VMS (legacy systems) for road users without SAFESPOT

equipped vehicles. c. The LED warning system developed by INFRASENS and integrated in the

WSN system (see Chapter 7 of D2.4.2). Option b is guaranteed by setting up gateways connected to road side unit (reference to Figure 2 in deliverable D2.4.2) offering the interface to the road operator control centre. Gateway is implemented accordingly to the specific message set defined in the document, SF_SP7_Data_format&messages. D2.4.7 Integration of SAFESPOT with traffic management systems The integration with traffic management systems are test site specific. This prototype has been implemented in the Netherlands Test Site (Helmond) and Germany (Dortmunt) where there is an interface with local urban traffic control controllers.




ANNEX 2 : Planned installations of the SP2 modules The following pages indicate the planned implementations in SAFESPOT Test Sites which involve a roadside unit and some elements of the Infrastructure Platform. These have been ‘mapped’ on the Functional model, to show the processing modules required. There are a total of 20 implementations

1. G-D1 Dortmund, Germany 2. I-TC1 Torino-Caselle, Italy 3. I-TC2 Torino-Caselle, Italy 4. I-CRF1 Test Track, Orbassano, Italy 5. I-CRF2 Test Track, Orbassano, Italy 6. I-BP1 Brescia Padova Motorway, Italy 7. N-1 Helmond Nethrelands 8. N-2 Helmond Netherlands 9. N-3 Helmond Nethrelands 10. S-1 Gothenborg, Sweden 11. W-VS1 Vivy Saumur, France 12. W-VS2 Vivy Saumur, France 13. W-VS3 Vivy Saumur, France 14. W-VS4 Vivy Saumur, France 15. W-VS5 Vivy Saumur, France 16. W-VS6 Vivy Saumur, France 17. W-EM1 Etables sur Mer, France 18. W-EM2 Etables sur Mer, France 19. W-S1 Satory track, France 20. W-B1 Bourbriac, France




SP2 - Data Fusion

Data Receiver

LOCAL DYNAMIC MAP DATABASE

Q- / T-API

25.01.2008

SP5 Feedback

Message Generator

VANET Messages Q- / T-APIQ-API


RFID for Ghost Driver Detection (Preprocessing Unit)


Gateway to Traffic Light Controller



Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching

Cooperative Pre-Data Fusion

SAFESPOT RSU System – Dortmund

Vehicle Traffic Environmental Safety



Thermal Camera Living Objects (Preprocessing Unit)

NIR Camera Ice Detection (Sensor and Preprocessing Unit)

CCTV for Visibility (Preprocessing Unit)

RFID Ghost Driver(Pre-processing unit)

Wireless Sensor Network(Pre-processing unit)

Data Receiver

WSN, RFID

Data Receiver

Laser-scanner

Object RefinementWSN, RFID

SP5 Application: IRIS_01, 02

Map provider: TeleAtlas

Vehicle trajectories

G-D1

Annex2 - Figure 1 – G-D1 Dortmund, Germany




SP2 - Data Fusion

Data Receiver

TUM


Q- / T-API

25.01.2008

SP5 Feedback

Message Generator







Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching









Data ReceiverMIZAR

Data Receiver

Laser-scanner

Object RefinementWSN, RFID, NIR

SAFESPOT RSU System – Torino-Caselle

SP5 Application: H&IW_01 ObstacleSP5 Application: H&IW_02 Ghost Driver


Ghost driver, pedestrian

I-TC1

Annex2 - Figure 2 – I-TC1 Torino-Caselle, Italy




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback

Message Generator





Message Router (VANET) SMAEV


Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching









Data Receiver

WSN, RFID

Data Receiver

Laser-scanner

Object RefinementWSN, RFID, NIR

SAFESPOT RSU System – Torino-Caselle

SP5 Application: SMAEV


I-TC2

Annex2 - Figure 3 – I-TC2 Torino-Caselle, Italy




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback

Message Generator







Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching









Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – CRF Test Site (Ghost driver)

SP5 Application: H&IW_02 Ghost driver


I-CRF1

Annex2 - Figure 4 – I-CRF1 Test Track, Orbassano, Italy




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching










Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – CRF Test Track (RoadDep)

SP5 Application: RoadDep


I-CRF2

Annex2 - Figure 5 – I-CRF2 Test Track, Orbassano, Italy




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching










Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – Helmond

SP5 Application: IRIS_01, IRIS_02

Map provider: Navteq

N-1

Annex2 - Figure 6 – N-1 Helmond Nethrelands




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching










Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – Netherlands - N629

SP5 Application: Speed Alert


Legal speed limit*

N-2

Annex2 - Figure 7 – N-2 Helmond Netherlands




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching










Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – Netherlands - A16

SP5 Application: H&IW_01SP5 Application: H&IW_03


Position of damaged vehicle/ slippery road/ fog

N-3

Annex2 - Figure 8 – N-3 Helmond Netherlands




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching










Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – Sweden - E6 motorway

No SP5 Application (only SP4)


Data itemswrittendirectlyon LDM

NB. Using CVIS RSU

S-1

Annex2 - Figure 9 – S-1 Gothenborg, Sweden




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback

Message Generator







Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching










Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – WestTS Scenarios 9a & 10a – COFIROUTE Autoroute A85 (Vivy-Saumur)

Legal speed limit (depending on weather conditions)

SP5 Application: SPA_01 (LCPC)


simulatedGateway to Weather Station

W-VS1

Annex2 - Figure 10 – W-VS1 Vivy Saumur, France




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching










Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – WestTS Sc 9b – Autoroute A85 (Vivy-Saumur)

Position of damaged vehicle on the road

SP5 Application: H&IW_01 (Cofiroute)


Accident

W-VS2





SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback(H&IW feedback)

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching










Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – WestTS Sc 9c – Autoroute A85 (Vivy-Saumur)

New speed limit regarding the position of damaged vehicle on the road

SP5 Application: SPA_02 after H&IW (LCPC) Map provider: Navteq

W-VS3





SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback from H&IW

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching



Gateway to COFIROUTETraffic Control Centre







Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – WestTS Sc 10b – Autoroute A85 (Vivy-Saumur)

Position of road works on the road

SP5 Application: H&IW_01 (COFI)


Road works

W-VS4

simulated





SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

SP5 Feedback from H&IW

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching



Gateway to COFIROUTETraffic Control Centre







Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – WestTS Sc 10c - Autoroute A85 (Vivy-Saumur)

SP5 Application: SpA_02 after H&IW (LCPC) Map provider: Navteq

New speed limitation regarding the position of road works

W-VS5





SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

Message Generator





Gateway to meteorological station



Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching










Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT (mobile) RSU System – Motorway A85 (Vivy-Saumur)

SP5 SMAEV HMI

(Static) position of event or mobile roadworks on the road

SP5 Application: SMAEV 01 (SODIT)


W-VS6





SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

Message Generator





Gateway to Weather Station



Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching










Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – Rural road RN 786 (Etables s/ Mer) and before on LIVIC test tracks

SP5 Feedback

Bad weather conditions on the road (visibility distance, rain, wind…)

VMS (CG22)

SP5 Applications: SpA_01 (LCPC)SpA_03 (LCPC)


W-EM1

Annex2 - Figure 16 – W-EM1 Etables sur Mer, France




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching










Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT (mobile) RSU System – Rural road RN 786 (Etables s/ Mer) – SMAEV – CG 22 (Scenario 14)

(Dynamic position of maintenance vehicle on the road

SP5 Application: SMAEV 01 (SODIT)


SP5 SMAEV HMI

W-EM2

Annex2 - Figure 17 – W-EM2 Etables sur Mer, France




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching









Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – Satory closed test track – Road departure prevention – LIVIC (Scenario16)

SP5 Feedback

Dynamic position of the vehicle on the road

SP5 Application: RDep 01 (DIBE)


W-S1

Annex2 - Figure 18 – W-S1 Satory track, France




SP2 - Data Fusion

Data Receiver


Q- / T-API

25.01.2008

Message Generator








Manoeuvre Estimator



ECAID




Object Refinement

Object Matching

Map Matching









Data Receiver

WSN, RFID

Data Receiver

Laser-scanner


SAFESPOT RSU System – Rural road RD 8 (Bourbriac) – Road departure prevention – CG 22 (Scenario 17)

SP5 Feedback

Dynamic position of the vehicle on the road

SP5 Application: RDep 01 (DIBE)


W-B1

Annex2 - Figure 19 – W-B1 Bourbriac, France




ANNEX 3 : Installation of the LDM Detailed indications are provided below on the installation of the PostgreSQL database and the creation of the LDM developed by TeleAtlas.

• Packages for PostgreSQL database server and PgAdmin administration application are:

– postgresql , postgresql-client , postgresql-contrib

– pgadmin3

• Command lines: – $ sudo apt-get install postgresql postgresql-client postgresql-contrib

– $ sudo apt-get install pgadmin3

• Reset the password for the ‘postgres’ admin account for the server: – $ sudo su postgres -c psql template1

– $ template1=# Change the postgres user to the password 'safeprobe';

– $ template1=# \q

• For the unix user ‘postgres’: – $ sudo passwd -d postgres

– $ sudo su postgres -c passwd

then enter the ‘safeprobe’ that you used previously

• Set-up the PostgreSQL admin pack – enables better logging and monitoring within pgAdmin

– $ sudo su postgres -c psql < /usr/share/postgresql/8.2/contrib/adminpack.sql

PostgreSQL Configuration

• Edit /etc/postgresql/8.2/main/postgresql.conf

• Modify fields: – Listening IP Address and port:

• listen_addresses = '*' or insert to specific IP Address;

• port = 5432

• Edit /etc/postgresql/8.2/main/pg_hba.conf

• Using the subnet address 192.168.0.0 insert the following field: # IPv4 local connections: host all 192.168.0.0/24 md5

• Finally restart the server typing: $ sudo /etc/init.d/postgresql-8.2 restart

• To use PostgreSQL libraries you need to install the following package: – libpq-dev

• The installed libraries can be found at: – /usr/include/postgres




How to create an LDM database • A LDM database needs a PostGIS template

– Create a new database as ‘postgres’ user

$ createdb template_postgis

– PostGIS requires the PL/pgSQL procedural language extension:

$ createlang plpgsql template_postgis

– To create the template schema use:

$ psql –d template_postgis –f /usr/share/postgresql-8.2-postgis/lwpostgis.sql

$ psql –d template_postgis –f /usr/share/postgresql-8.2-postgis/spatial_ref_sys.sql

• In the case of problems, refer to following link: http://postgis.refractions.net/documentation/manual-1.3/index.html

• Create new LDM database:

– From pgAdminIII interface:

• Create new database and select ‘template_postgis’ as template;

• Use the ‘Query Tool’ to create the schema provided by .sql files downloaded from Safespot Site;

– From a shell command line (as ‘postgres’ user):

$ createdb –T template_postgis ldm

$ psql –d template_postgis –f <sql file path>

sp2 – infrasens – safespot infrastructure platform final … · 2010-10-26 · task no....

Documents