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
1. 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 |
|
|
Comité
ejecutivo nacional |
Corredor
de bolsa Escorpio |
|
|
Sensinov |
Djane.io |
|
|
Asamblea
General Extraordinaria |
Corredor
de bolsa Stellio |
Estamos
actualizando esta lista
2. 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 |
Implementaciones
de código abierto de la API de SensorThings de OGC
|
Proveedor |
Nombre |
Enlace |
|
Geodán |
GOST |
|
|
52
Norte |
Servidor
web SensorWeb |
Implementaciones
de API de SensorThings de OGC
|
Proveedor |
Nombre |
Enlace |
|
SensorArriba |
API SensorThings v1.0 de SensorUp |
3. 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
1. 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 .
2. 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
3. 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
