SP1/4 meeting 2007-09-26/27, BOSCH 1 Main PC SW Processes Processes controlled by operating system Communication (IPC) by database SW db instance DBMSData

1SP1/4 meeting2007-09-26/27, BOSCH

Main PC SW Processes

• Processes controlled by operating system• Communication (IPC) by database SW

db instance

DBMS Data Fusion

shared memory

Client

network socket network socket network socket

Application clients

OEM GW, VANET router, Positioning PC, Laserscanner PC

DB, GPS card driver

Otional client process

Operating system

DF processLDM process

Co-ordi-nator


Main PC SW Framework Fundamentals

• DF process is multithreaded

• All data exchange between threads through shared memory

• Memory is set of ring buffers with cell types, depths, etc. as defined by FW users

• Access to shared memory under control of FW,FW users get shared memory read/write methods for use in their code

• Memory read/write events defined by FW users but generated by FW

• Events induce calls of user’s thread methods

• Event triggered method calls coordinated by FW (scheduler), i.e.

Hollywood principle: ‘Don’t call us, you will be called’

FW: framework


Main PC Data Fusion Process

class SP1_MainPC

coordinator

scheduler

threadList

sharedMemoryframework implemented and compiled into exe and DLLs by Bosch

thread

+ prio: + state:

+ stop()+ wait()+ run()

threadMethods

+ run()

code pieces (e.g. methods) implementedand compiled into DLLs by partners

Example threads:- dataAcquisition- OR_alignment- OR_radar- OR_vanet- SR_centralLevel- SR_ego- SR_obj- SR_event- infoProv- logger

1..*

«realize»


class shared memory

GenericRingbuffer

- start: int- end: int+ readCount: int+ writeCount: int

+ writeItem() : void+ readItem() : voidPOS

+ sysState:

LatLongBuf

YawRateBuf

VDM

+ PowertrainBusState:

speedBuf

brakePedalBuf

steerAngleBuf

:

:

LRR

+ sysState:

distAzRRBuf

NumObjBuf

:

VANET

+ networkState:

NodeStateBuf

NumNodesBuf

BODY

+ ComfortBusState:

TurnSignalBuf

LightsStateBuf

DoorStateBuf

Framework Fundamentals – Shared Memory

• Generic ring buffer defined by FW

→ same access methods and attributes for all ring buffers

• Ring buffer instantiations grouped according to sources (here systems, busses)

→ structured access

• Number and type of buffer objects defined by FW users

→ common class diagram

Example: DAQ output region


FW Fundamentals – Event Flow

DAQ threadDAQ thread

LAN packet arrived

schedulerschedulerIP threadIP thread

method23()method23()

POS

BODY

OR results

SR results

signal23

• Ring buffer events generate signals

• Signals are connected with methods in one or more threads

• Scheduler coordinates method calls

OR threadOR thread


1.

2.


FW Fundamentals – Event Flow Example

DAQ threadDAQ thread

1. FW call following NTsocket event

2. item writing

read

3. reading # unread

writeschedulerscheduler

3. signal23 emission

OR/SR/IP threadOR/SR/IP thread


