SP1 – SAFEPROBE · Contract N. IST-4-026963-IP SF_D1.3.4_PublicHwSwSpec_v1.1.doc Page 8 of 50...

Deliverable D1.3.2 Dissemination Level (CO) Copyright SAFESPOT

Contract N. IST-4-026963-IP

SF_D1.3.4_PublicHwSwSpec_v1.1.doc of 50 SP1-SAFEPROBE

SAFESPOT INTEGRATED PROJECT - IST-4-026963-IP

DELIVERABLE

SP1 – SAFEPROBE

Deliverable No. (use the number indicated on technical annex)

D1.3.4

SubProject No. SP1 SubProject Title SAFEPROBE

Workpackage No. WP3 Workpackage Title Specification

Task No. T1.3.5, T1.3.6 Task Title HW/SW Platform Specification

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

Christian Zott, Chris Brown, Bosch; Florian Ahlers, Ibeo

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

Version No: 1.1

File Name: SF_D1.3.4_PublicHwSwSpec_v1.1.doc

Planned Date of submission according to TA: 31/08/2007

Issue Date: 23/04/2008

Project start date and duration 01 February 2006, 48 Months

Hardware and Software Platform Public Specification




Revision Log

Version Date Reason Name and Company

1.0 20-04-2008

First version proposed for publication Christian Zott, Bosch

1.1 23-04-2008

Modifications to CPDF, Piaggio PTW sections

Florian Ahlers, Ibeo Paolo Cravini, Piaggio




Abbreviation List CPDF Cooperative Pre-Data Fusion

DB Database

ESPOSYTOR SAFESPOT SYSTEM MONITOR

GDF Geographic Data Files

DF Data Fusion

GW Gateway

HW Hardware

IPC Inter-process communication

LAN Local Area Network

LDM Local Dynamic Map

MPV Multi-Purpose Vehicle

NTP Network Time Protocol

OEM Original Equipment Manufacturer, here Vehicle Manufacturer

OR Object Refinement

PTW Powered Two/Three Wheeler

SF SAFESPOT

SR Situation Refinement

SW Software

VANET Vehicular Ad-hoc Network




Table of contents Revision Log ............................................................................................................................................2 Abbreviation List......................................................................................................................................3 Table of contents ......................................................................................................................................4 List of Figures ..........................................................................................................................................5 List of Tables............................................................................................................................................5 EXECUTIVE SUMMARY ......................................................................................................................6 1. Introduction ......................................................................................................................................7

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

2. SafeSpot System Overview ............................................................................................................11 2.1. System Fundamentals.......................................................................................................... 11 2.2. Moving Node’s Functional Components............................................................................. 13

2.2.1. In-Vehicle Sensing.......................................................................................................... 14 2.2.2. Data Fusion..................................................................................................................... 14 2.2.3. Local Dynamic Map Database Server ............................................................................ 15 2.2.4. Message Generation and Routing ................................................................................... 16 2.2.5. SF Application Clients.................................................................................................... 16

3. Platform Hardware Architecture and Components.........................................................................18 3.1. General HW Architecture Concept...................................................................................... 18

3.1.1. Truck and Passenger Car Configuration ......................................................................... 21 3.1.2. PTW Configuration ........................................................................................................ 22

3.2. In-Vehicle Network.............................................................................................................22 4. Software to Hardware Allocation ...................................................................................................25

4.1. Overview of Hardware Component Functions .................................................................... 25 4.1.1. OEM Sub-Systems and Gateways .................................................................................. 25 4.1.2. Positioning Devices and Positioning PC......................................................................... 26 4.1.3. VANET Router and WLAN Card .................................................................................. 26 4.1.4. Main Platform PC........................................................................................................... 27 4.1.5. Laserscanner PC ............................................................................................................. 27 4.1.6. ESPOSYTOR PC ........................................................................................................... 28

5. Software Architecture of Data Fusion Platform PCs......................................................................29 5.1. Software Architecture of Main Platform PC ....................................................................... 29

5.1.1. Soft versus Hard Real-Time System............................................................................... 29 5.1.2. Software Architecture Model.......................................................................................... 30 5.1.2.1. LDM Database Server and Client Processes.............................................................. 30 5.1.2.2. Data Fusion & Coordinator Process........................................................................... 33 SW Framework............................................................................................................................... 36

5.2. SW Architecture of Laserscanner PC.................................................................................. 37 6. Conclusions ....................................................................................................................................39 7. References ......................................................................................................................................40 8. Annex .............................................................................................................................................41

A. Demonstrator / Test Vehicles ................................................................................................... 41 I. Volvo Trucks....................................................................................................................... 41 II. CRF Passenger Car..............................................................................................................43 III. Renault Passenger Car......................................................................................................... 44 IV. PIAGGIO Powered-Two-Wheelers..................................................................................... 47

B. Laserscanner System for Positioning and Cooperative Pre-Data Fusion (CPDF).................... 49 I. Architecture description ...................................................................................................... 49




List of Figures Fig. 1 Methodology Used for Developing the Specifications................................................................... 9 Fig. 2 Centralised Node Architecture ..................................................................................................... 12 Fig. 3 SAFESPOT Node Functional Component Diagram (Guyancourt Diagram) ............................... 13 Fig. 4 Functional Component Diagram of Data Fusion.......................................................................... 14 Fig. 5 Local Dynamic Map..................................................................................................................... 16 Fig. 6 General SAFEPROBE Hardware Architecture ............................................................................ 18 Fig. 7 SAFEPROBE Hardware Architecture.......................................................................................... 21 Fig. 8 SAFEPROBE Hardware Architecture (PTW option) .................................................................. 22 Fig. 9 Database Server and Client Processes.......................................................................................... 31 Fig. 10 Main platform PC SW Processes, On-line Configuration .......................................................... 32 Fig. 11 Main PC SW Processes, Replay Configuration.......................................................................... 33 Fig. 12 Example of Threads’ Synchronization inside the Main PC........................................................ 35 Fig. 13 Software Architecture of the Cooperative Pre-Data Fusion ....................................................... 37 Fig. 14 Volvo Demonstrator Vehicle...................................................................................................... 41 Fig. 15 Fiat Demonstrator Vehicle ......................................................................................................... 43 Fig. 16 Renault Demonstrator Vehicle (MODUS) ................................................................................. 45 Fig. 17 Renault Demonstrator Vehicle (LAGUNA)............................................................................... 45 Fig. 18 Renault Demonstrator Vehicle (ESPACE)................................................................................. 46 Fig. 19 Piaggio Demonstrator Vehicle ................................................................................................... 48 Fig. 20 Hardware Architecture of the Cooperative Pre-Data Fusion...................................................... 50

List of Tables Table 1 Volvo Truck Characteristics ...................................................................................................... 42 Table 2 Volvo Truck Sensing System .................................................................................................... 42 Table 3 Fiat Passenger Car Characteristics............................................................................................. 43 Table 4 Fiat Passenger Car Sensing System........................................................................................... 44 Table 5 Renault MODUS Characteristics............................................................................................... 44 Table 6 Renault LAGUNA Characteristics ............................................................................................ 45 Table 7 Renault ESPACE Characteristics .............................................................................................. 46 Table 8 Renault Passenger Car Sensing Systems ................................................................................... 47 Table 9 Piaggio MP3 Characteristics ..................................................................................................... 47 Table 10 Piaggio Sensing System .......................................................................................................... 48 Table 11 Laserscanner Performance Specifications ............................................................................... 50




