Sensors as a Service Oriented Architecture: Middleware for Sensor Networks

Transcription

1 Sensors as a Service Oriented Architecture: Middleware for Sensor Networks John Ibbotson, Christopher Gibson, Joel Wright, Peter Waggett, IBM U.K Ltd, Petros Zerfos, IBM Research, Boleslaw K. Szyanski, Rensselaer Polytechnic Institute, David J. Thornley, Iperial College London {john_ibbotson, gibsoncr, joel.wright, peter_waggett }@uk.ib.co, pzerfos@us.ib.co, szyab@rpi.edu, djt@doc.ic.ac.uk Abstract: There is a significant challenge in designing, optiizing, deploying and anaging coplex sensor networks over heterogeneous counications infrastructures. The ITA Sensor Fabric addresses these challenges in the areas of sensor identification and discovery, sensor access and control, and sensor data consuability, by extending the essage bus odel coonly found in coercial IT infrastructures out to the edge of the network. In this paper we take the essage bus odel further into a seantically rich, odel-based design and analysis approach that considers the sensor network and its contained services as a Service Oriented Architecture. We present an application of a hierarchic schea for nested service definitions together with an initial ontology that describes the assets and services deployed in a sensor network infrastructure. Index Ters: Sensor networks, Ontology, Service coposition, Service odeling I. INTRODUCTION The diversity of sensors, actuators and networking technologies used in intelligent environents provides significant challenges in the areas of identification and discovery, access and control, data consuability and trusted policy-based interoperability. The ITA Sensor Fabric [,3], developed as part of the International Technology Alliance in Network and Inforation Science [2], has addressed these challenges to provide an extensible iddleware layer to interconnect sensors with users (huan or software agents) that need to consue the data generated by the. The Sensor Fabric (or Fabric) extends the essage bus architectural odel to the edge of the network. It spans between the reliable counications infrastructures found in data centers and the interittent connectivity of deployed sensors and obile personnel connected using ad hoc wireless network technology. The Fabric provides universal access to sensor data fro any point on the network. It axiizes the availability and utility of the data to users, whilst hiding the coplexity of the underlying network infrastructure. Research was sponsored by US Ary Research laboratory and the UK Ministry of Defence and was accoplished under Agreeent Nuber W9NF The views and conclusions contained in this docuent are those of the authors and should not be interpreted as representing the official policies, either expressed or iplied, of the US Ary Research Laboratory, the U.S. Governent, the UK Ministry of Defense, or the UK Governent. The US and UK Governents are authorized to reproduce and distribute reprints for Governent purposes notwithstanding any copyright notation hereon. The Fabric is an extensible iddleware platfor with each participating node interconnecting with neighbours to for a lightweight service bus. Its plug-in architecture allows new functions such as filters, transforations, policy enforceent, security, data fusion and event detection algoriths to be easily deployed within the network and selectively applied to sensor essages as they flow through the network. In addition to its use with deployed sensors, the Fabric is also used as a research and developent tool. New algoriths can be tested using the Fabric s record and playback, sensor siulation, and perforance easureent support. New sensors can trialed in an environent that bridges between siulation and fielded systes. Central to the functioning and anageent of the essage bus is a distributed Registry, an evolution of the Service Registry coonly used with a Service Oriented Architecture (SOA). Built using the ITA Gaian dynaic distributed federated database technology [4], the Fabric Registry is used to track all aspects of the essage bus operation including assets, users, topology, and plug-in functions. The Fabric Registry also tracks tasks being perfored using the Fabric. These are groupings of sensors and users that are assigned to soe activity, for exaple the users and assets associated with water level onitoring in a flood detection syste. Tasks ay be used to prioritise resources interconnected using the Fabric; for exaple, data fro one geographical area ay be given priority over another in the case of extree weather conditions leading to flooding. The Fabric does not establish task priorities itself; this is left to external applications that consue the data provided through the Fabric. The Fabric has been developed as a lightweight service bus for sensors, which is intended to augent existing Enterprise Service Bus technologies. Sensing environents provide different challenges to those in highly reliable business infrastructures and the Fabric has been designed with these in ind. However, there are advantages in thinking of the sensor assets and the plug-in algoriths deployed onto the bus as services in the context of a Service Oriented Architecture (SOA). This has previously been discussed in [5], but this paper focuses on extending the essage bus at the edge odel to a service bus at the

