Category: IoT
Managed FIWARE: Orion, IoT Agents and time series in your own account
Your FIWARE platform with the context broker, the device agents and the history working as a single system, with protected access, backups and up-to-date versions.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
- Licence
- Open source: Orion, Orion-LD and IoT Agents under AGPL-3.0; QuantumLeap, Keyrock and Wilma under MIT
In short
FIWARE is a set of open source components for managing context data, such as the state of sensors, vehicles or buildings, through the NGSI-v2 and NGSI-LD APIs. We set up and run in your account the context broker (Orion or Orion-LD), the IoT Agents that translate device protocols, QuantumLeap with its time series database, and Keyrock with Wilma for identity and access.
What do we look after?
A FIWARE platform is several pieces that talk to each other through subscriptions: if a subscription drops or an agent loses its connection to the MQTT broker, the dashboard keeps showing the last value and nobody notices that the data is no longer today’s. Our job is to make sure that is detected within minutes.
Context broker
Orion or Orion-LD as several replicas, with MongoDB as a replica set and reviewed indexes.
IoT Agents
Agents for JSON, UltraLight 2.0 or other protocols, connected to the MQTT broker over TLS.
History
QuantumLeap or Mintaka with its time series database and a defined retention.
Identity
Keyrock and Wilma, or the identity provider you already have, in front of every API.
Subscriptions
Status of each subscription and its failed notifications, with alerts.
Upgrades
Versions of each component pinned, tested together and upgraded in order.
Which architecture do we recommend?
Devices publish to an MQTT broker or call over HTTP; the IoT Agents translate those messages into NGSI entities and update them in the context broker. The broker only stores the current state, so for the history a subscription sends every change to QuantumLeap, which writes it to CrateDB or TimescaleDB. With Orion-LD, the NGSI-LD temporal API is provided by Mintaka, which reads the TimescaleDB database that Orion-LD itself feeds.
| Situation | What we set up | Why |
|---|---|---|
| Existing NGSI-v2 platform | Orion, IoT Agents and QuantumLeap | The most proven and documented part of the ecosystem |
| New project that has to interoperate | Orion-LD with Mintaka and TimescaleDB | ETSI NGSI-LD with a temporal API |
| Requirements that Orion-LD does not cover | Scorpio or Stellio, other NGSI-LD brokers | Same standard with a different internal architecture |
Every API sits behind a proxy with authentication: the broker is never exposed to the internet without access control, even if the data looks public.
Who is it for?
- Local councils and public bodies: they want a smart city platform of their own, with traffic, waste, street lighting or air quality data in a common model.
- Integrators of city or regional projects: they deploy sensors and applications, and need someone to run the platform after handover.
- Companies that receive data from a FIWARE platform: they need their own broker or history to exchange data with NGSI.
Which problems do we come across most often?
- Platform handed over and never operated: it was set up for a project and nobody has upgraded it since the handover.
- Open broker with no authentication: anyone can read or modify entities.
- Subscriptions that fail silently: the history stops growing and it is discovered when someone writes a report.
- MongoDB on a single node with no backup: the state of every entity lives on one disk.
- Unpinned image versions: a restart pulls a new version and breaks something.
- Made-up data models: each project names its entities its own way and the data cannot be cross-referenced.
How do we handle backups and upgrades?
We back up MongoDB, which holds the state of the entities, the subscriptions and the agents’ configuration, and the time series database; on TimescaleDB, with point-in-time recovery as in managed PostgreSQL. The service groups, the subscriptions and the configuration of each component are also in the repository. We regularly restore into a test environment and check that a test measurement travels from the agent to the history.
Each FIWARE component has its own release pace. We pin the version of each image, read the notes before changing it, test the whole set in a separate environment and upgrade one piece at a time, starting with the stateless ones.
What does day-to-day support look like?
Metrics from the broker, MongoDB, the agents and the time series database go to Prometheus and Grafana, as we explain in monitoring with Grafana and Prometheus, with alerts when an entity or a group of sensors stops updating. If you use Keycloak for identity, we manage it as described in Keycloak for companies. Automated monitoring is continuous; human response is next business day, during business hours, as part of SRE as a service. Every month you receive a report with versions, incidents, growth of the history and changes made.
- DevicesMQTT or HTTP
- IoT AgentsTranslate to NGSI
- Orion or Orion-LDCurrent state, on MongoDB
- QuantumLeapHistory via subscription
- CrateDB or TimescaleDBTime series
- GrafanaDashboards and alerts
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- Azure
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | The components on cloud servers with Docker or on Kubernetes, with MongoDB and the time series database set up by us. | No provider offers managed FIWARE: in every case we run it ourselves. |
| AWS | The components on EKS or EC2, with your own MongoDB or MongoDB Atlas, and TimescaleDB on your own PostgreSQL. | If a MongoDB-compatible database is proposed instead of MongoDB, we check compatibility first. |
| Google Cloud | The components on GKE or Compute Engine, with your own MongoDB or MongoDB Atlas. | |
| Azure | The components on AKS or virtual machines, with your own MongoDB or MongoDB Atlas. | |
| OVH | The components on Public Cloud or Managed Kubernetes, with OVHcloud managed MongoDB or your own. | |
| Own server | The complete platform on your servers or in your organisation's data centre. | MongoDB needs three nodes for a real replica; on a single machine, backups are the only protection. |
What is included
- Orion Context Broker for NGSI-v2 or Orion-LD for NGSI-LD, with replicated MongoDB behind it.
- IoT Agents (JSON, UltraLight 2.0 or others) connected to your MQTT broker or over HTTP, with service groups and devices declared as code.
- QuantumLeap with CrateDB or TimescaleDB for the history, or Mintaka on TimescaleDB if the broker is Orion-LD.
- Keyrock as identity manager and Wilma as a proxy in front of the APIs, or Keycloak if you already use it.
- Data models based on Smart Data Models, reviewed before the entities are created.
- Backups of MongoDB and of the time series database, with a test restore.
- Metrics for the broker, the agents and the subscriptions, with alerts when data stops arriving.
- Upgrades of each component rehearsed in a separate environment, with pinned images and versions.
Frequently asked questions
NGSI-v2 or NGSI-LD?
NGSI-v2 is simpler and is what Orion uses, with plenty of documentation and deployments. NGSI-LD is the ETSI specification, with JSON-LD contexts and relationships between entities; it is implemented by Orion-LD, Scorpio and Stellio. For a new project that has to interoperate with other platforms we usually propose NGSI-LD; if you already have a working NGSI-v2 platform, there is no rush to migrate.
Is FIWARE suitable for publicly funded projects?
Many smart city calls ask for open, interoperable, standards-based platforms, and FIWARE with NGSI-LD fits that kind of requirement. But whether a project is eligible for funding is decided by the rules of each call and the body that manages it, not by the technology chosen. Our job is to make sure the platform works and is documented.
Keyrock or Keycloak for identity?
Keyrock is FIWARE's identity manager and, with Wilma in front of the APIs, protects the broker with OAuth2. Both have had few new releases for some time, so we review their status before proposing them. If your organisation already has Keycloak or another identity provider, it is usually better to use it and put a proxy that validates its tokens in front of the APIs, so you do not maintain two user systems.
What happens to the data if the context broker goes down?
The current state of the entities is in MongoDB and the history in the time series database, so nothing is lost. While the broker is down, the agents cannot update the entities; that is why, in production, the broker runs as several replicas and MongoDB as a replica set.
Can you deliver the whole smart city project?
We take care of the platform: installing, protecting, monitoring, backing up and upgrading the FIWARE components in your account. The sensors, their installation on the street and the business applications on top of the platform are usually handled by other teams, whom we coordinate with.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
Reviewed on