dca-idas device communication rest api€¦ · dca-idas device communication rest api date...

DCA-IDAS DEVICE

COMMUNICATION REST API

Date 2013-06-01

Autor DCA-IDAS Group, Telefonica I+D SAU

Edition 03.01 Rev. 00

FI-WARE / FI-PPP RESTRICTED

Table Index

3 de 74

1 INTRODUCTION .............................................................................................. 9

2 DEFINITIONS ............................................................................................... 10

2.1 URN ............................................................................................................................ 11 2.1.1 IDAS Namespace ........................................................................................................ 11 2.2 Xlink ........................................................................................................................... 12 2.3 Data types .................................................................................................................. 12 2.3.1 Numerical values ........................................................................................................ 13 2.3.2 Boolean values ........................................................................................................... 13 2.3.3 Temporary values ...................................................................................................... 13 2.3.4 Textual Values ........................................................................................................... 13 2.3.5 Geospatial values ....................................................................................................... 13 2.3.6 Values composition .................................................................................................... 14

3 A RESOURCE DESCRIPTION .......................................................................... 15

3.1 System ....................................................................................................................... 15 3.2 General information elements .................................................................................... 16 3.2.1 Description ................................................................................................................. 16 3.2.2 Name ......................................................................................................................... 16 3.2.3 Keywords ................................................................................................................... 16 3.2.4 Contact ...................................................................................................................... 17 3.2.5 Identification ............................................................................................................. 17 3.2.6 Classification .............................................................................................................. 18 3.3 Restrictive elements .................................................................................................. 18 3.3.1 Valid Time .................................................................................................................. 18 3.3.1.1 Deleting resources ........................................................................................................ 19 3.4 Functional descriptive elements ................................................................................. 20 3.4.1 Characteristics ........................................................................................................... 20 3.4.2 Capabilities ................................................................................................................ 21 3.4.3 Parameters ................................................................................................................ 22 3.4.4 Inputs ........................................................................................................................ 22 3.4.5 Outputs ...................................................................................................................... 23 3.4.6 Components ............................................................................................................... 24

Index (cont.)

4 de 74

3.5 Spatial and temporal description elements ................................................................ 25 3.5.1 SpatialReferenceFrame .............................................................................................. 25 3.5.2 TemporalReferenceFrame .......................................................................................... 26 3.5.3 Position ...................................................................................................................... 26 3.5.4 TimePosition .............................................................................................................. 27

4 RESOURCE MEASURES .................................................................................. 28

4.1 Observation ............................................................................................................... 28 4.1.1 SamplingTime ............................................................................................................ 28 4.1.2 Procedure .................................................................................................................. 29 4.1.3 ObservedProperty ...................................................................................................... 29 4.1.4 FeatureOfInterest ...................................................................................................... 29 4.1.5 Parameter .................................................................................................................. 29 4.1.6 Result ......................................................................................................................... 30 4.1.6.1 Measures serie ............................................................................................................. 30

5 LIGHTWEIGHT PROTOCOL ............................................................................ 34

5.1 URN in reduced format ............................................................................................... 34 5.2 Data types .................................................................................................................. 34 5.2.1 Numeric values .......................................................................................................... 34 5.2.2 Boolean values ........................................................................................................... 35 5.2.3 Time values ................................................................................................................ 35 5.2.4 Textual values ............................................................................................................ 35 5.2.5 Geospatial values ....................................................................................................... 36 5.2.6 Values composition .................................................................................................... 36 5.3 Record operation ........................................................................................................ 36 5.3.1 Resource description .................................................................................................. 36 5.3.1.1 Description .................................................................................................................. 36 5.3.1.2 Name .......................................................................................................................... 37 5.3.1.3 Contact information ...................................................................................................... 37 5.3.1.4 Keywords .................................................................................................................... 37 5.3.1.5 Characteristics ............................................................................................................. 37 5.3.1.6 Identification ............................................................................................................... 37 5.3.1.7 Classification ................................................................................................................ 38 5.3.1.8 Resource validity .......................................................................................................... 38

Index (cont.)

5 de 74

5.3.1.9 Capacities .................................................................................................................... 38 5.3.1.10 Observed physical phenomena ....................................................................................... 38 5.3.1.11 Measured physical phenomena ....................................................................................... 38 5.3.1.12 Parameters .................................................................................................................. 39 5.3.1.13 Spatial position ............................................................................................................ 39 5.3.1.14 Temporal position ......................................................................................................... 39 5.3.1.15 Components ................................................................................................................ 39 5.4 Measure publication operation ................................................................................... 40 5.4.1 Description of an observation .................................................................................... 40 5.4.1.1 Observation time. ......................................................................................................... 41 5.4.1.2 Observed phenomenon .................................................................................................. 41 5.4.1.3 Parameters .................................................................................................................. 41 5.4.1.4 Measured value ............................................................................................................ 41 5.4.2 Observation description in super-small format. .......................................................... 42

6 PROTOCOLS .................................................................................................. 44

6.1 Registration request .................................................................................................. 44 6.2 Measure notification request ...................................................................................... 47 6.3 Commands and actions .............................................................................................. 49 6.3.1 SET/GET default commands ....................................................................................... 50 6.3.2 Specific commands ..................................................................................................... 51 6.3.3 Commands responses ................................................................................................ 52 6.3.4 Commands by polling from devices ............................................................................ 53 6.3.5 Updating command URL of device .............................................................................. 54 6.3.6 API-KEY ..................................................................................................................... 54

A IDAS NAMESPACES URNS ............................................................................. 55

B APLICATION NOTES ..................................................................................... 63

C REQUIREMENTS ............................................................................................ 64

D EXAMPLE ...................................................................................................... 65

D.1 Weather station description ....................................................................................... 65 D.2 Weather station measure ........................................................................................... 69

E IDAS PROTOCOL SCHEME ............................................................................. 72

Index (cont.)

6 de 74

Table Index

7 de 74

Tabla 1. ObjectType field identifiers of a URN ......................................................... 55

Tabla 2. Identifiers .................................................................................................. 55

Tabla 3. Classifiers .................................................................................................. 56

Tabla 4. Properties .................................................................................................. 56

Tabla 5. Coordinates systems .................................................................................. 58

Tabla 6. Reference Coordinates System .................................................................. 58

Tabla 7. Reference Temporal Systems ..................................................................... 58

Tabla 8. Temporal systems ...................................................................................... 58

Tabla 9. Physical phenomena .................................................................................. 59

Tabla 10. Measurement units .................................................................................... 61

Index

¡Error! No se encuentra el origen de la referencia.

8 of 74

Figure 1. Register Sensor request flow ........................................................................ 46

Figure 2. InsertObservation request flow .................................................................... 49

9 of 74

1 INTRODUCTION

This document describes the mechanism for the representation of contextual information in Intelligent Data Advanced Solution (IDAS) that makes available information from heterogeneous networks and formats to applications and services in a single format.

Chapter 2 presents the basic definitions used in the architecture of IDAS and will serve to justify the chosen model, especially in regard to the organization of information and the entities that are modeled.

Chapter 3 describes the SensorML model elements to be used in the description of resources.

Chapter 4 describes the elements that are used to generate an observation or measurement from the described resources.

Chapter 5 describes a lighter alternative to both the resource description and for the sending of measured values.

Chapter 6 explains the protocol on which resource description and send measurements or observation operations are performed.

10 of 74

2 DEFINITIONS

This section describes the concepts and terms that are considered to define the information model in the domain of the IDAS.

Gateway

In general, the integration between networks of sensors and actuators and IDAS are performed through communication access points from both environments. The gateway is the boundary element of IDAS platform with the devices.

Hub

For networks of sensors and actuators, a functional element called hub will allow communications to and from the network or networks of controlled sensors and actuators.

Physically, a hub can be any element that enables communications over an IP packet network and it acts as an interface for sensors and actuators. A physical device can bring together various functional elements (e.g. a counting device with a GPRS modem that allows the transmission of meter readings, will also act as the hub of a sensor network consisting of a single sensor device).

In the ecosystem of the network of sensors and actuators are distinguished the following functional elements represented in the information model of the IDAS.

System

It is an element that consists of the aggregation of other elements and can be described as a composition of other resources. For example, weather station, a car, etc.

Node

It is an element capable of communication in the environment of sensors and actuators network. The coordinators of a wireless sensor network or ZigBee router are examples of nodes. They may contain other functional elements, the previously described case of a counter with GPRS modem is an example that brings together in one physical device a hub, node and sensor.

Sensor

Element (physical or not) that is able to analyze its surroundings and obtain measurements of some property of the environment. It is part of a node.

Actuator

Element (physical or not), able to modify some property of the environment. It is part of a node.

11 of 74

Although, in general, a sensor or an actuator only make sense while integrated into an element with communication capacity (node) is not necessary to describe this relationship in the information model of the IDAS.

The ability of homogeneous description of the sensing devices and actuators, the publication of measures and the possibility of action does not require knowledge of the nodes that integrate sensing devices and actuators.

The devices that integrate sensor and actuator type functions must be decomposed into atomic resources (sensors and actuators), which would be the ones that will be managed in the domain of the IDAS.

2.1 URN

The descriptions of resources in the domain of IDAS are based on a family of concepts and terms (identifiers, classifiers, etc.). IDAS provides identifiers for concepts and definitions that specify an action following a URN scheme. The URN syntax is useful because it provides persistent identifiers regardless of the location of the resource and supports a web context.

The RFC 2141 describes in BNF the URN syntax as: <URN> ::= “urn:” <NID> “:” <NSS>, where <NID> is the Namespace Identifier and <NSS> is the URN specific syntax within the Namespace Specific String.

urn:ogc:{category.label}:{ResourceSpecificString}

The used namespace used by IDAS is defined as OGC© 07-092 Definition identifier URNs in OGC namespace.

urn:x-ogc:def:objectType:authority:version:code

The objectType part will be used to specify the concept type identified by URN, being able to define particular concepts for the IDAS domain plus the defined by OGC®. When the description of a resource requires a concept to complete this description in the domain of IDAS, and this concept is not defined by the recommendations of OGC®, it will be created in the IDAS domain.

The Authority part will be the identification of the organization that specifies the definition. In the domain of IDAS, the authority for the used definitions will be an unregistered authority and will be identified by IDAS.

The optional version part identifies the version within the domain of the definition authority.

The code part is the definition identifier assigned by the authority.

2.1.1 IDAS Namespace

The IDAS namespace is the set of concepts or terms defined in the domain of the platform. These concepts or definitions are identified by the urn in the format indicated above.

This namespace is completely flexible and can incorporate new concepts or terms.

12 of 74

The concepts associated with identification, classification, physical phenomena and measurement units are mandatory because they affect current or future functionality of the platform.

There may be used other concepts beyond those defined in the IDAS namespace, whenever they follow the urn format, and identify an authority that must not be IDAS. As a relevant example we can show that the definition of most parameters associated with a resource is relevant to the resource reporter and to the application that uses it, but not for the platform. For example, to indicate that a resource managed by XXX companyhas an YYY parameter will be identified as:

urn:x-ogc:def:property:XXX:1.0:YYY

2.2 Xlink

To understand some of the elements and/or attributes used to describe resources is necessary to understand the use of Xlink components - Xlink defines attributes and how the elements containing them should use them – and their use in the descriptions by reference, which allows re-use of objects defined in the document itself or in external documents.

Object references are made using URIs (URL or URN). The use of a reference implies that it is a resource (in the W3C sense) remote, despite being in the same document as the local resource (described by value).

xlink:href

URI of the resource where the value for the described element or property can be found.

xlink:role

URI of the resource that describes the nature or type of described element.

xlink:arcrole

URI of the resource that describes the nature of the relationship or association (link) between the described element and the remote resource.

It’s important to note, that an URI could be used to identify the value of a property. The xlink attribute value indicates where to get a description or definition the attribute.

These attributes are used properly according to the needs of different XML documents managed by the platform.

2.3 Data types

We describe the data types used to describe values.

13 of 74

2.3.1 Numerical values

Numerical values are represented as real numbers with the swe:Quantity element. The definition attribute is, in general, a basic phenomenon or physical property representing their significance. For example, if a resource measures the wind speed, the swe:Quantity element representing it will be of urn:x-ogc:def:phenomenon:IDAS:1.0:velocity type.