2 2 edge. We describe a seantically rich, odel-driven approach to a practical SOA for sensor networks. In the reainder of this paper, we first present a otivating use case for an SOA on a sensor network iddleware in section 2. In section 3 we describe an approach to odeling services on the sensor network using annotated UML Activity diagras, which is expanded to include service coposition in section 4. In section 5 we describe a draft ontology for odeling the assets and services contained within the network. Finally we end with soe conclusions and outline further work to develop an environent for describing, odeling, analysing and deploying services onto the sensor network SOA infrastructure. II. A MOTIVATING SCENARIO There is a trend in healthcare that encourages the long-ter treatent of patients in their own hoes for both clinical and econoic reasons, particularly for elderly patients who value their independence. Sensor technology can aid this by onitoring both the patient s vital signs (blood pressure, teperature, pulse rate etc.) and activities (oveents, utterances, noise) using obile sensors attached to the patient or fixed sensors located around the hoe. In addition, sensors can onitor a patient s living environent and daily activity patterns. For exaple, sart software agents ay use otion sensors within the hoe to learn about the patient s noral behavior patterns and detect any deviation fro that behavior; if there is no oveent within the hoe by 8:00a, then issue an alert. This could be augented by personal alar systes activated by the patient in case of distress. In the sae way that hoe autoation and personal coputers are linked by wireless technology, siilar networking techniques ay be used to create a hoe edical hub node (MediHub) that integrates hoe sensors for edical onitoring. These sensors ay counicate with the hub by different network protocols such as Zigbee [6] or Bluetooth [7]. Using a essage bus odel, such as that provide by the Fabric, this infrastructure can be connected with eergency services and other relevant patient support to provide effective patient care. We illustrate this with a use case within this scenario that shows the response to an eergency patient alert generated by the MediHub node within a patient s hoe. Note that the eergency response described in this use case is a specific task within the context of a longer running patient healthcare anageent process. In response to the detection of an eergency in the patient s hoe the MediHub node publishes an alert (), which is received by the abulance dispatch service (which will have subscribed to all alerts fro all MediHub nodes in its locality) and the local hospital (which will have subscribed to alerts fro all patients under its care). The alert triggers the dispatch of an abulance to the patient s address. Whilst the abulance is in transit, paraedics in the abulance and edical teas in the hospital s accident and eergency (A&E) departent autoatically receive the patient s sensor edical data (MedData). This allows the hospital tea to provide predictive diagnosis to the paraedics before their arrival at the patient s hoe. S Patient S4 S2 S3 Hoe:MediHub Patient s Hoe MedData Abulance to patient MedData AbData Abulance to Hospital NextOfKin Alert Hospital Abulance Dispatch Diagnosis A&E Intensive Care Fig : A Medical use case for the Sensor Fabric Fabric Bus Once the patient has been transferred to the abulance, the patient vital signs onitored within the abulance provide data feeds via the Abulance node AbData to the hospital that in turn can continue to provide diagnostic inforation. The patient onitoring data is also used to prepare other resources in the hospital, such as intensive care, for the reception of the patient. The edical data transferred via the sensor network essage bus will include other data such as GPS location fro the abulance so that the dispatcher and edical teas can onitor its progress en route to the hospital. Policy-driven transforations can transcode the data to different forats and resolutions that are appropriate for display and consuption by various devices (e.g. sart-phones, screens on board abulances, hospital edical record systes, etc.) with heterogeneous display and processing capabilities. In addition to the edical staff, ebers of the patient s faily (NextOfKin) can subscribe to events and inforation about the patient (such as the nae of the hospital to which the patient is taken) using, for exaple, a Sartphone application or a essage bus/sms bridge. Policies for access control and encryption within the essage bus ensure that privacy regulations are et as essages flow across the bus between the patient s MediHub, the abulance dispatch service, the hospital, the abulance and the patient s faily ebers. Such policies are applied at organizational, user role, and individual user identity levels. III. SERVICES ON THE SENSOR NETWORK Services on the sensor network do not follow the conventional view of a service requestor invoking a service provider that responds to the invocation. This request/response service odel is widely used in Web service-oriented SOA applications but is not appropriate for the strea-based services found in an event based essaging environent such as a sensor network. Whilst the Fabric does provide a essage bus that is coparable to

