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.
Constraints that shape the work
The equipment predates the software
Machines with twenty-year service lives, protocols that were never designed for a network, and vendors who consider the interface a support risk.
The network is deliberately segmented
OT and IT separation exists for good reasons. Data crosses that boundary in one direction through a broker, never by opening a firewall for convenience.
The line does not stop for a deploy
Rollouts happen in planned maintenance windows measured in hours, with a rollback that has been rehearsed on a rig rather than argued about in a document.
Local first, cloud second
Edge collection has to keep working through a broken uplink and reconcile afterwards. Any design that assumes connectivity will lose data on the first outage.
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
When not to hire us
We do not touch control systems. PLC logic, safety instrumented systems and anything that can move a machine belongs to your controls engineers and their vendors, and we stay firmly on the read side of that boundary.
The project we most often turn down is a predictive maintenance programme where no historical failure data exists. Without labelled failures there is nothing to learn from, and a model trained on assumptions will fail quietly and expensively.
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.
Related work
Bring us the part that is stuck.
Send the constraint you are working around and we will come back with an approach, a rough shape of the work, and what it would take to hand it over.