EXECUTIVE SUMMARY The SAFEPROBE vehicular platforms will host a variety of modules developed semi-independently by a variety of working groups. These platforms will exist in a variety of configurations based on available data (sensors), desired functionality and physical constraints. These configurations include a solution with one or two PCs for the Piaggio PTW and more comprehensive configurations for the passenger cars and trucks. The latter have an Ethernet-based LAN that may consist of a main PC (hosting data fusion and the LDM), an ego-positioning PC, a VANET router, an applications PC and a Laserscanner PC. A gateway will provide an interface between the OEM sub-system and the SF LAN. In addition, provision has been made for the inclusion of an ESPOSYTOR PC to monitor the operation of the node. With such a diverse range of modules and configurations, a software framework based on Qt has been proposed to support rapid development, efficient use of computing power and operating system independence. It is believed that this advanced, flexible framework will allow SF developers to concentrate on algorithms and functionality rather than low-level details of the implementation. The specification of the SAFEPROBE platform, as described in this deliverable, provides an overview of the hardware and software architecture of the platform and the framework that will support the development of the functional modules.




1. Introduction The SAFEPROBE subproject is responsible for the vehicular platforms to be used in SAFESPOT. This document presents the specification of the hardware and software that will be present in these platforms. The requirements of these systems have already been identified during the Needs and Requirements phase and have been provided in deliverables such as D1.2.3 [2]. The platforms should meet these requirements and support system development without imposing too many constraints. Consequently, they sometimes need to balance competing demands, e.g. physical constraints on the dimensions of the system against computing power. Nevertheless, the hardware and software platforms to be developed should provide stable, flexible bases to support the sensors and systems that will deliver the functionality of SAFESPOT. Acknowledging and accommodating the range of users’ needs and requirements presents a major challenge in the design of the platform. Every effort has been made to provide as much concrete detail in this deliverable as possible. Nonetheless, some aspects of the specification have only been able to be provided in, what may be considered, more general terms. In reading this document, the reader should be aware that, due to the evolutionary and interactive nature of the project, some specifications have dependencies that are unresolved at the time of writing. This document describes the current state of the vehicular hardware and software specification. It is fully anticipated that some aspects of the specification will become more detailed as the operation of different components becomes more clearly defined. It is also accepted that other aspects of the specification may need to be refined or changed in the light of constraints during the implementation phase.

1.1. Innovation and Contribution to the SAFESPOT Objectives

Typically today’s driver assistance and information systems have been designed for a specific set and configuration of sensors and data sources as well as certain use cases and scenarios. Changing configurations, sensors, use cases or scenarios usually results in a largely different system design, i.e. poor or no reuse of the original system design or signal processing components such as data fusion. In this respect, SAFEPROBE intends to be significantly innovative by providing a platform which is flexible and scalable to accommodate a wider range of sensors, other input data and vehicle configurations as well as use cases and their associated scenarios. For example, the client-server design of the platform with the Local Dynamic Map (LDM) as the configuration independent central element shall be constant for all safety system use cases and scenarios defined by SP4 and SP5. Furthermore, the LDM shall act as the single interface to all SAFESPOT applications and abstract the ego-




vehicle state and the representation of the vehicle’s surroundings, i.e. hiding all sensor and vehicle specifics from the applications. The LDM shall also be capable of serving a number of concurrent applications in parallel. In this sense, the SAFEPROBE system can be regarded as constant middleware between the varying platform inputs (sensors, internal and external data sources) and various sets of applications. As a result of this approach, the HW and SW of the prototype platform has to produce a single design capable of supporting different sets of applications, vehicle types and equipment configurations that will be considered in the SP4, SP5 and Test Site subprojects. Since these platforms will host components developed by a number of different subprojects, this specification is not just of importance internally to SP1 but to the greater SAFESPOT project, including the Test Site subprojects and beyond. It describes the state of the work that develops interfaces (software and hardware) between components that will be implemented by independent working groups.

1.2. Methodology The approach to drawing up the specifications follows the guidelines provided by the subproject SCORE (illustrated in the diagram below). The underlying methodology is based on the process set out in the European ITS Framework Architecture. The adaptation of this process for SAFESPOT consists of four interlinked stages (see Fig. 1). The activities regarding the Infrastructure and Vehicle Platforms are shown on the left. The first stage involves defining the functional areas and data flows, which are derived from the system requirements (see deliverable D1.2.3). This stage is described in greater detail in D1.3.1 Data Fusion Specification.




Fig. 1 Methodology Used for Developing the Specifications The next important step consists of identifying the input/output parameters of the in-vehicle platform data processing, in particular: - the output of the in-vehicle systems (for vehicle dynamics, body/comfort, environmental perception, occupant safety, etc.) for the data fusion process - the output of the data fusion process for the LDM This information is presented in tables to be found in the appendices of D1.3.1 or the public D1.3.3. Based on the results of these 2 stages and the mentioned flexibility requirement of the prototype for different vehicles, configurations and applications (use cases) a physical architecture has been designed. The vehicle independent part of this architecture is basically a PC network, see chapter 3. On the basis of the physical architecture, the system specifications have been generated for each of the main components of the in-vehicle platform:

• Vehicle data sources and gateway (OEM responsibility)

• Main platform PC (hosting at least Data Fusion and LDM)

• VANET router and message generation (SP3 and SP4/5 responsibility)

• Positioning PC and dedicated sensor systems (SP3 responsibility). The task of specifying the platforms has required constant consideration of the simultaneous developments being made in the other subprojects. Their requirements and expectations have developed in a response to their own progress as they specify their own components. This deliverable provides a description of the result of this iterative, consultative development process.




1.3. Deliverable structure An overview of the SAFESPOT system components, e.g. Data Fusion, LDM, etc. can be found in chapter 2. For more detailed information about these components references to the according specifications are given. Chapter 3 presents the concepts of the hardware architecture design. Different hardware configurations for the test vehicles are shown there. The topic of chapter 4 is the review of the functional components in the hardware devices discussed in the previous chapter. Software modules are described and allocated to the HW components based on their functional descriptions. The software architecture of the main PC and the Laserscanner PC are specified in chapter 5. Proposals for a software framework coordinating and handling processes and threads on the main PC platform are made.




2. SafeSpot System Overview This chapter provides information needed to understand the HW and SW architecture design given in the remaining chapters. It contains mainly informal functional descriptions of the complete SAFESPOT system and the in-vehicle platform in particular. General system specifications can be found in the SP7, SP4 and SP5 deliverables and platform functional specifications in the SP1 deliverables D1.3.1 [3] or the public D1.3.3.

2.1. System Fundamentals The main features of the SAFESPOT system are briefly described below. System scope The SAFESPOT system aims to expand the time horizon for acquiring safety relevant information for driving, compared to autonomous vehicle sensor systems, through the sharing of information. SAFESPOT applications will allow an extension of the “safety margin” – the time between the detection of a potential accident and the occurrence of the accident – from a range of milliseconds up to seconds. Through issuing warnings and advice, more time will be available for drivers to become aware of the potential danger and to undertake the appropriate remedial manoeuvres. No automatic actuation, e.g. no automatic steering, braking and no automatic manoeuvring, is considered in SAFESPOT. Communication Vehicles and infrastructure platforms act as communication nodes exchanging information in the form of SAFESPOT messages across decentralized wireless ad-hoc networks with short communication ranges. A single hop will be in the range of a few hundred meters. Multi-hop connections and position based routing, e.g. geocast routing, will be possible. Communication partners cannot mutually request or acknowledge messages – i.e. there will only be the ability to push information to the network, not pull. The physical and MAC layer will be according to the upcoming IEEE 802.11p standard.




Message generation and use Every node applies the same set of standard rules for message generation as defined by the applications. There will be a defined set of beaconing data to be transmitted periodically as well as event driven messages to be generated only in specific, well defined situations. The warnings and advisories to be displayed to the driver will be generated or selected by each node individually. In addition to these generated messages, nodes will repeat messages which are not directly applicable to themselves, but are relevant for other nodes’ applications. Client-Server node architecture Every node, i.e. vehicle and infrastructure platform, carries a database server called a Local Dynamic Map (LDM) containing its knowledge of its own state and its environment. This database provides a unique access point for applications and message generation as well as server functionality (e.g. data selection, filtering, and grouping) in response to queries and notification requests set by the clients. In the case of the in-vehicle platform, the LDM can therefore be regarded as a mobile server. See Fig. 2 for an illustration of the centralised node architecture.

