Industries / Manufacturing & Industry 4.0
Plant-floor software that respects the control network
We build the IT layer above operations: OT data collection across OPC UA, Modbus and MQTT with Sparkplug B, MES functionality, ERP integration, ISA-95 aligned models, OEE and plant-floor dashboards, quality traceability and genealogy, and edge architecture that survives connectivity loss. Safety instrumented systems are out of scope, and no cloud agent goes on a control network without an air-gapped review.
- Purdue-model boundaries respected, with data flowing outward only
- Predictive maintenance scoped against labelled failure data you actually have
- Condition monitoring recommended before machine learning, deliberately
- SIS and SIL-rated safety functions explicitly excluded
At a glance
- Protocols
- OPC UA, Modbus TCP and RTU, MQTT with Sparkplug B, PROFINET and EtherNet/IP via gateway
- Standards context
- ISA-95, Purdue reference model, IEC 62443 for OT security
- ERP integration
- SAP, Microsoft Dynamics, and others via a queued interface layer
- Edge posture
- Store-and-forward, outward-only connections
- Out of scope
- Safety instrumented systems and any SIL-rated function
- Availability target
- 99.95% on supported architectures
- Enquiries
- nitesh@redcubical.com
Architecture
OT and IT convergence, and the Purdue levels that constrain it
What OT and IT convergence actually means
The Purdue model separates a plant into levels: 0 for sensors and actuators, 1 for controllers, 2 for supervisory control and HMI, 3 for site operations and MES, 3.5 as an industrial DMZ, 4 for business systems and 5 for enterprise or cloud. Convergence does not mean flattening it. It means a controlled, outward-only data path from level 2 to level 3.5, with the DMZ as the only place OT and IT meet.
| Level | What lives there | Our involvement | Hard rules |
|---|---|---|---|
| Level 0 to 1 | Sensors, actuators, PLCs, safety instrumented systems, drives | None directly. We consume data made available by level 2 systems or a gateway | We never write to a controller and never touch a safety function. Deterministic control is not an IT concern |
| Level 2 | SCADA, HMI, batch control, line supervisory systems | Read-only data access through a supported interface, usually an OPC UA server or a historian | No agents installed on level 2 hosts without OT sign-off. No changes to HMI logic. Read paths must not add load to a control host |
| Level 3 | MES, historian, plant scheduling, quality systems, local reporting | This is where most of our build work sits. MES functions, dashboards, traceability, local persistence | Level 3 must keep working with the site link down. Anything operators depend on runs here, not in the cloud |
| Level 3.5, industrial DMZ | Data diodes, brokers, gateways, replication endpoints, jump hosts | We design and build the gateway: protocol translation, buffering, filtering and outbound publication | Connections initiate from OT outward only. The cloud never dials in. No shared credentials across the boundary |
| Level 4 to 5 | ERP, PLM, corporate analytics, cloud data platform, multi-site reporting | Aggregation, cross-site analytics, model training, ERP interface layer, executive reporting | Never a precondition for production. ERP unavailability delays reporting, it does not stop the line |
One architectural rule carries most of the risk reduction: the direction of connection initiation. If the cloud can open a session into the plant, you have created a path an attacker can use and a dependency an outage can exploit. Outward-only publication with buffering at the gateway removes both, and costs almost nothing to design in at the start.
Protocols
Industrial protocols and what each one is actually for
Protocol choice is usually made for you by the equipment already installed. What matters is knowing what each is good at, and where the gateway has to sit.
Choosing an industrial protocol
In short: OPC UA for structured, secure, semantically described data from modern equipment; Modbus because it is everywhere and trivial, with no security and no semantics; MQTT with Sparkplug B for efficient publish-subscribe telemetry with state awareness; PROFINET and EtherNet/IP for deterministic control traffic we do not touch, read instead through a gateway or the PLC vendor interface.
| Protocol | What it is for | Strengths | Limitations and how we work around them |
|---|---|---|---|
| OPC UA | Structured data exchange between level 2 and level 3, with an information model describing what each value means | Type system and address space semantics, built-in authentication and encryption, subscriptions with dead-banding, companion specifications per industry | Heavier than expected on older hardware, and server implementations vary in quality. Sessions can be expensive on a busy control host, so we tune subscription rates and dead-bands rather than polling, and test load impact with OT present |
| Modbus TCP and RTU | Simple register reads from almost any device made in the last forty years | Universal, trivially implemented, extremely low overhead, well understood by every plant engineer | No authentication, no encryption, no data types beyond registers and no semantics at all. Register maps live in a vendor PDF or in tribal knowledge. We maintain register mapping as versioned configuration with units and scaling, and keep Modbus strictly inside the OT zone |
| MQTT with Sparkplug B | Efficient publish-subscribe telemetry from many devices or gateways to a broker, and onward to the DMZ | Low bandwidth, works over poor links, birth and death certificates give real state awareness, defined payload and topic structure removes the usual bespoke-JSON problem | Plain MQTT without Sparkplug becomes an undocumented topic and payload free-for-all within a year. Broker becomes a single point of failure, so we cluster it and buffer at the edge. We insist on Sparkplug B rather than ad hoc MQTT for exactly this reason |
| PROFINET | Deterministic real-time control traffic between PLCs and field devices, Siemens-centric estates | Cyclic real-time performance, mature diagnostics, strong ecosystem | A control protocol, not a data protocol. We do not put IT software on it. Data is read via an OPC UA server on the PLC or controller, or via a dedicated gateway |
| EtherNet/IP with CIP | Deterministic control traffic in Rockwell and Allen-Bradley estates | Widely deployed, integrates cleanly with the Rockwell toolchain | Same position as PROFINET. Read through a gateway or the vendor OPC UA interface, and never introduce traffic that could affect cyclic timing |
| Historian interfaces | Time-series data already collected and compressed at level 3 | Often the fastest and safest route to plant data, with no new load on control systems | Compression and interpolation settings can hide the transients you want. We read raw where available and document the compression regime with any dataset used for analysis |
A practical note on units and scaling. Raw register values carry no units, and scaling factors live in commissioning documents. Every value we ingest is normalised at the gateway with units, scaling and engineering range stored as configuration, versioned in the same repository as the code. Silent unit mismatch is the most common cause of a plant dashboard that everybody quietly stops believing.
Systems
MES, ERP integration and the ISA-95 hierarchy
Why ISA-95 modelling is worth the discipline
ISA-95 gives you the vocabulary: an equipment hierarchy of enterprise, site, area, work centre and work unit, and a clean split between business planning at level 4 and manufacturing operations at level 3. Modelling to that hierarchy from the start is what lets one dashboard aggregate across three plants that name their lines differently. Retrofitting it is a data migration nobody enjoys.
MES functions we build most often
- Production order execution. Receiving orders from ERP, dispatching to work centres, tracking progress by operation and confirming completion with quantities and times.
- Material consumption and backflush, with lot and batch capture at consumption so genealogy is built as production happens rather than reconstructed later.
- Downtime and reason-code capture at the operator terminal, since machines report that they stopped and almost never report why.
- Quality checks in-process, with sampling plans, tolerance evaluation, non-conformance raising and hold or quarantine states that actually block despatch.
- Labour and shift tracking where it drives cost or capability requirements such as certified operators for a given process.
- Recipe and parameter management with versioning and change control, because an unversioned recipe change is untraceable when a batch fails.
ERP integration without coupling the line to it
- Queued, store-and-forward interface layer. Production confirmations, goods movements and order updates are written locally and posted onward asynchronously.
- Idempotency keys on every posting, because ERP interfaces time out and get retried, and a duplicated goods movement is a stock discrepancy that takes days to unpick.
- ERP availability is never a precondition for production. If SAP is down, the line runs and reporting catches up. Designs that block production on an ERP call get bypassed manually within a week.
- One canonical mapping between plant identifiers and ERP master data — material numbers, work centres, storage locations — maintained as configuration and validated on change.
- Reconciliation daily between MES-recorded production and ERP-posted confirmations, with differences reported as a monitored metric rather than found at month end.
- Backpressure visibility. Queue depth on the ERP interface is on the plant dashboard, so a growing backlog is seen before it becomes a closing problem.
OEE and plant-floor dashboards
OEE is availability multiplied by performance multiplied by quality. The arithmetic is simple and the definitions are where every implementation argues.
- Availability is run time over planned production time, so the definition of planned time decides the number. Planned maintenance, changeover and no-demand time must be agreed in writing before the first dashboard is built, or the figure will be disputed forever.
- Performance is actual output against ideal cycle time, which requires a defensible ideal cycle time per product and machine rather than a nameplate figure from a brochure.
- Quality is good units over total units, and it needs rework and concession to be handled explicitly rather than quietly counted as good.
- Reason codes decide whether the dashboard is used. A short, well-designed list captured at the machine within seconds beats a comprehensive taxonomy nobody completes. Losses without attribution are a number without an action.
- Display where the work is. Andon boards at the line for the current shift, and analytical views for supervisors and engineers. One dashboard serving both audiences serves neither.
- Comparability across sites requires the ISA-95 hierarchy and shared definitions. Otherwise you get three plants each confident their OEE is best, measuring three different things.
Honesty
Predictive maintenance, condition monitoring and digital twin scepticism
What predictive maintenance actually requires
Predictive maintenance needs labelled failure history: repeated instances of a specific failure mode, with sensor data covering the run-up to each, and trustworthy records of when degradation began. Most plants have neither the sensor coverage nor the labelling, because maintenance records say what was replaced and not when the fault started. Without labels you have anomaly detection, and condition monitoring usually beats both.
| Approach | What it needs | What it delivers | Our view |
|---|---|---|---|
| Reactive | Nothing | Failure, then repair, with unplanned downtime and secondary damage | The baseline you are trying to leave. Worth quantifying properly first, because the business case for everything else depends on knowing this cost |
| Preventive on a schedule | Asset register, manufacturer intervals, work order management | Fewer failures, at the cost of servicing components that had life left | Cheap, reliable and undervalued. Getting the asset register and work orders right is a prerequisite for anything more advanced anyway |
| Condition monitoring | Appropriate sensors and established thresholds. No training data required | Vibration, temperature trend, oil analysis and motor current signature analysis catch a large share of mechanical failures with weeks of warning | Where we advise most clients to start. Known physics, no data history needed, and it produces the sensor coverage and labelled failure events a model would later need |
| Anomaly detection | Normal-operation data only, plus a tolerance for false positives | Flags deviation from learned normal behaviour without predicting what will fail or when | Achievable on most estates, and honest about what it is. False positive rate is the deciding factor for whether maintenance teams keep trusting it |
| Predictive with remaining useful life | Many labelled instances of each specific failure mode, sensor data through each degradation period, and accurate onset dates | Failure mode identification and a time-to-failure estimate with a confidence interval | Viable on high-value assets with genuine failure history, on fleets where instances aggregate across identical machines, or where a manufacturer supplies validated models. Rarely viable on a single bespoke line with three recorded failures in a decade |
| Prescriptive | All of the above plus validated cost and production models | Recommended action with an expected cost and production impact | Mostly aspirational in the plants we have worked in. We are willing to build towards it and will not present it as a near-term outcome |
The question we ask in the first workshop: how many times has this specific failure mode occurred, on this asset or an identical one, with sensor data retained for the period before it? If the answer is fewer than roughly ten, no modelling technique will rescue it, and the correct investment is condition monitoring plus disciplined failure labelling so that the answer is different in two years.
Digital twin, in three honest meanings
- A 3D visualisation. A model of the plant or asset, sometimes with live values overlaid. Genuinely useful for training, layout planning and communication. Frequently sold as more than it is.
- A live data model. A structured representation of an asset holding current and historical state, relationships and configuration. This is achievable, valuable, and mostly a data modelling and integration exercise. Most of the value attributed to twins comes from here.
- A simulation or physics model. A validated model that predicts behaviour under conditions not yet observed. This is a serious engineering programme requiring domain physics, calibration against measured behaviour and ongoing validation. It is what is usually implied and least often delivered.
We ask which of the three you mean before quoting, because the effort differs by an order of magnitude. If the honest answer is the second, we say so and build that, which is generally a better outcome than a partially validated simulation nobody trusts.
Quality, traceability and genealogy for recall
Traceability is judged in one scenario: a defect is found and you must determine what else is affected, within hours.
- Forward and backward genealogy. From a finished serial or batch back to every input lot, machine, operator, recipe version and process parameter set, and forward from a suspect input lot to every finished unit containing it.
- Capture at consumption, not reconstruction afterwards. Genealogy assembled retrospectively from production reports is approximate, and approximate is not adequate for a recall boundary.
- Process parameters retained with the batch record, so a deviation investigation can compare a suspect batch against good ones on actual conditions rather than on setpoints.
- Non-conformance and hold states that genuinely block despatch, enforced in the system rather than by a label on a pallet.
- Query performance as a requirement. A recall query that takes six hours to run has failed. We index and model for this specific query shape from the start.
- Retention aligned to product life, which for some sectors means a decade or more, so storage tiering and format longevity are design considerations rather than afterthoughts.
Deployment
Edge or cloud, and what must never leave the plant
How to split workloads between edge and cloud
Split on latency and dependency. Anything with a control or operator-response deadline under a second, and anything operators depend on during a network outage, runs at the edge. Cross-site aggregation, long-horizon analytics, model training and reporting run in the cloud. The failure we see most often is an operator dashboard hosted centrally that goes dark when the site link drops.
| Workload | Placement | Reason |
|---|---|---|
| Protocol translation and data normalisation | Edge, in the DMZ gateway | Must continue during a link outage, and it is the point where units, scaling and provenance are applied |
| Operator dashboards and andon displays | Edge | Operators need them during an outage. A dashboard that fails with the WAN loses trust permanently after the first incident |
| Machine-vision inspection and closed-loop response | Edge | Latency budgets in tens of milliseconds. A round trip to a cloud region is not a candidate |
| Local buffering and store-and-forward | Edge | Sized for the worst realistic outage, commonly 24 to 72 hours of full-rate data, with ordered replay on reconnection |
| Short-horizon historian and shift reporting | Edge, replicated to cloud | Local queries stay fast and available; the copy feeds enterprise analytics |
| Cross-site benchmarking and multi-plant OEE | Cloud | Needs data from every site and no real-time deadline. Requires shared ISA-95 definitions to be meaningful |
| Model training and long-horizon analytics | Cloud | Compute-heavy, batch-tolerant, benefits from elastic capacity and access to the full history |
| Model inference for maintenance alerts | Either, decided by deadline | Cloud is fine for alerts measured in hours. Edge if an action must follow within seconds or if the link is unreliable |
Edge deployment needs the same engineering discipline as cloud: version-controlled configuration, signed and staged updates with rollback, remote health monitoring, and a rehearsed recovery procedure for a failed gateway. An edge estate managed by someone visiting sites with a USB stick becomes unmaintainable at around ten sites, and every plant we have seen reach that point had not planned for it.
Answers
Manufacturing and Industry 4.0 questions
Will you put a cloud agent on our PLC network?
Not without an air-gapped design review and written sign-off from whoever owns OT risk on your site. Control networks were built on the assumption of isolation, and an agent that phones out from Purdue level 2 changes the site risk profile. The pattern we use instead is a unidirectional flow from OT to an edge gateway in a DMZ, and the cloud never initiates a connection inwards.
What data do we actually need before predictive maintenance is viable?
Labelled failure history: enough instances of the specific failure mode, with sensor data covering the period before each one, and accurate records of when and why each asset failed. Most plants have neither the sensor coverage nor trustworthy failure labelling, because maintenance records say "bearing replaced" without a date of onset. Without labels you have anomaly detection, which is a different and more modest claim.
Is condition monitoring really better than machine learning for maintenance?
Usually, as a first step. Vibration thresholds, temperature trending, oil analysis and current signature analysis are established engineering with known physics and no training data requirement. They catch a large share of mechanical failures for a fraction of the cost, and they give you the sensor coverage and the labelled events that a model would later need anyway. Start there and earn the right to model.
What is a digital twin, honestly?
The term covers three very different things: a 3D visualisation, a live data model of an asset with current state, and a physics or simulation model that predicts behaviour under conditions not yet observed. The first two are achievable and useful. The third is a serious engineering programme requiring validated physics, and it is the one most often implied and least often delivered. We ask which of the three you mean before quoting.
Do you work on safety instrumented systems?
No. SIS and anything carrying a SIL rating is explicitly out of scope. Safety functions are designed, verified and maintained under IEC 61508 and IEC 61511 by qualified functional safety engineers, and IT-driven change to them is a hazard. We read data from safety systems where a supported read-only interface exists, and we never write to them.
How do you integrate with SAP or Dynamics from the plant floor?
Through a defined interface layer with store-and-forward, never a direct call from a machine. Production confirmations, goods movements, order status and material consumption are queued at the edge and posted with idempotency keys, so an ERP outage or a network break slows reporting rather than stopping production. ERP availability must never be a precondition for making product.
Should our plant data go to the edge or the cloud?
Both, with a clear split. Anything with a control or operator-response deadline under a second stays at the edge, along with buffering for connectivity loss. Aggregation across sites, long-horizon analytics, model training and reporting go to the cloud. The mistake we see most often is a dashboard that operators depend on which stops working when the site link drops.
How accurate is OEE if we calculate it from machine signals?
Accurate on availability and performance, and only as good as your reason-code discipline on quality and downtime attribution. Machines report that they stopped; they rarely report why. Unless operators or an inference layer attribute downtime to a cause, you get a defensible number with no actionable content, which is how OEE dashboards end up ignored.
Start with an OT data and architecture review
Three weeks, fixed fee. You get a protocol and data availability audit per line, a Purdue-boundary architecture proposal, an OEE definition workshop output, a maintenance data readiness assessment and a costed plan. Yours to keep either way.