aharsityolog

Article history:Available online 2 April 2010

Keywords:Intelligent transport systemsVehicular platformOSGiAndroidCloud computing

assistance, navigation, driver aids, remote diagnostics, entertain-ment, and web browsing. The telematics market is currently quiteyoung, and most telematics technologies are independent of eachother due to multiple platform standards. This situation also makesit difcult for service providers to create value-added telematicsservices. Consequently, numerous vehicle manufacturers haveestablished and developed open/standard embedded platforms for

(humanmachine interface) so that both service providers and carmanufacturers can quickly deliver solutions to potential marketsand simplify development. If service providers want to remotelydeploy telematics services to an on-board terminal, or if road-sidecenters need to diagnose vehicular devices or congure telematicsapplications, they should use remote management services thatrely on open/standard telematics platforms.

Telematics applications can be divided into four categories,including VANET embedded systems, vehicularmultimedia embed-ded systems, intelligent driver aid embedded systems, and UrbanNomadic/Pedestrian Telematics embedded systems. First, a VANET

* Corresponding author.

Computer Communications 34 (2011) 169183

Contents lists availab

m

elsE-mail address: lchen@mail.ntust.edu.tw (J.-L. Chen).1. Introduction

In recent years, sophisticated information technology has al-lowed the automotive industry to mature in the eld of telematics.Telematics in automobiles involves the automated convergence oftelecommunications and information technology. So far, automak-ers and third-party serviceprovidershavedevelopedquite anumberof telematics services, including monitoring, emergency road-side

vehicles. These platforms includeOSGi/VEG, AUTOSAR, AMI-C, CVIS,OSEK/VDX, and Android.

Fig. 1 illustrates an open Linux operating system ported into anembedded on-board terminal. This system does not only provide avariety of device drivers, including CAN/LIN/FlexRay buses andout-network connection modules, but also offers resources man-agement. The open/standard telematics platforms in the telematicsmiddleware layer mainly standardize APIs and graphic/vocal HMI0140-3664/$ - see front matter 2010 Elsevier B.V. Adoi:10.1016/j.comcom.2010.03.032With the enormous market potential of the telematics industry and the rapid development of informationtechnology, automotive telematics has attracted considerable attention for mobile computing and Intel-ligent Transport Systems (ITSs). However, as a result of varied platform standards, not all telematics ser-vices can be used in telematics terminals. The main issues are that most telematics technologies dependon vertical, proprietary, and closed Original Equipment Manufacturer (OEM) platforms. These platformsform islands of non-interoperable technology and prevent third-party service providers from creatingvaluable services. This study integrates the Open Gateway Service Initiative Vehicle Expert Group(OSGi/VEG) into an Android platform to generate a vehicular Android/OSGi platform that has the advan-tages of both original platforms. These features include remote management, rich class-sharing, proprie-tary vehicular applications, security policies, easy management of Application Programming Interface(APIs), and an open environment. This study also integrates a cloud computing mechanism into theAndroid/OSGi platform, allowing service providers to upload their telematics bundles onto storage cloudsusing a provisioning server. A management agent in the Android/OSGi platform can simultaneouslyupdate its application service modules using remote storage clouds and use visual intelligence to contin-ually change the distinguishing features of applications based on context-awareness without user inter-vention. To assess the feasibility of the proposed Android/OSGi platform, this study presents a vehiculartestbed to determine the functionalities of different telematics applications. Android/OSGi platformapplications require less memory and system resources than those on the original Android platformwhen performing complicated operations. Additionally, the Android/OSGi platform launches telematicsservices more quickly than the original Android platform. The proposed platform overcomes the problemof frequent non-responsive exceptions in the original Android platform.

2010 Elsevier B.V. All rights reserved.a r t i c l e i n f o a b s t r a c tAndroid/OSGi-based vehicular network m

Ming-Chiao Chen a, Jiann-Liang Chen b,*, Teng-Wen CaDepartment of Computer Science and Information Engineering, National Taitung UnivebDepartment of Electrical Engineering, National Taiwan University of Science and TechncDepartment of Electrical Engineering, National Taiwan University, Taipei, Taiwan

Computer Co

journal homepage: www.ll rights reserved.nagement system

ng c

, Taiwany, Taipei, Taiwan

le at ScienceDirect

munications

evier .com/locate /comcom

tics architecture.

mmsystem allows vehicles to communicatewith other vehicles or road-side units using DSRC/IEEE 1609. For example, if a vehicle has anaccident, it can broadcast an emergencymessage to vehicles behindit using the VANET embedded system. The second type of telematicsapplication is, amultimedia systemthat allowsdrivers towatchDVBprograms, play on-line games, monitor home conditions, and so on.This type of multimedia embedded system takes advantage of high-performance graphics, SoC, or 3D engines when performing compli-cated operations. Third, driver aid systems ensure the security ofdrivers, economize the use of power, and so on. Finally, anUrbanNo-madic/Pedestrians Telematics system provides interactive servicesbetween users and service providers in a non-automotive environ-ment, such as nding local gas stations in an unfamiliar area. Other

Fig. 1. Telema170 M.-C. Chen et al. / Computer Cotelematics services allowdrivers to download/upload or share infor-mation to telematics information platforms using Web servers andout-network connection capabilities.

This study discusses how to combine OSGi/VEG into an Androidplatform to form a new vehicular Android/OSGi platform that hasthe advantages of both original platforms, including remote man-agement/deployment, rich class-sharing, proprietary vehicularapplications, security policies, and more.

2. Related works

2.1. Android platform