If it is a numeric value with units, includes a swe:uom element. From an external element to the platform (eg a hub) it has been choosen to use the xlink:href attribute and indicate the URN assigned to the unit of measure. This avoids the direct use of the code or symbol for the unit indicated by the external element, generates inconsistencies in the definitions of symbols assigned by the platform to the units of measurement.

The value is indicated in the swe:value element.

A range of numeric values are described with swe:QuantityRange and the value is a pair of numbers separated by a space.

This element may contain an optional <gml:name> element that allows including additional application information.

2.3.2 Boolean values

The representation of Boolean values is carried out with the swe:Boolean element that have a definition attribute. The value is represented in the swe:value element as false or true.


2.3.3 Temporary values

They are represented by the swe:Time (definition attribute available) element. Includes the ability to describe the unit with swe:uom (see 2.3.1) and the value represented with swe:value can be either ISO8601 or decimal value to represent a relative time.

It is also possible to describe a range of times with swe:TimeRange.


2.3.4 Textual Values

They are represented by swe:Text (optionally with the definition attribute) and the swe:value element.


2.3.5 Geospatial values

They are represented by swe:Position. See 3.5.3 example.

14 of 74

The position has two possible components, swe:location and swe:orientation. Each of these components is a swe:Vector indicating the coordinates of each element.

If the reference system is common for both elements, it can be specified in the swe:Position (localFrame and referenceFrame) element. If the reference system is different, the swe:Vector component has these attributes to separate the reference from the location and orientation.

2.3.6 Values composition

There will be used the swe:DataRecord type because it is the most general. <swe:DataRecord> <swe:field xlink:href="urn" name="Campo 1"/> <swe:field name="Campo 2" xlink:href="urn"/> </swe:DataRecord>

In each field we can indicate any of the above types. In general, the xlink:href attribute indicates a URN for the property to which the swe:field element refers. The name field could be changed by the platform with one set to the referenced URN.

15 of 74

3 A RESOURCE DESCRIPTION

This chapter describes the model used to describe resources in the IDAS domain. The used language is SensorML.

The general scheme for the description of a resource in the IDAS domain is as follows: <sml:System> <gml:description/> <gml:name/> <sml:keywords/> <sml:identification/> <sml:classification/> <sml:validTime/> <sml:characteristics/> <sml:capabilities/> <sml:contact/> <sml:spatialReferenceFrame/> <sml:temporalReferenceFrame/> <sml:position/> <sml:timePosition/> <sml:inputs/> <sml:outputs/> <sml:parameters/> <sml:components/> </sml:System>

This scheme is the more comprehensive description of a resource in the IDAS domain. The following describes the various elements and identifies the required ones.

3.1 System

Any resource that is defined in the domain of Ambient Intelligence Platform should be described using SensorML within one sml:System element. This item is considered the more general model to describe any resources because it allows including components that do not have its own entity outside.

However, you can choose to use this element for individual descriptions of resources (sensors and actuators).

The following paragraph provides an example of tags among which it is described the System element.

<sml:System gml:id="f81d4fae-‐7dec-‐11d0-‐a765-‐00a0c91e6bf6" xsi:schemaLocation="http://www.opengis.net/sensorML/1.0.1 system.xsd" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:swe="http://www.opengis.net/swe/1.0" xmlns:gml="http://www.opengis.net/gml" xmlns:sml="http://www.opengis.net/sensorML/1.0.1" xmlns:xsi=http://www.w3.org/2001/XMLSchema-‐instance Descripción </sml:System>

16 of 74

It is interesting to comment on the existence of a mandatory gml:id attribute that is a unique identifier within the XML document and in the domain of the IDAS unique character extends to all levels of the domain. An alternative to having a unique “universal” value is to use a Universally Unique Identifier (UUID) generator.

3.2 General information elements

These elements carry out, within the XML document, a presentation of the described resource. However, we must not underestimate some of these elements as they could be a possible first criterion in the process of resource discovery.

3.2.1 Description

Corresponds to the namespace of Geographic Markup Language and contains a textual description or a reference to that description.

The following paragraphs show examples of a description by reference and an online description.

<gml:description xlink:href="http://host:8080/nodo.xml"> </gml:description>

In the above example the description can be found in the URI specified in the xlink:href attribute.

<gml:description> Temperature and light measurement node </gml:description>

3.2.2 Name

It contains a descriptive name. CodeSpace optional attribute allows to indicate a dictionary or authority in whose area is defined the value of this element.

<gml:name codeSpace="TID">Nodo-‐1234</gml:name>

In this example it is named Node-1234 taken from the naming rules of the TID authority.

3.2.3 Keywords

It contains key terms to facilitate rapid discovery of the resource. These terms are grouped in a list for an optional codeSpace to indicate, for example, a dictionary where to find rules or options for the interpretation of the indicated values .

<sml:keywords> <sml:KeywordList codeSpace="TID"> <sml:keyword>IDAS</sml:keyword> <sml:keyword>Ligth</sml:keyword> <sml:keyword>Temperature</sml:keyword>

17 of 74

<sml:keyword>Ambient</sml:keyword> </sml:KeywordList> </sml:keywords>

3.2.4 Contact

The sml:contact element allows to include information on responsibility for the described resource or indicate the type of relation that a person or an organization has with the resource. Is an element that can be found many times to define several types of contact and can also include a list of members for one type of contact.

The following example defines an “owner” type sml:contact. The features or semantic of this type will be defined by the URN of the xlink:arcrole attribute. It uses the sml:onlineResource element to indicate a resource that identifies the sml:contact.

<sml:contact xlink:arcrole="urn:owner"> <sml:ResponsibleParty> <sml:organizationName>Instituto para la conservación de la Naturaleza </sml:organizationName> <sml:contactInfo> <sml:onlineResource xlink:href="urn:ICONA"/> </sml:contactInfo> </sml:ResponsibleParty> </sml:contact>

In the current version, special IDAS concepts (URNs) are not defined in the domain to identify different types of sml:contact elements.

3.2.5 Identification

The sml:identification element is mandatory and provides a list of different ways to identify a resource by sml:identifier. This information is useful for resource discovery functions. The sml:Term definition attribute of provides a link to the semantics of the identifier.

See Tabla 2.

In this example a resource is identified with a SerialNumber element.

<sml:identification> <sml:IdentifierList> <sml:identifier name="Serial Number"> <sml:Term definition="urn:x-‐ogc:def:identifier:IDAS:1.0:serialNumber"> <sml:value>24FG5467M </sml:value> </sml:Term> </sml:identifier> </sml:IdentifierList> </sml:identification>

GlobalIdentifier is used for unique identification of a resource within the platform and contains a part generated by the platform and a part given by one of the identifiers in the table above.

18 of 74

They must ensure that the hub under which they are is able to route them. For example, a resource identified by LocalIdentifier will be identified on the platform so it is routed to the appropriate gateway and the hub. The hub should be able to route the LocalIdentifier resource.

Identifiers able to be used for the generation of globalIdentifier must not contain blank spaces.

Identifiers able to be used for the generation of globalIdentifier must be universally unique.

The Universal Identifier of Logical Hub is needed to identify the logical hub (may coincide with a physical hub) to facilitate the identification of mobility devices and avoid inconsistencies due to changes in other properties, such as dynamic IP addresses. It must be universally unique. They should be provided both in resource descriptions (RegisterSensor) and publication of measures (InsertObservation).

If it is not provided, the identification of concentrators is undertaken by the IP from which the message arrives to the IDAS gateway.

3.2.6 Classification

The sml:classification element is mandatory and provides a list of values that establish resource groups and are used for resource discovery. Through a list of sml:classifier. The sml:Term definition attribute provides a link to the semantics of the classifier.

See Tabla 3

In the following example, a resource is classified according to sensor type.

<sml:classification> <sml:ClassifierList> <sml:classifier name="Sensor Type"> <sml:Term definition="urn:x-‐ogc:def:classifier:IDAS:1.0:sensor"> <sml:value>termometro</sml:value> </sml:Term> </sml:classifier> </sml:ClassifierList> </sml:classification>

3.3 Restrictive elements

This group of elements includes the ones describing limitations or restrictions on the SensorML document.

3.3.1 Valid Time

This element limits the validity of the document and the description included in a time frame. This time frame may be a moment or a period of time.

19 of 74

The indication of a moment in time is performed through the gml:TimeInstant element containing a gml:timePosition element. The indication of a period will be made with gml:TimePeriod, containing the gml:beginPosition and gml:endPosition elements. The format for describing time properties follows the rules specified in ISO-8601. There is an optional attribute to indicate non exact time positions (now, after, before, unknown).

The following example defines validity to the moments after 13:20:20 on September 25, 2008.

<sml:validTime> <gml:TimeInstant> <gml:timePosition indeterminatePosition="after">2008-‐09-‐25T13:20:20

</gml:timePosition> </gml:TimeInstant> </sml:validTime>

The following example shows a time of validity for a period of time after the date specified in gml:beginPosition to date.

<sml:validTime> <gml:TimePeriod>

<gml:beginPosition indeterminatePosition="after">2008-‐09-‐25T13:20:20 </gml:beginPosition>

<gml:endPosition indeterminatePosition="unknown"/> </gml:TimePeriod> </sml:validTime>

3.3.1.1 Deleting resources

The deletion of resources is done through RegisterSensor message processing. A RegisterSensor message updates the description of the sml:System element. Therefore, a RegisterSensor message which describes an already registered sml:System element but modifying such description may be used to remove previously registered resources.

If the aim is the elimination of a complete sml:System element, the procedure is based on sending a RegisterSensor of an already registered sml:System element but with the sml:validTime field reflecting the end of the validity of the sml:System element.

It mustn't be used the possible sml:validTime element of each component (if any) to delete individual components.

In the following example it’s set through gml:TimeInstant in sml:validTime the end of the validity of the resources associated with the sml:System:element

<sml:validTime> <gml:TimeInstant> <gml:timePosition indeterminatePosition="before"/>

20 of 74

</gml:TimeInstant> </sml:validTime>

There is no indication of value in gml:timePosition, so the indeterminatePosition=”before” attribute is interpreted as a “before the present time” validity.

In the following example it’s set through gml:TimePeriod in sml:validTime the end of the validity of the resources associated with the sml:System:element

<sml:validTime> <gml:TimePeriod> <gml:beginPosition indeterminatePosition="unknown"/> <gml:endPosition indeterminatePosition="now"/> </gml:TimePeriod> </sml:validTime>

If the indeterminatePosition attribute of gml:endPosition is “now”, it will be interpreted as “the end of validity is now.”

3.4 Functional descriptive elements

This section presents the elements that make a functional description, andthat allows to have knowledge about the capabilities of the described resource.

The defined URNs are the ones considered in the current version and although their description is made on certain elements, they are defined as property, so they could be used in the elements as necessary. Thus, a URN defined at parameters, could be used in the capabilities element.

3.4.1 Characteristics

The sml:characteristics element will be used to describe the properties or attributes of the described resource that are fixed or do not affect the operational behavior of the resource. Physical properties such as weight, dimensions, construction materials, etc. do not vary for a given resource and do not represent specific attributes that determine their behavior.

Since these are general properties, or extensible to other types of resources they could lose their value as elements to be considered in the criteria and process of resource discovery.

It is represented by swe:DataRecord. This element includes a definition attribute that indicates through a URI (URL or URN) the semantics of the described property. The swe:DataRecord element contains elements of swe:field type.

The nature of the properties described in this element should not require very complex semantics.

The multiplicity of this element allows carry out groups of properties.

See Tabla 4

21 of 74

<sml:characteristics> <swe:DataRecord> <swe:field name="Supply Voltage"

xlink:href=”urn:x-‐ogc:def:property:IDAS:1.0:dcVoltage”> <swe:Quantity

definition="urn:x-‐ogc:def:phenomenon:IDAS:electricPotential"> <swe:uom xlink:href=”urn:x-‐ogc:def:uom:IDAS:1.0:volt"/> <swe:value>5.5</swe:value> </swe:Quantity> </swe:field> </swe:DataRecord> </sml:characteristics>

3.4.2 Capabilities

The sml:capabilities element follows a structure similar to the described for the sml:characterisitcs element. Its semantics vary if this element is used to describe fixed operational properties, for example, quality tolerance, accuracy, etc. This element also supports multiplicity in order to perform grouping of these capabilities.

See Tabla 4

The following example describes the operational capabilities of a resource. Describes the range of temperatures and is capable of measuring the resolution of the device.

