Model-based Management of Embedded Service Systems – An AppliedApproach

Stefan Illner, Heiko Krumm,Ingo Luck, Andre Pohl

University of Dortmund, Germany{illner, krumm, pohl}@ls4.cs.uni-dortmund.de

ingo.lueck@materna.de

Andreas Bobek, Hendrik Bohn,Frank Golatowski

University of Rostock, Germany{andreas.bobek, hendrik.bohn,

frank.golatowski}@uni-rostock.de

Id: aina-uro-udo-complete.tex 126 2006-04-25 10:03:17Z pohl

Abstract

The automatic integration of devices into dynamic, auto-matically configured networks alone does not take advan-tage of the entire potential of Service Oriented Architec-tures (SOA). Using service management, independent ser-vices can be directed to perform meta tasks in a SOA net-work.In this paper we describe and evaluate the service manage-ment toolMOBASEC, which consists of two parts: at sys-tem runtime, management services are running in order toenforce management policies. The second part of the tool isa graphical model editor which supports the user in settingup the desired management policies easily.This research is part of the European SIRENA (ServiceInfrastructure for Real-time Embedded Networked Applica-tions). The use ofMOBASEC was evaluated by the projectin automotive application and the results are summarizedhere.

1 Introduction

TheService Oriented Architecture (SOA)approach pro-vides a standardized view to software components in a net-work. These components – calledServices– are describedin a standardized format (Service Description) which isused to integrate, announce, discover and use the func-tionality they offer. Furthermore services can subscribe toevents generated by other services to get informed aboutstate changes. The implementation of the services is hiddenfrom the service users, which only make use of the providedfunctionality using a well defined interface.

This research is part of theSIRENAproject [1]. SIRENAwas aimed at heterogeneous embedded devices interact-ing inside and between four different domains (automotive,telecommunication, industrial and home automation). Sev-

eral SOAs were evaluated such asUniversal Plug and Play(UPnP), Web servicesor theOpen Services Gateway Initia-tive (OSGi)for example. Due to interoperability and plat-form independence it was decided to use UPnP and theDe-vices Profile for Web Services (DPWS).

UPnP is a simple, easy-to-use SOA for small net-works [2]. It supports ad-hoc networking of devices andinteraction of services by defining their announcement,discovery and usage. The UPnP specification defines aprogamming language and platform independent technol-ogy as only protocols and interfaces are specified. It dividesthe device life cycle into six phases:Addressing, Discoveryand Description specify automatic integration of devicesand services,Control, Eventingand Presentationspecifyhow to use them.

The Devices Profile for Web Services(DPWS) [3], an-nounced in August 2004 and revised in May 2005, is a pro-file identifying a core set of Web services that enables dy-namic discovery of, and eventint capabilities for Web ser-vices. It arranges several Web service specifications suchasWS-Addressing, WS-Discovery, WS-MetadataExchange,and WS-Eventingfor devices, particularly. In contrast toUPnP, it supports discovery and interoperability of Web ser-vices beyond local networks. Temporarily DPWS was con-sidered the successor of UPnP and thus subtitled with ”AProposal for UPnP 2.0 Device Architecture” in one of itsearlier versions. However, DPWS is not compatible withUPnP.

The meaningful combination of heterogeneous services– so calledService Orchestration– can be used to fulfillmeta tasks which stand-alone services could not achieve.In the SIRENA project we dealt with the management ofdistributed and loosely coupled service systems running onembedded, networked devices. The mobile nature of thesedevices lead to new management issues and the dynamicconfiguration management adapting to changing environ-mental conditions became one of our major goals. Withrespect to the limited computing capabilities of embedded

1

devices, we developed a two-phase management approachwhich splits up the management task into a design-timeand a runtime phase. At design-time we adhere to theconcepts of the model-based management approach to cre-ate the management policies whilst at runtime a small andlightweight set of management services is used to enforcethe created management policies.

The remainder of this paper is organized as follows. Sec-tion 2 gives an overview of the demonstrator which showsthe feasibility of the presented approach. Section 3 de-scribes the components of the demonstrator and their func-tionality in detail. The evaluation results are presented insection 4, followed by a look on related work in section 5.Finally a conclusion is drawn in section 6 including an out-look to future research.

2 Architecture of the demonstrator