Fig. 2 Centralised Node Architecture




2.2. Moving Node’s Functional Components

A slightly more detailed UML functional component diagram is shown below in Fig. 3. This diagram has been adopted by the SP7 core architecture group and is sometimes referred to as the ‘Guyancourt’ diagram [8]. It is more detailed with respect to the message generation and naming of the interfaces between the LDM server and the clients. T-API stands for transaction API, Q-API for query API. It also depicts the component development responsibilities of the different subprojects. In the remainder of this section, these functional components are described in more detail. Although only the In-vehicle Sensing and Data Fusion components are developed in SP1, all components will have to be incorporated into the vehicular platforms and, hence, are briefly described here. For more information about these non-SP1 components, readers are referred to the relevant specification documents from SP3 and SP4.

sd Domain Model

Data Processing / Fusion

Message Generation Message Router

Message Stack

This Node's Application #1

This Node's Application #N

Application Coordination

External Application, e.g.

CVIS

VANET Transmitter

VANET Receiver

Actuator, HMI, VMS, ...

LDM

This Vehicle /Infrastructure Node's

Sensing & Data Sources

common LDMev aluation, for

all SFapplications

contextrelev ancechecking

relev ancechecking, e.g.position based

SP1/2

SP3

SP4/5

Q-API

T-API

Q-API

Q-API

messages relevant to this node

messagesnotrelevantfor thisnode

Q-API

determinesat designtime byrules

Fig. 3 SAFESPOT Node Functional Component Diagram (Guyancourt Diagram)




2.2.1. In-Vehicle Sensing Possible and useful in-vehicle sensors and data have been identified during the WP2 Needs and Requirements phase and can be found in D1.2.2 System Analysis of Useful Data, esp. Annex I [1]. These data have been clustered into the following groups: VDM Vehicle dynamics measurements, e.g. speed, steering angle BOD Body systems data, e.g. lighting, wiper status ENP Environmental perception data, e.g. object data from radar,

Laserscanner, vision system OCC Occupant safety systems, e.g. airbag activated NAV Navigation system data, e.g. GPS position, static road map data SVD Static vehicle data, e.g. vehicle length, width, number of axles The particular sensors available will vary between the test vehicles and are described in Section 3.1 and in Annex A.

2.2.2. Data Fusion The functional description of the Data Fusion component is specified in D1.3.1 Data Fusion Specifications [3] or the public D1.3.3. However, for quick reference a functional component diagram is included here. Data fusion has to be interpreted in a wide sense here, since it includes all data produced for LDM input.

Fig. 4 Functional Component Diagram of Data Fusion




The major components of the Data Fusion are:

• Data acquisition, including data decoding, checking and provision in dedicated stores, e.g. shared memory

• Object refinement, including alignment to common reference systems, association of data to (past or predicted) established objects and between different sources and common filtering (tracking) and classification of fused objects

• Situation refinement, in general recognition of defined relations between objects, e.g. based on trajectory prediction, finding relationships between vehicles and lanes (manoeuvre prediction) and among vehicles (traffic density)

• Information provision, where the results of data acquisition (e.g. ego vehicle state), object refinement (e.g. other vehicles states) and situation refinement (e.g. ego and other vehicles manoeuvres) are cast into transactions for the LDM. This component includes the maintenance of the LDM, e.g. removal of obsolete dynamic objects.

2.2.3. Local Dynamic Map Database Server

The concept of combining static digital maps with dynamic environmental objects in a standardized way is the Local Dynamic Map approach. The complete specification of Local Dynamic Map is specified in D3.3.3 Local Dynamic Map Specification [5]. The current view of the Local Dynamic Map is that it consists of four layers (see Fig. 5):

• The bottom layer consists of the (quasi) static information obtained from the digital map provider according to the GDF conceptual approach.

• The second layer extends the static map by further traffic attributes, static road side units and communication node features, intersection features and landmarks for referencing and positioning. These new static data can be seen as a GDF extension for co-operative systems.

• The third layer contains temporary regional information like weather, road or traffic conditions. This layer will use the dynamic object approach.

• The top layer contains dynamic communication nodes as well as other road users detected by in-vehicle sensors mentioned above.




Fig. 5 Local Dynamic Map As mentioned above, the LDM not only provides a unique access point for applications and message generation but, in addition, server functionality such as data selection, filtering, grouping, in response to queries and notification requests as set by the clients.

2.2.4. Message Generation and Routing The Message Generation component contains the rule set determining when to send messages and what they will contain. These rules are defined at design phase by the applications. These rules define under what situations and conditions which messages are to be sent to other nodes via the VANET router. The second component performs message routing. Here, the routing mechanism takes into account not only the positions of the nodes, but performs some analysis of the environmental and/or ego vehicle situation.

2.2.5. SF Application Clients The application clients are responsible for combining the environmental and vehicle state data to detect/predict safety critical situations and eventually issue warnings or advisories to the drivers. Note, that usually there will be multiple applications running in parallel requesting information from the LDM database. They may also generate concurrent or even contradictory warnings. This conflict has to be resolved by an application coordinator which may even activate/deactivate single applications based on its own situation assessment.




There are basically two ways for the clients (and their coordinator) to request data from the LDM database. In the first case, the clients generate queries by defining LDM object relationships as well as filtering, grouping or projection conditions. For example, a client may ask for all vehicles on certain lanes, in the direction of the ego vehicle’s current driving direction, with speed lower than 40km/h sorted with respect to relative distance. In the second case, a client subscribes to an event based or regular/periodic notification. For example, a client requests the LDM to automatically provide it with the ego position, speed and heading every second or to provide it with the vehicles in the next lane once the turn indicators are activated.




3. Platform Hardware Architecture and Components The process of specifying the hardware architecture had several factors to consider. One of the most important of which was that an environment that facilitates rapid prototyping is required – not a commercial product. This allowed the option of using multiple PCs to be considered. Using PCs rather than ECUs will allow the SF developers to concentrate on algorithmic and functional aspects by reducing the required implementation effort. The cost associated with this approach is that the physical profile of the platform needs to be monitored – in the case of a Volvo truck, the number, size and power requirements of the PCs is largely irrelevant, however, the unique physical constraints of the Piaggio PTW platform will require unique solutions. The use of PCs also allows a degree of independence between the SF subprojects. Working groups can develop their implementations in relative isolation before coming together for incorporation into the demonstrator platforms. In this chapter, the HW components of the SF vehicular platform will be described, as well as the different configurations they will be placed in.

3.1. General HW Architecture Concept Given the multiple PC-based approach described, the SF vehicular platform will consist of a group of PCs connected within a LAN with access to the data from on-board sensors (preferably through an OEM gateway, but possibly directly connected to a PC) and the VANET. This is shown in Fig. 6.

Fig. 6 General SAFEPROBE Hardware Architecture




The platform described in this report consists of the follow main HW components:

• The abstraction of vehicle specific data sources is performed by an OEM gateway with SAFEPROBE standardized output. This is consistent with the modular approach being used that should facilitate the independent development of components. Consequently, the inclusion or exclusion of a sensor from a vehicular platform should have minimal affect on subsystems not directly reliant on the sensor. There will be very vehicle specific HW for the OEM gateways. The HW selection will depend on

− the number and type of vehicle buses, e.g. high-speed / low-speed CAN, LIN, MOST, etc.

− the required bandwidth of in-vehicle data and sensor equipment

− the available physical space

− the available power