The Android platform delivers a complete set of software formobile devices: an operating system, middleware, and key mobileapplications [1]. Windows Mobile and Apples iPhone provide a ri-cher, simplied development environment for mobile applications.However, unlike Android, theyre built on proprietary operatingsystems that often prioritize native applications over those createdby third parties and restrict communication between applicationsand native data. Android offers new possibilities for mobile appli-cations by offering an open development environment built on anopen source Linux kernel. Real hardware can be accessed through aseries of standard API libraries, allowing the user to manage Wi-Fi,Bluetooth, and GPS devices. As Fig. 2 illustrates, the Open MobileAlliance (OHA) [2] and Google support the Android platform andhope to reach the goal of ensuring global mobile services thatunications 34 (2011) 169183operate across devices, geographies, service providers, operators,and networks.

Google has already released the open source Android platform,providing the opportunity to create new adaptive mobile platforminterfaces and applications designed to look, feel, and function asdesired. Consequently, the Android platform has recently beenported into mobile devices, such as notebooks, PDAs, and automo-tive systems. In automotive system elds, the Intel and Wind RiverSystems are actively integrating Android-powered infotainmentoperating systems for vehicles.

2.1.1. Android software stackFig. 3 illustrates the Android software stack [3], which con-

sists of a Linux kernel, a collection of Android libraries, anapplication framework that manages Android applications inruntime, and native or third-party applications in the applicationlayer. The following list species these Android software stackcomponents:

Fig. 2. Open environment for Android platform.

f An

mmFig. 3. Architecture o

M.-C. Chen et al. / Computer Co Linux kernel: A Linux 2.6 kernel manages core services (includ-ing device hardware drivers, process and memory management,security, network, and power management). The kernel alsoprovides an abstraction layer between the hardware and therest of the stack.

Libraries: Android includes various C/C++ core libraries runningon top of the kernel. These libraries include libc and SSL, and thefollowing: A media library for playing multimedia resources A Surface manager to provide display management Graphics libraries that include SGL and OpenGL for 2D and

3D graphics SQLite for data storage SSL and WebKit for integrated web browser and Internet

security Android runtime: Including the core libraries and the Dalvik vir-tual machine, the Android runtime is a runtime environment fornormal Android applications.

Core libraries:While Android development is performed in Java/C++, Dalvik is not a standardized Java VM. The core Androidlibraries provide most of the functionality available in the coreJava libraries and the Android-specic libraries.

Dalvikvirtual machine: Dalvik is a register-based virtual machinethat is optimized to ensure the efcient and stable operation ofmultiple instances. Dalvik relies on the Linux kernel for thread-ing and low-level memory/process management.

Application framework: The application framework provides theclasses used to create Android applications. It also provides ageneric abstraction layer for hardware access and managesthe user interface and application resources.

Applicationlayer:All applications, bothnative and third-party, arebuilt on the application layer using the same API libraries. Theapplication layer runswithin the Android runtimeusing the clas-ses and services available from the application framework.droid software stack.

unications 34 (2011) 169183 1712.1.2. Android platform featuresAndroid offers several unique features that other mobile plat-

forms do not possess:

Google map of navigation applications: Fig. 4 shows that theAndroid platform provides a MapView widget that allows a userto navigate, display, manipulate, and annotate a Google Mapwithin the Activities to build map-based applications usingthe more familiar Google Maps interface.

Background services and applications: Background services allowAndroid applications to use an event-driven model that workssilently while other applications are being used in theforeground.

All applications are created equal: Android does not differentiatebetween core applications and third-party applications, and allapplications have equal access to a platforms capabilities pro-viding users with a broad spectrum of applications and services.

P2P inter-device application messaging: Android offers a peer-to-peer messaging mechanism that supports presence, instantmessaging, and inter-device/inter-application communication.

Breaking down application boundaries: Android breaks down thebarriers to building new and innovative applications. Users cancombine information from the web with their own Androidplatform, including user contacts, calendar, or geographic loca-tion, to provide a more relevant user experience. Further, third-party applications can be downloaded to the users Androidplatform from the Android Market for free.

2.2. Open services gateway initiative (OSGi) service platform

The OSGi platform standard [4] denes a standardized, com-ponents-oriented computing environment for networked servicesthat is the foundation of an enhanced Service-Oriented Architec-ture (SOA). The OSGi specications were initially targeted at

mm172 M.-C. Chen et al. / Computer Coresidential internet gateways for home automation applications[11,12]. However, the standard and extensible features of OSGimake enterprises regard OSGi technology as key solutions. Forexample, Nokia and Motorola adopted the OSGi technology stan-dard for next-generation smart phones, and many car manufactur-ers have embedded OSGi specications into their Global System forTelematics (GST) specications [5]. The OSGi framework providesgeneral-purpose, secure support for deploying extensible anddownloadable java-based service applications, called bundles.OSGi bundles are applications packaged in a standard Java Archive(JAR) le, and contain a manifest le that describes the relation-ships among bundles and the OSGi framework, a series of compiledJava classes, and native code. Fig. 5 illustrates the OSGi frameworkrunning on a Java virtual machine. The OSGi framework provides ashared execution environment that dynamically installs, updates,and uninstalls bundles without restarting the system.

2.2.1. OSGi-based telematics gatewayThe OSGi Alliance whitepaper [10] indicates that the research

and development of OSGi can be extended to any networked envi-ronment, including automobile applications, and implemented incomplex embedded devices that require deployable services. TheOSGi framework makes it possible to access, download, and useservices in an automotive mobile environment, creating an enor-mous potential for automotive manufacturers and service provid-ers to offer new proactive services to drivers and passengers [13].The open standard-based, service-oriented automotive infrastruc-ture for the telematics architecture [14,15] includes a OSGi