procPacket() switch(packet.type){ : case x: check(packet); writeSM(pos.lat); if( getUnread(pos.lat)>2 ) emit signal23;

procPacket() switch(packet.type){ : case x: check(packet); writeSM(pos.lat); if( getUnread(pos.lat)>2 ) emit signal23;

condition defined by FW user,which implements method23()

4. call of method bound to buffer condition


Framework Fundamentals

FW requires from FW users: • list of Ring buffer objects (standard C++) with buffer depths• table with event conditions and associated method names to be called

Event Nr Object Condition Thread:method Remark

23 double latLon[2]

unread items > 2 InfoProv:updatePos() lat/long arrives every 0.5sec from SP3 PC, but only every 1s update in LDM

24 double latLon[2]

item written OR_align:alignObj() alignment necessary as soon as new ego position known

25 double latLon[2]

unread items > buffer depth

SysMon:notify(25) buffer overflow exception to be thrown

:

DF Event List, Examples


Main PC 1st Framework Lab Test

• Single PC and single process configuration• No (LAN) networking• Partners test thread implementation and shared memory access• Input to threads via shared memory from files• File and shared memory contents to be defined by thread developers

OR/SR threads

shared memory

player / recorder thread

DF process

Coordinator

recorded / simulated data

Main PC (any PC or eBox)


Main PC 2nd Framework Lab Test

• Still no LDM, only 1 process in main PC• Data logging and replay in external PCs (not eBox)• Test of network driven thread execution and

RT performance (scheduling, network latency,…)

shared memory

Coordinator

DF process


player

network socket

recorder

Main PC under test (eBox)Gw, Router, Appl,… Emulation PC

Ethernet (cross link cable)

network socket

DAQ/OR/SR threads


Main PC 3rd Framework Lab Test

• LDM database integration, 2 processes in main PC• Final SW configuration of main PC• Test of T-/Q-API and RT performance with LDM

(transaction/query latencies, etc.)

db instance

DBMS

shared memory

network socket

DF processLDM process


player

network socket

recorder

Main PC under test (eBox)Gw, Router, Appl,… Emulation PC

Ethernet (cross link cable)

Coordinatornetwork socket

DAQ/OR/SR/IP threads


Framework Fundamentalsact dev cycles

1st framework: DFprocess only, sources:

files on mainPCpartners indiv idually

implement threadmethods (compiled) thread execution and

interfacing tests

general framework mechanisms:- partner's object code integration- thread implementation- interfacing with shared mem and coordinator, e.g.- get/set shared mem methods- event notification / emission

add LAN networking:2nd framework

partners add PCsemulating data sources

(gateway, VANET,positiong, etc.)

tests of data sourcenetworking

- test networking with remote data sources (PC or gateway)- network driven thread excution- RT performance, e.g. latenciesadd LDM database

process: 3rdframework (final)

integration tests withcompound modules

- thread interaction, data exchange- thread coordination- OR-SR collaboration- DF internal RT performance

partners exchange andintegrate object code

partners implementcomponents using

T-/Q-APILDM integration tests

- T-/Q-API functionality- full platform function with emulated data sources- RT performance with LDM

add SP3's VANET routerwith SP4's message

generator client

VANET router integrationtests

- networking with router- RT performance, e.g. latencies (stationary nodes)

add SP4's applicationclients (PC)

1st application lab tests - remote LDM access- RT performancePC network into v ehicle

integration, incl. pos PC

stationary v ehicle tests

mov ing v ehicle tests

test objectivescomponent developmentframework releases test actions

SW frameworkdevelopment

thread development

SP4 co-operation

needed

E10/07

M11/07

E11/07

M12/07

S01/08

E01/08

E02/08fixed

SP1 SW Integration plan


Development Distribution

Partner Frame work

Sharedmem def + event list

DAQ thread

OR threads

SR threads

Info prov thread

Log thread

Pos, Gw, VANET emul.SW

LDM user (query, notific.) tests

PC network integr.

Appl integr., demo

Prep.

WP1.4MM

CRF X X X X X X 25

ICCS X X X 21

Bosch X X X X X X 25

SVDO X X X X 8

Ibeo X X 12

MMSE X X 10

Volvo X X X 11

Renault X X 0

Piaggio X X X 10


Decisions HW SW

• Main PC: eBox 638FL (Plug-In), Pentium M, 1.4GHz, 1GB, 40GB automotive HDD, 12V, up to 100W, 3 serial ports, Ethernet, 4 USB 2.0, 2 PCI slots, PS/2, VGA

• Main PC: Windows XP, C++, partners’ DLLs with Visual Studio or MinGW, Qt commercial license only for framework (Bosch)

• LDM: 2 implementations: Navteq research platform (SQLite), spatial database (PostgresQL, PostGIS)

• VANET router: based on any 802.11a(p) card, NEC/NoW driver under Linux, eBox/PC104/PDA open

Documents

SP1/4 meeting 2007-09-26/27, BOSCH 1 Main PC SW Processes Processes controlled by operating system Communication (IPC) by database SW db instance DBMSData