The presented demonstrator is part of the automotivedemonstrator of the SIRENA project showing new appli-cations of a SOA in a car. The architecture of the presentedapplication is shown in figure 1. Its purpose is to turn offan airbag whenever a child safety seat is placed on the frontseat to increase the safety of the child in the case of an ac-cident. A UPnP network (on top of LAN and WLAN re-

Figure 1. Architecture of the demonstrator

spectively) is used to connect all devices except the childsafety seat which is connected via Bluetooth. The airbag isrepresented by anAirbag Deviceand aBluetooth ID Scan-ner is searching for Bluetooth IDs of children safety seats.Both devices are independent from each other and only of-fer their own services but do not interact with each other. Athird device MOBASEC-S Deviceembeds aManagementService. It is configured in such a way that it browses the

network to find Bluetooth ID scanners and airbag devices.If a Bluetooth ID scanner is found the MOBASEC-S devicesubscribes to the scanner using UPnP Eventing. Thereby itgets informed about all Bluetooth IDs found by the scanner.Whenever a Bluetooth ID is identified as a child safety seatthe airbag device is switched off using UPnP Control.

All components are described below in more detail.

3 Components

3.1 Bluetooth ID Scanner

When talking about loosely coupled devices and control-ling them, future visions mostly end up in manual handlingthe devices, e.g. by remote controllers or by desktop-basedapplications. But there are a lot of scenarios requiring au-tomatic invocation of services. As an example: Consider-ing an air conditioner which should be regulated accordingto current temperature and time. A scheduler might be setup which defines different temperatures for different condi-tions. Manual regulations are not sufficient. We used theMOBASEC tool to model such situations. Conditions mayconsist of state information of other devices, localization,resource, and time information, or more generally spokenof context information. To solve the localization (identifica-tion) problem in our scenario, we used a Bluetooth-enabledscanning device.

Bluetooth[4] is a well-known wireless technology, actu-ally established as a cable-replacement for home and officecomputational devices and applications, mainly. Its short-range radio is operating in the ISM-band at 2.4 GHz. TheBluetooth specification also defines theHost Controller In-terface (HCI)that acts as a uniform interface to the Blue-tooth firmware. Via HCI, it is possible to search for otherBluetooth devices and services. Each Bluetooth device isequipped with a world-wide unique device ID consisting ofa six byte number similar to MAC addresses of network in-terface cards. Device IDs along with the inquiry processmake identification of devices possible. For our purpose wedeveloped a scanning device which inquires other Bluetoothdevices permanently. Since inquiry responses are only sentby devices in range, we are able discover devices near to thescanning device.

For our implementation we chose theFOX boardavail-able at [5]. FOX is a very small (66 x 72 mm, or2.6 x 2.8 inches) hardware platform and can be used as anembedded system. It is equipped with a 100 MHz RISCCPU, one Ethernet and two USB ports and runs a specialLinux distribution including services like a web, FTP orTELNET server. To enhance the system with UPnP andBluetooth capabilities we connected the board with a Blue-tooth USB dongle and an Ethernet cable.

2

The Bluetooth software component was implemented ontop ofBlueZ[6]. The C-based BlueZ API is a complete im-plementation of the Bluetooth stack for Linux systems. In-quiry commands are sent periodically and responses are col-lected. We wrapped the Bluetooth application as an UPnPservice. For that purpose, an UPnP device was generatedusing the Intel UPnP stack [7].

3.2 Management

The two major parts of our two-phase managementframework will be outlined in more detail in the followingsections.

3.2.1 Model-based Management & MOBASEC

The model-based management approach uses an object-oriented model of the managed system to ease the creationand modeling of complex management policies. The graph-based modeling of such a system is supported by a graph-ical modeling tool. Common policy-based managementapproaches [8] apply low level policies to describe man-agement demands. Systems applying the model-based ap-proach [9] use abstract high-level policies from which con-crete service configurations are automatically created.

The refinement process for policies uses the concept of apolicy hierarchy[10] which divides the model into differentlayers of abstraction (cf. figure 2). On the topmost layerthe model contains a very abstract description of the man-agement objectives. On the way down to the bottom layerthe model gets more and more concrete by (semi-)automaticand manual refinement of the model elements. The bottomlayer finally contains a low-level policy model which, forexample, can be transformed to XML-coded service config-uration descriptions. The modeling of policies is supportedby our MOBASEC modeling tool.

Figure 2. Model diversion overview

Besides the horizontal diversion into different abstrac-tion layers, the model can be moreover split into four verti-cal parts (cf. figure 2):

System The system model contains all the real-world en-tities of the system to be managed. These include thedevices and network connections or services with theiractions and attributes, for example.