Fig. 4. Location-based services for Android platform.gateway, service infrastructure, and self-automobile. The centralcontrol point of the service infrastructure, which is the OSGi-basedtelematics gateway, can be interconnected with various internaland external networks and buses. This gateway acts as an execu-tion environment for mobile automotive services. The followingbundles provide many critical services for OSGi-based telematicsgateway:

Monitoring bundle: This bundle offers basic intelligent vehiclefunctions. By monitoring the status and performance of localvehicle devices, a driver can acquire vehicle information, suchas temperature, various pressure levels, engine uid levels, etc.

Navigation bundle: This bundle provides a navigation systemthat offers navigational assistance to drivers. The systemreceives and processes GPS position information signals todetermine the current latitude and longitude coordinates, anddirection of travel.

Communication bundle: This bundle acts as an OSGi-based tele-matics gateway for in-vehicle or out-vehicle network connec-tions. This bundle extends the functionality of the OSGi-basedgateway by remote deployment of OSGi bundles provided by

Fig. 5. Architecture of OSGi framework.

unications 34 (2011) 169183the service provider. Through CAN, LIN, or MOST [16], theOSGi-based telematics gateway realizes local area connectionsamong in-vehicle devices, and by using GPRS, GSM or even spe-cial ITS FM channels, this bundle allows wide area connectionsamong vehicles, home gateways, remote service centers, androad-side systems.

Driver aid bundle: This bundle provides driver assistance andoffers some warning messages based on lane recognition.

Diagnostics bundle: This bundle provides remote diagnostic ser-vices, allowing complicated diagnostic information to be ana-lyzed and stored in remote systems. This technique is similarto the MYCAREVENT project [17] in that it enables a telematicsgateway to have the capacities of automatic repair and self-management.

Information/Entertainment bundle: Video and audio equipmentare already widely applied in vehicles. Previous research dis-cusses an infotainment server system for in-vehicle users thatallows the network-enabled Information Appliances (IA) toaccess information and entertainment services from an info-tainment server [18].

Automotive operating systems are also very signicant in vehi-cles [19]. By supporting specic device drivers such as CAN/LINbuses, which communicate with other Electronic Control Units

(ECU) nodes for diagnostic purpose, previous studies have embed-ded an OSGi platform in a vASOS automotive operating system[20,21]. Fig. 6 illustrates OSGi-based middleware run on a K VirtualMachine (KVM), which is a compact, portable Java virtual machineintended for small, resource-constrained devices [5]. In addition,previous studies use an OSGi R3 implementation of Oscar to devel-op application bundles, including navigation and CAN/LIN/MOSTaccess bundles. This study takes advantage of OSGi R4 implemen-tation of Apache Felix to integrate with the Google Android plat-form, turning a variety of Google APIs into OSGi bundles, such aslocation-based, peer-to-peer communication, and network man-ager bundles. This approach not only allows service providers todeploy telematics services, but also enhances Android runtimelayer performance and remote management functionality.

The goal of the Vehicle Expert Group (VEG) is to tailor and ex-tend the OSGi specication in order to meet vehicle-specicrequirements. To achieve this, the VEG has dened a list of topicsthat cover vehicle-specic issues. Working with the automotiveindustry, the VEG has specied telematics APIs so that both serviceproviders and car manufacturers can quickly deliver solutions tomarket and increase customer loyalty. The OSGiVEG organizationhas the following automotive projects:

M.-C. Chen et al. / Computer Comm 3GT: The 3GT project [6] is designed to help establish OSGi-based in-vehicle telematics platforms for the European massmarket by ensuring interoperability between the products ofdifferent middleware providers, terminal manufacturers, andservice providers. This will be done by establishing commontelematics interfaces for OSGi-based service delivery. Morespecically, 3GT will develop OSGi-based specications for theinterface between vehicles and control centers and the interfacebetween control centers and service providers.

ITEA EAST EEA: This automotive project [7] is funded by theEuropean Union, and involves major European automotivemanufacturers, rst-tier suppliers, and research departments.The goal of EAST-EEA is to enable hardware and software inter-operability of in-vehicle ECU nodes by dening an open, mid-dleware-based architecture.

Stadtinfokoeln: Stadtinfokoeln is a Cologne-based project [8],funded by the German Ministry of Education and Science(BMBF), that focuses on parking services for the residents orFig. 6. Architecture of vASOS and OSGi-based middleware for vehicles.visitors of Cologne, Germany. The goal of this project is to sat-isfy customer demand and to reduce trafc, which is relatedto parking space availability. An important component of thisproject is the rapid development of information and communi-cation technology in a mobile environment. To fulll theserequirements, the Stadtinfokoeln project managers decided touse an OSGi service platform framework. This has enabled therapid development and deployment of new services.

TOP-IQ: The Eureka-project TOP-IQ [9] focuses on the develop-ment of a new generation of On-Board Computers (OBC) for lux-ury cars and trucks. This type of OBC facilitates telematicsservices for transport and logistics, and conducts the manage-ment, billing, and delivery of new services such as on-line nav-igation, trailer management/tracking, cargo tracking, and more.

2.2.2. Safe deployment of OSGi bundlesThe security of deployment vehicular services is a crucial issue

in the telematics environment. If vehicle owners install third-partyapplications on their on-board vehicle system, they may experi-ence hazardous conditions if those vehicular applications havemany bugs, such as sending mass messages, accessing the securitysensitive areas of the vehicle, and consuming excesses system re-sources. Therefore, it is hard to establish meaningful trust relation-ships in an open environment, and even when one can, trust doesnot equal quality. Previous researchers have utilized Aspect-Ori-ented Programming (AOP) to weave a security enforcement policyinto OSGi bundles [22]. Additionally, AOP provides cross-cuttingfunctionalities in complicated vehicular applications, allowing pro-gram concerns in a software system to be captured and encapsu-lated into so-called aspects. Fig. 7 illustrates the weaving processscenario in a vehicular environment, which involves an in-vehiclesystem, control center, and third-party service providers.

