Final Report: Needs and Requirements of Infrastructure ... · Status (F: final; D: draft; RD:...

SAFESPOT INTEGRATED PROJECT - IST-4-026963-IP

DELIVERABLE

SP2 – INFRASTRUCTURE PLATFORM

Deliverable No. D2.2.2

SubProject No. SP2 SubProject Title Infrastructure Platform

Workpackage No. WP2 Workpackage Title Needs and Requirements

Task No. Tasks 2.1-2.5 Task Titles Role of the Infrastructure, Technology survey & analysis; Definition of User Needs; Reference Architecture; System Requirements.

Main Authors Angela Spence (MIZAR), Yannis Pavlis (CERTH), Tobias Schendzielorz (TUM), Silvia Zangherati (CRF)

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

Version No: V7.0

File Name: SF_D2.2.2_Part A_Final Report_Needs&Requ_v7.0

Issue Date: 20/11/02006

Project start date and duration 01 February 2006, 48 Months

Final Report: Needs and Requirements of Infrastructure-based Sensing – Part A

Deliverable D2.2.2 Part A Dissemination Level (PU) Copyright SAFESPOT

Contract N. IST-4-026963-IP

D2.2.2 Part A Main Report.doc Subproject SP2 - INFRASENS ii

Revision Log

Version Date Action Main authors

V1.0 15-09-06 First version of report based on reorganisation of D2.2.1 with the following modifications:

25-09-06 Changing role of the Infrastructure: ‘smart roads’ for greater safety

Angela Spence MIZAR Carlo Alampi ANAS

03-10-06 Definition of User Needs: revised presentation of safety needs

Simonetta Manfredi CSST Stefano Marco CSST

12-10-06 Innovative sensing approach: wireless sensor networks

Pierluigi Civera ISMB Dario Galleano ISMB

Sept/Oct Contributions to Technology Capabilities templates

Partners: VTT, TA, CIDAUT, CSST, CERTH, TUM, MIZ, LCPC, IBEO, PTV

23-10-06 Description of High Level Functional Architecture for the Infrastructure

Gino Franco MIZAR Eugenio Morello CSST

18-10-06 Explanation of approach to defining the System Requirements Silvia Zangherati CRF

V2.0 20-10-06 Additions to Technology Analysis Summary Table of technology performance and characteristics

Yannis Pavlis CERTH

V3.0 20-10-06 Local Dynamic Map description Christine Bartels TA

V4.0 20-10-06 Technology Capabilities: collection, consolidation and final editing

Tobias Schendzielorz TUM Sibylle Nussbaecher PTV

V5.0 20-10-06 Final editing Javier Burgoa CIDAUT Angela Spence MIZAR

V6.0 31-10-06 Correlation between Technology Capabilities and SP5 Use Cases Editing Technology Capabilities

Joel Receveur SODIT Tobias Schendzielorz TUM

V7.0 20-11-06 Integration of changes requested by Peer Reviewers Angela Spence MIZAR



D2.2.2 Part A Main Report.doc Subproject SP2 - INFRASENS iii

List of Abbreviations AVL Automatic Vehicle Location

CCTV Closed Circuit TeleVision

EITSFA European ITS Framework Architecture

ENV Environmental Data

ESS Environmental Sensor Station

GDF Geo-referenced Data Format

GPS Global Positioning System

INFRA Infrastructure-related data

ITS Intelligent Transport System

KAREN Keystone Architecture Required for European Networks

LAN Local Area Network

LDM Local Dynamic Map

LED Light-Emitting Diode

MFO Multi-functional Outstation

NAV Navigation Data

OSS Occupant Safety System

OV Own Vehicle (Host vehicle)

RSU Roadside Unit

PTW Powered Two Wheeler (Motorcycle)

SoA State-of-the-art

SP Subproject

SVD Static Vehicle Data

TIC Traffic Information Centre

TMS Traffic Management System

TRAF Traffic-related Data

UN User Need

UTC Urban Traffic Control

VANET Vehicle Ad hoc Network (for temporary communication – data exchange - between vehicles in a local area)

VEH Vehicle-related Data

VIP Video Image Processor

VMS Variable Message Sign

WAN Wide Area Network

WSN Wireless Sensor Network



D2.2.2 Part A Main Report.doc Subproject SP2 - INFRASENS iv

Table of Contents

PART A List of Abbreviations...............................................................................................................................iii Table of Contents .................................................................................................................................... iv List of Figures .......................................................................................................................................... v List of Tables............................................................................................................................................ v EXECUTIVE SUMMARY .....................................................................................................................vi 1 Introduction ...................................................................................................................................... 1

1.1 Innovation and Contribution to SAFESPOT Objectives ............................................................ 1 1.2 Methodology .............................................................................................................................. 2 1.3 Deliverable structure .................................................................................................................. 3

2 A new role for the Infrastructure ...................................................................................................... 4 3 The Needs of Cooperative Roadside Sensing................................................................................... 6

3.1 The specific needs of preventive safety...................................................................................... 6 3.2 Approach to the definition of the User Needs ............................................................................ 8 3.3 The ‘Users’ of the Infrastructure Platform ................................................................................. 9 3.4 Summary and analysis of the User Needs ................................................................................ 11 3.5 How to read the User Needs table ............................................................................................ 13 3.6 List of SP2 User Needs ............................................................................................................ 14

4 Technology Assessment ................................................................................................................. 21 4.1 State-of-the-art survey.............................................................................................................. 21

Table 5 Correlation of sensing technologies and ‘events’ detected........................................................ 26 4.2 Analytical summary of the survey results ................................................................................ 27 4.3 Principal shortcomings of current systems............................................................................... 30 4.4 Micro-technologies .................................................................................................................. 30 4.5 Wireless sensor network........................................................................................................... 31 4.6 Local Dynamic Map (LDM) .................................................................................................... 35 4.7 Potential for co-operative detection ......................................................................................... 36 4.8 INFRASENS research strategy ................................................................................................ 41

5 Technology Capabilities ................................................................................................................. 42 6 Infrastructure Platform: Functional Architecture............................................................................ 87

6.1 System Components................................................................................................................. 88 6.2 Three-level hierarchy ............................................................................................................... 92 6.3 Reference Model ...................................................................................................................... 93 6.4 Geographical characteristics of the Platform ........................................................................... 94

7 System Requirements ..................................................................................................................... 96 7.1 Methodology ............................................................................................................................ 96 7.2 Organisation of the requirements ............................................................................................. 97

8 References .................................................................................................................................... 100 PART B Technology Review and Survey PART C List of INFRASENS System Requirements



D2.2.2 Part A Main Report.doc Subproject SP2 - INFRASENS v

List of Figures Figure 1 INFRASENS work flow in relation to other subprojects ..........................................................3 Figure 2 Logical components of a network node ..................................................................................32 Figure 3 Function of node in reducing data volume...............................................................................33 Figure 4 Architecture of the ‘Local Dynamic Map’ ...............................................................................36 Figure 5 Data paths for cooperative event detection (source C. Zott et al) ...........................................40 Figure 6 Relations between the Use Cases of SP4 and SP1 (from D4.2.3) ............................................47 Figure 7 Logical architecture of the platform.......................................................................................87 Figure 8 System components on the Infrastructure ................................................................................88 Figure 9 Hierarchical organization of the Infrastructure Platform .........................................................92 Figure 10 Functional Reference Model ..................................................................................................93 Figure 11 Geographical distribution of local SAFESPOT applications .................................................94 Figure 12 Main steps in the definition of the INFRASENS requirements ............................................96

List of Tables Table 1 List of INFRASENS Users or ‘stakeholders’ ............................................................................10 Table 2 Relationship between the EITSFA and INFRASENS Users Needs ..........................................11 Table 3 INFRASENS User Needs Groups .............................................................................................12 Table 4 Features of main technologies in terms of cost, maintenance, reliability, performance, etc .....23 Table 5 Correlation of sensing technologies and ‘events’ detected........................................................26 Table 6 Strengths and Weaknesses of Sensor Technologies ..................................................................27 Table 7 Complementary data acquisition by roadside and vehicle-based sensors..................................38 Table 8 Template for Technology Capabilities ......................................................................................42 Table 9 List of INFRASENS Technology Capabilities..........................................................................43 Table 10 Link between Technology Capability and SP4/SP5 Use Cases...............................................44 Table 11 Overview of the CoSSIB Use Cases (from D5.2.1) ................................................................45 Table 12 Overview of the SCOVA Use Cases .......................................................................................46 Table 13 Description of the System Actors (or Components) for Infrastructure-based Sensing............89 Table 14 Explanation of fields in Requirements Table .........................................................................98



D2.2.2 Part A Main Report.doc Subproject SP2 - INFRASENS vi

EXECUTIVE SUMMARY This Report presents the different stages of work carried out by the subproject INFRASENS as part of the process of defining the User Needs and System Requirements for the SAFESPOT Infrastructure Platform. It includes: A discussion of how the integration of sensing technologies within the

infrastructure will enable the ‘smart roads’ of the future to play a more active role in supporting preventive safety. This section explains the New Role of the Infrastructure and how this can be achieved through enhanced roadside detection of safety-critical conditions made possible by ‘co-operation’ between vehicles and the infrastructure.

The identification of the users or ‘stakeholders’ of the Infrastructure Platform and an examination of their needs and expectations with regard to cooperative systems for road safety. The services, functions and qualities desired by the users are expressed in formal terms as a List of User Needs using the approach set out in the European ITS Framework Architecture as a model.

An analysis of the results of the roadside sensing technology survey made by INFRASENS partners (the details of the survey can be found in Part B of this report). It assesses the strengths and weaknesses of different technologies in detecting safety-critical conditions and proposes some innovative technologies and approaches (including wireless sensor networks, improved incident detection techniques, and highly accurate digital maps) which could increase the effectiveness of future systems.

A set of templates which some of the capabilities (or potential) of the technology for improving the quality and performance of roadside sensing, as well as detection of safety-critical events, and provision of warning signals.

A description of Functional Architecture of the Infrastructure Platform Architecture and proposed Reference Model. It presents the main system components and provides a high level view of the platform functions, based on the logical ‘process’ of data acquisition, processing and generation of ‘alerts’ (or warnings) for road users.

An explanation of the how the User Needs and Functional Architecture served as a basis for drawing up the System Requirements for infrastructure-based sensing. (The List of System Requirements can be found in Part C of this report).

The principal contributions of the work presented in this report are: - to provide a basis for the specification for the Infrastructure Platform to be drawn up in the next stage of the work; - to provide a description of the high level architecture of the platform; - to give an indication of the technologies which can be adopted.



D2.2.2 Part A Main Report.doc Subproject SP2 - INFRASENS 1

1 Introduction The objective of the SAFESPOT project is to understand how ‘intelligent vehicles’ and ‘Intelligent roads’ can cooperate to improve road safety. The aim is to develop systems which can detect potentially dangerous situations affecting the driving environment, and to provide information to vehicles in the local area in order to prevent road accidents from occurring, or to avoid that existing incidents cause further serious risks for road users. The principle is to use sensing technologies to extend drivers´ awareness of the surrounding environment in space and time. The role of INFRASENSE is to develop the elements which will make up the Infrastructure Platform. These will consist of a set of systems or ‘modules’ able to detect safety-critical conditions occurring on the road network, as well as the software for processing the raw data to generate information which can be used to provide real-time warnings for road users present in the local area, enabling them to avoid being involved in accidents. The safety warnings will be communicated to road users via the infrastructure itself (i.e. by means of roadside signals) and/or also sent to equipped vehicles where they will be presented to the driver. This Report presents the needs and requirements of the Infrastructure Platform to be developed by INFRASENS. It includes details of the activities which have been undertaken in the first stage of the project. These followed two parallel streams: a ‘top down’ approach (to examine how an ‘Intelligent Co-operative Infrastructure’ could contribute to improving road safety, identify the needs of such a system from the point of view of the users and define the high level architecture) and a ‘bottom up’ approach (consisting of a Technology Survey and Analysis whose aim was to assess how roadside sensing technologies could potentially meet these requirements). Some of the contents of this report have already been presented in an internal Interim Report which was submitted to an internal review. The observations and feedback of the reviewers has been taken into account in this version.

1.1 Innovation and Contribution to SAFESPOT Objectives

The definition of the Needs and Requirements for the Infrastructure Platform provides an important contribution to SAFESPOT’s objectives by establishing the basis for the specifications to be drawn up in the next stage of the work. The specifications for the various elements of the platform will in turn serve as a foundation for the development of the prototypes. In this sense, this present stage represents the ground work for the whole platform. Some significant innovative aspects of the work undertaken include: - the systematic analysis of the detection capacities of technologies used for roadside sensing seen from a safety point of view and the identification of ways in which innovative technologies could be integrated within new sensing systems for the future (e.g. use of micro-technologies and ad hoc networks);




- the compilation of the List of User Needs for cooperative roadside sensing; - the identification of system requirements for the roadside elements of the SAFESPOT cooperative systems for road safety.

1.2 Methodology Before describing the methodology, it is useful to mention briefly the other SAFESPOT subprojects which have important interrelations with INFRASENS at the present stage of the project: SAFEPROBE (SP1), responsible for developing the Vehicle-based Platform, and with which INFRASENS is examining the potential for data exchange for the identification of safety-critical events. SINTECH (SP3), developing the Innovative Technologies (Local Dynamic Map, Vehicle-Infrastructure Communications, and Positioning) needed by the Infrastructure Platform and for which the requirements must be defined. CoSSIB (SP5), responsible for the Infrastructure-based Applications in which the INFRASENS modules will be integrated. This subproject is defining a set of Use Cases whose requirements will need to be taken into account in developing the Infrastructure Platform. SCORE (SP7), responsible for defining the Core Architecture and providing general methodological guidelines for the definition of the needs and requirements. SCORE have provided the high-level User Needs which served as a basis for the selection to be made by INFRASENS. The methodology adopted by INFRASENS respects the common Work Flow established by the SCORE subproject responsible for the common high level architecture. Due to the numerous inter-relations between the subprojects, a coordinated approach was essential. In a series of meetings, a joint plan was agreed to ensure a coherent approach to the completion of the Definition of Needs and Requirements of all the technical subprojects. The resulting workflow for INFRASENS is shown in Figure 1, which illustrates the main activities involved and the principal interactions with the other technical subprojects. It can be seen that the activities were divided into three main stages: - a high level description (which set the overall guidelines); - the definition of User Needs and Technology Capabilities which proceeded in parallel with the Technology Analysis; - the definition of the System Requirements.




Requirements

ScenariosUser NeedsUse Cases SP2 LIST of

USER NEEDS

Accident data Analysis SP4-SP5

COMMON USE CASES

SP2 OBJECTIVESRole of the Infrastructure

High Level USER NEEDS

SP7

TECH SCENARIOSSP2

SYSTEM COMPONENTS

High Level Description

Activity Flow for producing Needs and Requirements in SP2

Common Basic Scenarios SP4-SP5

TECHNOLOGY ANALYSIS Sensors ‘state-of-art’

System Requirements SP3 SYSTEM REQUIREMENTS

Functional/Non-functional/Other

1a

2

4

3

5

1b“Scenario

Requirements”SP5-SP4

Figure 1 INFRASENS work flow in relation to other subprojects

1.3 Deliverable structure For ease of assimilation of the large amount of material produced, the report has been subdivided into three parts. PART A contains an explanation of the approach adopted and summarises the work carried out to define the Needs and Requirements: - Description of the new role for the road infrastructure; - Needs of infrastructure based sensing for preventive safety; - Innovative developments and enhancements required - Technology Capabilities; - Architecture of the Infrastructure Platform - System Requirements PART B contains the results of the technology survey, which examines the potential of a wide range of technologies to undertake safety-related roadside sensing. It consists of three sections: - Methodology adopted - Technology Survey (completed templates) - Technology Review and Analysis PART C contains the current List of INFRASENS System Requirements.




2 A new role for the Infrastructure The task of INFRASENS is to develop the components of the “intelligent infrastructure” which, in cooperation with “intelligent vehicles”, will enable the SAFESPOT applications to achieve the goal of improving safety on Europe’s roads. But what is implied by an intelligent cooperative infrastructure? As stated in the recent FORESIGHT study1: “Information, and its collection and management, is at the heart of the development of an intelligent infrastructure”. The focus of INFRASENS will therefore need to be on the way such information is acquired, processed and made available to road users. The principal features envisaged for the INFRASENS Infrastructure Platform are that it should be: - equipped with technologies which enable it to autonomously gather a large amount of ‘intelligence’ about the driving environment; - able to communicate (i.e. exchange data) with vehicles passing along it; - able to efficiently process the data gathered to provide timely information to road users which promotes the ‘intelligent use’ of roads; - use a ‘local dynamic map’ module to support the sensors by providing a highly accurate geo-referenced data base. For safety purposes, the benefit of a ‘cooperative architecture’ is that the roadside sensors and vehicle sensors are included in the same network. This offers enormous additional potential through the sharing of data in real time, meaning that:

• the infrastructure can benefit from the integration of vehicle-detected data, and as a result gain greatly enhanced coverage and precision in interpreting traffic and individual vehicle behaviour;

• the vehicle benefits from data detected by roadside sensors (as well as other vehicles) and, as a result, gains greatly enhanced awareness of its surrounding environment.

The SAFESPOT Applications will be able to exploit this potential to provide safety-related support to road users - both through roadside equipment and onboard devices. This will range from simple warnings or recommendations (e.g. speed alerts) to advanced assistance for vehicle manoeuvring in hazardous conditions. Such warnings will be broadcast in the immediate area of the hazard, allowing drivers to adapt their behaviour and avoid an accident.

1 Intelligent Infrastructure Futures: The Scenarios – Towards 2055 (Department of Trade and Industry, January 2006).




The potential of the new approach to sensing, together with improved processing methods and the integration of data from vehicles, offer exciting opportunities which significantly enhance the role of the infrastructure. Having acquired real time data relating to a given part of the road network, an intelligent infrastructure can provide safety information which is specific to a given moment, a given stretch of the road and even a specific vehicle. It can, for instance, recommend the safe speed for the approaching bend taking into consideration the road geometry, the weather conditions (dry, wet or icy), and road holding properties of the vehicle. Or it could give a warning of a vehicle overtaking dangerously and arriving in the opposite direction, or the fact that there is a queue hidden behind the bend. For a cooperative infrastructure, the vehicle acts as a special kind of “mobile sensor” able to provide information which is impossible (or maybe too costly) for road-side sensors to obtain. For the vehicle, the ability to acquire data or receive warning messages from the infrastructure is especially important in the absence of other equipped (probe) vehicles on a given stretch of road. An intelligent infrastructure therefore plays a particularly significant role in the early stages of co-operative system deployment and in regions where there is a low density of traffic. Nevertheless, even in the case of full market penetration of equipped vehicles, it seems probable that some types of data will still be provided more efficiently and accurately by roadside sensors. Identification of the optimum complementary role of the vehicle and infrastructure platforms in relation to data acquisition and processing is therefore an important task which will require close collaboration between INFRASENS and SAFEPROBE. An intelligent infrastructure involves not only technical innovations, but also new attitudes on the part of drivers and infrastructure managers. The cooperative systems planned by SAFESPOT imply a collaborative approach to the promotion of safety. Rather than focusing on ‘blanket’ restrictions, road operators will be able to provide fine-tuned safety-related recommendations. Drivers will however have to learn how to use this information in order to interpret road conditions more effectively and hence drive more safely. The systems aim to support and enhance human decision-making. A changing relationship between road operator and road user has already been occurring in recent years. The infrastructure is expected not only to be safely designed, but to guarantee a minimum level of information and support, and also to offer a range of “value-added” services. This means equipping roads with sensing and communication technologies, but coverage is still not uniform, nor always associated with the level of safety risk. Most current systems are used to improve traffic efficiency rather than prevent accidents. And although accidents on rural roads have the highest mortality rate, motorways are generally the most comprehensively equipped. So the challenge is to develop enhanced sensing systems which can provide information useful for preventive safety, and to ensure that geographical coverage is linked to the potential danger.




3 The Needs of Cooperative Roadside Sensing A clear statement of the needs of the users of a system is a preliminary and fundamental activity for any complex technology project. It ensures that the system actually developed will be user-oriented and satisfy the requirements and expectations of all those affected by it. In the case of INFRASENS, the list of User Needs has served as a basis for the specification of the components of the INFRASENSE platform. The List of ‘User Needs’ consists of a formal expression of the priorities, needs and expectations relating to the system being implemented, seen from the viewpoint of the users. They are a statement that defines what the users require the system to do, therefore defining in a systematic way the services, qualities and performance that the system should offer and the constraints on their provision. In this sense they represent the minimum set of problems that the system should solve.

3.1 The specific needs of preventive safety The safety context, which is central to SAFESPOT, imposes a set of critical requirements on the systems to be developed by INFRASENS. These fall into three main categories: system performance, deployment factors, and factors regarding the human-machine interface. Firstly, with regard to performance, the required characteristics are:

• very rapid processing: to have an impact on safety, warnings must be produced with a very low latency time. This means that the whole process – from sensing, to event recognition, translation into safety alerts, including data processing and communication – must be extremely rapid (response times for accident avoidance have been calculated by EC research projects such as SASPENCE and can be used as guidelines);

• the need for precision: the information produced must have a high degree of accuracy and reliability. If not, drivers will lose confidence in the system; it could even risk actually provoking an accident. Information should therefore be associated with a ‘score’ expressing the degree of confidence;

• constant availability: in relation to safety, it is necessary to define the degree of ‘criticality’ of the system concerned. Those with high criticality will need to be operative on a permanent basis (24 hours a day). This means that they need to be fault tolerant.

Secondly, in order to make a real contribution to European road safety, the systems developed by SAFESPOT must be widely implemented. This implies that they must be attractive to road operators, who are sensitive to a set of operative and economic factors, including.

• low maintenance: systems with minimal requirements in relation to human resources and time to remain fully operational;




• low cost: to maximise the feasibility of widespread deployment;

• minimum disturbance: interventions, including installation, repair, and maintenance should not result in undue traffic disruption;

• applicability to different types of road: it should be feasible to install systems in all locations where the safety risks exist.

One of the shortcomings of existing sensing systems is that the devices often need to be embedded in the road surface or mounted on special supports. Their installation can require temporary lane closure and, especially on busy motorways, cause serious disruption to traffic. The road environment is ‘unfriendly’ for sensing equipment, due to exposure to dampness, dust, pollution, vibrations etc which can be damaging. Sensors may also be impaired (or even removed) unintentionally by road works. Many of the current systems are very vulnerable to wear and tear, requiring frequent attention or replacement. This incurs a heavy cost in terms of maintenance. In the case of traffic management systems, sub-optimum performance may not be critical, in the case of safety it is a serious shortcoming. An additional problem is that of the communications which (except for wireless systems) involves cabling, and can be very problematic in remote locations. Electrical parts are also sensitive to humidity and storm voltage spikes. A further consideration is the energy needs of sensor systems. The reliability guarantees and system maintenance represent a considerable monetary and ‘disturbance’ cost for the road operator. As a result, there is a growing tendency to impose constraints on the location of equipment and access conditions. Some operators (e.g. Cofiroute in France) no longer allow any installations on the central reservation of motorways. All of these considerations will affect the system design and also the choice of technologies to be adopted in future systems. They indicate that vulnerable elements, such us under-pavement cabling, must be kept to a minimum, and that ease of maintenance, low cost and energy requirements will be critical features for future sensors and alert systems. The third area concerns the communication of information to drivers, which involves issues of: rapid assimilation of the crucial information: so that the driver’s response is quick enough to prevent an accident. This means paying great care to the design of the human-machine interface (HMI); reliability: the driver must have confidence in the system in order to be prepared to react; universality: the system must be ‘familiar’ in different parts of Europe. The remaining part of this chapter explains how these needs have been taken into consideration and ‘translated’ into User Needs.




3.2 Approach to the definition of the User Needs In order to favour the interoperability of the SAFESPOT system at European level and to have a common terminology, it was decided to use the approach set out in the European ITS Framework Architecture (EITSFA)2 as a basis for the definition of the User Needs for the whole project. A guide to the way in which this was to be done, a common glossary and set of templates were defined by the subproject SCORE (Core Architecture) on behalf of the other subprojects. This is described in detail in the Deliverable D7.2.1, but the main concepts are briefly summarized below. After a critical revision of the existing EITSFA dictionary of User Needs, an initial set of high level User Needs was defined by SCORE. Those selected were generic and applicable to the whole SAFESPOT System. They have been used as a ‘checklist’ by the technical subprojects (SP1-6) to select the User Needs most relevant to their own specific areas of activity. In order to undertake this selection, it was necessary as a first step to define the users of the system. INFRASENS partners therefore began by identifying the users of the Infrastructure Platform (see below). In the light of their desires and aspirations, the List of High Level User Needs selected by SCORE was reviewed systematically. The selection of those relevant to the infrastructure platform required an in-depth analysis and resulted in the acceptance of many of the User Needs listed, the rejection of others, the modification of some and introduction of some new needs. This process was facilitated by the expertise of a number of INFRASENS partners and in particular experience with the European ITS Framework Architecture as well as the Italian ITS Architecture (ARTIST). As a result of this activity, INFRASENS has produced a set of User Needs which is compatible with, and directly correlated to the EITSFA User Needs. The User Needs cover not only functional expectations, but also many other characteristics and qualities that the Systems are required to meet, such as maintainability, reliability, user-friendliness and security. Once the List of User Needs is complete and the Use Cases are defined the System Requirements will have to be identified. These are a series of formal statements that describe the features of the system that will be necessary to satisfy the User Needs.

2 The first version of the European ITS Framework Architecture was issued in August 2000 as a result of the KAREN (Keystone Architecture Required for European Networks) project, which began on 1st April 1998. The Architecture was designed to be a minimum stable framework necessary for the deployment of working and workable ITS within the European Union until at least 2010, and focuses on road-based ITS systems. For more details see documentation listed in the References at the end of this report.




3.3 The ‘Users’ of the Infrastructure Platform Users or ‘stakeholders’ are considered to be all those who have an interest in or are affected in some way by a system. Based on the guidelines set out by the project CONVERGE [1998] four main categories can be defined: those who Want a given ITS system, those who Make it, those who Use it and those who Rule it. The European ITS Framework Architecture lists seven main groups of users: Private Consumers – Travellers (who make use of ITS as users of transport systems, infrastructure and facilities). Commercial Consumers – the Freight and Transport Industry (which makes use of ITS to carry out their operations). Companies – Private commercial organizations (which provide or use ITS). Local Authorities (which plan/manage or regulate ITS at the local level). High Level Ministries (which plan/manage/regulate ITS at the national level). Exploitation Level - Operators (which use ITS and also provide services based on ITS). Industry Level - Companies (which develop and produce ITS). The systems or ‘modules’ to be developed by INFRASENS are components of the Infrastructure Platform and will be integrated within the applications to be implemented by the SCOBA and CoSSIB subprojects. The primary users for INFRASENS are therefore these applications, and in particular those defined by CoSSIB. They impose a series of specific requirements relating to the type of situation, conditions or event the systems need to detect (vehicle presence, traffic status, etc) as well as the necessary performance. The requirements of the Applications which have been defined so far by CoSSIB are presented in the deliverable D5.2.1. From the point of view of the overall design of the system, it is useful to also take into account a category of secondary users, consisting of those who will be affected by the implemented systems. The consideration of their needs helps to determine the general characteristics and qualities required of the platform, and hence the choice of technologies and other strategic decisions. All of these Users are listed in the table below. For each a brief description is provided of their role in relation to the infrastructure-based systems to be developed by INFRASENS and a summary of their ‘aspirations’ in relation to these systems. Each User Need will be allocated to one or more of the groups of users identified. As INFRASENS partners include representatives of several of the key Users: including road operators (ANAS), the car industry (CRF), service providers (SODIT, PTV, MIZAR), it was possible for them to give direct endorsement of the selected needs.




Table 1 List of INFRASENS Users or ‘stakeholders’

USER DESCRIPTION OF USER AND “ASPIRATIONS” Infrastructure Operator/Road Manager

A body or organisation (public or private) responsible for managing and maintaining the road infrastructure, i.e. road authority, motorway operator, etc.

Concerned that the SAFESPOT system will provide a value-added service which will increase the safety of the infrastructure for which they are responsible. They will also be concerned that the installation, maintenance or repair of the systems will result in a minimum disruption to traffic, and will need to have a map of all installations and access to relevant data.

Public Administration (e.g. Ministry of Transport)

A public body with responsibility for the transport network as a whole and the safety of the travelling public.

Concerned that the SAFESPOT system will result in a substantial reduction in the number of accidents, injuries and deaths caused by road accidents. This implies that the systems should be effective, and also that the costs of installing and running them should be low enough to allow widespread deployment. Will also need to be informed of any modifications required in the Highway Code and have access to information which can be used to ‘teach’ road users how to use such systems effectively.

Road Users a) Driver of Probe (equipped) Vehicle

