<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Automated Sensor Registration, Binding and Sensor Data Provisioning</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Pascal Hirmer</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Matthias Wieland</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Uwe Breitenbücher</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Bernhard Mitschang</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Institute of Architecture of Application Systems University of Stuttgart</institution>
          ,
          <addr-line>Universitätsstr. 38, Stuttgart</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Institute of Parallel and Distributed Systems</institution>
        </aff>
      </contrib-group>
      <fpage>81</fpage>
      <lpage>88</lpage>
      <abstract>
        <p>Today, the Internet of Things has evolved due to an increasing interconnection of technical devices. However, the automated binding and management of things and sensors is still a major issue. In this paper, we present a method and system architecture for sensor registration, binding, and sensor data provisioning. This approach enables automated sensor integration and data processing by accessing the sensors and provisioning the data. Furthermore, the registration of new sensors is done in an automated way to avoid a complex, tedious manual registration. We enable (i) semantic description of sensors and things as well as their attributes using ontologies, (ii) the registration of sensors of a physical thing, (iii) a provisioning of sensor data using diferent data access paradigms, and (iv) dynamic sensor binding based on application requirements. We provide the Resource Management Platform as a prototypical implementation of the architecture and corresponding runtime measurements.</p>
      </abstract>
      <kwd-group>
        <kwd>Internet of Things</kwd>
        <kwd>Sensors</kwd>
        <kwd>Ontologies</kwd>
        <kwd>Data Provisioning</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        Nowadays, the integration of sensors becomes more and more important, especially