Some vehicle owners install vehicular application bundles bymaking a corresponding request in the GST standard. Beforeinstalling this type of application bundle on an in-vehicle systemover a wired/wireless network, the control center weaves theapplication with security policies so that the woven bundle canoperate with enforcement security policies on the in-vehiclesystem.

2.3. Comparison of OSGi and Android

Fig. 8 shows that both OSGi and Android dene a developmentplatform for developing service-oriented computing mechanismsin mobile devices, and share similar VM technology, service mod-els, component models and openness. The main difference be-tween them is that the Android platform utilizes process-basedisolation to enhance resource management, while the OSGi plat-form uses a classloader-based isolation model. This allows OSGibundles to selectively export some of their internal packages toother consumer bundles. Bundles can declare their package depen-dencies and the framework is responsible for managing depen-dency relationships between consumer bundles and providedbundles. Due to its classloader-based isolation mechanism, theOSGi framework also has the advantage of rich class-sharing. TheAndroid platform uses background services to perform time-con-suming operations, but these services are usually heavyweight,and only can be accessed utilizing inter-process communication,which makes service access slower and more expensive. In OSGi,service components are lightweight. They are called directly whenfound in the service registry. Consequently, OSGi services play asignicant role in keeping components lightweight and looselycoupled. The OSGi specication denes many remote management

unications 34 (2011) 169183 173services, including SNMP, CMISE, CIM, and OMA DM [23]. Utilizingremote management services, managers can easily remotelyadminister an OSGi framework in many situations. These remote

mm174 M.-C. Chen et al. / Computer Comanagement services are not available on the Android platform.The Android platforms lack of class-sharing ability seriously limitsthe sharing of components and remote device management. Thelack of versioning and management APIs is a further limitation.Presumably, OEMs will provide some solutions for these importantrequirements in the future.

3. Open embedded Android/OSGi platform for telematics

Fig. 9 illustrates the proposed architecture for a telematics sys-tem. Here, the Android platform adopts the latest Android 1.5 ker-nel, allowing the proposed Android/OSGi platform to be integratedinto real Android-based hardware devices. This design also allowsthe OSGi R4 implementation to be operated normally in an AndroidDalvik Virtual Machine (VM), developing the communication inter-face between users and OSGi framework in the Android applicationlayer, bridge Android/OSGi applications, and other Android appli-cations. This study also develops an advanced technique forembedding an OSGi instance into Android applications, to make

Fig. 7. The weaving process in

Fig. 8. Comparisons ofunications 34 (2011) 169183them more adaptive and exible. Any time-consuming operations,such as continually loading the main class of OSGi framework andupdating the Android GUI interfaces, will be performed by Androidbackground services. As a result, the proposed Android/OSGi plat-form has high-performance and responsiveness. In the proposeddesign, an iPOJO service-oriented framework is ported and runon top of Android/OSGi applications. The primary goal is to providethe components with a self-management capacity and dynamicallyrespond to service changes in capricious environments. We also in-stalled indispensable OSGi bundles for developing some valuabletelematics applications, such as the Web management console,remote deployment interface, navigation, diagnostics, and so on.Finally, this study develops the management agent to communi-cate with remote cloud called Amazon EC2 through Restful API.The management agent installs/updates local services synchro-nously with remote cloud, and all of Android/OSGi bundles arestored in Amazon S3. This study also implements a provisioningserver to remotely deploying packages or OSGi bundles to the cli-ents Android/OSGi platforms based on Amazon S3.

vehicular environment.

OSGi and Android.

of OSGi framework.

mm3.1. Location of OSGi framework in the Android platform

The Dalvik VM use the devices underlying Linux kernel to han-dle low-level functions, including security, threading, process, and

Fig. 9. Location

M.-C. Chen et al. / Computer Comemory management. Its also possible to read and write C/C++applications that run directly on the underlying Linux OS. How-ever, Dalvik VM can only execute Dalvik executable les (e.g., clas-ses.dex), a format optimized to ensure minimal memory footprint.Consequently it cannot perform general Java packages and OSGibundles, causing OSGi framework operations to fail when Androidencounters OSGi functionalities in runtime. Besides, as Fig. 10shows, if the OSGi framework successfully runs in the AndroidRuntime layer, it cannot directly interact with users, because userscan only view Android Activities (or applications) in the applica-tion layer. For this reason, the Android/OSGi Activity must grab areport or log message from the OSGi framework, and use the An-droid UI to present information to the users. The proposed designuses the OSGi R4 implementation of Apache Felix to integrate withthe Android platform because this container is more portable andlightweight, and better-suited to embedded hardware devices suchas telematics systems.

3.2. Android/OSGi conversion mechanism

The Android/OSGi conversion mechanism uses the OSGi frame-work to dynamically load bundles through the Android Davik VM.Fig. 11 shows the Android/OSGi conversion mechanism, whichmakes the OSGi framework perform a series of complied Java clas-ses from OSGi bundles in the Android runtime layer using a clas-ses.dex le to reference the OSGi bundles general Java classes.Therefore, the classes.dex le plays a bridging role between theOSGi framework and bundles. The proposed design implementsAndroid/OSGi conversion code through Dalvik.system.dexFile API,and imports two parameters, the package name (bundle API pack-ages) and ClassLoader (reading the Java classes) objects. The con-version code then returns the collection of Java classes, allowingunications 34 (2011) 169183 175the OSGi framework to indirectly perform the functionalities pro-vided by the OSGi bundles.

