Upto: Table of Contents of full book "Internet of Things - a techie's viewpoint"

Sensor description languages

Resources

Introduction

Sensors are one set of edge devices for the IoT, along with actuators, end-user computers such as PCs and possibly many other systems. In a world of billions of sensors it will be impossible to deal with each one separately. There needs to be general descriptions that can be applied to classes of devices, with more detail available if required.

Eastman et al are leading a NIST effort to give adequate descriptions of sensors. One publication is A Sensor Ontology Literature Review . As sensors are both physical and electrical devices, a completely general description should include both the physical and the electrical characteristics. For example, the temperature sensors discussed in the last chapter vary in technologies used, size and physical behaviour in addition to their electrical properties of temperature response, range and accuracy.

For the IoT, we are more interested in the electrical properties, but even in that domain there may be many physical properties that can affect a sensor as an IoT device: battery power, response under different power levels, degradation in behaviour over time, etc.

This is still an ripe area for development.

W3C semantic sensor network

The Open Geospatial Consortium is concerned with geological measurements related to location. They produced a description for sensors relevant to geolocation. This was picked up by the W3C for their own work on sensor descriptions.

The W3C descriptions are relatively abstract. They do not describe particular devices such as thermometers, rather whether a sensor hasMeasurementCapability, and what is the Accuracy. The descriptions are given by an ontology in OWL (Web Ontology Langauge) as XML specifications. There are many software tools that can read such descriptions, and are an open specification.

An abstract Device is illustrated by SSN Device . An example of a specific device (a Vaisala WM30 wind sensor) is given at SSN Ontology example: Wind Sensor but there only seem to be a few others such as Sensor Observations by Markus Stocker for "CO2 and H2O fluxes using an LI-7500."

This specification does not seem to have gained much traction, despite its wide citation, generality and probable applicability to IoT sensors and actuators.

OIC sensor descriptions

The OIT (Open Interconnect Consortium) is one IoT group quite well advanced in developing a full IoT ecosystem. In particular, they have addressed the topic of sensor descriptions. Rather than being declarative descriptions, they are more of a client-server request-response API description. That is, they describe the requests that may be made, along with optional parameters, and then the result that should be returned.

As components of an ecosystem, OIC sensors are assumed to have enough processing capability to be able to use HTTP over a wireless or wired connection, using a protocol such as CoAP. Typically this would require a microcontroller or microprocessor. An Arduino with an ethernet shield would be close to the minimum requirement. OIC sensors use REST to communicate with other components of an OIC system as their "programming API". (REST and CoAP are described in detail in later chapters).

The formal description of sensors uses a representation language called RAML (RESTful API Modeling Language). This is discussed along with REST in a later chapter. We paraphrase extensively here.

A request made to a temperature sensor is primarily to GET the current temperature as in

      
GET /mythermometer?units="C" HTTP/1.0
      
    

Units are an optional parameter of "C", "F" or "K".

The response is a real value, also including the units and the possible temperature range as described in (temperature.raml). The response will be an HTTP 200 "OK" response, including the data say as a JSON object:

      
{
  "temperature":  20.0,
   "units":        "C",
   "range":        "0,100"
}
      
    

The description is simplistic, but adequate for many purposes. It may not be enough if you need the accuracy, performance outside of that domain, and so on. Well, you can subclass the basic temperature device if you need more detailed properties.

IPSO sensors

IPSO (Internet Protocol for the Networking of Smart Objects) is "is an open, informal and thought-leading association of like-minded organizations and individuals that promote the value of using the Internet Protocol for the networking of Smart Objects." IPSO Alliance: About us They have produced a list of 18 "smart objects" in a Starter pack . This describes objects such as a temperature sensor with value, units, min and max temperature.

Like the OIC descriptions, the description is simplistic, but adequate for many purposes

      
 "temperature":  20.0,
 "units":        "C",
 "range":        "0,100"
      
    
It may not be enough if you need the accuracy, performance outside of that domain, and so on. Well, you can subclass the basic temperature device if you need more detailed properties.

SenML: Media Types for Sensor Measurement Lists

From the RFC:

SenML is defined by a data model for measurements and simple meta- data about measurements and devices. The data is structured as a single array that contains a series of SenML Records which can each contain fields such as an unique identifier for the sensor, the time the measurement was made, the unit the measurement is in, and the current value of the sensor. Serializations for this data model are defined for JSON, CBOR, XML, and Efficient XML Interchange (EXI).

SenML defines a number of field names, such as 'n' for name, 'u' for unit and 'v' for value. A temperature measurement might be in JSON:


   [
     {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
   ]
	
      

The rest of the specification considers optimisations for representation of data in various formats. It does not define values such as "Cel" for Celsius. These would belong to further data representation schemes.

Conclusion

This chapter has given a brief discussion of how to describe IoT devices so that other components in an IoT system can know how to deal with them. The situation is not yet satisfactory.


Copyright © Jan Newmarch, jan@newmarch.name
Creative Commons License
"The Internet of Things - a techie's viewpoint" by Jan Newmarch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://jan.newmarch.name/IoT/.

If you like this book, please donate using PayPal