IoT & real time
A connected asset estate rarely fails on throughput. It fails on the time an event carries, on the order events arrive in, and on where the decision is actually taken. That is what we work on: a chain that stays readable from the sensor to the action it triggers.
Real time is a question of order, far more than of speed.
IoT programmes rarely fail on the number of sensors connected. They fail on a decision taken too late, or based on a reading that could not be compared with the one from the neighbouring site.
Our work therefore starts by defining what an event has to carry, before choosing the technology that moves it. We then build the full chain presented below, from the sensor through to the decision: that is what separates an estate producing curves from an estate triggering actions.
What we do
Four workstreams, from the sensor terminal block to the action a rule triggers.
Connect the assets and the OT
MQTT, OPC-UA and proprietary gateways, secure enrolment and a fleet managed without touching production. The connection starts with a telemetry contract: unit, measurement time, validity range and what an absent reading means.
an event without its unit is legible only to the person who emitted it
- MQTT, OPC-UA and industrial gateways
- Measurement time kept alongside arrival time
- An absent reading treated as an event, not a gap
Decide at the edge
Filtering, aggregation and local inference on the site gateway, so that what has to hold when the link drops does not depend on the cloud. A safety threshold stays local; a rule that changes every month does not.
an isolated site keeps deciding, several times a year it has to
- Safety thresholds kept on the gateway
- Local buffer replayed on reconnection
- Business rules kept centrally, where they change
The streaming chain
Brokers partitioned by site, ordering guaranteed where it means something, windows that follow the measurement time and not the arrival time, replay from the log and back pressure that degrades rather than drops.
a batch replayed after an outage falls back into its own window
- Partitioning by site, ordering inside a partition
- Windows on measurement time, with a late tolerance
- Replay from the log, idempotent consumers
From alert to action
Thresholds held over a duration rather than on a single point, hysteresis so an oscillating value does not alert every two seconds, and every automatic action carrying the identifier of the event that triggered it.
an automatic action nobody can trace back gets switched off
- Alerts on a duration, with a return threshold
- Each action carries its triggering event
- Operations supervision and long-term history separated
The chain we build
From sensor signal to decision
A streaming pipeline that carries every event from the edge to an actionable decision, with no batch delay.
End-to-end flow
What you get
One project runs through the four deliverables below: supervising an equipment estate spread across several sites. Each line states what is actually handed over, in the order it is handed over.
A telemetry contract
Unit, precision, valid range, measurement time and arrival time, and what an absent reading means. Written once, it is what lets two sites be compared three years later.
The arbitration of where the calculation happens
What stays on the gateway, what goes to the streaming cluster, and the reason next to each. A safety function and a rule that changes monthly do not live in the same place.
Rules that survive a burst
Windows on measurement time, a late tolerance, hysteresis on the thresholds and silence treated as a signal. Written so a replayed batch does not reopen yesterday's alerts.
A measurement of the chain in production
Median and 99th percentile latency hold, and 4.1% of events arrive out of order. The cause is not the network: three gateways have a drifting clock, which is what produced sixty-one alerts closed and reopened within the minute.
How we deliver
Discover
depending on scope, sector and the level of compliance required
- Audit of use cases and pain points
- Value / feasibility matrix
- Executable specification (ASDD)
MVP
depending on system complexity and integrations
- An agent in a real environment
- Generated tests, measured coverage
- Go / no-go before industrialisation
Scale
depending on the number of agents and connected systems
- Multi-agent orchestration on a shared foundation
- CI/CD and MLOps integration
- Team upskilling
Run
service commitment defined with you
- LLMOps observability
- FinOps optimisation of AI costs
- Continuous compliance audit
What a connected estate actually weighs
Estates instrumented in production
A cold chain where the alert arrives before the loss
240 vehicles tracked · 3 temperature zones
A European fleet carrying goods at minus twenty-five, plus two and plus twelve degrees, where a temperature deviation is not an incident to analyse afterwards: once the threshold is crossed for long enough, the load is already lost.
On-board sensors feeding the Soon & Connect platform, exchange services separated by domain, orders, fleet, temperature and alerts, and cold chain alerting raised on the deviation itself rather than on the end-of-run report.
Trainset status seen as it changes, not looked up
68 trainsets supervised · 8 workshops in production
Maintenance workshops where the state of a trainset was consulted screen by screen, when the decision to release it or hold it is taken collectively, standing in front of the board, at the moment the field event happens.
Field events propagated in real time over WebSockets onto an interactive 4K board readable by the whole workshop, with drill-down per train and per piece of equipment, rolled out workshop by workshop rather than in one go.
Insights & Perspectives
Building a real-time data pipeline with Kafka, Spark and Hive
KRaft ingestion, unified batch and streaming, an Iceberg lakehouse and the Lambda or Kappa patterns: what each layer of a streaming pipeline actually holds.
6 major trends in manufacturing data and AI
The six technology trends reshaping the manufacturing industry through artificial intelligence and advanced data analytics.
Reactive programming architecture across platforms
Reactive Streams, back pressure, Spring Data R2DBC and their alternatives: the benefits, the limits, and a method for deciding whether it fits.
Build a chain that stays readable to the action
A telemetry contract, an arbitration of where the calculation happens, rules that survive a burst, and a chain measured once it runs.
Frequently asked questions
No, and deciding that is the first architecture question. A safety threshold has to hold while the site is isolated, which happens several times a year, so it stays on the gateway. A rule that changes every month stays central, where changing it costs nothing. Everything else is an arbitration between bandwidth, latency and who is allowed to change what.
Usually because of the clocks, not the network. A gateway whose clock drifts by thirty seconds dates its measurements thirty seconds off, and a five-minute window then aggregates readings that did not happen together. Keeping both the measurement time and the arrival time is what makes the difference visible, and synchronising the gateways is what fixes it.
At-least-once with idempotent consumers covers the large majority of industrial cases, and costs far less to operate. Exactly-once earns its cost where a duplicate has a financial or regulatory consequence, billing or traceability of a batch. Choosing it everywhere makes a chain slower and more fragile for a guarantee nobody was asking for.
Yes, and without touching the automation logic. We integrate MQTT, OPC-UA and proprietary gateways, add secure enrolment and manage the fleet alongside production rather than through it. The part that takes time is not the protocol, it is writing the telemetry contract for equipment that has been emitting for fifteen years.
Since 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents through a single European platform, and the rest of regulation 2024/2847 applies on 11 December 2027. In practice, the estate has to be inventoried, its components tracked and its update path known before it is needed.
It keeps deciding locally, and buffers what it cannot send. The gateway holds a local buffer replayed on reconnection, and the windows on the processing side tolerate that replay so a batch arriving late falls back into its own window rather than reopening alerts that were already closed.
Framing takes 2 to 6 weeks depending on scope, sector and the level of compliance required, and produces the telemetry contract, the arbitration of what stays local and the first rules. A first flow in production, on a real perimeter rather than a demonstrator, follows in 4 to 10 weeks.