Por: Carlos A. FERREYROS SOTO
Doctor en Derecho
Universidad de Montpellier I Francia.
RESUMEN
El presente artículo intenta explicar los Mecanismos de Interoperabilidad Mínimos, MIM, de la Propuesta de Marco Europeo de Interoperabilidad para Ciudades y Comunidades Inteligentes, EIF4SCC, basado en el objetivo de proporcionar a los dirigentes de la administración local de la Unión Europea definiciones, principios, recomendaciones, casos de uso práctico procedentes de ciudades y comunidades de toda Europa y de fuera de ella, y un modelo común para facilitar la prestación de servicios al público en todos los ámbitos, ciudades, regiones y fronteras.
El marco de la Propuesta se desarrolló aprovechando y buscando complementariedades con iniciativas anteriores y en curso, como el movimiento Living-in.EU, el Marco Europeo de Interoperabilidad de 2017, los Mecanismos de Interoperabilidad mínimos (MMI Plus) y los resultados de las iniciativas financiadas por la UE (Ejemplo, el Mecanismo «Conectar Europa» (MCE), los bloques digitales de las ciudades, el reto de las ciudades inteligentes, el reto de las ciudades inteligentes, la asociación para la transición digital en el marco de la Agenda Urbana) y los proyectos financiados por la UE (síntesis, Triangulum, etc.).
A fin de acceder a normas similares y estándares europeos, las empresas, organizaciones públicas y privados interesados en asesorías, consultorías, capacitaciones, estudios, evaluaciones, auditorías sobre el tema, sírvanse comunicar al correo electrónico:cferreyros@hotmail.com
____________________________________________________________________
Mecanismos de Interoperabilidad Mínimos : avanzando hacia el futuro digital de Europa
Comprender MIMS plus y el desarrollo de versiones de MIM
- 26 de agosto de 2024
- https://data.europa.eu/en/news-events/news/minimal-interoperability-mechanisms-advancing-europes-digital-future
La introducción de los mecanismos de interoperabilidad mínimos (MIM) supone un gran avance en la búsqueda de dar forma al futuro digital de Europa y garantizar un intercambio de datos sin fisuras en todo el continente. La interoperabilidad permite que distintos sistemas se comuniquen y compartan datos de forma eficaz entre sí. Los MIM son normas y especificaciones técnicas que ayudan a las ciudades, comunidades y proveedores a replicar datos o a permitir que estos fluyan fácilmente entre sistemas.
En Europa, MIMs Plus se desarrolló sobre la base del marco MIMs original para atender las necesidades específicas de las ciudades y la legislación europeas. Se trata de una iniciativa de Living-in.EU que promueve la soberanía digital y tiene como objetivo armonizar las soluciones de ciudades inteligentes en toda Europa. Al adoptar MIMs Plus, las ciudades europeas no solo pueden garantizar el cumplimiento de las normas de la UE, como la Ley de Interoperabilidad , sino que también permiten la integración de datos abiertos de diversas fuentes, como los conjuntos de datos de data.europa.eu .
Los MIM constan de varias versiones, siendo la última la versión 7 (MIM7) . Cada versión tiene un tema diferente, y la versión 7 cubre los «Lugares». Esto se relaciona con los datos geoespaciales y el desafío de las ciudades y comunidades para integrar datos, por ejemplo, farolas, edificios y datos de sensores. Otros ejemplos de temas de MIM que están disponibles son los contratos, la confianza y la transparencia. En el futuro, habrá un total de temas de MIM disponibles para el uso público.
La adopción de MIMs Plus es un gran paso hacia una Europa interoperable, sobre la que se puede obtener más información a través de nuestras noticias sobre interoperabilidad o ampliar sus conocimientos leyendo más sobre la conferencia SEMIC 2024. Los datos abiertos siguen facilitando el intercambio de datos para ciudades y comunidades, así que consulte nuestra plataforma periódicamente para mantenerse al día sobre los avances en interoperabilidad en Europa.
___________________________________°°°°°°°_____________________________________
MIM1 – Información de contexto
OASC MIM1: Información de contexto
Descripción
La información de contexto es la información necesaria para que los sistemas sean más adaptables a diferentes contextos dentro del mundo real.
- Ejemplos:
o Gestión del tráfico: MIM 1 puede agregar y estandarizar datos de varios sensores (cámaras de tráfico, estaciones meteorológicas, sistemas GPS de vehículos) en un formato unificado. Esto permite que los sistemas de gestión del tráfico ajusten automáticamente los tiempos de las señales y ofrezcan recomendaciones de ruta a los conductores en función de las condiciones del tráfico, el clima y los eventos en tiempo real, lo que reduce la congestión y mejora el flujo de tráfico.
o Gestión energética: MIM 1 puede facilitar la integración de datos de sensores en edificios públicos para ajustar dinámicamente la calefacción, la refrigeración y la iluminación en función de la ocupación y las condiciones climáticas, lo que reduce significativamente el desperdicio de energía y los costos operativos.
o Seguridad pública: al integrar y estandarizar datos de múltiples fuentes, incluidos CCTV y alertas de emergencia, MIM 1 mejora las capacidades de respuesta en tiempo real, lo que permite un despliegue más rápido de los servicios de emergencia durante eventos críticos, mejorando así la seguridad pública y la resiliencia.
- Literatura:
o Dey et al. (2001) definen Contexto como “cualquier información que pueda utilizarse para caracterizar la situación de una entidad”.
o Rocha et al. (2012) define la gestión de contexto como un proceso informático dinámico que utiliza «sujetos» de datos en una aplicación para señalar datos residentes en una aplicación separada que también contienen el mismo sujeto.
Objetivos
- Permitir que la información de contexto de diferentes sistemas dentro o entre organizaciones, como ciudades o comunidades, que proviene de fuentes heterogéneas, se reúna mediante una API basada en la Web.
- Permitir el uso, la reutilización y el intercambio integrales e integrados de datos, así como la gestión de la información de contexto.
- Convertir los datos en un recurso estratégico
Capacidades y requisitos
C1: Las aplicaciones pueden acceder a datos de diferentes fuentes (como ciudades, comunidades y soluciones verticales).
| Requisitos C1: |
| R1: El contexto se puede gestionar a través de la Web |
| R2: La información de todas las fuentes debe utilizar los mismos conceptos, llamados modelos de información de datos |
C2: Las aplicaciones pueden utilizar datos actuales e históricos, utilizar consultas geoespaciales y actualizarse automáticamente cuando cambian los datos de origen.
| Requisitos C2: |
| R3: La API basada en web deberá admitir la recuperación de datos actuales |
| R4: La API basada en web debe admitir la recuperación de datos históricos cuando corresponda |
| R5: La API basada en web debe admitir consultas geoespaciales cuando corresponda |
| R6: La API basada en web debe admitir la suscripción a los cambios cuando corresponda |
C3: Las aplicaciones pueden descubrir y recuperar datos relevantes para su contexto desde una variedad de fuentes
| Requisitos C3: |
| R7: Las fuentes de datos relevantes para cualquier contexto requerido (como ubicación y/o período de tiempo) deben poder descubrirse y recuperarse según su contexto. |
C4: Las aplicaciones pueden recuperar un subconjunto de datos de un conjunto de datos más grande
| Requisitos C4: |
| R8: Se deben poder recuperar subconjuntos específicos de datos relevantes para el contexto dentro de conjuntos de datos más grandes y se pueden establecer límites de tamaño. |
Mecanismos
- ETSI NGSI-LD
| Requisitos | Mecanismo NGSI-LD |
| R1: El contexto se puede gestionar a través de la Web | La API NGSI-LD es una API de gestión de contexto uniforme que proporcionan diferentes aplicaciones de gestión de contexto. Permite la gestión del contexto a través de una API REST. |
| R2: La información de todas las fuentes debe utilizar los mismos conceptos, llamados modelos de información de datos | Esto se proporciona a través del modelo de información común NGSI-LD, que es el metamodelo en el que se basa la API. El mundo (NGSI-LD) consta de entidades que pueden tener propiedades, relaciones, etc. |
| R3: La API basada en web debe admitir la recuperación de datos más recientes | Desde la perspectiva de la terminología NGSI-LD, se recuperarían una o más entidades con sus atributos. Se pueden restringir los atributos que se devolverán como parte de la entidad a los proporcionados en “attrs”, que es un parámetro URI. Se pueden descubrir todas las entidades en función de sus características especificando su tipo. La llamada API a utilizar es GET /entities |
| R4: La API basada en web debe admitir la recuperación de datos históricos | Los datos históricos se almacenan en Context Broker y se puede acceder a ellos de forma similar a como se pueden recuperar los datos más recientes. La llamada API a utilizar es GET /entities/temporal |
| R5: La API basada en web debe admitir consultas geoespaciales | Las entidades y las fuentes de contexto tienen propiedades de ubicación en GeoJSON. Las entidades y las fuentes de contexto se pueden geoconsultar especificando una relación geográfica como cerca, dentro,… La llamada API a utilizar es GET /entities or GET /CSourceRegistrations |
| R6: La API basada en web debe admitir la suscripción a los cambios | Esto se puede hacer publicando un objeto de suscripción. La llamada API que se debe utilizar es: POST /subscriptions/ |
| R7: Las fuentes de datos relevantes para cualquier contexto requerido (al menos ubicación y período de tiempo) deben ser detectables y recuperables según su contexto. | Esto se puede hacer usando una consulta de tipo. La llamada API a utilizar es GET /CSourceRegistrations |
| R8: Se deben poder recuperar subconjuntos específicos de datos relevantes para el contexto a partir de conjuntos de datos más grandes y con límites y tamaños de página predeterminados. | NGSI-LD es independiente de mecanismos de paginación específicos, pero requiere que los sistemas NGSI-LD admitan y definan límites y tamaños de página predeterminados. |
Implementaciones de referencia ETSI NGSI-LD
La siguiente tabla enumera las implementaciones de referencia del estándar NGSI que conoce OASC. Si conoce otras implementaciones de referencia, compártalas en la sección de comentarios.
Tenga en cuenta que esta lista tiene un propósito puramente informativo. OASC no garantiza que las implementaciones de referencia enumeradas funcionen en entornos técnicos locales y no se hace responsable de las implementaciones enumeradas.
| Proveedor | Nombre | Enlace |
| FIWARE | Agente de contexto Orion | https://github.com/FIWARE/context.Orion-LD |
| Comité ejecutivo nacional | Corredor de bolsa Escorpio | https://github.com/ScorpioBroker/ScorpioBroker |
| Sensinov | Djane.io | https://github.com/sensinov/djane |
| Asamblea General Extraordinaria | Corredor de bolsa Stellio | https://github.com/stellio-hub/stellio-context-broker |
Estamos actualizando esta lista
- ISO 19156 Observaciones, mediciones y muestras
Este mecanismo necesita más perfeccionamiento
El estándar Observaciones, Mediciones y Muestras (OMS), preparado y publicado conjuntamente por el Consorcio Geoespacial Abierto e ISO/TC 211 como OGC Abstract Specification Topic 20 ( OGC 20-082r4 ) e ISO 19156:2023 , define un esquema conceptual para las observaciones, para las características involucradas en el proceso de observación y para las características involucradas en el muestreo al hacer observaciones. Los modelos respaldan el intercambio de información que describe los actos de observación y sus resultados, tanto dentro como entre diferentes comunidades científicas y técnicas. El estándar OGC SensorThings API es una implementación de API RESTful de ODATA de la especificación abstracta OMS ( ISO 19156-2023) .
SensorThings API ( OGC 18-088 (v1.1) y ITU-T REC Y-4473 ) utiliza el modelo de referencia de IoT adaptado de [ITU-T Y.2060] y sigue la definición de ITU-T: “ un 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 ”. OGC busca alinearse con otras iniciativas como la Web of Things del W3C .
El desarrollo de los estándares se lleva a cabo en GitHub .
| Requisitos | Mecanismo API de SensorThings |
| R1: El contexto se puede gestionar a través de la Web | La API SensorThings proporciona una API RESTful ODATA que proporciona todo el acceso (Crear, Leer, Actualizar, Eliminar – CRUD) a las observaciones y a todos los elementos de contexto. |
| R2: La información de todas las fuentes debe utilizar los mismos conceptos, llamados modelos de información de datos | La API de SensorThings es una implementación del modelo OMS abstracto ISO 19156. OMS define todos los conceptos y garantiza que sean consistentes. |
| R3: La API basada en web debe admitir la recuperación de datos más recientes | La API proporciona acceso (lectura) a la información más reciente (actual) de todas las entidades en el contexto. Ejemplo GET /v1.0/Observations GET /v1.0/Things GET /v1.0/Sensors GET /v1.0/Datastreams(1)/Observations … |
| R4: La API basada en web debe admitir la recuperación de datos históricos | Varios elementos del contexto tienen marcas de tiempo (todos se pueden usar para recuperar información histórica): ubicaciones históricas de la cosa y observaciones (PhenomenonTime, ResultTime y ValidTime). Ejemplo: GET /v1.0/Observations?$filter=phenomenonTime lt ‘2016-11-24T14:37:01.000Z’ GET /Things?$expand=Datastreams/Observations/FeatureOfInterest&$filter=Datastreams/Observations/FeatureOfInterest/name eq ‘Rue du Luxembourg 19-21 1000 Brussels’ and Datastreams/Observations/phenomenonTime ge 2017-01-01T00:00:00.000Z and Datastreams/Observations/phenomenonTime le 2017-03-01T00:00:00.000Z GET /v1.0/HistoricalLocations?$filter=time lt ‘2016-11-24T14:37:01.000Z’ |
| R5: La API basada en web debe admitir consultas geoespaciales | Las consultas geoespaciales en la API de SensorThings definen nueve funciones geoespaciales basadas en la relación espacial entre dos objetos geométricos. Las funciones de relación espacial se definen en la especificación de acceso simple a funciones ISO19125 . Ejemplo: GET /v1.0/Locations?$filter=st_equals(location,geography’POINT(4.3679 50.84)’) |
| R6: La API basada en web debe admitir la suscripción a los cambios | La API de SensorThings proporciona capacidades de publicación y suscripción mediante MQTT. Ejemplo: Suscribirse av1.1/Datastreams(1)/Observations |
| R7: Las fuentes de datos relevantes para cualquier contexto requerido (al menos ubicación y período de tiempo) deben ser detectables y recuperables según su contexto. | La información de contexto (incluidos los modelos de datos externos) (proporcionada, por ejemplo, por enlaces RDF en la información del sensor) se puede encontrar y recuperar mediante inferencia semántica. |
| R8: Se deberían poder recuperar subconjuntos específicos de datos relevantes para el contexto a partir de conjuntos de datos más amplios | Las opciones de consulta de SensorThings se pueden clasificar en dos grupos diferentes. El primer grupo especifica las propiedades que devolverá la solicitud. $expand y $select son opciones de consulta de este grupo. El segundo grupo limita, filtra o reordena los resultados de la solicitud. Este grupo contiene $orderby, $top, $skip, $count y $filter. Ejemplo: /v1.0/Datastreams(id)?$expand=Observations,ObservedProperty /v1.0/Observations?$top=3&$orderby=phenomenonTime desc |
Implementaciones de referencia de API de OGC SensorThings
La siguiente tabla enumera las implementaciones (de referencia) del estándar API de SensorThings que conoce OASC. Si conoce otras implementaciones de referencia, compártalas en la sección de comentarios.
Tenga en cuenta que esta lista tiene un propósito puramente informativo. OASC no garantiza que las implementaciones enumeradas (de referencia) funcionen en entornos técnicos locales y no se hace responsable de las implementaciones enumeradas.
| Proveedor | Nombre | Enlace |
| OSB Fraunhofer | HELADA | https://github.com/FraunhoferIOSB/FROST-Server |
Implementaciones de código abierto de la API de SensorThings de OGC
| Proveedor | Nombre | Enlace |
| Geodán | GOST | https://github.com/gost/server |
| 52 Norte | Servidor web SensorWeb | https://github.com/52North/sensorweb-server-sta |
Implementaciones de API de SensorThings de OGC
| Proveedor | Nombre | Enlace |
| SensorArriba | API SensorThings v1.0 de SensorUp | https://www.sensorup.com |
- LDES
| Requisitos | Mecanismo LDES |
| R1: El contexto se puede gestionar a través de la Web | La especificación Linked Data Event Streams (LDES — https://w3id.org/ldes/specification ) utiliza HTTP y RDF como interfaz basada en web para la reutilización de modelos de dominio, la definición del esquema (SHACL), descripciones de la interfaz API (hipermedia TREE — https://w3id.org/tree/specification ), contexto y datos de instancia. Un servidor que publica LDES se puede gestionar de varias formas. Flanders pone a disposición una implementación de referencia. La documentación se puede encontrar aquí: https://informatievlaanderen.github.io/VSDS-Tech-Docs/introduction/LDES_server . |
| R2: La información de todas las fuentes debe utilizar los mismos conceptos, llamados modelos de información de datos | Cada LDES contiene información sobre cómo se estructuran los objetos miembros en función de formas SHACL bien definidas. En toda la Web, promueve la reutilización de vocabularios de datos vinculados. |
| R3: La API basada en web debe admitir la recuperación de datos más recientes | Un LDES es un registro de miembros que solo se puede agregar y, por lo tanto, de manera predeterminada, un servidor mantiene el historial completo. Además de una vista, puede documentar una política de retención en la que el servidor indica que los datos se eliminarán del servidor después de un cierto período de tiempo o una cierta cantidad de miembros. Los terceros deben leer las políticas de retención para comprender qué subconjunto de los datos se puede recuperar. Pueden decidir, en función de ellas, archivar estos miembros. La vista predeterminada que debería estar disponible sobre un LDES es la Fuente de eventos. La Fuente de eventos permite que todos los agentes de usuario interesados en este conjunto de datos repliquen el historial, pero también se mantengan sincronizados. LDES establece que los «datos más recientes» son relativos a la vista que desea crear. Por ejemplo, si está interesado en crear una descripción general de los trenes cancelados, entonces procesará una fuente de eventos de manera diferente. LDES admite múltiples estrategias de gobernanza de datos, como el uso de objetos de versión (se puede indicar mediante ldes:versionOfPath) o mediante la descripción de un registro de eventos reutilizando, por ejemplo, ActivityStreams2.0 |
| R4: La API basada en web debe admitir la recuperación de datos históricos | Ver R3: LDES proporciona datos históricos y en vivo en la misma interfaz. |
| R5: La API basada en web debe admitir consultas geoespaciales | La funcionalidad geoespacial se puede lograr de dos maneras: 1. O bien puede utilizar una canalización de LDES a servicio en la que replica el conjunto de datos completo en un software geoespacial de su elección. 2. Publica secuencias de eventos de datos vinculados fragmentados geoespacialmente (consulte https://informatievlaanderen.github.io/VSDS-LDESServer4J/configuration/fragmentations/geospatial ) En 2, al publicar una fragmentación geoespacial, permite que un agente de consulta seleccione los fragmentos correctos justo a tiempo. |
| R6: La API basada en web debe admitir la suscripción a los cambios | La fuente de eventos LDES es una vista especializada para la replicación y sincronización en la misma interfaz que R4 y R5. Con un cliente LDES, un agente puede mantenerse actualizado con los últimos cambios. |
| R7: Las fuentes de datos relevantes para cualquier contexto requerido (al menos ubicación y período de tiempo) deben ser detectables y recuperables según su contexto. | El descubrimiento de datos funciona a través de portales de datos DCAT-AP que indican que su dcat:Dataset también es un ldes:EventStream y que su dcat:DataService también es un tree:ViewDescription. En un ldes:EventStream, habrá una forma SHACL definida que muestra qué propiedades se están utilizando dentro de los miembros. Con eso, puede seleccionar las propiedades de interés y usar ese conjunto de datos en otros contextos también. El ldes:EventStream también tiene dos propiedades: · ldes:timestampPath apunta a una propiedad en el miembro que se ocupará del orden cronológico (por ejemplo, dcterms:modified) · ldes:versionOfPath apuntará a la propiedad que se utiliza para indicar de qué versión es este miembro (por ejemplo, dcterms:isVersionOf). Esto también le permite crear un estado más reciente si su conjunto de datos consta de objetos de versión. En la parte superior de un árbol:ViewDescription se puede describir una política de retención o puede contener sugerencias para los agentes de consulta sobre si estas vistas están especializadas en un determinado caso de uso. |
| R8: Se deberían poder recuperar subconjuntos específicos de datos relevantes para el contexto a partir de conjuntos de datos más amplios | LDES se basa en la especificación de hipermedia TREE que permite fragmentar flujos de eventos en árboles de búsqueda. Estos árboles de búsqueda permiten que el cliente se mantenga sincronizado o replique el historial completo de un subconjunto. El servidor es quien decide qué granularidad y tipo de fragmentaciones publicar. |
Cumplimiento y conformidad
- ETSI NGSI-LD ETSI organizó un grupo de trabajo de pruebas (TTF) para crear un kit de herramientas de pruebas para validar los agentes de contexto de acuerdo con la especificación NGSI-LD. EGM, Ubiwhere y OASC colaboraron en este grupo de trabajo para crear este kit de herramientas. El resultado fue un conjunto de descripciones de pruebas claras y definidas, propósitos de pruebas y scripts de robot ejecutables. Toda esta información se puede encontrar en el sitio web de ETSI CIM https://www.etsi.org/committee/cim .
- API de SensorThings La especificación de la API de SensorThings incluye clases de conformidad como parte de la especificación, que se utilizan como parte del conjunto de pruebas. (Ejemplo: https://docs.ogc.org/is/18-088/18-088.html#datastream ) OGC proporciona un conjunto de pruebas de conformidad que verifica la conformidad con la API de SensorThings (STA) 1.0. https://cite.opengeospatial.org/teamengine/about/sta10/1.0/site/ y https://github.com/opengeospatial/ets-sta10
- LDES Flanders reutilizó el banco de pruebas de interoperabilidad (ITB) de Joinup para crear pruebas de cumplimiento para las instancias de LDES Server. Definió múltiples pruebas de cumplimiento que pueden ser utilizadas por organizaciones que creen su propia implementación de LDES Server para verificar el cumplimiento con la especificación de LDES. El código se puede encontrar aquí: https://github.com/Informatievlaanderen/VSDS-Testbed