− the existing HW, SW and tools from other (research) projects. Therefore, some OEMs with less strict physical limitations may prefer more flexible devices such as a PC or AUTOBOX from dSPACE. Others may need a small form factor and low power device, e.g. based on a micro-controller.

• The main platform PC will host the DF module (SP1) and LDM database server (SP3-LDM). SAFEPROBE will follow the CVIS selection for a car PC, since

− Many requirements from CVIS and SAFEPROBE overlap, e.g. automotive suitability, power supply and physical dimensions, processor performance, system memory and hard disk size, number and configuration of interfaces, esp. Ethernet, serial and USB ports, expansion slots and costs.

− Many test vehicles will be used for CVIS as well as for SAFESPOT and therefore the CVIS car PCs (router and/or hosts) can be used for SAFEPROBE as well (with different SW).

− CVIS carried out a rigorous selection process for the car PC. It investigated and compared a number of alternatives with respect to product performance, quality, flexibility, documentation, RFI answer and price.

− There is the possibility of cost savings by CVIS and SAFESPOT group ordering.

The selected car PC is a Pentium M based system, with 1GB RAM, 40GB hard disk, Ethernet, 3 serial and 4 USB ports, 12V/24V, fan-less, 235mm(W) x 180mm(D) x 144mm(H).




• Other parts of client applications (SP4) may also be hosted on the main platform PC or on fully separate, vehicle and HMI specific systems.

• Where possible and appropriate, a separate PC will be used for ego positioning (SP3-POS), esp. for the landmark- and image-based approach. This is primarily motivated by the computational requirements of the image processing algorithms to be implemented. In the absence of environmental perception sensors (e.g. for PTW), the relaxed computational requirements will allow incorporation of the ego positioning into the main platform PC. HW components of the ego positioning subsystem are a dedicated PC to perform image processing and data fusion, a plug-in PCI card hosting accelerometer, gyro and single-frequency GPS receiver, as well as attached camera, laserscanner, DGPS, UWB, GSM modules. Detailed descriptions can be found in SP3 documentations [4].

• The VANET router (SP3-VANET) may exist in a separate hardware unit (either a PC or PDA) or may be incorporated into the main platform PC. Further details of this component can be found in [6].

• A separate Laserscanner PC will process data coming from the Laserscanner. In depth description of the Laserscanner PC is provided in section B.

• For obvious reasons, the ESPOSYTOR system must run on separate hardware to allow unobtrusive monitoring of the platform and its sub-systems [7].

• The PCs will be connected to each other and to the OEM gateway through an Ethernet LAN and switch (see section 3.2).

• On-board sensors provide information about the vehicle, as well as the perceived environment. No sensors will be developed within SF, however sensors to be used within each test vehicle are listed in Annex A.

As mentioned above, the status of several of the hardware components is not fixed. Some changes may be envisaged based on the actual implementation-specific computational requirements, however some are already foreseen based on the likely demonstrator vehicle configurations. At this stage there will be unique SF vehicular platform configurations for:

• Volvo trucks, Fiat and Renault passenger cars (see Annex A section I, II and III) and

• Piaggio PTW (see Annex A.IV). These vehicles will differ in many aspects including:

• physical dimensions and space available for SF platform

• availability of electrical power

• sensor configurations and availability.




The following sections describe the proposed configurations based on the currently available information.

3.1.1. Truck and Passenger Car Configuration The proposed hardware configuration for use in the Volvo truck, Fiat and Renault passenger car is shown in Fig. 7. A few details of the test vehicles and the systems expected to be available are in Annex A.

Fig. 7 SAFEPROBE Hardware Architecture Without space or electrical power restrictions, all PCs (main PC, VANET router, Application PC and Positioning PC) can be included. The configuration in Fig. 7 does not claim to be final, it represents more the general characteristics of the hardware architecture. Both trucks and passenger cars will feed their in-vehicle data (power train/ body data) into the main PC via the OEM Gateway. Apart from the Laserscanner system, all other in-vehicle sensors for environmental perception are separated from the SAFESPOT network by the Gateway as well. Using this Gateway the OEM specific in-vehicle interface is hidden. For use in SafeSpot only the standardized Gateway output is relevant. On the right side of the Gateway in Fig. 7 all SafeSpot PCs are connected to an Ethernet switch which organizes the information or data flow in this network. For example, the Positioning PC will send the positioning information to the main PC. But as ESPOSYTOR is plugged in for monitoring positioning data needs also to be sent to ESPOSYTOR.

VANET

OEM Gatewa

Positioning system

Main PC

Applications PC Ethernet Switch

In-vehicle sensor data

ESPOSYTOR

Laserscanner system

In-vehicle powertrain/ body data

HMI

Note : A reduced (two PC only) version for Piaggio vehicle (PTW) is planned

Firewire




3.1.2. PTW Configuration The Piaggio PTW presents unique challenges for SAFEPROBE. The space available for hardware is clearly limited, as is the available electrical power. In fact, because of this, it is expected that no environmental perception systems will be available. A minimal SF system configuration consisting of a gateway, the VANET router and the main PC is envisaged (see Fig. 8). The main PC will include a simplified version of Positioning module and SP4 applications.

Fig. 8 SAFEPROBE Hardware Architecture (PTW option)

3.2. In-Vehicle Network The in-vehicle network will be an Ethernet based LAN connecting SF HW within the vehicular platform through a central switch. Although in-vehicle sensors have been shown in the HW architecture configuration diagrams above, the in-vehicle network is defined to extend only up to the OEM Gateway – i.e. it does not include the connection between the Gateway and the in-vehicle sensors. Rationale for the use of Ethernet in the SAFEPROBE network

• All devices can communicate point-to-point, e.g.

− Positioning PC gets ENP, NAV, etc. from gateway w/o main PC involvement

− Laserscanner gets VANET message from VANET router PC w/o main PC involvement

− ESPOSYTOR can monitor all data with one (physical) plug.

• Centralized time-synchronization is facilitated:

GW APX

VANET router

USB

ethernet

rs232 ethernet

RS232-Ethernet converter

MAIN PC Gateway (Aprilia)




− Clock synchronization throughout the platform can be performed via LAN (Ethernet) by the Positioning PC (with plug-in sensor PCB from CVIS) using the PPS (pulse-per-second) signal from GPS receiver and an NTP server. On each connected PC, an NTP client would synchronize the local clock to the system time. Due to expected complexity of the implementation, the Gateway will not have to run an NTP client.

− Using the GPS PPS signal, the Gateway will maintain its own synchronized clock for time stamping of in-vehicle data close to its source.

• Ethernet provides plenty of bandwidth, 100Mbit/s standard – much more than CAN.

• It is flexible with respect to protocols, e.g. it allows the use of UDP with small overhead and self defined ports. Whilst UDP does not have an acknowledgment mechanism, experience from other research projects has shown that lost packets are relatively infrequent in a closed, controlled network such as the in-vehicle network described here. Additionally, the possibility of data outages as a result of sensor or communication system unavailability is actively considered. Therefore, the effect of lost packets is tolerable.

• It is standard for PC networking:

− HW: today all PCs have built in network adapters, no extra cards needed, e.g. CAN, switches & cables cheap, cables (cat5) can be up to 100m, EMC will usually not cause any problems

− SW: drivers, sockets, sniffers, etc. available for all SW frameworks and OS (Windows, Linux)

• Many automotive research platforms use or have used it, including CVIS

Ethernet-Switch In the optimal case, a conventional Fast-Ethernet switch can transport 11 MBytes of data per second. By way of comparison, the most efficient Ethernet-switches currently available can transport almost ten times more – 100MByte data per second. Some special features of these switches are:

• Auto-negotiation: the switch automatically determines the fastest possible transmission mode among the connected devices

• The switches maintain the IP-addresses of all connected devices in an internal list

• Network traffic regulation: In order to avoid buffer overflow the switch has mechanism like break-frames or “Back-Pressure”. The transmitters are then asked to make a break before sending data again.