b) Driver of other vehicles, including all 2-wheelers

c) Other road users, pedestrians, etc

Any person using the road infrastructure, including drivers of any vehicle (equipped or not): cars, commercial trucks, motorbikes, etc. and pedestrians. In relation to the Infrastructure Platform, the driver/riders are receivers of the safety-related information generated. All road users are also passive beneficiaries of the SAFESPOT systems.

Will be concerned that the information arrives in time to prevent accidents, is easy and rapid to assimilate, is accurate, reliable and available at all times.

Service Provider An organisation responsible for providing transport-related services to road users, including safety-related services as well as general information, emergency support for drivers, weather information, etc.

Will be interested in being able to receive relevant safety-related data from the INFRASENS systems, and may in some cases also be able to provide useful information for the Infrastructure Platform for incident detection.

Map provider

Special type of service provider who supplies digital maps which can act as databases or be visualized on board vehicles.

Supports sensing systems and the detection of safety critical situations by providing geometry and other local features at in-vehicle and infrastructure level. Will need to know the kind of data to be represented on the Local Dynamic Map.




USER DESCRIPTION OF USER AND “ASPIRATIONS” System producer

An organisation which will be involved in supplying the system components (hardware and software).

Will require sufficiently detailed specifications to allow the supply of components.

SAFEPOT Applications

The Applications to be implemented by the CoSSIB and SCOVA will be the ‘primary users’ of the INFRASENS systems, as these will be incorporated within them.

These applications impose a series of requirements on the INFRASENS systems relating for example to the objects and events to be detected, the system performance, etc. (Those relating to CoSSIB are listed in the report D5.2.1 and have been incorporated in the User Needs).

3.4 Summary and analysis of the User Needs As would be expected, the selection carried out by INFRASENS resulted in a final list which included many of the original EITSFA User Needs, required the modifications of others and the addition of some new ones. The relationship with the 9 groups defined in the European Architecture is summarized below. Table 2 Relationship between the EITSFA and INFRASENS Users Needs

EITSFA GROUP INFRASENS User Needs

1 GENERAL (Basic properties and qualities of the System Architecture)

This group has remained almost intact with the exception of some very high level architecture needs which are relevant to all subprojects, and will need to be taken into account at the SAFESPOT level.

2 INFRASTRUCTURE PLANNING AND MAINTENANCE

Source of a number of important User Needs relating to the maintenance of the infrastructure and reporting activities.

3 LAW ENFORCEMENT Source of a few needs associated with the respect of traffic laws and regulations, and the collection of related data (it should be noted that SAFESPOT will not be involved directly with enforcement activities).

4 FINANCIAL TRANSACTIONS

No relevant User Needs

5 EMERGENCY SERVICES

A few User Needs relating to safety-related information and detection regarding emergency vehicles (but not the management of such services).

6 TRAVEL INFORMATION AND GUIDANCE

Some User Needs concerned with the provision of safety-related information, including warnings and recommended actions for preventive safety.

7 TRAFFIC, INCIDENTS AND DEMAND MANAGEMENT

activities associated with incident management, exceptions management, speed management, and Vulnerable Road Users (VRUs).

8 INTELLIGENT VEHICLE SYSTEMS

This group, originally relating to Intelligent Vehicles, has been ‘translated’ into the User Needs for an Intelligent




Infrastructure. Many of the requirements relating to the CoSSIB Applications have been integrated, including those involving the detection of specific safety-critical conditions and events, system performance as well as warnings and alerts communicated through roadside equipment or sent to vehicles.

9 FREIGHT & FLEET MANAGEMENT

The group provided a few User Needs associated with detection of safety-critical conditions and provision of warnings involving commercial vehicles.

A total of around 90 User Needs were identified. In order to make them easier to consult, and also easier to use for generating the system requirements, it was decided to regroup them so that they reflect the main processes involved the overall qualities required of the INFRASENS platform. The four resulting groups are described in Table 3. Table 3 INFRASENS User Needs Groups

INFRASENS User Needs Group DESCRIPTION

GENERAL ARCHITECTURE & SYSTEM QUALITIES

The group includes those needs specifically related to the System Architecture and to the general INFRASENS system qualities.

DETECTION

The group includes the needs of detection concerning the capability of the SP2 system to detect and measure data. The needs in this group highlight data and information to be collected by the roadside sensing.

COMMUNICATIONS

The group includes the needs of communication, that means those needs concerning the capability of the SP2 system to exchange data and information both with the other SAFESPOT systems and with other external systems (TMC/TIC/UTC, etc.).

ALERTS/WARNINGS

The group includes the needs of alert, that means those needs concerning the capability of the SP2 system to give the proper alerts that can prevent safety critical situations.

The INFRASENS User Needs were renumbered according to these new groups. In order to maintain traceability to the EITSFA User Needs, the European reference number is given in the penultimate column, and the final column indicates whether the User Need consists of a modified version or is completely new. A last point to be underlined is that the User Needs included in the List refer to all the systems which the INFRASENS Platform could hypothetically support, not only those likely to be developed in the Applications.




3.5 How to read the User Needs table The INFRASENS User Needs are presented in the following table in which each User Need takes up one row. A brief explanation of the information give in the columns is given below.

Column Heading Description

ID_SP2 ID of the User Need for SP2

DESCRIPTION Description of the User Need, expressed in the following way: - System shall - if the item is mandatory - System shall be able to - if there are some conditions to apply to it - System shall enable - if some conditions apply to it.

SP2_GROUP Group of User Needs defined in SP2

DESCRIPTION Description of the User Need

USERS Category of SP2 User affected by the need

IDEITSFA/ other references

ID of the EITSFA User Need from which the SP2 one has been derived.

VAR SP2 Variation with respect to the original User Needs: M = modified; N = new




3.6 List of SP2 User Needs ID

_SP2

DESCRIPTION

Roa

d U

ser

(incl

- Pro

be V

ehic

les)

Roa

d M

anag

er

(Infra

stru

ctur

e O

pera

tor)

Publ

ic A

dmin

istr

atio

n

(e.g

. Min

. of T

rans

port)

Serv

ice

Prov

ider

Map

Pro

vide

r

Syst

em P

rodu

cer

ID E

ITSF

A/

othe

r ref

eren

ces

VAR

_SP2

1 General Architecture & System Qualities

1.01 General Features

1.01.01 The system shall be able to minimise the consequences of an incident on the road network for those travellers who are not involved. y y y 7.2.4.1

1.01.02 The system shall provide support to monitor for hazards involved in lane keeping, lane changing, entering and leaving high speed roads, and overtaking. y y 8.4.0.1

1.01.03 The system shall be able to enhance the vision of the driver in adverse visibility conditions, e.g. in fog y y 8.1.0.2 1.01.04 The system shall include applications for different types of roads (motorways, urban roads, etc.). y y y y y y 7.1.1.2 M 1.01.05 The system shall know where it is within the road network. y y y 6.4.0.3

1.01.06 The system shall enable the data that it stores to be extracted by an operator onto a variety of media and used for other purposes, or by other organisations. y y y y 7.1.0.8

1.01.07 The system shall be able to support a database of all speed limits on the road network. y y y 7.1.7.5

1.01.08 The system shall be able to support a database of safety margins for distances between vehicles and all other adjacent objects y y 8.3.0.3 M

1.02 Installation, Repair, Maintenance

1.02.01 The systems shall be capable of being repaired with minimum disturbance. y y y y y 1.08.01 M 1.02.02 The systems shall be easily maintainable with minimum disturbance. y y y y y 1.08.02

1.02.03 All the static information stored in the system (e.g. geometry of the network sections and intersections) shall be easily updatable y y y y

TeleAtlas #3.1/4 SP2 Use Case

N

1.02.04 The systems shall be easily installed with minimum disturbance. y y y y y - N

1.02.05 The systems shall be easily installed respecting any constraints imposed by the Road Manager Operators. y y y - N




ID_S

P2

DESCRIPTION

Roa

d U

ser

(incl

- Pro

be V

ehic

les)

Roa

d M

anag

er

(Infra

stru

ctur

e O

pera

tor)

Publ

ic A

dmin

istr

atio

n

(e.g

. Min

. of T

rans

port)

Serv

ice

Prov

ider

Map

Pro

vide

r

Syst

em P

rodu

cer

ID E

ITSF

A/

othe

r ref

eren

ces

VAR

_SP2

1.03 Quality of Data Content

1.03.01 The systems shall provide data with a stated minimum level of accuracy at all times. y y y 1.09.01 M 1.03.02 The systems shall check all input data for validity, whenever possible, and report failures. y y y 1.09.02

1.03.03 The systems shall check data values by comparing different sources, when available, so to ensure high-accuracy and completeness. y y y 1.09.03

1.04 Robustness

1.04.01 The systems shall be able to detect errors in operation, when higher integrity is required, e.g. for financial, security or safety reasons. y y y y y y 1.10.01

1.04.02 The systems shall be able to monitor each safety-related component (including software), warn the user (Infrastructure Manager) in case of problems, and disable it, or reduce it to a safe state. y y y y y 1.10.02 M

1.04.03 The safety-related systems shall be fault-tolerant. y y y y y y 1.10.03

1.04.04 The systems shall be reliable with respect to the legal and/or quality requirements needed for each application. y y y y y 1.10.04

1.04.05 The systems shall be able to operate in all potential climatic and traffic conditions. y y y y y 1.10.05

1.05 Safety

1.05.01 The system shall not do anything that might aggravate or cause an incident, or, in general, reduce road safety. y y y y y

7.1.0.3 7.2.0.2 7.2.0.3

1.05.02 The system shall operate in a manner that does not generate a safety hazard for its users. y y y y y 1.11.01

1.05.03 The system shall operate in a manner that does not encourage unsafe behaviour. y y y y y 1.11.02

1.05.04 The system shall operate in a safe manner during degraded modes of operation. y y y y y y 1.11.03

1.05.05 The system shall not obstruct traffic in any way but may slow down traffic for safety reasons. y y 3.1.0.4 M

1.06 Security




ID_S

P2

DESCRIPTION

Roa

d U

ser

(incl

- Pro

be V

ehic

les)

Roa

d M

anag

er

(Infra

stru

ctur

e O

pera

tor)

Publ

ic A

dmin

istr

atio

n

(e.g

. Min

. of T

rans

port)

Serv

ice

Prov

ider

Map

Pro

vide

r

Syst

em P

rodu

cer

ID E

ITSF

A/

othe

r ref

eren

ces

VAR

_SP2

1.06.01 The systems shall be capable of surviving accidental and intentional attacks on their integrity. y y y y y y 1.12.01 1.06.02 The systems shall provide protection against unauthorised access. y y y y y y 1.12.02

1.07 User Friendliness

1.07.01 The systems shall be simple and efficient for travellers to use, and easy to understand. y y y 1.13.02 2 Detection

2.01 Traffic

2.01.01 The system shall be able to monitor specific sections of the road network to provide the current traffic conditions (e.g. flows, occupancies, speed, densities, headway, etc.) as real time data. y y y 7.1.1.1

8.2.6.6 M

2.02.02 The system shall be able to detect the imminence of a collision y y 8.6.0.1

2.01.03 The system shall be able to detect "non-vehicle" incidents before they can escalate into traffic accidents, e.g. bad weather conditions, objects on the road, ghost drivers, etc. y y y y 7.2.5.1

2.01.04 The system shall be able to measure the characteristics (e.g. length, speed, etc.) of a vehicle automatically, whilst the vehicle is in motion. y 3.1.1.3 M

2.01.05 The system shall be able to provide support to detect the position of the vehicle relative to lane boundaries and/or roadway shoulders. y y y 8.4.2.1

2.01.06 The system shall be able to detect the presence of vulnerable road users, e.g. pedestrians, cyclists, animals, etc in order to provide safety related information y y y 7.1.12.2

8.5.3.3 M

2.02 Incidents

2.02.01 The system shall be able to detect that an accident has occurred and identify its location. y y y y 5.1.0.2 9.4.0.4 8.5.1.2

M

2.02.02 The system shall be able to classify all the types of incidents defined in the use cases y y y 7.2.2.2 M 2.02.03 The system shall be able to validate that an incident has occurred in order to minimise false alarms. y y 7.2.0.7 2.02.04 The system shall minimise the time between the occurrence of an incident and its detection. y y y y 7.2.0.6

2.02.05 The system shall be able to monitor the aftermath of an incident, regarding the aspects that involve the possible generation of new incidents (flow conditions, slippery road surface, etc) y y 7.2.4.2 M




ID_S

P2

DESCRIPTION

Roa

d U

ser

(incl

- Pro

be V

ehic

les)

Roa

d M

anag

er

(Infra

stru

ctur

e O

pera

tor)

Publ

ic A

dmin

istr

atio

n

(e.g

. Min

. of T

rans

port)

Serv

ice

Prov

ider

Map

Pro

vide

r

Syst

em P

rodu

cer

ID E

ITSF

A/

othe

r ref

eren

ces

VAR

_SP2

2.02.06 The system shall be able to collect and store as much data on each incident detected, in order to enable the possibility to produce incident data statistics, by time, type and location, performance of the incident detection system, etc.

y y y 7.2.2.1 7.2.3.1 M

2.03 Infrastructure

2.03.01 The system shall be able to support a database of the road network, infrastructure and road-side equipment. y y y y y 2.2.2.3

2.03.02 The system shall be able to receive information on the structural integrity of roads, bridges, tunnels, gantries, etc., in order to check that there is no safety critical damage. y y y 2.2.2.2 M

2.04 Weather

2.04.01 The system shall be able to measure the range of visibility and detect reductions caused by adverse weather and pollution conditions (but not darkness). y y y y 7.1.1.8

8.1.0.1

2.04.02 The system shall be able to measure and analyse the road surface (e.g. for black ice, water, ice) y y y y 8.5.3.1 M 3 Communications

3.01 Data handling and exchange

3.01.01 The system shall be able to retrieve, analyse, and process data from different combinations of sources y y y 6.1.2.5 3.01.02 The system shall be able to communicate with other parts of the infrastructure y y y y 8.2.4.1 M

3.01.03 The system shall enable bi-directional data communication with equipped vehicles. y y y y y y 6.4.2.3 8.2.4.1 M

3.01.04 The system shall be able to exchange traffic, travel and safety information with external centers TMC/TICs to enhance local information. y y y

2.1.0.1 7.2.2.3 9.5.2.11

M

3.01.05 The system shall be informed of the arrival of an emergency vehicle or assistance vehicle in order to warn other vehicles if necessary y y 5.2.0.4 M

3.01.06 The system shall know the position and the status of the assistance vehicles (e.g. salting, snow removing, etc.) and emergency vehicles on the road network y y y y SP5_UN23

3.01.07 The system shall be able to retrieve information about traffic lights characteristics, traffic lights profiles and traffic signs in order to support the drivers at the intersections y y y TeleAtlas

#1 SP2 N




ID_S

P2

DESCRIPTION

Roa

d U

ser

(incl

- Pro

be V

ehic

les)

Roa

d M

anag

er

(Infra

stru

ctur

e O

pera

tor)

Publ

ic A

dmin

istr

atio

n

(e.g

. Min

. of T

rans

port)

Serv

ice

Prov

ider

Map

Pro

vide

r

Syst

em P

rodu

cer

ID E

ITSF

A/

othe

r ref

eren

ces

VAR

_SP2

Use Case

3.01.08 The system shall communicate with other transport and non-transport information systems using "open" standard protocols. y y y 6.1.3.9