Control Services This part of the model contains a collec-tion of services which are responsible for the runtimemanagement of the modeled system. This includes theservices for service monitoring, configuration and se-curity management.

Management Policy The policy part of the model containsthe description of the management actions to be ap-plied to the system. For example, this part containsthe structures for setting service attributes to specificvalues or calling a service’s action with a particularparameter list.

Environment The environment section of the model con-tains the definition of the important environmental sit-uations the system may be exposed to. These situationsare directly related to particular parts of the manage-ment policy section.

For the modeling of the environment we adopted the no-tion of Environment Rolesfrom theGeneralized Role BasedAccess Control (GRBAC)[11] approach. GRBAC is an ex-tension to the well knownRole Based Access Control[12]model. Naturally being used for the creation of environmentaware access control policies, we use environment roles asabstract representatives for environments on the topmostlayer of our common management model. On the lower lev-els these roles are replaced by so calledenvironment condi-tionswhich are logical expressions overenvironment condi-tion elements. The elements can be used to interpret avail-able sensor or service monitoring data. This concept en-ables us to model arbitrary environmental conditions basedon the evaluation of simple data structures.

The information about which types of elements are avail-able for modeling and how these can be connected to eachother is encoded in the so calledmeta-model. The meta-model contains domain specific graph-node implementa-tions, normally in form of Java classes. Each of theseclasses subsumes the associated behavior and properties ofthe real-world or policy entity represented by a model node.Moreover the meta-model contains the functions to createlow-level configurations for the services that are responsi-ble for the runtime enforcement of the modeled policies.

The models are created using our MOBASEC modelingtool for ”Model-BasedService Configuration”. The tool

3

itself provides a modeling platform which includes a graph-ical user interface, graph-modeling and -transformation ca-pabilities and filtering functions. Moreover it is possible todefine different views on a model to enable a differentiatedview on even very complex models. All other informationregarding the modeling process is provided by domain spe-cific meta-models.

Figure 3. MOBASEC screen-shot

The graph transformation algorithms [14] that are partof the MOBASEC platform are used for automated modelrefinement. The idea of this is as follows: as stated above,the model is described by a graph. Therefore it is possi-ble to define a graph transformation system consisting ofsingle transformation rules which alter the graph in a spec-ified way. One such rule consists of a pre-patternL and apost-patternR, and on detection of aL in the model, thisoccurrence is replaced with an instance ofR, after ensuringthat this step will not violate any connectivity restrictions ofthe affected nodes.L andR are graphs also, consisting ofelements of the same meta-model as the model graph does.The rule elements can be specified using the tool in the sameway the model is specified. Some nodes inL are identifiedwith nodes inR, while others are not. The same appliesto the edges inL andR. The algorithm to apply a rulerto a model graphM is roughly outlined by the followingsequence:

1. Find an occurrence ofL in M

2. Remove all components inM which occur inL, butdo not have an identity component inR

3. Insert all components intoM which occur inR, butdo not have an identity component inL

The application of a ruler transforms the graphG to aGraphG′, denoted byG ⇒ G′. This is called a directderivation, andG′ is directly derived fromG. For a bet-ter control over the application of a rule, every rule is aug-mented with two additional components. Acondition al-lows to specify certain constraints which must be met by thedetected subgraphL′ in order to match the defined patternin the search. These constraints can refer to all attribute val-ues of elements inL′. An effect functionis a function whichis applied to the inserted graph elements, and describes howthe attribute values of the inserted elements are computedfrom the attributes of the elements ofG.

The model created for the demonstrator to provide the(de)-activation of the airbag in the car based on the pres-ence of the child safety seat is depicted in figure 4. On theleft hand side of the model you can see the modeledAirbagServiceand theBlueScan Servicefor scanning BluetoothIDs. The Airbag service offers an action calledSetEnabled,with the boolean parameterMode. The BlueScan servicehas only one single service attribute calledDiscoveredIDswhich contains the IDs of the currently present Bluetoothdevices. This attribute can be accessed via an eventingmechanism. The services are hosted by theAirbag and re-spectively theBluescandevice. Right next to the services,five management services are modeled, running on the de-vice calledAWebS. All devices are connected by aNetworkLink which has to provide IP connectivity to enable the ser-vices to communicate.

