In a manufacturing plant, every production line generates data continuously: baking temperature, injection pressure, tightening torque, bearing vibration, per-equipment power consumption. For decades, that data stayed locked inside PLCs and SCADA systems, invisible to the ERP managing finance, inventory, and orders on the other side of the application wall.
The Industrial Internet of Things (IIoT) is changing that equation. The promise: real-time physical data flowing from the shop floor straight into the ERP — automatically triggering replenishment orders, calculating OEE (Overall Equipment Effectiveness) without manual entry, or opening a maintenance work order before a breakdown occurs. According to Deloitte (2025), 46% of manufacturers have already deployed IIoT solutions at site level, yet many stop at the visualisation layer without connecting the data to their ERP.
This guide covers the technical “how”: the layered architecture, the protocols (OPC-UA, MQTT), native connectors from leading ERP vendors, and the five steps of a successful IIoT-ERP integration project.
Why Connect IIoT Directly to Your ERP (and Not Just to Your MES)
The MES Silo Problem: Production Data That Finance and Supply Chain Never See
The MES (Manufacturing Execution System) captures production data operation by operation — quantities produced, cycle times, scrap rates, lot/serial traceability. That is its job. But MES remains a shop floor tool. It does not know that a customer needs their order by end of month, that cash flow is tight on a specific product, or that a key component supplier is out of stock at day plus five.
The real value of IIoT-ERP integration lies in cross-domain data exploitation. When a low-level sensor in a raw material silo triggers a purchase order directly in the ERP procurement module, the chain is automated end to end. When actual power consumption from a machine flows into the ERP cost-of-goods calculation, production cost reflects energy reality rather than a budget estimate.
The MES manages the production flow. The ERP manages the value created by that flow. Connecting them directly through IIoT eliminates the consolidation lag and re-keying that degrade financial data quality.
Concrete Use Cases: What Direct Integration Makes Possible
Real-time OEE inside the ERP. OEE combines availability, performance, and quality for a given asset. Calculated manually once a week, it serves as a retrospective report card. Calculated in real time from sensor feeds and displayed on the production manager’s ERP dashboard, it becomes an operational decision lever.
Automated replenishment order triggering. A weight sensor on a conveyor detects stock falling below safety level. The reading travels through the MQTT broker, crosses the edge gateway, and generates a purchase request inside the ERP — no human intervention, no intermediate spreadsheet.
Invoicing based on actual energy consumption. For manufacturers who charge energy costs back to customers (contract manufacturers, tolling operations), the ERP can incorporate per-machine, per-production-order electricity consumption measured at the meter into the invoice calculation. Actual margin replaces theoretical margin.
The Three-Layer Technical Architecture
IIoT-ERP connectivity does not happen directly between a sensor and an enterprise application server. The ERP cannot absorb millions of raw messages per second. The architecture is structured in three layers that filter, aggregate, and normalise data before it reaches the ERP.
Layer 1 — Sensors and Controllers (PLCs, SCADA, IoT Sensors)
This is the physical layer. It includes:
- Programmable Logic Controllers (PLCs): Siemens S7-1500/S7-300, Schneider Modicon M580, Beckhoff CX2000. These are the industrial computers that command actuators (valves, motors) and read sensors (temperature, pressure, position). Historically they communicate via proprietary protocols (Siemens S7comm, Modbus TCP, Profinet).
- Next-generation IoT sensors: LoRaWAN or Zigbee wireless sensors for temperature or humidity, vibration sensors on bearings, communicating energy meters. These sensors bypass the PLC and publish directly via MQTT.
- SCADA systems: Ignition (Inductive Automation), Aveva System Platform, Siemens WinCC. These software platforms supervise the entire shop floor and already aggregate data from PLCs and sensors.
This layer generates heterogeneous data in different formats at frequencies ranging from 100 ms (process control) to 10 minutes (energy meter). The job of the next layer is to unify it.
Layer 2 — Edge Gateway and Broker (OPC-UA, MQTT, Ignition)
This is the local intelligence layer. It runs on servers physically located inside the plant — “edge computing” as opposed to centralised cloud. Its role: collect data from equipment, filter it, aggregate it, normalise it, and transmit it to the ERP or a cloud broker.
OPC-UA (IEC 62541) is the standard protocol for communication between heterogeneous industrial equipment. Published by the OPC Foundation and standardised as IEC 62541 (the EN IEC 62541-1:2026 edition was recently finalised), OPC-UA offers two decisive advantages for ERP integration:
- Multi-vendor interoperability: a single OPC-UA server reads a Siemens PLC, a Schneider controller, and a Beckhoff sensor interchangeably — no proprietary development required.
- Structured information model: data is not raw streams but typed objects with units, reliable timestamps, and contextual metadata (which machine, which sensor, which process). The ERP can interpret them without transformation.
MQTT (Message Queuing Telemetry Transport) is the lightweight pub/sub protocol adopted for low-bandwidth sensors or intermittent connections. An IoT sensor on battery publishes its reading to an MQTT topic (e.g. plant/line3/level_sensor/value), and an MQTT broker (Mosquitto, HiveMQ, EMQX) redistributes that message to all subscribers — including the ERP connector. MQTT and OPC-UA are not competitors: modern architecture combines both, OPC-UA for structured real-time data from PLCs, MQTT for lightweight sensors at the edge.
Industrial edge middleware implementing these protocols includes several widely-adopted options:
- PTC Kepware: universal aggregator (600+ PLC drivers) with OPC-UA output and native SAP connectors
- Cogent Datahub: OPC-UA/MQTT bridge with filtering and caching
- Ignition (Inductive Automation): SCADA + IIoT gateway platform with ERP connection module
- Siemens MindSphere: Siemens IoT cloud platform, native for Siemens equipment, with REST API towards the ERP
Middleware selection depends on the existing equipment base, budget, and the OT competency level of the IT team.
Layer 3 — ERP Connector (REST/SOAP API, ESB, Vendor-Native Connector)
This is the layer that brings data into the ERP. Three approaches coexist:
REST or SOAP API: virtually all modern ERPs expose APIs. The edge gateway calls the ERP API to create a maintenance work order, update a stock quantity, or record a quality control measurement. This approach is generic but requires managing call frequency — do not flood the ERP with 10,000 requests per minute.
Message bus / ESB: an Enterprise Service Bus (MuleSoft, IBM MQ, Apache Kafka) sits between the edge gateway and the ERP. It manages queues, retries on ERP unavailability, and format transformations. Recommended when multiple ERPs or multiple source systems are involved.
Vendor-native connector: SAP offers SAP Edge Services, IFS offers native MQTT connectors in IFS Cloud. These connectors are optimised for their respective ERP but their functional scope and licensing models vary — details in the next section.
Native Connectors by ERP Vendor: What Is Delivered vs. What Must Be Built
SAP S/4HANA: SAP Edge Services and SAP IoT
SAP provides two building blocks for IIoT integration:
SAP Edge Services is a lightweight runtime deployed on-premises (on-site or edge VMs) that collects OPC-UA data from equipment, applies local processing rules, and transmits it to SAP S/4HANA or SAP IoT. It supports predictive maintenance and equipment tracking scenarios. SAP Edge Services is included in some RISE with SAP editions, but advanced scenarios often require a separate add-on — confirming the exact scope with your SAP account executive before budgeting is essential.
SAP IoT Application Enablement (rebranded and integrated into SAP BTP) allows you to define connected objects (a machine, a sensor) with their properties and hook their data to SAP business processes (PM — Plant Maintenance, PP — Production Planning). Development remains necessary to map MQTT topics or OPC-UA tags to SAP objects.
Concrete connection with PTC Kepware: Kepware publishes OPC-UA data to SAP PCo (Plant Connectivity), which forwards it to SAP MII (Manufacturing Integration and Intelligence) or directly to SAP S/4HANA via RFC/BAPI. SAP PCo is limited to 128 simultaneous data sources in its standard configuration — a point to verify for large multi-line plants.
IFS Cloud: IFS Connected Assets and Native MQTT Connectors
IFS Cloud natively integrates the concept of connected assets through the IFS Connected Assets module. This module includes a built-in MQTT broker that receives equipment data (via IoT agents deployed at the edge) and automatically associates it with asset records in IFS. When a vibration sensor exceeds a threshold, IFS automatically creates a work order in the maintenance module — no additional development required.
This is a genuine differentiator for manufacturers where maintenance and asset management are critical (energy, transportation, heavy manufacturing). IFS’s asset-centric information model aligns naturally with the logic of IoT data tied to a physical piece of equipment.
Infor CloudSuite Industrial: Infor OS and Integration Hooks
Infor CloudSuite Industrial (formerly SyteLine) relies on Infor OS as its integration and orchestration layer. Infor OS exposes REST APIs and ION (Intelligent Open Network) connectors for external data integration. Connecting to an IIoT gateway typically goes through an ION webhook or a REST API called from the edge middleware.
Infor does not offer a native MQTT broker as capable as IFS. IIoT integration with Infor CloudSuite usually requires a third-party middleware layer (MuleSoft or Kepware) to transform IoT data into ION messages compatible with the ERP.
Odoo and Dynamics 365 Business Central: Community Connectors
Odoo (versions 16, 17, and 18) does not include a native IIoT connector in the standard product. OCA (Odoo Community Association) modules exist for MQTT connectivity and automatic maintenance order creation, but maturity varies. For critical industrial use, custom development or a dedicated middleware remains necessary. Odoo’s well-documented REST API simplifies custom integration.
Dynamics 365 Business Central integrates with IIoT primarily through Azure IoT Hub (Microsoft). Sensor data flows through IoT Hub, is processed by Azure Stream Analytics or Azure Functions, then flows into Business Central via API or the native Azure connector. This full-Azure architecture is coherent for manufacturers already in the Microsoft ecosystem, but introduces a cloud dependency that some CIOs prefer to avoid for latency or data sovereignty reasons.
Summary comparison table:
| ERP Vendor | Native IIoT Connector | Native MQTT | Native OPC-UA | Notes |
|---|---|---|---|---|
| SAP S/4HANA | SAP Edge Services + PCo | Via SAP BTP IoT | Via PCo | Add-on depending on edition, verify licence scope |
| IFS Cloud | IFS Connected Assets | Yes (built-in broker) | Via IoT agents | Strong native integration for maintenance/assets |
| Infor CloudSuite Industrial | ION via REST API | Not native | Not native | Third-party middleware recommended (Kepware, MuleSoft) |
| Odoo | OCA modules (community) | Community modules | Community modules | Custom development likely for critical use |
| Dynamics 365 BC | Via Azure IoT Hub | Via Azure | Via Azure | Cloud-first architecture, strong Azure dependency |
Practical Implementation: The 5 Steps of an IIoT-ERP Project
Step 1 — Data Source Inventory
Before any deployment, exhaustively map equipment, communication protocols, and data quality. Key questions: Which PLCs are already networked? Which are isolated? What sensors exist and what parameters do they measure? What is the update frequency for each source?
This step routinely surfaces surprises: 15-year-old controllers that do not support Ethernet, sensors with no digital output capability, or proprietary protocols without public documentation. Inventory conclusions directly condition the edge layer budget.
Step 2 — Choose the Protocol for Your Use Case
The basic rule is straightforward:
- OPC-UA for structured, reliably real-time data from PLCs and SCADA. Ideal when data semantics matter (which variable, which equipment, which alarm).
- MQTT for low-bandwidth sensors, long-distance communications (multiple buildings, LoRaWAN networks), or environments where protocol lightness is paramount.
In most industrial projects, both protocols coexist. The Unified Namespace architecture standardises all MQTT topics and OPC-UA tags into a coherent tree (enterprise/site/zone/equipment/variable), accessible to all data consumers — ERP, MES, SCADA, analytics.
Step 3 — Select the Edge Layer
The edge gateway is the central component of the project. It must be:
- Physically close to equipment (low OT network latency)
- Redundant (if the gateway fails, data stops flowing)
- Remotely administrable (firmware updates without physical intervention)
Hardware options range from DIN-rail industrial PCs (Siemens IPC227, Moxa V2401) to more powerful edge servers for complex sites. Software options: Kepware (Windows), Ignition Edge (Linux/Windows), or cloud-native edge solutions (AWS IoT Greengrass, Azure IoT Edge) for well-connected sites.
Step 4 — Map Data Flows to ERP Processes
Each IIoT data flow must be mapped to a specific ERP business process:
| IIoT Source | Target ERP Process | ERP Object Created/Updated |
|---|---|---|
| Line output parts counter | PP — Production Planning | Production declaration, stock movement |
| Bearing vibration sensor | PM — Plant Maintenance | Preventive maintenance notification |
| Raw material silo level sensor | MM — Materials Management | Automatic purchase request |
| Per-machine electricity meter | CO — Controlling | Actual energy cost allocated to production order |
| Kiln temperature sensor | QM — Quality Management | Process parameter recorded for traceability |
This mapping table is the project governance document. Each row represents an interface to develop, test, and maintain. The broader the scope, the more complex the project — start with two or three high-value flows and expand progressively.
Step 5 — Data Governance and IoT Data Quality
IoT data is not perfect. Sensors fail, network connections drop, outliers (spurious readings) appear. Without governance, these imperfections propagate into the ERP.
Key controls to implement:
- Duplicate detection: an MQTT message can be received twice (at-least-once delivery). The ERP must deduplicate before creating a transaction.
- Missing value handling: if a sensor sends no data for five minutes, should the ERP consider the last value valid or trigger an alert?
- Sensor quality alarms: OPC-UA natively carries a quality indicator (Good/Bad/Uncertain) on every value. The ERP must check this before acting.
- Appropriate refresh frequency: there is no need to call the ERP 10 times per second to update a stock level. The edge gateway aggregates and sends only one ERP transaction every 30 seconds, or on each significant state change.
Measurable ROI: Metrics to Track
IIoT-ERP integration is justified by concrete results, measurable before and after deployment. Three metrics consistently appear across manufacturing case studies.
Reduction in Manual Data Entry
Every time an operator manually keys a produced quantity, a quality result, or a downtime duration into the ERP, there is error risk and a time delay. A mid-sized plant with 50 operators may spend 5 to 10% of production time on data entry. IIoT connectivity automates that entry for measurable data (quantities, process parameters, consumption), freeing operators for higher-value tasks.
Improved OEE and Reduced Downtime
According to consolidated data from IoT Mag (2025), IIoT-sensor-driven predictive maintenance reduces unplanned downtime by 35 to 50% and improves OEE by 20 to 25%. A documented Siemens (2024) case study on a production line shows monthly downtime reduced from 39 hours to 27 hours after integrating vibration sensors connected to the maintenance system.
These gains depend on the complete chain being in place: sensor → alert → maintenance work order in the ERP → intervention scheduling → spare parts procurement. If the alert stays in the SCADA without surfacing to the ERP, preventive maintenance remains manual.
Actual Cost-of-Goods Accuracy
The cost of goods calculated by the ERP often incorporates assumptions about material and energy consumption. When IIoT sensors provide actual consumption per machine, per production order, cost control teams finally have an accurate view of product margin. Pricing and product mix decisions improve considerably as a result.
The payback period for a well-scoped IIoT-ERP project typically falls between 6 and 18 months for critical production equipment, according to Faclon Labs (2025) analysis across a panel of manufacturing projects.
Pitfalls and Key Risks
OT network latency vs. ERP transaction frequency. The shop floor network (OT) can have very low latency (under 1 ms on Profinet). The ERP is not designed to absorb transactions at that frequency. The edge layer must aggregate and filter — forwarding to the ERP only data that has changed significantly, not every raw measurement. Without this filter, the ERP is overwhelmed and performance degrades for all users.
OT/IT separation: the ERP must never be directly exposed to the shop floor network. The OT network (controllers, sensors, machines) operates under different security constraints than the IT network (offices, ERP, Active Directory). The IEC 62443 standard (security for industrial automation and control systems) recommends strict segmentation with an industrial DMZ between the two networks. The edge gateway sits in this DMZ — collecting on the OT side and publishing on the IT side — without creating direct flows between the two zones. Exposing the ERP directly to the shop floor network is a serious security failure.
Sensor firmware management and protocol compatibility. An IoT sensor deployed today may require a firmware update in 18 months to patch a vulnerability. In a manufacturing environment, updates cannot be applied during production runs. The lifecycle management of sensors (firmware, protocol compatibility, end of support) must be built into the operational maintenance contract from project launch.
Regulatory and framework compliance. Beyond IEC 62443 for OT/IT cybersecurity, two frameworks shape industrial IIoT projects across Europe: RAMI 4.0 (Reference Architecture Model Industrie 4.0, Germany), which defines communication and information layers for connected plants, and the Smart Industry programmes active in the UK, Netherlands, and Scandinavia, backed by national manufacturing bodies and EU structural funds. These are not regulatory mandates but proven architecture guides with strong ecosystem support. Non-European manufacturers can reference the Smart Manufacturing Leadership Coalition (SMLC) framework and IIC (Industrial Internet Consortium) reference architecture, which align with the same OPC-UA and MQTT building blocks.
Further Reading
This guide covers the IIoT-ERP connection architecture. To complete your picture of the connected plant, three directly related resources on this blog:
- Manufacturing ERP: MES, IoT, and Industry 4.0 — the overview of MES flows and real-time ERP-MES data exchange, essential groundwork before deploying the IIoT layer.
- ERP and Digital Twins — the logical next step after IIoT connectivity: building digital models of equipment for simulation and optimisation.
- ERP and Lean Manufacturing: Kanban, OEE, Kaizen — how lean methods leverage the real-time data that IIoT connectivity makes available.