• Low latency: typical latency for small packages (128 Byte) is 3 μs to 5 μs. Large frames (1518 Byte) have latencies about 13 μs to 24 μs.




• Switches offer the ability to assign priority to the frames – Quality of Service (QoS).

• Power consumption of conventional Megabit-Ethernet switches is in the area of 13W to 23W. Gigabit-Switch users must expect 18W to 40W power consumption.

Protocols Within the Ethernet based in-vehicle LAN UDP will be used. This applies only to non-LDM connections. All connections between clients and LDM are due to a database-specific protocol which is usually based on TCP/IP. The major advantage in using UDP is its efficiency. In case of the light weighted overhead due to the lack of checking mechanism like in TCP, the data transport between the applications is much faster and more efficient. Since most of the SafeSpot applications are time-sensitive there will be no benefit from the overhead in TCP. A delayed message is no longer useful and can actually be dropped without any warning.




4. Software to Hardware Allocation Following the description given above of the HW architecture and its main components, this chapter will describe what functionality will be provided by these HW components and the particular SW components that will be required to be deployed. The allocation needs to keep in mind that there are multiple HW configurations and, consequently, functionality based on each demonstrator vehicle’s specifications. This, in turn, will lead to multiple SW to HW allocations.

4.1. Overview of Hardware Component Functions The HW components that will be present in the SF vehicular platform have been listed and briefly described in the previous chapter. Here, the functionality to be provided by each HW component will be described. Where appropriate for non-SP1 HW components, references will be given to other documents from other SF subprojects that describe the HW component and its functionality in greater depth. The information provided here will serve to give an overview of all the components and to provide a demarcation of responsibilities.

4.1.1. OEM Sub-Systems and Gateways The OEM sub-system and gateway provides the access point for the SF system to the in-vehicle and sensor data. As such, it will vary significantly between different demonstrator vehicle models. However, each unit will provide the following functionality:

• data acquisition (polling and interrupt processing of sensors, navigation systems and networks), time stamping based on GPS PPS signal and data formatting for the standard SP1 bus (e.g. UDP)

• networking according to the SP1 bus protocol

• configuration and initialisation of all OEM-components (power-up sequences, built-in test activation and monitoring), error handling

• collaboration with ESPOSYTOR (e.g. transmission of messages to ESPOSYTOR for monitoring)




4.1.2. Positioning Devices and Positioning PC The Ego Positioning system will be developed within SP3. Greater detail can be found in SP3 documentation D3.3.2 Positioning Specifications [4]. In summary, it will perform:

• data acquisition (from cameras, GPS receivers, etc.) and time stamping (based on GPS clock signal)

• networking of the PC with positioning devices and with the main platform PC

• provision of NTP service

• configuration and initialisation of all positioning devices (power-up sequences, built-in test activation and monitoring) and error handling

• processing of data from each positioning device (landmark-based, com-based, UWB-based, relative DGPS) and the fusion of these results to provide enhanced ego positioning

• collaboration with ESPOSYTOR to monitor the activities of the different positioning modules in order to cross-check their results and test the correct operation.

4.1.3. VANET Router and WLAN Card

The exact HW to be used for the VANET router and WLAN card are yet to be determined by SP3. A detailed description is provided in SP3 documentation D3.3.4 Vehicular Ad Hoc Networks Specifications [6]. Its task will be:

• receive and transmit VANET messages (most likely using the IEEE 802.11p physical layer), communication of the router with the card (configuration, initialisation, power-up sequence, built-in-testing, error handling etc.)

• position-based routing, message relevance checking, message storage, management of message stack

• collaboration with ESPOSYTOR, to monitor the messages going in/out from the VANET.




4.1.4. Main Platform PC As the name suggests, this HW component is the core of the in-vehicle system. Amongst all the components of the system, the main platform PC has the most varied tasks to perform and the most interaction with the other HW. On board will be the following functionality:

• networking with all components within the in-vehicle network: the OEM gateway, positioning PC, VANET router, Laserscanner PC, message generation and application clients

• configuration, initialisation, power-up sequence, built-in-testing, error handling of all PC internal (including LDM) and connected external devices

• data fusion (object and situation refinement) in collaboration with LDM database management system (including support for push and pull mechanisms: transactions, queries, subscriptions)

• (optionally) execution of all applications’ message generation (according to SF/SP7 rule set)

• (optionally) POS, including NTP

• (optionally) VANET router

• logging

• collaboration with ESPOSYTOR. Multiple modules running on the Main Platform PC will collaborate with ESPOSYTOR. The two PCs will open a transmission session for data transfer. ESPOSYTOR will require data from the LDM to test the Data Fusion modules.

4.1.5. Laserscanner PC

Due to the significant amount of pre-data fusion processing of the Laserscanner data, as well as its dual roles in SP1 and SP3-POS, the Laserscanner has a dedicated PC. Its responsibilities are limited to the processing of Laserscanner data and auxiliary services:

• networking with the Laserscanner device and with the main platform PC and ego positioning PC

• configuration and initialisation of the Laserscanner device (power-up sequences, built-in test activation and monitoring) and error handling

• data acquisition (from the Laserscanner) and time stamping

• processing of data from the Laserscanner to provide detected objects to the object refinement module in the main PC as well as landmark objects for enhanced ego positioning by the Positioning PC




• collaboration with ESPOSYTOR. Data will be acquired by ESPOSYTOR in order to test the correct operation of the Laserscanner’s modules.

4.1.6. ESPOSYTOR PC

The ESPOSYTOR PC will be used to implement the functionalities of the monitoring tool: it will cooperate with the other HW components to test the efficiency of the modules implemented on them. Specifically, the functionalities of ESPOSYTOR will be the following (refer to D4.3.5 On Vehicle Diagnostics and Monitoring Specifications [7] for a detailed explanation):

• monitoring the operation and efficiency of the Data Fusion module;

• monitoring the activities of the Positioning modules for positioning;

• monitoring the messages sent/received by the ego vehicle to check the operation of the VANET;

• visualizing the environment around the ego vehicle;

• monitoring the state of and the activities done by the SP4 Application Manager and Message Manager;

• monitoring the state of and the activities done by the SP5 Message Manager;

• monitoring the state of and the activities done by the individual SP4 and SP5 applications;

• monitoring the data fusion algorithm working on the infrastructure;

• visualizing the current state of the test site.




5. Software Architecture of Data Fusion Platform PCs

5.1. Software Architecture of Main Platform PC The software architecture of the main platform PC shows the main SW components present on the main PC and their interaction. This is particularly important for this PC given that it has a diverse range of SW developed by a number of SF subprojects deployed on it.

5.1.1. Soft versus Hard Real-Time System Although the demonstrator SF systems are expected to provide real-time warnings and information to drivers, it has been concluded that a hard real-time system is not necessary at this stage – rather, a soft real-time system should suffice. The reasons for this include:

1. There are no closed control loops or automatic actuation, therefore a delay in the delivery of data beyond some deadline will not be catastrophic, although users will perceive system degradation unfavourably (e.g. late and therefore potentially distracting warning or advice). In this context it is important to distinguish between a quick system and a real-time system.

2. The Data Fusion module has to cope with data drop-outs, out-of-sequence data and random delays from the surround sensing (e.g. random physical object detection and random processing time due to varying number of object detections) and VANET (multi-hop, multi-path, driving out-of-range, etc.) anyway, i.e. the surround sensing and ad-hoc network communication are not hard-real-time.

3. All data are assumed to be time-stamped (by the gateway) enabling proper fusion or data rejection (when the data is outdated).

4. Database management systems (to be used by the LDM) usually cannot guarantee any deterministic delays, since the effort for data management (restructuring or indexing following insert, delete, etc.) depends heavily on the number and types of entries.