3 3 those used in ainstrea SOA architectures, interconnecting the sensor network s assets and users, the service coposition odel that is required to efficiently deliver coposite services built fro these individual functions is very different to the process choreography [8] that is coonly used. In constrained strea-oriented environents such as this it is necessary to revert to first principles and discuss how a user could describe a set of services that provides a particular processing function. For odeling services on the sensor network, we use the UML activity diagra as a starting point. Activities atch the seantics of sensors and services in the network, with the being synonyous with services having zero or ore inputs and zero or ore outputs. This is illustrated in Fig 2, which shows the UML odel of part of the sensor network deployed within a patient s hoe. MS MS2 PersonAlar PA AudioSensor AS MotionAlar MA AudioAlar AA Alar A variety of foral odels for verifying quantitative and qualitative properties of a odel. These opportunities include evaluation of the perforance characteristics of services deployed on a sensor network by translating the into, for exaple, Perforance Evaluation Process Algebra (PEPA) for integration into the MARS fraework that explains inforation quality and effectiveness and will serve to quantify the related edical deands on tie and resource consuption in a anner that supports decision aking [9]. Further annotations will allow transforation of the odel into other representations including transforation of the odel to generate a deployent descriptor describing the deployent of an ipleentation of the odel on the Fabric, or indeed code generation where the odel describes new or incoplete coponents. We expect transforations into foral odels to be used as part of an initial design process prior to deployent in the sensor network. fro the analysis of the foral odel ay then be used to enhance or odify the annotations on the design odel. The flexibility of seantically annotating the odel gives us a technique to easily integrate the results back into the original UML odel as feedback to the designer/developer. We describe this as round-tripping (Fig 3). Model and Tools Fig 2: Sensors and services generating an alar within a patient s hoe In this odel, there are 4 sensors deployed in the hoe to onitor the environent. Two otion sensors (MS and MS2), positioned so as to detect the patient s noral activities (such as getting up fro bed), feed a MotionAlar activity MA which generates an alar event if a variance fro noral activity is detected. The PersonAlar sensor PA is carried by the patient and activated in case of eergency. Finally, an audio sensor AS can trigger an alar via an AudioAlar activity AA. Any of these three alars can cause a alar to be published by the Alar activity A fro the patient s hoe onto the Fabric bus which will trigger a response by the hospital eergency services. The UML erge activity ay be ipleented either as a separate service or as a function of the input port to the Alar service. The exaple illustrates several coponents of the core odel: activities, inputs, outputs and connections. UML allows each of these design odel coponents to be annotated with additional inforation and we propose the exclusive use of seantic annotations to enrich the odel. The UML seantic annotations are ade according to a flexible, extensible ontology. This cobination (i.e. UML odel plus seantic annotation) provides a flexible basis for both transforation and analysis of the odel. Annotations ay reflect both abstract and concrete properties of the design required for transforation into a Transfored Models Abstract Concrete Model Transforations Process Algebra Other Foral Model Ipleentation Deployent UML Meta Model + Seantic Annotations Model Analysis Other Model Analysis Type Checking Run tie Metrics Model Round Tripping Annotation Iport Fig 3: Round-Tripping fro the Core Design Model Generated Annotations Seantic annotations can also be used to capture physical properties of a deployed sensor network. This supports the second, concrete, round-tripping route shown in Fig 3 between the design odel and the services deployed on an active sensor network. The Fabric provides instruentation on the sensor network essage bus allowing real-tie etrics to be gathered and a profile of the perforance of the deployed services to be generated. This profile can be used to provide further annotations within the design odel to allow subsequent refineents of the foral representation that will be ore suitable for the deployent environent. We expect the UML design odel to undergo ultiple round-trips between the foral and deployed states during its lifecycle.