<sml:capabilities> <swe:DataRecord> <swe:field name="Dynamic Range"

xlink:href="urn:x-‐ogc:def:property:IDAS:1.0:operatingRange"> <swe:QuantityRange

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"> <swe:uom code=”urn:x-‐ogc:def:uom:IDAS:1.0:celsius”/> <swe:value>-‐30 +70</swe:value> </swe:QuantityRange> </swe:field> <swe:field name="Resolution"

xlink:href="urn:x-‐ogc:def:property:IDAS:1.0:resolution"> <swe:Quantity

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"> <swe:uom code=” urn:x-‐ogc:def:uom:IDAS:1.0:celsius”/> <swe:value>0.1</swe:value> </swe:Quantity> </swe:field> </swe:DataRecord> </sml:capabilities>

22 of 74

Note that it uses the xlink:href attribute to identify the type of property (capability) referred to the defined element.

3.4.3 Parameters

The sml:parameters element will be used to describe attributes or properties that can be viewed or modified and it would act on the operating behaviour of the resource.

The description of the parameters allows the identification of the possible actions on them and their role in the IDAS domain. In general, the definition of the parameter is included in the xlink:href attribute, the xlink:arcrole attribute will be used to define the access type of the parameter and the xlink:role attribute determines the role of the parameter in the behavior of the resource.

See Tabla 4

As a general rule, the definition of a parameter as configuration involves a read-only access, and the definition of a parameter as the operation involves a read-write access (configurable parameter).

For an actuator, the parameter that determines action should be described as operation Property.

It is important to determine the parameter(s) to identify the measures that will enable a sensor and (if required) send measurement requests to resources.

<sml:parameters> <sml:ParameterList> <sml:parameter name="Report Interval"

xlink:href="urn:x-‐ogc:def:property:IDAS:1.0:reportInterval" xlink:arcrole="urn:x-‐ogc:def:property:IDAS:1.0:readwrite" xlink:role=”urn:x-‐ogc:def:property:IDAS:1.0:operationProperty”>

<swe:Quantity definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:time"> <swe:uom code="urn:x-‐ogc:def:uom:IDAS:1.0:second"/> <swe:value>30000</swe:value> </swe:Quantity> </sml:parameter> </sml:ParameterList> </sml:parameters>

3.4.4 Inputs

The sml:inputs element is mandatory and it describes the properties that are the entries in the transformation process that performs a resource. In general, a sensor takes as input a physical phenomenon and an actuator takes as input a physical phenomenon, a digital signal or a quantification of the mentioned signal.

The idea behind the definition of these elements in the SensorML specification, because only sml:input elements defined at sml:System level must be accessible by external applications.

23 of 74

This means that if we want that a sml:input element of a component can be accessible is necessary to include it among the list of sml:input of sml:System.

Generally, and without limiting the components of a system to sensors and actuators, each sml:input element can be described with a swe:ObservableProperty element to identify by reference (definition attribute) the type of property or measurable elements representing digital signal input through swe:Quantity, swe:Count elements, etc. The latter would be the case that represents the sml:input elements of an actuator.

An example for a sensor:

<sml:inputs> <sml:InputList> <sml:input name="Temperatura"> <swe:ObservableProperty

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"/> </sml:input> </sml:InputList> </sml:inputs>

An example of an actuator:

<sml:inputs> <sml:InputList> <sml:input name="Temperatura"> <swe:Quantity

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"> <swe:uom code="Cel"/> </swe:Quantity> </sml:input> </sml:InputList> </sml:inputs>

See Tabla 9 and Tabla 10.

3.4.5 Outputs

The sml:outputs element is mandatory and describes the properties that are the outputs of the transformation process that performs an action. In general, the output of a sensor is a digital number representing the quantification of the input physical phenomenon, and output of an actuator is usually a physical phenomenon in response to the input.

The idea behind the definition of these elements in the SensorML specification is that only sml:output elements defined at sml:System level must be accessible by external applications.

24 of 74

This means that if we want that a sml:input element of a component can be accessible is necessary to include it among the list of sml:input of sml:System.

Generally, and without limiting the components of a system to sensors and actuators, each sml:input element can be described with a swe:ObservableProperty element to identify by reference (definition attribute) the type of property or measurable elements representing digital signals input through swe:Quantity, swe:Count elements, etc. The latter is the case to represent the sml:input elements of an actuator.

For example, a temperature measuring sensor generates the following output

<sml:outputs> <sml:OutputList> <sml:output name="Temperatura"> <swe:Quantity

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:celsius"/> </swe:Quantity> </sml:output> </sml:OutputList> </sml:outputs>

The actuator of the above example will have as output a modified phenomenon, physical property or temperature,

<sml:outputs> <sml:OutputList> <sml:output name="Temperatura"> <swe:ObservableProperty

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"/> </sml:output> </sml:OutputList> </sml:outputs>


3.4.6 Components

The sml:components element describes all processes or elements that are sources of data for the described resource, either by reference or inline. They can be atomic elements or elements that contain components (sml:Component or sml:System).

This element is used when the sml:System element describes a resource that is not atomic and is made up of other resources (that, for some reason) are not described individually.

25 of 74

The outline of the description of components is:

<sml:components> <sml:ComponentList> <sml:component name="Termometro"> <sml:Component> <sml:identification/> ver 3.2.5 <sml:classification/> ver 3.2.6 <sml:capabilities/> ver 3.4.2 <sml:position/> ver3.5.3 <sml:timePosition/> ver 3.5.4

<sml:inputs/> ver 3.4.4 <sml:outputs/> ver 3.4.5

<sml:parameters/> ver 3.4.3 </sml:Component> </sml:component> </sml:ComponentList> </sml:components>

3.5 Spatial and temporal description elements

This section describes the elements of a SensorML document used to describe spatial properties, and are essential for applications based on geographic location.

3.5.1 SpatialReferenceFrame

The sml:spatialReferenceFrame element allows to define a local reference coordinate system through the gml:EngineeringCRS element and can be used for fixed and mobile systems. They include the gml:id attribute in gml:EngineeringCRS to identify this reference system in describing relative positions.

This element is to describe a local or contextual system in a way that, once defined a global position, other positions are identified regarding this position. It is the case of a system with several sensors. For example, an aircraft equipped with GPS to obtain the global position of the aircraft and other sensors are positioned relative to the position of the GPS as the source of a local system of reference.

We can say that a gml:EngineeringCRS is basically composed of a name, a coordinate system and datum indicating the start of the reference system in the indicated coordinate system.

This example identifies a reference coordinate system (WeatherStation_1_CRS) using it’s own coordinate system. This will be the reference system for positioning components inside the system.

<sml:spatialReferenceFrame> <gml:EngineeringCRS gml:id="WeatherStation_1_CRS"> <gml:srsName>WeatherStation_1_CRS</gml:srsName> <gml:usesCS xlink:href="urn:x-‐ogc:def:cs:IDAS:1.0:cartesian3D"/> <gml:usesEngineeringDatum> <gml:EngineeringDatum gml:id="WeatherStation_1_Datum">

26 of 74

<gml:datumName> Datum para la EM WeatherStation_1

</gml:datumName> <gml:anchorPoint>

El origen de la EM está situado en la posición del GPS incorporado. </gml:anchorPoint>

</gml:EngineeringDatum> </gml:usesEngineeringDatum> </gml:EngineeringCRS> </sml:spatialReferenceFrame>


3.5.2 TemporalReferenceFrame

This element allows to define a time origin, similar to as it is done in the case of spatial references described above.

<sml:temporalReferenceFrame> <gml:TemporalCRS gml:id="WeatherStation_1_TRS"> <gml:srsName>WeatherStation_1_TRS</gml:srsName> <gml:usesTemporalCS xlink:href="urn:x-‐ogc:def:ts:IDAS:1.0:piam"/> <gml:usesTemporalDatum> <gml:TemporalDatum gml:id="WeatherStation_1_TimeDatum"> <gml:datumName>

Datum Temporal WeatherStation_1 </gml:datumName>

<gml:origin> El origen temporal es el momento del registro de la estacion. </gml:origin>

</gml:TemporalDatum> </gml:usesTemporalDatum> </gml:TemporalCRS> </sml:temporalReferenceFrame>


3.5.3 Position

This element allows describing both location and orientation.

For the description of “absolute” positions it’s used a global referenceFrame, while the relative positions will use a local referenceFrame.

The position indicated in the resource description corresponds to the one the system or device has at that moment. When it comes to mobile devices, position, plus being part of the initial resource description, will also be described by elements input, output, parameter, etc. to determine what will form part of the measurements or observations of the resource.

27 of 74

In this example it’s described the position of a weather station in WSG84, assigning that global position (referenceFrame) as the origin of the local coordinate system (localFrame).

<sml:position name="WeatherStation Position"> <swe:Position localFrame="#WeatherStation_1_CRS" referenceFrame="urn:ogc:def:crs:IDAS:1.0:CRS84"> <swe:location> <swe:Vector

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:location"> <swe:coordinate name="latitud"> <swe:Quantity

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:latitude"> <swe:uom xlink:href=

"urn:x-‐ogc:def:uom:IDAS:1.0:degree"/> <swe:value>34.72450</swe:value> </swe:Quantity> </swe:coordinate> <swe:coordinate name="longitud"> <swe:Quantity

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:longitude"> <swe:uom xlink:href=

"urn:x-‐ogc:def:uom:IDAS:1.0:degree"/> <swe:value>-‐86.94533</swe:value> </swe:Quantity> </swe:coordinate> <swe:coordinate name="altitud"> <swe:Quantity

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:altitude"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:meter"/> <swe:value>0.0</swe:value> </swe:Quantity> </swe:coordinate> </swe:Vector> </swe:location> </swe:Position> </sml:position>

3.5.4 TimePosition

This element allows describing the temporary position.

For the description of “absolute” positions a global referenceFrame is used, while the relative positions will use a local referenceFrame.

<sml:timePosition name="WeatherStation Time Position">

<swe:Time referenceFrame="urn:x-‐ogc:def:trs:IDAS:1.0:ISO8601" localFrame="#WeatherStation_1_TRS">

<swe:value>2010-‐04-‐12T09:30:30.0</swe:value> </swe:Time> </sml:timePosition>

28 of 74

4 RESOURCE MEASURES

The measures or observations carried out by a resource follow the schemes defined in Observation and Measurements.

<om:Observation xsi:schemaLocation="http://www.opengis.net/om/1.0 observation.xsd"

xmlns:gml="http://www.opengis.net/gml" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:swe=http://www.opengis.net/swe/1.0.1 xmlns:om="http://www.opengis.net/om/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance">

<om:samplingTime/> <om:procedure/> <om:observedProperty/> <om:featureOfInterest/> <om:parameter/> <om:result/> </om:Observation>

4.1 Observation

This element encapsulates the description of a measurement or observation made by a resource.

4.1.1 SamplingTime

Indicates a point in time for measurement or observation. This moment in time can represent a point in time (gml:TimeInstant) or a time interval (gml:TimePeriod).

The following example shows a description of a point in time: <om:samplingTime> <gml:TimeInstant> <gml:timePosition

frame="urn:x-‐ogc:def:trs:IDAS:1.0:ISO8601">2010-‐04-‐14T11:29:47 </gml:timePosition>

</gml:TimeInstant> </om:samplingTime>

The following example describes a time interval: <om:samplingTime> <gml:TimePeriod> <gml:beginPosition frame="urn:x-‐ogc:def:trs:IDAS:1.0:ISO8601">

2010-‐08-‐05T12:23:03Z </gml:beginPosition>

<gml:endPosition frame="urn:x-‐ogc:def:trs:IDAS:1.0:ISO8601"> 2010-‐08-‐05T12:23:03Z

</gml:endPosition> </gml:TimePeriod> </om:samplingTime>

29 of 74

When we want to use mass publishing capabilities, the use of gml:TimeInstant in the om:samplingTime field will be required.

4.1.2 Procedure

This element indicates the measurement resource origin. It must be a previously described resource.

If the measure or observation origin resource is recorded as a System element, then the om:procedure element coincides with the registered element.

If the measure or observation origin resource is a component of an action described as System, then the om:procedure field contains a reference to the component.

<om:procedure xlink:href="WeatherStation_1.12345678"/>

4.1.3 ObservedProperty

Indicates the property or physical phenomenon for which it is providing a value.

Must match one of the inputs of the description fields and use the URN as reference.

<om:observedProperty

