OSGi Based Service Infrastructure for Context Aware Automotive Telematics Daqing ZHANG, Xiao Hang WANG
Kai HACKBARTH
Institute for Infocomm Research 21 Heng Mui Keng Terrace, Singapore 119613
[email protected] [email protected]
ProSyst Software AG Cologne, Germany
[email protected]
Abstract—This paper presents an open standard based, service-oriented infrastructure for provisioning, managing and developing telematics services. Within this end-to-end infrastructure, a novel context aware service architecture has been proposed to acquire, deliver, process, derive and deploy context for enhancing the safety and convenience of the vehicles. Keywords-OSGi; infrastructure
telematics;
I.
context
aware;
service
INTRODUCTION
With the enormous market potential of telematics industry and the rapid technology progress, automotive telematics has become a hot R&D area in mobile computing and intelligent transportation system. So far quite a number of telematics services have been proposed by the automakers and partners, ranging from navigation, emergency roadside assistance, media streaming, remote diagnostics and prognostics, entertainment to the e-commerce and insurance [1]. However, most of the telematics solutions rely on the vertical, proprietary networks and closed platforms, creating islands of non-interoperable technology [2]. Clearly, proprietary solutions exclude third party developers from creating value added services and force wasteful duplications of effort. Mirroring the Internet development, the wide acceptance of telematics can only occur after de facto open standards emerge for a telematics service infrastructure around which a critical mass of developers can build a variety of applications. The Open Service Gateway Initiative (OSGi) [3] was established in 1999 to define open specifications for the delivery and provisioning of multuple services over wide area network to local networks and devices in homes, cars and other environments. The OSGi specifications try to standardise the way for secure and reliable service delivery and provisioning, for remote life cycle mangement of services, for reusing the services as well as for bridging between different networking standards. So far there have been several efforts in adopting OSGi as an open and standard paltform for telematics services, the activities carried out by OSGi Vehicle Expert Group, ERTICO 3GT [4], AMI-C [5] and BMW [6] are among the best known on-going ones.
Safety and convenience is and will always be the core for vehicle design, ubiquitous context information affecting safety and convenience is hidden in the three entities: vehicle, people and environment. The context about vehicle may include engine status, speed, position, acceleration and tyre status etc., the context about people may include the status of the driver, the number of passengers, user preference and permission profile, etc., and the context about environment may include road condition, weather condition, surrounding traffic condition, etc.. Apparently, telematics will become more feature-rich and attractive once the context can be used to enhance safety and convenience. For example, a potential problem with the tyres or road condition ahead can be warned to the driver in advance; a normal call can be conveyed later in order not to distract the attention of the driver driving in a high speed; the driver can discover and download interested movie trials using hot-spot wireless connection when driving into the premises of a gas station. There has been some work bringing the context aware concept to the automotive telematics [2][7][8], however, the ad hoc development mode and tight-coupled context sensing and utilization mechanism set a barrier for the practical deployment of intelligent telematics services. There is a need for a context aware architecture to support the context acquisition, representation, aggregation, interpretation and utilization in the vehicle environment. In this paper, we propose an open standard based, serviceoriented infrastructure which aims to provide a flexible and extensible platform to build innovative telematics services. Within this end-to-end infrastructure, we further propose context aware telematics framework to de-couple the various stages of context processing. In such a way, context can be acquired, aggregated, interpreted and utilized independently as the vehicle sensors evolve. The rest of the paper is organized as follows. First, the overall telematics service infrastructure is introduced in Section II, followed by the description of OSGi based software architecture. Then the context aware automotive service architecture is presented in Section IV. The OSGi telematics platform implementation details are given in Section V. Finally, some concluding remarks are drawn for the paper.
II.
OVERALL SYSTEM INFRASTRUCTURE
In this section, we present the open standard-based, serviceoriented system infrastructure for the context aware automotive telematics system as illustrated in Fig. 1.
and the context aware service architecture will be described in detail. III.
OSGI BASED SOFTWARE ARCHITECTURE
The OSGi service delivery and management system consists of two parts: the backend system and the service gateway platform. A. The OSGi Backend System The backend system stays with the telematics service provider, it enables the service provider to manage the mobile gateways and deliver telematics services to end users, it supports functions such as configuration, diagnostics, update/upgrade and billing. The key features of the backend system include:
Figure 1. Overall System Architecture
The key ideas of the proposed telematics system are: •
The OSGi mobile service gateway is deployed as central control point for interconnecting various internal and external networks and buses such as CAN (Controller Area Network), MOST (Media Oriented Systems Transport), USB, Bluetooth, IEEE 802.11x and GPRS. In such a way, the service gateway can provide local area connection for the devices in the vehicle system through CAN, MOST and wireless; provide wide area connection to the mobile network through GRPS, and provide shortrange hot-spot communication through IEEE 802.11x and Bluetooth. It’s also for hosting telematics services and bridging different service delivery/discovery protocls such as UPnP (Universal Plug and Play), Jini, SOAP and SIP (Session Initiation Protocol).
•
The component-based service infrastructure provides flexible mechanism for remote service download, update and maintenance. It allows services deployed to be discovered and used by other services. The telematics service providers manage mobile service gateways through the use of back-end servers, which are responsible for provisioning, configuring and billing the telematics services. The open service infrastructure can achieve provider independence and hardware platform independence.
•
•
•
Remotely administer the OSGi based mobile service gateways
•
Perform service publishing and service delivery
•
Start/Stop and bill delivered services
•
Remotely troubleshoot and solve user problems
Figure 2. Basic topology of OSGi backend system
The overall structure of the OSGi backend system is shown in Fig. 2, it includes the following fundamental components: •
Service gateway (G1 – G10): the mobile gateway where the OSGi framework is embedded.
•
Gateway manager: manage a set of service gateways and interact with HTTP server and Database.
An embedded Java security model is applied to protect the integrity of the delivered services against unauthorized components. SSL is utilized for secure communication with external network.
•
LDAP server: management engine for database.
•
HTTP server: enables GUI administration for the network administrator.
The context aware telematics service architecture is developed and encapsulated into pluggable OSGi service framework to facilitate the acquisition, aggregation, interpretation and dissemination of context information.
•
Administrator console: web browser to visually manage the network.
In the following sections, the main components of the system infrastructure like the OSGi based software architecture
B. The OSGi Service Gateway Platform The OSGi service gateway platform refers to the software stack embedded in the mobile service gateway. As shown in Fig. 3, the service gateway software architecture consists of
three layers: the OSGi layer, the system layer and the physical interface layer.
Figure 3. Software architecture of OSGi service gateway
The OSGi layer is composed of two key components: the OSGi service framework and service bundles. Service framework provides a service hosting environment as well as a set of common APIs to develop service bundles. It also includes several basic service bundles such as http service, log service, configuration management, permission administration, preferences, user manager, device manager etc.. The rest of the service bundles are provided by service developers, it is important to note that adding any new functionality in the service platform is usually translated into adding new OSGi service bundles. For instance, in order to support service access using SIP, a SIP service bundle is needed handling all the communication issues [9]. The telematics services refer to the services provided to the end users such as the communication service, roadside assistance service, navigation service, etc.. Context aware service bundles are needed to support context awareness, these bundles include the context provider, context interpreter, context manager and context services which will be elaborated in next section. The system layer refers to the Java Virtual Machine and Operating System (OS) in the mobile gateway, the OS performs the functionality of IP forwarding, firewall and Network Address Translation (NAT). The physical interface layer deals with the low-level communications among various in-vehicle devices and external network and devices. THE CONTEXT AWARE AUTOMOTIVE SERVICE ARCHITECTURE To bring context-awareness to automotive environments, we have developed a component-based context-aware service architecture that aims at enabling rapid development and deployment of context-aware automotive services. Central to this architecture, an ontology-based context model is employed throughout the entire process of sensing, interpreting, managing and exchanging context information. As will be presented in this section, our solution for context-aware services converts an automotive environment into a programmable computing system. IV.
A. Modelling of Context Information using Ontology Ontology refers to the explicit and shared understanding of certain domains, which could be conceived as a set of entities, relations, functions, axioms and instances. Ontologies can provide a machine-interpretable semantics of information when different entities (both machines and humans) communicate with each other. Our previous research [10, 11, 12] has shown that using ontology to model context has many advantages: well-defined context ontology helps formalize, model, structure, and inter-link context information, making it possible to be shared and interpreted by independently developed systems. In such a way, rich context information sources become reusable. The evolving nature of automotive services makes complete formalization of all context knowledge an impossible mission. Nevertheless, we observe that certain contextual entities (e.g., location, user, vehicle and computational entity, etc.) are most fundamental for capturing the general condition about the context, as they not only form the skeleton of overall situation, but also act as indices into associated information. Fig. 4 shows a graphical notation of our context ontology modeling concepts about these contextual entities. The context model is structured around a set of classes, each describing a physical or logical object that is associated with its attributes and relations with other classes. Ontology allows the hierarchical structure of sub-class entities, thus providing extensibility to add new concepts for a specific application. ContextEntity
CompEntity Service Agent
locatedIn contains
Location
name longitude latitude temperature ...
Device ...
Legend:
AuthorizedUser
locatedIn contains
User
IndoorSpace OutdoorSpace ...
SensorDevice
InVehicle name age situation ...
Vechicle
LocatedIn
TemperatureSensor
ActuatorDevice
LoadSensor
...
LightSensor
manufacturer Model locatedIn speed temperature ...
...
... Class
Sub-class
Attribute/Relation
Figure 4. A partial context ontology for automotive environments
We choose to use Web Ontology Language (OWL[13]) as the modeling language to implement the context model. Besides the support for object-oriented modeling, OWL also provides additional vocabulary for describing properties and classes: among others, relations between classes, richer typing of properties, and characteristics of properties. OWL’s additional vocabulary helps capture the rich features of context information. For example, we can easily express concept such as “IndoorSpace is disjointed with OutdoorSpace”, or “relation locatedIn and contains are inverse of each other, and both are transitive”. B. Overview of Context-Aware Automotive Service Architecture As shown in Fig. 5, there are several types of service components that are involved in the sensing, interpreting, managing and utilizing context information in an intelligent
automotive environment. All these components are packaged in form of pluggable OSGi service bundles so that they can be remotely deployed and managed. Security Service
Reminder Service
Navigation Diagnostic Service Service
Comm. Service
Environmental Context Provider
HW sensors/ECUs: GPS, in-car weather, speed, noise ...
SW sources: user profile, preference, to-do list, calendar ...
•
Context-Aware Services: context-aware services acquire context information from the context manager and adapt themselves accordingly. One common way in which services are made context-aware is to specify rules that trigger actions when a specific contextual event happens. Our context-aware service architecture makes it easy to program context-aware behaviors by specifying IF-THEN rules [11, 12]. Table 1 shows several examples of rulebased context-aware behaviors:
Context Manager
User situation Interpreter
User Context Provider
Context Manager: The Context Manager manages context provided by distributed context providers and interpreters, offering correlated context knowledge in a flexible, scalable, and reliable manner. Context management process comprises the aggregation of context, the composition of the context into less voluminous refined information, and the extraction and delivery of the required information to context-aware automotive services through a flexible query interface. The basic functions of the Context Manager include providing a persistent repository for maintaining the context information (i.e., context ontology and its data instances), detecting and resolving inconsistent context information, providing abstract interface with which context-aware services can retrieve context information using both query and subscription/notification mechanisms.
...
Context Knowledge Base
Location Provider
•
Context-Aware Services
Context Query Interface
Location Interpreter
position, and schedule, using first-order logic reasoning [11,12].
Context Interpreters
...
Vehicle Context Provider
Context Providers
...
Backend services: Ubiquitous out-car weather, Context road condition ... Sources
Figure 5. The context-aware automotive service architecture
•
•
Context Providers: Context providers are software wrappers (or proxies) for ubiquitous context information sources. They provide abstraction to separate the details of context sensing mechanisms from the high-level context manipulation. Context providers obtain context data from a wide variety of context sources and transform them to semantic representations based on the context model so that they can be automatically shared and interpreted by distributed software services. Context information sources in automotive environments have almost unlimited diversity: context can be acquired from all kinds of software sources (e.g. user profile, calendar, to-do-lists, address book, etc.), hardware systems (position, engine status, speed, in-car temperature, noise etc.), and other external backend services (out-car weather condition, road condition, etc.). Context Interpreters: Context interpreters are responsible for interpreting lower-level context to generate higherlevel context according to the requirements of the respective context-aware automotive service. Low-level context obtained by context providers often are meaningless, and not directly interpretable by upper-level service. Therefore, further processes such as data format transformation, logic reasoning, sensor data fusion and machine learning are required to fill the gap between sensor-driven data and high-level context. For example, a simple Location Interpreter can map absolute GPS coordinates to the name of proximate building, while a complex one can fuse location information from multiple location systems to reduce uncertainty and solve conflict. Another example could be a User Situation Interpreter that can reason about user’s current situation from other context such as location, time, noise/light level, body
TABLE I. Security Service Diagnostic Service Comm. Service Reminder Service
V.
FIRST ORDER LOGIC RULES
IF a stranger is detected in the vehicle AND the time is at night THEN the owner and the security department is warned via phone call IF a potential problem with the tyres is detected OR a door is not locked THEN user is warned in advance AND the vehicle is limited to a certain speed IF a phone call comes AND the user is driving in high speed THEN the call is conveyed later (in order not to distract the attention of the driver) IF home fridge reports the need for milk AND the user is driving pass a supermarket THEN the driver is reminded via voice.
OSGI TELEMATICS PLATFORM IMPLEMENTATION
We have adopted ProSyst's Infotainment/Telematics Suite [14] as the open and scalable platform for telematics service development and management. The Telematics Suite acts as a mediator between the various internal vehicle protocols and bus systems and provides a connection to the external world. It incorporates the key features that streamline the service delivery process: •
interoperability within the in-vehicle network and its components for remote diagnostics and maintenance;
•
dynamic delivery and updates of safety-, information- and entertainment-services from gateway operators or service providers;
•
reusability of software-modules;
•
high security.
natively provided by OSGi framework, the SIP service has been integrated into the mobile service gateway so that both HTTP and SIP can be used to control in-vehicle devices.
For the in-vehicle communication, the platform offers: •
Access to the CAN network and support for particular CAN controllers
•
Pure Java SAE J1939 stack working on top of the CAN 2.0B physical layer.
•
Full support for the MOST protocol For the external communication, the platform supports:
•
HTTP connection
•
WAP and SMS through CDMA/GSM/GPRS network
•
Web Services integration
•
SSL, TLS, and WTLS protocols. The other features of the Telematics Suite include:
•
Support for the telematics system GUI design and implementation. The Suite provides a pure Java GUI library which is OS- and JVM-independent.
•
Support for service personalization. The Suite can deliver personalized services to the subscribers on request.
•
Support of different realms. The telematics customers can benefit everywhere from the same services – in the office or at home. For example, users can access their home security system from the car, exchange data between the car and back-end office systems, etc.
•
Persistent storage for the data. Usually there is no persistent connection between a vehicle system and the back-end systems. A persistent storage on the telematics system to keep application-specific data is required. The Suite provides an embedded object database for the target environments with limited resources. VI.
CONCLUSIONS
In this paper, we have proposed and implemented an OSGi based service infrastructure for context aware automative telematics. Compared with other intelligent telematics solutions, the proposed telematics service infrastructure exhibites the following unique features: •
Telematics services are provisioned and managed using OSGi based service infrastructure, various standards and protocols co-exist and inter-play on top of the OSGi mobile service gateway. Besides the HTTP service
•
A generic context aware telematics service framework is incorporated in the end-to-end solution. Context extration, aggregation, inpretetation and utilization are de-coupled, thus the context aware serivice development can be independent from the low-level sensor evolvement. ACKNOWLEDGMENT
The authors would like thank Chin Chung Yau for drawing Fig. 1 of the paper. REFERENCES [1] [2]
[3] [4] [5] [6] [7]
[8]
[9]
[10]
[11]
[12]
[13] [14]
2002 Automotive News Europe Telematics Conference Presentations, http://www.networkevents.co.uk/events/anetur02/front2.htm C. Bisdikian, I. Boamah, P. Castro, A. Misra, J. Rubas, N. Villoutreix, D. Yeh., “Intelligent pervasive middleware for context-based and localized telematics services,” ACM MobiCommerce 2002, September 2002, Atlanta, USA. Open Service Gateway Initiative, www.osgi.org ERTICO website, www.ertico.com AMI-C website, www.ami-c.org BMW, http://www.osgiworldcongress.com/agenda_BMW_Michel.asp N. Gura, A. Held, J. Kaiser, “Proactive services in a distributed traffic telematics application,” Workshop on Mobile Communication over Wireless LAN: Research and Applications, September 2001, Vienna, Austria. Pablo Vidales, Frank Stajano, “The sentient car: context-aware automotive telematics, “ IEE Seminar on Location Based Services, 16 September 2002. D. Q. Zhang, “A new service delivery and provisioning architecture for home appliances,” Proc. of IEEE International Conf. On Consumer Electronics, June, 2003, Los Angeles, USA, pp. 378-379. T. Gu, X. H. Wang, H. K. Pung and D. Q. Zhang, “An OWL-based context model in intelligent environments,” Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS'04), January, 2004, San Diego, California. X. H. Wang, D. Q. Zhang, T. Gu and H. K. Pung, “Ontology based context modeling and reasoning using OWL,” Workshop on Context Modeling and Reasoning at 2nd IEEE International Conference on Pervasive Computing and Communication (PerCom’04), in press. D. Q. Zhang, X. H. Wang, K. Leman, and W. M. Huang, “OSGi based service infrastructure for context aware connected homes,” In Independent Living for Persons with Disabilities and Elderly Care, M. Mokhtari, Eds. IOS Press, 2003, pp. 81-88. [1st International Conference on Smart Homes and Health Telematics (ICOST2003), Paris, France, 2003]. OWL W3C, Web Ontology Language (OWL) Reference Version 1.0. , W3C Working Draft 31 March (2003) ProSyst: http://www.prosyst.com/solutions_html/info_edition_text.html