After operating Android conversion mechanism, it is necessaryto ensure that all OSGi bundles or general Java packages containclasses.dex les. This allows the OSGi framework to assume thatany bundle works, share API packages, and let consumer bundlesquery the OSGi services provided by the OSGi framework. This ap-proach adopts the DEX conversion tool from Android SDK. This toolcan easily convert Java complied les into classes.dex les, whichthat Dalvik VM is able to execute. Fig. 12 illustrates the conversionow of OSGi bundles to apk les (Android executive extension); in

Fig. 10. Location of OSGi framework.

3.3. Development of Android/OSGi application

This study had created Android/OSGi application in Androidapplication layer, which can fetch the OSGi corresponding informa-tion from Android runtime layer, and providing interactive envi-ronment between users and OSGi framework. In rst integrationof procedure, this study must to implement Android Activity inter-face, letting Android/OSGi application to have Android Activityproperties. Unlike most traditional environment, Android applica-tions have no ability of control over their own life cycles, Instead,Android application framework must to be in charge of Androidapplications state, and react accordingly, taking particular care to

176 M.-C. Chen et al. / Computer Communications 34 (2011) 169183original, this study had made the OSGi bundle projects to be com-piled, and if no exception will generate a series of Java compiledclasses. After converting into jar les, the DEX tool is used to makejar les containing classes.dex, and he aapt command transformsOSGi bundles into Android apk les. Finally, the adb push com-

Fig. 11. Android/OSGi conversion mechanism.mand is used to push converted the apk les to the Androidplatform.

With the Android conversion mechanism and converted OSGibundles, it is possible to port the OSGi framework to the Androidunderlying layer, along with other functional bundles such as tel-net, deployment admin, http, and remote manager bundles etc.,so that the Android platform can be operated and managed remo-tely. The original platform does not have this ability. Fig. 13 showsthe script of starting the OSGi framework in the Android runtimelayer, and using a Dalvik VM to read the main class of the OSGiframework, enter the OSGi console mode, and show a list of someinstalled bundles. Nevertheless, because users cannot directlyinteract with the OSGi framework in real hardware devices usingthis technique, this study implements Android/OSGi Activity andGUI interface to acquire corresponding OSGi information fromthe underlying layer, and also embeds the OSGi framework intoan Android application to make it more powerful and adaptable.

Fig. 12. Conversion ow of OSGibe prepared for untimely termination. When main launch Activitywhich belongs to Android/OSGi application has become activestate and need to operate continually, the Android applicationframework will pay attention to ensure that the Android/OSGiapplication remains responsive. Therefore Android applicationframework has the capacity of monitoring platform resources atany time, if necessary, will kill some empty or background pro-cesses to free resources for high-priority applications.

The Android application has various Activities, which representa screen that an application can present to its users. Android Activ-ity typically includes at least a primary interface screen that han-dles the main UI functionality for Android application. This isoften supporting additional by secondary Activities for enteringinformation, and providing different perspectives on user data.For example, this study had created the Android views of OSGi con-sole, making users can enter OSGi commands and catch the sight ofOSGi corresponding Information. Every Android Activity has an ini-tializer method called onCreate, by using this initializer method;Android platform can distribute the memory to perform thelauncher thread which can make OSGi framework to be started.Fig. 14 illustrates the cross-communication operation that An-droid/OSGi Activity launches the FelixService (Android backgroundservice) which can represent the GUI interface of OSGi console andto load the main class of OSGi framework after Android/OSGi Activ-ity onCreate method had already been initialized. Android servicesrun without a dedicated GUI, they usually silently perform back-ground works that users cant perceive. Before FelixService torun, they must to be attached with Android/OSGi Activity. Fromdifferent point of view, the Android/OSGi Activity provides AndroidContext object, which makes Android application framework to beable to manage its life states, and communication betweenAndroid/OSGi application and other native or third-partyapplications.

To ensure that the proposed Android/OSGi application remainsresponsive, the proposed design moves all slow and time-consum-ing operations off the main Activity thread and onto a child thread.Examples of slow operations include continually reading the mainclass of the OSGi framework, and updating the GUI interface whenthe OSGi console view has been changed or GUI bundles providebundles to become apk les.

mmM.-C. Chen et al. / Computer Conew screen services. Consequently, this study implements theFelixservice to perform the above-mentioned operations. Fig. 15shows that Felixservice can directly determine the location of theOSGi framework in the Android runtime layer and extract the mainjar le of the OSGi framework, which is Apache Felix of R4 OSGiimplementation. Using the Dalvik ClassLoader object to read themain class continually in child thread, the Android/OSGi platformcan start the OSGi framework in the Android application layer. Inaddition, this study also implements a OSGi console view thatcan fetch the corresponding OSGi message and display them tousers. The OSGi console view has two input/output interfaces thatallow users to immediately interact with the OSGi framework.

Fig. 16 shows that how the Android/OSGi Activity can transmitthe received information to the OSGi framework after nishing theabove-mentioned operation. The OSGi framework regards thisinformation as permanent properties data (key/value pairs) storedin the OSGi environment and OSGi bundles can retrieve theseproperties through preference service to implement advancedapplications, such as network manager, navigation bundle, and so

Fig. 13. OSGi framework run

Fig. 14. Cross-communication operation.on. In the same way, when OSGi bundles become ACITVE, theycan also transmit explicit or implicit intents to launch useful Activ-ities. Based on the strength of this two-way communication mech-anism, the proposed design allows Android applications to easilyconnect with the OSGi framework and bundles.

3.4. Embedding OSGi framework to Android application

in Android runtime layer.