2.1.1.2

3.02 Infrastructure Maintenance Management

3.02.01 The system shall be able to receive infrastructure equipment status data remotely. y y 2.2.2.1 4 Alerts/Warnings

4.01 General

4.01.01 The system shall be able to provide safety related information to all drivers (probe vehicles and others) using an equipped part of the infrastructure. y y y y y 6.1.2.3 M

4.01.02 The system shall be able to provide information about various aspects of the road network, e.g. default speed limits, road hazards, junctions y y y y 8.2.5.3

4.01.03 The system shall be able to provide local safety warnings on dangerous sections and intersections (urban, motorway, etc.) of the road network based on current weather and traffic conditions. y y y 6.2.2.4

7.2.5.2

4.01.04 The system shall be able to provide an appropriate speed limit for given traffic, weather, visibility conditions, and road network characteristics. y y y y

7.1.7.2 7.1.7.3 8.5.3.2

M

4.01.05 The system shall warn the driver in case of excessive speed. y y y y SP5_UN39

4.01.06 The system shall warn the driver of its strange behaviour (e.g. trajectory conflicting with another vehicle) and provide support to all vehicles involved y y y y

SP5_UN45 SP5_UN46 SP5_UN47

4.01.07 The system shall activate alerts when the presence of a ghost driver is detected, in order to provide support to all vehicles interested (included the ghost-driver itself) y y y

SP5_UN26 SP5_UN27 SP5_UN28 SP5_UN29 SP5_UN30




ID_S

P2

DESCRIPTION

Roa

d U

ser

(incl

- Pro

be V

ehic

les)

Roa

d M

anag

er

(Infra

stru

ctur

e O

pera

tor)

Publ

ic A

dmin

istr

atio

n

(e.g

. Min

. of T

rans

port)

Serv

ice

Prov

ider

Map

Pro

vide

r

Syst

em P

rodu

cer

ID E

ITSF

A/

othe

r ref

eren

ces

VAR

_SP2

4.01.08 The system shall be able to provide support to warn a driver when the vehicle in front is too close. y y 8.3.1.2 M

4.01.09 The system shall alert pedestrian and cyclists by means of road-side installed warning devices (e.g. acoustically or flash light) if any dangerous situation occurs that might concern them. y y SP5_UN12

4.01.10 The system shall be able to set priorities for the safety information to be displayed to the drivers y y y TeleAtlas #1 SP2 UC N

4.02 Intersections

4.02.01 The system shall warn the driver in his turning manoeuvre in order to avoid collisions with oncoming vehicles, cyclists and crossing pedestrians, even in the case they do not obey right of way y y y y

SP5_UN01 SP5_UN02 SP5_UN03 SP5_UN04 SP5_UN05

M

4.02.02 The system shall warn the drivers when approaching the end of the tailback at an intersection y y y y SP5_UN16 4.02.03 The system shall support the driver approaching a complex intersection in finding the correct lane. y y y y SP5_UN17 4.02.04 The system shall inform or warn drivers, pedestrians and bikers in case of red light violation. y y y SP5_UN14 4.02.05 The system shall warn the driver about the status of the traffic lights. y y y SP5_UN18

4.03 Incidents 4.03.01 The system shall be able to warn surrounding drivers that a driver has a problem. y y 8.5.0.4 M

4.03.02 In case of an incident the system shall be able to alert the oncoming vehicles in order to avoid collisions y y y

SP5_UN31 SP5_UN36 SP5_UN37

M

4.03.03 In case of an incident the system shall be able to command drivers to change lane on multi-lane roads in order to avoid collision with stopped vehicles or other objects on the road y 7.1.5.2 M

4.03.04 In case of an incident the system shall be able to provide an appropriate speed limit to the oncoming vehicles in order to avoid collisions y y y SP5_UN32

4.03.05 In case of an incident the system shall be able to warn the oncoming vehicles on a possible pedestrian on the road event y y y SP5_UN34




ID_S

P2

DESCRIPTION

Roa

d U

ser

(incl

- Pro

be V

ehic

les)

Roa

d M

anag

er

(Infra

stru

ctur

e O

pera

tor)

Publ

ic A

dmin

istr

atio

n

(e.g

. Min

. of T

rans

port)

Serv

ice

Prov

ider

Map

Pro

vide

r

Syst

em P

rodu

cer

ID E

ITSF

A/

othe

r ref

eren

ces

VAR

_SP2

4.03.06 The system shall be able to warn the other vehicles of the arrival of emergency and assistance vehicles, their position, distance and driving direction y 5.2.0.1

5.2.0.4 M

4.03.07 The system shall give the appropriate support to allow the emergency vehicles to pass the intersections rapidly and safely. y y SP5_UN07 M

4.03.08 The system shall inform the emergency vehicles whether the infrastructure is giving them the priority y y SP5_UN10

4.03.09 The system shall alert the drivers when approaching assistance vehicles (event signalling, snow removal, etc), and to inform them of their position and status y y y SP5_UN20 M

4.04 Tunnels/Bridges

4.04.01 The system shall be able to provide alerts for bridges so that warnings of weather conditions, vehicle restrictions and closure can be provided. y y y y y 7.1.4.6 M

4.04.02 The system shall be able to provide safety related alerts for "tunnel" environments i.e. vehicle restrictions, fire detection, atmospheric pollution and closure. y y y y y 7.1.4.7 M

4.04.03 The system shall warn the driver of possible obstacles/hazards at the entrance of a tunnel. y y y SP5_UN52

4.05 Information Qualities

4.05.01 The system shall be able to provide accurate, credible, timely, and easy to comprehend traffic and travel information. y y y y y y 6.1.0.3

4.05.02 The system shall provide information which is consistent (and not conflicting) with other information being presented about the road. y y y 6.4.1.6 M

4.05.03 The system shall be able to manage concurrent events affecting a given part of the infrastructure (e.g. assigning the priorities to the alerts). y y 6.1.2.4 M

4.05.04 The system shall produce its output within a time that is sufficient to be useful for incident prevention. y y y y 1.13.04 M

4.05.05 The systems user interfaces (alerts, warnings, etc) shall use as far as possible standard graphic forms with the minimum text, a similar "look and feel" and similar display throughout Europe. y y y 1.13.01 M

4.05.06 The system shall be able to activate alerts (e.g. lights, VMS, etc.), either individually or in groups. y y y 7.1.3.4 M 4.05.07 The system shall normally provide messages from a finite set of well defined message texts. y y y 6.2.3.2 M 4.05.08 The system shall be able to run pre-defined incident mitigation strategies automatically. y 7.2.0.9




4 Technology Assessment In parallel with the “top down” approach through which the User Needs for the Infrastructure Platform were defined, a “bottom up” analysis has been carried out in order to provide an understanding of the potential of the technology to meet these needs. The technological aspects relevant to the Infrastructure Platform include: - the roadside sensing systems - the roadside safety alert systems - the communications technologies - the positioning aspects (geo-referencing of the ‘events’) - the digital maps for representation of geo-referenced data. The first two topics have been investigated in detail by INFRASENS and the conclusions are described below. Some initial indications of the requirements regarding communications are included in Part C, but more detailed analysis in collaboration with SINTECH with regard to communications between vehicle and infrastructure, positioning technologies and Local Dynamic Map is planned in the next stage of the project. The investigation of sensing technologies consisted of three elements: - a ‘state-of-the-art’ survey of technologies used for roadside sensing. This covered a wide range of systems are able to detect safety-related conditions affecting the driving environment. Detailed information has been collected on their technical and operational characteristics; - a technology review: an examination of the emerging options for sensing, positioning and safety alert systems, and analysis of their strengths and weaknesses in relation to the detection of safety-critical conditions; - an assessment of the enhancements and innovations required to meet the requirements of SAFESPOT. Discussion of possible new approaches for the future and an examination of the potential of innovative technologies, such as micro-sensing, and the use of wireless communications. The full content of the technology review and state-of-the-art survey can be found in PART B of this report. A brief summary is provided below of the main features and conclusions to serve as an introduction to the discussion of the technology requirements of future systems.

4.1 State-of-the-art survey A detailed template was designed for the technology survey in order to solicit information on all the features of interest to INFRASENS. These included the characteristics of the sensing technology, and also operational, performance and other features important to the system’s users (identified in Chapter 3).




The information in the templates falls into the following categories: SENSOR IDENTITY

• Sensor type • Technology used

PERFORMANCE

• type of measurements • accuracy of data • sensitivity and reliability of the system

OPERATIONAL FEATURES

• average life cycle • possible operational restrictions • installation location • annual maintenance frequency

COMMERCIAL CONSIDERATIONS

• purchase cost • installation cost • maintenance cost • annual repair cost • annual life cycle cost • commercially availability

COMMUNICATION SUBSYSTEM (relating to transfer of data between the sensing (or alert) system and data collection or processing units and/or an external centre (e.g. TMC);

• communication medium, • unit cost, • type of data measurements, • any intermediate devices, • data bandwidth, and • remote monitoring capabilities

POWER SUPPLY SUBSYSTEM

• energy requirements • capability of autonomous operation

OVERALL ASSESSMENT

• strengths/weaknesses of the system. The completed survey templates can be found in PART B. The characteristics of the principal technologies are summarised in Table 4 and a correlation between the technologies and the safety-related conditions or event that they can detect is shown in Table 5.




Table 4 Features of main technologies in terms of cost, maintenance, reliability, performance, etc Technology Cost*

Ease of Installation/ Ease of Calibration/ Maintenance

Reliability/ System Life/ Lifecycle Cost

Lanes/ Mounting

Accuracy of count/ speed/ classification/ Weather effect High (<5%); Medium (<10%); Low (>10%)

Communi- cation Bandwidth

Inductive Loop Low. $500-$800 per lane (purchase and installation).

Poor/ Excellent/ High

Generally meets all of the manufacturer’s performance criteria/ About 10 years/ Poor.

Single/ Under Pavement.

Excellent/ Fair/ Fair/ Low (Not affected by weather).

Low to Moderate

Pneumatic Road Tube

Low to Moderate. $200-$1700 per lane for purchase and installation.

Excellent/ Excellent/ Unknown

Generally meets some of the manufacturer’s performance criteria/ Around 3 years/ Fair.

Multiple/ Across pavement.

Fair to Poor/ Poor/ Unknown/ Medium (Snow removal equipment may damage tubes; Air switches sensitive to temperature).

Low

Magnetometer (Two-axis fluxgate magnetometer)

Moderate. $900-$6300 per lane for purchase and installation.

Excellent/ Excellent/ High to Medium

Generally satisfactory, i.e. according to manufacturer’s performance criteria/ Around 10 years; if battery used 4-10 years/ Excellent to Fair.

Single/ Core drilling hole, around 8 inches deep.

Excellent/ Excellent/ Fair/ Low (Not affected by weather).

Low

Magnetic (Induction or search coil magnetometer)

Low to moderate. $400-$2000 per lane for purchase and installation.

Fair/Fair/ Unknown

Generally performs satisfactorily i.e., according to manufacturer’s performance criteria/ Around 10 years/ Excellent to Fair.

Single/ Under pavement (inserted in 3 inch non-metallic conduit placed 21 inches under roadway.

Excellent/ Excellent/ Unknown/ Low (Not affected by weather).

Low

Microwave Low to moderate. Average cost $340 per

Excellent/ Excellent/

Generally meets some or few of the

Multiple/ Overhead (15-20

Excellent to Fair/ Excellent/ Poor/ Low

Moderate




Radar lane for purchase and installation.

Medium manufacturer’s performance criteria/ 5-10 years/ Excellent.

ft) or Sidefire (16-30 ft)

(Electromagnetic interference may occur if detector operates in vicinity of high power radars).

Microwave True Presence

Low to moderate. Average cost $700 per lane for purchase and installation.

Excellent/ Excellent/ Low

Generally meets some or few of the manufacturer’s performance criteria/ 5-10 years/ Excellent.

Multiple/ Overhead (15-20 ft) or Sidefire (16-30 ft)

Excellent/ Fair/ Fair/ Low (Electromagnetic interference may occur if detector operates in vicinity of high power radars).

Moderate

Active Infrared (Laser radar)

Moderate to high. Average cost $1300 per lane for purchase and installation.


Generally meets most of manufacturer’s performance criteria/ 5-10 years/ Poor.

Single/ Overhead (20-25 ft)

Excellent/ Fair/ Excellent/ Medium (Affected by snow and rain).

Low to Moderate

Passive Infrared Low to moderate. Average cost $450 per lane for purchase and installation.

Excellent/ Excellent. Sidefire installation difficult / Low

Generally meets all or some of the manufacturer’s performance criteria/ 5-10 years/ Excellent.

Single/ Overhead (15-30 ft); Sidefire (around 20 ft).

Fair/ Poor/ Poor/ Low (Not affected by weather).

Low to Moderate

Ultrasonic Low to moderate. Average cost $650 per lane for purchase and installation.


Generally meets all or some of manufacturer’s performance criteria/ 5-10 years/ Excellent.

Single/ Overhead (15-25 ft) or Sidefire (5-15 ft)

Excellent/ Poor/ Poor/ Low (Acoustic noise in audible or ultrasonic ranges could conceivably interfere).

Low

Acoustic Moderate. Average cost $500 per lane for purchase and installation.

Excellent/ Excellent/ Low to Medium

Generally meets all of manufacturer’s performance criteria/ 5-10 years/ Fair.

Single or Multiple/ Sidefire (25-40 ft).

Fair/ Excellent to Fair/ Poor/ High (Snow and extreme cold affect performance; Acoustic noise).

Low to Moderate

Optical Video Image Processor (or CCTV systems)

Moderate to high. Initial capital outlays may exceed costs of traditional methods, but VIDS have lower

Excellent/ Poor/ Medium

Generally meets all or some of manufacturer’s performance criteria/ Around 10 years/ Fair

Multiple/ Overhead or Sidefire (25-45 ft).

Excellent/ Fair/ Poor/ High (Light conditions; cold temperatures create exhaust plumes; Wind; Heavy Rain and

Low to High




installation and life-time costs. Communications costs can be high for digital video technology. Digital around three times more expensive than analogue technology. With existing transmission link, a colour CCTV camera with 20-year lifetime can cost $10,000- $50,000; cost of operation and maintenance $200 - $1,000 per year. Cost of CCTV camera tower with 20-year lifetime $18,000 - $50,000; maximum operations and maintenance costs $900 pa, not including software systems and algorithms required for surveillance.

snow reduce visibility).

Infrared VIP Same as active infrared. Same as active infrared.

Same as active infrared.



Moderate.

WSN Low. Around $300 per lane for purchase and installation.

Excellent/ excellent/ low maintenance

Still to be tested for road applications/ From a few hours to around 10 years/ Unknown.

Single/ Glued on pavement or mounted on node or guardrail.

Depends on the technology of the sensor or node.

Low.




Table 5 Correlation of sensing technologies and ‘events’ detected

Tabl

e N

o. *

Veh

icle

pre

senc

e

Occ

upan

cy

Den

sity

Vol

ume

(Flo

w ra

te)

Veh

icle

spe

ed

Inci

dent

det

ectio

n

Con

gest

ion/

Que

ue d

etec

tion

Driv

ing

wro

ng d

irect

ion

Sho

rt he

adw

ay

Vehi

cle

clas

sific

atio

n

Roa

d te

mpe

ratu

re

Vis

ibilit

y ra

nge

Fog

Roa

d S

urfa

ce -

Wet

Roa

d Su

rface

- Ic

e

Deb

ris a

nd d

ropp

ed c

argo

Peo

ple

/ Ani

mal

s

Roa

d el

emen

ts /

Junc

tions

Dan

gero

us c

urve

Optical 28 s s 25 26 27 s s c s s s Infrared 11 c c c

Passive Infrared

22 c c c c c s s s

Video Image Processing

15

c s c s s s s CCTV 24 c s c s s s s Piezoelectric

9 c c c

RFID/Radio Signals

16 s s s s s s s

14 s s s s s s s Laser scanner 5 s s s s s

Inductive loop

6

c c c c c c c

Triple tech 20 23 c c c c c c c

Doppl radar, microwave

10

c c c Magneto-meter

19 s s s s s s

Magneto-resistive

7 c c c c c c

Magnetic strips

17 c

Temperature /humidity

13 s s s s

Pneumatic tube

8 c c

Microphone 18 s s s

Maps 21

s s s s Sensor network

12 s s s s s

Key: c = consolidated results available; s = being studied. * Number of Table in Part B of this report containing the results of the Technology Survey.




The technologies surveyed are able to contribute to the identification of safety-critical events in all of the following categories: Traffic-related data (TRAF): information regarding aggregate characteristics of traffic including the existence of queues, occupancy rate, headway, etc. Vehicle status (VEH): information regarding the type and status of single vehicles, such as vehicle classification, weight, speed, etc. Environmental conditions (ENV): information regarding the road surface status and weather conditions, such as ice on the road, presence of fog, etc. Obstacle Ranging Systems (OBS): information on pedestrians, animals, rocks, debris or other physical objects that block the road; Infrastructure features (INFRA): information on the safety status of tunnels, bridges, etc, existence of dangerous bends, intersections, etc.

4.2 Analytical summary of the survey results The following table summarises the results of the technology survey. Table 6 Strengths and Weaknesses of Sensor Technologies

Technology Strengths Weaknesses Inductive Loop • Flexible design to satisfy large

variety of applications. • Mature, well-understood

technology. • Large experience base. • Provides basic traffic

parameters (e.g. volume, presence, occupancy, speed, headway, and gap).

• Insensitive to inclement weather such as rain, fog, etc.

• Provides best accuracy for count data compared with other commonly used techniques.

• Common standard for obtaining accurate occupancy measurements.

• High frequency excitation models provide classification data.

• Disruption of traffic for installation and repair. Installation and maintenance require lane closure.

• Failure associated with installation in poor road surfaces.

• Installation requires pavement cut.

• Improper installation decreases pavement life.

• Installation and maintenance require lane closure.

• Wire loops subject to stresses of traffic and temperature.

• Multiple detectors usually required to monitor a location.

• Detection accuracy may decrease when design requires detection of a large variety of vehicle classes.

Pneumatic Road Tube

• Quick installation for temporary data recording.

• Low power usage. • Low cost. • Simple to maintain.

• Inaccurate axle-counting when traffic volume is high.

• Temperature sensitivity of the air switch.

• Cut tubes resulting from vandalism and wear produced by vehicle tires.

Magnetometer (Two-axis fluxgate magnetometer)

• Less susceptible than loops to stresses of traffic.


• Some models transmit data over wireless RF link.

• Can be used where loops are

• Installation requires pavement cut.

• Improper installation decreases pavement life.

• Installation and maintenance require lane closure.

• Models with small detection




Technology Strengths Weaknesses not feasible, e.g. bridge decks.

• Less disruption to traffic flow than loops.

zones require multiple units for full lane detection.

Magnetic (Induction or search coil magnetometer)

• Can be used where loops are not feasible, e.g. bridge decks.

• Some models are installed under roadway without need for pavement cuts. However, boring under roadway is required.


• Less susceptible than loops to stresses of traffic.

• Installation requires pavement cut or tunnelling under roadway.

• Cannot detect stopped vehicles unless special sensor layouts and signal processing software are used.

Microwave Radar • Typically insensitive to inclement weather at the relatively short ranges encountered in traffic management applications.

• Direct measurement of speed. • Multiple lane operation

available.

• CW Doppler sensors cannot detect stopped vehicles.

• Antenna beam width and transmitted waveform must be suitable for the application.

• Doppler microwave sensors have been found to perform poorly at intersection locations as volume counters.

Microwave True Presence

• Good performance in inclement weather.

• Detects stopped vehicles. • Can operate in side-looking

mode for detecting multiple lanes.

• Vehicle occlusion may occur with side-looking sensor.

Active Infrared (Laser radar)

• Transmits multiple beams for accurate measurement of vehicle position, speed, and class.

• Multiple lane operation available.

• Operation may be affected by fog when visibility is less than 6 m or blowing snow present.

• Installation and maintenance, including lens cleaning, require lane closure.

Passive Infrared • Multizone passive sensors measure speed.

• Capable of day and night operation.

• Passive sensor may have reduced vehicle sensitivity in heavy rain, snow, dense fog, or overcast skies.

• Some models not recommended for presence detection.

Ultrasonic • Multiple lane operation available.

• Capable of over-height vehicle detection.

• Large Japanese experience base.

• Compact size ease of installation.

• Environmental conditions such as temperature change and extreme air turbulence can affect performance. Temperature compensation is built into some models.

• Large pulse repetition periods may degrade occupancy measurement on freeways with vehicles travelling at moderate to high speeds.

Acoustic • Passive detection. • Insensitive to precipitation. • Multiple lane operation

available in some models.

• Cold temperatures may affect vehicle count accuracy.

• Specific models are not recommended with slow moving vehicles in stop-and-go traffic.




Technology Strengths Weaknesses Optical Video Image Processor (or CCTV systems)

• Single camera and single processor can monitor multiple lanes and multiple detection zones/lane.

• Easy to add and modify detection zones.

• Rich array of data available. • Provides wide-area detection

when information gathered at one camera location is linked to another.

• Large vehicles mask smaller vehicles, which leads to undercounting.

• Tall vehicles can project their image into adjacent lanes, which leads to overcounting.

• Installation and maintenance, including periodic lens cleaning, require lane closure when camera is mounted over roadway (lane closure may not be required when camera is mounted at side of roadway)

• Performance affected by inclement weather such as fog, rain, and snow; vehicle shadows; vehicle projection into adjacent lanes; occlusion; day-to-night transition; vehicle/road contrast; and water, salt grime, icicles, and cobwebs on camera lens.

• Requires 15-21m height camera mounting (in a side-mounting configuration) for optimum presence detection and speed measurement.

• Some models susceptible to camera motion caused by strong winds or vibration of camera mounting structure.

• Generally cost-effective when many detection zones within the camera field-of-view or specialized data are required.

Infrared VIP • Rich array of traffic data available.

• Low cost-technology not yet available but currently under development.

Wireless Sensor Networks

• The network is flexible regarding its a) topology, b) technology (i.e. can combine a variety of different devices), c) communication modality.

