Our Solutions
Data In Motion develops model-driven open-source solutions for data platforms, governance & compliance and visibility across evolved IT landscapes. They fit into your existing systems rather than replacing them. Automation takes care of repetitive, error-prone work — decisions stay with your people.
All solutions are built from the same open-source building blocks, which we develop and maintain ourselves: Model Atlas, Data Atlas and Event Atlas (see Technology Foundation). Each one can be used on its own or combined with the others — based on open standards and free of vendor lock-in.
Technology Foundation
All of our solutions rest on the same three building blocks: the Model Atlas, the Data Atlas and the Event Atlas. They share a common set of models — whatever is described in the Model Atlas is immediately available to the Data Atlas and the Event Atlas. All three are part of the Eclipse Fennec open-source project and are built on EMF (Eclipse Modeling Framework) and OSGi.
Model Atlas — Models and Metadata
The Model Atlas is the central model registry: the data structures of your systems are held here as formal models — versioned, validated and available to every connected component. The Model Atlas also manages the configurations of the Data Atlas and the Event Atlas, as well as the transformations between models; the same review and approval rules apply to them as to any other model.
The following demo illustrates the data flow in the Model Atlas — from schema ingestion across multiple source formats to model registration and downstream distribution to connected applications.
- Multi-tenant model registry — separate spaces for each organisational unit or project, which can inherit shared models from their parent spaces.
- Staged approval — configurable stages from draft to release, with review steps at every transition; every version remains traceable.
- Validation — models and data objects are checked against their rules, including business constraints written in OCL (Object Constraint Language); findings are recorded directly on the object concerned.
- Open formats — import and export as Ecore/XMI, JSON Schema, XSD and UML.
- Central transformations — model transformations (QVT) are versioned in the Model Atlas and executed directly by the Data Atlas.
- Searchable and connectable — full-text search across the classes, attributes and types of all models; your own applications connect via a REST API or a Java client.
Data Atlas — Data and Interfaces
The Data Atlas does for the data itself what the Model Atlas does for models: it describes where the data resides, how it is prepared and through which interfaces it is made available. Each instance is defined entirely by a configuration model instead of code, and changes to it take effect at runtime without a restart. The Data Atlas only ever reads from your source systems.
- Data sources — relational databases such as PostgreSQL, as well as MongoDB and files; credentials are stored only as secured references, never in plain text.
- Transformation — QVT model transformations from the Model Atlas map the source data onto the respective target model.
- Interfaces — REST (JSON, XML, CSV), GeoJSON, OData v4.01 and OGC API Features.
- Exports — datasets for download as CSV, JSON or XML.
- Open data — publication to an open data portal based on DCAT-AP 3.0, the European application profile of the W3C DCAT standard, retrievable in common RDF formats and via SPARQL.
Event Atlas — Events and Sensor Data
The Event Atlas brings sensor and event data into the same model-driven world: a declarative mapping onto a model in the Model Atlas defines how a device’s message becomes a digital twin — with no custom transformation code per device type. Technically, the Event Atlas is built on Eclipse sensiNact, an open-source IoT broker from the Eclipse Foundation. Data In Motion plays an active and leading role in its development.
- Ingestion — via MQTT and HTTP as JSON or XMI; LoRaWAN devices are connected via the decoded messages from their network server.
- Shared device models — devices from different manufacturers can be mapped onto a common model; mappings can be changed at runtime.
- Change rules — for each measured value, you define what counts as a change: a percentage or absolute deviation, every nth message or a time-based throttle. This way, only significant changes are stored.
- Time-series history — stored in PostgreSQL, optionally accelerated by TimescaleDB.
- Standardised output — OGC SensorThings API 1.1 via REST and MQTT, plus a REST interface to the digital twins.
Proven under real-time conditions: Data In Motion has built a traffic conflict detection system on this foundation. It combines traffic signal states and sensor data from an intersection in real time and predicts potential conflicts between road users before they occur.
How the Three Atlases Work Together
Sensor data flows through the Event Atlas into the time-series history. The Data Atlas makes it available alongside the rest of your data, via open interfaces and as open data — structured according to the models that the Model Atlas manages for all three. Each building block runs as a container and can be deployed on its own or combined with the others. Start with the building block you need today and extend later, without rebuilding your models.
Details on all three building blocks are available in the technical documentation on GitHub.
Work With Us
Whether your starting point is data governance, infrastructure visibility, AI integration or a data platform — we work with organisations to design and implement solutions based on these components. Contact us to discuss your use case.