SensorThings API [1] es un estándar del Open Geospatial Consortium (OGC) que proporciona un marco abierto y unificado para interconectar dispositivos de detección, datos y aplicaciones de IoT a través de la Web. Es un estándar abierto que aborda la interoperabilidad sintáctica y la interoperabilidad semántica del Internet de las cosas. Complementa los protocolos de red de IoT existentes como CoAP , MQTT , HTTP , 6LowPAN . Si bien los protocolos de red de IoT mencionados anteriormente abordan la capacidad de diferentes sistemas de IoT para intercambiar información, la API OGC SensorThings aborda la capacidad de diferentes sistemas de IoT para usar y comprender la información intercambiada. Como estándar OGC, SensorThings API también permite una fácil integración en infraestructuras de datos espaciales o sistemas de información geográfica existentes .
La API OGC SensorThings tiene dos partes: (1) Parte I: Detección y (2) Parte II: Tareas. OGC SensorThings API Parte I - Sensing se publicó para comentarios públicos el 18 de junio de 2015. [2] El Comité Técnico (TC) de OGC aprueba el inicio de la votación electrónica el 3 de diciembre de 2015, y SensorThings API Part I - Sensing aprobó el TC votación el 1 de febrero de 2016. La especificación estándar oficial OGC se publicó en línea el 26 de julio de 2016. En 2019, la API SensorThings también se publicó como Especificación Técnica UIT-T de las Naciones Unidas. [3]
OGC SensorThings API Parte II - Tasking Core se lanzó para comentarios públicos el 20 de febrero de 2018, [4] y pasó la votación del TC el 1 de junio de 2018. Se publicó la especificación estándar oficial de OGC para SensorThings API Parte II - Tasking Core en línea el 8 de enero de 2019.
Para ofrecer una mejor experiencia a los desarrolladores, el documento de debate SensorThings API Parte II - Tasking Core se publicó en línea el 18 de diciembre de 2018. El documento de debate Tasking Core proporciona 15 ejemplos JSON que muestran cómo se puede utilizar SensorThings API Parte II - Tasking Core.
La API SensorThings está diseñada específicamente para dispositivos IoT con recursos limitados y la comunidad de desarrolladores web. Sigue los principios REST , la codificación JSON y el protocolo OASIS OData y las convenciones de URL. Además, tiene una extensión MQTT que permite a los usuarios/dispositivos publicar y suscribirse a actualizaciones desde los dispositivos, y puede usar CoAP además de HTTP.
La base de la API SensorThings es su modelo de datos que se basa en la norma ISO 19156 (ISO/OGC Observations and Measurements ), que define un modelo conceptual para las observaciones y para las características involucradas en el muestreo al realizar observaciones. En el contexto de SensorThings, las funciones se modelan como Cosas , Sensores ( es decir , Procedimientos en O&M) y Funciones de interés . Como resultado, la API SensorThings proporciona una vista de enfoque de observación interoperable, que es particularmente útil para conciliar las diferencias entre sistemas de detección heterogéneos (por ejemplo, sensores in situ y sensores remotos).
Un dispositivo o sistema de IoT se modela como una cosa . Una cosa tiene un número arbitrario de ubicaciones (incluidas 0 ubicaciones ) y una cantidad arbitraria de flujos de datos (incluidos 0 flujos de datos ). Cada flujo de datos observa una propiedad observada con un sensor y el sensor recopila muchas observaciones . Cada Observación observa una FeatureOfInterest particular . El modelo basado en O&M permite a SensorThings acomodar dispositivos IoT heterogéneos y los datos recopilados por los dispositivos. [5]
SensorThings API proporciona dos funcionalidades principales, cada una manejada por una pieza. Los dos perfiles son la parte de detección y la parte de tareas. La parte Sensing proporciona una forma estándar de administrar y recuperar observaciones y metadatos de sistemas de sensores de IoT heterogéneos, y las funciones de la parte Sensing son similares al Servicio de observación de sensores OGC . La parte de Tareas proporciona una forma estándar de parametrización (también llamada tareas) de dispositivos IoT con capacidad de tareas, como sensores o actuadores. Las funciones de la parte de tareas son similares al servicio de planificación de sensores OGC. La parte de detección está diseñada en base al modelo de observaciones y mediciones (O&M) ISO/OGC y permite a los dispositivos y aplicaciones de IoT CREAR, LEER, ACTUALIZAR y BORRAR ( es decir , HTTP POST, GET, PATCH y BORRAR) datos de IoT y metadatos en un servicio SensorThings.
SensorThings API Parte I: Sensing define los siguientes recursos. Como SensorThings es un servicio web RESTful, cada entidad se puede CREAR, LEER, ACTUALIZAR y ELIMINAR con verbos HTTP estándar ( POST , GET , PATCH y DELETE): [6] [7]
Thing: Objeto del mundo físico (cosas físicas) o del mundo de la información (cosas virtuales) que es capaz de ser identificado e integrado en redes de comunicación. [8]Locations: Localiza la cosa o las cosas con las que está asociada.HistoricalLocations: Conjunto proporciona las ubicaciones actual (es decir, la última conocida) y anterior de la cosa con su tiempo.Datastream: Una colección de Observaciones y las Observaciones en un Flujo de Datos miden la misma Propiedad Observada y son producidas por el mismo Sensor .ObservedProperty : Especifica el fenómeno de una Observación .Sensor : Instrumento que observa una propiedad o fenómeno con el objetivo de producir una estimación del valor de la propiedad.Observation: Acto de medir o determinar de otro modo el valor de una propiedad. [9]FeatureOfInterest: Una observación da como resultado la asignación de un valor a un fenómeno. El fenómeno es una propiedad de una característica, siendo esta última la característica de interés de la observación . [9]Además de los recursos de detección anteriores, SensorThings API Parte II - Tasking Core define los siguientes recursos: [10]
TaskingCapabilities: Especifica los parámetros de tarea de un actuador.Tasks: una colección de tareas que se ha creado.Actuator : Un tipo de transductor que convierte una señal en alguna acción o fenómeno del mundo real. [11]http://example.org/v1.0/Datastream(id)/Observations
{ "@iot.count" : 2 , "valor" : [ { "@iot.id" : 1 , "@iot.selfLink" : "http://example.org/v1.0/Observations(1)" , "fenómenoTiempo" : "2016-01-01T05:00:00.000Z" , "resultado" : "-9" , "horaResultado" : nulo , "[email protected]" : "http://example.org/v1.0/Observations(1)/Datastream" , "[email protected]" : "http://example.org/v1.0/Observations(1)/FeatureOfInterest" }, { "@iot.id" : 2 , "@iot.selfLink" : "http://example.org/v1.0/Observations(2)" , "fenómenoTiempo" : "2016-01-01T04:00:00.000Z" , "resultado" : "-10" , "horaResultado" : nulo , "[email protected]" : "http://example.org/v1.0/Observations(2)/Datastream" , "[email protected]" : "http://example.org/v1.0/Observations(2)/FeatureOfInterest" } ]}Para reducir el tamaño de los datos transmitidos a través de la red, la extensión de matriz de datos API de SensorThings permite a los usuarios solicitar múltiples entidades de observación y formatear las entidades en el formato dataArray. Cuando un servicio SensorThings devuelve una respuesta de dataArray, el servicio agrupa entidades de observación por Datastream o MultiDatastream, lo que significa que las entidades de observación que se vinculan al mismo Datastream o al mismo MultiDatastream se agregan en un dataArray.
http://example.org/v1.0/Observations?$resultFormat=dataArray
{ "valor" : [ { "[email protected]" : "http://example.org/v1.0/Datastreams(1)" , "componentes" : [ "identificación" , "fenómenoTiempo" , "horaResultado" , "resultado" ], "[email protected]" : 3 , "matriz de datos" : [ [ 1 , "2005-08-05T12:21:13Z" , "2005-08-05T12:21:13Z" , 20 ], [ 2 , "2005-08-05T12:22:08Z" , "2005-08-05T12:21:13Z" , 30 ], [ 3 , "2005-08-05T12:22:54Z" , "2005-08-05T12:21:13Z" , 0 ] ] } ]}Interoperabilidad entre OpenIoT y SensorThings " Creemos que la implementación de la API SensorThing será una mejora importante para el middleware OpenIoT. Le dará a OpenIoT una interfaz estandarizada y verdaderamente fácil de usar para los valores de los sensores. Esto complementará los ricos servicios de razonamiento semántico con una interfaz simple basada en recursos. Y el mapeo consistente del modelo de datos brinda a ambos un contexto común para describir el Internet de las cosas ". [12]
Eficiencia de la API de SensorThings Una evaluación exhaustiva de la API de SensorThings está publicada en Jazayeri, Mohammad Ali, Steve HL Liang y Chih-Yuan Huang. "Implementación y Evaluación de Cuatro Estándares Abiertos Interoperables para Internet de las Cosas". Sensores 15.9 (2015): 24343-24373.
La API SensorThings se demostró en un proyecto piloto [13] patrocinado por la Dirección de Ciencia y Tecnología del Departamento de Seguridad Nacional . El Dr. Reginald Brothers, subsecretario de Ciencia y Tecnología de Seguridad Nacional, quedó "impresionado con el 'estado de lo práctico' en el que estos diversos sensores industriales se pueden integrar hoy en día utilizando estándares abiertos que eliminan las limitaciones de las tecnologías únicas. [ 14] "
En marzo de 2016, SensorUp y GeoSensorWeb Lab de la Universidad de Calgary presentaron una propuesta de proyecto de software de código abierto a la Fundación Eclipse y fue aprobada. El proyecto se llama Bigotes. [15] Whiskers es un marco API de OGC SensorThings. Tendrá un cliente JavaScript y un servidor liviano para dispositivos de puerta de enlace de IoT (por ejemplo, Raspberry Pi o BeagleBone). Whiskers tiene como objetivo fomentar un ecosistema de IoT abierto y saludable, en lugar de uno dominado por silos de información patentados. Whiskers tiene como objetivo facilitar el desarrollo de SensorThings para el gran y creciente mundo de los desarrolladores de IoT.
GOST [16] es una implementación de código abierto de la API SensorThings en el lenguaje de programación Go iniciada por Geodan. Contiene software de servidor fácilmente implementable y un cliente JavaScript. Actualmente (junio de 2016) está en desarrollo pero ya se puede descargar e implementar una primera versión. El software se puede instalar en cualquier dispositivo que admita Docker o Go (por ejemplo, Windows, Linux, Mac OS y Raspberry Pi). De forma predeterminada, los datos del sensor se almacenan en una base de datos PostgreSQL .
FROST-Server [17] es una implementación de servidor de código abierto de la API OGC SensorThings. FROST-Server implementa toda la especificación, incluidas todas las extensiones. Está escrito en Java y puede ejecutarse en Tomcat o Wildfly y está disponible como una imagen de Docker. Entre sus muchas características está la capacidad de utilizar ID de entidad basados en cadenas o UUID.
FROST-Client [18] es una biblioteca cliente Java para comunicarse con un servidor compatible con SensorThings API.
SensorThings HcDT [19] es una biblioteca de gráficos JavaScript para la API OGC SensorThings. Se basa en la biblioteca Highcharts y DataTables de código abierto [ se necesita aclaración ] . Es una biblioteca de gráficos front-end que permite a los desarrolladores conectarse a flujos de datos desde cualquier servicio API de OGC SensorThings y mostrar las observaciones del sensor en gráficos, tablas o widgets de panel para aplicaciones web.
Mozilla desarrolló una implementación de nodo de la API OGC SensorThings. [20]
52N SensorThingsAPI [21] es una implementación de código abierto de la API OGC SensorThings. Sus características principales son la interoperabilidad con el 52N SOS que implementa el servicio de observación de sensores OGC , asignaciones de bases de datos personalizables y varias extensiones convenientes. Se puede implementar como un contenedor Docker, dentro de Apache Tomcat o como una aplicación independiente.
En 2019, el experimento operativo Shaken Fury [22] para el programa Next Generation First Responder del DHS describe un escenario de un terremoto que causa un colapso estructural parcial y una fuga de HAZMAT en un estadio. La API OGC SensorThings se utiliza como interfaz estándar [23] que interconecta múltiples sensores y ofrece conciencia situacional en tiempo real habilitada para IoT.
El 8 de octubre de 2016, [24] un grupo de voluntarios (ciudadanos inteligentes) en Calgary se reunieron, ensamblaron sus propios sensores, los instalaron en sus casas y formaron una red colectiva de sensores de calidad del aire. Todos los datos están disponibles públicamente a través de la API OGC SensorThings. [25] Estos esfuerzos de detección ciudadana aumentaron el número de sensores de calidad del aire de Calgary de 3 a más de 50.
Emisión inteligente [26] es un proyecto de monitoreo de la calidad del aire en la ciudad de Nijmegen, NL. El proyecto implementó múltiples sensores de calidad del aire en toda la ciudad. Los datos se publican con estándares abiertos, incluida la API OGC SensorThings. Parte del proyecto es un motor ETL de código abierto para cargar los datos del sensor del proyecto en una API OGC SensorThings. [27]
Este panel proporciona una visualización del lado del cliente fácil de usar de los datos de los sensores de Internet de las cosas desde servidores compatibles con la API OGC SensorThings. Se pueden organizar y configurar varios tipos de widgets en el panel. Es una aplicación web y puede integrarse en cualquier sitio web. Una demostración en vivo está disponible en la página del proyecto. https://github.com/SensorThings-Dashboard/SensorThings-Dashboard
GOST Dashboard v2 es una biblioteca de código abierto de elementos HTML personalizados (componentes web) que admiten la API SensorThings. Estos elementos facilitan el desarrollo de aplicaciones HTML que integran funcionalidad y datos de servicios compatibles con SensorThings API. Los componentes están desarrollados con Predix-UI y Polymer.
El conector permite la interoperabilidad entre fuentes de datos compatibles con OGC y el middleware semántico [28] desarrollado en el proyecto AFarCloud de Horizonte 2020 ECSEL. Es una aplicación Java modular con implementación basada en Docker, implementada según el Estándar de implementación 15-078r6 OGC SensorThings API 1.0.
SensorThings API proporciona funciones similares al OGC Sensor Observation Service , una especificación de OGC aprobada en 2005. Ambas especificaciones estándar se encuentran bajo el conjunto de estándares OGC Sensor Web Enablement . La siguiente tabla resume la diferencia técnica entre las dos especificaciones. [29]
{{cite web}}: |last=tiene nombre genérico ( ayuda )Mantenimiento CS1: varios nombres: lista de autores ( enlace )