Changes to Thing/Sensor/Actuator Model

[alexrobin]

Allowing only Actuators to be associated to TaskingCapabilities is somewhat limiting because Sensors often support receiving commands as well (e.g. for changing sampling rate, mode, etc.). Likewise, actuation systems often produce data themselves, albeit usually via embedded sensors.

Although it is technically possible to model the tasking capability of a Sensor with a separate Actuator in SensorThings, the current model makes it hard to link the two and forces creating more entities than necessary.

In order to improve the situation, although it is useful to clarify (semantically) the main intent of the given component (i.e. Sensor or Actuator), we may find it useful to have a more generic System class that can have both DataStreams, TaskingCapabilities, as well as components that are themselves Systems (note that this is the W3C SSN model). Sensor, Actuator and Thing can then all derive from System and share the same properties.

Such a model would allow the data provider to better choose the level of granularity desired to describe an observation system:

• For simple cases, this allows a Thing to expose datastreams directly without the need to describe individual sensors and/or actuator composing the system. It also allows a Sensor to expose its own tasking inputs and an Actuator to expose its own data, without having to create another entity for that purpose.

• On the other side of the spectrum, having a fully recursive System model allows for describing complex systems in great details. (e.g. a robot would be a system that can have its own top-level datastreams and be composed of sub-systems like one or more robotic arms, each of which with its own sensors, actuators, etc.).

In any case,I also suggest clarifying the relationship between Thing and classes defined in O&M, OMS, SensorML and W3C SSN. For example, a Thing can be a Platform as defined by SSN or a Host as defined by OMS. It can also be a System as per SSN or a PhysicalSystem as defined by SensorML, etc.

[liangsteve]

@alexrobin

• Can you please give a concrete example of the proposed System (e.g., a simple UML?)
• Is the issue here about needing a relation between Sensor and Actuator, either one-to-one or even many-to-many?
• Can you also add a use case based on the use case template?

[liangsteve]

If the issue here is about needing a relation between Sensor and Actuator, is it possible to use a navigation property for that? or add a custom link (e.g., a JSON-LD?)

It might be worth an informative section to show the best practice how to relate different entities.

[alexrobin]

I was thinking of something like this:

A System is fully recursive with potential components/members but can also be a black box.

Things, Sensors and Actuators are merely tagging entities since there are no difference of functionality between them. They can all have datastreams and tasking capabilities.

Location can become a special kind of datastream.

[hylkevds]

I can see many uses for having Things linked to other Things (it's why we made the CustomEntityLinking extension)

Merging Things with Sensors and Actuators makes quite a few use cases much harder, if not impossible. For example the situation where one sensor is moved between different monitoring facilities, depending on need. That requires the Datastream to be linked to both the Sensor and the Facility. This is also the reason that in OMS the Observation(Collection) has separate links to Observer, Procedure and Host.

[alexrobin]

@hylkevds I don't fully understand your comment. Before I can answer, I feel I first need to better understand how you handle moving a sensor to a new facility with STA today.

Are you modeling the facility as a Thing? What do you connect the old Datastream to after moving the Sensor? How do you know that the Datastream actually came from that sensor before the move?

[hylkevds]

• Each facility is a Thing.
• For each (occasionally redeployed) sensor there is 1 sensor.
• When the sensor is deployed in a facility, a Datastream is created.
• Old Datastreams do not change. They simply do not get new data, which is reflected in the fact that the phenomenonTime of the Datastream no longer changes.

When a Sensor is deployed in a facility that it was already deployed in before there is the option to re-use the already existing Datastream, or create a new one for this new deployment. It depends on the details of the use case which option is preferred.

Note 1: in OMS there is now the concept Deployment to explicitly reflect when an Observer is deployed on a Host. Note 2: The model you propose above can be mapped to STA, so a system implementing that model can expose the model as STA. It's just the mapping the other way around that doesn't work.

[alexrobin]

@hylkevds thanks for the explanations. It makes sense.

What is confusing to me is that it only works if you take a data centric view of things (i.e. if you're mostly interested in the datastream). But if I take a system/sensor centric point of view, I would start looking at my sensors and I don't really know in what facility there are at.

For me it's more logical to have a link between the Sensor and the Host it is attached to, whether or not there is data. I think that's what OMS improves upon by using Deployments. In SWE API, we do that by historizing the System descriptions so that at any point in time you can get a snapshot of a state of a System, which can be a Host/Platform (this state includes, among other things, what sub-systems are attached to it at that exact point in time).

Anyway, I can see how my suggestion doesn't completely fit the current STA model. The main thing that I was looking for is to have an entity that can have both datastreams and tasking capabilities. I know you could do that with a Thing but many sensors (even the simplest ones) also accept commands so it's kinda odd to have to model my simple sensor as a Thing with one Sensor and one Actuator when it's really just a very simple sensor (e.g. a simple digital thermometer with settable sampling rate and sensitivity). How do you recommend handling this very common use case?

And it gets even more tricky when you have multiple sensors like this that you would also like to attach to the same platform, which, AFAIK, also has to be modeled as a Thing in STA.

[hylkevds]

Yes, the current STA model is quite focused on the data and less on the system. I think extra links would help with that.

The case of Sensor / Actuator combinations is one of those cases that are clearly not ideal, since there is no link between those entities other than over Datastream <-> Thing <-> TaskingCapability, which is a long way. Fortunately, STA allows queries like

Actuators?$filter=TaskingCapabilities/Thing/Datastreams/Sensor/name eq 'MyName'

So if you give the Actuator and Sensor entities the same name, finding them is trivial. But this is also why I suggested #143

In most cases I do not make a Thing for my Sensors. One example of a use case where a Sensor is represented as both a Thing and a Sensor is in our Building management use case, since there some measurements are specific to the sensor (like Battery level) and some measurements are specific to the room the sensor is currently in (like Temperature). At the same time, a sensor is sometimes moved to a different room, and it is possible for different Sensors that measure the same properties to have been in the same room. The Sensor-Thing and the Room-Thing are linked through their common Location. So for the sensor (device) to find the temperature Datastream for the room it is currently in, it does the query

Datastreams?$filter=
  Sensor/properties/sensorId eq '{{dev-uuid}}'                                    -- Only Datastreams with me as a Sensor
  and ObservedProperty/definition eq '{{observedProperty}}'                     -- And the correct ObservedProperty
  and Thing/Locations/Things/properties/sensorId eq Sensor/properties/sensorId  -- Attached to a Thing currently in the same location as my Sensor-Thing

I think that is about the worst-case scenario when it comes to this Sensor, Sensor-Type, Thing, Deployment conundrum. That use-case would really benefit from the Deployment concept, but thanks to powerful queries it still works :)

Another conundrum is that in many use cases in the environmental domain the Sensor entities are sensor types, not sensor instances, and these types are shared among all Datastreams that are measured using a sensor of that type. For instance, I have a bunch of DHT22s in my house, but I have no further data on each sensor other than that it is a DHT22. So there is no point in making an entity for each individual Sensor.

Every data model choice has advantages and disadvantages... We may have to define domain-specific extensions to the data model that add extra entities and relations, as to not completely over-complicate the base model so it becomes useless for everybody.

[alexrobin]

Thanks for explaining everything in details. I see how it can work but there are quite a few implied things here that one needs to know to build these queries.

But anyway, I agree with you that each data model is going to have its own pros and cons. That is why I said in my email that maybe having two standards to access sensor data and metadata in slightly different way is not such a bad thing. As long as there are clear mapping between our API resources (which I would call an implementation model) and the OGC/ISO conceptual models, I think we're fine.