unications 34 (2011) 169183 177In traditional devices, the Android/OSGi platform utilizes theOSGi services and service registry as an extensibility mechanism.This mechanism allows any application to run completely on topof the OSGi framework, but this is not always possible. In otherwords, system components must follow the OSGi standard to beimplemented, which will result in increasing the developmenttimes and costs. Besides, the system components spend extra-timeto communicate with OSGi framework in runtime layer. Therefore,if any Android application wants to use either the OSGi services orthe APIs provided by bundles, it needs a complicated Android/OSGicommunication mechanism. We created an embedded mechanismthat allows the OSGi framework to tightly embed into Androidapplications in the application layer, as Fig. 17 shows. In thisway, any Android application can host the instance of OSGi frame-work by utilizing reection approach, and application canexternally load the services which OSGi bundles provided. Never-theless, the extender mechanism has some drawbacks in that itlack dynamic changes in OSGi bundles/services and cannot cong-ure OSGi instances. Therefore, this study combines two mecha-nisms with the Android platform to create a more integratedAndroid/OSGi environment.

The Felix framework instance does not utilize ServiceReferencearray object to get referenced services, but on the contrary, it usesthe Service Tracker interface to monitor services. As a result ofutilizing traditional service-oriented mechanism, the producerbundles should use the BundleContext object to register servicesin the service registry. If referenced services have been changed,the ServiceChanged event must be implemented to ensure thatno exceptions have been generated. As a result, this mechanismis more cumbersome then the service tracker mechanism. For

mm178 M.-C. Chen et al. / Computer Coexample, Fig. 18 shows, if referenced services have been modied,the server bundle automatically callback the modiedServicemethod to rebind these services without implementing the Ser-viceChanged event handler. The service tracker also can take

Fig. 15. Inter-architectur

Fig. 16. Two-way communication mechunications 34 (2011) 169183advantages of a whiteboard pattern, allowing embedded OSGiframework to utilize a server bundle to monitor listener serviceschanges. The embedded OSGi Activity has the responsibility oftracking UI services, and if these UI services exist, the embedded

e of the Felixservice.

anism between OSGi and Android.

allowsanycomponentwith self-managing capability topublish/dis-cover services using iPOJO handlers, but also reduces system com-plexity. Besides, an Android/OSGi application can dynamicallyreact to the changing availability of services in capricious environ-ments. The iPOJO framework extends the declarative service con-cepts dened in OSGi R4 version, which also makes allows servicesto be dened in iPOJO metadata. Then, if the provision componentbecomes valid, it will spontaneously inject services to on-demandcomponents from metadata in runtime without any interruptionsfrom the OSGi framework. In the same way, if the provision compo-nent becomes invalid, the on-demand components will unbind thereferenced services to ensure system reliability. However, the iPOJOframework has two limitations in Dalvik VM that prevent it fromsupport dynamic generated classes and composite services. Fig. 19illustrates the SendRoadImage component, which allows road-sidecenter to monitor the road conditions of remote vehicle. It uses

M.-C. Chen et al. / Computer Communications 34 (2011) 169183 179Fig. 17. Tightly integrated Android/OSGi environment.OSGi Activity utilizes a child thread to call the setContentViewmethod to update the foreground screen for the user.

3.5. Self-managing middleware for the Android platform

We ported the iPOJO service-oriented framework into the re-source directory of the Android/OSGi application using the Filein-stall Activator, which has the main goal of making Android/OSGiapplications more adaptive and exible. This approach not only

assign the location of remote provision server. When this agent

Fig. 18. Service tracker of embedded OSGi activity.

S1

S2

S1S3

iPOJO Components

OSGi(Felix)/iPOJO framework

Android Application

MMS Service

CameraService

SendRoadImageService

Service Component Binding

DynamicSer

Fig. 19. The iPOJO component inhas been started, it installs and starts remotely downloaded appli-cations, and also manages their packages and resources.

4.1. Vehicular Android/OSGi platform

The Android/OSGi bundles which mainly contain standardizedBundleActivator interface and BundleContext object that make

private MmsSender sender;private Camera[] cameras;public void send() {

MMS mms = new MMS();synchronized (cameras) {

for (int i = 0; i < cameras.length; i++) {mms.add(cameras[i].getImage());}

}sender.send("Road_Condition", mms);

}}

SendRoadImage By MMS implementation

ally Injection vicestwo services: the rst required service is MmsService, which allowsa client to send anMMSmessage, and the second service is Camera,which allows a client to take a monitor image using camera hard-ware in theAndroidplatform.When theSendRoadImagecomponentbecomes available, it can easily use the above-mentioned servicesthrough dened iPOJO metadata. Therefore, developers only needto be concerned with the logic design of this component.

4. System design and implementation of Android/OSGi platform

Testing the proposed telematics applications in real vehicles isinconvenient and expensive. Consequently as Fig. 20 illustrates, avehicular testbed was built to test and verify the functionalitiesand security of the proposed Android/OSGi applications. This studyregards sensor-based LEGO robots as simulated vehicles, andmakes the vehicular Android/OSGi platform act as an on-board ter-minal for simulated vehicles. Instead of utilizing car buses, this on-board terminal mainly controls simulated vehicles using Bluetooth,like IBM iDrive systems. Communications between different vehi-cles is conducted via Wi-Fi. Finally, this study designs a provision-ing server responsible for storing telematics applications anddeploying an admin bundle called the management agent, whichiPOJO Metadata for SendRoadImage

Android application layer.

OSGi framework can manage their life cycle and service registra-tion or publishing. They also include required Android libraries

droid/OSGi platform can only update its foreground screen aftercalling setContentView method, Android/OSGi application must

Fig. 20. Vehicular testbed.

180 M.-C. Chen et al. / Computer Communications 34 (2011) 169183into their descriptive Manifest les, so that OSGi framework can re-solve these special packages. Fig. 21 illustrates inter-architecture ofVehicular embedded Android/OSGi platform, in rst, because An-Fig. 21. Inter-architecture ofto provide ViewFactory objects make other Android/OSGi bundlesbeing able to provide or update their Android GUI interfaces intomain Activity such as ImageView, MapView, VideoView, and soAndroid/OSGi platform.

