SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 1 Integrated Project...
-
Upload
ferdinand-lucas -
Category
Documents
-
view
215 -
download
0
Transcript of SP1 – Meeting March 1 st - 2nd 2007 – Pontedera (Pisa) Electronic Systems 1 Integrated Project...
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