4 4 IV. SERVICE COMPOSITION Services ay theselves be coposed of other services which results in a requireent for a hierarchic coposition schea that describes their interconnection. Hierarchic interconnection of coponents is a generic requireent in silicon CAD tools, which has led to a schea known as the five-box schea. A description of the schea can be found in the Silicon Integration Initiative physical design language specification [0]. The five-box schea relates the definition of a coponent and the ports (input and output interfaces) it exposes to instances of the coponent. The concept of a coponent in the silicon CAD doain relates exactly to a service in the sensor network doain. The schea, labeled to describe sensor network services, is shown in the following figure. AA and A and their associated ports will be included in the odel. Connections between the instantiated ports also for part of the odel. Type enforceent will ensure that the connection atches the types of the output and input ports it is interconnecting. Additional annotations on a connection (such as its latency or rate) are included as required by the target odel transforations (for exaple a PEPA transforation). MS MS2 PersonAlar PA MotionAlar MA MediAlar Med Alar A ServiceDefn Contains Contains Connects PortDefn AudioSensor AS AudioAlar AA Fig 5: Coposing Services DefinedBy Contains ServiceInst Connection Presents Connects Fig 4: The Five-Box Schea for Hierarchic Services PortInst DefinedBy In the schea, a service definition (ServiceDefn) contains ultiple port definitions (PortDefn), which ay be specialised as either an input or output. Service definitions ay also contain instances of services (ServiceInst) which creates the hierarchic service description. Service definitions also contain the connections (Connection) that interconnect the service port definitions. Services and ports can be instantiated (PortInst) and interconnected with the instances linked by the DefinedBy relationship to their definitions. We have used the five schea eleents, service and port definitions and instances together with connections, to provide the anchor points for seantic annotations supporting the UML activity odel for sensor network service designs. These classes ap directly to the activities, typed ports and connections of the UML as shown in Fig 2. Applying this schea to the exaple in Fig 2, the service is used twice as instances MS and MS2. Such a dual use of would be represented in the schea as a single instance of the ServiceDefn class for the and two instances of the ServiceInst class; one for MS and one for MS2. The port definition for the service will be annotated with the type of the essage generated by the service. Siilarly, service definitions will be provided for the PersonAlar, AudioSensor, MotionAlar, AudioAlar and Alar sensors. The instances of these services PA, AS, MA, Services ay for part of other services as illustrated in Fig 5. In this exaple, the MotionAlar, AudioAlar and Alar services together with the output of the PersonAlar have been identified as a useful, reusable service. The fivebox schea allows this collection of interconnected services to becoe a service definition (MediAlar), which can be added to a design tool s palette of available services for future use. The instantiation of this coposite service as Med in a design tool would allow users to expand the coposite service to inspect the atoic or other coposite services that ake up the MediAlar service description. The five-box schea supports the hierarchic definition of coposed services to any level but in practice, the depth of the hierarchy will be liited. In addition to the benefits of coposition in a service design environent, providing a rich annotation capability for the core odel creates further opportunities for autoating the coposition of services. This ay not necessarily involve the hierarchical coposition described earlier, but autoated coposition is iportant in environents that ust be adaptive and self-anaging; this is particularly true for the strea-based services in a sensor network. We have identified four possible scenarios where the autoated coposition of services is advantageous:. Inforation typing. Users ay require inforation of a type that is available fro a particular service output. Autoated coposition will allow the tree of services to be constructed to provide the correctly typed inforation for a user. 2. Service optiisation. When transforing the core odel into a deployent odel, there ay be ultiple copositions of services that eet the sae functional requireents. Round-tripping of the core odel through foral or deployed odels ay identify which

