Deployments, Systems and Devices

Deployments and Systems

This page discusses the modelling of concepts related to deployments and system/device/deployment information.

For example, the page discusses how to model devices ‘deployed into the field’, including the temporal nature of this deployment: that is, the devices and systems in the deployment exist independent of the deployment and the deployment itself exists for some time. Also, issues such as the manufacturer, further documentation, construction materials, owner, model numbers, etc. will be discussed (note that these attributes are often relevant to both devices/systems and deployments).

Much of what we want to cover in this part of the development is already covered in the MMI device and platforms ontologies so we want to reuse as much as possible.

First we have the system and device concepts as they stand in the ontology

To which we investigate the idea of a platform. A platform being the physical thing to which a (sensing) system is attached. The MMI device ontology for example defines it as

physical entity upon which a component (such as a system) can be physically deployed

see MMI terms

For the moment a system can be attached to a platform, but we needn’t specify platforms further

The MMI platforms ontology already defines platforms and how they are attached to sensors (including the definition of many marine platforms). The relevant piece being

The simple extension of adding an onPlatform role to our ontology seems enough for the XG, but for real use tt seems that we can fairly easily reconcile the two, and thus get platforms for free, with the following alignments. (dotted lines indicate additions)

One problem is however that the MMI device ontology doesn’t yet recognise the MMI platforms ontology and the MMI Device Ontology Working Group hasn’t yet decided how to handle platforms. Thus far we aren’t sure how to align the MMI platform ontology, the MMI device ontology and our ontology.

The relevant part of the MMI device ontology is in the figure below. Note a deployment is taken as

“association of an entity to another entity (as for example, a device to a parent platform, or to an observation campaign), for a determinable period of time.”

Note that platforms and now connected to systems via deployments, so the alignment given above doesn’t seem to work anymore.

This isn’t to say that we can’t make use of this part of the MMI device ontology, we could roughly equate the MMI system to the SSN-XG System and then mimic the device ontology view of deployment, expecting that the MMI group will sort out the relation to platforms and that this could resolve in a way that we can still use.

The device ontology view places a Deployment as something quite different from a System, but it seems that often a deployment behaves very much as a system. It’s also not clear how and if there is a subDeployment relation that is important here.

It seems that one of the important aspects of a deployment is its temporal nature - that it exists for a period of time - and that it isn’t really an intrinsic thing, but such a deployment may still be a system and have subSystems etc, so one important aspect of the modelling is how to correctly capture these relations.

Deployments as Processes

The group's subsequent discussions on this topic began with MMI's definition

Deployment [1]: "association of an entity to another entity (as for example, a device to a parent platform, or to an observation campaign), for a determinable period of time."

and concluded from this that a ‘deployment’ is a process, “a process that happens to the installation”, i.e. putting the sensors out in the field

In terms of alignment to DOLCE this means: entity:sensor participatesIn process:deployment

The group also discussed that there are three good options for deployment

• the act of putting the system in the field
• the time the system is in the field
• the configuration of the system for that environment

There are also issues here of the relationship between the system lifetime and that of the constituent devices – i.e. is the scope of “one deployment” that of an individual sensor or a “whole” System constructed for on particular purpose?

The figure below is a suggestion that interprets a deployment as a process that really represents the lifetime of the deployment. That is, a DOLCE process that represents the evolving nature of the system through time. The idea is similar to how DOLCE would model the lifetime of a person as distinct from the person and how the person always exists, but will change over the course of that lifetime.  Another example is a car, for which the lifetime of the car is a process (it happens in time) and any point along that timeline there is an endurant, the car, participating in the process; but the endurant keeps changing, new wheels, etc.

For deployments it is similar - there is some concept of the deployment as beginning with installation (or commissioning), evolving as sensors are added or maintenance is carried out, and ending with removal (decommissioning). The identifiable processes that occur within the lifetime of the deployment are sub processes (part in DOLCE) and the sensors, etc are participants in the deployment.

The figure tries to illustrate this for a hypothetical deployment. Diamonds are individuals and ovals are concepts - ABox and TBox. Dotted arrows shows individuals as members of concepts and solid arrows show properties. The unfilled arrows are concept hierarchy.

The figure shows a sensor network, which was deployed. The main deployment is composed of of sub deployments at different sites. The sensor network has components, that were installed at the various sub deployments.

Not shown in the figure is that associated with a process is time information.