• The network is self-organizing (set-up and maintenance).

• Some pre-processing is possible in the network nodes so data can be filtered locally; this enables fast extraction of the appropriate information for safety or other traffic management purposes.

• A network node can also include an alert system.

• Technology currently under development.

• Energy restrictions affect the communication bandwidth, as well as the storage and data processing capabilities.

• Implies weaknesses of the corresponding technology of the sensor that is attached to the network node.




4.3 Principal shortcomings of current systems The technology survey has highlighted several shortcomings in current sensing technologies with regard to safety-related applications. They include:

• High costs and high maintenance: many conventional systems are inappropriate for applications requiring widespread deployment due to their high cost and demanding maintenance requirements.

• Insufficient precision and reliability for preventive safety: this is in some cases due to inherent weaknesses in the current technologies. In others it is a result of having too few data inputs to be able to identify safety-critical events with the necessary degree of confidence (due to insufficient measurements, or degraded state of the sensors).

• High energy requirements: making it very difficult to install systems outside urban areas or on long stretches of road (Cabling represents a high percentage of the instalment costs in many cases).

• Slow warning actuation: warning systems based on collection of wide area data or human response (e.g. video monitoring) may be adequate for traffic management, but is too slow for accident prevention.

As already stated, to have a real impact on safety, sensing systems must be able to provide widespread coverage of the road network, be highly reliable and robust. One of the research priorities will therefore be to investigate the potential of emerging technologies to offer alternatives which are inexpensive, have low maintenance and low energy needs. INFRASENS is intending to investigate a range of technologies not currently used for detection in the transport field, but which appear to offer promising characteristics. These are described below.

4.4 Micro-technologies Among the most interesting new possibilities for detection are offered by the adaptation for roadside sensing of micro-technologies originally used for other purposes (e.g. military applications). Such detection systems are made up of a very large number of microsensors, or sensing nodes, which can be interconnected using digital radio communication channels. The sensors themselves may be extremely small – the smallest, referred to as ‘smart dust’, are practically invisible to the naked eye. These micro-electro-mechanical devices (MEMS) can employ many different kinds of technology: - accelerometers, - magnetometers, - microphones, - light diodes, - micro video cameras, etc.




They are able to measure physical parameters (such as noise, vibrations, etc) of a qualitative nature which are correlated to the level of traffic (free flow, dense traffic, queuing) or the occurrence of an accident, for example, which can be used for the detection of incidents affecting safety. Many of them can operate with small batteries and, if they have low energy needs, can be fully autonomous. Therefore sensors which do not require an additional energy supply either for their operation or for communications, have the great advantage of not needing any wiring. For roadside applications the low cost, small size and autonomous wireless operation of micro-sensors permits the easy and rapid installation of a full monitoring system. They have the added advantage of minimal maintenance requirements as the sensors can be considered ‘disposable parts’.

4.5 Wireless sensor network A network is likely to consist of a number of nodes with different functions. Some will act simply as radio repeaters, and others as ‘collecting nodes’ able to gather data from a number of sensors and transfer it to the roadside unit directly or through long range communication systems or networks (phone lines, satellite, cellular networks, etc). Each node consists of four principal blocks or elements: the sensing module, the processing module, the communication module and the power source or energy management module. All of these are controlled by the processing module, which is a low power microprocessor with the necessary software to carry out all the necessary activities (signal acquisition, processing, radio and energy management). The functions of each are briefly described below: a) the sensing module generally consists of one or more sensors whose role is to acquire the raw data with the highest possible sensitivity, but also the lowest power consumption. The sensing itself is likely to be carried out by micro-electro-mechanical devices (MEMS), which are very small and able to operate with capacitive (electrostatic) low power transducing techniques. MEMS integrate mechanical elements, sensors, actuators, and electronics on a common silicon substrate using micro-fabrication technology. They bring together silicon-based microelectronics with micromachining technology, creating complete ‘systems-on-a-chip’. b) the processing module will consist of one or more microprocessors and plays a central role within the node. It supports all the other elements with software routines which manage the sensing measurements, data storage, data compression and communications, as well as the radio receiver for dynamic configuration of the network, and the forwarding and repeating of service packets and data packets. It which will also be in charge of energy management: monitoring the battery status, self-sensing (the health) of the node and deciding the best operational strategy.




To keep the power consumption low, the amount of information transmitted must be kept to a minimum. This can be achieved with features such as variable clock speed, which means that the monitoring is continuous, but the processing system will ‘wake-up’ when an event occurs. The operating system and networking protocol must therefore be ‘power aware’.

Figure 2 Logical components of a network node c) the communication module consists of a simple radio system, capable of both receiving and transmitting digital data. The transmitted data which originates from the local node (pre-processed sensor data) or from other nodes is forwarded along a pathway toward the destination receiver. This module involves the physical side (radio chips, amplifiers, antennas ) and the protocol. Many universities are working on radio devices tailored for Wireless Sensor Network applications, so in the near future such devices could be available as commercial devices. But even here the power consumption must be taken in account For roadside-sensing there will be data flows between the main components. The node will collect data from the sensors, pre-process it and send it to the roadside unit. The application will fuse data from different nodes and sensors and recognize safety-relevant ‘events’. It will then make decisions about the actions that are necessary. This fused information can be send to the centre. Climbing up the levels, the amount of information is reduced, so we have a ‘distributed’ intelligence. The most important decisions are made at an intermediate level and guarantee faster reaction time. d) the power source is in charge of supplying energy to the nodes. For the detection of events, energy needs to be supplied continuously to the sensor

SE/AE

CM PS

PM Sensed Data

Network PS : Power Source CM: Communication module PM : Processing module SE : Sensor AE : Actuator




and the radio receiver so that they are always ‘awake’. On the other hand, for the processing element and the transmitting part of the communication element, it is sufficient for the energy to be available ‘on demand’ and for the minimum amount of time required for transmission purposes. The energy management module normally manages the batteries and limits consumption as much as possible. Recent modules are often able to ‘scavenge’ or harvest energy from the outside environment in order to recharge the accumulators and prolong the operational life of each node. Typical sources applicable to the road environment are vibrations, thermal energy, solar power, wind, etc. The limited amount of energy available at each sensing node and the constraints of radio-telecommunications limit the transmission power, and therefore the distance between sensors needs to be small. In order to meet the coverage requirements, they need to be distributed liberally so that they are close to each other and redundant (i.e. more than one is within range of the radio communications node). Data to be transferred to remote nodes or collecting stations not within the transmission range of the originating node can be forwarded by means of intermediate nodes in a series of ‘multi-hops’.

Figure 3 Function of node in reducing data volume One further function of the more sophisticated nodes is to reduce amount of information which needs to be sent to the roadside unit, thereby making the system more ‘reactive’ and also reducing the bandwidth for communication.

Level 3 Centre

Level 2 Roadside

Unit

Level 1 Node

Real world events

Actions alerts

Recognised events

Information path




By ‘pre-processing the data at an early stage, it is possible to ‘shortcut’ the information path. The above diagram shows the flows of information (data from sensors, processed data, events, commands to the alerts, etc). At the base of the "ladder" there is a large amount of data arriving from the sensors. Proceeding up the ladder, it is possible to reduce this amount by processing and filtering the data so that the ‘thickness’ is reduced. This means that even at the node level it will be necessary to take some decisions. For example if an accident is detected, it could be possible to immediately "close the loop" by sending a signal directly to the alerts, avoiding the need for the information to arrive at the MFO/control centre. Below is a summary of some of the main research challenges to overcome in relation to wireless sensor networks: - the identification of suitable power sources and energy scavenging techniques suitable for the road environment; - the identification of ways of using sensor networks in conjunction with conventional safety monitoring systems permitting the data streams to be merged to obtain more robust and precise information. - the combination of power sources which will permit the transmission of larger amounts of data (battery operated nodes can normally transmit only very limited transmission bandwidth which is suitable for slow data rate sensors, but not video or image based monitoring); - the need to resolve the security issues raised by wireless communications; - ways of ensuring rigorous validation of data to ensure it meets the stringent requirements of safety systems. (Due to the complex management of such networks, they tend to have non deterministic behaviour and relatively slow data transfer speed, which can affect the system’s reaction time). (Bibliographical references are provided at the end of this report.)




4.6 Local Dynamic Map (LDM) A further important element which it is intended to develop in SAFESPOT is the Local Dynamic Map. The purpose of the Local Dynamic Map is to provide a real world model which will support a co-operative approach to road safety. The concept is described in greater detail in the report D3.2.1 produced by SINTECH. A brief description is given here of the basic principles. The implications of the LDM for INFRASENS will be explored jointly with SINTECH in forthcoming phases of the project. One of the main features of the cooperative systems being developed by SAFESPOT is the ability to map temporary conditions affecting the driving environment. This involves the detection of safety-critical situations in the vicinity of a vehicle. In order to be able to interpret such data, it must be accurately ‘geo-referenced’. To be able to do this reliably and efficiently, it is also necessary to know the precise location of the sensors themselves. The sensors must know where they are in order to communicate their information to the outer world. A clear reference in the local dynamic map is needed to meet infrastructure sensing system requirements. In order to fulfill SAFESPOT requirements, state-of-the-art digital maps will therefore be enhanced to support the technologies that detect, capture and analyze environmental conditions. As well as an extension in the map content, based on the Geo-referenced Data Format (GDF) approach, SAFESPOT will need to identify a standardized way of integrating dynamic objects detected in the environment surrounding a vehicle within the static digital maps available today. The aim is to guarantee that all actors handing dynamic objects will have the same ‘virtual reality’ and therefore the same basic understanding of the situation at any given moment. However, the map itself can be seen as additional source of data providing input to the sensor systems. In order to analyse sensor data, map geometry (as static information) is essential especially for image and laser scanner processing. One important task of INFRASENS is therefore to clearly define the potential of the local dynamic map approach for the Infrastructure Platform and identify the conditions for providing, installing and maintaining such a system. In order to provide the Local Dynamic Map for infrastructure sensing, a clearly specified interaction process between nodes and roadside units is needed. The information transferred to the roadside unit needs to include information about the location of the event or incident. The roadside unit will collect all node information to derive warning or status messages on infrastructure level. At the in-vehicle level, the first step of defining an API towards the application according to the ADASIS approach has been done. At the infrastructure level, different approaches depending on the level of intelligence and capabilities might be considered. The current view of the local dynamic map is shown in Figure 4.




Figure 4 Architecture of the ‘Local Dynamic Map’ The Local Dynamic Map is envisaged as a four-layer geographical data base. The four layers of the LDM are briefly described below: - The bottom layer consists of the (quasi) static map from the digital map provider according to the conceptual approach of the GDF; - The second layer extends the static map with further attributes: static features regarding the driving environment which can serve as ‘landmarks’ for referencing and positioning. This new static data can be seen as a GDF extension for co-operative systems; - The third layer contains temporary local information such as weather, road or traffic conditions, and will deal with the dynamic object approach. - The top layer contains dynamic communication nodes as well as information about other road users detected by in-vehicle sensors. Information detected by roadside sensors can contribute to both the third and top layers, helping to build up an accurate three-dimensional database of the temporary local driving environment.

4.7 Potential for co-operative detection One of the most critical areas of research for SAFESPOT will be to identify the most effective approach to the cooperative detection of safety-critical events. A first step in this direction is represented by Table 5 which compares the contribution potentially made by road-based and vehicle-based sensing to the acquisition of data on events, conditions and measurements which enable




identification of safety-critical states (information relating to the latter was provided by SAFEPROBE). Although it gives only a very general idea of the potential sources of data, without indications of the accuracy or performance, it is evident that: - for the acquisition of many types of safety-related measurement there are a large number of alternative data sources; - the type of data provided varies enormously, not only in terms of the nature of the measurement (temperature, distance, humidity, vehicle presence, speed, etc), but also its nature (continuous, binary, discrete); - while some of the sensed data gives a high degree of reliability in detecting a given situation (e.g. airbag activation or roll-over detection as evidence of an accident), others provide just an indication (e.g. incident detection based on traffic flows) and may require confirmation from other sources to achieve the required degree of confidence. In developing a cooperative approach to detection, it is therefore essential to establish which measurements can be considered: alternative data sources: when more than one source data contributes to establishing the event information, it will be necessary to establish which provides the optimum performance (in terms of precision, reliability, costs, etc). Where vehicle-based data is concerned, this will also be influenced by the density of equipped vehicles on the road; complementary sources: when the available detected and/or processed data is insufficiently reliable, accurate or continuous for safety purposes, it will be necessary to identify the optimum combination of sources (or processing operations) to produce information output of the required quality. There are a number of different ‘cooperation strategies’: a) the two ‘extreme’ – but less complicated - cases consist of identification of a safety related ‘event’ by roadside detection (with warnings sent to roadside alerts and also equipped vehicles) and vehicle-based detection (with warnings sent to roadside alerts and other vehicles via the VANET (the ad hoc network enabling temporary communications between vehicles in a local area). b) a series of far more complex cases involve the co-operative identification of safety events (and warning strategies) based on data from roadside and vehicle sensors. It raises the difficult question of both where and how the various stages of fusion and other processing operations will be carried out. A joint INFRASENS/ SAFEPROBE work group has recently been set up to investigate this. Possible alternative approaches to the cooperative detection of safety-critical events or conditions are illustrated in Figure 5 (from the SAFEPROBE Report D1.2.2).




Table 7 Complementary data acquisition by roadside and vehicle-based sensors

ROADSIDE SENSING VEHICLE-BASED SENSING Category Technologies

INFORMATION/CONDITION USED TO DETECT SAFETY RELATED

EVENT Measurement/Source/Event Category

VEH Infrared, Video Image Processing, CCTV, Piezoelectric, Inductive loop, Triple tech (passive IR + Doppler radar + ultrasound), Doppler radar, Pneumatic tube

Vehicle presence Longitudinal and lateral distance from other (nearby) vehicles

EP

VEH Infrared, Piezoelectric, Doppler radar, Pneumatic tube

Vehicle speed

Vehicle speed Relative velocity Relative acceleration

VDM EP EP

VEH Infrared, VIP, CCTV, Piezoelectric, RFID, Laser scanner, Inductive loop, Triple tech, Doppler radar, Magnetometer

Vehicle classification Vehicle ID BM

VEH Vehicle position GPS (numerous different position measurements)

NAV

TRAF Inductive loop, Triple tech, Magnetometer Traffic density TRAF Inductive loop, Triple tech, Magnetometer Traffic volume (flow rate) TRAF Inductive loop, Triple tech, Microphone

(plus detection algortihms) Incident detection / accident Emergency brake

Airbag fired Seat belt locked Roll-over detected

VDM OSS OSS OSS

TRAF Laser scanner, inductive loop, Triple tech, Magnetometer

Congestion/Queue detection Idle mode (engine) Brake light Brake pedal touched

VDM VDM VDM

TRAF RFID, Laser scanner Driving in wrong direction




ROADSIDE SENSING VEHICLE-BASED SENSING Category Technologies

INFORMATION/CONDITION USED TO DETECT SAFETY RELATED

EVENT Measurement/Source/Event Category

TRAF Infrared, VIP, CCTV, RFID, Laser scanner, Headway to vehicle in front ACC sensor Laser sensors

VDM EP

TRAF Inductive loop, Triple tech, Magnetomoeter Lane occupancy ENV Infrared, RFID, Thermometer Road surface temperature (Air temperature) (BM) ENV VIP, CCTV, Laser scanner Visibility range ACC vision

Laser scanner BM BM

ENV VIP, CCTV, Laser scanner, Thermometer Presence of fog Fog light on Outdoor temperature

BM BM

ENV Optical, Humidity sensor Rain (Road surface – Wet) Windscreen wiper Rain detector

BM BM

ENV Optical, Infrared Ice (Road surface – Icy) Outdoor temperature Heating (rear screen)

BM BM

OBJ VIP, CCTV, Laser scanner Dropped cargo OBJ VIP, CCTV, Laser scanner Debris (rocks, trees, etc.) OBJ Infrared, VIP, CCTV, Laser scanner Presence of people / animals INFRA RFID, Maps Road elements / junctions INFRA RFID, Maps Dangerous curve KEY: VEH = vehicle characteristic, TRAF = traffic status, ENV = environmental conditions, OBJ = object detection, INFRA = infrastructure feature. Vehicle-based sensing: VDM = Vehicle dynamics management, BM = Body Management, OSS = Occupant Safety System, EP = Environment perception, NAV = Navigation.




Figure 5 Data paths for cooperative event detection (source C. Zott et al)




4.8 INFRASENS research strategy In the long term, if safety-oriented systems are to be implemented on a large scale, it is clear that a new generation of roadside sensing technologies will have to be developed. There seems little doubt that these will include various types of micro-sensor, linked in wireless networks. If INFRASENS is to “look to the future”, then it is essential to investigate the potential of such approaches. Although they show great promise, there are still serious difficulties to overcome and various practical aspects which need to be better understood. The use of such technologies will also involve the development of new techniques for processing the data acquired. However, in the more immediate term, there are also valuable enhancements to be made to conventional systems, and improvements in performance which can be achieved by combining different technologies. It is also necessary to consider how legacy systems can be usefully integrated. For this reason, INFRASENS intends to adopt a ‘composite’ research strategy including:

a) The experimentation with different micro-sensor technologies to discover their suitability for roadside sensing (i.e. their ability to produce measurements which effectively identify safety-related ‘events’):

b) The examination of various wireless technologies to identify the most suitable, and investigation of related security issues;

c) The experimentation with energy harvesting techniques and ways of achieving energy savings;

d) The development of enhancements to existing technologies; e) The investigation of new combinations of sensing technologies; f) The development of specially-tailored of middleware to integrate all

the subsystems involved in an infrastructure-based safety system; g) An examination of how data sensed at the roadside can be integrated

in the Local Dynamic Map and how the map, as a geo-referenced database, can be used to enhance incident detection by roadside units;

h) the development of improved data fusion techniques to enable the merging of non-homogeneous data (conventional and non conventional measurements, as well as data from mobile and static sources;

i) the development of innovative incident detection algorithms able to incorporate data from vehicles as well as roadside sensing and to produce high quality information on safety-related events;

j) the development of roadside systems which can provide real-time warnings to passing vehicles to enable drivers to avoid accidents.

An outline of the potential (or capabilities) of technology to achieve enhanced roadside sensing and actuation is given in Chapter 5. The descriptions are simply intended to give an indication of the direction of possible future developments; the details of the actual development to be undertaken and the applications of the various technologies will be established at a later stage in response to the requirements of the SAFESPOT Applications.




5 Technology Capabilities The aim of this chapter is to present the features of the sensing technologies, data processing methods, maps, etc. which are being proposed as part of the Infrastructure Platform. The intention is to give a tentative overview of the potential of the various technologies, and an indication of the Use Cases to which they could contribute. More detailed matching of this potential with the requirements of the applications will be undertaken jointly with SAFEPROBE in the next stage of the project. The two main objectives of the Technology Capabilities are therefore: - to clarify and define the relative duties and responsibilities of the technical subprojects, especially the two focusing on the road infrastructure, CoSSIB (SP5) and INFRASENS (SP2) in order to avoid overlapping. - to make an effort to correlate the technology developments foreseen in INFRASENS and the CoSSIB / SCOVA Use Cases. It is important to establish close collaboration between these subprojects in order to ensure a safety enhancing overall SAFESPOT System. INFRASENS’ Technology Capabilities and the SP5/SP4 Use Cases, have as far as possible to be compatible. The following formal template has been used for explaining the Capabilities. It includes all information considered to be necessary for a detailed description. Table 8 Template for Technology Capabilities Name Capability headline including the mainly used technology (e.g. RFID) ID Format: SP<SP-Nr>_TC<No>_V<Version>, e.g. SP2_TC11_v1.1 Author Author’s name and company Status Draft or Final

Brief description A short executive summary of the technology capability including a drawing.

Innovation Brief description of the enhancement achieved by using the innovation. Driving environment The road types the capability is referred to Purpose A brief description of the purpose Trigger The action / event on the system which triggers this capability. Frequency of occurrence How often is the situation expected to occur. Sensing system List of sensing systems which are useable within this capability External data sources

List of external data / information sources which are useable within this capability

Description of process steps Step Process step

short name of the step 1 The steps of the capability from triggering event to goal delivery 2 … Related Use Cases (SP4 / SP5) The id(s) of use case of SP4 / SP5 related to this capability.

Open issues Comments




The table below lists all the INFRASENS Technology Capabilities described in the completed templates. Table 9 List of INFRASENS Technology Capabilities Technology Capability ID Technology Capability Name

SP2_TC01_V1.0 Pattern recognition for detection of too short headway

SP2_TC02_V1.0 Camera technology for detection of obstacle on road

SP2_TC03_V1.0 Terrestrial laser scanning for junction visibility map

SP2_TC04_V1.0 RFID for wrong way detection

SP2_TC05_V1.0 Laser scanner for V2I cooperative intersection sensing

SP2_TC06_V1.0 Extended Cooperative Automatic Incident Detection

SP2_TC07_V1.0 RFID for curve overshooting prevention

SP2_TC08_V1.0 RFID for short headway to front vehicle detection

SP2_TC09_V1.0 Sensors for support in poor visibility conditions

SP2_TC10_V1.0 NIR and thermal imaging for detection of animals

SP2_TC11_V1.0 VIP for detection of vehicle behind a blind corner

SP2_TC12_V1.0 Optical methods for detection of ice or snow on road

SP2_TC13_V1.0 Sensors for assessing trajectories in intersections

SP2_TC14_V1.0 CCTV camera for detection of daytime fog and visibility

SP2_TC15_V1.0 RFID network for driver warning

SP2_TC16_V1.0 Local Radio Warning System

SP2_TC17_V1.0 Data fusion for risk assessment for road segments

SP2_TC18_V1.0 Data Fusion supporting the Safe Urban Intersection

SP2_TC19_V1.0 Local Dynamic Map to support detection

SP2_TC20_V1.0 Local map reference for infrastructure data exchange

SP2_TC21_V1.0 Middleware Platform for safety system interface

SP2_TC22_V1.0 Wireless Sensor Network for obstacle detection The table on the following page indicates the links between the Technology Capabilities and the Use Cases defined by SCOVA and CoSSIB (SP4 and SP5) which are the subprojects responsible for the SAFESPOT Applications.