5. Hard real-time systems often suffer from poorer performance with respect to processing time.

6. There is a lower level of support for SW libraries and tools to be used in hard real-time systems.

7. Integration of the database (LDM) using a third party SW component (e.g. PostgreSQL) into hard real-time systems would pose a significant (if not impossible) problem.




8. Usually SW for hard real-time systems is not portable to other processing platforms

5.1.2. Software Architecture Model

As already mentioned in the previous chapters, the following functional components exist in the main platform PC:

1. LDM database server 2. Data fusion / LDM data producer 3. Message generation client (for certain configurations only) 4. Application clients (for certain configurations only) 5. VANET router (for certain configurations only).

In the following sections, the SW corresponding to each of these components will be described.

5.1.2.1. LDM Database Server and Client Processes The LDM is the main data store in the SF system. Its client-server architecture implies that the components listed above are parallel, concurrently running processes. The database management system (DBMS) of the LDM server is in charge of serializing, scheduling and controlling transactions (database input) and the generation of query responses and notifications (database output). Typically database (DB) systems have a SW architecture similar to that depicted in Fig. 9.




Fig. 9 Database Server and Client Processes The LDM client SW (e.g. the Data Fusion) may run on the same computer as the LDM server SW or, more typically, on a remote computer (e.g. application SW on a remote application PC). The operating systems on the client and server hosts may differ as long as the appropriate database drivers for database access are installed. The communication between client programs and the remote database management system is handled by the database SW and its drivers (typically using TCP/IP connections) and is usually not visible to the remote client. Even if the client resides in the same host as the server, a TCP/IP connection is usually used. As a ‘natural extension’ of this general client-server approach to SAFEPROBE, the main platform PC SW architecture consists of at least two processes under the control of the main PC’s operating system, each communicating via the LAN to their specific communication partners – see Fig. 10.




Fig. 10 Main platform PC SW Processes, On-line Configuration The inter-process communication (IPC) in the main PC between the client process and the LDM database server process is the same as the remote client PC communication. The specifics of the IPC (e.g. protocols and formats) with the LDM cannot be determined at this stage. Of critical importance to this is the support provided by the DBMS to be used for the LDM. At the time of writing, the benchmarking and selection of DBMS by SP3 was not complete. Additional client processes may be added for some configurations if some or all application SW, message generation SW or the VANET router SW will also run in the main PC. These processes would typically communicate only with the DBMS. During system development for system and SW testing and debugging, it should be possible to run the platform in an ‘off-line’ mode with some ‘replay’ of recorded or simulated data. This data will emulate live data from the sensors, the VANET or the applications. This is illustrated in Fig. 11 below which shows an external test-PC emulating all kinds of inputs for the main PC. The emulated data are sent as the real or on-line data via Ethernet to the main PC which has only one single configuration both for on-line and off-line mode. This test-PC can also be used as a data recorder to log main PC’s outputs. By observing the response of the system to fixed, known inputs, the platform can be evaluated under controlled and repeatable conditions.




Fig. 11 Main PC SW Processes, Replay Configuration

5.1.2.2. Data Fusion & Coordinator Process The Data Fusion (DF) and Coordinator process (see Fig. 10 and Fig. 11) have the following sub-functions:

1. Data acquisition 2. GPS-INS based ego positioning (for some configurations only) 3. Object refinement 4. Situation refinement 5. Information provision 6. Process coordination.

Event and time driven sub-functions Object refinement for environmental objects is typically a time-driven periodic process with a fixed cycle time, probably in the range of 100ms. Typically, tracking algorithms, such as Kalman filters, are applied which require a fixed cycle time. The necessary periodic stimulus for the temporal alignment and tracking needs to be provided by a timer. The same will hold for the ego positioning when it is present in the main platform PC (i.e. for platform configurations without a dedicated positioning PC and the corresponding advanced positioning devices). This function, when performed in the main PC, will ‘only’ include the fusion of inertial navigation data (speed, yaw rate, accelerations), GPS and map data into a fixed cycle absolute ego position. By contrast, the data from the OEM gateway will generate events when they arrive at the main PC’s network socket. Some of them, such as vehicle dynamics data (e.g. vehicle speed or steering angle), will generate periodic events, but in general with different data specific frame rates (e.g. 10Hz for




vehicle speed, 100Hz for steering angle). Other data, such as body data, will generate events for a bounded time interval only (e.g. hazard warning lights activated) or just one event (e.g. short-time VANET data). These events will then trigger the necessary check, transformation and formatting tasks of the data acquisition. Therefore, the data acquisition is typically an event driven function, at least when the system runs in on-line mode. In order to support system and SW tests and SW debugging, usually the SW should be executable in an off-line mode, where the data acquisition typically reads recorded or simulated data from files. In this case the data acquisition may be time-driven. The situation refinement will most likely also be event driven, where the events are either generated by the object refinement (e.g. new object data in shared memory) or data acquisition (e.g. new event-type VANET data in shared memory). Although, it is likely that some situation refinement tasks, such as trajectory prediction, will run at similar frame rates as the object refinement, others, such as manoeuvre assessment or traffic density estimation, typically have significantly lower frame rates. Information provision will typically be event driven when the creation of new or modification (update) of existing LDM data is required. On the other hand, it can also be time driven, e.g. in the maintenance case of periodic removal of decayed or outdated LDM entries. In addition to the above, all functions may also perform block processing, i.e. there might be modules which collect data over some cycles and process them altogether. The process coordination is time driven, especially to perform its monitoring and scheduling tasks as well as event driven to react on feedback of the systems’ SW and HW components. Multithreading The preceding discussion shows that a single thread design would not be appropriate. Therefore, the SW framework for the data fusion process should support multithreaded programming allowing multiple threads to exist within the context of the single data fusion process, sharing the process' resources, such as shared memory, but able to execute independently for some time. Example Sequence of Thread Execution As we can see in the figure below the information provision thread is event driven from data acquisition, object refinement and situation refinement threads.




Scheduler/Dispatcher

Data Acquisition

Object Refinement

Situation Refinement

Data Acquisition Data Acquisition Data Acquisition

Object Refinement


Object Refinement


IP IPIPIPIP IP IPIP IP IP

IP = Information Provision

time

Fig. 12 Example of Threads’ Synchronization inside the Main PC The data acquisition thread is reading data from the socket and writing them to a dedicated buffer. When a suffice amount of data is available inside the buffer (we have input from available sensors, VANET etc.) the data are copied inside the shared memory (type of blackboard). The idle cycle between two sequential data acquisition cycles is the time needed to copy the input data to the shared memory. A special care should be considered in case there is a delay in receiving information from socket (e.g. impose a timeout of 50 ms: if this period of time expires without suffice information having been arrived, the system will trigger the processing of whatever data have been collected up to that point). The communication between object and situation refinement modules (in general data fusion modules) will usually use shared memory, often called blackboard memory. This memory contains input and output data structures for every data processing module within fusion process. All these modules have access to the blackboard with read and write properties. The blackboard comprises several sections (e.g. DriverState, EgoFuturePath etc.). Every section contains a time stamp and the specific data. When object refinement is running, every module inside it has a dedicated section inside the blackboard where it can write its results. There is no more than one module that is trying to write in the same section inside the blackboard, so we have no write conflicts. When object refinement has finished its job it triggers situation refinement to start. For the same reason no write conflicts occur inside situation refinement. In this way we can synchronize object and situation refinement threads. Even if that data comes from data acquisition and concerns only situation refinement (e.g. relevant VANET messages) it could be processed within the next situation refinement cycle. The reason for that is the short time interval between two SR cycles and for synchronization purposes.




SW Framework The main requirements for the SW framework selection are that it:

1. is appropriate for a soft real-time system 2. has controllable runtime performance 3. is portable, with at least the possibility to compile the same code (or

with minimal modifications) for different operating systems (Windows family and Linux) and ‘standard’ PCs