for the emerging Internet of Things (IoT) [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ] and Industry 4.0 [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. Through the
integration of raw sensor data, high level information can be derived that leads
to huge benefits, e.g., in advanced manufacturing, smart homes or smart cities.
In previous work [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ], e.g., we presented SitRS – a service for situation recognition
in smart environments based on raw sensor data. However, in this and in many
other IoT approaches, sensors are manually registered and bound for processing,
which is a complex and tedious task that requires technical knowledge about the
sensors to be registered. Furthermore, adapters have to be manually created and
deployed for each sensor to extract its data and to provision it to the application
that is intended to consume the data. However, these steps are error-prone and
can take hours or even days to be processed manually: a sensor expert has to
configure the sensors, install a sensor gateway, bind the sensors, implement the
sensor data provisioning and establish interfaces to applications that intend to
consume the sensor data. By doing so, he constantly has to communicate with
domain-experts that want to build or use sensor-driven applications. In real-world
scenarios, eficiency and accuracy are of vital importance. The drawbacks that
come with a manual registration can lead to high costs due to occurring errors
and a tedious, time-consuming registration process.
      </p>
      <p>In this paper, our goal is to reduce the manual steps to the modeling of
sensors and things using ontologies. All other steps (sensor binding, sensor data
provisioning) can be processed automatically in milliseconds instead of hours or
even days when conducting them manually. By doing so, we can reduce occurring
errors that are more likely with manual processing and, as a consequence, save
costs. To enable this, we need a means for automated sensor registration, sensor
binding, as well as provisioning of the sensor data for further processing. In
this paper, we present a method and system architecture for this means by
(i) using ontologies for the definition of sensors and things, by (ii) enabling
dynamic sensor binding through automated adapter deployment, and by (iii)
sensor data provisioning using diferent data access paradigms. This enables
direct Machine-to-Application communication by the abstraction of technical
details.</p>
      <p>Note that there are also objects in the world that are not observable by
sensors. These objects are not covered in this paper.</p>
      <p>The remainder of this paper is structured as follows: In Sect. 2, we describe
related work. In Sect. 3, the main contribution of this paper is presented. After
that, in Sect. 4, we evaluate the approach through runtime measurements of our
prototypical implementation. Finally, in Sect. 5, we give a summary of the paper
and describe future work.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Related Work</title>
      <p>
        In [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] the goal is similar to our approach. The authors present a middleware
called Global Sensor Network (GSN), which enables binding data sources like
sensors and data streams with zero programming efort. To realize that, a virtual
sensor abstraction is provided in [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], which allows declarative specification of
deployment descriptors and basic processing of the data using SQL-like queries.
In our approach, we separate these steps strictly. First, the dynamic sensor
binding is done using ontologies. Second, the data is provisioned to sensor-driven
applications.
      </p>
      <p>
        Sensor description and configuration is standardized in IEEE 1451.2 defining
Transducer Electronic Data Sheets (TEDS) [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ] that enable the self-description
of sensors. Furthermore, an interface for standardized dynamic plug and play
binding of sensors to networks is provided. In our approach, the physical binding
of sensors is not the focus. We concentrate on an easy provisioning of sensor data
to sensor-driven applications through the Internet. Note that standards such as
the IEEE1451.2 could be used for sensor binding in our approach.
      </p>
      <p>
        In [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], a REST-based interface is built to access sensors and retrieve their
data. By doing so, this paper assumes an already in place sensor network bound
to a gateway, which provides information of the sensors and manages their access
for data retrieval. In contrast, our paper does not necessarily assume such a
gateway and manages the sensor binding itself. Only the provisioning of sensor
data is similar to our approach in [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ].
      </p>
      <p>
        In recent years, a large amount of Machine-to-Machine (M2M) gateways
have been created such as FIWARE, OpenMTC3, OpenIoT [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ], or GSN [
        <xref ref-type="bibr" rid="ref1 ref2">2,1</xref>
        ].
These gateways serve as layer between physical sensors and “virtual” sensor
data. It is important to note that the approach in this paper does not try to
compete with these approved platforms but rather uses them, i.e., provides a
more abstracted layer on top in order to enable an easy way to bind things in
contrast to specific sensors, and to automatically provision data of the contained
sensors to sensor-driven applications using Internet technologies. More precisely,
the mentioned platforms can be used as gateways by our approach to realize the
sensor binding.
      </p>
      <p>
        Middleware between the physical and application layer gain more and more
importance [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. The main purpose of such middleware systems is to hide and
abstract the physical details in order to allow the programmer to focus on the
development of a specific sensor-driven application. Furthermore, it is important
to abstract from the concrete environment and sensory that will be used after
deployment of the application, in order to avoid a cumbersome and time-consuming
configuration in each new environment.
      </p>
      <p>
        SStreaMWare [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] is a service-oriented middleware for heterogeneous sensor
data. It uses a hybrid approach supporting both centralized data streams and
distributed sensor networks. Furthermore, a generic schema for sensor data
representation is proposed (measures, timestamps and properties) and declarative
queries can be executed on the sensor data streams. SStreaMWare has an approach
similar to ours in managing the sensors and binding them based on the devices
observed.
      </p>
      <p>
        OntoSensor [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ] is a sensor knowledge repository for modeling and management
of sensors. It combines SensorML, IEEE SUMO, ISO 19115, OWL and GML.
The goal of OntoSensor is to achieve a usage for description of sensors in diferent
application domains. Through the combination of many diferent sensor definition
languages, the ontologies become heavy-weight and complex. In our approach,
we aim for a particularly lightweight ontology. Because of that, we decided to
use only a subset of SensorML and omit using the whole OntoSensor ontology.
      </p>
      <p>
        DCON [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] is an ontology for representation of user activity context. In [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ],
the authors combine many diferent OSCAF ontologies 4 to create a Personal
Information Model: DDO (for Devices), DPO (for Presence), DCON [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] for
representation of user activity context, and further. This is a specialized area and
the ontologies are very detailed. In our approach the goal is to support any kind
of domain, so the concepts are more generic. Not everything is focused on the
3 www.open-mtc.org/ 4 http://www.semanticdesktop.org/ontologies/
users, in our approach things are the main focus and persons in contrast should
not be monitored for privacy reasons.
      </p>
      <p>
        In summary, the presented related work is mainly focusing on specific aspects
like the access of sensors using gateways, or the execution of queries on sensor
data streams or in a sensor network. However, the goal of our approach is to
provide an easy-to-use ontology for the Internet of Things that combines sensor
registration, binding of the sensors, and sensor data provisioning. Whereat the
binding of a concrete sensor is done indirectly based on the things that are
monitored by the sensors. Furthermore, our approach allows a separation of
concerns, since the sensor data processing is specified separately, e.g., in the
situation recognition as described in [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ], based on situation templates that can be
mapped onto diferent execution systems. Additionally, our approach allows the
integration of heterogeneous sensor types in a standard way as REST resources
or through a publish-subscribe model so that they can be accessed by multiple
clients and in parallel.
3
      </p>
      <p>Sensor Registration, Binding and Sensor Data</p>
      <p>Provisioning
This section presents the main contribution of this paper by introducing a system
architecture and a method for ontology-based sensor registration, binding, and
sensor data provisioning. Figure 1 depicts the overall architecture of our approach.
It consists of the following main components: (i) the sensor registry, storing
meta-information about the physical things and sensors, (ii) the sensor ontology,
containing sensor binding information, (iii) the sensor adapters, extracting the
data from the sensors, that can be deployed directly on a thing or on an adapter
platform, and (iv) the Resource Management Platform (RMP) provisioning the
sensor data as remotely accessible resources (pull) or via a publish-subscribe
approach (push).</p>
      <p>Resource
Management</p>
      <p>Platform
Sensor
Adapter
Platform</p>
      <p>Queue
Broker
Sensor
Adapter 1</p>
      <p>Sensor-driven Applications</p>
      <p>Service</p>
      <p>Service
Sensor Data Storage
Sensor
Adapter 2
…</p>
      <p>Sensor</p>
      <p>Adapter n
Physical Things with Sensors</p>
      <p>Create
Resource Sensor Registry</p>
      <p>Register</p>
      <p>Sensors/Objects
Sensor
Ontology</p>
      <p>Model
This architecture is applied through a method that enables automated sensor
registration, binding and sensor data provisioning in five consecutive steps. Note
that a full automation of this method is possible.</p>
      <sec id="sec-2-1">
        <title>Step 1: Task Definition</title>
        <p>– Input: thing identifier, sensor identifier(s),
– Output: thing identifier, sensor identifier(s),
optional: ontology snippet
optional: ontology snippet
In the first step of the method, the things and sensors to be registered are defined
by so called task definitions . Each task definition contains a unique identifier of
the thing to be registered and, if specific sensors of a thing should be registered,
also the sensors’ identifiers. Detailed information of sensors and things are not
necessary, because they are contained in the sensor ontology (cf. Step 2). In
case a thing or a sensor is not known, i.e., is not represented in the ontology, an
ontology snippet describing their properties has to be added to the task definition,
which will be processed in Step 2. However, in the following, we assume that the
ontology contains all sensors and things of the specific domain our approach is
applied to and is modeled correctly.</p>
      </sec>
      <sec id="sec-2-2">
        <title>Step 2: Ontology Traversal</title>
        <p>
          – Input: thing identifier, sensor identifier(s), optional: ontology snippet
– Output: list of sensor specifications, thing identifier, sensor identifier(s)
Based on the information contained in the task definitions of Step 1, additional,
specific information about things and sensors are retrieved from the ontology next.
The ontology describes technical details that are necessary for an automated
sensor registration, sensor binding, as well as sensor data provisioning, and can
also be used as meta-data source by sensor-driven applications. These information
include sensor specifications (accuracy, frequency, ...), information about the
sensor access, i.e., about sensor binding in terms of the corresponding adapter
in a sensor adapter repository, and information about the contained sensors of
a thing. To enable an eficient storage and retrieval of these information, we
use ontologies based on the XML-based sensor markup language SensorML [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ].
Ontologies ofer a means for an automated editing and extension, e.g., using
generated SPARQL queries. Furthermore, in Internet of Things scenarios, the use
of ontologies is commonly accepted [
          <xref ref-type="bibr" rid="ref13 ref14 ref3">14,13,3</xref>
          ] due to the heterogeneous, dynamic
environments that have to be integrated. On sensor registration, we traverse the
ontology and search for the corresponding entry of the sensor or thing. Once
the relevant sensor information is found, it is used for automated sensor binding,
which is described next.
        </p>
      </sec>
      <sec id="sec-2-3">
        <title>Step 3: Sensor Adapter Deployment / Automated Sensor Binding</title>
        <p>– Input: list of sensor specifications, thing identifier, sensor identifier(s)
– Output: list of successfully deployed adapters
After the information necessary to bind the sensors has been extracted from the
ontology, the next step is the automated sensor binding and, furthermore, the
provisioning of the sensor data. To enable this, we first need a means to extract
the sensor data from the corresponding sensors. This requires adapters, which
are connecting to the sensors’ serial interfaces, extract the data as a stream, and
send it to the Resource Management Platform (e.g., using HTTP or MQTT).
An advantage of our approach is that the adapters do not have to care about
sensor data provisioning to sensor-driven applications, because they send the
data directly to the centralized RMP that manages the provisioning for them.</p>
        <p>
          Sensor adapters are deployed automatically. First, the adapters are retrieved
from a repository and can be parameterized (e.g., with the RMP’s URL). The
information, which adapter is needed to bind the sensor(s) defined by the task
definition is extracted from the ontology in Step 2. There are several possibilities
how an adapter deployment can be realized: if the sensor is connected to a thing
that is containing a powerful runtime environment such as, e.g., a Raspberry
Pi, the adapter can be deployed directly using, e.g., SSH connections or more
sophisticated approaches such as TOSCA [
          <xref ref-type="bibr" rid="ref5">5</xref>
          ]. However, in most cases this is
not possible. Because of that, the adapters have to be deployed on external
platforms, either self-implemented or using approved solutions, such as FIWARE
or OpenMTC, that are capable to connect to the sensors, even if, e.g., they are
embedded into a production machine, using Machine-to-Machine standards.
        </p>
      </sec>
      <sec id="sec-2-4">
        <title>Step 4: Sensor Data Provisioning</title>
        <p>– Input: list of successfully deployed adapters
– Output: REST resource URI(s), queue topic(s)
Once a sensor adapter is deployed and activated, it starts sending data to the
RMP. However, the data can only be accessed by the sensor-driven applications
after the fourth step is processed, the sensor data provisioning. In this step,
the interfaces to the sensor-driven applications are established. The sensor data
provisioning step represents the integration of all components, from the sensor
adapters to the sensor data provisioning through the RMP. After the automated
adapter provisioning (Step 3), the RMP is informed that the registered sensors
have started sending their data. By doing so, entries in the sensor data storage
as well as corresponding REST resources are created for each sensor to provision
its data to enable the pull approach. Furthermore, we create topics in a queue
for each sensor and publish these topics to the sensor-driven applications that
can subscribe to them to enable the push approach. After this step, the sensor
data are available to sensor-driven applications.</p>
      </sec>
      <sec id="sec-2-5">
        <title>Step 5: Sensor Deactivation</title>
        <p>– Input: thing identifier, sensor identifier(s)
– Output: list of successfully deactivated sensors
The last step is the deactivation of sensors once they are not needed anymore.
To do so, the thing and the type of the sensor have to be provided to the sensor
registry. Based on this information, the sensor registry finds running sensors of a
thing with the corresponding type, connects to the adapters to terminate them,
clears the values from the sensor data storage, and removes the REST resources
and the topics in the queue. Deactivation of sensors saves energy and, thus, costs.
4</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Evaluation</title>
      <p>We implemented an open-source prototype of the RMP that is in productive
use within the project SitOPT. The sensor registry component is based on
NodeJS5 and ofers a REST-based programmatic interface. The sensor registry
uses SPARQL requests to access the sensor ontology, SSH to deploy the sensor
adapters and HTTP to notify the RPM that a new sensor has been registered.
Currently, the native file system is used as adapter repository. The ontology
was defined using the Web Ontology Language (OWL) 1.16. The access to the
ontology is done by SPARQL requests through the Apache Jena7 framework.
The RMP is also implemented in NodeJS, which enables an easy definition of a
RESTful interface. Furthermore, due to the lightweight platform, it ofers high
eficiency. The sensor data storage is implemented using the NoSQL database
mongodb8, which allows high eficiency, scalability, and data replication. The
direct push approach was realized using MQTT9 and the Mosquitto10 broker.</p>
      <p>We conducted runtime measurements of our prototype for evaluation purposes
using a machine with a Core i5-3750K @3.4GHz and 8 GB RAM. We measured
the average runtime of the steps described in the previous section based on 10
measurements: (i) the sensor registration took 1,91 ms, (ii) the ontology traversal
6,73 ms, and (iii) the adapter deployment 139,63 ms. The measurements show
that we could achieve the eficiency goals of this paper (cf. Sect. 1).
5</p>
    </sec>
    <sec id="sec-4">
      <title>Summary and Future Work</title>
      <p>In this paper, we present an approach for ontology-based sensor registration and
sensor data provisioning. We introduce a system architecture and a method to
make our approach applicable for a wide range of Internet of Things applications.
After registration of a sensor, an adapter is deployed automatically that reads
the sensor data, and passes it to the Resource Management Platform. The RMP
creates topics in a MQTT queue and HTTP REST resources to provision the data.
By doing so, we created an easy-to use solution for sensor-driven applications
to bind sensors and access their data. Our goal was the registration, binding
and sensor data provisioning in an automated manner to enable this within
milliseconds in contrast to a manual processing of these steps that can take up
to hours or even days. This goal was achieved as described in our evaluation.</p>
      <p>In the future, we will add security, privacy and robustness features to our
prototypical implementation and, furthermore, we will work on the performance
that will supposedly decrease by adding these features. In addition, we will work
on optimizations for our presented method.</p>
      <sec id="sec-4-1">
        <title>5 http://nodejs.org/</title>
        <p>7 https://jena.apache.org/
10 http://mosquitto.org/</p>
      </sec>
      <sec id="sec-4-2">
        <title>6 http://www.w3.org/Submission/owl11-overview/</title>
        <p>8 http://www.mongodb.org/ 9 http://mqtt.org/</p>
        <p>Acknowledgment. This work is partially funded by the DFG project SitOPT
(610872) and by the BMWi project SmartOrchestra (01MD16001F).</p>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Aberer</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hauswirth</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Salehi</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>A middleware for fast and flexible sensor network deployment</article-title>
          .
          <source>In: Proceedings of the International Conference on Very Large Data Bases (VLDB</source>
          <year>2006</year>
          )
          <article-title>(</article-title>
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Aberer</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          , et al.:
          <article-title>Zero-programming Sensor Network Deployment</article-title>
          .
          <source>In: Proceedings of the Service Platforms for Future Mobile Systems</source>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Attard</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Scerri</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rivera</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Handschuh</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Ontology-based Situation Recognition for Context-aware Systems</article-title>
          .
          <source>In: Proceedings of the 9th International Conference on Semantic Systems</source>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Atzori</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Iera</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Morabito</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          :
          <article-title>The Internet of Things: A survey</article-title>
          .
          <source>Computer Networks</source>
          (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Binz</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          , et al.:
          <source>TOSCA: Portable Automated Deployment and Management of Cloud Applications</source>
          , pp.
          <fpage>527</fpage>
          -
          <lpage>549</lpage>
          . Springer (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Botts</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          , et al.:
          <article-title>OGC Sensor Web Enablement: Overview and High Level Architecture</article-title>
          .
          <source>In: GeoSensor Networks</source>
          . Springer Berlin Heidelberg (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Gurgen</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Roncancio</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>LabbÃľ</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bottaro</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Olive</surname>
          </string-name>
          , V.:
          <article-title>SStreaMWare: a service oriented middleware for heterogeneous sensor data management</article-title>
          .
          <source>In: International Conference on Pervasive Services</source>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Hauswirth</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Aberer</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Middleware support for the" Internet of Things"</article-title>
          .
          <source>5th GI/ITG KuVS Fachgespräch "Drahtlose Sensornetze"</source>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Hirmer</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wieland</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schwarz</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mitschang</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Breitenbücher</surname>
            ,
            <given-names>U.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Leymann</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          :
          <string-name>
            <surname>SitRS-A Situation Recognition</surname>
          </string-name>
          <article-title>Service based on Modeling and Executing Situation Templates</article-title>
          .
          <source>In: Proceedings of the 9th Symposium and Summer School on Service-Oriented Computing (SUMMERSOC</source>
          <year>2015</year>
          ). pp.
          <fpage>247</fpage>
          -
          <lpage>258</lpage>
          (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Ishaq</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hoebeke</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rossey</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>De Poorter</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Moerman</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Demeester</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Facilitating Sensor Deployment, Discovery and Resource Access Using Embedded Web Services</article-title>
          .
          <source>In: Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS)</source>
          ,
          <year>2012</year>
          Sixth International Conference on. pp.
          <fpage>717</fpage>
          -
          <lpage>724</lpage>
          (
          <year>July 2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Jazdi</surname>
          </string-name>
          , N.:
          <article-title>Cyber physical systems in the context of Industry 4.0</article-title>
          . In: Automation, Quality and Testing, Robotics, 2014 IEEE International Conference on (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Lee</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          : IEEE 1451:
          <article-title>A standard in support of smart transducer networking</article-title>
          .
          <source>In: Instrumentation and Measurement Technology Conference</source>
          ,
          <year>2000</year>
          .
          <article-title>IMTC 2000</article-title>
          .
          <article-title>Proceedings of the 17th IEEE (</article-title>
          <year>2000</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Probst</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gordon</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dornelas</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          :
          <article-title>OGC discussion paper: ontology-based representation of the OGC observations and measurements model</article-title>
          .
          <source>Institute for Geoinformatics (ifgi)</source>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Russomanno</surname>
            ,
            <given-names>D.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kothari</surname>
            ,
            <given-names>C.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Thomas</surname>
            ,
            <given-names>O.A.</given-names>
          </string-name>
          :
          <article-title>Building a Sensor Ontology: A Practical Approach Leveraging ISO and OGC Models</article-title>
          .
          <source>In: IC-AI</source>
          (
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Scerri</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Attard</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rivera</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Valla</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>DCON: Interoperable Context Representation for Pervasive Environments</article-title>
          . In: AAAI Workshops (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Soldatos</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kefalakis</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hauswirth</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          , et al.:
          <article-title>OpenIoT: Open Source Internetof-Things in the Cloud</article-title>
          . In: Interoperability and
          <article-title>Open-Source Solutions for the Internet of Things</article-title>
          . Springer International Publishing (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Vermesan</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Friess</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Internet of Things: Converging Technologies for Smart Environments</article-title>
          and
          <string-name>
            <given-names>Integrated</given-names>
            <surname>Ecosystems</surname>
          </string-name>
          . River Publishers (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>