5 5 of the alternative copositions are optial (based on network resource utilization or soe other etric) for a given network configuration. 3. Functional redundancy and substitution. In sensor networks where there is an unreliable network and syste layer, services ay becoe inaccessible due to counication breakdown or energy depletion of sensor nodes. Functional resilience ay be achieved by re-coposing services within the reaining accessible network to provide the sae functionality. In case no exact equivalent functionality can be provided through re-coposition due to unavailability of appropriate service instances, a substitute service that ipleents only a subset of the required functions can be alternatively suggested. This assues a sensor network environent that is regularly onitored and in which services can be re-coposed and deployed autonoically. 4. Run-tie optiization. During a services execution the network conditions can drastically change, for exaple the deployent of new services on to a shared node could cause it to becoe overloaded. Hence, periodic load balancing and/or redistribution of long ter running services ay iprove their perforance. This is particularly iportant for coposite services which can allocate their coponent services to nodes in such a way as to balance both the counication and coputational load in the network. V. AN ONTOLOGY FOR SOA ON A SENSOR NETWORK Various ontologies and vocabularies have been proposed for sensor networks in the literature with SensorML [] and OntoSensor [2] being probably the best known. Others within the ITA research prograe have addressed seantic techniques in the allocation of resources in sensor networks [3, 4]. The ontology presented in this paper is not intended to replace those presented elsewhere. Instead, it is used to describe the core sensor network design odel, the hierarchic five-box schea for services and the artifacts represented in the existing Fabric registry relational database schea. Its purpose is to provide a flexible, extensible representation of the core odel and the annotations needed for transforation of the core odel for analysis, ipleentation, and deployent. Fig 6 shows the initial set of classes within the ontology. For clarity, the relationships between the classes are not shown. Each Owl file describes the classes within a different naespace. The SeanticFabric naespace acts as a top level entry point whose role is siply to iport other naespaces into the ontology. Instance ontologies such as one to describe the earlier edical exaple will then iport the SeanticFabric naespace to access definitions of the available classes. SeanticFabric.owl iports Actor.owl Node.owl Platfor.owl Sensor.owl Feed.owl Task.owl Plugin.owl Service.owl Actor Node Platfor Sensor Feed Task SiplePlugin Connection PortDefinition PortInstance ServiceDefinition ServiceInstance Fig 6: A draft ontology for sensor networks Annotation.owl AssetType.owl AssetAttribute.owl GeoSpatial.owl NodePlugin SystePlugin FabletPlugin CoplexPlugin InputPortDefinition OutputPortDefinition ActorPlugin TaskPlugin There are four ajor groups of classes in the ontology: Assets, Tasks, Plugins, and Services. Assets include Nodes, Platfors, Sensors and their data feeds (that generate the event streas subscribed to by sensor network users). The users are represented in the ontology as Actors and are either end (i.e. huan) users or software processes. Assets can have Types and Annotations associated with the in the for of their affiliation, the asset s readiness, their roles, security credentials and availability. Assets can also have geographical inforation associated with the via the GeoSpatial class which ay include inforation such as the asset s latitude, longitude and altitude. Mobile assets ay have inforation on their velocity and current bearing. A set of classes support the Fabric notion of Tasks. These are groupings of sensor network assets that have been allocated to a particular activity. The concept of a Task is provided to enable external planning and resource applications to track and prioritize the allocation of assets within the Fabric. Classes are also provided within the Service naespace to support the five-box schea representation of hierarchic services with the PortDefinition class having sub-classes to specialise input and output ports for a service. Fig 7 expands the classes for representing hierarchic services to show the OWL predicates that link the classes. In the ontology, Connections have a fro and to qualification linking the to PortDefinition and PortInstance classes to represent the source and sink port classes they interconnect. Finally, there are a set of classes to support the Fabric plugin architecture. When deployed, services will be ipleented as plug-in odules that process essages as they flow through Fabric nodes. Node plug-ins process all essages that flow through a node. Actor and Task plug-ins are applied to essages destined to a particular actor or flowing as part of a defined Task. Fablets have the additional flexibility of being able to interact with other non-fabric applications and resources. Finally, Service plug-ins extend the capability of the core Fabric functionality.