4. hides details of platform specifics (e.g. low level operating system calls, type representations, etc.)

5. provides rich libraries, supporting networking, multithreading, file-IO (logging, off-line replay), database support (SQL), graphics (GUI) for development and math functions

6. matches the experience and familiarity of partners with language, tools, etc.

With these considerations in mind, the main options are:

• Non-native programming languages, which are compiled first into an intermediate platform independent code, like byte-code (Java) or CIL/MSIL (.NET) with later just-in-time (JIT) compilation of this code into platform-specific native (machine) code. This implies the need for runtime engines and environments (.NET) or virtual machines (Java)

• Native languages, such as C, C# or C++ which are directly compiled into platform specific native code.

The view is held that non-native languages will execute slower with randomly occurring extended delays. Dynamic array boundary checks, which eliminate a possible source of instability but usually at the cost of slowing down execution, the just-in-time compilation by the virtual machine (at least at start-up) and, significantly, the automatic garbage collection are assumed to be responsible for this undesirable behaviour. Although modern non-native languages perfectly meet requirements 3 to 5, it is believed that only native languages sufficiently fulfil requirements 1 and 2 above. Based on a survey of SAFEPROBE partners, C++ under Windows with Visual Studio SDE is seen to best fulfil requirement 6. In order to still meet requirements 3 to 6 the use of the Qt-framework from Trolltech has been proposed, since Qt provides:

• an extensive C++ class library with over 400 classes for GUI, Database, XML, Networking, Open GL, Multithreading, and more




• a cross-platform application build tool, which reads project sources, generates dependency trees and generates platform-specific project and makefiles

• integration with Visual Studio

• creation of platform-independent database applications using standard databases. Qt includes native drivers for Oracle, Microsoft SQL Server, Sybase Adaptive Server, IBM DB2, PostgreSQL, MySQL, SQLite, and ODBC-compliant databases.

• a mature framework which is in widespread use. For example, Qt is the foundation of KDE, a Linux desktop environment.

5.2. SW Architecture of Laserscanner PC The Laserscanner PC will host the modules which process the data obtained from the Laserscanner. These have been described in section 4.1.5. The component developed as part of SP1 is the Cooperative Pre-Data Fusion (CPDF). This is an environment perception sub-system, providing information about objects in the host-vehicle’s vicinity to the main SAFEPROBE data fusion system. The overall software architecture for the CPDF module is shown in Fig. 13.

scan data pre-processingand segmentation

environment perception datato SAFESPOT system

Laserscanner

V2V data

Coo

pera

tive

Pre

-Dat

aFu

sion

(dynamic) host-vehicle data

static map data(from LDM)

tracking and classification

Fig. 13 Software Architecture of the Cooperative Pre-Data Fusion The CPDF will make use of four data sources feeding into different levels of the pre-data fusion process:




• Laserscanner data (range profile)

• V2V data (static and dynamic information send via vehicle-to-vehicle communication)

• (dynamic) Host-vehicle data

• Static map data (from LDM) Details on the algorithms to be used for the CPDF are described within the deliverable document D1.3.1 [3] or the public D1.3.3. As shown in Fig. 13, the software running the data acquisition and data fusion process within the CPDF will consist of two main software modules:

• Scan data pre-processing and segmentation

• Tracking and classification. Both modules will be developed by IBEO using C++ extended by Boost and Asio libraries. This choice enables operating system independent development and offers well tested and robust functionalities. In particular, the Ethernet communication might be implemented based on these libraries. The Laserscanner PC itself will be running an IbeoOS, which is based on Linux running a 2.6.x kernel and using glibc version 2.6. The operating system is developed and maintained by IBEO and offers stable performance while being extremely configurable and easy to extend. Furthermore, all required hardware drivers are supported natively including the Arcnet interface drivers for communication to the Laserscanner.




6. Conclusions The specification of the hardware and software that will be used on the SAFEPROBE platform is an essential phase in the project, not just in terms of the development of the platform, but also in the coordination between subprojects. The platform will consist of a series of networked computers, hosting a variety of SAFESPOT modules, in vehicle-dependent configurations. These configurations take into account the varying physical capabilities of the demonstrator vehicles, as well as the different sensors that they will deploy. In the most restrictive conditions (i.e. the Piaggio PTW), a minimised set of modules will be deployed on as few as one or two networked PCs. These modules will still be able to provide a defined functionality that identifies it as a SF node; i.e. a data provider, an LDM, a simplified ego-positioning module and a VANET router. In the less restrictive car and truck configurations, enhanced functionality will be available through a greater range of sensors and greater computing power. In terms of software, a framework to support the development of software components by different working groups has been proposed. Due consideration has been given to the in-vehicle network architecture, the anticipated inter-PC communication and functional requirements, as well as the absence of a choice of a single operating system for use throughout SAFESPOT. The information provided in this deliverable has been obtained through a rigorous process that considered the currently identified and possible future needs of the SAFEPROBE platform and the sub-systems it will host. It has identified and considered the roles that each component will play and has sought to define how they will interact and interface. As such, this specification will be used as the basis for the following steps of algorithm development and implementation. In some cases, the specifications here will need to be refined, adapted or expanded as feedback from the development and implementation stages is obtained. However, even as some details may change, it is expected that the main findings of this deliverable will remain and will serve as a central reference point for those developing components for the SAFESPOT vehicular platform.




7. References [1] SafeSpot SAFEPROBE D1.2.2 In-Vehicle Sensing and Platform [2] SafeSpot SAFEPROBE D1.2.3 Requirements for the Vehicle Probe Platform [3] SafeSpot SAFEPROBE D1.3.1 Data Fusion Specification [4] SafeSpot SINTECH D3.3.2 Positioning Specifications [5] SafeSpot SINTECH D3.3.3 Local Dynamic Map Specifications [6] SafeSpot SINTECH D3.3.4 Vehicular Ad Hoc Networks Specifications [7] SafeSpot SCOVA D4.3.5 On-Vehicle Diagnostics and Monitoring Specifications [8] SafeSpot SCORE

D7.3.1 Global System Reference Architecture Specification [9] Specification of User Datagram Protocol

http://tools.ietf.org/html/rfc768 [10] Specification of Internet Transmission Control Program

http://www.ietf.org/rfc/rfc0675.txt [11] http://en.wikipedia.org/wiki/User_Datagram_Protocol




8. Annex In the remainder of the document, supplementary information relating to the specification task is presented.

A. Demonstrator / Test Vehicles Here, only brief overviews of the demonstrator vehicles of the SP1 partners and their equipment are given. More detailed information will be available at a later date in D1.4.1 Platform Prototype and Test Bed Architecture Details and D1.4.2 HW and SW Specifications of Prototype and Test Bed Components. At the time of writing, information was available for a Volvo truck, a Fiat passenger car, three Renault passenger cars and a Piaggio PTW. Note, that the equipment of in-vehicle data sources is very vehicle specific.

I. Volvo Trucks It is planned that the vehicle provided by Volvo will be a FH12 Long-haul tractor. It will be equipped with auxiliary brake systems and an automatic gearbox.

Fig. 14 Volvo Demonstrator Vehicle




a. General Characteristics Width 2.50m

Length 5.99m

Height 3.7m exclusive spoilers

Weight empty 7 200kg

Electrical Power System 12V available

Electronic System 250kb J1939 CAN Table 1 Volvo Truck Characteristics

b. Sensing System The data coming from the vehicle specific systems will be provided via the Gateway (the Laserscanner and the camera will be the exceptions).

Long Range Radar Standard ACC radar

Laserscanner IBEO Laserscanner (see Annex B) mounted in the front right corner of the cab

Lane Tracker Optional

Front Camera Optional, a camera for the DF system in the centre of the truck at ca. 2.2m