xlink:href="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"

/>

4.1.4 FeatureOfInterest

This field will be left unused in this version.

4.1.5 Parameter

This element allows entering additional information in the observation. A use example would be to have background information supplementing the measure.

With the xlink:href attribute we may indicate the definition of the described parameter. If it is a resource parameter, the xlink:href attribute must refer to the URN with which is described in the RegisterSensor message.

Supports data types listed in 2.3.

<om:parameter> <swe:Position/> </om:parameter>

30 of 74

This element is used to include an observation identifying logical hub. <om:parameter xlink:href=”urn:x-‐ogc:def:identifier:IDAS:1.0:UniversalIdentifierOfLogicalHub”> <swe:Text>

<swe:value>fghskghskghskghsdkhg</swe:value> </swe:Text>

4.1.6 Result

Contains the value generated by the om:procedure referenced for the referenced om:observedProperty.

<om:result> <swe:Quantity definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:celsius"/> <swe:value>17.4</swe:value> </swe:Quantity> </om:result>

4.1.6.1 Measures serie

It is possible to send a set of measurements or observations in a single InsertObservation message. To do this, this version of interface must meet the following requirements:

1. You can only send massive values observed for a single om:procedure and a single om:observedProperty. For example, you can not send observed values of temperature and velocity in the same InsertObservation message.

2. The data that make up the serie is organized into records. Each record corresponds to the data associated with a simple observation.

3. It is necessary to describe the record to carry out the correct interpretation of the data. 4. You should specify the number of records that comprise the data series 5. The sample time (om:samplingTime) will be an instant of time and in no case a period

of time.

The type to use for sending mass observed data corresponding to an om:procedure and om:observedProperty is swe:DataArray and to describe the format of massive data record is swe:DataRecord.

(In the example the texts are samples and are not required in any case). <swe:DataArray> <swe:elementCount>

31 of 74

<swe:Count> <swe:value>2</swe:value>

</swe:Count> </swe:elementCount> <swe:elementType name="Descripción de Registro"> <swe:DataRecord></swe:DataRecord> </swe:elementType> <swe:encoding>

<swe:TextBlock decimalSeparator="." blockSeparator="#" tokenSeparator="|"/> </swe:encoding> <swe:values>2|pepe#3|adiso</swe:values> </swe:DataArray>

We can distinguish the following elements:

• swe:elementCount: indicates the number of records that comprise the data set. It’s an integer type described by swe:Count.

• swe:elementType: element encapsulating the description of a data series record. For this description will be used the swe:DataRecord type.

• swe:encoding: indicates the way to process the data registry within a series. It uses swe:TextBlock. This type contains three attributes:

decimalSeparator: indicates the character used for the decimals representation.

blockSeparator: indicates the separator between records. It can contain up to 3 characters.

tokenSeparator: indicates the separator between record fields. It can contain up to 3 characters.

• swe:values: a series of records making up the observed values.

From the fields that make up a swe:DataRecord and that allow to assign each field of a record, we must identify the field that corresponds to om:observedProperty. The xlink:href attribute of swe:field of a swe:DataRecord that describes the observed value must match om:observedProperty.

If one of the fields in a record corresponds to the moment when the sample was taken, and in a single observation it would correspond to om:samplingTime, it is necessary to identify this field so that the platform can accommodate that value in the correct part of the message. Therefore, the xlink:href attribute of swe:field that describes the sample time will be the urn:

urn:x-ogc:def:property:IDAS:1.0:samplingTime

and may relate only to a point in time (gml:TimeInstant).

Fields described in swe:DataRecord that do not correspond with the om:observedProperty nor with om:samplingTime will be considered om:parameter of the observation.

All the swe:field elements have a mandatory name attribute that will be descriptive.

The following example defines the om:result to send 5 measures, separated by “|” character. Each measurement consists of 4 fields separated by the “,” character”. We use the “.” to indicate decimals. The first field of a record is om:samplingTime, the second is the om:observedProperty. The last two are the longitude and latitude of the position.

32 of 74

<om:result> <swe:DataArray> <swe:elementCount> <swe:Count> <swe:value>5</swe:value> </swe:Count> </swe:elementCount> <swe:elementType name="Registro de Datos Masivos"> <swe:DataRecord> <swe:field name=”Hora Muestra” xlink:href="urn:x-‐ogc:def:property:IDAS:1.0:samplingTime"> <swe:Time/> </swe:field> <swe:field name=”Fenomeno Observado” xlink:href="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"> <swe:Quantity definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:celsius"/> </swe:Quantity> </swe:field> <swe:field name="Location"> <swe:Position> <swe:location> <swe:Vector referenceFrame="urn:x-‐ogc:def:crs:IDAS:1.0:CRS84"> <swe:coordinate name="latitude"> <swe:Quantity definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:latitude"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:degree"/> </swe:Quantity> </swe:coordinate> <swe:coordinate name="longitude"> <swe:Quantity definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:longitude"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:degree"/> </swe:Quantity> </swe:coordinate> </swe:Vector> </swe:location> </swe:Position> </swe:field> </swe:DataRecord> </swe:elementType> <swe:encoding> <swe:TextBlock decimalSeparator="." blockSeparator="|" tokenSeparator=","/> </swe:encoding> <swe:values>2010-‐08-‐05T12:23:03Z,22.0,-‐77.8912,38.512|2010-‐08-‐05T12:24:03Z,25.0,-‐77.8912,38.512|2010-‐08-‐05T12:25:03Z,22.6,-‐77.8912,38.512|2010-‐08-‐05T12:26:03Z,26.0,-‐77.8912,38.512|2010-‐08-‐05T12:27:03Z,22.0,-‐77.8912,38.512</swe:values> </swe:DataArray>

</om:result>

33 of 74

Those parameters (om:parameter) described in the message of mass action are preserved. If the field for samplingTime is not specified, it means that all records have the om:samplingTime InsertObservation message that carries the set of values.

Note. In this version the data type can contain a swe:field of a swe:DataRecord limited to the basic types described at the beginning of the document except a swe:DataRecord type, i.e. nested swe:DataRecord is not allowed.

34 of 74

5 LIGHTWEIGHT PROTOCOL

The lightweight protocol is an alternative to the models described above to reduce the size of messages.

The reduction is based on several aspects:

1. Using schemes without qualifying, resulting in the smaller XML documents headers not being necessary to indicate the namespaces.

2. The tags used for XML documents element and attribute names are reduced. 3. In some cases it’s only supported the model alternative to a subset of the possibilities

provided by SensorML and O&M. 4. Possibility to use reduced URNs for the IDAS namespace. 5. Some attributes in the complete model are used in the lightweight model to facilitate its

use.

The lightweight protocol does not eliminate any of the requirements described in the traditional protocol.

5.1 URN in reduced format

The identification of concepts or terms by URN (2.1) has an alternative syntax in lightweight protocol for those concepts within the IDAS namespace (where the authority field is IDAS)

urn:x-‐ogc:def:objectType:authority:version:code

Other concepts or terms not defined in IDAS must follow the full format.

The reduced form identifies the objectType and code. Thus, a concept identified by urn:x-ogc:def:phenomenon:IDAS:1.0:temperatura may be named as: phenomenon:temperatura.

In addition, it provides another, smaller format, consisting of the objectType labels and having a code number with which these concepts are equivalent:

urn:x-ogc:def:phenomenon:IDAS:1.0:temperature

phenomenon:temperatura

8:1

5.2 Data types

We describe the data types used to describe values in the lightweight protocol

5.2.1 Numeric values

Equivalent to the swe:Quantity and swe:QuantityRange types. They represent a decimal value or a pair of decimal values separated by a space, respectively.

• The uom attribute indicates the URN associated to the measuring unit.

35 of 74

• The represented physical phenomenon can be indicated with a def attribute. If this attribute is not present, we obtain thephysical phenomenon from the measure unit, but it will always be a basic physical phenomenon.

<quan uom="9:11">0</quan>

<qrange uom="9:11">0 1</quan>

This element may contain an optional name> attribute that can include additional information on the application.

5.2.2 Boolean values

Is the same as the swe:Boolean type.

• It may contain a def attribute to indicate the physical phenomenon it represents.

<bln>true</bln>


5.2.3 Time values

Equivalent to the swe:Time and swe:TimeRange types representing temporal data or a pair of temporary data separated by a space.


<time>2011-04-06T12:08:09Z</time>

<trange>2011-04-06T12:08:09Z 2011-04-06T13:08:09Z </trange>


5.2.4 Textual values

Equivalent to swe:Text type.


<text>SmartSantander</text>

36 of 74


5.2.5 Geospatial values

In the lightweight protocol geospatial values are restricted to using the GPS position in WSG84 with latitude and longitude in degrees and optional altitude in meters.

• lat: indicates the latitude in degrees. • lon: indicates the longitude in degrees • alt: indicates the altitude in meters.

<gps lat="40.87" lon="23.78"/>

5.2.6 Values composition

The aggregation of values equal to the swe:DataRecord type. It consists of a sequence of fields (fld) that can contain any of the other basic types except other aggregated types.

• The rec element can contain a def attribute to indicate the represented phenomenon. • Each fld field can contain the href and name attributes to identify a definition and an

auxiliary name, respectively.

<rec><fld><bln>true</bln></fld><fld><text>Hola</text></fld></rec>

5.3 Record operation

There is a parallel operation to RegisterSensor in lightweight protocol.

<rs>

Resource description

</rs>

5.3.1 Resource description

The described elements constitute the contents of lightweight protocol <rs> operation.

5.3.1.1 Description

It is an optional element that allows including a textual description.

<des>Resource text description</des>

37 of 74

5.3.1.2 Name

It is an optional element that allows including a descriptive name of the resource

<name>Descriptive name</name>

5.3.1.3 Contact information

This optional element corresponds to the sml:contact element. The name attribute is interpreted as the resource responsible and the arc attribute as the type of relation with the resource. The content is interpreted as the contact information.

<cnt name="Organization name" arcr="owner">Contact address</cnt>

5.3.1.4 Keywords

It is a sequence of terms that identify certain properties of the resource. This sequence is optional.

<kwd>Sensor</kwd>

<kwd>Temperature</kwd>

5.3.1.5 Characteristics

It is an optional sequence that describes characteristics of the resource. Is equivalent to sml:characteristics element. It is described by composition of values.

<chr name="System feature"><fld><bln>true</bln></fld></chr>

5.3.1.6 Identification

At least there must be an element that identifies the resource.

• It may contain an optional name element to give a descriptive name. • The href attribute identifies through URN the identifier type.

<id href="1:1">LuebeckSensor</id>

38 of 74

5.3.1.7 Classification

It is an optional element that allows carrying out a classification of the resource

• It may contain an optional name element to give a descriptive name. • The href attribute identifies through URN the identifier type.

<cat href="2:1">Multi zone sensor </cat>

5.3.1.8 Resource validity

Optional element indicating the time range of validity for the resource and is also used to perform a deletion of the resource. It can be an instant or an interval, indicating the latter through two time instants separated by a space.

• Can contain an optional ip attribute to indicate an indefinite instant used to carry out the resource deletion. See ¡Error! No se encuentra el origen de la referencia..

<vtm>2011-04-06T12:08:09Z</vtm>

5.3.1.9 Capacities

Equivalent to sml:capabilities and is an optional element. It is described through an aggregation of data.

• The cap element can hava an optional name attribute to indicate a descriptive name for a group of described capacities.

<cap><fld><bln>true</bln></fld></cap>

5.3.1.10 Observed physical phenomena

Corresponds with sml:inputs. It may contain one or more elements.

• The href attribute indicates through URN the observed physical phenomenon. • It may contain an optional name attribute defining a descriptive name.

<what href="8:49"/>

5.3.1.11 Measured physical phenomena

Corresponds with sml:outputs. It may contain one or more elements. Each element contains one of the basic types to indicate how it represents a measured physical phenomenon.

39 of 74

• It may contain an optional name attribute to provide a descriptive text.

<data><quan uom="9:11">0</quan></data>

• It may contain an additional id attribute that will be used as data in the publication of

super-small format measures.

<data id=”data_1”> description </data>

5.3.1.12 Parameters

Corresponds to the sml:parameters parameter list. It is an optional and multiple element, so that there may be several elements.

Each element is described with one of the basic types.

• It may contain the optional name attribute to give a descriptive name. • It may contain the href, role, arcr attributes whose interpretation is derived from the