In the policy section of the model, the management goalsand their resulting tasks are modeled. On the topmost layera management goal namedAirbag-Child Safety Seat Con-trol is modeled. This abstract goal is refined to the manage-ment tasks modeled on the middle layer. The lower taskenables the airbag by calling theSetEnabledaction withthe value forModeset totrue, while the other task disablesthe airbag by settingModeto false. Management tasks aregrouped together using so calledfolder nodes, which can beopened or collapsed to improve the readability of a model.On the right hand side of the model you can see the environ-ments for our demonstrator scenario. On the upper layer theenvironments are represented by very abstract environmentroles calledChild Seat insertedand Child Seat removed.These roles are refined to appropriate environment condi-tions which define what sensor data should be used to de-termine a special environment and how this data should beinterpreted. TheSeat removedenvironment condition con-tains the definition for the situation when the child safetyseat is not present. This environment is active, wheneverthe DiscoveredIDsattribute of theBlueScanservice doesnot contain the Bluetooth ID of the child safety seat. Themanagement tasks are connected to the appropriate envi-

4

ronment condition elements.

Figure 4. Airbag control model

From models like the one depicted in figure 4 the low-level XML policy descriptions can be created. For thesedescriptions we developed an XML Schema document thatdefines the structure and elements of the configuration de-scription. The configuration description is action centric,that means all management tasks are encoded as actions ofservices and whenever a configuration change has to takeplace, this change is defined as an action call on the affectedtarget service. This very flexible concept allows us to definethe configuration of the management services and managedservices the same way.

A short example of the XML structure is outlined below:

<config version="v1" ...><serviceConfigurations>

<service type="ServiceType" ...><action name="ActionName" ...>

<parameter name="ParameterName" ...><value>...</value></parameter>...

</service>...

</serviceConfigurations></config>

3.2.2 Policy Enforcement

So far we have outlined the modeling of management poli-cies by means of graphical modeling and model refinementusing the MOBASEC tool. The automated creation of thelow level policies concludes the design phase of the man-agement process. At runtime, a set of dedicated servicesis used to enforce the given policies and to enable the adap-tive runtime management of the system. The provided infra-structure consists of five different services, each responsiblefor a special subtask of our runtime enforcement process.TheDeployment Serviceis responsible for the initialization

of the service infrastructure. TheMonitoring Servicesub-sumes all functionality for the runtime monitoring of ser-vices by using polling or eventing mechanisms. The activa-tion state of the environment elements is managed by theEnvironment Element Activation Service. The AutomaticAdaptation/Dynamic Reconfiguration Service (AADR)de-tects the environmental situation a system is exposed to, andfinally the Service Control Management Serviceactivatesthe appropriate configuration for a particular environment.The service infrastructure is also depicted in figure 5.

Figure 5. Runtime service infrastructure

The low-level configuration derived from the model canbe directly deployed onto an existing management serviceinfrastructure from within the MOBASEC tool. As soon asa new configuration arrives, the Deployment Service splitsup the configuration data and forwards the appropriate con-figuration parts to the other management services. Afterthe initialization phase the services are ready to enforcethe given management policy. This process is as follows:the Monitoring Service gathers information about the cur-rent system environment by listening for incoming eventsor polling appropriate service actions. As soon as a changein the environment is detected, the name of the sensor el-ement and the current value are forwarded to the Environ-ment Element Activation Service. This service reevaluatesthe state of all environment condition elements that dependon the given sensor element. If this evaluation leads to achange in the set of active elements, this set is sent to theAADR. This service now starts an evaluation of the config-ured environment conditions which are encoded by meansof logical formulas. If an environment condition is foundto be active, and it was not active before, the AADR re-solves the identifier of the associated configuration set and

5

sends a message containing this identifier to the ServiceControl Management Service. A single configuration setcontains all service configuration descriptions that are as-sociated with a particular environment condition. Finallythe Service Control Management Service loads the appro-priate configuration and performs the enclosed managementactions.

Service Implementation The service infrastructure intro-duced in the last paragraph was implemented using the Javaprogramming language. Before implementing the serviceswe developed an abstraction layer for service oriented archi-tectures that hides the specific low-level implementation ofUPnP or DPWS from the services implementations. Thusfor porting the services to the DPWS platform we only haveto implement a new communication module for the abstrac-tion layer, while the services above the abstraction layerremain unchanged. The footprint of our implementation’scompressed byte code is about 420kB with≈ 80kB for theservices implementations,≈ 35kB for the abstraction layer,and about 300kB for the UPnP libraries.

4 Evaluation

