Categoría: IoT
FIWARE gestionado: Orion, IoT Agents y series temporales en vuestra cuenta
Vuestra plataforma FIWARE con el context broker, los agentes de dispositivos y el histórico funcionando como un solo sistema, con accesos protegidos, copias y actualizaciones al día.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Open source: Orion, Orion-LD e IoT Agents con AGPL-3.0; QuantumLeap, Keyrock y Wilma con MIT
En resumen
FIWARE es un conjunto de componentes de código abierto para gestionar datos de contexto, como el estado de sensores, vehículos o edificios, con las API NGSI-v2 y NGSI-LD. Montamos y operamos en vuestra cuenta el context broker (Orion u Orion-LD), los IoT Agents que traducen los protocolos de los dispositivos, QuantumLeap con su base de datos de series temporales y Keyrock con Wilma para la identidad y el acceso.
¿Qué nos encargamos de mantener?
Una plataforma FIWARE son varias piezas que se hablan por suscripciones: si una suscripción se cae o un agente pierde la conexión con el broker MQTT, el panel sigue mostrando el último valor y nadie nota que los datos ya no son de hoy. Nuestro trabajo es que eso se detecte en minutos.
Context broker
Orion u Orion-LD en varias réplicas, con MongoDB en replica set e índices revisados.
IoT Agents
Agentes para JSON, UltraLight 2.0 u otros protocolos, conectados al broker MQTT con TLS.
Histórico
QuantumLeap o Mintaka con su base de datos de series temporales y retención definida.
Identidad
Keyrock y Wilma, o el proveedor de identidad que ya tengáis, delante de todas las API.
Suscripciones
Estado de cada suscripción y de sus notificaciones fallidas, con alertas.
Actualizaciones
Versiones de cada componente fijadas, probadas juntas y actualizadas por orden.
¿Qué arquitectura recomendamos?
Los dispositivos publican en un broker MQTT o llaman por HTTP; los IoT Agents traducen esos mensajes a entidades NGSI y las actualizan en el context broker. El broker guarda solo el estado actual, así que para el histórico una suscripción envía cada cambio a QuantumLeap, que lo escribe en CrateDB o TimescaleDB. Con Orion-LD, la API temporal de NGSI-LD la da Mintaka, que lee la base de datos TimescaleDB que alimenta el propio Orion-LD.
| Situación | Lo que montamos | Por qué |
|---|---|---|
| Plataforma existente en NGSI-v2 | Orion, IoT Agents y QuantumLeap | Lo más probado y documentado del ecosistema |
| Proyecto nuevo que debe interoperar | Orion-LD con Mintaka y TimescaleDB | NGSI-LD de ETSI con API temporal |
| Requisitos que Orion-LD no cubre | Scorpio o Stellio, otros brokers NGSI-LD | Mismo estándar con otra arquitectura interna |
Todas las API quedan detrás de un proxy con autenticación: el broker no se expone a internet sin control de acceso, aunque los datos parezcan públicos.
¿Para quién es?
- Ayuntamientos y entidades públicas: quieren una plataforma de ciudad inteligente propia, con datos de tráfico, residuos, alumbrado o calidad del aire en un modelo común.
- Integradores de proyectos de ciudad o territorio: despliegan sensores y aplicaciones, y necesitan que alguien opere la plataforma después de la entrega.
- Empresas que reciben datos de una plataforma FIWARE: necesitan su propio broker o histórico para intercambiar datos con NGSI.
¿Qué problemas encontramos más a menudo?
- Plataforma entregada y sin operar: se montó para un proyecto y nadie la ha actualizado desde la entrega.
- Broker abierto sin autenticación: cualquiera puede leer o modificar entidades.
- Suscripciones caídas sin aviso: el histórico deja de crecer y se descubre al hacer un informe.
- MongoDB en un solo nodo y sin copia: el estado de todas las entidades vive en un disco.
- Versiones de imágenes sin fijar: un reinicio descarga una versión nueva y rompe algo.
- Modelos de datos inventados: cada proyecto nombra las entidades a su manera y no se pueden cruzar datos.
¿Cómo hacemos las copias y las actualizaciones?
Copiamos MongoDB, que guarda el estado de las entidades, las suscripciones y la configuración de los agentes, y la base de datos de series temporales; en TimescaleDB, con recuperación a un momento concreto como en PostgreSQL gestionado. Los grupos de servicio, las suscripciones y la configuración de cada componente están además en el repositorio. Restauramos periódicamente en un entorno de prueba y comprobamos que una medida de prueba llega del agente al histórico.
Cada componente de FIWARE tiene su propio ritmo de versiones. Fijamos la versión de cada imagen, leemos las notas antes de cambiarla, probamos el conjunto en un entorno aparte y actualizamos una pieza cada vez, empezando por las que no guardan estado.
¿Cómo es el soporte día a día?
Las métricas del broker, de MongoDB, de los agentes y de la base de datos de series temporales van a Prometheus y Grafana, como contamos en monitorización con Grafana y Prometheus, con alertas cuando una entidad o un grupo de sensores deja de actualizarse. Si usáis Keycloak para la identidad, lo gestionamos como en Keycloak para empresas. La vigilancia automática es continua; la respuesta humana, el siguiente día hábil en horario laboral, dentro del SRE como servicio. Cada mes recibís un informe con versiones, incidencias, crecimiento del histórico y cambios hechos.
- DispositivosMQTT o HTTP
- IoT AgentsTraducen a NGSI
- Orion u Orion-LDEstado actual, sobre MongoDB
- QuantumLeapHistórico por suscripción
- CrateDB o TimescaleDBSeries temporales
- GrafanaPaneles y alertas
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Los componentes en servidores cloud con Docker o en Kubernetes, con MongoDB y la base de datos de series temporales montadas por nosotros. | Ningún proveedor ofrece FIWARE gestionado: en todos los casos lo operamos nosotros. |
| AWS | Los componentes en EKS o EC2, con MongoDB propio o MongoDB Atlas y TimescaleDB en un PostgreSQL propio. | Comprobamos antes la compatibilidad si se propone una base de datos compatible con MongoDB en lugar de MongoDB. |
| Google Cloud | Los componentes en GKE o Compute Engine, con MongoDB propio o MongoDB Atlas. | |
| Azure | Los componentes en AKS o máquinas virtuales, con MongoDB propio o MongoDB Atlas. | |
| OVH | Los componentes en Public Cloud o en Managed Kubernetes, con MongoDB gestionado de OVHcloud o propio. | |
| Servidor propio | La plataforma completa en vuestros servidores o en el centro de datos de vuestra organización. | MongoDB necesita tres nodos para tener réplica de verdad; en una sola máquina, las copias son la única protección. |
Qué incluye
- Orion Context Broker para NGSI-v2 u Orion-LD para NGSI-LD, con MongoDB replicado detrás.
- IoT Agents (JSON, UltraLight 2.0 u otros) conectados a vuestro broker MQTT o por HTTP, con grupos de servicio y dispositivos declarados en código.
- QuantumLeap con CrateDB o TimescaleDB para el histórico, o Mintaka sobre TimescaleDB si el broker es Orion-LD.
- Keyrock como gestor de identidad y Wilma como proxy delante de las API, o Keycloak si ya lo usáis.
- Modelos de datos basados en Smart Data Models, revisados antes de dar de alta las entidades.
- Copias de MongoDB y de la base de datos de series temporales, con restauración de prueba.
- Métricas del broker, de los agentes y de las suscripciones, con alertas cuando dejan de llegar datos.
- Actualizaciones de cada componente ensayadas en un entorno aparte, con las imágenes y versiones fijadas.
Preguntas frecuentes
¿NGSI-v2 o NGSI-LD?
NGSI-v2 es más sencillo y lo usa Orion, con mucha documentación y despliegues. NGSI-LD es la especificación de ETSI, con contextos JSON-LD y relaciones entre entidades; lo implementan Orion-LD, Scorpio y Stellio. Para un proyecto nuevo que debe interoperar con otras plataformas solemos proponer NGSI-LD; si ya tenéis una plataforma en NGSI-v2 que funciona, no hay prisa por migrar.
¿FIWARE sirve para proyectos con financiación pública?
Muchas convocatorias de ciudad inteligente piden plataformas abiertas, interoperables y basadas en estándares, y FIWARE con NGSI-LD encaja con ese tipo de requisito. Pero si un proyecto es subvencionable lo deciden las bases de cada convocatoria y el órgano que la gestiona, no la tecnología elegida. Nosotros nos ocupamos de que la plataforma funcione y quede documentada.
¿Keyrock o Keycloak para la identidad?
Keyrock es el gestor de identidad de FIWARE y, con Wilma delante de las API, protege el broker con OAuth2. Los dos llevan tiempo con pocas versiones nuevas, así que revisamos su estado antes de proponerlos. Si vuestra organización ya tiene Keycloak u otro proveedor de identidad, suele ser mejor usarlo y poner delante de las API un proxy que valide sus tokens, para no mantener dos sistemas de usuarios.
¿Qué pasa con los datos si cae el context broker?
El estado actual de las entidades está en MongoDB y el histórico en la base de datos de series temporales, así que no se pierden. Mientras el broker está caído, los agentes no pueden actualizar las entidades; por eso, en producción, el broker va en varias réplicas y MongoDB en replica set.
¿Podéis hacer el proyecto de ciudad inteligente completo?
Nos ocupamos de la plataforma: instalar, proteger, vigilar, copiar y actualizar los componentes de FIWARE en vuestra cuenta. Los sensores, su instalación en calle y las aplicaciones de negocio encima de la plataforma suelen ser de otros equipos, con los que nos coordinamos.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el