GPS Reference System An additional GPS-based reference system for evaluation

Table 2 Volvo Truck Sensing System




II. CRF Passenger Car CRF will make available a Fiat New Bravo production car see Fig. 15. It will be equipped with environment perception systems and a gateway subsystem.

Fig. 15 Fiat Demonstrator Vehicle


Length 4.34m

Height 1.79m

Weight empty 1400kg


Electronic System High speed 500kb CAN, low speed 250kb CAN Table 3 Fiat Passenger Car Characteristics




b. Sensing System The vehicle will have:

Long Range Radar 76 GHz, located behind a bumper penetrable for radar pulse

Laserscanner Rotation frequency from 10Hz to 40 Hz located on the front bumper

Table 4 Fiat Passenger Car Sensing System

III. Renault Passenger Car The SAFESPOT vehicles implemented by Renault for experimentation and demonstration will be as follows:

• Two MODUS type vehicles to be used in Spain as part of the West Site for demonstration and experimental purposes

• One LAGUNA Estate to be used in France as part of the West Site for demonstration and experimental purposes

• One ESPACE to be used in France as part of the West Site for experimental purposes.

a. General Characteristics

The MODUS vehicle is a mini MPV with the following dimensions:

Width 1.71m

Length 3.79m

Height 1.59m

Weight empty 1155kg


Electronic System 500kb/s H.S. CAN 2.0A Table 5 Renault MODUS Characteristics




Fig. 16 Renault Demonstrator Vehicle (MODUS) The LAGUNA Estate vehicle is a Large Family Car category vehicle. It has a large trunk of 475 l volume and will be equipped with navigation system. The dimensions are:

Width 1.77m

Length 4.75m

Height 1.44m

Weight empty 1270kg


Electronic System 250kb/s H.S. CAN 2.0A Table 6 Renault LAGUNA Characteristics

Fig. 17 Renault Demonstrator Vehicle (LAGUNA)




The ESPACE is a Large MPV. It has a large trunk of 650 l volume. It is equipped with navigation system, rain sensor and luminosity detection.

Width 1.89m

Length 4.65m

Height 1.72m

Weight empty 1810kg


Electronic System 250kb/s H.S. CAN 2.0A Table 7 Renault ESPACE Characteristics

Fig. 18 Renault Demonstrator Vehicle (ESPACE) Each vehicle will be equipped with a gateway providing access to the required information in the vehicle CAN-bus, a main PC hosting the SAFESPOT applications described in the HW architecture and a the communication module (VANET Router). Power Supply Units will be available for other computers to be incorporated on board of the above vehicles. That is power outlets at 12 V DC will be available. All components will be installed in the trunk of the vehicles and the necessary fixtures built in.

b. Sensing system The Renault ESPACE will be equipped with GPS automotive and surveyor level automotive modules. A measuring and logging system will provide the true vehicle trajectory and additional kinematics data. The ground truth with respect to spatial-temporal measurements can be made. This can be used to




provide high precise position estimations of the vehicle when evolving in urban like environments. It is likely that the LAGUNA vehicle could host a similar system for evaluation trials. The ESPACE vehicle will have cameras and an IBEO Laserscanner for experimental purposes. MODUS LAGUNA ESPACE

Navigation system x x

Rain Sensor

Luminosity Detection

x

Camera x

Laserscanner x

GPS reference system

x x

Kinematics reference system

x x

Table 8 Renault Passenger Car Sensing Systems

IV. PIAGGIO Powered-Two-Wheelers The PTW platform for SAFEPROBE is a Piaggio “MP3 250 ie”. The base vehicle characteristics are:

• a monocylindrique 244.3cc 4stroke engine

• Continuous Variable Transmission

• water cooled

• fuel electronic injection


Length 2.13m

Height 1.245m

Weight empty 204kg

Electrical Power System 12V available, Lead Battery 14V / 14Ah

Electronic System 500kb/s ISO11898, standard frame format 11 bit Table 9 Piaggio MP3 Characteristics




The CAN Communication System in MP3 has the following characteristics:

• Subsystem Nodes

o Engine control unit (“EMS” node)

o Parking control unit (“NST” node)

Fig. 19 Piaggio Demonstrator Vehicle

b. Sensing System The vehicle has an external temperature sensor and a tilt sensor in addition to positioning sensors. Temperature Sensor Outside temperature

Tilt Sensor Detects if PTW has fallen down

Direction Lights Status of turn indicators (left/right on or off)

Brake Lights Status of brake lever (brake on or off) Table 10 Piaggio Sensing System




B. Laserscanner System for Positioning and

Cooperative Pre-Data Fusion (CPDF) The Ibeo automotive Laserscanner was developed for the integration of this technology into automobiles. It combines a 4-channel laser range finder with a scanning mechanism. The approach within SP1 focuses on road user detection, tracking and classification realised as a Cooperative Pre-Data Fusion process based on Laserscanner data in combination with vehicle-to-vehicle (V2V) communication information and static map data. In addition, a relative ego positioning, developed within the scope of SP3-POS, is performed, based on natural landmarks detected by the Laserscanner. Based on the expected processing requirements and the dual-role of this system, a separate HW module will process all Laserscanner data. The reader is reminded of the proposed HW architecture configurations shown in section 3.1.

I. Architecture description The Cooperative Pre-Data Fusion (CPDF) is performed on a Laserscanner PC providing environment perception results – object state information – to the Main Platform PC as depicted in Fig. 20. The main data source for the CPDF is the Laserscanner integrated into the vehicle’s front bumper. It provides the PC with Laserscanner raw data for further processing via an Arcnet connection. To enable the internal tracking algorithms, the ego motion of the host-vehicle is required, which is provided by the Positioning PC via Ethernet. Additionally, this PC provides the absolute position and velocity of the host-vehicle. This information is needed to request static map data from the Local Dynamic Map (LDM) to improve detection, tracking and classification performance. A fourth input to Cooperative Pre-Data Fusion running on the Laserscanner PC is the VANET PC. Via this connection, V2V data from other road users in the vicinity of the host-vehicle is provided to Laserscanner PC. This input enables and realizes the main cooperative part of the pre-data fusion to increase the reliability and robustness of the detection, tracking and classification algorithms.




Fig. 20 Hardware Architecture of the Cooperative Pre-Data Fusion

a. Laserscanner Device The Alasca XT Laserscanner has been chosen as an environment perception sensing device within SAFEPROBE. It utilizes 4-layer technology to minimize the performance impact of the vehicle’s pitch motion as well as multi-echo technology to improve robustness in precipitation and fog. The subsequent table shows the Laserscanner’s performance specification.

Description Value accuracy +/- 0.1 m max. range 200 m min. range approx. 0.3 m object tracking up to 200 m horizontal field of view

max. 240 deg./Laserscanner (due to the mounting position)

horizontal angle resolution

0.25 deg. or 0.5 deg. or 1.0 deg.

vertical field of view approx. 3.2 deg (in driving direction) vertical angle resolution

approx. 0.8 deg (in driving direction)

distance resolution 0.04 m scanning frequency 12.5 or 25 Hz

sensor dimensions The laser scanner unit is 100x127x157 mm. The mounting weight is 1.3 kg.

Table 11 Laserscanner Performance Specifications

c. Laserscanner PC The Laserscanner PC is a standard embedded PC, running a Linux based operating system. It provides interfaces for Arcnet, Ethernet, VGA, USB devices and CAN. The approximate size of the housing is 210x320x100 mm. The system requires a 12 VDC power supply.

SP1 – SAFEPROBE · Contract N. IST-4-026963-IP SF_D1.3.4_PublicHwSwSpec_v1.1.doc Page 8 of 50...

Documents

Transcript of SP1 – SAFEPROBE · Contract N. IST-4-026963-IP SF_D1.3.4_PublicHwSwSpec_v1.1.doc Page 8 of 50...