on. Additionally, the Android/OSGi application should register itsActivity instance service, so that host bundle can fetch this mainActivity, and push registered GUI interfaces into it. The host bundleimplements a ViewFactory interface with the primary responsibil-ity of providing DesktopApplication service to other consumerbundles. The second service of DesktopApplication acts as a con-tainer for any Android View in the bundles. Consequently, if anybundles want to provide some Views for the main Activity, theymust implement the DesktopApplication interface, and registertheir DesktopApplication services with the OSGi service registry.Besides, the host bundle implements ServiceTrackerCustomizerinterface, which makes host bundle being able to track primaryActivity service and other DesktopApplication services simulta-neously in customized way. Supposing quantity of DesktopAppli-cation service greater than zero in OSGi registry, host bundle cancall getViewmethod belong to DesktopApplication interface to ob-tain container instances of Android View which GUI-based bundlesprovided. Finally, host bundle will add one of instances into main

tional memory size of OSGi framework. In tested Android hard-

ing application, however in pure Android platform same applica-tion only needs to spend about 1.21 MB memory size. In otherword, if this study compares pure Android/OSGi bundles with An-droid applications, as Fig. 22 table shows, Android applicationshould spend extra 0.96 MB size, but comprehensive look at totalplatform, Android/OSGi platform spends extra 0.95 MB memorysize. However, if existence of enormous applications, Android/OSGiplatform can substantially lighten its system resources based onOSGi mechanism.

Fig. 23 illustrates Android/OSGi platform spends approximately2 MB memory size to launch OSGi framework, and when OSGiframework had been started, Android/OSGi platform can consumeless memory size to start other applications. Total occupiedmemory size of probably lies in between 2 MB and 3 MB inAndroid/OSGi platform, however, pure Android platform hasincreased memory size, and grows up 5 MB. Consequently, pro-posed Android/OSGi platform can spend less memory size thanpure Android platform when OSGi framework had been started.

4.2.2. Telematics servicesThis study presents various telematics services to establish

intelligent vehicles in mobile environment, as Fig. 24 shows, whichmainly consist of line follow, object detection, keep distance, andso on. The rst part of service helps vehicles follows guidelinesto ensure driver security and reduce route-nding complexity tolighten the use of power. The second part of this service provides

M.-C. Chen et al. / Computer Communications 34 (2011) 169183 181ware, it has total 990440 KB memory size, and Android/OSGiplatform need to spend about 1.91 MB memory size for initiatingand starting OSGi framework, and 0.25 MB memory size for start-LinearLayout object, and return it to Android/OSGi Activity. Inthe proposed mechanism, only one bundle can provide GUI ser-vices to the main Android/OSGi Activity, based on user interaction.

4.2. Android/OSGi bundles

4.2.1. GUI-based bundlesThe original Android platform allows developers to create map-

based Activities using Google Map as a user interface element. Wehave full permissions to access the map, include change the zoomlevel, move the centered location, use overlays, provide map-con-textualized information and functionality, and so on. But if serviceproviders want to design navigation applications based on map-based Activities, they must to create many heavyweight servicesto perform time-consuming operations. Besides, Android platformlack of class-sharing among different applications and islands ofno-interoperable processes, which often limit usage of system re-sources and remain non-responsive. Fig. 22 illustrates vehicularAndroid/OSGi platform has feature of lightweight bundles suchas navigation bundle, which bundle size is less 11 KB than originalAndroid application. But vehicular Android/OSGi platform must tospend about 7.5 s to start OSGi framework in rst time, and addi-Fig. 22. Lightweight navigation applicFig. 23. Used memory analysis.ation for Android/OSGi platform.

vehicles with visual intelligence to identify objects like trafcsignals. The third part of the service helps vehicles maintain a setdistance from vehicles in front of back. The last component of thisservice allows road-side centers to survey the condition of vehicles.If some of services access the signicant components of vehicle, thevehicular Android/OSGi platform can enforce security policies toavoid accidents using a AOP-based OSGi weaving mechanism. Forexample if one service makes the vehicle travel faster than

agement, and remote deployment console. The rst part of thetelnet console allows a remote manager to diagnose and manageAndroid/OSGi applications though a telnet interface, which ex-tends the telnet bundle provided by the Oscar R3 implementation.The original Android platform cannot utilize telnet services to diag-nose or manage its applications or system conguration. The sec-ond part of the web console allows remote managers to diagnoseand manage Android/OSGi applications based on web techniques.

Fig. 24. Android/OSGi applications.

182 M.-C. Chen et al. / Computer Communications 34 (2011) 16918370 km/h, this service will be rejected.

4.2.3. Remote managementFig. 25 illustrates vehicular Android/OSGi platform mainly pro-

vide three management consoles, which include telnet, web man-Fig. 25. Remote management of veThis web management console relies on underlying OSGi bundles,including http service, declarative service, log service, congadmin,deployadmin, metadata, and so on. Although the original Androidplatform has http service that allows users to surf the internet de-pend on a WebKit browser, it does not have a web server, whichhicular Android/OSGi platform.

allows remote users to log into or our out the platform. The rest ofthe remote deployment console enables applications to be de-ployed on a remote vehicular Android/OSGi platform. This is simi-lar to the Android market deployment mechanism, but has somedifferences. For example, the Android/OSGi platform uses a man-agement agent to request deployment packages from a provision-ing server, while a pure Android platform uses a web server todirectly download Android applications from the Android Market.This management agent communicates with remote cloud calledAmazon EC2 through Restful API. Android/OSGi bundles are storedin Amazon S3, and Android/OSGi platform uses management agentto automatically install/update bundles with remote cloud same asactive sync. way. Consequently, the Android/OSGi platform candynamically recongure its application services by communicatingwith a provisioning server in runtime based on context-awareness.