The application and management services described inthe last section where used to implement the automotive andcross-domain demonstrators from section 2. After the ini-tial deployment and startup of all involved components, themanagement services where initialized with the configura-tion created from the above-mentioned model of the demon-strator scenarios. This initialization phase started with theonline-deploymentof the actual configuration from withinthe MOBASEC tool. The initialization phase took about30 secs. from starting the deployment in MOBASEC untilthe service system was in an completely initialized state.

As the child safety seat was installed in the car, it wasrecognized and the management services enforced the mod-eled configuration change and thus set the airbags statevir-tually to off. After the seat had been removed, the airbagwas reactivated again. The management system’s responsetime was about 700 msecs. from monitoring a change of asensor state to the enforcement of the new configuration atthe airbag service.

The demonstrator showed that our management ap-proach was applicable for the management of (UPnP) ser-vice systems. The airbag and bluetooth scanner serviceswere combined together without having to implement anyadditional line of source code, just by creating a modelof the managed system and instrumenting the managementruntime service infrastructure. We also used our approachto create a personalisation service inside a car using the on-board AWebS box and a PDA.

5 Related Work

In [13] Lobo et al. describe a platform called ”PolicyManagement for Autonomic Computing” (PMAC). Basedon an extensive policy language, management policies canbe created using a so calledPolicy Definition Tool. During apolicy ratification process the available policies are checkedfor dominance or conflict issues. The policies are used byanAutonomic Managerfor the automated runtime manage-ment of managed resources. The main difference to the ap-proach presented in this paper is that PMAC indeed usesa policy definition tool to support the user in creating themanagement policies but does not apply the model-basedmanagement approach to create management models.

6 Conclusion & Outlook

The implementation of the demonstrators showed the ap-plicability of the management approach that was developedduring the SIRENA project. Therefore our future work willconcentrate on the improvement of the meta-model and re-finement rules to make the policy creation process muchmore friendly. This includes the evaluation of so calledManagement Patterns. These patterns can be seen as a tool-box of refinement patterns that are able to deal with man-agement issues that may arise in domains based on serviceoriented architectures. Moreover the implementation of asmall DPWS stack for Java and its integration into the ab-straction layer the management services are based on is an-other task we are currently working on. Finally we have toconduct more tests in complex service management scena-rios to confirm our initial results.

This work was supported by the SIRENA project in theframework of the European premier cooperative R&D pro-gram ”ITEA”.

References

[1] SIRENA (Service Infrastructure for Real-timeEmbedded Networked Applications), http://www.sirena-itea.org , 2004.

[2] UPnP Forum, UPnP Device Architecture v.1.0.1,http://www.upnp.org/resources/documents.asp ,2003.

[3] Microsoft, Devices Profile for Web Services,http://specs.xmlsoap.org/ws/2005/05/devprof/devicesprofile.pdf , 2005.

[4] The Bluetooth Special Interest Group, Specification of theBluetooth System 1.2, 2004.

[5] ACME Systems, FOX BOARD a complete Linux system ona small board,http://www.acmesystems.it/?id=4, 2005.

6

[6] BlueZ, Official Linux Bluetooth protocol stack,http://www.bluez.org/ , 2005.

[7] Intel, Intel Software for UPnP Technology,http://www.intel.com/cd/ids/developer/asmo-na/eng/downloads/upnp/index.htm ,2005.

[8] M. Sloman, Policy Driven Management for Distributed Sys-tems,Journal of Network and Systems Management, 2(4),1994.

[9] Ingo Luck, Sebastian Vogel and Heiko Krumm, Model-based configuration of VPNs,8th IEEE/IFIP Network Op-erations and Management Symposium (NOMS), Florence,Italy, 2002, 589–602.

[10] Rene Wies, Using a Classification of Management Policiesfor Policy Specification and Policy Transformation,Proc. ofthe IFIP/IEEE International Symposium on Integrated Net-work Management, Santa Barbara, California, USA, May1995.

[11] Matthew J. Moyer and Mustaque Ahamad, GeneralizedRole-Based Access Control,Proc. 21st Int. Conf. on Dis-tributed Computing Systems, Mesa, USA, 2001, 391–398.

[12] Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein andCharles E. Youman, Role-Based Access Control Models,IEEE Computer, 29(2), 1996, 38–47.

[13] Dakshi Agrawal, Kang-Won Lee, Jorge Lobo, Policy-BasedManagement of Networked Computing Systems,IEEECommunications Magazine, vol. 43, no. 10, October 2005.

[14] M. Andries et. al.,“Graph Transformation for Specificationand Programming”,Science of Computer Programming,Vol. 34, pp. 1–54, 1999.

7