Semelhante a An OSGi Environment for FlexibleService Concepts - Detlef Kuck, Teamleader Telematics & Navigation Research, Ford Research Centre Aachen (20)
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
An OSGi Environment for FlexibleService Concepts - Detlef Kuck, Teamleader Telematics & Navigation Research, Ford Research Centre Aachen
1.
2. An OSGi Enviroment for
Flexible Service
Concepts
DetlefDetlef KuckKuck
Team Leader Telematics & Navigation ResearchTeam Leader Telematics & Navigation Research
Ford Research & Advanced Engineering EuropeFord Research & Advanced Engineering Europe
3. AgendaAgenda
•• Open Market for TelematicsOpen Market for Telematics
•• Global Systems for Telematics (GST)Global Systems for Telematics (GST)
•• Test Site Aachen /Test Site Aachen / RüsselsheimRüsselsheim
•• Subprojects demonstrated in Test SiteSubprojects demonstrated in Test Site
•• Test Site ArchitectureTest Site Architecture
•• Test CarsTest Cars
6. Creating an Open MarketCreating an Open Market
Service
Provider
Open
Telematics
Market
Service
Provider
Service
Provider
Service
User
Service
User
Service
User
Ease of Market Access
Ease of Market Access
Avoid unduly high
barriers of market entry
Freedom of choice in
service consumption
7. GoalGoal –– Open Market at WorkOpen Market at Work
(3)
Service
Registration
(6)
Browse & Select
Service-Browser
(8)
Service
Download
(9)
Operation
Virtual Path
(2)
Service
Test
Service
Creation
(1)
(7)
Subscription
Request
(5)
Service
Publication
(4)
Login
8. Purpose of GST ProjectPurpose of GST Project
• Create an open market for telematics services
– Create an environment in which innovative telematics
services can be developed and delivered cost
effectively
– Increase the range of economic telematics services
available to manufacturers and consumers
9. Fact sheetFact sheet
• Integrated Project, co-funded by EC 6th framework
• Start: March 2004, end: February 2007 (36
months)
• Total budget: 21,5 M , EC contribution: 11 M
• 49 partners
12. Cross Border Test Site Aachen /Cross Border Test Site Aachen / RüsselsheimRüsselsheim
•• Open SystemsOpen Systems
•• EFCDEFCD
•• RescueRescue
•• Safety ChannelSafety Channel
•• Service PaymentService Payment
13. OpenOpen SystemsSystems –– GST ArchitectureGST Architecture
id OS HL Architecture
Client System
Service Centre
(SC)
Client System
(CS)
Authentication &
Authorization
(AA)
User
Subscriptions
(USubscr)
Client System
Management
(CSMgmt)
Billing Centre
(BC)
Payment Centre
(PC)
Vehicle
(Vehicle)
End-User
I/O Device (IO)
Telematics
Control Unit
(TCU)
«RP»
«RP»
«RP»
«RP»
«RP»
«RP»
«RP» «RP»
«RP»
«RP»
«RP»
«RP»
«RP»
«RP»
«RP»
«RP»
«RP»
«RP»
«RP»
«RP»
17. EFCD FrameworkEFCD Framework
Vehicle
sensor
technology
Status of sensor
objects
unfiltered (e.g.
speed, rain)
Filtered sensor
status exceeding
thresholds (e.g.
pollution data)
Complex
algorithms using
various in-
vehicle sensors
Complex
algorithms using
external service
information
Communication
Module
SC information (e.g. traffic, weather)
In-vehicleapplicationinterface
(e.g.Navi,Rescue,ADAS)
EFCDmessagegenerationandmanagement
EFCDdetectionmanagement
Event-based data
+ information
Raw data
Third Party
Algorithms
Third Party
Algorithms
EFCD
Framework
Standardizedvehiclesensorinterface
Local danger information (e.g. V2V, V2I)
Vehicle
sensor
technology
Status of sensor
objects
unfiltered (e.g.
speed, rain)
Filtered sensor
status exceeding
thresholds (e.g.
pollution data)
Complex
algorithms using
various in-
vehicle sensors
Complex
algorithms using
external service
information
Communication
Module
SC information (e.g. traffic, weather)
In-vehicleapplicationinterface
(e.g.Navi,Rescue,ADAS)
EFCDmessagegenerationandmanagement
EFCDdetectionmanagement
Event-based data
+ information
Raw data
Third Party
Algorithms
Third Party
Algorithms
EFCD
Framework
Standardizedvehiclesensorinterface
Local danger information (e.g. V2V, V2I)
Different
levels of
detection
Possible
implementation
of 3rd Party
algorithms
19. RescueRescue -- ServicesServices
• eCall
– Sending “Minimum Set of Data” (MSD) to a PSAP and
forward that to the ambulance vehicle
• Rescue Vehicle Navigation
– Supporting the ambulance driver with a detailed,
dynamic navigation information to the place the
accident occurs
22. SafetySafety ChannelChannel
• Develop a bearer independent transmission channel for
transporting safety related messages
• Provide Specifications
• Validation via a tested reference implementation
DAB DVB Others
Safety Channel Protocol
Safety Chan
Service
Speed
Limits
Traffic
Info … Others
…
23. Safety ChannelSafety Channel -- Message TypesMessage Types
EventsEventsTraffic messagesTraffic messagesDriverDriver
AWARENESSAWARENESS
Road Surface conditions,Road Surface conditions,
Visibility, Animals / PedestriansVisibility, Animals / Pedestrians
on the Road, Ice / Snowon the Road, Ice / Snow
conditions, general weatherconditions, general weather
warningswarnings
Accidents, Lane restrictions,Accidents, Lane restrictions,
Queues, Road Closures,Queues, Road Closures,
Facilities not working, wideFacilities not working, wide
loads, Road blockedloads, Road blocked
DriverDriver
WARNINGWARNING
+ advice+ advice
FogFog
AvalancheAvalanche
Obstructions, Closures,Obstructions, Closures,
Spillages (leading to poor roadSpillages (leading to poor road
surface conditions), Ghostsurface conditions), Ghost
Drivers, Flooding, Fires,Drivers, Flooding, Fires,
Accidents causing obstructionsAccidents causing obstructions
Driver ACTIONDriver ACTION
+ instruction+ instruction
Location NonLocation Non--specificspecificLocation SpecificLocation Specific
24. Service PaymentService Payment
• Service Payment intends to cover the required
system components and functionalities for the GST
payment and billing architecture, such as:
– Secure transaction environment for payment or
commercial transactions (the Trustable Running
Environment)
– Payment/billing agent in the in-car infrastructure
– Payment/billing entities in the back-office infrastructure
– Specific "wrappers" or connectors to existing payment
solutions/payment infrastructure.
25. Test Site Systems ArchitectureTest Site Systems Architecture
Car with Client system
Car with Client system
Content Centre 1
Content Centre 2
Belgium
Netherland
Russelsheim
Offenbach
Aachen
Cologne
Internet-User
Internet
Control Centre
Service Centre 1
Service Centre 2
Peer-to-Peer
DAB-WDR
DAB-NL
DAB-HR
DAB-BE
GPRS-
Provider BE 1
GPRS-
Provider NL 1
GPRS-
Provider DE 1
GPRS-
Provider DE 2
Content Centre 3
S/PAZ
26. Test Car Focus CTest Car Focus C--MAXMAX
•• HardwareHardware Embedded PlatformEmbedded Platform
•• Extraction of specification for embedded platformExtraction of specification for embedded platform
–– Positioning (GPS, Gyro, SpeedPositioning (GPS, Gyro, Speed--Sensor)Sensor)
–– V2I /V2V communication (GPRS, WLAN)V2I /V2V communication (GPRS, WLAN)
–– Short range communication (Short range communication (BluetoothBluetooth))
–– In Car communication (CAN)In Car communication (CAN)
–– Serial Interfaces (for connecting external modules)Serial Interfaces (for connecting external modules)
–– Broadcast communication (DAB receiver)Broadcast communication (DAB receiver)
27. Test Car Focus CTest Car Focus C--MAXMAX
•• SoftwareSoftware
–– Operating systemOperating system
•• QNXQNX
•• JVM (IBM J9)JVM (IBM J9)
–– OSGiOSGi frameworkframework
•• ProsystProsyst mBeddedmBedded ServerServer
–– Reference ImplementationsReference Implementations
•• Provided by GST subprojectsProvided by GST subprojects
28. Thank you for your attention!Thank you for your attention!
Detlef Kuck
dkuck1@ford.com
www.ertico.com/GST