out user intervention. This study also establishes a vehiculartestbed to verify and analyze the functionalities of the Android/OSGi and original Android platform. Finally, this study proves that

References

[1] Android Platform Ofcial Site, .[2] Open Mobile Alliance Ofcial Site, .[3] Google Android software stack in brief, .[4] OSGi Alliance, OSGi service platform, core specication release 4. Draft, July

2005.[5] GST Global System for Telematics Ofcial Site, .[6] 3GT Project Website, .[7] European ITEA Project Website, .[8] Stadtinfokoeln Project Website, .[9] Eureka-project TOP-IQ Website, .[10] About the OSGi Service Platform, OSGi Technical Whitepaper 4.1, June 2007.[11] C. Lee, D. Nordstedt, S. Helal, Enabling smart spaces with OSGi, IEEE Pervasive

M.-C. Chen et al. / Computer Communications 34 (2011) 169183 183the proposed Android/OSGi platform has lighter applications andhigher performance than a pure Android platform when perform-ing complicated operations. This study will continue to correct sys-tem lack like combine other technology and architecture to achievethe best performance.Besides, the Android/OSGi platform supports partial renewal ofapplications, reducing system delay time and enhancing systemperformance. The Android Market should also take advantage ofOSGi remote deployment mechanism using the above-mentionedadvantages.

5. Conclusion

This paper introduces the principles of an embedded OSGiframework in a Google Android platform. The proposed vehicularAndroid/OSGi platform provides various unique features:

Rich class-sharing Loose-coupled and lightweight services Easy API management Automatic service change response Remote device management Dynamic application update services

Using the proposed vehicular Android/OSGi platform, road-sidecenters can diagnose or manage the system status of vehicularplatform remotely, and use visual intelligence to continually up-date their application services based on context-awareness with-Computing 2 (3) (2003) 8994.[12] K. Myoung, J. Heo, W.H. Kwon, D.S. Kim, Design and implementation of home

network control protocol on OSGi for home automation, in: Proceedings of theIEEE International Conference on Advanced Communication Technology, vol.2, July 2005, pp. 11631168.

[13] N. Gun, A. Held, J. Kaiser, Proactive services in a distributed trafc telematicsapplication, in: Proceedings of the International Workshop on MobileCommunication Over Wireless LAN: Research and Applications, September2001.

[14] Y. Li, F. Wang, F. He, Z. Li, OSGi-based service gateway architecture forintelligent automobiles, in: Proceedings of the IEEE International Conferenceon Vehicles, June 2005, pp. 861865.

[15] D. Zhang, H.W. Xiao, K. Hackbarth, OSGi based service infrastructure forcontext aware automotive telematics, in: Proceedings of the IEEE InternationalConference on Vehicular Technology, vol. 5, May 2004, pp. 29572961.

[16] Y. Zhou, X. Wang, M. Zhou, The research and realization for passenger car CANbus, in: Proceedings of the IEEE International Forum on Strategic Technology,October 2006, pp. 244247.

[17] E. Weiss, G. Gehlen, S. Lukas, C. Rokitansky, MYCAREVENT vehicularcommunication gateway for car maintenance and remote diagnosis, in:Proceedings of the IEEE International Conference on Computers andCommunications, June 2006, pp. 318323.

[18] R.C. Hsu, L.R. Chen, integrated embedded system architecture for in-vehicletelematics and infotainment system, in: Proceedings of the IEEE InternationalSymposium on Industrial Electronics, vol. 4, June 2005, pp. 14091414.

[19] S.V. Alberto, M.D. Natale, Embedded system design for automotiveapplications, in: Proceedings of IEEE Computer Society on ComputerEngineering, vol. 40, October 2007, pp. 4251.

[20] Y. Ai, Y. Sun, W. Huang, X. Qiao, OSGi based integrated service platform forautomotive telematics, in: Proceedings of the IEEE International Conference onVehicular Electronic and Safety, December 2007, pp. 16.

[21] Y. Sun, W.L. Huang, S.M. Tang, X. Qiao, F.Y. Wang, Design of an OSEK/VDX andOSGi-based embedded software platform for vehicular applications, in:Proceedings of the IEEE International Conference on Vehicular Electronic andSafety, December 2007, pp. 16.

[22] P.H. Phung, D. Sands, Security policy enforcement in the OSGi framework usingaspect-oriented programming, in: Proceedings of the IEEE InternationalConference on Computer Software and Applications, August 2008, pp. 10761082.

[23] R. Hyun, C. Sung, P. Shiquan, K. Sung, The design of remote vehiclemanagement system based on OMA DM protocol and AUTOSAR S/Warchitecture, in: Proceedings of the IEEE International Conference onAdvanced Language Processing and Web Information Technology, July 2008,pp. 393397.

Android/OSGi-based vehicular network management systemIntroductionRelated worksAndroid platformAndroid software stackAndroid platform features

Open services gateway initiative (OSGi) service platformOSGi-based telematics gatewaySafe deployment of OSGi bundles

Comparison of OSGi and Android

Open embedded Android/OSGi platform for telematicsLocation of OSGi framework in the Android platformAndroid/OSGi conversion mechanismDevelopment of Android/OSGi applicationEmbedding OSGi framework to Android applicationSelf-managing middleware for the Android platform

System design and implementation of Android/OSGi platformVehicular Android/OSGi platformAndroid/OSGi bundlesGUI-based bundlesTelematics servicesRemote management

ConclusionReferences