Table 10 Link between Technology Capability and SP4/SP5 Use Cases Technology Capability ID Driving Environment Main Technology Related

SP4 UC Related SP5 UC

SP2_TC01_V1.0 Motorways, rural roads Advanced pattern recognition methods

SP4_UC – 5a SP4_UC – 5b SP4_UC – 6a SP4_UC – 6b SP4_UC – 6c SP4_UC – 7c

SP5_UC11 SP5_UC12 SP5_UC13 SP5_UC14 SP5_UC23 SP5_UC51 SP5_UC53 SP5_UC541

SP2_TC02_V1.0 Motorways, rural roads High resolution camera technology

SP4_UC – 1a SP4_UC – 10a SP4_UC – 7b

SP5_UC14 SP5_UC17 SP5_UC131 SP5_UC43 SP5_UC45

SP2_TC03_V1.0 Traffic junctions Terrestrial laser scanning

SP5_UC22 SP5_UC31 SP5_UC33 SP5_UC52

SP2_TC04_V1.0 Motorways, rural roads RFID SP5_UC34 SP5_UC23

SP2_TC05_V1.0 Urban intersection Laser scanner SP5_UC22 SP5_UC55 SP5_UC31 SP5_UC33 SP5_UC52

SP2_TC06_V1.0 Motorways Incident Detection SP5_UC13 SP5_UC14 SP5_UC51

SP2_TC07_V1.0 Motorways, rural roads RFID SP5_UC32 SP5_UC411 SP5_UC412 SP5_UC42 SP5_UC45

SP2_TC08_V1.0 Motorways, rural roads RFID SP5_UC42 SP2_TC09_V1.0 Any with low visibility Photodiodes/

Piezoresistive SP4_UC – 2c SP5_UC11

SP5_UC15 SP5_UC45

SP2_TC10_V1.0 Motorways, rural roads NIR and thermal imaging

SP5_UC17

SP2_TC11_V1.0 Urban Area inexpensive camera system

SP4_UC – 1b SP4_UC – 4c SP4_UC – 7a

SP5_UC22 SP5_UC52 SP5_UC55

SP2_TC12_V1.0 Motorways, rural roads SP5_UC411 SP5_UC412 SP5_UC42 SP5_UC44

SP2_TC13_V1.0 Intersections Loops, microwave, CCTV, radar, laser

SP5_UC55

SP2_TC14_V1.0 Motorways, rural roads CCTV camera SP5_UC42 SP2_TC15_V1.0 Black spots, tunnels,

urban canyons RFID

SP2_TC16_V1.0 Any type of road Radio broadcast SP5 – UC51 SP2_TC17_V1.0 Motorways, rural roads Data Fusion and

interpretation SP4_UC – 6b SP4_UC – 6c

SP5_UC411 SP5_UC412




SP4_UC – 8a SP4_UC – 9a


SP2_TC18_V1.0 Urban Area Data Fusion SP4_UC – 1a SP4_UC – 1b SP4_UC – 1c SP4_UC – 1f SP4_UC – 1d


SP2_TC19_V1.0 Any road type Local Dynamic Map SP2_TC20_V1.0 Any road type Local Dynamic Map SP2_TC21_V1.0 Any road type Middleware SP2_TC22_V1.0 Motorway, rural roads Wireless Networks SP5_UC11

SP5_UC12 SP5_UC13 SP5_UC14 SP5_UC15 SP5_UC16 SP5_UC17

Table 11 Overview of the CoSSIB Use Cases (from D5.2.1)

Use Case ID Use Case Headline Obstacles SP5_UC11 Safety margin for maintenance vehicle on snow removal or salting

operation. SP5_UC12 Assistance vehicle patrolling or signalling a traffic event on a road SP5_UC13 Accidents as obstacles SP5_UC14 Traffic jams as obstacles (slow moving vehicles) SP5_UC15 Traffic Jam as an obstacle results of an accident, with poor visibility. SP5_UC16 Deviations for road-works SP5_UC17 Pedestrian on motorway Misjudgement (“wrong behaviour”) SP5_UC21 Prevention and management of the inattention of the driver SP5_UC22 Safe signalized intersection (crossing, turning) SP5_UC23 Overtaking on a two way road (infra-scenario only) Rule violation SP5_UC31 Safe signalized intersection (red light violation) SP5_UC32 Prevention of Driver Excessive Speed SP5_UC33 Right of way (stop sign), not signalized roads SP5_UC34 Ghost drivers (wrong way driving) Critical environment conditions (including infrastructure) SP5_UC411, SP5_UC412

Prevention for the Lack of adherence of the road

SP5_UC42 Prevention of Driver excessive Speed (critical environment.) SP5_UC43 Entering into a tunnel SP5_UC44 Exiting from a tunnel SP5_UC45 Sudden reduced visibility (geometric) Safety improving driver assistance (incl. safety margin) SP5_UC51 Assistance vehicle signalling a traffic event on a road




SP5_UC52 Emergency vehicle is approaching a controlled intersection SP5_UC53 Junction of two motorways (merging and separation) SP5_UC541, SP5_UC542

Access or exit of a motorway (at junction)

SP5_UC55 Driver assistance for complex urban intersections

Table 12 Overview of the SCOVA Use Cases

Use Case ID Use Case Headline Use Cases for the LATC cluster SP4_UC_Accident at intersection – 1a A crash happens at an intersection SP4_UC_Obstructed view at intersections – 1b

Obstructed view at intersections

SP4_UC_Permission denial to go-ahead – 1c

Due to a detected dangerous situation the driver is not allowed to go ahead

SP4_UC_Defect traffic lights – 1d Validation of defect or false traffic lights SP4_UC_Other vehicle brakes hard due to red light – 1e

Other vehicle brakes hard due to red light

SP4_UC_Approaching Emergency Vehicle Warning – 1f

Approaching Emergency Vehicle Warning

SP4_UC_LaneChangeManoeuvre – 2a Lane Change manoeuvre for Trucks with blind spot

SP4_UC_LaneChangeManoeuvre – 2b Lane Change manoeuvre for Car/Trucks SP4_UC_LaneChangeManoeuvre – 2c Lane Change manoeuvre for Trucks in extended

on ramp in motorways SP4_UC_SafeOvertaking – 3a Safe Overtaking in urban and semi-urban roads SP4_UC_SafeOvertaking – 3b PTW overtaking OV while OV is turning left to

park area SP4_UC_SafeOvertaking – 3c PTW overtaking OV while OV is turning left Use Cases for the LONC cluster SP4_UC_HeadOnCollisionWarning – 4a Head On Collision Warning due to hazardous

overtaking attempt by host vehicle. SP4_UC_HeadOnCollisionWarning – 4b Head On Collision Warning due to hazardous

overtaking attempt by a second vehicle. SP4_UC_HeadOnCollisionWarning – 4c Head On Collision Warning due to the presence of

bus climbing down through a hairpin curve. SP4_UC_RearEndCollision – 5a Rear End Collision due to heavy vehicle climbing

up through a hairpin curve at a low speed. SP4_UC_RearEndCollision – 5b Rear End Collision due to the presence of an

slower vehicle at the end of a hilly road segment. SP4_UC_SpeedAndDistance – 6a Speed limitation and Safety Distance and trucks

driver recommendations SP4_UC_SpeedAndDistance – 6b Safety Margin Assistant on black spots - tunnels SP4_UC_SpeedAndDistance – 6c Safety Margin Assistant on black spots –

reduction of lanes SP4_UC_FrontalCollisionWarning – 7a Frontal collision warning due to static obstacle in

front SP4_UC_FrontalCollisionWarning – 7b Frontal collision warning due to static obstacle in a

tunnel




SP4_UC_FrontalCollisionWarning – 7c Frontal Collision Warning due to abnormal vehicle behaviour in front

Use Cases for the RODP cluster SP4_UC_RoadConditionStatusV2I – 8a Road Condition Status – V2I Based SP4_UC_RoadConditionStatusV2V – 8b Road Condition Status V2V Based SP4_UC_CurveWarning – 9a Curve Warning in rural black spots, based on a

transponder in the infrastructure. Use Cases for the VURU cluster SP4_UC_VRUAccidentAvoidance – 10a Vulnerable Road users crossing a road SP4_UC_VRUAccidentAvoidance – 10b VRU in blind spot – truck turning right

Figure 6 Relations between the Use Cases of SP4 and SP1 (from D4.2.3)




TC01 Pattern recognition for detection of too-short headway Name Pattern recognition for detection of too short headway ID SP2_TC01_V1.0 Author Matti Kutila, Jukka Laitinen, Seppo Rantala (VTT) Status Final

Brief description

The distance between two cars can be detected with extracting the edges of a car, thus providing opportunity to measure time to collision information to a driver. The methodology is developed for the in-vehicle collision warning system, but may potentially be adapted to the road side sensing as well by additionally developing the system's robustness in the outdoor weather conditions (rain, sun shine, snow, etc.).

Innovation The use of advanced pattern recognition methods in the estimation of headway.

Driving environment Motorways, rural roads

Purpose Prevent potential accident with the lead vehicle.

Frequency of occurrence

Fatigue or aggressive driving are frequent reasons for paying inadequate attention for headways to a lead vehicle, therefore providing potential accident risk if the front vehicle starts braking. 19% of accidents on motorways in Italy are head-tail crashes.

Trigger -

Sensing system

The distance between two cars can be detected with extracting the edges of a car, thus providing opportunity to measure time to collision information to a driver. The methodology is developed for the in-vehicle collision warning system, but may potentially be adapted to the road side sensing as well by additionally developing the system's robustness in the outdoor weather conditions (rain, sun shine, snow, etc.). Research and development work is needed for adapting the methodology to road side sensors and for optimising the proposal of Yao-Jan et al.

External data sources -


Development of detection system 1 Adapting in-vehicle collision system to road side sensing.

Evaluation of sensor system 2

For accuracy and sensitivity analysis a test system is build. Available types of data measurements:

- Vehicle presence - Speed




Related Use Cases (SP4 / SP5)

The described Technology Scenario is related to the SP4 and SP5 application dealing with potential accident with the lead vehicle.

- SP4_UC_RearEndCollision – 5a (Rear end collision due to the presence of an heavy vehicle climbing up through an hairpin curve at a low speed)

- SP4_UC_RearEndCollision – 5b (Rear end collision due to the presence of an slower vehicle at the end of a hilly road segment)

- SP4_UC_SpeedAndDistance – 6a (Speed limitation and safety distance and trucks driver recommendations)

- SP4_UC_SpeedAndDistance – 6b (Safety margin assistant on black spots – tunnels)

- SP4_UC_SpeedAndDistance – 6c (Safety margin assistant on black spots – reduction of lanes)

- SP4_UC_FrontalCollisionWarning – 7c - SP5_UC11_v1.1 (Safety margin for maintenance vehicles.) - SP5_UC53_v1.0 (Junction of two motorways) - SP5_UC12 - SP5_UC13 - SP5_UC14 - SP5_UC23 - SP5_UC51 - SP5_UC541


TC02: Camera technology for detection of obstacle on road Name Detection of obstacle 500 m ahead on a road ID SP2_TC02_V1.0 Author Matti Kutila, Jukka Laitinen, Seppo Rantala (VTT) Status Final

Brief description

The dropped cargo lies in range of 500 m front of the car, which in one hand will reduce the flow capacity of a road and may cause hazard in near future if the driver is unknown of the on-coming incident and continuous with the normal speed.

Innovation

Latest camera technology (with high resolution images and control functions) may enable system, which can take charge of long roadways. Drivers can prepare to the dangerous situation by warning system, which uses infrastructure to vehicle communication.





Purpose Prevent potential hazard occurrence (obstacle). Frequency of occurrence

Accident as an obstacle represents about 14.4% of fatal accident on highway. Moreover, it is a large source of congestion.

Trigger -

Sensing system

The static obstacles on a road can be detected with subtracting images if the proper environmental adaptation is implemented. However, the basic problem is that the roadside sensors are statically located and obstacle on road information is useless for the driver if the information is given in the visible range. The VTT's knowledge in the sensor network field can utilised for including the communication capability to the sensor units, which then may provide the information to the driver already at "start" of the intelligent road. There, the image processing unit recognised the potential risk and delivers the information to the network nodes. The node, which is nearest to the car, transmits the message to the driver.

External data sources -


Development of detection system 1 Choosing sensor for evaluation and data communication

method. Evaluation of detection and communication system

2 For response time analysis a test system is build. It will consist of detection system and network structure.


The described Technology Capability is related to the SP4 and SP5 application dealing with envisioned reduced traffic safety.

- SP4_UC_Accident at intersection – 1a - SP4_UC_FrontalCollisionWarning – 7b (Frontal collision

warning due to static obstacle in a tunnel) - SP4_UC_VRUAccidentAvoidance – 10a (Vulnerable Road

users crossing a road) - SP5_UC131_v1.0 (Accident as an obstacle) - SP5_UC43_v0.1 (Entering into a tunnel) - SP5_UC45_v1.0 (Sudden reduced visibility (geometric) - SP5_UC14 - SP5_UC17





TC03: Terrestrial laser scanning for junction visibility map Name Terrestrial laser scanning for junction visibility map ID SP2_TC03_V1.0 Author Tamas Lovas, Arpad Barsi (BME) Status Final

Brief description

Junction visibility is a very important safety issue in many black spots. Drivers often do not recognize the approaching vehicles because they are hidden by vegetation, buildings or other man-made objects. Black spots can be easily mapped applying terrestrial laser scanning. Analyzing the 3D junction models, the visibility range and area can be derived for each relevant road segments. A visibility map example can be seen below (the hatched area is visible to the driver):

Innovation Applying state-of-the-art (accurate, rapid, affordable) terrestrial laser

scanning technology for visibility mapping. Driving environment Traffic junctions

Purpose Derive the visibility range for each connecting road segments in a junction

Frequency of occurrence -

Trigger -

Sensing system Terrestrial laser scanners are to be used in order to derive the 3D junction models

External data sources

The 3D models are to be built up onto a base map (e.g. navigation map segment)


Acquisition planning 1 It has to be decided which traffic junctions have to be mapped. Junctions surrounded by buildings, or dense vegetations can be the subjects of surveying.

Data acquisition 2 The junctions are to be scanned from different scanning positions in order to get all the hidden objects, obstacles which can block the drivers view.




Data processing 3

The data have to be processed in an appropriate CAD and/or GIS environment in order to derive the 3D model of the junction and to compute the particular visibility ranges for the drivers approaching from all the connecting roads.



Open issues

Comments Not part of the sensing system; can be included as external information source. The resulted visibility information can be transmitted to the driver (e.g. via RFID technology) if needed (e.g. extremely blocked visibility area).

TC04: RFID for wrong way detection Name RFID for wrong way detection ID SP2_TC04_V1.0 Author Jacques Ehrlich, Nicolas Hautière (LCPC) Status Final

Brief description

Wrong way vehicles can cause very serious accident especially on motorway. It is important to detect this kind of event as soon as possible in order to notify the wrong way driver and to alarm other drivers about a situation potentially dangerous. Up to now, there is not any system available on the market, but researchers are working on different tracks: solution based on digital maps and GPS, solution based on roadside detection equipment etc. Wrong way vehicles detection is also possible with RFID. Compared to other solutions, RFID is interesting because it is a multi-purpose applications device. Thus a given RFID tag can be used not only for wrong way detection but also for curve overshooting prevention, ISA application, on-board road sign displaying etc.

Innovation

- Passive detection of wrong way vehicles through use of RFID tags under the road surface and a reader in the car

- No additional sensors needed from the infrastructure point of view

- Multi-application devices Driving environment Motorways, rural roads

Purpose Wrong way detection

Trigger Due to misjudgement, aggressive violation or vigilance decrease, the driver make a half turn changing cruising direction or enters in the wrong way either at the interchange or when leaving a parking or a service area.

Frequency of occurrence How often is the situation expected to occur.




Sensing system

Two tags, located under the road surface and spaced out a few meters apart are sufficient to detect wrong way drivers. One solution consists in giving the two tags increasing ID numbers when driving in the good way. As soon as the vehicle's reader detects decreasing ID numbers, it means that the vehicle is currently in the wrong way. Thus it becomes possible to notify to the wrong way driver with an alarm message. Providing information to other drivers is not possible with this technology and requires V2I and I2V capabilities and a control centre to centralize, verify and broadcast the information. Other solution based only one tag is possible, but it requires more equipment on vehicle (GPS).



short name of the step 1 A vehicle enters in the wrong way

2 The vehicle passes over two tags spaced out a few meters

3 The vehicle detects deceasing ID numbers

4 A alert is message is generated or broadcasted to other vehicles or to the TMC.


SP5_UC34 SP5_UC23





TC05: Laser scanner for V2I cooperative intersection sensing

Name Laser scanner and V2I cooperative intersection sensing (Vehicle/Pedestrian/Bike Detector)

ID SP2_TC05_V1.0 Author Florian Ahlers (IBEO) Status Final

Brief description

Co-operative sensor fusion for object detection, tracking and classification based on Laser scanner raw data, V2I communication information and static map data.

The stand alone performance of detection, tracking and classification of road users (e.g. cars, trucks, bikes, pedestrians) within the vicinity of an urban intersection can be enhanced by using co-operative information. This will lead to a more robust and reliable description of the current intersection situation with all its road users.

Innovation

The sophisticated cooperative approach of fusing Laserscanner data with vehicle information transferred via V2I combined with additional information from a digital static map improves the accuracy, reliability and robustness of the description of the current intersection situation with all its road users significantly.

Driving environment Urban intersection

Purpose The purpose is to generate a reliable and robust description of the current intersection situation. This is the basis for many alert applications which are based on situation analysis and road user prediction algorithms (e.g. left turn assistance).

Trigger - Frequency of occurrence Continuously

Sensing system - 2 roadside Laserscanners detecting road users - in-vehicle sensors detecting actual vehicle state reported via V2I

such as turn signal status, velocity, position, steering angle etc.





Static Digital Map information e.g.: - road / sidewalk shape - lanes - landmarks


data acquisition 1

As soon as a vehicle enters the V2I communication range it is triggered to send its data (e.g. position, velocity, size, mass) to the roadside node. At the same time the Laserscanner detects all road users within its visible range and provides the raw data to the attached node.

Data preprocessing 2 The data received via the V2I module and the Laserscanner data is transferred to the node. Afterwards the data is pre-processed and provided to the co-operative pre-data fusion.

Co-operative pre-data fusion 3

The pre-data fusion merges the vehicle information send via V2I and the Laserscanner’s data using a co-operative approach which is also based on static map information.


This capability supports the following use cases: - SP5_UC22_v1.0 - SP5_UC55_v1.0 - SP5_UC31 - SP5_UC33


TC06: Extended Cooperative Automatic Incident Detection Name Extended Cooperative Automatic Incident Detection (ECAID) ID SP2_TC06_V1.0 Author Stefano Marco (CSST) Status Final

Brief description

Freeway incident management systems often rely on algorithms to detect incidents using data collected from vehicle sensors installed on the road. Most of the incident detection algorithms in existence today basically rely on recognizing in a short time unusual patterns of traffic (in space and time). These algorithms compare the value of a measured traffic parameter (i.e. volume, occupancy, or speed) to estimated or predicted values, or predetermined thresholds. An alarm is triggered when parameters exceed the thresholds.




Innovation

Improvement of detection reliability and response time, thanks to: - the use of both road side data, coming from innovative/conventional

sensors, and vehicle data (location, speed, distance, relative position)

- the availability of a higher density of roadside sensors compared to the conventional applications (order of magnitude of tens of meters instead of thousands of meters)

Driving environment Highways

Purpose Fast acknowledgement of the presence of a congestion event (e.g. unexpected queue caused by an accident) in order to alert immediately the oncoming vehicles and reduce injuries.


Queues and congestions are very common on highways; they may be caused by car accidents, slow-moving vehicles, road geometry discontinuities (work sites, etc), sudden changes of visibility (fog, smoke, etc.), or simply stop&go traffic waves. They often result into pile-ups that may involve a large number of vehicles and therefore cause serious injuries and damages.

Trigger Queue or congestion caused by an event on the road

Sensing system

Traffic data (volume, occupancy, speed, density) are detected by different types of roadside sensors: inductive loops, CCTV cameras, microwave, radar, laser sensors, etc). The detection capability of the AID system can be improved by processing also the measurements sent by the probe vehicles driving within the monitored area (position, grip, vibrations, noise, airbag activation, etc); with these data it is be possible to obtain more information and thus integrate the inputs for the AID algorithms.

External data sources n.a.





Data collection and storage 1

The signals coming from the infrastructure sensors stations are acquired by the sensors interface boxes; the signals coming from the vehicles are acquired by the vehicles themselves; the information from both sources is then pre-processed for validity and made available to the applications module. The measurements include:

- traffic measures: vehicle passage, vehicle presence and position, instantaneous speed, vehicle length, vehicle class

- non-traffic measures: noise, vibrations, collision, rollover, grip, temperature, wet pavement, fire, etc.

The files containing the traffic data aggregated over a certain time step (parametric - defined by the Centre) are built:

- flow - average speed (arithmetic/harmonic, etc.) - occupancy per vehicle class and lane

The files containing non-traffic data aggregated over a certain time step, per vehicle-class and lane are built as well.

Data processing 2

The data coming from the peripherals level are processed in order to perform:

- data cleaning - data validation - data reconstruction

The traffic and non-traffic data are then processed by the AID algorithm considering the refresh time-step of the data coming from the data collection step (detection rate), in order to detect the presence of a queue according to the combination of the various parameters. Possibly, different algorithms work on the comparison of various parameters (e.g. comparison of current road-cell occupancy with the downstream cell occupancy, variations of speed in a single cell, discontinuity of speed and density, etc.).

Supply of warning 3

The different implemented algorithms work in parallel, so to enhance the reliability of the event detection, which will trigger an alert. The alarms generated by each single algorithm are processed by an integration module that generates the actual alarm to be taken in charge by the alert display module.



Open issues n.a. Comments n.a.

TC07: RFID for curve overshooting prevention Name RFID for curve overshooting prevention ID SP2_TC07_V1.0