xlink:href, xlink:role and xlink:arcrole attributes described in 3.4.3.

<param><text>Hello</text></param>

• It may contain an optional id attribute that will allow its use as data in the publication of super-small measures format.

<param id=”param_1”> descption </param>

5.3.1.13 Spatial position

A resource record may describe the spatial position in which it is at the time of registration. It is done through <gps> staple. It is an optional element.

5.3.1.14 Temporal position

The registration of a resource can indicate the time position at the time of registration. It is an optional element.

<rtm>2011-04-06T12:08:09Z</rtm>

5.3.1.15 Components

If a record contains other atomic resources, they are described as components. A resource can contain more than one component or none.

40 of 74

A component is described through 5.3.1.6, 5.3.1.7, 5.3.1.8, 5.3.1.9, 5.3.1.10, 5.3.1.11, 5.3.1.12, 5.3.1.13 y 5.3.1.14.

• The <cmp> element may contain an optional name attribute to give a descriptive name. <cmp name="Nombre Componente">

<id href="1:1">IdentificadorComponente</id> <cap name="Capacidades de componente">

<fld><bln>true</bln></fld> </cap> <what href="8:49"/> <data>

<quan uom="9:11">0</quan> </data> <param>

<text>Hola</text> </param> <gps lat="1" lon="1"/> <rtm>2011-04-06T12:08:09</rtm>

</cmp>

5.4 Measure publication operation

There is an operation similar to InsertObservation associated to lightweight protocol.

<io>

One or more measures

</io>

With this message we can publish more than one observation.

• The <io> element may contain an optional attribute to indicate the resource from the message source. Using this attribute is interpreted as the origin of all the observations it contains.

5.4.1 Description of an observation

An observation is described by <obs> element. This element may contain an optional attribute to indicate the resource from the origin of this particular observation. It shall be consideed whether it is not specified to the attribute from <io> element.

<obs from="LuebeckSensor">Measure description

41 of 74

</obs>

5.4.1.1 Observation time.

It is equivalent to the traditional om:samplingTime element. We can specify an instant or a time interval.

<stm>2011-04-06T12:08:09Z</stm>

5.4.1.2 Observed phenomenon

It is represented by the <what> element. See 5.3.1.10.

<what href="8:1"/>

5.4.1.3 Parameters

We can optionally specify parameters that enrich the observation. See 5.3.1.12.

<param><gps lat="40.87" lon="23.78"/></param> <param href="1:7">

<text>SmartSantander</text> </param>

5.4.1.4 Measured value

It is equivalent to the om:result element. See 5.3.1.11.

<data><quan uom="uom:celsius">20.70</quan></data>

It is also possible to indicate a special type of measured value that is used to massively send measured values.

<recg> <fld href="urn:x-ogc:def:property:IDAS:1.0:samplingTime"> <time>2011-04-06T12:08:09Z</time> </fld> <fld href="urn:x-ogc:def:phenomenon:IDAS:1.0:temperature"> <quan uom="urn:x-ogc:def:uom:IDAS:1.0:celsius">0</quan> </fld> <text>2011-04-06T12:10:09Z,2|2011-04-06T12:20:09Z,13.9</text> </recg>

42 of 74

The element is comprised of <recg> and <fld> elements describing the interpretation of the stocks comprising the <text> element. The values are records separated by “|”. The fields in each record are separated by “,”.

The above example indicates that the first value of a register is the value associated with the instant of observation and the second value corresponds to a basic <quan> type with the indicated characteristics. The <text> analysis indicates that there are two records and generates two observations.

5.4.2 Observation description in super-small format.

The use of this publication format requires the use of the lightweight registration form (<rs>), using the id attribute in the data and param fields.

An observation on super-small format is a string where each field is separated by the “|”: character:

<UniversalIdentifierOfLogicalHub>|<resource>|<sampling time>|

<observed phenomenon>|<parameters>|<measured_value>

Where:

• UniversalIdentifierOfLogicalHub: This is the identifier of this type published in the registration operation associated to the lightweight protocol.

• Resource: The name of the resource by which is identified the observation origin. • Sampling time: the value corresponding to the <stm> field of the lightweight protocol. • Observed phenomenon: the value corresponding to the href attribute of the <what>

field of the lightweight protocol (following the reduced urn format). • Parameters: corresponds to the <param> elements of the lightweight protocol. Follows

this format:

<id_param>|<values>

Where:

id_param: Identifier associated with parameter in the registry (id attribute).

Values: can be one or more fields, separated by “|” depending on the type modeled for the parameter. For example, if it was modeled as <gps> with latitude and longitude, will be composed by two values (<latitud>|<longitud>).

If the parameters are not published, it is empty (||).

• Measured_value: corresponds to the <data> field of the observation according to the lightweight protocol. Follows this format:

<id_data>|<valores>

Where:

id_data: The identifier (id attribute) associated with registration <data> element according to the lightweight protocol.

43 of 74

Values: may be one or more fields separated by “|” depending on the modeling for the data. For example, if modeled as <gps> with latitude and longitude, will consist of two values (<latitud>|<longitud>).

Example: <rs>

<id href="urn:x-‐ogc:def:identifier:IDAS:1.0:localIdentifier">rec_idas_1</id> <id href="1:7">UCIDASTEST</id> <what href="urn:x-‐ogc:def:phenomenon:IDAS:1.0:presence"/> <what href="urn:x-‐ogc:def:phenomenon:IDAS:1.0:batteryCharge"/> <gps lat="43.47139" lon="-‐3.80222"/> <param id="pgps" name="ParamGPS"

role="property:configurationProperty" arcr="urn:x-‐ogc:def:property:IDAS:1.0:read" href="urn:x-‐ogc:def:property:UC:1.0:ParamGPS"> <gps lat="00.47139" lon="-‐00.80222"/>

</param> <data>

<bln>false</bln> </data> <data name="BC" id="bc">

<quan uom="urn:x-‐ogc:def:uom:IDAS:1.0:percent">0</quan> </data>

</rs>This registry publishes the following information:

• Resource: rec_idas_1 • UniversalIdentifierOfLogicalHub: UCIDASTEST • Observed phenomena: presence and battery charge. • Measured values: One Boolean and another identified as “bc” which is a Quantity type. • Parameters: One, identified as “pgps”, which is a gps type (with latitude and longitude).

In view of this record, the super-small protocol may be used to send the pgps parameter, and the measured value identified by bc.

UCIDASTEST|rec_idas_1|2011-04-06T12:08:09Z|8:49| pgps|-00.678|45.045|bc|6.99

44 of 74

6 PROTOCOLS

The operations including the description of an action or measure taken by a resource consist in XML documents transmitted through the HTTP 1.1 protocol in the body of a POST request.

It is mandatory to send a registration request before sending any measure. A sending of a resource measure not previously registered will result in an error.

6.1 Registration request

It is used to describe resources and register them on the platform. Registration can be done both with the traditional protocol (SensorAPI), and with the lightweight protocol described in Chapter 5.

<sos:RegisterSensor service="SOS" version="1.0.0" xsi:schemaLocation="http://www.opengis.net/sos/1.0 sosRegisterSensor.xsd" xmlns:om="http://www.opengis.net/om/1.0" xmlns:swe="http://www.opengis.net/swe/1.0.1" xmlns:sml="http://www.opengis.net/sensorML/1.0.1" xmlns:sos="http://www.opengis.net/sos/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance"> <sos:SensorDescription> <sml:System/> ver 3.1 </sos:SensorDescription> <sos:ObservationTemplate> <om:Observation> <om:samplingTime/> <om:procedure/> <om:observedProperty/> <om:featureOfInterest/> <om:parameter/> <om:result/> </om:Observation> </sos:ObservationTemplate> </sos:RegisterSensor>

This XML document is sent in the Content of a HTTP 1.1 POST request.

The response to a successful petition is an XML document in the Content of an HTTP 1.1 200 response.

<sos:RegisterSensorResponse xsi:schemaLocation="http://www.opengis.net/sos/1.0 sosRegisterSensor.xsd" xmlns:sos="http://www.opengis.net/sos/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance"> <sos:AssignedSensorId>WeatherStation_1</sos:AssignedSensorId> </sos:RegisterSensorResponse>

45 of 74

The sos:AssignedSensorId identifier is of the resource registered as System.

In case of the lightweight protocol, a successful registration response of a resource is:

<rsr id=”Resource Identifier”/>

When an error occurs, a HTTP 1.1 4xx code is returned with Content:

<ows:ExceptionReport

version="1.0.0" xsi:schemaLocation="http://www.opengis.net/ows/1.1owsExceptionReport.xsd"

xmlns:ows=http://www.opengis.net/ows/1.1 xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance" xml:lang="es">

<ows:Exception exceptionCode="" locator=""> <ows:ExceptionText>Recurso no registrado</ows:ExceptionText> </ows:Exception> </ows:ExceptionReport>

In case the lightweight protocol is used, an error condition is described as:

<e c=”código” l=”locator”>Descripción del error</e>

The codes for different error conditions (ExceptionCode attribute) are still to be defined.

46 of 74

Figure 1. Register Sensor request flow

1. Through the HTTP POST hub is sent an XML RegisterSensor document following the instructions in this document. It checks the request and the resource description included in the XML RegisterSensor document.

2. It responds to the hub with an XML RegisterSensorResponse or ExceptionReport document, depending on whether the request was accepted or not.

3. If the request is accepted by the gateway it starts the procedure of sending the XML RegisterSensor document adapted to the model defined in the platform.

4. In the response of the Sensor Enabler can be requested the forwarding of the request to update the named resource. The gateway will perform the change of the name assigned to resources on the platform and try to log again in the Sensor Enabler.

Registration can proceed from two sources, from a device, this is the registration procedure above described and can also proceed from the API REST. In the first case, when the register message arrive from a device can include a parameter modelName or cannot have this parameter. The gateway sends the register message to the sensor enabler and this platform manages the model. If the parameter modelName is present, and the model exists in database, the registration is according the existing model. If the model not exists in database, the sensor enabler generates a model with the information of the register message, and the name of the modelName. When the register has not the parameter modelName, the sensor enabler generates a model in database with the information of the register message, and the name “Autogenerate”.

47 of 74

In the second case, the gateway receives the registration from the API REST, through neo_http_proto. In this case, registration is always according with a model. The message received from the API REST includes the following information: model_name : name of model service : number of service domain : name of concentrator device : name of device enabled_command : enable or disable command functionality lon, lat : for location

The gateway find in the mongo collection MODEL, the information for registration associated to model_name and service. Using the input / output information that read from the database, the gateway generates a register message, and sends it to the neo_oe_recorder process in the sensor enabler. An example of the information in database about the model is: "MN" : "ModelJU1", "IL" : [ { "NI" : "Temperatura", "OB" : "temperature", "O" : { "NO" : "Temperatura", "AUL" : "Temperatura", "T" : "Quantity", "UOM" : "partsPerMillion" } }, { "NI" : "Humedad", "OB" : "relativeHumidity", "O" : { "NO" : "Humedad", "AUL" : "h", "T" : "Quantity", "UOM" : "percent" } } ], "SERVICE" : 2402 Where IL indicates the list and format of inputs and outputs allowed for the device. If the field AUL is dummy or not exist, that indicates a register in SensorML protocol, if AUL is not dummy indicate register in Ligth protocol.

6.2 Measure notification request

This request is used to inform the platform about the collection of an observation or measurement. You can perform both SensorAPI as lightweight protocol described in Chapter 5.

48 of 74

<sos:InsertObservation service="SOS" version="1.0.0" xsi:schemaLocation="http://www.opengis.net/sos/1.0 sosInsert.xsd" xmlns:om="http://www.opengis.net/om/1.0" xmlns:sos="http://www.opengis.net/sos/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance"> <sos:AssignedSensorId>WeatherStation_1</sos:AssignedSensorId> <om:Observation> <om:samplingTime/> <om:procedure/> <om:observedProperty/> <om:featureOfInterest/> <om:result/> </om:Observation> </sos:InsertObservation>

This document is sent in the Content of a HTTP 1.1 POST request.

The response to a request with success is an XML document in the Content of a HTTP 1.1 200 response.

<sos:InsertObservationResponse xsi:schemaLocation="http://www.opengis.net/sos/1.0 sosInsert.xsd" xmlns:sos="http://www.opengis.net/sos/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance"> <sos:AssignedObservationId>1</sos:AssignedObservationId> </sos:InsertObservationResponse>

