Do I really need a separate MES if I already plan to deploy Business Central with dvproduction?

For most discrete and process manufacturers between 80 and 300 employees with 1–3 plants, no. dvproduction extends Business Central to cover ISA-95 level 3 functions — order release, shop-floor data capture, OEE, traceability — without a separate MES database. A standalone MES is justified when you operate in heavily regulated industries with electronic batch records (FDA 21 CFR Part 11, full GMP audit trails), or when you run more than 5 plants with diverging local processes. Below that threshold, a separate MES creates more interface debt than business value.

Which IoT protocol should I standardize on: OPC-UA, MQTT or something proprietary?

For new installations, OPC-UA for machine-to-edge communication and MQTT for edge-to-cloud transport is the safest combination in 2026. OPC-UA is the de facto standard for industrial equipment from Siemens, Rockwell, B&R and most modern PLCs. MQTT is lightweight enough to push thousands of tags per second to Azure IoT Hub without saturating plant networks. Proprietary protocols (Modbus TCP, custom OEM stacks) still appear in legacy lines — the edge gateway is where you normalize them into OPC-UA or MQTT before anything reaches the ERP.

How quickly do you actually see OEE improvements after going live?

Honest answer: not in month one. The first 8–12 weeks after go-live are spent stabilizing data capture and getting operators to register downtime reasons consistently. OEE numbers in that window are noisy. Real, defensible OEE improvement — typically 5 to 12 points — shows up between months 4 and 9, once micro-stops are visible, downtime codes are clean, and planners start scheduling around real bottlenecks instead of estimates. Anyone promising 20 points in 90 days is selling a slide, not a result.

Can the same stack handle discrete and process manufacturing in the same Business Central instance?

Yes, with caveats. dvproduction supports both modes in a single tenant: discrete uses BOM, routings and operation-level capture; process uses formula-based recipes, yield management and batch traceability. The shared parts — IoT capture, OEE, maintenance, quality — work identically. Where you do need extra design effort is in costing (process needs co-product and by-product allocation) and in regulatory traceability (process is usually GMP-heavier). A mixed plant doing semi-finished process plus finished discrete is handled in one instance; multi-plant groups with very different regulatory regimes sometimes split into two companies under the same tenant.

What does the integration with Azure IoT Hub look like in practice?

The edge gateway publishes telemetry to Azure IoT Hub over MQTT. Stream Analytics or Azure Functions filter and aggregate the stream (you do not want 50,000 raw tag updates per minute hitting Business Central). Aggregated events — production counts, downtime starts/stops, alarm conditions — land in Business Central through a custom connector that dvproduction provides. Heavy time-series data stays in Azure Data Explorer or Microsoft Fabric for long-term analytics, while the ERP keeps only the events relevant to costing, planning and traceability. This separation is what keeps Business Central performant once you scale to multiple plants.

What is a realistic budget for an Industry 4.0 rollout of this scope?

For a single discrete plant with 80–150 employees, 6–10 work centers and basic IoT instrumentation, the all-in cost — Business Central licenses, dvproduction/dvgmao/dvquality, edge gateways, sensor retrofits where needed, Azure consumption, and Davisa professional services — typically lands between €180k and €350k over the first 18 months. Multi-plant rollouts after the first template is stable add 35–55% per additional site, not 100%, because most of the analysis and configuration is reused. These are real numbers from recent projects, not list-price extrapolations.

Volver a dvproduction Volver a dvgmao Volver a dvquality

Microsoft Business Central

Industry 4.0 Stack on Business Central

How to build a real Industry 4.0 stack on Microsoft Business Central: sensors, edge, MES, ERP and analytics. Practical scope, not slideware.

7 min

Industry 4.0 stack architecture on Microsoft Dynamics 365 Business Central with dvproduction, dvgmao and dvquality

Industry 4.0 architecture on Microsoft Dynamics 365 Business Central, deployed by Davisa — Microsoft Solutions Partner for Business Central since 2003