Author Jacques Ehrlich, Nicolas Hautière (LCPC) Status Final

Brief description

Curve overshooting is a major cause of fatalities. ADAS can help motorist to prevent this kind of accident. Classically, lane keeping systems are based on lane marking detection (by cameras or IR sensors). Digital maps with attributes such as road geometry description can complete sensors information ton increase system's robustness. We developed a special purpose RFID device which can provide the following information: road geometry and adherence and lateral vehicle positioning on the lane. Thanks to this information, different solutions can be implemented to help the driver: the fist one consist in providing the driver with a risk level taking into account road geometry, adherence, vehicle speed, driver behaviour etc.; the second one consist in providing the driver with an information such as the step aside the lane median and to suggest a corrective action.

Innovation - Passive V2I communications to transmit road attributes to the

vehicle and thus compute the safety margin - Alternative to a digital map - Multi-application devices


Purpose Curve overshooting prevention

Trigger

1) Due to misjudgement of the road geometry or adherence, driver adjusts the vehicle speed at an excessive level which consequently causes an accident risk of curve overshooting. 2) For any reasons (misjudgement, bad action, vigilance decrease), vehicle is deviating from the lane median leading to a lane departure.


Sensing system

A RFID system is comprised of the following elements: - one ore more tags (also called transponders), which contains an

identifier and information specific to the application; all these data being contained in a memory,

- a read/write device (also called interrogator) whose main function is to interrogate the tag to recover the data that it has in memory. In certain applications, the interrogator can also transmit data to the tag so that it stores them in its memory. The transfer of the electromagnetic energy is done by means of antennas integrated into the tag and the interrogator. The proposed RFID has been specially designed for ITS applications and not yet commercially available. Read or write operations can be done on the fly at a speed up to 140 km/h. The reader is powered by supply available on board of the vehicle. The tag, embedded under the road surface is powered by a battery which lifetime is estimated to 5 years. Furthers researches should allow to operate at higher vehicle speed and to remote supply the tag with the energy provided by the reader.


Information related to the road characteristics (geometry, adherence etc) or information provided by other vehicles (in this case, RFID operates like a "letter box")


short name of the step 1 Vehicles enters the curve and passes over a tag 2 The interrogator reads the road description in the tag

3 The vehicle computes a critical speed according to road characteristics and vehicle capacities




4 The vehicle alerts the driver in case of an excessive speed with respect to the critical speed and eventually proposes a corrective action.




TC08: RFID for short headway to front vehicle detection Name RFID for short headway to front vehicle detection ID SP2_TC08_V1.0 Author Jacques Ehrlich, Nicolas Hautière (LCPC) Status Final

Brief description

In many countries, regulations impose a minimum distance between two consecutive vehicles. This headway is normally expressed in terms of a time (to collision) rather than a distance (2 seconds in France). Drivers can evaluate headways (with low accuracy), but it is quite impossible to visually estimate a time to collision. Consequently there is a need for headway measurement system (in time units). Solutions based on perception sensors are being developed by researchers, equipment suppliers or car manufacturers. RFID offers an alternative solution. Compared to other solutions, RFID is interesting because it is a multi-purpose application device. Thus a given RFID tag can be used for not only for short headway measurement but also for wrong way detection, curve overshooting prevention, ISA application, on-board road sign displaying etc.

Innovation - Passive cooperative system to express the headway to front

vehicle in time units - Multi-application devices


Purpose Short headway to front vehicle detection

Trigger

A vehicle is driving with a short headway to front vehicle. Each time, the car run over an RFID, it can get the time to collision with the vehicle ahead. An alarm message can be delivered to the driver if the headways (in time unit) is lower than a given (legal) value. It is then to the responsibility of the driver to reduce the vehicle speed.


Sensing system

For this application, it is supposed that all vehicles are equipped with a RFID reader and that RFID tag have read/write capabilities. Thanks to a DCF77 reception module located in the reader, all vehicles clock have a common reference. RFID tags are embedded under the road surface at any place where headway measurement is expected and speed. When the following vehicle run over the tag, it get this information and knowing its own time and speed, it can then calculate the time to collision with the vehicle ahead.


List of external data / information sources which are useable within this capability





short name of the step 1 Each time a vehicle runs over a tag it writes its current time

2 The following vehicle runs over the tag and gets this information

3 Knowing its own time and speed, it can then calculate the time to collision with the vehicle ahead

4 An alert is generated Related Use Cases (SP4 / SP5) SP5_UC42





TC09: Sensors for support in poor visibility conditions Name Sensors for support in poor visibility conditions ID SP2_TC09_V1.0 Author José Miguel Perandones (CIDAUT) Status Final

Brief description

Situations with low visibility or even no visibility can contribute to lack of confidence and affect a driver’s interpretation of the environment. But driver expectations are also based on attitudes, previous experience, familiarity, etc (Theeuwes, J., 2002). Accidents often occur because drivers did not anticipate events adequately. A large proportion of accidents are the result of inappropriate expectations of the environment (Malaterre, 1986). The ability to perceive other road users’ movements rapidly and precisely is a key component of successful collision avoidance (Santos, Berthelon and Mestre, 2002). As over 90% of the information a driver has to process is visual, different visual cues are used to guide behaviour. Drivers use for example edge lines to steer their vehicle. At night time, delineation systems are therefore an important visual cue for facilitating driving (Mestre, D., 2002). Insufficient visibility is a common contributing factor to accidents.

Innovation Driving environment Any with low visibility

Purpose

Electronic sensors, installed in road infrastructure, are used to identify situations where the visibility is reduced due to:

- Road layout, e.g. grade changes, on straight single carriageway roads which can hide a vehicle overtaking in the opposite direction. The sensor system will identify the situation and alert the driver of the oncoming vehicle by means of warning lights installed on the roadside (1a Geometric design → Blocks/Decreases frontal/lateral driver visibility).

- Sun glare on single carriageway roads which makes overtaking dangerous. Electronic detectors installed on stretches at risk would identify overtaking manoeuvres and warn vehicles coming in the opposite direction through signals installed above the verge road surface (possibly on roadside reflectors) (4 Sun glare → Blocks/Decreases frontal/lateral driver visibility).

- Rain at night time on roads where horizontal road marking is poor can confuse the driver. Sensors can identify wet conditions on such roads and turn on lights fitted on roadside reflectors (4 Rain → Decreases frontal/lateral driver visibility).

Trigger - Frequency of occurrence Whenever the vehicle enters into an low visibility area

Sensing system

As the situations where poor visibility conditions can occur are very large, wide range of sensors can be used: i.e.

- Photodiodes. - Piezoresistive sensors. - Weather sensors: rain, fog.

External data sources Pre-stored data (i.e. relating to potentially risky road designs)





Incident detection 1 The system will detect vehicles are in a local low visibility situation (road layout, sun glaring, rain)

Data processing 2 Data will be filtered and processed. Data fusion 3 Visibility conditions are estimated and actions are defined

Action and warnings 4 Generate warning alerts and actions to handle the hazardous situation




TC10: NIR and thermal imaging for detection of animals Name NIR and thermal imaging for detection of animals on the road ID SP2_TC10_V1.0 Author Matti Kutila, Jukka Laitinen, Seppo Rantala (VTT) Status Final

Brief description

VTT has earlier experience in NIR and thermal imaging for detecting animals on a road. A roadside sensing setup may be used in such road sectors where frequent animal collisions have occurred. The major problem is caused by the big animals like elks and deer, but the similar methodology could also be utilised to detect the smaller fur animals like rabbits, roe deer, cats, etc. which may scare the driver and therefore, apply a momentary inattention for driving. Already GM and BMW are offering thermal imaging in cars for the purpose, but the reaction time for warnings by in-car units is very short, therefore infrastructure can offer better protection. The prices of detectors (microbolometer, thermopile, pyroelectric) and optics (low-Ge chalcogenide, and PE polymer) are decreasing rapidly, and could provide cheaper solutions than the long fence installations used currently in the northern countries.




Innovation The use of NIR and thermal imaging with new detectors and optics for the detection of animals.


Purpose The fur animals are a considerable risk factor because their behaviour is unpredictable. Therefore, early and accented warning of any observed animal movements on a road is preferred.

Frequency of occurrence -

Trigger Traffic surveillance sensors: Roadside/overhead mounted sensors (CCTV cameras), imaging sensors

Sensing system

A roadside sensing setup may be used in such road sectors where frequent animal collisions have occurred. AGM and BMW are offering thermal imaging in cars for the purpose, but the reaction time for warnings by in-car units is very short, therefore infrastructure can offer better protection. The prices of detectors (microbolometer, thermopile, pyroelectric) and optics (low-Ge chalcogenide, and PE polymer) are decreasing rapidly (, and could provide cheaper solutions than the long fence installations used currently in the northern countries.) NIR and thermal imaging systems provides information from which animals can be detected. Even though some in-car units of these kind sensors are available (i.e. GM and BMW) research is needed to create roadside sensors.

External data sources Accident databases are providing safety-relevant data and information.


Choosing of traffic surveillance sensors for evaluation

1 The selection of proper detector.

Evaluation of different sensor systems 2


- People - Animals

Related Use Cases (SP4 / SP5) SP5_UC17


TC11: VIP for detection of vehicle behind a blind corner Name VIP for detection of vehicle behind a blind corner ID SP2_TC11_V1.0 Author Matti Kutila, Jukka Laitinen, Seppo Rantala (VTT) Status Final




Brief description

When approaching a road junction in city environment whereas high buildings or barrier reduces the driver ability to see the on-coming vehicles: bicycles, passenger car or truck. The assisting system for providing opportunity to automatically detect and thus prevent the potential accident would increase the safety driving.

Innovation The use of inexpensive camera system with robust image processing

in the detection of hazardous situations. Driving environment Urban Area

Purpose Increase safety driving in traffic junction of cities. Frequency of occurrence -

Trigger -

Sensing system Detecting a moving obstacle is in one hand pretty simple by comparing differences of the image sequences. However, in the outdoor conditions the environmental changes like sun, rain, night time, etc. cause much more challenging task for the robust image processing.


Moving vehicle (primary) Rain (secondary) Fog (secondary) Sun glare (secondary) Snow (secondary)


Evaluation of different sensor systems 1 Test systems for different outdoor conditions.


The described Technology Capability is related to the SP4 and SP5 application dealing with reduced driver visibility.

- SP4_UC_Obstructed view at intersections – 1b - SP4_UC_HeadOnCollisionWarning – 4c (Head on collision

warning due to the presence of an auto bus vehicle climbing down through an hairpin curve)

- SP4_UC_FrontalCollisionWarning – 7a (Frontal collision warning due to static obstacle in front)

- SP5_UC22 - SP5_UC52 - SP5_UC55





TC12: Optical methods for detection of ice or snow on road Name Optical methods for detection of ice or snow on road ID SP2_TC12_V1.0 Author Matti Kutila, Jukka Laitinen, Seppo Rantala (VTT) Status Final

Brief description

In the Nordic countries ice and snow increase risky driving especially in autumns and springs due to unpredictable weather conditions changes. The problem also exists in the countries where the winter tyres are rare. Due to reduced friction the stopping distance increases, which consequently cause an accident risk with lead vehicles or pedestrians especially in traffic junctions.

Innovation Detection of ice or snow by using advanced data fusion of vision system and environmental sensors.


Purpose Decrease the risk of loosing vehicle control.


Ice and snow on the road increases the accident risk (e.g. according to German Federal Office of Statistics icy roads cause approx. 270 traffic fatalities and 20 000 injuries each year). The warning for a driver especially in a case of a black ice would assist the driver to adapt speed before the slippery road surface is encountered.

Trigger Data fusion of roadside sensors detecting actual environmental conditions (e.g. atmospheric sensors, road surface condition sensors) and vision system.

Sensing system