This returns an identifier for the inserted observation.

If we use lightweight protocol to publish measure, the successful response is:

<ior id=”Measure Identifer”/>

In case of error it returns a HTTP 1.1 4xx code as shown in 6.1. The response with error to the publication of an observation is similar to the described for the case of resource record through the lightweight protocol.

Using the super-small protocol we can send multiple frames for several observations. Each observation will be separated by a configurable character.

The super-small protocol allows specifying certain parameters in the URL:

• UC: indicates a UniversalIdentifierOfLogicalHub. Its presence allows not transmitting this data for each observation included in the HTTP POST. This is useful when several observations are transmitted from the same UC.

• ID: Indicates a resource. Its presence allows not transmitting this data for each observation included in the HTTP POST. This is useful when several observations are transmitted from the same resource.

49 of 74

• URL: Indicates the address to which we send commands. This parameter must be accompanied by the two previous ones, and allows updating the direction in which the commands are received by the resource indicated by ID, and the hub indicated by UC.

Figure 2. InsertObservation request flow

1. The hub sends via an HTTP POST request an XML document that follows InsertObservation the instructions in this document.

2. If the resource identified in this document as the source of the measure hasn’t been previously registered as a resource, the request with a XML ExceptionReport document will be rejected. If there is a request that does not pass parsing/semantic it will also be rejected. If accepted, it responds with an InsertObservationResponse document.

3. InsertObservation document adapted to the needs of the sensor platform is sent to Enabler only if the analysis phase is successful.

6.3 Commands and actions

The mechanism for running commands or actions in the environment of the network of sensors and actuators is similar.

50 of 74

It is essential to know the subject(s) to be changed. The case of actuators is reduced to the modification of parameters that have an effect on some physical phenomenon.

The commands are sent to the switch via HTTP POST method to the URL specified in the parameter defined as urn:x-ogc:def:property:IDAS:1.0:commandURL in the RegisterSensor request. The message content will be:

<paid:command dest =”” name="" id=""> <paid:cmdParam> Tipo definido en RegisterSensor para el parámetro. </paid:cmdParam> </paid:command>

The name attribute indicates the command string to execute, and using the id attribute assigns a sequence number to the command. The dest attribute specifies the resource recipient of the command.

The parameters are referenced using the URN with that it was described in the RegisterSensor message parameter.

6.3.1 SET/GET default commands

By default, any parameter posted in the RegisterSensor message is accessible through the SET/GET command. When a parameter is set to read only the GET command applies. When a write command is defined only applies the SET command. When a parameter is defined readwrite, both commands apply.

• GET command: should be applied to parameters defined or described as read and allows recovery of the value of that attribute. The name attribute is GET.

• SET command: should apply to parameters defined as writing and including the value with an attribute to be updated. With this type of command you can change settings or perform actions. The name attribute is SET.

Let’s suppose that a paremeter in the RegisterSensor was defined as:

<sml:parameter name="TemperaturePeriod" xlink:href="urn:x-‐ogc:def:property:XXX:1.0:TemperaturePeriod" xlink:arcrole="urn:x-‐ogc:def:property:IDAS:1.0:readwrite" xlink:role=”urn:x-‐ogc:def:property:IDAS:1.0:operationProperty”> <swe:Quantity definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:time"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:millisecond"/> <swe:value>30000</swe:value> </swe:Quantity> </sml:parameter>

Note that the parameter is defined through a urn namespace outside the IDAS one (XXX) , since, in principle, has in itself no special semantics in the namespace of the platform.

51 of 74

To read the parameter value is send a GET command:

<paid:command xsi:schemaLocation="urn:ogc:def:dictionary:PAID:1.0:paid PaidCommand.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance" xmlns:swe="http://www.opengis.net/swe/1.0.1" xmlns:paid="urn:ogc:def:dictionary:PAID:1.0:paid" dest=”id_recurso” name="GET" id="1234"> <paid:cmdParam name=" urn:x-‐ogc:def:property:XXX:1.0:TemperaturePeriod"/> </paid:command>

To set the value of this parameter will be sent a SET command:

<paid:command xsi:schemaLocation="urn:ogc:def:dictionary:PAID:1.0:paid PaidCommand.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance" xmlns:swe="http://www.opengis.net/swe/1.0.1" xmlns:paid="urn:ogc:def:dictionary:PAID:1.0:paid" dest=”id_recurso” name="SET" id="1234"> <paid:cmdParam name=" urn:x-‐ogc:def:property:XXX:1.0:TemperaturePeriod"> <swe:Quantity> <swe:value>6000</swe:value> </swe:Quantity> </paid:cmdParam> </paid:command>

6.3.2 Specific commands

It is possible to describe specific commands via parameters defined as urn:x-ogc:def:property:IDAS:1.0:commandProperty in the xlink:role attribute.

For example, to define a Reset command (without parameters), a parameter in RegisterSensor is defined as:

<sml:parameter name="Reset" xlink:href="urn:x-‐ogc:def:property:XXX:1.0:Reset" xlink:role=”urn:x-‐ogc:def:property:IDAS:1.0:commandProperty”> </sml:parameter>

If there were parameters, we would define a swe:DataRecord and each field would be a parameter. <sml:parameter name="Reset" xlink:href="urn:x-‐ogc:def:property:XXX:1.0:Reset" xlink:role=”urn:x-‐ogc:def:property:IDAS:1.0:commandProperty”>

<swe:DataRecord> <swe:field name="parametro1" xlink:href="urn:x-‐ogc:def:property:XXX:1.0:parametro1" > <swe:Boolean> <swe:value>false</swe:value>

52 of 74

</swe:Boolean> </swe:field>

</swe:DataRecord> </sml:parameter>

And the command to send would be:

<paid:command xsi:schemaLocation="urn:ogc:def:dictionary:PAID:1.0:paid PaidCommand.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance" xmlns:swe="http://www.opengis.net/swe/1.0.1" xmlns:paid="urn:ogc:def:dictionary:PAID:1.0:paid" dest="id_recurso" name=" urn:x-‐ogc:def:property:XXX:1.0:Reset " id="1234"> <paid:cmdParam name="urn:x-‐ogc:def:property:XXX:1.0:parametro1"> <swe:Boolean> <swe:value>true</swe:value> </swe:Boolean> </paid:cmdParam> </paid:command>

The name of the command to run is identified by the URN that was defined in the RegisterSensor message parameter.

6.3.3 Commands responses

In many situations, the request for execution of a command is not performed instantaneously by agencies with the protocol used in the sensor network. There are networks in which the nodes follow sleep/awake procedures and a command attention depends on the time they are active or awake.

Thus, the command responses follow two mechanisms:

1- Synchronous: When the command is executed immediately. In this case, a HTTP 200 OK code will be sent when the command is successful, or appropriate HTTP code to indicate an error. It may incorporate a response message body.

2- Asynchronous: when the execution is delayed. In this case, it shall be replied with a HTTP error code in the event that the command can not be executed, or a HTTP 202 Accepted code if the request is executed on a deferred basis. After running the command we may proceed to send the result of running through a HTTP POST command and the result of execution. A response to a command follows the following scheme: <paid:commandResponse xsi:schemaLocation="urn:ogc:def:dictionary:PAID:1.0:paid PaidCommand.xsd" xmlns:swe="http://www.opengis.net/swe/1.0.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance" xmlns:paid="urn:ogc:def:dictionary:PAID:1.0:paid" id="1234"> <paid:cmdParam> o <paid:resultCommand> o <paid:errorCommand>

53 of 74

</paid:commandResponse>

There should always be the id attribute to identify the command that is answered and that correspond to the id attribute of the command execution request.

When it comes to the default SET/GET commands affecting a parameter, it will return the parameter value in the format corresponding to that parameter (paid:cmdParam)

When it comes to a specific command, the answer will be paid:resultCommand type, containing one of the basic types defined in the interface (e.g. swe:Boolean).

When we want to explain an error, it will be replied with paid:errorCommand, which is a string type.

If a command is executed synchronously and the request is correct, it always returns a 200 OK, even if the result of the execution contains an errorCommand. That is, the HTTP code identifies whether the request is correct and commandResponse determines the result of command execution.

The reduced protocol associated with sending commands is the use of the types defined for that protocol.

The following table indicates the label replacement towards the reduced protocol:

Normal protocol tag Reduced protocol tag

paid:command cmd

paid:cmdParam cmdp

paid:commandResponse cmdr

paid:resultCommand cmdres

paid:errorCommand cmde

6.3.4 Commands by polling from devices

Alternative mechanism is provided in order to execute a command. When a device publishs its description by RegisterSensor operation without commandURL parameter, platform cannot send a command by HTTP POST method.

In this scenario, command is temporarily stored waiting HTTP GET method from device to retrieve it:

• HTTP method: GET

• Device uses the URL to send measures with parameters to identify itself:

54 of 74

GET /idas/sml?UC=<UniversalConcentrator>&ID=<device>

• Body response is a command as described above.

• When command is executed, device informs as asynchronous execution.

6.3.5 Updating command URL of device

When command URL of device changes, the new URL must be informed. The mechanism consists of sending HTTP POST method with parameters (this parameters can be sent when a measure is sent).

Parameters:

• UC: identifies UniversalConcentrator

• ID: identifies the device or resource changing command URL.

• URL: identifies the new command URL.

6.3.6 API-KEY

As another level of security that enables client side authentication, the secret concept is introduced.

In the service provisioning phase, there is the option of creating an API KEY. If this option is chosen, all the requests related to this service must contain “apikey=[generated key]”.

This key will be provided to the devices so they can include it into the URL. It allows indentifying the source of the requests to some extent.

55 of 74

A IDAS NAMESPACES URNS

The following table identifies the objectType numeric value of a URN when using the reduced form.

Tabla 1. ObjectType field identifiers of a URN

objectType Numeric value Description

identifier 1 Identifier

classifier 2 Classifier

property 3 Property

cs 4 Coordinate system

crs 5 Reference coordinate system

trs 6 Temporal reference system

ts 7 Temporary system

phenomenon 8 Physical phenomenon

uom 9 Measuring unit

The URN associated to identifiers follow the syntax: urn:x-ogc:def:identifier:IDAS:1.0:<code> for the full format. The reduced format will be identifier:<code> and the format with numeric values will be 1:<numeric_code>

Tabla 2. Identifiers

code numeric_code Desciption

globalIdentifier 0 This type of identifier can reference a resource in the IDAS domain and is assigned internally. Should not be used to describe a resource outside IDAS.

localIdentifier 1 It is a local identifier within the defined resource scope. May be used to generate the globalIdentifier.

serialNumber 2 It is a local identifier within the defined resource scope. May be used to generate the globalIdentifier.

56 of 74

uuid 3 It is a local identifier within the resource scope defined in UUID format. May be used to generate the globalIdentifier.

UniversalIdentifierOfLogicalHub 7 It is a universal unique identifier associated with the hub (physical or logical). Mandatory.

localName 4 It is a local identifier within the defined resource scope.

manufacturer 5 Identifies the manufacturer of the device/resource.

version 6 Identifies the version of the resource given by the manufacturer.

The URN associated to classifiers follows the syntax: urn:x-ogc:def:classifier:IDAS:1.0:<code> for the full format. The small format will be classifier:<code> and the format with numeric values will be 2:<numeric_code>

Tabla 3. Classifiers

code numeric_code Description

node 0 Classifies the resource as a node.

sensor 1 Classifies the resource as a sensor.

actuator 2 Classifies the resource as an actuator.

concentrator 3 Classifies the resource as a hub.

application 4 Classifies the resource as an application.

system 5 Classifies the resource as a system.

The URN associated to generic properties follows the syntax: urn:x-ogc:def:property:IDAS:1.0:<code> for the full format. The small format will be property:<code> and the format with numeric values will be 3:<numeric_code>

Tabla 4. Properties


length 0 Physical length of the device/resource.

width 2 Physical width of the device/resource.

depth 3 Physical depth of the device/resource.

dcVoltage 4 Voltage for the DC power source.

57 of 74

acVoltage 5 Voltage for the AC power source.

resolution 6 Sets the resource resolution.

accuracy 7 Operational accuracy of the resource.

operatingRange 8 Operating range of the resource.

reportInterval 9 Sets the interval between measurements.