Industry 4.0 has been a buzzword for a decade. By 2026, the term has lost most of its marketing weight and become something more useful: a reasonably stable reference architecture that mid-sized manufacturers can actually buy, deploy and operate. The pieces are commoditized, the protocols are settled, and the integration patterns are documented.

This article walks through the five-layer stack we deploy at Davisa for industrial customers, how Microsoft Business Central plus the dv* extensions map onto it, which IoT patterns work in the field, and what KPIs you can realistically expect to move.

REQUEST A TECHNICAL DEMO

What Industry 4.0 means in 2026 (beyond the buzzword)

Strip away the marketing and Industry 4.0 reduces to four operational shifts:

Machines emit data continuously, not at end-of-shift handover.
That data is normalized and aggregated before it reaches the ERP, so planners see signal instead of noise.
Decisions move closer to the event — a downtime is logged when it starts, not reconstructed two days later from a paper sheet.
The same data feeds finance, maintenance and quality, not just production.

Everything else — digital twins, AI vision, predictive maintenance, autonomous AGVs — is built on top of those four shifts. If your shop floor still runs on whiteboards and end-of-shift Excel, no amount of AI will fix that. The foundation has to come first.

The 5 layers of a real I4.0 stack

The reference architecture we deploy has five layers, each with a clear responsibility and a clear handoff to the next:

Layer 1 — Sensors and PLC. Physical instrumentation: temperature probes, energy meters, vibration sensors, vision cameras, plus the PLCs and SCADA systems already running the machines. This layer speaks Modbus, Profinet, EtherCAT, or vendor-proprietary protocols.

Layer 2 — Edge gateway. Industrial PCs or ruggedized edge devices sitting next to the line. They translate Layer 1 protocols into OPC-UA or MQTT, buffer data during network outages, and run light pre-processing (deduplication, downsampling, anomaly tagging). This is also where local HMI dashboards live for operators.

Layer 3 — MES / shop-floor execution. Order dispatch, work-in-progress tracking, operator data entry, downtime registration, scrap reporting, traceability genealogy. In a dvproduction deployment this layer is inside Business Central, not a separate database.

Layer 4 — ERP. Planning, costing, procurement, finance, sales, customer service. Business Central sits here, consuming aggregated production events from Layer 3 and pushing back orders, schedules and BOM updates.

Layer 5 — Analytics and AI. Time-series storage (Azure Data Explorer, Microsoft Fabric), dashboards (Power BI), predictive models, energy and sustainability reporting. This layer reads from all the others — never the other way around.

The most common architectural mistake is collapsing layers 2 and 3, or skipping the edge entirely and trying to push raw PLC data straight to the ERP. Both lead to performance problems within 12 months of go-live.

Mapping the stack to Microsoft + Davisa extensions

Layer	Microsoft component	Davisa extension
1. Sensors/PLC	—	—
2. Edge gateway	Azure IoT Edge	dvproduction IoT module
3. MES	Business Central	dvproduction, dvquality, dvgmao
4. ERP	Business Central	dvproduction (costing, planning)
5. Analytics	Power BI, Microsoft Fabric	dvproduction OEE dashboards

The advantage of this mapping is that layers 3 and 4 share the same database. A downtime registered by an operator on a shop-floor terminal immediately affects available capacity in the planning board, automatically creates a corrective work order in dvgmao, and updates the cost of the affected production order. No interface, no batch sync, no reconciliation. That is the reason we recommend keeping MES inside Business Central for SMB manufacturers — every kilometer of interface code you avoid is a kilometer you do not have to maintain.

For deeper scope on the MES side, see our article on Manufacturing Operations Management on Business Central. For maintenance specifically, the comparison Fracttal, Maximo and Mainsaver versus dvgmao covers when a standalone CMMS is worth it.

IoT integration patterns (OPC-UA, MQTT, Azure IoT Hub)

Three patterns cover 95% of the IoT integration work we do in the field:

