=Paper=
{{Paper
|id=None
|storemode=property
|title=Short Paper: Using SOAR as a Semantic Support Component for Sensor Web Enablement
|pdfUrl=https://ceur-ws.org/Vol-839/kannegieser.pdf
|volume=Vol-839
|dblpUrl=https://dblp.org/rec/conf/semweb/KannegieserL11
}}
==Short Paper: Using SOAR as a Semantic Support Component for Sensor Web Enablement==
https://ceur-ws.org/Vol-839/kannegieser.pdf
Short Paper: Using SOAR as a Semantic Support
Component for Sensor Web Enablement
Ehm Kannegieser , Sandro Leuchter
Fraunhofer IOSB, Department of Interoperability and Assistance Systems
{ehm.kannegieser, sandro.leuchter}@iosb.fraunhofer.de
Abstract: 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.
Keywords: SOAR, SCA, rule based sensor selection, service discovery
1 Introduction
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 Sensor Web Enablement
2.1 Semantic Support for SWE
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 System Architecture
3.1 SOAR
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 Case Study Evaluation
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.
Table 1. SOAR-kernel methods.
Method name Performed action
start()/void stop() Starts/Stops the SOAR-kernel
query(IDs) Sends a query to the SOAR-
kernel. A list of sensor ids (IDs) is
passed to the method. Returns a
list of sensor ids as result.
setContext( KVPs ) Writes updates/changes to the
WM. A list of key-value-pairs is
passed to the method. This is the
most important method because
it allows the WM to be changed.
Changes to the WM may trigger
rules that affect the
recommendation of sensors.
setOntologyFile(String,String) Sets the ontology and the
corresponding XSLT file for
transformation of semantic
information into the SOAR-
kernel. Two filenames are passed
to the method.
setProductionsFile(String) Sets the productions file which
contains the
production and preference rules
needed for
sensor recommendation.
4 Conclusion & Future Work
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.
5 References
1 Open Geospatial Consortium Inc.: Sensor Web Enablement,
http://www.opengeospatial.org/ogc/markets-technologies/swe, 2009.
2 John E. Laird and Clare Bates Congdon: The Soar User's Manual, 2011.
3 The Soar Group (2009): Soar Website. University of Michigan.
http://sitemaker.umich.edu/soar/home, 2009.
4 W3C (2004): OWL Web Ontology Language Overview.
http://www.w3.org/TR/owl-features/, 2004.
5 W3C (o.J.): Extensible Markup Language (XML). http://www.w3.org/XML/,
2009.
6 Chappell, David: Introducing SCA.
http://www.davidchappell.com/articles/Introducing_SCA.pdf, 2007.
7 Arthur Na; Mark Priest: Sensor Observation Service, 2008.
8 Johannes Echterhoff; Ingo Simonis: OGC 09-000. Sensor Planning Service,
2011.