commandURL 17 Sets the URL for sending commands. It is recommended for this parameter to be unique in the sml:System element of the RegisterSensor request, so all components share the URL.

read 10 Read-only flag.

write 11 Write-only flag.

readwrite 12 Read and write flag.

configurationProperty 13 Sets a configuration property as defined by the manufacturer or installer.

operationProperty 14 Defines a property as associated with the operating environment.

observationProperty 15 Defines a property as associated to measures taking.

commandProperty 16 Defines a property as command type. It will be used to define extra command besides the default ones (set/get)

QoS 19 This property indicates that this message should be treated as gold, which means, that is marked to be retransmitted, if necessary, and to be persistent. This message would not be lost in case of network failure. Set to 1 means persistence/retransmission ena bled, disabled for 0.

ModelName 18 Define the name of the model used to register a device

The URN associated to generic coordinates system follows the syntax: urn:x-ogc:def:cs:IDAS:1.0:<code> for the full format. The small format will be cs:<code> and the format with numeric values will be 4:<numeric_code>

58 of 74

Tabla 5. Coordinates systems


cartesian1D 0 Coordinate system of 1 dimension with x axis in meters.

cartesian2D 1 Coordinate system of 2 dimensions with x, y axes in meters.

cartesian3D 2 Coordinate system of 3 dimensions with x, y, z axes in meters.

The URN associated to generic coordinates system follows the syntax: urn:x-ogc:def:crs:IDAS:1.0:<code> for the full format. The small format will be crs:<code> and the format with numeric values will be 5:<numeric_code>

Tabla 6. Reference Coordinates System


CRS84 0 WSG 84. Latitude and longitude, in degrees.

The URN associated to generic reference temporal systems follows the syntax: urn:x-ogc:def:trs:IDAS:1.0:<code> for the full format. The small format will be trs:<code> and the format with numeric values will be 6:<numeric_code>

Tabla 7. Reference Temporal Systems


ISO8601 0 Temporal reference system with the Gregorian calendar and Coordinated Universal Time (UTC).

GPSTime 1 Temporal reference system defined by GPS systems.

The URN associated to temporal systems follows the syntax: urn:x-ogc:def:ts:IDAS:1.0:<code> for the full format. The small format will be ts:<code> and the format with numeric values will be 7:<numeric_code>

Tabla 8. Temporal systems


piam 0 One-dimensional temporal coordinate with t axis in seconds.

59 of 74

The URN associated to physical phenomena follows the syntax: urn:x-ogc:def:phenomenon:IDAS:1.0:<code> for the full format. The small format will be phenomenon:<code> and the format with numeric values will be 8:<numeric_code>

Tabla 9. Physical phenomena


temperature 1 Temperature.

relativeHumidity 3 Relative humidity.

direction 4 Generic direction

windDirection 5 Wind direction.

velocity 6 Speed

windSpeed 7 Wind speed.

pressure 8 Pressure

atmosphericPressure 9 Atmospheric pressure.

rainfall 10 Precipitation, rainfall.

concentration 11 Concentration

CO2Concentration 15 CO2 concentration.

COConcentration 16 CO concentration.

time 12 Time

NOConcentration 13 NO concentration

O3Concentration 14 Ozone concentration

UVRadiation 17 UV radiation

solarRadiation 18 Solar radiation

acceleration 19 Acceleration.

Xacceleration 20 Acceleration in the X axis.

Yacceleration 21 Acceleration in the Y axis.

Zacceleration 22 Acceleration in the Z axis.

sound 23 Sound

electricPotential 24 Voltage

60 of 74

electricCurrent 25

length 26 Longitude, distance.

location 27 Location.

longitude 28 Geolocation longitude.

latitude 29 Geolocation latitude.

altitude 30 Height above sea level, geolocation altitude.

connectivity 31 Connectivity

turbidity 32 Turbidity

volume 33 Volume

power 34 Power.

averagePower 35 Average power

minimumPower 36 Minimum power

maximumPower 37 Maximum power

energy 38 Energy

currency 39 Currency

cost 40 Cost

energyCost 41 Energy cost

energyCO2 42

mass 2 Mass

event 0 Event or alarm

frecuency 43 Frequency

PulseOximetry 44 Saturation by Oximetry

GlucoseConcentration 45 Glucose concentration

BloodPressure 46 Blood pressure

HeartRate 47 Heart rate

presence 48 Presence

batteryCharge 49 Battery charge

61 of 74

GasConcentration 50 Gas concentration

The URN associated to physical phenomena follows the syntax: urn:x-ogc:def:uom:IDAS:1.0:<code> for the full format. The small format will be uom:<code> and the format with numeric values will be 9:<numeric_code>

Tabla 10. Measurement units

code numeric_code UCUM code Description

celsius 12 Cel Celsius degrees.

percent 11 % Relative humidity.

metersPerSecond 13 m/s Speed.

kilometersPerHour 14 km/h Speed.

pascal 16 Pa Pressure

hectoPascal 17 hPa Pressure.

millimetersPerSquareMeter 18 mm/m2 Precipitation, rainfall.

millimeters 19 mm Millimeters

partsPerMillion 20 [ppm] Concentration

partsPerBillion 21 [ppb] Concentration.

second 2 s Time

inch 3 [in_i] Inch

millisecond 44 ms Time

hour 15 h Time

wattsPerSquareMeter 27 W/m2 Ultraviolet, solar radiation.

milliwattsPerSquareCentimeter 26 mW/cm2 Ultraviolet, solar radiation.

wattsPerSquareCentimeter 25 W/cm2 Ultraviolet, solar radiation

gForce 29 g Acceleration.

metersPerSquareSecond 28 m/s2 Acceleration

decibel 30 dB Sound Power.

meter 1 m Longitude, distance

62 of 74

degree 31 deg Degrees, latitude, geolocation longitude.

watt 22 W Watt

kilowatt 23 kW Kilowatt

volt 24 V Volt

joule 35 J Joule

wattPerHour 37 Wh Watt per hour

kilowattPerHour 36 kWh Kilowatt per hour

euro 38 EUR Euro

dollar 39 USD Dollar

kilogram 0 kg Kilogram (mass)

gram 5 g Gram (mass)

centimeter 4 cm Centimeter

pound 6 [lb_av] Pound (mass)

ampere 7 A Amper

kelvin 8 K Kelvin degrees

mole 9 mol Mole (amount of substance)

candela 10 cd Candela (luminous intensity)

dimensionless 32 No unit

poundPerSquareInch 33 [psi] Pressure

cubicMeter 34 m3 Cubic meter

hertz 40 Hz Hertz

millimeterOfMercury 41 mm[Hg] Millimeters of mercury

heartBeaterMinute 42 {H.B.}/min Beats per minute

milligramPerDeciliter 43 mg/dL Milligrams per deciliter

63 of 74

B APLICATION NOTES

Resource and measures description indicated in this interface by different XML elements is not, in general, what remains on the platform, or what reaches the applications.

There is a previous process of homogenization of the elements and to adapt to the features configured in the gateway.

Textual elements.

There are elements in XML documents that describe resources and measures whose meaning is more textual and for representation than for interpretation. This applies to the name attributes that accompany many of the tags of XML documents.

To maintain uniformity in these textual elements and to have multi-language features, these attributes may be modified by the platform using the URN that defines the XML element in question.

Mesuring units

The elements having units of measurement in their description (swe:uom) should indicate the unit through the URN representative in the xlink:href attribute. Although this element has the code attribute used to indicate the symbol of unit, the platform will be responsible for the translation of the URN to the appropriate symbol (set on the platform for each unit), avoiding inconsistencies of representation.

64 of 74

C REQUIREMENTS

The following requirements are identified to match the functionality of the platform. The conditions 2 and 3 are justified by the possibility of dynamic routing in the elements producing information.

1. Any information generator element that wants to publish observations or measurements on the platform via the interface described in this document, should send a registration request before any other operation. This register will identify resources on the platform.

2. In order to facilitate the identification of resources, it is mandatory the uniqueness of the resources identified in a registration request, at least in the identifiers used to generate global identifier in the platform. This uniqueness is universal. The existence of the same identifier for multiple resources (regardless of its location or dependence for the same hub or another) may lead to uncontrolled operation.

3. The operative for any hub or element producing the information is to send a request for registration after every reboot or change of IP.

65 of 74

D EXAMPLE

Representation of a mobile weather station as a platform or system with the following components:

• GPS: indicates the position of the weather station. Not necessary to describe a local reference system for representing the relative location of other components.

• Temperature sensor. • Relative humidity sensor.

There are no configuration parameters that may vary.

The text fields (name attributes) are left empty, and the coordinates reference is indicated in the swe:Vector of swe:Position component to reflect this option as specified in 2.3.5.

Inputs and outputs elements of sml:System are an aggregation of the corresponding fields of each of the components.

D.1 Weather station description

<sml:System xsi:schemaLocation="http://www.opengis.net/sensorML/1.0.1 system.xsd" xmlns:gml="http://www.opengis.net/gml"

xmlns:swe="http://www.opengis.net/swe/1.0.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:sml=http://www.opengis.net/sensorML/1.0.1 xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance">

<sml:identification> <sml:IdentifierList> <sml:identifier> <sml:Term definition="urn:x-‐ogc:def:identifier:IDAS:1.0:localIdentifier"> <sml:value>EM_N1</sml:value> </sml:Term> </sml:identifier> </sml:IdentifierList> </sml:identification> <sml:classification> <sml:ClassifierList> <sml:classifier> <sml:Term definition="urn:x-‐ogc:def:classifier:IDAS:1.0:system"> <sml:value>Estacion Meteorologica</sml:value> </sml:Term> </sml:classifier> </sml:ClassifierList> </sml:classification> <sml:inputs> <sml:InputList> <sml:input name=""> <swe:ObservableProperty

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"/> </sml:input> <sml:input name=""> <swe:ObservableProperty

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:relativeHumidity"/> </sml:input>

66 of 74

<sml:input name=""> <swe:ObservableProperty

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:location"/> </sml:input> </sml:InputList> </sml:inputs> <sml:outputs> <sml:OutputList> <sml:output name=""> <swe:Quantity definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:celsius"/> </swe:Quantity> </sml:output> <sml:output name=""> <swe:Quantity

definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:relativeHumidity"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:percent"/> </swe:Quantity> </sml:output> <sml:output name=""> <swe:Position> <swe:location> <swe:Vector

referenceFrame="urn:x-‐ogc:def:crs:IDAS:1.0:CRS84"> <swe:coordinate name="latitude"> <swe:Quantity definition=”urn:x-‐ogc:def:phenomenon:IDAS:1.0:latitude”> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:degree"/> </swe:Quantity> </swe:coordinate> <swe:coordinate name="longitude"> <swe:Quantity definition=”urn:x-‐ogc:def:phenomenon:IDAS:1.0:longitude”> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:degree"/> </swe:Quantity> </swe:coordinate> </swe:Vector> </swe:location> </swe:Position> </sml:output> </sml:OutputList> </sml:outputs> <sml:components> <sml:ComponentList> <sml:component name=""> <sml:Component> <sml:identification> <sml:IdentifierList> <sml:identifier> <sml:Term definition="urn:x-‐ogc:def:identifier:IDAS:1.0:serialNumber"> <sml:value>DF34GPS456</sml:value> </sml:Term> </sml:identifier> </sml:IdentifierList> </sml:identification> <sml:classification> <sml:ClassifierList>

67 of 74

<sml:classifier> <sml:Term definition="urn:x-‐ogc:def:classifier:IDAS:1.0:sensor"> <sml:value>ReceptorGPS</sml:value> </sml:Term> </sml:classifier> </sml:ClassifierList> </sml:classification> <sml:inputs> <sml:InputList> <sml:input name=""> <swe:ObservableProperty definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:location"/> </sml:input> </sml:InputList> </sml:inputs> <sml:outputs> <sml:OutputList> <sml:output name=""> <swe:Position> <swe:location> <swe:Vector referenceFrame="urn:x-‐ogc:def:crs:IDAS:1.0:CRS84"> <swe:coordinate name="latitude"> <swe:Quantity definition=”urn:x-‐ogc:def:phenomenon:IDAS:1.0:latitude”> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:degree"/> </swe:Quantity> </swe:coordinate> <swe:coordinate name="longitude"> <swe:Quantity definition=”urn:x-‐ogc:def:IDAS:1.0:longitude”> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:degree"/> </swe:Quantity> </swe:coordinate> </swe:Vector> </swe:location> </swe:Position> </sml:output> </sml:OutputList> </sml:outputs> </sml:Component> </sml:component> <sml:component name=""> <sml:Component> <sml:identification> <sml:IdentifierList> <sml:identifier> <sml:Term definition="urn:x-‐ogc:def:identifier:IDAS:1.0:serialNumber"> <sml:value>234TEMP98H</sml:value>

