Semantic service discovery is necessary to facilitate the potential of service providers (many sensors, different characteristics) to change the sensor configuration in a generic surveillance application without modifications to the application's business logic. To combine efficiency and flexibility, semantic annotation of sensors and semantic aware match making components are needed. This short paper gives the reader an understandig of the SOAR component for semantic SWE support and rule based sensor selection.
It is a common conception that semantic service discovery is necessary to facilitate the Internet of Services because the plethora of potential service providers has to bematched to the specific needs of a service consuming value chain. From our point of view this is also true for the Internet of Things – in our case a sensor web – because there are many sensors with different characteristics available. We want to be able to change the sensor asset configuration in a generic surveillance application without modifications to the application’s business logic. We also envision a SOA-like wide area enterprise architecture for sensor webs where different sensor service providers will be combined in a cost efficient and flexible way. To achieve this, semantic annotation of sensors and semantic aware match making components are needed. In the remainder of this paper we describe our solution to this problem definition, based upon SWE, SCA, and the SOAR rule engine as well as a prototype application in the surveillance domain. 2.1
SWE, short for Sensor Web Enablement is a suite of OGC standards, i.e. Sensor Markup Language (SensorML), Sensor Planning Service (SPS) and Observation Service (SOS), which provides an open interface for sensor web applications as described in [1].
In a time of rapidly developing semantic web, sensors and sensor data have to be accessible in a feasible kind of way, thus have their capabilities described semantically. Ontological descriptions and annotations achieve this by adding helpful metadata to sensors and data, harnessing the massive amount of available information. Originating from a semantic aware service discovery that fits into SOAs and is based upon the SOAR rule engine, we have developed a semantic component to aid the process of sensor tasking and sensor data retrieval in a SWE environment by finding the most feasible sensors and related data.
In a proof of concept we introduce a perimeter control application with simple service enabled sensors. The component uses an ontological representation of attributes and capabilities of deployed sensors and a custom rule set that uses context information to deduce constraints of the current situation and proposes sensor services best suited to current task and context. 3 3.1
State, Operator, Action, Result (SOAR) describes the solution of a problem as a number of state transitions. A starting state (representing the problem) is changed into a final state (representing the solution) by changes to the systems memory, done by rules.
A SOAR rule consists of two parts: condition and action. The condition describes a specific working memory (WM) pattern. If this pattern is matched by changes (i.e. input) to the working memory, the action is triggered, changing WM into a new pattern which may trigger other rules. This way SOAR is able to react to system context changes and transit towards the desired system state.
There are three different ways to store knowledge in SOAR: the WM is an acyclic directed graph which represents all known facts.
Rules that are changing WM are stored in the production memory.
Preference memory (PM) maintains a ranking of operator feasibility. In case that there is more than one feasible operator, an impasse arises. Impasses create substates of the main problem with their own WM, to solve the problem that caused the impasse (Figure 3). A solved impasse creates one or more production rules (chunks) in the RM of the top state. Thus impasses caused by the same (or similar) WM constellation will be avoided in the future. After the impasse is solved, the WM of the substate is retracted and the current state can transit towards its final state. This mechanism enables SOAR with basic learning capabilities [2; 3].
To help with useful recommendations, SOAR needs to rely on facts. Thus, knowledge of the subject matter (i.e. sensors and their feasibility under specific environmental conditions) is modeled in an ontology by domain experts. This allows for a reliable initialization of WM with facts from ontology classes and derivation of rules from relations (i.e. “is better/worse than”, “is part”), if specified.
To realize easy access to the ontology knowledge, a XML based ontology language, namely OWL was chosen [4]. XML based files can easily be transformed into arbitrary output formats using XSLT and XPATH (Figure 4) [5]. SensorML is not feasible at this point because knowledge about dependencies and capabilities of sensors has to be represented, which is aligned with the specific SOAR rule set and WM structure.
Open SOA Collaboration (OSOA) Service Component Architecture (SCA) applications consist of composites which again consist of components (Figure 6). Components may be implemented in different programming languages (i.e. Java). Apart from the specific implementation used, the behavior of the components is described to combine them into complex applications [6].
The component provides an interface for operation and communication with the encapsulating system. Through this interface the SOAR kernel and its memories can be accessed (i.e. updating WM with new facts). Further implementation effort is only needed to redefine rule and preference memory. 3.2
Objective of this study is to create a surveillance system that operates on an exchangeable set of sensors and adapt its recommendations to the changing environment conditions. A specific scenario is planned as follows: A defined area (i.e. small room, hallway, laboratory) is equipped with different sensors (i.e. photoelectric barriers, pressure contacts, acoustic, ultrasonic, video, and luminosity sensors) and actuators (i.e. horn, warning light) to detect movement and then sound an alarm.
Therefore the encapsulated SOAR-kernel is integrated into an Open Geospatial Consortium (OGC) SPS and SOS architecture which are described in length at [7; 8].
The interface provided by the component is implemented in Java and features a number of methods for communication and control of the SOAR-kernel (see Table 1).
Firstly if there is a request, the ontology and the rules are passed to the SOARkernel for initialization. Then a query containing a list of (available) sensor ids is sent from the SPS to the SOAR component using the query()-method. The component then elaborates a list of recommended sensors according to the current situation which is passed over to the SOS. The SOS polls for any personWasDetected-signals send by sensors of this list. If the signal is detected, either an alarm is sounded or an optical warning signal is displayed.
The provided rule-set follows a generic approach which lets the system recommend an element from its WM (i.e. the name or id of a feasible sensor). Feasibility is defined as the conformance of the system context and the semantic description of sensors derived from the ontology. If SOAR recognizes one or more matching attributes, the sensor is recommended. There are several scenarios suitable for the rule set provided: few sensor resources, security reasons limiting access only to authorized personnel and high mission costs are decreasing the number of theoretically available sensors. Additionally, harsh environmental conditions and physical restrictions (i.e. extreme temperature, low light, sensor effects) have to be considered when choosing a sensor. There also may be different qualitative and quantitative requirements for sensor observation results, depending on perimeter ranges and security policies.
In this paper we have presented a semantic component capable of rule driven sensor selection. In a proof of concept a perimeter control application which uses an ontological representation of sensors to deduce constraints of the current situation and proposes sensor services best suited to current task and context, was set up. Future work will focus on additional semantic capabilities of the SOAR and extending SWE support (i.e. sensor data interpretation). Another field of activity will be semantic service discovery in the context of SOA, Semantic Grid and Cloud Computing.