Pattern A — OPC-UA on the line, MQTT to the cloud. The edge gateway reads PLCs over OPC-UA, aggregates and tags the data, and publishes selected events to Azure IoT Hub over MQTT. Stream Analytics filters and routes events: high-volume telemetry goes to Azure Data Explorer for long-term storage, business-relevant events go to Business Central through the dvproduction connector. This is the default pattern for new lines or lines with modern PLCs.

Pattern B — Modbus retrofit. Older lines without OPC-UA support are retrofitted with low-cost edge gateways that read Modbus TCP and translate to OPC-UA at the gateway. The rest of the stack stays identical. We use this pattern for plants where 30–60% of equipment is more than 15 years old — replacing the PLCs is rarely justified, but adding €600–€2,000 of edge hardware per machine usually is.

Pattern C — Operator-driven capture. Some events cannot be sensed automatically: downtime reasons, quality defects, micro-stop causes. These are captured by operators on touchscreen terminals running the dvproduction shop-floor app. The terminals talk directly to Business Central — no IoT Hub round trip — because the data volume is low and the latency requirements are immediate.

A production-grade plant typically uses all three patterns. Pure-IoT purists who insist on automating every capture point end up with brittle vision systems trying to read damaged labels; pure manual capture loses the high-frequency signal that makes OEE useful. The mix is the answer.

Real KPIs that move (OEE, MTBF, energy/unit, defect rate)

Four KPIs justify the investment in most projects we have audited:

OEE (Overall Equipment Effectiveness). Baseline measurements often start at 45–58% for SMB plants that have never instrumented properly. Realistic post-stabilization range: 62–76%. The first 4–6 points come from making downtime visible; the next come from scheduling and maintenance changes.
MTBF (Mean Time Between Failures). Improves once dvgmao captures real failure events instead of relying on operator memory. Typical improvement: 25–45% over 12 months as preventive intervals get tuned to actual failure patterns instead of OEM defaults.
Energy per unit produced. Energy meters at the line level, normalized against production output, surface the worst offenders. Typical reduction: 6–14% in the first year, mostly from idle-state optimization and shift-changeover discipline.
First-pass defect rate. When dvquality captures inspections in-line instead of at end-of-line, defects are caught one or two operations earlier. Scrap cost drops 10–25% in the first 9 months.

These are ranges from real customer outcomes, not vendor brochures. The variance inside each range depends almost entirely on how disciplined the operations team is about using the data, not on the software.

Implementation roadmap: 18-24 months realistic

A realistic, end-to-end I4.0 rollout for a single mid-sized plant follows this pacing:

Months 1–3 — Foundation. Business Central core go-live (finance, procurement, sales). dvproduction baseline configuration. Master data cleanup (BOMs, routings, work centers). No IoT yet.

Months 4–7 — Shop-floor capture. Touchscreen terminals deployed. Operators trained on downtime registration and production confirmation. OEE measurement starts. dvquality inspection plans live.

Months 8–12 — IoT layer. Edge gateways installed on priority lines. OPC-UA / MQTT integration. Stream Analytics filtering rules. First real OEE numbers stabilize. dvgmao tied to downtime events.

Months 13–18 — Analytics and optimization. Power BI dashboards for line managers and plant leadership. Energy meters. First predictive maintenance models on critical assets. Cost accounting tied to real production data instead of standard rates.

Months 19–24 — Scale. Second plant rollout from the stabilized template, or deeper analytics (digital twin, AI vision, sustainability reporting).

Anyone selling a 6-month full Industry 4.0 rollout for a real industrial plant has never lived through a stabilization phase. Plan for 18–24 months. For broader BC pricing context, see Business Central pricing and license levels in 2026.

The technology has matured enough that Industry 4.0 is no longer a research project — it is an operations program. The hard parts are organizational discipline, master-data hygiene and patience to let the stack stabilize before judging the numbers.

REQUEST A TECHNICAL DEMO