6 6 ServiceDefinition servicedefinedby containsserviceinstance ServiceInstance containsconnection containsportdefinition connectsfroportdefinition Connection containsportinstance connectstoportdefinition connectsfroportinstance connectstoportinstance PortDefinition portdefinedby PortInstance InputPortDefinition OutputPortDefinition Fig 7: The Five Box Schea represented as an Ontology VI. CONCLUSIONS AND FURTHER WORK In this paper we have described a odel-based approach for the design, analysis and deployent of services within a sensor network based on previously reported work on the developent of sensor network iddleware: the ITA Sensor Fabric. Using a otivating exaple scenario, we base our core design odel on UML Activity diagras and their associated seantics, with an underlying representation using the five-box schea realized as an ontology. The odel ay be transfored into alternative odels (including foral odels such as process algebras) for analysis with the results providing additional annotations to the core design odel via a round-tripping echanis. The core odel ay also be transfored into a for that can be deployed onto a real sensor network using the ITA Sensor Fabric. Further work is continuing under the ITA research prograe to develop a tooling infrastructure to support the creation, transforation, analysis and deployent of sensor network service odels. User tools based on the Eclipse fraework are being developed which will integrate with a seantic wiki provides an interactive representation of the knowledge it contains. This will provide a flexible environent where different applications, each using the core sensor network odel, can be developed. Other applications that are based on seantic technologies such as ission and resource planning will benefit fro the flexibility of the tools fraework which will perit application specific ontologies to be iported in the for of RDF files and integrated with the core sensor network odel. A version of the ITA Sensor Fabric can be downloaded for evaluation and experientation fro the IBM Alphaworks website at REFERENCES [] J. Wright, C Gibson, F. Bergaaschi, K. Marcus, R. Pressley, G. Vera, G Whipps, A Dynaic Infrastructure for Interconnecting Disparate ISR/ISTAR Assets (The ITA Sensor Fabric), IEEE/ISIF Fusion 2009 Conference, July [2] G. Cirincione and J. Gowens, The International Technology Alliance in Network and Inforation Science a U.S.-U.K. Collaborative Venture, IEEE Cos. Mag., vol 45, pp 4-8, March [3] Fabric for Sensor Network Manageent and Data Transfer, [4] G. Bent, P. Dantressangle, A. M. D. Vyvyan and V. Mitsou, A Dynaic Distributed Federated Database, in Second Annual Conference of ITA, Septeber [5] J. Ibbotson, S. Chapan, B. K. Szyanski, The Case for an Agile SOA, Annual Conference of ITA, 2007, Septeber, [6] The Zigbee Alliance, [7] The Bluetooth Special Interest Group, [8] Web Services Business Process Execution Language Version 2.0, [9] D. Thornley, R. Young, J. Richardson, Developent of a Mission Abstraction Requireents Structure (MARS) and Stochastic Modelling for Sensing Service-Driven Mission Perforance Prediction, Iperial College Dept of Cop Tech Report 2009 #0, [0] Silicon Integration Initiative, CHDStd Reference Specification Physical Design Language (PDL) Description, [] A. Robin, S. Havens, S. Cox, J. Ricker, R. Lake and H. Niedzwiadek. OpenGIS Sensor Model Language (SensorML) Ipleentation Specification. Technical Report, Open Geospatial Consortiu Inc, [2] D.J. Russoanno, C.R. Kothari and O.A Thoas. Building a sensor ontology: A practical approach leveraging ISO and OGC odels. In Proceedings of the 2005 International Conference on Artificial Intelligence (ICAI), pp , [3] M. Sensoy, T. Le, W. W. Vasconcelos, T. J. Noran, A. D. Preece, Resource Deterination and Allocation in Sensor Networks: A Hybrid Approach, The Coputer Journal, January, 200. [4] M Goez, A Preece, M P Johnson, G de Mel, W Vasconcelos, C Gibson, A Bar-Noy, K Borowiecki, T La Porta, D Pizzocaro, H Rowaihy, G Pearson, & T Pha, An Ontology-Centric Approach to Sensor-Mission Assignent, Proc 6th International Conference on Knowledge Engineering and Knowledge Manageent (EKAW 2008), in press, 2008.