SSN Deploy

From Semantic Sensor Network Incubator Group
Revision as of 08:22, 14 June 2011 by Llefort (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Deployment


This section describes creating a Deployment instance for a System object. The ssn:System class is an abstraction for parts of a sensing infrastructure. The ssn:Sensor class in the ontology provides the structure to represent a concrete sensing object. Sensor can represent any object with the sensing capability (e.g., in some cases a human observer can be also a sensor). However, in many scenarios the sensors are devices. The ssn:Device class describes a device and inherits all the properties of the ssn:System class. The following provides an overview of the main classes and properties related to deployment of a network of sensors in the ontology. The classes and properties are shown in the Figure.

  • ssn:hasDeployment: Points to deployment description of sensor expressed as an instance of the ssn:Deployment class. The description of a Deployment refers to ssn:System and it is also a subclass of ssn:DeploymentRelatedProcess and inherits all the properties from this class.
  • The ssn:DeploymentRelatedProcess class groups various Processes related to Deployment. For example, it includes installation, maintenance and deployment features.
  • The ssn:System class for parts of a sensing infrastructure. A system has components, its subsystems, which are other systems. A system is deployed on a Platform.
  • ssn:deployedOnPlatform points to platform on which the system is deployed.
  • ssn:Platform includes different components that can be attached to Sensor and also different features such as measurement properties, operating properties and system settings.
  • ssn:deployedSystem provides relation between a deployment and a deployed system.


A concept map showing the relationships between Deployment, Platform and System

Figure 5.18 - ssn:Deployment

How to represent a deployment of a network of sensors?

Deploy example (OWL)



A deployment of a system is created by defining an instance of the ssn:Deployment class.

A Platform can be used for multiple sensors. In the following OWL example, the defined Platform handles two sensors participating in a deployment scenario and belonging to the same system. The system is a sensor network node (a "mote") which includes a Temperature sensor and a Humidity sensor (this is allowed because SensingDevice is a sub-class of System).

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy">
 ...
 <!-- Deployment -->
 <ssn:Deployment rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#ABC01Deployment">
  <ssn:deployedOnPlatform>
   <ssn:Platform rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#UNiS-TSBPlatform"/>
  </ssn:deployedOnPlatform>
  <ssn:deployedSystem>
   <ssn:System rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#SN-Node-TSB-ABC01">
    <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A deployment which includes a temperature and a humidity
    sensor on the same sensor network node.</rdfs:comment>
   </ssn:System>
  </ssn:deployedSystem>		
 </ssn:Deployment>
 <!-- Platform (and Operating conditions) -->
 <ssn:Platform rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#UNiS-TSBPlatform">
  <DUL:hasLocation>
   <DUL:PhysicalPlace rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#PhysicalPlace_UNiSTestBED-BA03A">
    <DUL:isLocationOf rdf:resource="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#UNiS-TSBPlatform"/>
   </DUL:PhysicalPlace>
  </DUL:hasLocation>
  </ssn:Platform>
  <!-- System (TelosB Mote) -->
  <ssn:System rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#SN-Node-TSB-ABC01">
   <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A sample sensor network node. The data is for
   TELOS-B product and the data sheet is available at: http://www.willow.co.uk/TelosB_Datasheet.pdf </rdfs:comment>
   <ssn:hasDeployment>
    <ssn:Deployment rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#ABC01Deployment"/>
   </ssn:hasDeployment>
   <ssn:hasSubSystem>
    <ssn:SensingDevice rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#TemperatureSensor-TSB-ABC01">
     <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">The embedded temperature sensor. </rdfs:comment>
    </ssn:SensingDevice>
   </ssn:hasSubSystem>
  <ssn:hasSubSystem>
   <ssn:SensingDevice rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#HumiditySensor-TSB-ABC01">
    <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">The embedded humidity sensor.</rdfs:comment>
   </ssn:SensingDevice>
  </ssn:hasSubSystem>
 </ssn:System>
 <!-- Temperature sensor -->
 <ssn:SensingDevice rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#TemperatureSensor-TSB-ABC01">
  <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A specific instance of temperature sensor. </rdfs:comment>
  <ssn:hasDeployment>
   <ssn:Deployment rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#ABC01Deployment"/>
  </ssn:hasDeployment>
 <!-- Humidity sensor -->
 <ssn:SensingDevice rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#HumiditySensor-TSB-ABC01">
  <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A specific instance of humidity sensor. </rdfs:comment>
  <ssn:hasDeployment>
   <ssn:Deployment rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#ABC01Deployment"/>
  </ssn:hasDeployment>
 </ssn:SensingDevice>
 

PlatformSite

PlatformSite module



The SSN ontology defines relationships between classes such as Deployment, System and Platform. However it does not provide some aspects such as spatial attributes for the Platform class. There are three options to represent locations.

When the DOLCE Ultra Lite alignment is enforced, a Platform is a DUL:Physical:Object and as such may have a DUL:hasLocation relation to a DUL:PhysicalPlace location. A PhysicalPlace is an abstraction of a real-world place. Hence, this option allows statements like: the sensor/platform hasLocation the eastern edge of the lake; the sensor/platform hasLocation room S323; the sensor/platform hasLocation car123; and the like.

As well as the relative locations above, DOLCE Ultra Lite also allows absolute locations. The location of an entity is an observable aspect of the entity and is thus a ssn:Property, properties have values (ssn:hasValue), represented as regions, in this case a DUL:SpaceRegion. Hence, a sensor or platform can be given, for example, an absolute latitude and longitude, a location relative to another co-ordinate, or any other sort of value for location. Of course, if this method is to be used often, sub properties of hasValue could be defined (e.g. hasLatLong, hasAbsoluteLocation, hasCoordinates, etc) to provide descriptive names for locations, depending on the method used.

The third option is to define or import a further method for representing locations.

Relative locations are shown in the Figure 5.19.


A concept map showing how to specify a Deployment at a particular site

Figure 5.19 - Using ssn:Platform in conjunction with dul:PhysicalPlace

How to represent a site?

PlatformSite example (OWL)



The following example shows how location attributes are defined for a platform by using concepts from the DOLCE Ultra Lite ontology.


 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy">
 ...
 <ssn:Platform rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#UNiS-TSBPlatform">
  <DUL:hasLocation>
   <DUL:PhysicalPlace rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#PhysicalPlace_UNiSTestBED-BA03A">
    <DUL:isLocationOf rdf:resource="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#UNiS-TSBPlatform"/>
   </DUL:PhysicalPlace>
  </DUL:hasLocation>
 </ssn:Platform>
 

OperatingRestriction

Operating Restriction module


The operational and survival restrictions can be described for System. The operational properties are referred to by using ssn:hasOperatingRange, which in turn ssn:hasOperatingPropertys such as Maintenance Schedule and Operating Power Range. The survival properties are referred to by using ssn:hasSurvivalRange and include properties (ssn:hasSurvivalProperty) such as Battery Life Time and System Life Time.

The main classes and properties to describe the Operating Restrictions for a system are shown in Figure 5.20.

A concept map showing how restrictions are defined using conditions and properties like system lifetime, maintenance schedule or operating power range

Figure 5.20 - ssn:OperatingRange and ssn:SurvivalRange

ssn:SurvivalRange describes environmental conditions to which a sensor can be exposed without causing damage: i.e., the sensor continues to operate as defined using MeasurementCapability. If, however, the SurvivalRange is exceeded, the sensor could be 'damaged' and MeasurementCapability specifications may no longer hold. ssn:SurvivalRange is related to ssn:SurvivalProperty class by using ssn:hasSurvivalProperty.

ssn:SurvivalProperty represents the attributes that describe extent of the useful life of sensors.

ssn:OperatingRange describes the environmental conditions and attributes of a system/sensor's normal operating environment. It is related to ssn:OperatingProperty by using ssn:hasOperatingPropery.

ssn:OperatingProperty describes characteristic of the environmental and other conditions in which the sensor is intended to operate. This includes features such as power ranges, power sources, standard configurations, and attachments.

An Operational Restriction can be defined in a condition. inCondition ssn:inCondition relates a MeasurementCapability to a Condition.

ssn:Condition specifies ranges for qualities that act as conditions on a system/sensor's operation. For example, the accuracy features of a sensor represented by SurvivalRange and OperatingRange (see the next section) are defined in a certain temperature (e.g. 25 degree Celsius).

How to represent operational and survival conditions?

Operating Restriction example (OWL)



The following example describes the operating power range restriction for a Sensor Node system.


 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy">
 ...
 <ssn:System rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#SN-Node-TSB-ABC01">
  <ssn:hasOperatingProperty>
   <ssn:OperatingPowerRange rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#TSBOperatingPowerRange">
    <ssn:hasValue>
     <DUL:Amount rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#Current_Draw_Idle">
      <DUL:hasDataValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">21 μA</DUL:hasDataValue>
       <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Current Draw in Idle mode</rdfs:comment>
       <DUL:isClassifiedBy>
        <DUL:UnitOfMeasure rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#microAmpere"/>
       </DUL:isClassifiedBy>
      </DUL:Amount>
     </ssn:hasValue>
    </ssn:OperatingPowerRange>
   </ssn:hasOperatingProperty>
  <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A sample platform description for sensors. 
  The data is for sample TELOSB sensors and the data sheet is available at: 
  http://www.willow.co.uk/TelosB_Datasheet.pdf</rdfs:comment>
 </ssn:System>
 

The usage of ssn:Condition is the same as for Measurement Capabilities. A more complete example is provided in the Condition module documentation page.