General Assembly, 2 nd day , Orbassano (CRF) 1 SP1 Meeting Christian Zott Bosch (Schwieberdingen, Germany) SP1 “In-Vehicle Platform and Sensing” leader SAFEPROBESAFEPROBE

General Assembly, 2 nd day , Orbassano (CRF) 2 Meeting Topics Management Issues -Cost statements (form C), interim & periodic reports -Amendment: fusion tasks, delivery date fusion specs? -Planning of EC review, participants, 2-3 pages paper for preview, cross check of UCs with SP4/5 -Improvement of information flow Review of some SP1/SP3 decisions Technical challenges Next steps -Scenario Analysis -Detailed fusion concepts -Refinement of SafeSpot/Safeprobe architecture -Message Generation

General Assembly, 2 nd day , Orbassano (CRF) 3 SP1 Schedule and Milestones DF spec to peer review (CRF) public HW/SW spec to peer rev. (CRF) public DF spec to peer review (CRF) HW/SW spec to peer review (Bosch) Activity 4 regular SP1 meetings in 2006: Berlin, Turin, Birmingham, Turin + participation at ~ 6 other SPs + KO + CG D1.2.1, 1.2.2, completed

General Assembly, 2 nd day , Orbassano (CRF) 4 Review of Some SP1 Decisions Allocation of data fusion related tasks -SP3:  Fusion to generate improved ego-vehicle position  LDM database structure, transactions: object creation, update and maintenance methods, SW selection for embedded systems, static map integration, etc.  LDM T- and Q-API specification -SP1:  changed fusion components from internal and cooperative to object and situation refinement  Object and situation refinement for objects of vehicle’s surrounding  Transaction generation  Support to LDM maintenance  Support to LDM T- and Q-API specification No common in-vehicle data gateway for different OEM’s vehicles: Individual HW and SW solutions under OEMs responsibility Common platform HW: Industrial PC (small form factor)

General Assembly, 2 nd day , Orbassano (CRF) 5 Technical SP1 Challenges (1/2) LDM contents (at least SP1,3,4) -Detailed objects attributes (class diagrams) -Uncertainty values (e.g. variances or bounds or probabilities for non-Gaussian errors) -Predicted trajectories in LDM ? -Elementary events in LDM ? (e.g. future collisions, zone entry/exit, neighborship, traffic flow condition) ? -Definition of event codes for efficient inter-platform communication Fusion algorithm development and specification -Uncertainty propagation through data fusion -Situation refinement, e.g. fusion of platform event codes (not unlikely to be necessary due to communication bottleneck) -In-depth scenario analysis: models, simulations, predictions of needed configurations and resulting performance of demo cases -Detailed allocation of tasks considering planning and capabilities of partners, performed questionnaire (evaluation pending)

General Assembly, 2 nd day , Orbassano (CRF) 6 WP 1.3 Specification Next Steps Detailed scenario definition and simulation: -Vehicles’ distances/speeds/accelerations, trajectories, collisions,… -Occlusions by vehicles & buildings, RSU positions, sensor & communication fields-of-view,... -Inspect length of detection time intervals (sensing & com) Design of cooperative concepts: -Sensor-level to central-level fusion: acitivity diagrams, data flow -Data models and dictionary, common with SP2, CVIS (Zoutendijk)  syntax (XML, ASN.1?)  semantics: structure and behaviour (UML, XML) Detailed performance estimation & requirements for data fusion: -Timing: time-to-detect / classify / fuse / decode -Accuracy: e.g. necessary req’ts for collision prediction -“Do-able” scenarios (for given HW: vehicles, equipment)

General Assembly, 2 nd day , Orbassano (CRF) 7 WP 1.3 Specification Next Steps Future trajectory hypotheses based on current dynamic states lane associations traffic light states (stop, pass thru) LDM could provide this* : 10s 0s 10s 0s Object Relations = Elementary Events: lane occupancy by vehicles based on current positions future lane occupancy based on trajectory hypotheses association of traffic light to vehicle based on lane occupancy intersections of trajectory hypotheses current and predicted distances of vehicle pairs to trajectory hypotheses … * by query or notification

General Assembly, 2 nd day , Orbassano (CRF) 8 Technical SP1 Challenges (2/2) Message Definition and Generation -difficult trade-off between needs of applications and constraints from VANET -drives data fusion (what events are needed) and system performance -joint task of SP1-5, 7, should be closely monitored and guided by SP7 In-lab test bed architecture and components (SP1, 3, 4) -development/selection/adaptation of traffic simulator (incl. driver models) -embedding of SP3’s VANET network simulator -embedding of vehicle manufacturers’ specific data source simulators and measurement replay, e.g. for particular in-vehicle sensor data, in-vehicle network, gateway Platform SW framework (SP1, 3, 4) -design should enable/support integration of heterogeneous components, e.g. external VANET module + PreVent sensor & internal fusion comp’ts + off-the-shelf database for embedded systems

General Assembly, 2 nd day , Orbassano (CRF) 9 Improvement of Information Flow RSS news feed For SP1 announcements Controlled and generated (XML) by editor/owner Readers poll feed at user-defined intervals Users “pull” information rather than “push” Numerous aggregators (client program) freely available: dedicated clients built-in functionality with newer browsers (Firefox, IE7) Central archive of activity Sample feed availableavailable

General Assembly, 2 nd day , Orbassano (CRF) 10 Improvement of Information Flow Discussion forum Built-in feature of BSCW No additional software, familiar interface Grouping of related discussions by topic or WP No need for mailing lists (though partners need to be notified a discussion has started) No missed s Partners only read topics of interest Other partners can be “brought in” to discussion at later stage Currently investigating integration with BSCW RSS news feeds for automatic notification Sample forum availableavailable