VTT coordinated the Apollo (http://virtual.vtt.fi/apollo/) project and leads now the Friction project in which intelligent tyre monitoring techniques are developed including detection of road surface properties. The technology can be complemented with an optical method (CCTV cameras) that uses texture features and/or increasing detection confidence with the light polarisation analysis for detecting ice or snow on a road.


Furthermore also external sources (e.g. infrastructure operator, accident database) are providing safety-relevant data and information.

Ice on road: TRUE Snow on road: FALSE





Choosing of road surface condition sensors for evaluation

1

Using well known effects on the relative intensities of the TE and TM polarisation directions of reflected light from surfaces with different indices of refraction (such as water and ice), it may be possible to analyse the surface properties with optical means, whereas snow is easy to detect based on surface lightness. Additional research is required since no commercial product is yet available.

Evaluation of different sensor systems 2


- Road Surface-Wet (yes/no) - Road Surface-Ice (yes/no) - Road Surface-Snow (yes/no)

Further analysis is done how one sensor system can cover spot detection area.


The described Technology Capability is related to the SP4 and SP5 application dealing with critical environment conditions.

- SP5_UC411_v1.0 (Prevention of the lack of adherence of the road).

- SP5_UC412_v1.0 (Warning for the reduced friction of the road surface)

- SP5_UC42_v1.0 (Prevention of driver excessive speed in critical environment conditions)

- SP5_UC44_v0.1 (Exiting from a tunnel) Open issues

Comments One patent exists, which relates to the envisioned technique: Fridthjof, J. 2004. A Device for Detection of Road Surface Condition, Patent number: WO/2004/081897.

TC13: Sensors for assessing trajectories in intersections Name Sensors for assessment of erroneous trajectories in intersections ID SP2_TC13_V1.0 Author José Miguel Perandones (CIDAUT) Status Final

Brief description

Junctions are sites where safety problems are concentrated and easier to identify. An electronic system able to provide real time information regarding the position of approaching vehicles and vulnerable road users is of great interest for improved road safety. (From Artic to Mediterranean. First Pan-European Report. EuroRAP)




When a driver is approaching an intersection, the motion of other vehicles must be anticipated so appropriate avoiding manoeuvres can be made (Santos, Berthelon and Mestre, 2002). But research studies have shown that, when crossing intersections, drivers display inertia in their regulating actions, taking time to become aware of conflicts with other drivers. This can lead to accidents (Saad, F., 2002). Queues at the intersection are not always sufficient to prompt a speed reduction, failing to indicate the intersection as a zone of transition. Monseur and Marchadier (1971) emphasise the importance for road design to highlight the intersection visually or incorporate structural constraints that clearly identify it as a transitional zone. Hence the need for good road design and for developing driving aids to facilitate the dynamic management of a driver’s interactions with other road users. To enable such a support system, it is necessary to detect the incident. The assessment of erroneous trajectories of vehicles entering intersections is the first task (see picture above)

Innovation Improved accuracy in assessment of poor visibility conditions Driving environment Intersections

Purpose

To facilitate the dynamic management of a driver’s interactions with other road users through:

- Detection of high approach speeds to an intersection. - Inform approaching vehicles with regard to the vehicles present

at the intersection and their position. - Detect ion of long queues of vehicles at an intersection in order

to inform approaching vehicles. Trigger


IN Spain intersection accidents accounted for 34.3% of injuries and 15% of road fatalities in 2004. At European level, side impacts at junctions are one the main four accident types accounting for fatalities and injuries in accidents (Spanish National Injury Accident Database).

Sensing system Assessment of vehicle trajectory can be detected by different types of sensors: e.g. inductive loops, CCTV cameras, microwave, radar, laser sensors, sensing cables, loop mats.

External data sources External data from control centre: traffic jam, weather conditions.

Description of Step Process step

Vehicle entering into an intersection at high speed

No INFRASENSE Capabilities

Vehicle entering into an intersection at high speed is detected by infrastructure. Vehicle is warned to reduce the speed as there is a queue in the road

INFRASENSE Capabilities

¡¡WARNING!! REDUCE YOUR

SPEED




process steps Incident detection 1 The system will detect vehicles entering into an

intersection, by means of different techniques. Data processing 2 Data will be filtered and processed.

Data fusion 3 Trajectory of vehicles will be estimated. If it isn’t within the limits of a safe driving, alerts will be generated

Action and warnings 4 Generate warning alerts and actions to handle the hazardous situation




TC14: CCTV camera for measuring daytime fog and visibility Name CCTV camera for measuring daytime fog and visibility ID SP2_TC14_V1.0 Author Nicolas Hautière (LCPC) Status Final

Brief description

It has been shown that drivers often overestimate intervehicle distance in fog. Visibility distance can be communicated to vehicles and an advice of speed reduction can be given to the driver and thus prevent pile-ups to occur. Classical visibility sensors are not relevant. A transmissometer is reliable but is expensive and is hard to calibrate (alignment of optical blocks). A scatterometer, is less expensive than a transmissometer and that no optical block alignment is required. But, the small size of the diffusing volume makes measurements highly sensitive to non-homogeneities in the fog. Furthermore, the sensor accuracy decreases with the meteorological visibility and is not acceptable for visibilities below 50m. We developed a first method dedicated to daytime fog detection and estimation of meteorological visibility distance and a second method estimating the visibility conditions under various meteorological conditions through use of in-vehicle cameras. We want to adapt our techniques to CCTV cameras. This solution would be reliable and cheaper than classical visibility sensors. Furthermore, under daytime foggy weather, the images provided by CCTV cameras are also bad degraded. We want to develop an algorithm to restore the contrast of the scene and thus improve automatic incident detection.

Innovation

- Alternative to classical visibility sensors using CCTV cameras, which is cheaper and easier to deploy thanks to the existing network of CCTV cameras

- Fusion of visibility measurements with vehicles data - Improvement of AID through contrast restoration


Purpose Detect and estimate the presence of daytime fog Trigger Daytime fog presence Frequency of occurrence -




Sensing system CCTV camera but additional information coming from in-vehicle sensors could be used to confirm the result.

External data sources External weather information systems


Image acquisition 1 The camera grabs images of the road scene

Image analysis 2 The images are analyzed and a decision about the presence of fog is taken. If it is the case, fog density is computed.

Supply and distribution of safety information

3 The fog density is transmitted to a local node and is distributed to the MFO in order to consolidate information, to alert drivers/vehicles and to fuse this information with other information sources or sensors.


- SP5_UC42_v0.1 (prevention of driver excessive speed in critical environment conditions)


TC15: RFID network for driver warning Name RFID network for driver warning ID SP2_TC15_V1.0 Author Tamas Lovas, Arpad Barsi (BME) Status Final




Brief description

The exchange of data from sensors to roadside unit depends on a robust power supply and communication network. However, in case of failure, backup is needed. If the most important information (e.g. traffic rules, warnings) is stored in RFID tags and vehicles are equipped with RFID reader units, they can receive the relevant data independently. The system must however ensure that the RFIDs contain up-to-date information, or provide real-time data through the sensors. The block-scheme below shows how a RFID network can be integrated in the INFRASENS architecture:

Note: RFIDs can also be used for providing location data in certain locations without GPS signals (e.g. urban canyons, tunnels).

Innovation Application of RFID network in traffic junctions. Using RFID network for positioning.

Driving environment Black spots, tunnels, urban canyons

Purpose - Warn the driver with continuously updated traffic information. - Provide location data if needed.

Frequency of occurrence RFID network is activated when the reader (vehicle) is within range.

Trigger Information is transmitted when the reader approaches the tag.

Sensing system RFID memories can be filled or stored data updated by Safespot systems, but the tags mostly contain basic traffic information or ‘non-real-time’ warnings (e.g. construction works, temporary speed limits)


The planned RFID network has a strong dependence on external data sources, such as

- traffic maps of black spots (traffic rules, limitations) - road database (schedule, road closures, limitations)

Another way of using the tags: the RFID refers to a record of the local dynamic map (database) which can be queried by the vehicle.


Collection and storage of data 1

Safety-related information is stored in the RFID tags. The required data can be uploaded using external databases or Safespot sensing systems. Since the RFID network is a less interactive network, continuous control and maintenance of the stored data is required!




Data transmission 2

Passive tags (without battery) can be read from a short distance (6m: therefore need to be located on roadside), battery equipped active tags have up to 100m range and can be coupled with sensors. The tags continuously provide information to readers (vehicles) within range. There is no pre-processing or any kind of data filtering in the tag; all stored information has to be transmitted.

Safety data at the driver 3 The vehicle onboard unit (through HMI) has to display

the relevant information to the driver. Related Use Cases (SP4 / SP5)

The RFID network is able to store and provide any kind of safety related data. Therefore, no particular use cases should be highlighted.





TC16: Local Radio Warning System Name Local Radio Warning System ID SP2_TC16_V1.0 Author Javier Burgoa (CIDAUT) Status Final

Brief description

The task of warning road users is one of the fundamental activities to be considered by INFRASENS. To extend the benefits of cooperative sensing to any type of road users, the warning system must be:

- Available for all vehicle (equipped and not equipped), and type of road user (tourism, motorcycles, trucks, pedestrians…)

- Widely used. - Inexpensive - Easy to use.

These characteristics are offered by a Local Radio Warning System using suitable radio frequencies and existing Radio Tuners on vehicles. The wide use of Frequency Modulated receivers to receive warning messages from the infrastructure makes it easy to extend the use of SAFESPOT systems to all kind of road users.

Mountain Road

RIVER

SAFESPOT INFRASTRUCTURE EQUIPPED

INCIDENT USER(s) ENTERING A RISK AREA

BROADCAST WARNING MESSAGE - ACTIVE -

IN ACTIVE

IN ACTIVE . .. ..

SENSORS

o RADIO FREQUENCY EMMITTER

Rural road: any vehicle entering a hazardous area will be warned by means of a radio frequency signals directly to his radio tuner.

Innovation Driving environment Any type of road equipped with infrastructure SAFESPOT system

Purpose To extend SAFESPOT warning capabilities to any type of road user, equipped or not with innovative systems.

Trigger The trigger is defined according to SAFESPOT Infrastructure application


The warning system will broadcast a warning message at any time the safety application decides it is convenient.

Sensing system Dynamic data is detected by any types of sensors. The warning message is broadcasted to any road user.





External sources of information can be broadcast (e.g. police, infrastructure operator, accident database) to provide safety-relevant or traffic conditions:

- general pavement quality - weather forecast - special conditions in the area


Detection 1 Infrastructure detects an incident

Processing 2 Intelligence on infrastructure processes raw data. It is determined that a warning message has to be broadcasted

Warning-Alerting 3 The message is broadcast Related Use Cases (SP4 / SP5) SP5_UC51

Open issues Range of the warning system Comments




TC17: Data fusion for risk assessment for road segments Name Data fusion for risk assessment for road segments ID SP2_TC17_V1.0 Author Sibylle Nussbächer (PTV AG) Status Final

Brief description

Evaluation of safety risk based on information/data from roadside sensors, vehicle sensors and also from external sources: On rural roads as well as on motorways there are always segments, which are considered to be more unsafe than other ones. The reasons for this estimation are various (e.g. low tire grip, steep incline). However, seen for itself only, all of these diverse reasons do not mandatory result in a safety critical situation for the driver. But additional bad weather or traffic conditions like snow, fog, rain, dense traffic etc. can lead to an enormously increasing risk for accidents at the before ‘only’ unsafe road sections. To handle this critical situation safely, it is necessary to warn/advise all drivers passing on the stretch of the road “at risk” as early as possible (e.g. announcement of speed limits adjusted to the identified safety risk).

accident database police infrastructure

operator

safety data base(risk assessment for

road network and segments)

APPLICATIONS

roadside sensors

in-vehiclesensors

SP2 SP4/SP5

Node(data aggregation/preprocessing)

SF Information Center

Algorithms for data processing and data fusion

Local Safespot „Box“ MFO

Local Dynamic Map Data Storage

in-vehicle alert system

roadside alert system

Input data

Output data

accident database police infrastructure

operator

safety data base(risk assessment for

road network and segments)

APPLICATIONS

roadside sensors

in-vehiclesensors

SP2 SP4/SP5

Node(data aggregation/preprocessing)

SF Information Center

Algorithms for data processing and data fusion

Local Safespot „Box“ MFO

Local Dynamic Map Data Storage

in-vehicle alert system

roadside alert system

Input data

Output data

Innovation Merging and interpretation of a high amount of static and dynamic data/information in order to estimate the current risk level on the road network and thereby to accompany the driver on his way with the best possible safety information.

Driving environment Motorways, rural roads (non-urban)

Purpose Prevent (fatal) accidents due to safety critical environmental conditions.

Trigger





“Unadjusted driving behaviour” is one of the most frequent reasons for (fatal) accidents on motorways and rural roads. It mainly means inappropriate speed and dangerous driving regarding to special situations like:

- wrong speed with weather conditions - wrong speed with traffic conditions.

Note: “Unadjusted driving behaviour” is difficult to quantify because the term subsumed a bundle of different accident causes (e.g. inappropriate speed, insufficient safety distance).

Sensing system

Dynamic data are detected by different types of sensors: - roadside sensors detecting actual traffic conditions (e.g.

inductive loops, CCTV cameras, microwave, radar, laser sensors, sensing cables, loop mates).

- roadside sensors detecting actual environmental conditions (e.g. atmospheric sensors, road surface condition sensors).

- in-vehicle sensors detecting actual traffic and environmental conditions.


Furthermore also external sources (e.g. police, infrastructure operator, accident database) are providing safety-relevant data and information like:

- general pavement quality - number/width of lanes - rate/cause of accidents - incline


Collection, storage and evaluation of static data

1

All safety-relevant data/information, deriving from different external sources, are collected and stored into a comprehensive safety database within the Safespot Information Centre. Based upon this data pool, all segments of a road network are categorized/classified depending on their evaluated risk level. These detailed information are transmitted via node to the SAFESPOT infrastructure platform respectively local MFO (multi-functional-outstanding) for further processing. Note: Continuous maintenance of the “safety data base” is absolutely necessary to ensure up-to-dateness of the stored information (e.g. rapid worsening of the pavement quality due to a high truck rate).




Detection and preprocessing of dynamic data

2

Roadside sensors as well as in-vehicle sensors are continuously detecting different kinds of dynamic data/information like

- environmental data/information (e.g. weather conditions, road surface conditions, visibility and lighting conditions)

- traffic data/information (e.g. speed, density, distance and provide them to a local node, where a first preprocessing of the delivered data occurs (e.g. check for plausibility, quality, validity). After this, all sufficiently reliable and correct data/information are transmitted to the SAFESPOT infrastructure platform respectively local MFO for further processing. Note: Due to the fact that surrounding conditions can change rapidly, data must be transferred continuously in a certain time interval (for example every minute). Of course the transfer rate depends on the detection rate of the used sensor(s).

Data consolidation and evaluation of current safety risk. Determination of situation suitable procedure.

3

The intrinsic data processing (consolidation and evaluation) occurs into the local SAFESPOT MFO. There, the received sensor data (roadside and in-vehicle) as well as the safety-relevant information from external sources are consolidated and, after this, the result is checked for its accident proneness. That means evaluation and identification of the road sections’ current risk level (according to the applied algorithm). Depending on the current risk level, appropriate safety information for the roadside alerts and the equipped vehicles are generated (e.g. warnings, instructions, information, routing) Note: Due to the fact that surrounding conditions can change rapidly, the combination of the particular factors has to be dynamic. Here, flexible cooperative systems can make a great contribution.

Supply and distribution of safety information

4

The safety information is communicated to the roadside and in-vehicle application for further processing. Subsequent the safety information must be conveyed to the drivers which are at risk in order to avoid accidents. This could be carried out via

- an ‘alert’ for the drivers of all vehicles passing on the stretch of the road which is calculated to be ‘at risk’ (e.g. display of speed limits on score boards).

- an ‘alert’ for the drivers of equipped vehicles passing the dangerous area to be visualized via the OBU (and/or the local dynamic map).

Note: In this context it is absolutely necessary to achieve a high acceptance for these kinds of information. To meet this requirement, speed limits for instance shall only be displayed in addition with more information and only, if the situation is estimated to be really accident-prone and dangerous.




Related Use Cases

The described Technology Capability is mainly related to the SP5 application dealing with critical environment conditions.

- SP5_UC411_v0.1 - prevention of the lack of adherence of the road.

- SP5_UC412_v0.1 - warning for the reduced friction of the road surface

- SP5_UC42_v0.1 - prevention of driver excessive speed in critical environment conditions

- SP5_UC43_v0.1 - entering into a tunnel - SP5_UC44_v0.1 - exiting from a tunnel - SP4_UC_SpeedAndDistance – 6b - SP4_UC_SpeedAndDistance – 6c - SP4_UC_RoadConditionStatusV2I – 8a - SP4_UC_CurveWarning – 9a


TC18: Data Fusion supporting the Safe Urban Intersection Name Data Fusion Supporting the Safe Urban Intersection ID SP2_TC18_V1.0 Author Tobias Schendzielorz (TUM) Status Final

Brief description

Approaching an urban intersection, a driver is faced with complex problems and decisions. There are four options: crossing the intersection, turning left, turning right and making a u-turn. The driver has to keep an eye on several points to avoid misjudgement. He must pay attention to pedestrians, cyclists and other potential vehicles crossing his way. Furthermore there is the risk of a potential dangerous driver disobeying the traffic rules / lights.

Red Light Violation !!

Potential safety critical situation

Traffic Lights

Pedestrian

Trajectory

Traffic Lights ControllerTraffic Lights Controller

Intersection MFOIntersection MFO

NodeNode

Environmental Sensors


Traffic SensorsTraffic Sensors

In-VehicleSensors

In-VehicleSensors

Red Light Violation !!

Potential safety critical situation

Traffic Lights

Pedestrian

Trajectory

Traffic Lights ControllerTraffic Lights Controller

Intersection MFOIntersection MFO

NodeNode



Traffic SensorsTraffic Sensors

In-VehicleSensors

In-VehicleSensors

The trajectories of vehicles and other road-users (like pedestrians) can be reconstructed and forecast in real-time by road-side procedures, based on in-vehicle sensing, road-side sensing and the traffic light control status. In the case of an imminent danger, warnings can be sent out to the drivers concerned. As far as pedestrian and bikers are concerned, warnings can be given by means of acoustic signals.




Furthermore useful information for supporting the driver could be provided to an ADAS:

- If there is a tailback the driver needs to be warned in the case of approaching to fast.

- Recommendations for the correct speed to stay within the progressive signal system would avoid possible sharp breaking.

- Warning if the driver is not able to reach the intersection within the green period to avoid sharp breaking being dangerous for pedestrians starting crossing the road or the following vehicles, too.

- Recommendations about the right lane to use in order to be aware of lane changes on the short-run.

- The Red-Light transmitted into the vehicle is an opportunity for reducing red-light violating or sharp breaking.

Innovation

Sophisticated fusion of static and dynamic data within the MFO in order to derive more accurate and reliable information about vehicle’s and other road user’s positions and speed, etc. as well as the current traffic conditions. (Data Fusion could probably be used within other driving environment.)

Driving environment Urban Area

Purpose

Prevent collision of two vehicles or collision of vehicle and cyclist or pedestrian. This is necessary because the collision with another vehicle which turns into or crosses a road is the largest group of accidents people being injured in Germany in the urban area. Failure to observe the traffic control by policemen or traffic lights is the reason for 2.0% of accidents with injured people and 0.8% with fatalities in the urban area.


Permanent surveillance of the intersection in order to identify safety critical situation.

Trigger Every time a vehicle is approaching the intersection.

Sensing system

- Roadside sensors detecting current traffic conditions (e.g. inductive loops, CCTV cameras, microwave, radar, laser sensors, sensing cables).

- Roadside sensors detecting current environmental conditions (e.g. atmospheric sensors, road surface condition sensors).

- In-vehicle sensors or rather the in-vehicle platform. Static vehicle data like dimensions and weight of the

vehicle, etc. Dynamic vehicle data like speed, position,

acceleration, indicator status, etc. Activity of driver assistance systems and Information of the vehicle’s route provided by the in-

vehicle navigation system. - Already existing roadside sensors (E.g. being used for detecting

current traffic conditions as input for traffic actuated intersection controlling).

- Detector for sensing vulnerable road users like pedestrians. External data sources

Connection to the Traffic Lights Controller in order to have the schedule of the signalling phases at the controlled intersection.





Collection of static data 1

Building up of a detailed static local data base / map of the intersection. Including data like e.g. the kind of intersection or roundabout, quality of road surface, number and width of lanes, cycle and pedestrians crossings / lanes, accident rate, gradient of the road, curves, landmarks for positioning, exact position of stopping-line, etc.

Acquisition of dynamic data 2

Acquisition of the dynamic data provided by - roadside and in-vehicle environmental sensors, - roadside traffic monitoring sensors - in-vehicle sensors, and - traffic lights controller.

Due to the fact that surrounding conditions can change rapidly, these data must be transferred continuously at a high speed (about 0.1 sec) Data provision by equipped vehicles should be done via V2I short range communication. Quality and plausibility check of the received raw data and processing of the data and conditioning into adequate format before transmission to the MFO should be done by the node.

Data fusion 3 Fusion of static and dynamic data within the MFO in order to derive more accurate and reliable information about vehicle’s and other road user’s positions and speed, etc. as well as traffic conditions.

Data supply 4

The processed and stored data should be prepared for delivery to applications located at the infrastructure as well as to vehicle-based application by using the Local Dynamic Map as a kind of data platform. Application at the urban intersection calculates the trajectories and identifies safety critical situations based on the prediction of the trajectories.


- SP5_UC22_v0.1 – safe signalized intersection (crossing, turning)

- SP5_UC31_v0.1 – safe signalized intersection (red light violation)

- SP5_UC33_v0.1 – right of way(stop sign), not signalized roads - SP5_UC52_v0.1 – emergency vehicle is approaching a

controlled intersection - SP5_UC55_v0.1 – driver assistance for complex urban

intersections - SP4_UC_Accident at intersection – 1a - SP4_UC_Obstructed view at intersections – 1b - SP4_UC_Permission denial to go-ahead – 1c - SP4_UC_Defect traffic lights – 1d - SP4_UC_Approaching Emergency Vehicle Warning – 1f





TC19: Local Dynamic Map to support detection

Name Local dynamic map to support detection ID SP2_TC19_V0.1 Author Christine Bartels (TA) Status Draft

Brief description

The local dynamic map stores high accurate content of the surrounding area. This can be an intersection with corresponding pedestrian features and geometry, a map of an infrastructure device along a highway with corresponding lane information or some kind of hot spot where detailed map information about the specific characteristics is needed. Depending on the infrastructure device and application the amount of data or functionality might be different to support the detection functions of sensors. In INFRASENS all requirements necessary for the local dynamic map implementation have to be specified to figure out the most convenient way to support all relevant safety applications.

To support detection mechanism for sure additional static content specifications supporting intersection applications as further geometry is needed. The use of digital map content itself can be divided in use of static and dynamic components to support sensing systems. According to the appropriate sensor systems and the intentions both content can be relevant to support sensing systems. Image and laser scanner detection processes are the most sophisticated sensing systems that will benefit from the local dynamic map support.

Innovation New concept of a four layer dynamic digital database for geo-referenced information in a local area.

Driving environment

Next to intersection all further safety critical parts of the road network like freeway exit or entrance where image processing or laser scanner systems are foreseen can be considered.

Purpose

The intentions and related use cases are - to support safety applications that inform the driver about a critical situation like a red traffic light where the driver has to stop and is still driving very fast. - to identify and control manoeuvres that are identified as more safety critical than others. - to give best support to avoid traffic jams and guide via the most efficient road network.


Permanent surveillance of the intersection in order to identify safety critical situation.

Trigger Every time a vehicle is approaching the intersection.

Sensing system Sensing systems using 3D and further map geometry to support detecting systems and processing on infrastructure level.

External data sources Next to the digital map content traffic light information might be needed.


Request for local dynamic map data 1

Request from the sensing system which kind of data is needed to improve data detecting mechanism on infrastructure side




Provision of local dynamic map data 2

Data extraction and provision of static or dynamic map content from the local dynamic map towards the sensing system.

Sensing system processing and filtering

3 Processing of sensor data using the local dynamic map information in order to determine obstacles, vehicles, pedestrians or further objects.

Detection result provision 4 Update and input towards the local dynamic map.


- SP5_UC22_v0.1 – safe signalized intersection (crossing, turning)- SP5_UC31_v0.1 – safe signalized intersection (red light

violation) - SP5_UC33_v0.1 – right of way(stop sign), not signalized roads - SP5_UC52_v0.1 – emergency vehicle is approaching a

controlled intersection - SP5_UC55_v0.1 – driver assistance for complex urban

intersections - SP4_UC_Accident at intersection – 1a - SP4_UC_Obstructed view at intersections – 1b - SP4_UC_Permission denial to go-ahead – 1c - SP4_UC_Defect traffic lights – 1d - SP4_UC_Approaching Emergency Vehicle Warning – 1f


TC20: Local map reference for infrastructure data exchange Name Local map reference for infrastructure data exchange ID SP2_TC20_V0.1 Author Christine Bartels (TA) Status Draft

Brief description

The provision of detection is necessary to provide the driver and the infrastructure the current model of the world. The local dynamic map will consist of dynamic and static content. The static content is identified in many situations as reference to describe a location. In order to exchange or link information especially infrastructure detected objects a more detailed location reference is needed in order to evaluate the information. The location reference has to be much more accurate than this is needed today for the provision of traffic information and incidents. The sensing system itself should benefit from the local dynamic map and the corresponding location referencing language that allows to provide a location reference according to accuracy needs.

Innovation New concept of a four layer dynamic digital database for geo-referenced information in a local area.

Driving environment

Every location where infrastructure support via the local dynamic map approach is given.

Purpose The purpose it to describe the location more detailed than this is done in current location referencing approaches like AGORA-C. The result might end in a AGORA-C extension.


Every time a location reference with higher precision than the AGORA-C approach is needed.

Trigger The applications itself have to determine the precision of the needed location reference.




Sensing system Sensing systems that detects objects and incidents and have to provide a location reference.



Request for local dynamic map data 1 The sensing systems detect incidents or objects.

Provision of local dynamic map data 2

The information is provided to the local dynamic map according to the more precise or standard location referencing approach.

Sensing system processing and filtering

3 The applications asked for the information according precision requirements.

Detection result provision 4 The information is provided to other infrastructure or in-

vehicle platforms. Related Use Cases (SP4 / SP5)

All relevant use cases where a location reference is needed to analyze, evaluate or provide content.


TC21: Middleware Platform for safety system interface Name Middleware Platform to interface with applications linked to road safety ID SP2_TC21_V1.0 Author Mizar Automazione Status Draft




Brief description

The system includes: 1) an interface to a dynamic infomobility database; 2) an interface to a map-server; 3) A Graphic User Interface, available as WEB intranet/extranet and desktop solution), allowing the graphic representation of infomobility database output (e.g. real-time traffic situations, traffic flows). This permits management decisions and also continuous monitoring of the working status of all integrated systems; 4) A “User profile platform” (i.e. access rules for the platform data and services).

SW1

SW2

…

Traffic Detection

SystemVideo

Acquisition

DATEX

RM SENSORS

VMS

RT SENSORS

VIDEO STREAM

Traf

ficpl

atfo

rm

Middleware Platform

Channel Management modules

Tic/Tmc

Userprofile

Info

Gat

eway

–Tr

ansf

er a

nd n

orm

aliz

atio

n

WSNProtocolWSN

DBTTraffic

Database

Alert systemVMS

Interface LDM

Inte

rfac

e

Sys

tem

Adm

inis

trato

r

SW1

SW2

…

Traffic Detection

SystemVideo

Acquisition

DATEX

RM SENSORS

VMS

RT SENSORS

VIDEO STREAM

Traf

ficpl

atfo

rm

Middleware Platform

Channel Management modules

Tic/Tmc

Userprofile

Info

Gat

eway

–Tr

ansf

er a

nd n

orm

aliz

atio

n

WSNProtocolWSN

DBTTraffic

Database

Alert systemVMS

Interface LDM

Inte

rfac

e

Sys

tem

Adm

inis

trato

r

Innovation Creation of an interface allowing visibility of all sensing systems installed, automatic monitoring of equipment status (diagnostics), also messages and warnings currently in operation.

Driving environment Any road environment (urban, motorway, rural).

Purpose The high modularity of this platform and ease of connection permits to integration of a system based on a wireless sensor network and used in SAFESPOT to carry out incident detection, queue detecting and obstacles on the road applications, extending its features to safety applications field.

Trigger The WSN is able to recognise event depending of an incident (e.g. with barrier, queue, falling rocks)


-

Sensing system

This platform is able to exchange information with many sub-systems such as: Video surveillance (CCTV, Closed Circuit Television) Traffic monitoring Variable Message Signs Ramp metering Data Exchange WSN (Wireless Sensor Network)





Traffic related information, weather information, etc from service providers.

Description of process steps

Step Process step

Data Acquisition 1 Collection of detected data, ‘pre-processing’ to translate into raw traffic data. Also basic diagnostics and filtering.

Data processing 2 Data fusion, modelling, correlation, etc to produce safety-related traffic information with given degree of confidence

Alert strategy 3 Decisions on strategy (action/no action etc) Actuation 4 Decide which control instruction to send where Related Use Cases (SP4 / SP5)

-





TC22: Wireless Sensor Network for obstacle detection Name Wireless Sensor Network for obstacle detection ID SP2_TC22_v1.0 Author Mizar Automazione Status Draft

Brief description

Installation of a Wireless Sensor Network (consisting of accelerometers, light diodes, microphones, magnetometers or mini cameras) to detect obstacles on the road and alert approaching vehicles. High luminosity warning lights are incorporated in the network.

Roadside unit

Node-sensorAlert system

Centre

Wireless Sensor Network

Obstacleson the road

Roadside unit

Node-sensorAlert system

Centre

Wireless Sensor Network

Obstacleson the road

Innovation Use of micro-sensors for acquiring qualitative measurements which can be used to detect safety-critical events on roads.

Driving environment Motorway, rural roads

Purpose

Wireless Sensor Networks offer an inexpensive approach to the acquisition of traffic related measurements. They have the advantage of easy installation, low maintenance and a modular and scalable solution; they are appropriate for areas without energy supply, and can be used in conjunction with existing systems.

Trigger WSN recognises event (e.g. barrier, queue, falling rocks) Frequency of occurrence

-




Sensing system

WSN (Wireless Sensor Network) with micro-sensors: - possible technologies: accelerometer; magnetometer; microphone; light diode; micro-camera. The element involved in the sensing-acquisition is composed of at least of two objects: a sensor (e.g. accelerometer and/or magnetometer and/or other integrated sensing circuit) and a node. The latter integrates the sensors and all electronic needs, and is composed of a microcontroller (for processing) and a radio chip (for communicating). The node can pre-process data received from the same type of sensor. The network consists of many nodes which can communicate among themselves. One may be able to receive data from all nodes of the network. In this case this element acts as gateway and the data received will be sent to the Roadside Unit (MFO). All nodes can also communicate directly with the MFO. The Base Station (or Sink) is a special node which acts as a gateway between the sensor nodes and the users. It - forwards the queries receives to the network, - processes the information it receives; - makes available the data to the user. In particular, it compiles queries and generates the corresponding code to put it on the network. The type of communications (e.g. wi-fi, zigbee) depends on the geometry of the road network (intersection: the nodes are distributed without a preferred direction; on a motorway the nodes are distributed along a straight line). The same as for communication protocol.


-

Description of process steps

Step Process step

Data Acquisition 1 The sensor network performs data acquisition. It depends on the application.

Actuation 2

As soon as the MFO establish (after data fusion process) to actuate a command, following an event happened on the road, the nodes, through the gateway, can activate itself and flashing forward road users.


SP5_UC11 SP5_UC12 SP5_UC13 SP5_UC14 SP5_UC15 SP5_UC16 SP5_UC17





6 Infrastructure Platform: Functional Architecture