68 of 74

</sml:Term> </sml:identifier> </sml:IdentifierList> </sml:identification> <sml:classification> <sml:ClassifierList> <sml:classifier> <sml:Term definition="urn:x-‐ogc:def:classifier:IDAS:1.0:sensor"> <sml:value>Termometro</sml:value> </sml:Term> </sml:classifier> </sml:ClassifierList> </sml:classification> <sml:inputs> <sml:InputList> <sml:input name=""> <swe:ObservableProperty definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"/> </sml:input> </sml:InputList> </sml:inputs> <sml:outputs> <sml:OutputList> <sml:output name=""> <swe:Quantity definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:celsius"/> </swe:Quantity> </sml:output> </sml:OutputList> </sml:outputs> </sml:Component> </sml:component> <sml:component name=""> <sml:Component> <sml:identification> <sml:IdentifierList> <sml:identifier> <sml:Term definition="urn:x-‐ogc:def:identifier:IDAS:1.0:serialNumber"> <sml:value>HUM76098AB</sml:value> </sml:Term> </sml:identifier> </sml:IdentifierList> </sml:identification> <sml:classification> <sml:ClassifierList> <sml:classifier> <sml:Term definition="urn:x-‐ogc:def:classifier:IDAS:1.0:sensor"> <sml:value>SensorHumedad</sml:value> </sml:Term> </sml:classifier> </sml:ClassifierList> </sml:classification> <sml:inputs>

69 of 74

<sml:InputList> <sml:input name=""> <swe:ObservableProperty definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:relativeHumidity"/> </sml:input> </sml:InputList> </sml:inputs> <sml:outputs> <sml:OutputList> <sml:output name=""> <swe:Quantity definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:relativeHumidity"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:percent"/> </swe:Quantity> </sml:output> </sml:OutputList> </sml:outputs> </sml:Component> </sml:component> </sml:ComponentList> </sml:components> </sml:System>

Sending of this description is carried out by HTTP 1.1 in the content of a POST request as indicated in 6.1. The response will be HTTP 1.1 200 OK with

<sos:RegisterSensorResponse

xsi:schemaLocation=http://www.opengis.net/sos/1.0 sosRegisterSensor.xsd xmlns:sos="http://www.opengis.net/sos/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance">

<sos:AssignedSensorId>EM_N1</sos:AssignedSensorId>

</sos:RegisterSensorResponse>

D.2 Weather station measure

This document represents a measure provided by the temperature sensor of the weather station.

<om:Observation xsi:schemaLocation="http://www.opengis.net/om/1.0 observation.xsd"

xmlns:gml="http://www.opengis.net/gml" xmlns:xlink=http://www.w3.org/1999/xlink xmlns:swe="http://www.opengis.net/swe/1.0.1" xmlns:om="http://www.opengis.net/om/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance">

<om:samplingTime> <gml:TimeInstant>

70 of 74

<gml:timePosition frame="urn:x-‐ogc:def:trs:IDAS:1.0:ISO8601">2010-‐04-‐14T11:29:47</gml:timePosition> </gml:TimeInstant> </om:samplingTime> <om:procedure xlink:href="234TEMP98H"/> <om:observedProperty xlink:href="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"/> <om:featureOfInterest/> <om:result> <swe:Quantity definition="urn:x-‐ogc:def:phenomenon:IDAS:1.0:temperature"> <swe:uom xlink:href="urn:x-‐ogc:def:uom:IDAS:1.0:celsius"/> <swe:value>12.8</swe:value> </swe:Quantity> </om:result> </om:Observation> This document represents a measure of the GPS position provided by the weather station.<om:Observation xsi:schemaLocation="http://www.opengis.net/om/1.0 observation.xsd"

xmlns:gml="http://www.opengis.net/gml" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:swe="http://www.opengis.net/swe/1.0.1" xmlns:om="http://www.opengis.net/om/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance">

<om:samplingTime> <gml:TimeInstant> <gml:timePosition frame="urn:x-‐ogc:def:trs:IDAS:1.0:ISO8601">2010-‐04-‐14T11:29:47

</gml:timePosition> </gml:TimeInstant> </om:samplingTime> <om:procedure xlink:href="DF34GPS456"/> <om:observedProperty xlink:href="urn:x-‐ogc:def:phenomenon:IDAS:1.0:location"/> <om:featureOfInterest/> <om:result> <swe:Position referenceFrame="urn:x-‐ogc:def:crs:IDAS:1.0:CRS84"> <swe:location> <swe:Vector definition="urn:x_ogc:def:phenomenon:IDAS:1.0:location"> <swe:coordinate name=""> <swe:Quantity definition=

"urn:x-‐ogc:def:phenomenon:IDAS:1.0:latitude"> <swe:uom xlink:href=

"urn:x-‐ogc:def:uom:IDAS:1.0:degree"/> <swe:value>27.5678</swe:value> </swe:Quantity> </swe:coordinate> <swe:coordinate name=""> <swe:Quantity definition=

"urn:x-‐ogc:def:phenomenon:IDAS:1.0:longitude"> <swe:uom xlink:href=

"urn:x-‐ogc:def:uom:IDAS:1.0:degree"/> <swe:value>-‐3.9876</swe:value> </swe:Quantity> </swe:coordinate> </swe:Vector> </swe:location> </swe:Position> </om:result> </om:Observation>

71 of 74

These measurements are sent as described in 6.2

<sos:InsertObservation service="SOS" version="1.0.0"

xsi:schemaLocation="http://www.opengis.net/sos/1.0 sosInsert.xsd" xmlns:om="http://www.opengis.net/om/1.0" xmlns:sos="http://www.opengis.net/sos/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-‐instance">

<sos:AssignedSensorId>EM_N1</sos:AssignedSensorId>

<om:Observation> ……………………………… </om:Observation>

</sos:InsertObservation>

72 of 74

E IDAS PROTOCOL SCHEME

<?xml version="1.0" encoding="UTF-‐8"?> <!-‐-‐ edited with XMLSpy v2008 sp1 (http://www.altova.com) by lucas (EMBRACE) -‐-‐> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:paid="urn:ogc:def:dictionary:PAID:1.0:paid" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:documentation>Este grupo referencia a atributos que pueden aparecer en los elementos definidos.</xsd:documentation> </xsd:annotation> <xsd:attributeGroup name="DefinitionXlinkGroup"> <xsd:attribute name="href" type="xsd:string" use="optional"/> <xsd:attribute name="role" type="xsd:string" use="optional"/> <xsd:attribute name="arcr" type="xsd:string" use="optional"/> <xsd:attribute name="def" type="xsd:string"/> <xsd:attribute name="name" type="xsd:string" use="optional"/> </xsd:attributeGroup> <xsd:annotation> <xsd:documentation>Tipo reducido para expresar un swe:Quantity</xsd:documentation> </xsd:annotation> <xsd:complexType name="IdasQuantityType"> <xsd:simpleContent> <xsd:extension base="xsd:double"> <xsd:attributeGroup ref="DefinitionXlinkGroup"/> <xsd:attribute name="uom" type="xsd:string"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> <xsd:annotation> <xsd:documentation>Tipo boolean</xsd:documentation> </xsd:annotation> <xsd:complexType name="IdasBooleanType"> <xsd:simpleContent> <xsd:extension base="xsd:boolean"> <xsd:attributeGroup ref="DefinitionXlinkGroup"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> <xsd:annotation> <xsd:documentation>Tipo para swe:Time</xsd:documentation> </xsd:annotation> <xsd:complexType name="IdasTimeType"> <xsd:simpleContent> <xsd:extension base="xsd:dateTime"> <xsd:attributeGroup ref="DefinitionXlinkGroup"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> <xsd:simpleType name="IdasTimeListType"> <xsd:list itemType="xsd:dateTime"/> </xsd:simpleType>

73 of 74

<xsd:simpleType name="IdasTimeRangeType"> <xsd:restriction base="IdasTimeListType"> <xsd:minLength value="1"/> <xsd:maxLength value="2"/> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="IdasTextType"> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attributeGroup ref="DefinitionXlinkGroup"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> <xsd:element name="quan" type="IdasQuantityType"/> <xsd:element name="bool" type="IdasBooleanType"/> <xsd:element name="time" type="IdasTimeType"/> <xsd:element name="text" type="IdasTextType"/> <xsd:annotation> <xsd:documentation>Tipo para introducir parametros. Se define como any para permitir introduir algun tipo nuevo no definido en esta version.</xsd:documentation> </xsd:annotation> <xsd:complexType name="IdasParameterType"> <xsd:sequence> <xsd:any/> </xsd:sequence> <xsd:attributeGroup ref="DefinitionXlinkGroup"/> </xsd:complexType> <xsd:annotation> <xsd:documentation>La definicion de una propiedad observable se realiza a travÃ©s de un atributo. Si es necesario solo se define uno como obligatorio.</xsd:documentation> </xsd:annotation> <xsd:complexType name="IdasObservedType"> <xsd:attributeGroup ref="DefinitionXlinkGroup"/> </xsd:complexType> <xsd:annotation> <xsd:documentation>El valor medido se representa con el tipo any por si es necesario incluir tipos no contemplados hasta ahora</xsd:documentation> </xsd:annotation> <xsd:complexType name="IdasMeasuredType"> <xsd:sequence> <xsd:any/> </xsd:sequence> <xsd:attributeGroup ref="DefinitionXlinkGroup"/> </xsd:complexType> <xsd:annotation> <xsd:documentation>Elemento correspondiente a samplingTime. Siempre sera en formato ISO8601. Si aparecen dos elementos separados por espacio en blanco se considera un periodo y si aparece un inico elemento sera un instante.</xsd:documentation> </xsd:annotation> <xsd:element name="stm" type="IdasTimeRangeType"/> <xsd:element name="param" type="IdasParameterType"/> <xsd:element name="what" type="IdasObservedType"/> <xsd:element name="data" type="IdasMeasuredType"/> <xsd:annotation>

74 of 74

<xsd:documentation>Una observacion incluye un atributo opcional id, por si es necesario incluir algun tipo de clave y el procedure</xsd:documentation> </xsd:annotation> <xsd:complexType name="IdasObservationType"> <xsd:sequence> <xsd:element ref="stm"/> <xsd:element ref="what"/> <xsd:element ref="param" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="data"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:string" use="optional"/> <xsd:attribute name="from" type="xsd:string" use="required"/> </xsd:complexType> <xsd:element name="obs" type="IdasObservationType"/> <xsd:complexType name="IdasInsertObservationType"> <xsd:sequence> <xsd:element ref="obs" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="from" type="xsd:string" use="optional"/> </xsd:complexType> <xsd:complexType name="IdasInsertObservationResponseType"> <xsd:attribute name="id" type="xsd:string"/> </xsd:complexType> <xsd:element name="io" type="IdasInsertObservationType"/> <xsd:complexType name="IdasOrientationType"/> <xsd:attributeGroup name="PositionGroup"> <xsd:attribute name="lframe" type="xsd:string" use="optional"/> <xsd:attribute name="rframe" type="xsd:string" use="required"/> </xsd:attributeGroup> <xsd:complexType name="IdasGeoWSG84Type"> <xsd:attribute name="lat" type="xsd:float"/> <xsd:attribute name="lon" type="xsd:float"/> <xsd:attribute name="alt" type="xsd:float" use="optional"/> </xsd:complexType> <xsd:element name="gps" type="IdasGeoWSG84Type"/> <xsd:complexType name="IdasCoordType"> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="value" type="xsd:string"/> </xsd:complexType> <xsd:element name="coord" type="IdasCoordType"/> <xsd:complexType name="IdasLocationType"> <xsd:sequence> <xsd:element ref="coord"/> </xsd:sequence> <xsd:attribute name="rframe" type="xsd:string" use="required"/> </xsd:complexType> <xsd:element name="loc" type="IdasLocationType"/> <xsd:element name="ior" type="IdasInsertObservationResponseType"/> </xsd:schema>

dca-idas device communication rest api€¦ · dca-idas device communication rest api date...

Documents