1SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

Integrated ProjectIntegrated Project

Co-operative Systems for Road Safety Co-operative Systems for Road Safety

““Smart Vehicles on Smart Roads”Smart Vehicles on Smart Roads”

SP1 – SAFEPROBE SP1 – SAFEPROBE

In-vehicle sensing and platformIn-vehicle sensing and platform

ESPOSYTOR (SAFESPOSYTOR (SAFEESPOSPOT T SYSYSTEM MONISTEM MONITORTOR))

Piero Mortara, Luciano Picerno – MMSE

(from SP3 presentation)

SAFESPOTSAFESPOTSAFESPOTSAFESPOT

2SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

ESPOSYTOR A WIDE VIEW INSIDE SAFESPOT DATA DOMAIN

ESPOSYTOR (SAFESPOSYTOR (SAFESPOESPOT T SYSYSTEM MONISTEM MONITORTOR))

3SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

ESPOSYTOR - Highlights

• Integrated tool based on a PC Laptop external device• User and Developers oriented features • Monitoring Functions

– LDM– Ego Vehicle Data– Neighbour Vehicles and Infrasens Data– GPS data

• Diagnostic Functions– Modules check– Sensors and Communication Channels (CAN,LAN,WIFI..)

• Trace Functions– Networks Analyzer– Processes Logs– Resources usage

• Management Functions– Application & Configuration Manager– Resources management: Priority, Activation,Deactivation..

• Remote View ? (To be discussed)– Remote monitoring (showroom) using Local Infrastructure and/or direct GPRS connection

4SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

ESPOSYTOR – Architecture proposals External SAFEPLUG

(for developers’ functions)

ESPOSYTOR

SAFEPLUG

In Vehicle SAFESPOT System

VANET

5SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

ESPOSYTOR

SAFEPLUG

ESPOSYTOR – Architecture proposals Integrated SAFEPLUG

(for developers’ functions)

In Vehicle SAFESPOT System

VANET

6SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

ESPOSYTOR – Architecture proposals Integrated in the central SAFESPOT PC

(overloading the system?)

ESPOSYTOR

In Vehicle SAFESPOT System

VANET

7SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

• Different views for users and developers. This is because some functions might not interest “normal” users…

• Hence, the previous slides are specially related to “developers’/debugging” functions. Users’ functions stay within the system (in which PCs? Just on the “main”?)

• Protect “developer” functions with mechanisms such as configuration files or password

• Different type of functions:– LDM oriented– GPS oriented– Process/Application oriented– Network oriented– Remote control oriented

ESPOSYTOR – System Monitor Structure

8SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

• Neighbours table, with vehicles and infrasens on the map.

• Access to LDM information, including other vehicles data (position, track, speed, braking, ….), infrastructure data (TMC, TPEG, diagnostic…).

– Q-API must be used to access LDM data. A parallel access to “raw” data ( from sensors, router ) or intermediate data (from data fusion) may provide useful information for the debug of the data fusion and LDM algorithms.

ESPOSYTOR - Users’ functions

9SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

• Tracks GPS details, with infos about satellites. • Check on map mismatch (map matching. To be discussed with positioning

group).– In this case, data from GPS module are needed, from link between module and

system, using NMEA sentences.– Positioning group answer: they are available to support a log file procedure (for

developers), and check on properly running (positioning) technologies. They are going to implement already something similar inside positioning module (or PC?).

– How much can be placed (in the second part) in message manager part? Interaction with LDM?

• Diagnostic monitor needs specific functions running on the different HW/SW modules able to check correct operations.

• Application & Configuration manager ( activate / deactivate functions,… May take place in SMA which has these management tasks).

– Note : the client part of the whole monitor can be seen as an application (SP4 / SP5) handling a dialogue with all monitored components.

– Going on with the idea of Supervisor. Reckoning of failure mode…(with special functionalities for developers). What can SMA do for it? See also log files and trace section.

ESPOSYTOR - Users’ functions

10SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

• Packet analysers (comm channel data..)

• Network signal strength Information.

• Packet received from other network nodes (vehicles & infrastructure).

• Channel load and congestion.

• Lookahead (message path) and timeout information.– For these functionalities, a dialogue with router is needed,

analysing data flow at a data-link layer. Use of existing “sniffer” possible. Further discussions can be made within VANET group.

ESPOSYTOR - Developers’ functions

11SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

• Trace history (log files).

• Resource usage (CPU, memory)– For these functionalities, it is important to understand how many

different PCs are to be monitored. In any case, all running SW must be able to generate log files from events. For the second point, benchmark can be reused

• Remote control ( V2I, GPRS ?)– Complex item, especially in case some data phone connections are

to be used (not part of Safespot project). An alternative is to use the infrastructure to collect data to be presented in “show room” at test sites.

ESPOSYTOR - Developers’ functions

12SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

ESPOSYTOR - Pros & Cons

PROS• Allow debug “on field”. This can also lead to remote debugging and tracking • Single modules management (HW/SW). Even simulation or test of single parts• Close common understanding with other SPs is needed. In order to monitor

single applications, there must be some functions to be called from system monitor, and some data must be accessible via HW from monitor itself (lines and connectors must be present). This can help however, to force a better design of HW and SW components

CONS• The whole system is really complex; SPs involved in implementation have to

take in charge to include/interface ESPOSYTOR’s components• There are some unclear situations to be verified at global architectural level, and

even within SP3• For “showroom” application, either a GPRS connection is asked (and this is not

part of Safespot project. CALM can mask such a problem, anyway) or a specific connection through the infrastructure (V2I: more possible, but it asks always for co-operation with SP2-SP5, and feasibility of such a solution to be checked).

13SP1 – Meeting March 1st- 2nd 2007 – Pontedera (Pisa)

Electronic Systems

ESPOSYTOR – Effort and workload distribution

• MMSE is available to take in charge this activity• A specific SP3 WP/WT should be dedicated to this job.• A specific SP4 WT (in WP3) is going to be dedicated too.• It should be good if in WTs representatives from all SPs (or at least people knowing

well activities in other SPs) are present.• Some sub-parts of ESPOSYTOR have to be taken in charge in others SPs (1,2,5..)• Interest also from SP2 and SP5 (plus SP1, already known)• A good collaboration and contents agreement as well as technical contributions

from all SAFESPOT partners involved in development are fundamentals for the success of this realization