This section describes the Functional Architecture of Infrastructure Platform. It is the first stage in the process of architecture definition, which will also include a Physical, Communications, and Information Architectures. These are all being developed under the guidance of SCORE (responsible for the high level SAFESPOT architecture). It is important that the Architecture should meet the High Level User Needs defined by SCORE (see reference numbers in brackets). It must therefore: Include a number of reference models (UN_SP7_1.01.2) Be technology independent and allow services and equipment to be provided by more than one supplier (UN_SP7_1.01.5/) Facilitate the creation of modular, flexible designs (UN_SP7_1.01.6) Permit the integration of legacy systems and where possible describe migration paths (UN_SP7_1.01.12) Permit the integration of existing communications systems (UN_SP7_1.01.13) Be appropriate for all types of road network (motorways, urban areas or rural roads (UN_SP7_1.03.3) The Functional Architecture is based on a breakdown of the logical process into four main stages, shown below.

Signals,Measure-

ments

(Raw) trafficdata

Actuationcommand

‘Alert’ orwarningsignal

EventRecog-nition

DATA AQUISITION

DATA PROCESSING

‘ALERT’STRATEGY

WARNINGACTUATION

DATA COLLECTION• Signal capture• Measurement• Data filtering• Diagnostics• Pre-processing• etc

EVENT RECOGNITION • Data fusion• Data cleaning• Data modelling• Detection alg.• Event location• etc

EVENT MANAGEMENT • Event priority• Action strategy• Conflict check• Where to sendmessage/data

• etc

‘ALERT’ACTUATION • Message/ signal choice

• Timing and sequence

• Broadcastrange, etc

Figure 7 Logical architecture of the platform




It should be noted that the logical process described above, which consists of four sequential stages regarding the acquisition and processing of data to be able to satisfy the SAFESPOT Applications (and produce the safety warnings) is equally applicable to describing the Vehicle and Infrastructure Platforms.

6.1 System Components The components or ‘actors’ of the Infrastructure Platform are: Roadside sensing system Roadside alert system Node Roadside Unit (also referred to as an MFO – Multi-functional Outstation) Centre Equipped Vehicle Non-equipped Vehicle Local Area Network Wide area Network

These are described in detail in Table 10. In order to give an idea of the implications ‘on the road’, a possible application is represented below. The roadside sensors acquire measurements which are sent to the roadside unit via the nodes and enable the detection of a queue of vehicles. This information is converted into warning signals and sent both to the roadside alerts and to vehicles approaching the bend via the ad hoc vehicle communications network (being developed by SAFESPROBE).

System ‘actors’(components)

Infrastructure-relatedelements:

• Roadside sensors• Roadside alerts • Nodes• Local Area Network (LAN)• Roadside Unit (MFO)• Wide Area Network (WAN)• Centre (TMC/TIC)• Equipped Vehicle (as sensor)• Vehicle (non equipped) as

an element of traffic

Roadside ‘alerts’

30 20

TIC/TMC

MFO

Roadside Sensors

Equipped vehicle

Vehicle

Node

LAN

WAN

Figure 8 System components on the Infrastructure




Table 13 Description of the System Actors (or Components) for Infrastructure-based Sensing

ACTOR (COMPONENT) DESCRIPTION

SUB-COMPONENT

• Traffic/vehicle sensors

This category includes sensors able to capture information relating to individual vehicles or aggregate traffic conditions relevant for identifying safety-critical events. They can include: - vehicle presence, classification (e.g. car, bus, truck, motorbike) weight, wrong way driving, stationary vehicles, traffic status and flow, including presence of queues, headway, occupancy rate, etc; - physical parameters (such as noise, vibrations, etc) correlated to the level of traffic (free flow, dense traffic, queuing, etc.)., which is of a qualitative nature but can be used for incident detection; • Obstacle sensors

These are sensors able to detect the presence of static or moving objects on the road, including dropped loads, rocks, animals, bicycles and pedestrians (included drivers outside their vehicles). • Infrastructure sensors These are sensors able to acquire/provide data relating to: a) the physical status of bridges and tunnels and other

conditions relevant to the safety of the vehicles using such elements of the infrastructure, including fire (in tunnels);

b) potentially dangerous points on the infrastructure, such as dangerous bends, e.g. ‘marked’ with RFID tags.

Roadside sensors

This is a physical device installed on the road infrastructure: it may be at the roadside (e.g. on the guard rail), above the road (e.g. on an overhead gantry), on the road surface, or embedded within the road pavement. Sensing systems may involve the use of many different kinds of technology – radar, inductive loops, video, laser, infra-red images, ultrasonic, magnetometers, etc – as well as mixed technologies. They are used to detect events, conditions, or situations whose measurements can contribute to the identification of potentially safety-critical situations, in particular:

- obstacles on the road ahead (including stationary or slow vehicles, accidents, rocks, animals, etc); - environmental conditions which cause a potential risk (wet or icy road surface, bad visibility, etc); - potentially dangerous infrastructure features (sharp bends, tunnels, high bridges, etc); - dangerous behaviour, vehicles in the wrong lane (opposite direction), risky overtaking, etc.

The sensor is able to communicate the measurement or signal gathered to the roadside unit (directly or via a node). • Ambient environment sensors

These are sensors which can obtain data relating to weather conditions such as snow, rain, fog, ice, wind speed and direction, as well as manmade effects such as dust and smoke, which can affect the safety of a road user (road adhesion, visibility, etc). They include sensors which are able to detect the status of the road-surface, including conditions such as ice, flood water, etc.





SUB-COMPONENT

Roadside Alerts

This is a physical entity, located on the roadside, which gives a visual or other signal to warn road users of a safety risk. It can for example provide warnings of an obstacle ahead (risk of collision), recommend a safe speed, a change of lane, and/or provide other information designed to prevent an accident.

• High intensity lights • VMS (including roadside panels) • Mannequins

Probe vehicle

This entity acts as a ‘mobile’ sensor. It can communicate with the infrastructure and therefore make available data gathered by onboard sensors to the roadside unit (directly or via a node). (NB. Non equipped vehicles are a passive part of the system. As receivers of information via the roadside equipment, they are ‘users’ of the system, and when detected by sensors, they can be considered part of the ‘traffic population’.

• Private vehicle • Emergency vehicle • Freight vehicle • Public transport vehicle

Node This is a physical entity, located on the roadside (in some cases, it may be an integral part of the sensing apparatus). It is composed of several modules including: a) a sensing module b) a processing module, c) a communications module (or gateway). It is able to receive signals from sensing devices in the local area carry out simple data processing, diagnostics and filtering, and send the resulting traffic data to a roadside unit (MFO), A node will be necessary in certain applications (especially for micro-sensor networks) but not all. More sophisticated nodes may be able to exchange data with vehicles, and also send commands to an alert (warning system).

Local Area Network

This is a communications network used by the sensors (directly or via the nodes) to exchange data within a local area and to be able to communicate with the roadside centre. The physical dimension is likely to cover an area with a radius of at least 250 metres but not more than one kilometre, depending on the type of application and the communication system used.





SUB-COMPONENT

The LAN could also include equipped vehicles while present in the area, but should be distinguished from the VANET (Vehicular Ad Hoc Network) which permits communication between vehicles.

Roadside Unit - Multi-functional Outstation or MFO

This is a physical entity which carries out the main data processing operations required by the SAFESPOT applications and therefore represents the “intelligence” of the Infrastructure Platform. It processes the data received from the sensing systems/ nodes to produce information on the safety-critical events which is used by the applications to generate safety warnings, when appropriate, to road users. It contains all the necessary data bases, digital maps, diagnostics functions, etc. It can dialogue with the nodes and other roadside units, as well as external centres (TMC/TIC) when necessary. It is therefore part of both the LAN and the WAN.

Wide Area Network

This is a communications network used by a roadside units (or group of units) to exchange data over a wide geographical area. The dimension will depend on the type of application and the local geography: existence of mountains, tunnels, etc. as well as the location of the external traffic centres.

Centre This entity is an element of a (non-roadside) centre such as a Traffic Management or Information Centre (TMC/TIC) where some applications may be located. It will permit the system to have a remote view of the status of systems (diagnostics) in a given area and give access, when necessary, to data from a wider area, e.g. for incident detection algorithms. It can permit the remote ‘setting’ of software in a group of roadside units (e.g. switch between summer/winter mode). It may also enable safety-related data from SAFESPOT to be made available to external management centres (which will use it for their own purposes).

• Operator (service or road network operator)

• Traveller information operator

• External information source (travel information provider, weather forecasts)

• Safety related systems (e.g. emergency-call management)

• Geographical positioning service




6.2 Three-level hierarchy It is envisaged that the components listed above will be located at three physical levels: the peripherals, the roadside unit and the centre.

MFO MFOMFO

Node Node Node

sensors vehicles alertsLevel 1: Peripherals

Local area network (LAN)

Level 2: Roadside

Wide area network (WAN)

Level 3: CentreCentre (partof TIC/TMC)

Figure 9 Hierarchical organization of the Infrastructure Platform Level 1: PERIHERALS: includes the equipment installed on the road itself, consisting of sensing devices and also the devices which provide safety alerts and warnings to passing traffic. This level also includes the nodes, which may be used to collect data from a group of local sensors of undertake simple computing operations, before sending it to the Roadside Unit (MFO). Level 2: ROADSIDE UNIT: the roadside processing unit, which represents the heart of the SAFESPOT Infrastructure Platform and the real “intelligence” since this is where the main part of the processing will be done. Groups of MFOs are linked in a network, which can communicate with the Centre. Level 3: CENTRE: this consists of a Traffic Control or Management Centre with which the system can be connected as it may in some cases need to make use of data from a wider area or of static data/information.




6.3 Reference Model

‘CENTRE’(or network of centres)

PERIPHERALS(or network of peripherals)

Roadside Unit(or network of units)

Data AcquisitionData

Processing Actuation

PROCESS

PHYSICAL LEVELS

Roadside Unit (MFO)

Sign

als

from

sen

sors

, sen

sor

netw

orks

, veh

icle

and

/ or c

entra

l lev

el

DEDICATEDLOCAL LINKS

Actu

atio

n co

mm

and

sent

to

road

side

dev

ices

or t

o ve

hicl

e

Dat

a m

odel

ling;

dat

a fu

sion

, di

agno

stic

s; c

orre

latio

n, in

cide

nt

dete

ctio

n; e

tc

SAFESPOT REFERENCE MODEL

Sensing Alerts

Roadside sensors, sensor networks

Lights, panels, signals,etc

Stra

tegy

dec

isio

n, i.

e. a

ctio

ns

to b

e ta

ken

‘Alert’Strategy

(TMC/TIC)

WAN

Note: This diagram represents a general reference model for SAFESPOT: the physicallevels and activities described refer only to the Infrastructure Platform.

Figure 10 Functional Reference Model The principles underlying the reference model are as follows: The model is based on the four-stage process Each stage of the process can in principle be carried out at any physical level, depending on the Application concerned* (for a given application, not all the levels will necessarily be involved). The elements any level may be linked in a network. Hence there can be a network of sensors, or of alert systems. Also a network of roadside units, or a network of Centres. A Local Area Network (LAN) allows communication between a peripheral (or group of peripherals) and the roadside unit. A Wide Area Network (WAN) allows communication between a roadside unit (or units) and a Centre. For example, the data required for an application can come from the roadside sensors, from the vehicle (via a node or sent directly to the roadside unit), or also from the Centre. The processing will normally be carried out by the roadside unit. However, some simple processing may be done by the node, or in some cases the Centre. Using this model as a basic framework, it is possible to ‘map’ any of SAFESPOT the Applications (defined by CoSSIB or SCOVA).




6.4 Geographical characteristics of the Platform The SAFESPOT infrastructure-based applications will have two basic types of geographical distribution: associated with static and dynamic black spots, i.e. in local areas and extended (continuous) areas. The semi-static black spots are sections of the road network recognized (according to the accident statistics) as being intrinsically dangerous They include for example sharp bends, dangerous intersections, tunnels, roads prone to ice, etc). This kind of black spot is the primary type to be addressed by the Infrastructure Platform. It will require installation of sensing systems on the specific road section, able to detect the relevant parameters. Alerts will be given via the roadside and also using V2I communications sent to oncoming equipped vehicles (propagated via V2V multi-hop communication). The dynamic black spots consist of risky conditions that arise unexpectedly and suddenly due to a combination of adverse conditions affecting the driving environment. For example, icy conditions on a sharp bend, a queue which builds up behind a bend, an accident which has just occurred, the presence of pedestrian on the road in a blind spot, etc.). These can be addressed by both V2V and by V2I based applications. However, if data is to be acquired from roadside sensors and alerts also communicated from the roadside, it could involve equipping a long stretch of road in order able to deal with safety-critical situations which could arise at any point on the road at any time.

Figure 11 Geographical distribution of local SAFESPOT applications




It should be noted that while the acquisition of data for the Infrastructure Platform may derive from outside this local area, the roadside alerts will always be local, communicated in the immediate area of an identified risk. The typical extent of a SAFESPOT system in order to be able to respond to the applications, is envisaged as a ‘cell’ of at least 250 meters radius, but not larger than one kilometer. In the case of dynamic black spots there could be a series of contiguous cells, but this is only likely for priority roads vulnerable to high risk. In general, the synchronization between the different area will be carried out by the V2V communications (ad hoc vehicle network). It is anticipated that there will be five main kinds of roadside alert: emergency alert: to warn drivers of an immediate danger likely to require emergency braking (e.g. accident, obstacle or stationary queue ahead); lane switch: on a multilane road to avoid a collision due to a blocked lane; recommended speed (respect of the safety margin): to permit safe driving in current conditions (ice on road, dangerous bend, wet road); safety distance warning: to advise drivers to increase their headway (due to risky driving conditions, e.g. slippery road); additional information: provided where possible as back-up to the alerts. The definition of the a set of black spot scenarios to be tackled by SAFESPOT is the responsibility of the subprojects, CoSSIB and SCOVA. These will also define the types of application which should be given priority. A brief description has been given here in order to clarify the context in which the INFRASENS components will be deployed. It is foreseen that while in the future certain parts of the infrastructure, e.g. key stretches of motorway and black spots requiring priority treatment, may be equipped exclusively with the sensing systems developed by SAFESPOT, there are likely to be parts of the infrastructure where other devices already exist and need to be incorporated. It is therefore important that the SAFESPOT architecture is open, in the sense that it can accommodate ‘legacy systems’. It will also be necessary to devise a migration strategy for their gradual upgrade with innovative features and components.




7 System Requirements This chapter presents the system requirements for the infrastructure Platform being developed by INFRASENS, and explains what they are and how they were identified. System requirements consist of a list of features which must be satisfied by the implemented system or in other words represent a guide to follow in the specification phase and in technology selection phase. System requirements definition is a natural step in the characterization of a system and helps to describe what the system is expected to do in order to satisfy a user need.

7.1 Methodology In accordance with the approach proposed by the European ITS Framework Architecture, the methodology followed for defining the system requirements was characterized by the following steps.

Figure 12 Main steps in the definition of the INFRASENS requirements The first step consists in the identification of the main system components and their role, with reference to a Use Case. (A cross link between user needs and use cases is already available and is presented in Chapter 3) The System Requirements are directly derived from the User Needs. They represent the answer to the question “What should the developed system be able to do or what qualities should it possess to meet the User Needs?”. In other words, “What does the user of the system require this system to do?”. The definition of requirements is however an interactive process and requires close correlation with the requirements of the SAFESPOT Applications. For the infrastructure, many applications have already been identified, so it has been possible to incorporate the relative requirements. It should be stressed, however, this is a continuous and process and it is planned to carry out a harmonization of requirements at SAFESPOT level in November. This implies that the INFRASENS requirements listed are still subject to revision.

Systemcomponents User needs Use cases

What the SYSTEM COMPONENT is expected to do

To satisfy the NEEDS of a specific user

Within a USE CASE

Systemcomponents User needs Use cases

What the SYSTEM COMPONENT is expected to do

To satisfy the NEEDS of a specific user

Within a USE CASE




The system requirements are classified in three main categories:

• Functional requirements: these specify the service(s) expected from the system, and/or the functions needed to provide a working system.

• Non-functional requirements: these specify the performance and/or quality attributes of a workable system.

• Context requirements: these specify the context within which the system is to operate, they include the constraints imposed by the environment and the effects that the system introduction might have on the operating environment. These include assumptions made on the environment, or statements as to what is needed for the system to work effectively under the agreed conditions.

7.2 Organisation of the requirements System requirements are presented in tabular format and have been organised according to two different dimensions. Vertical dimension: It was decided to divide the system requirements into five categories which reflect the main elements of the functional architecture for the Infrastructure Platform described in the Chapter 6. These consist of: - DATA ACQUISITION (the requirements of the roadside sensing activities, as well as data acquisition from the vehicle); - PROCESSING (Requirements of the data processing needed to ‘translate’ the raw data into event related information); - ALERT SYSTEM (Requirements of the system responsible for providing alerts to drivers via the roadside or to the vehicles); - CENTRE (Requirements relating to the link with central systems) - COMMUNICATIONS LINKS (between roadside elements and between the infrastructure and vehicles). This is given specific attention since it has been identified as a key point for the implementation of the INFRASENS Platform. Horizontal dimension: For each system component, the following criteria have also been taken into account, reflecting the features already identified in the User Needs:

• General Features

• Installation, Repair, Maintenance

• Quality of Service

• Robustness

• Safety

• Security




• User Friendliness

• Cooperation

• Communication Looking at the table from the horizontal point of view, each requirement is characterized by the following features. Table 14 Explanation of fields in Requirements Table

Title Explanation

System requirement ID

(Mandatory)

Each requirement has a unique ID number traceability purposes. The format used is as follows:

SPX_REQ#ID_themeID#_partnerID#_v1.#>

Where X is the Sub-Project Number The theme is related to the req classification (example_GEN related to a general requirement)

Name

(Mandatory)

Denotes a unique name that complements the ID, but is easier to memorize.

System requirement Definition

(Mandatory)

Each requirement supporting the implementation of a use case must be written in a precise and concise manner using the “shall” language (“The system shall” …). The use of formal methods in the form of modeling languages like UML 2.0 will facilitate the formulation of requirements.

System requirement Relevance

(Mandatory)

This priority will help WP3 to prioritize the items to be developed during the system specifications. The value must either be:

C – Critical, must be incorporated

S – Significant, should be incorporated

I – of Interest, may be incorporated.

Responsibility

(Mandatory)

Specifies the organization and if possible the person responsible for implementing and maintaining a requirement.




Type of System requirement

(Mandatory)

It can be Functional requirement, Non-functional requirement, or Context requirement.

Link to global architecture system requirement

(Mandatory)

ID of the global architecture system requirement identified.

Acceptance (condition)

Is mandatory in case if the word "should" is used in the description attribute. It specifies when the decision will be made and the criteria the decision will be based upon.

Rationale

(Optional)

Is an explanation why this requirement is necessary.

Originator

(Optional)

When particular system requirements are included, the link with a given Sub-Project should be established. It should work as the Client to a particular requirement.

Assumption

(Optional)

Represents the facts we already know about the requirement or design decisions we already made

The List of System Requirements can be found in Part C of this report. It should be noted that the current version is a first draft and that a common harmonisation process with other subprojects is planned in the next months.




8 References Smart Infrastructure Intelligent Infrastructure Futures – The Scenarios – Towards 2025, Dept of Trade and Industry, UK, January 2006 ITS Architectures Guidelines for the Development and Assessment of Intelligent Transport System Architectures (CONVERGE), DSA2.3, Feb 1998, European Communities European ITS Framework Architecture: Overview, D3.6 Issue 1, Aug 2000 (KAREN) European Communities (2000) European ITS Framework Architecture: List of User Needs, D2.02 Issue 1 Aug 2000 (KAREN) European Communities (2000) SAFESPOT Reports Deliverable D1.2.2, C. Zott et al, System Analysis v2.0, Oct 2006 Deliverable D4.2.3, G. Vivo, Use Case and Typical Accident Situation, Sept 2006 Deliverable D5.2.1, P. Matthias et al, Use Case and User Requirements, Sept 2006 Microsensors and sensor networks European Patent Office – Padulosi Ugo – Jet Research srl, “Apparatus to monitor traffic”, published on 25/06/2003, http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1321915&RPN=EP1321915&DOC=cca34af198500ac37b3bf3af7731d8a84f&QPN=EP1321915. Jiagen Ding, Sing Yiu Cheung, Chin-Woo Tan and Pravin Varaiya, “Signal Processing of Sensor Node Data for Vehicle Detection”, 7th International IEEE Conference on Intelligent Transportation Systems (ITSC), October 2004, http://path.berkeley.edu/~singyiu/vehicledetection/publications/documents/ITSC_2004_0013_MoC3.4.pdf. Jiagen(Jason) Ding (University of California at Berkeley), “Vehicle Detection by Sensor Network Nodes”, Master of Science in Electrical Engineering and Computer Science, Autumn 2003, http://path.berkeley.edu/~singyiu/vehicledetection/publications/documents/03Fall_jiagenThesis_EE.pdf. Mobility LAB – Carolina Crespolini, “SMACS informazione a reazione immediata”, no. 4 June-July 2005, http://www.mobilitylab.it/pdf/ML_04_P30_P31.pdf. Sinem Coleri Ergen, Pravin Varaiya, “PEDAMACS: Power Efficient and Delay Aware Medium Access Protocol for Sensor Networks”, July 2004, http://path.berkeley.edu/ ~singyiu/vehicledetection/publications/documents/030714_pedamacs.pdf. Sinem Coleri Ergen, Pravin Varaiya, “PEDAMACS: Power Efficient and Delay Aware Medium Access Protocol for Sensor Networks”, March 2005, http://www.eecs.berkeley.edu/~csinem/academic/publications/pedamacs.pdf. Sinem Coleri, “PEDAMACS: Power Efficient and Delay Aware Medium Access Protocol for Sensor Networks”, Master of Science in Electrical Engineering and Computer Science, Autumn 2002, http://www.eecs.berkeley.edu/~csinem/academic/publications/master.pdf. Yiu Cheung, Sinem Coleri, Baris Dundar, Sumitra Ganesh, Chin-Woo Tan and Pravin Varaiya (University of California, Berkeley), “Traffic measurement and vehicle classification with a single magnetic sensor”, May 2004,




http://paleale.eecs.berkeley.edu/~varaiya/papers_ps.dir/TrafficMeasurementAndClassification.pdf.

Final Report: Needs and Requirements of Infrastructure ... · Status (F: final; D: draft; RD:...

Documents

Transcript of Final Report: Needs and Requirements of Infrastructure ... · Status (F: final; D: draft; RD:...