Industry 4.0 & IIoT — Smart Manufacturing Software
In short: The fourth industrial revolution: connecting machines, products, people and IT systems through IIoT, cloud/edge computing, data analytics and AI so factories become transparent, flexible and self-optimising.
- It builds on the automation of Industry 3.0 (PLCs, IT) by adding connectivity and data-driven decisions — e.g. real-time OEE, predictive maintenance, full traceability and digital twins.
In short: Industrial IoT connects industrial equipment — sensors, PLCs, machines — to collect and use data.
- Compared with consumer IoT it demands higher reliability, determinism and safety, works with industrial protocols (OPC UA, Modbus, PROFINET), runs in harsh environments with long equipment lifetimes (20+ years, brownfield machines), and has stricter security and uptime requirements.
In short: Overall Equipment Effectiveness = Availability × Performance × Quality.
- Availability = run time ÷ planned time; Performance = (ideal cycle time × total count) ÷ run time; Quality = good count ÷ total count.
- Example: 87.5 % × 90.5 % × 95 % ≈ 75 %.
- It shows how much of planned time is truly productive and which loss to attack first.
In short: MES executes and tracks production on the shop floor in real time — orders dispatched to lines, data collection, quality, traceability, OEE, work instructions.
- ERP manages the business — finance, purchasing, inventory, sales, planning over days/weeks.
- ISA-95 defines the integration: ERP sends orders and receives production confirmations and consumption from MES.
In short: An international standard (IEC 62264) for integrating enterprise and control systems.
- It defines the levels (0–4), the functions of manufacturing operations management (production, quality, maintenance, inventory) and object models for data exchanged between ERP and MES, plus the equipment hierarchy enterprise → site → area → line → unit — used to structure data models and topic namespaces.
In short: A lightweight publish/subscribe protocol over TCP with a broker.
- Small overhead, works on unreliable networks, decouples producers from consumers, supports QoS levels, retained messages, last will (detect offline devices) and persistent sessions;
- easy to secure with TLS and certificates;
- all clouds support it.
- Sparkplug B adds a standard namespace, payload format and state management for industrial use.
In short: QoS 0 — at most once, fire-and-forget, may be lost.
- QoS 1 — at least once, acknowledged, may be duplicated (consumers must be idempotent).
- QoS 2 — exactly once via a four-step handshake, slower.
- Telemetry usually uses 0 or 1; commands and important events use 1 with idempotency or 2.
In short: OPC UA is a full industrial interoperability standard — rich information models, browse/read/write/subscribe/methods, built-in security — ideal for connecting to machines and controllers.
- MQTT is a lightweight transport for pub/sub distribution of data to many consumers and to the cloud.
- Common pattern: OPC UA at the machine/edge, MQTT (or OPC UA PubSub over MQTT) from the edge to the enterprise/cloud.
In short: Processing data close to the machines on gateways or industrial PCs.
- Needed for low-latency decisions, operation when the network or cloud is down (store-and-forward), reducing bandwidth by filtering/aggregating high-frequency data, protocol translation, and keeping sensitive OT networks closed while sending only outbound data.
In short: An architecture where an event broker (typically MQTT) holds the current state of the whole business in one ISA-95-structured topic hierarchy.
- Machines, MES, ERP and analytics publish and subscribe there instead of building point-to-point integrations, making data discoverable and new consumers easy to add.
- It needs governance of topic structure and payload contracts.
In short: MTBF (mean time between failures) = operating time ÷ number of failures — reliability.
- MTTR (mean time to repair) = total repair time ÷ number of repairs — maintainability.
- Availability ≈ MTBF ÷ (MTBF + MTTR).
- Improving maintenance, spare-part availability and diagnostics reduces MTTR; root-cause analysis and predictive maintenance increase MTBF.
In short: Collect condition data (vibration, temperature, current, pressure, cycles) plus maintenance and failure history, engineer features (RMS, spectral peaks, trends), train anomaly-detection or remaining-useful-life models, deploy them at the edge or cloud, and turn predictions into alerts and CMMS work orders.
- Success needs domain experts, enough failure examples (or anomaly detection when rare), and a feedback loop measuring avoided downtime and false alarms.
In short: Edge per line reads machine state, counts and reject signals via OPC UA/Modbus, timestamps in UTC and publishes state changes to MQTT/IoT Hub.
- A stream processor or .NET consumer maintains current state per line, accumulates run/down time by reason and counts, stores events in a time-series/SQL store and shift summaries in SQL.
- An ASP.NET Core API + SignalR pushes live updates to an Angular/React dashboard (andon view, OEE gauges, downtime Pareto).
- Operators enter downtime reasons on a tablet.
- Handle shift calendars, planned stops, ideal cycle times per product, and offline buffering.
In short: A live virtual model of a physical asset or process, synchronised with real data and used to monitor, predict and simulate.
- Example: a twin of a packaging line combining live machine states, a throughput model and maintenance data, used to test a new product changeover sequence virtually and to predict the effect of a slower filler on output.
- Tools: Azure Digital Twins (DTDL), Asset Administration Shell, simulation software, virtual commissioning.
Batch inserts (SqlBulkCopy, table-valued parameters), narrow tables with tag ids, clustered columnstore indexes for history, partitioning by date with sliding-window archiving, report-by-exception/deadband to cut volume, aggregates (1-min/1-h) for dashboards, DATE_BUCKET and window functions for queries, separate hot recent data from cold history — or use a dedicated time-series store (ADX/InfluxDB) and keep SQL for transactional MES data.
In short: Retrofit: add sensors (current clamps for run/stop, vibration sensors, photo-eyes or counters for parts), read existing PLC I/O through gateways or protocol converters (serial Modbus → TCP), or use IO-Link and small edge devices.
- Start with simple, high-value signals (running/stopped, count, reject) to get OEE and downtime, then add condition monitoring.
- Keep the machine's safety and control untouched; document and secure the new connections.
In short: Performance above 100 % means the ideal cycle time is wrong (too slow) or counts are inflated — wrong ideal cycle time for the running product, product not switched in the system at changeover, double counting from sensor bounce (needs debounce/edge detection), counting rejects twice, or run time understated (downtime recorded incorrectly).
- Validate the master data per product and the signal logic at the edge.
Use the device's source timestamp (UTC) rather than ingestion time, buffer and replay at the edge with sequence numbers, make ingestion idempotent (dedupe by device + sequence/timestamp), let aggregations handle late data (recompute affected windows, or watermarks in stream processing), and show data-quality flags on dashboards when data is incomplete.
In short: Start with a clear business problem and one KPI — usually OEE/downtime on a bottleneck line.
- Connect a few signals with low-cost edge hardware, build a simple dashboard and digital downtime-reason entry, run daily review meetings on the data, and quantify savings (more output, less scrap, less overtime).
- Use the result to fund scaling with a standard architecture (ISA-95 naming, MQTT/OPC UA, central data store), then move to predictive maintenance and quality analytics.