SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 1 Integrated Project Co-operative Systems for Road Safety “Smart Vehicles on Smart Roads” SP1 – SAFEPROBE In-vehicle sensing and platform ESPOSYTOR (SAFESPOT SYSTEM MONITOR) Piero Mortara, Luciano Picerno – MMSE (from SP3 presentation) SAFESPOTSAFESPOT

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 2 ESPOSYTOR A WIDE VIEW INSIDE SAFESPOT DATA DOMAIN ESPOSYTOR (SAFESPOT SYSTEM MONITOR)

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 3 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

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 4 ESPOSYTOR – Architecture proposals External SAFEPLUG (for developers’ functions) ESPOSYTOR SAFEPLUG In Vehicle SAFESPOT System VANET

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 5 ESPOSYTOR SAFEPLUG ESPOSYTOR – Architecture proposals Integrated SAFEPLUG (for developers’ functions) In Vehicle SAFESPOT System VANET

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 6 ESPOSYTOR – Architecture proposals Integrated in the central SAFESPOT PC (overloading the system?) ESPOSYTOR In Vehicle SAFESPOT System VANET

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 7 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

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 8 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

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 9 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

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 10 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

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 11 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

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 12 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).

SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 13 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