Manufacturing
On a plant floor, the constraint is rarely the software. It is that the line cannot stop, the network was designed for isolation rather than convenience, and the equipment predates most of the protocols you would prefer to use.
The plant sets the architecture
Consumer-scale patterns assume reliable connectivity and tolerance for a retry. A production line assumes neither. If a control decision depends on a round trip to a cloud region, then a fibre cut is an outage on the line, and no amount of resilience engineering in the cloud changes that.
So the useful question is where each decision has to be made. Latency-sensitive and safety-adjacent logic stays local, near the equipment. Aggregation, analytics and planning go upstream, where scale is cheap. Getting that split right early avoids the far more expensive discovery that a feature cannot work where it was built.
Where we work
Shop-floor data collection
Telemetry from PLCs, sensors and older equipment over OPC UA, Modbus and whatever the machine actually speaks.
MES and production visibility
Order, batch and throughput tracking that reconciles with what the line physically produced rather than what was planned.
Predictive and condition-based maintenance
Models with an honest false-positive cost, because an unnecessary teardown is not a free outcome.
Quality and traceability
Genealogy from raw material to shipped unit, complete enough to scope a recall narrowly instead of broadly.
Supply chain and planning integration
Connecting ERP planning to actual plant state, so the schedule reflects the constraint rather than the forecast.
OT/IT boundary engineering
Getting data out of segmented networks without turning the segmentation into decoration.
Security without breaking segmentation
OT networks are isolated for good reason, and the pressure to expose them for analytics is where a lot of industrial risk now originates. The answer is not to flatten the network so the dashboard is easier to build.
Data should leave the plant through a narrow, one-directional path that cannot be used to reach back in. That constrains what is possible — some appealing remote-control features simply should not be built — and we would rather have that argument during design than after an incident.
One-way data egress by default; inbound control treated as exceptional
Local buffering so a network loss does not lose production history
Time synchronisation and ordering handled explicitly, not assumed
Changes staged and rehearsed against planned downtime windows
Failure modes agreed with plant engineering, not just with IT
Common questions
Usually, though sometimes only by reading what it emits rather than talking to it properly. Machines without a modern interface can often be instrumented externally. Where the only option is a protocol converter of uncertain reliability, we will say that the data quality will reflect it.
Keep exploring.
Ready to start your project?
Get a free technical discovery call. We'll map the right team, stack, and timeline to match your goals — no obligation.