Executive summary
- Most plants already have machines, meters and controllers that speak Modbus, over RS-485 serial lines or TCP/IP networks.12 They work, and replacing them only to get data out is rarely justified.
- An edge gateway can read those devices where they are and publish their values over MQTT,3 a lightweight publish/subscribe protocol that SCADA, MES and cloud platforms can consume.
- The ISA-95 model (IEC 62264) gives each system a clear place: devices and controllers at the bottom, SCADA above them, MES at manufacturing operations, ERP at the business level.4
- Getting the data model right — units, scaling, timestamps and quality — matters more than the transport. Once it is right, OEE, downtime analysis and traceability follow.
- Security is designed in from the start, using the zones-and-conduits approach of IEC 62443.5
1. The brownfield reality
A typical plant was built over decades. It contains PLCs from several vendors, energy meters, drives, temperature controllers and standalone machines, often installed by different contractors. Modbus is common among them because it is simple, openly specified and has been supported by industrial devices for many years.1
The problem is not that the data does not exist; it is that it is locked inside individual devices and serial cables. Production counts are written on paper, downtime is estimated at the end of the shift, and energy use is read from a meter once a month.
2. The gateway pattern
Instead of replacing equipment, we add a small edge gateway close to the devices. The gateway:
- Polls Modbus registers on serial (RTU) or Ethernet (TCP) devices on a schedule.
- Converts raw register values into engineering values with units.
- Publishes them over MQTT to a broker that SCADA, MES or a cloud platform subscribes to.
MQTT suits this role: clients publish to named topics and any number of consumers can subscribe, so adding a new consumer — a dashboard, a historian, an MES — does not require touching the gateway or the devices.3 The connection is also opened outbound from the gateway, which simplifies network security (see section 7).
3. Inside a protocol converter
The Inplux protocol converter, built by LIDAVI, follows a layered design:
| Layer | Responsibility |
|---|---|
| Drivers | Hardware: serial and Ethernet interfaces, digital inputs, buzzer. |
| Services | Shared services used by the protocol and application layers. |
| Middleware | Protocol implementations behind a common interface: Modbus RTU, Modbus TCP and MQTT. |
| Application | The conversion logic: which registers to read, how to map them, where to publish. |
Two choices make the converter reusable across sites. First, protocols are pluggable components that can be enabled or disabled at build time, so new conversions can be added without rewriting the application. Second, it supports several MQTT broker targets, including AWS IoT, Azure IoT Hub and ThingsBoard, so the same hardware fits different cloud choices. Vendor-specific details are kept in PLC vendor profiles rather than spread through the application.
4. Modelling the data
Most integration problems are data problems. Before any dashboard is built, each signal needs:
- A stable name and place in a site → area → line → machine hierarchy, reflected in the topic structure.
- Units and scaling. Modbus registers are 16-bit values;1 a reading of 2315 may mean 231.5 °C. The conversion belongs at the edge, documented once.
- A timestamp from the edge, taken when the value was read, not when it arrived.
- A quality indicator, so a failed read is not mistaken for a real zero.
Publish engineering values, not raw registers. Every consumer should receive “231.5 °C, good, read at 10:04:12” — never “register 40017 = 2315”.
5. Where each system fits
IEC 62264, the international standard based on ISA-95, describes manufacturing systems as levels.4 We use it to keep responsibilities clear:
| Level | Role | Examples |
|---|---|---|
| 4 · Business planning | Orders, finance, supply chain | ERP |
| 3 · Manufacturing operations | Execute and record production, quality, people and safety | Cardia MES, inShift |
| 2 · Supervisory control | Monitor and supervise the process in real time | Inplux SCADA |
| 1–0 · Control and field | Sense and act on the process | PLCs, meters, drives, Inplux gateway |
The gateway feeds Level 2 and above; SCADA supervises; MES turns signals into production facts and exchanges orders and confirmations with ERP. Each level talks mainly to its neighbours, which keeps changes local.
6. What MES needs from the floor
With reliable machine signals, an MES can automate what is otherwise collected by hand:
- OEE. Overall Equipment Effectiveness combines availability, performance and quality into one measure: OEE = availability × performance × quality.6 Machine run/stop states give availability, cycle or part counts give performance, and reject counts give quality.
- Downtime with reasons. Stops are captured automatically; operators only add the reason.
- Work-order progress. Counts are booked against the active order and operation.
- Genealogy. Linking the machine, time window and material lot to each batch makes traceability possible.
Cardia MES implements these capabilities, together with routings, bills of materials, inspections, non-conformance reports and ERP synchronisation. inShift adds the people side: shift logs, handover and Permit to Work for maintenance on the same equipment.
7. Security: zones and conduits
Connecting control equipment to IT networks creates risk. IEC 62443 recommends grouping assets into zones with similar security needs and controlling the conduits through which they communicate.5 In practice:
- Field devices and their serial or Ethernet segment form one zone; the gateway sits at its boundary.
- The gateway opens an outbound, encrypted MQTT connection; no inbound ports are opened into the control network.
- Brokers, SCADA and MES authenticate every client, and each client can only publish or subscribe to its own topics.
- Write access to devices, if needed at all, is limited, logged and separated from read-only data collection.
8. A staged roadmap
- Survey. List devices, protocols, register maps and network segments; agree the signals that matter.
- Pilot one line. Install a gateway, publish a handful of signals and validate them against the machine displays.
- Visualise. Bring the data into SCADA or a dashboard; start measuring availability and downtime.
- Execute. Connect MES for work orders, OEE and quality; integrate shift and safety processes.
- Integrate upwards. Exchange orders and confirmations with ERP; extend to further lines.
9. Risks and limitations
- Undocumented devices. Older equipment may lack register maps; reverse-engineering takes time and must be verified.
- Polling load. Serial buses have limited bandwidth; polling too many registers too often slows every device on the line.
- Clock drift. Edge timestamps are only as good as the gateway’s time source.
- Organisational change. Automatic downtime capture changes how performance is discussed; operators should be involved from the start.
10. Conclusion
Existing plants hold far more usable data than they report. A staged approach — gateways at the edge, a clean data model, MQTT in the middle, ISA-95 roles for each system and security by design — turns that data into supervision, execution and traceability without replacing equipment that still does its job. This is the approach behind LIDAVI’s Inplux, Cardia and inShift products.
References
- Modbus Organization (2012). MODBUS Application Protocol Specification V1.1b3. https://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf
- Modbus Organization (2006). MODBUS over Serial Line Specification and Implementation Guide V1.02. https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
- OASIS (2014). MQTT Version 3.1.1. OASIS Standard. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
- IEC 62264-1:2013. Enterprise-control system integration — Part 1: Models and terminology. International Electrotechnical Commission.
- IEC 62443-3-3:2013. Industrial communication networks — Network and system security — Part 3-3: System security requirements and security levels. International Electrotechnical Commission.
- Nakajima, S. (1988). Introduction to TPM: Total Productive Maintenance. Productivity Press.
This white paper is provided for information. Figures labelled “Established” or “Peer-reviewed” are taken from the cited sources; figures labelled “Industry claim” have not been independently verified by LIDAVI; anything labelled “Design target” or “Hypothesis” is LIDAVI’s own and must be confirmed in a site-specific feasibility study. Nothing here is a performance guarantee.