The pressure to add real-time visibility to automotive production lines rarely comes from one direction. An OEM customer asks for traceability data tied to a specific VIN. A plant manager wants downtime reports broken out by shift. A corporate quality team wants live OEE dashboards. All of it lands on the same controls and OT engineers who are already running the existing PLC, SCADA, and machine networks. Those same engineers know that bolting new sensors and gateways onto a stable plant floor is how stable plant floors stop being stable.
A well-designed IIoT monitoring architecture solves that problem by treating monitoring as a layered system, not a single project. For Tier 1, 2, and 3 automotive suppliers, the layers that matter are the edge (the machine and cell level), the broker and transport layer (how data moves), and the cloud or SCADA layer (where data is consumed and analyzed). Getting each layer right and keeping them properly isolated is what separates industrial IoT monitoring that improves the operation from monitoring that introduces new failure points, new attack surfaces, and new compliance exposure.
This guide walks through that architecture from the plant floor up, with a focus on the practical decisions Tier 2 and Tier 3 suppliers face when they do not have a dedicated OT security team and cannot afford to rip out existing controls infrastructure.
Why IIoT Monitoring Architecture Matters More for Smaller Suppliers
Tier 1 suppliers and large OEMs typically have dedicated OT cybersecurity staff, established reference architectures, and the budget to enforce them across multiple sites. Tier 2 and Tier 3 shops generally do not. They have a controls engineer or two, an outside systems integrator when needed, and a corporate IT group whose understanding of the plant floor often stops at the office firewall.
That gap is exactly why the architectural decisions made at the start of an IIoT monitoring architecture project carry so much weight. A poorly designed deployment in a Tier 2 plant can:
- Route raw PLC traffic across the same network segment as office workstations
- Create an unmanaged path between machine controllers and cloud services
- Drop OEE data into a dashboard with no documentation of where the numbers came from
- Fail a customer cybersecurity audit because OT and IT segmentation cannot be demonstrated
The fix is not more software. It is a clean, documented architecture that defines what runs at each layer, how data crosses between them, and where the security boundaries are. The same discipline that goes into a turnkey controls project applies here.
Layer 1: The Edge, Normalizing Data Before It Leaves the Plant Floor
The edge layer is the closest computing layer to the production equipment itself. In an automotive cell, that typically means an industrial PC (IPC) or edge gateway sitting next to the PLC cabinet, pulling tag data from one or more PLCs, CNCs, and sensor networks.
Edge hardware does three jobs that nothing else in the architecture is positioned to do:
- Protocol translation and tag normalization. A typical Tier 2 plant has Allen-Bradley PLCs on one line, Siemens on another, a few CNCs running their own protocols, and a vision system speaking yet another. The edge gateway is where those streams are pulled in over their native protocols and mapped into a common tag structure with consistent naming, units, and timestamps. Without that normalization step, every downstream consumer (every SCADA screen, every analytics platform, every dashboard) has to do the translation itself, and the inconsistencies compound.
- Local buffering and store-and-forward. Networks fail. WAN links to the cloud go down. A properly configured edge node holds data locally during outages and forwards it once connectivity returns, so OEE data and traceability records do not have gaps that the quality team has to explain to a customer auditor.
- Pre-processing and filtering. Sending every raw tag change to the cloud is expensive in bandwidth, slow to query, and almost never useful. The edge is where high-frequency sensor data gets aggregated into the metrics that actually matter (cycle time per part, scrap counts per shift, downtime events with reason codes) before anything leaves the plant.
Processing at the edge also reduces latency for any control or alerting logic that needs to act quickly. A vision inspection result that triggers a reject mechanism cannot wait for a round trip to a cloud server. A practical architecture keeps deterministic, time-critical logic on the PLC and uses the edge layer for the supervisory and monitoring data that informs decisions but does not directly control the line. South Shore Controls’ work in robot integration and HMI programming follows the same separation.
Layer 2: Transport, MQTT Sparkplug B, OPC UA, and Why You Need Both
A large roll of material such as laminate is cut into a smaller size that matches your application. Slitting as a manufacturing process reduces waste and is more economical for material converting.
OPC UA: Device and Server Communication
OPC UA is the modern standard for deterministic, session-based communication between industrial devices, controllers, and supervisory systems. It runs over TCP, supports rich data modeling, and is well suited to the southbound side of an edge gateway. In practice, that is the part of the architecture where the gateway is talking directly to PLCs, CNCs, and other controllers.
Most current-generation PLCs from the major vendors expose an OPC UA server natively or through a companion module. That makes OPC UA the natural choice for getting structured tag data out of a controller and into the edge layer without having to maintain a different driver for every brand of equipment. Session-based behavior, strong typing, and built-in security make it well suited to staying inside the OT network where deterministic behavior matters.
MQTT Sparkplug B: Broker-to-Cloud Transport
MQTT is a publish/subscribe messaging protocol. Vanilla MQTT, on its own, does not define payload structure or topic naming conventions, which means two MQTT-based systems from different vendors generally cannot interpret each other’s data without custom mapping.
MQTT Sparkplug B fixes that. It is an open specification published under the Eclipse Foundation that sits on top of MQTT and defines:
- A standard topic namespace structure (group/edge node/device/metric)
- A standard payload encoding using Google Protocol Buffers
- Standard message types for birth, data, death, and command, so the broker and any subscribing application always know the state of every connected node
That standardization is what makes Sparkplug B interoperable across vendors and SCADA platforms. A historian, an analytics tool, and an MES that all subscribe to the same Sparkplug-compliant broker can consume the same data without custom integration work between each pair. Eclipse Mosquitto is the widely used open-source MQTT broker that supports Sparkplug B payloads when configured appropriately.
How They Work Together
The practical pattern that has emerged in mature plants looks like this:
- Inside the OT network: Edge gateways pull data from PLCs and other controllers over OPC UA. This keeps device-level communication on a protocol designed for it.
- From the edge to the broker: The edge gateway publishes normalized data into an MQTT broker using MQTT Sparkplug B payloads.
- From the broker to consumers: SCADA, historians, OEE platforms, and cloud analytics subscribe to the topics they care about.
This pattern gives you deterministic, well-modeled communication where you need it (at the device level) and decoupled, scalable, interoperable communication where you need that (at the data distribution layer). Adding a new analytics consumer becomes a matter of pointing it at the broker, not retrofitting integrations into every PLC.
Layer 3: Cloud and SCADA, Where OEE Data Actually Gets Used
The top layer is where data becomes information. This is where SCADA visualization, MES integration, historians, and cloud analytics live. For automotive suppliers, the most common use cases at this layer are:
- OEE data dashboards covering availability, performance, and quality across lines, shifts, and product families
- Downtime reason code tracking with drill-down to specific machines and cells
- Traceability records that tie part-level data (cycle time, torque values, inspection results) to a serial number or VIN for warranty and recall response
- Predictive maintenance alerting based on trended sensor data
- Cross-plant rollups for multi-line Midwest plants where corporate quality teams need comparable metrics across facilities
The architectural rule at this layer is that it consumes from the broker. It does not reach down into the OT network to pull data directly from PLCs. That separation is what makes the rest of the security model possible.
A common deployment splits the SCADA function: a plant-floor SCADA layer for operator HMI and supervisory control that lives inside the OT network, and a cloud or corporate analytics layer that sits outside it. Both can subscribe to the same Sparkplug-compliant broker, with the broker (or a federated broker pair across the DMZ) acting as the controlled boundary between them. South Shore Controls’ IoT monitoring work is built around exactly this kind of layered consumption model.
Security and Segmentation: Applying NIST SP 800-82 Rev. 3
Industrial cybersecurity for an IIoT monitoring architecture is not an add-on. It is the part of the design that determines whether the rest of it is defensible.
NIST SP 800-82 Revision 3, Guide to Operational Technology Security, is the governing federal framework for ICS and OT environments. It is not automotive-specific, but it is the document that automotive cybersecurity audits, customer questionnaires, and IATF-aligned cybersecurity expectations increasingly reference. Two parts of SP 800-82 Rev. 3 matter most for an iiot architecture design that includes cloud connectivity:
1. Zones and conduits, aligned with IEC 62443. SP 800-82 endorses the zone-and-conduit model from the IEC 62443 series, which says that an OT environment should be divided into zones grouping assets with similar security requirements, with all communication between zones flowing through defined, controlled conduits. In a practical Tier 2 plant, that translates to:
- A cell or process control zone for PLCs, CNCs, drives, and the edge gateway that talks to them
- A supervisory zone for plant-floor SCADA and the MQTT broker
- An enterprise/IT zone for corporate analytics, cloud connectors, and business systems
- An industrial DMZ separating supervisory OT from enterprise IT
2. The industrial DMZ and the no-direct-path rule. NIST SP 800-82 is explicit that there should be no direct routable path between OT systems and the public internet, or in most cases between OT systems and the corporate IT network. The accepted pattern is a DMZ that brokers traffic between the two sides. Outbound MQTT connections from a broker inside the supervisory OT zone to a broker (or cloud endpoint) in the DMZ, rather than inbound connections from the cloud reaching down to the plant floor, is one of the standard patterns for achieving this safely.
Additional baseline practices that follow from SP 800-82 and apply directly to industrial IoT monitoring deployments:
- TLS encryption on every MQTT connection, with certificate-based authentication for edge nodes and brokers
- Per-device credentials and role-based access on the broker, not shared accounts
- Network segmentation enforced by firewalls or industrial security appliances at every zone boundary, not just at the IT perimeter
- Logging of broker connection events, authentication failures, and configuration changes
- A documented inventory of every edge device, broker, and subscriber, kept current
For suppliers without an in-house OT security function, working with an integrator who treats segmentation, controls support, and system upgrades as part of the same design conversation is generally the most reliable way to get this right the first time.
A Reference Architecture for a Tier 2 Automotive Plant
Pulling the layers together, a defensible reference deployment for a typical Tier 2 facility looks like:
- Cell zone: PLCs, CNCs, vision systems, and drives on a segmented control network. Edge gateway connected to controllers over OPC UA.
- Supervisory zone: Edge gateway publishes normalized data into a Sparkplug-compliant MQTT broker (Eclipse Mosquitto is a common open-source choice). Plant SCADA and historians subscribe from this same zone.
- Industrial DMZ: A second broker or a reverse proxy sits in the DMZ. The supervisory broker connects outbound to the DMZ broker. No inbound connections from the DMZ into the supervisory zone.
- Enterprise/cloud zone: Corporate analytics, cloud OEE platforms, and MES integrations subscribe from the DMZ broker. All traffic crossing the boundary is TLS-encrypted and authenticated.
- Documentation: Tag dictionary, zone diagram, conduit list, and device inventory are maintained as part of the system documentation, not in someone’s notebook.
This pattern scales down to a single-line cell and up to a multi-site rollout without changing structure. Adding a new subscriber, a new line, or a new plant becomes an additive change, not an architectural rebuild.
How South Shore Controls Approaches IIoT Monitoring in Automotive
South Shore Controls works with automotive suppliers across the Midwest to design and deploy monitoring architectures that hold up under both production demands and customer audits. Our approach combines automation and controls engineering, electrical panel design and build, field service, and integration work in a single team. The people specifying edge hardware are the same people who will commission it, support it, and document it.
For automotive clients specifically, we deliver on our automotive automation projects with a focus on:
- Edge and gateway selection that fits the existing PLC and HMI landscape, not a rip-and-replace
- Sparkplug B and OPC UA integration that gives quality and engineering teams real OEE and traceability data without exposing the plant floor
- DMZ and segmentation design aligned with NIST SP 800-82 and IEC 62443 expectations
- Documentation packages that hold up to OEM cybersecurity and quality audits
- Ongoing preventative maintenance and on-site commissioning so the monitoring system stays as reliable as the production system it watches
Whether the starting point is a single cell on one line or a full plant rollout across multiple facilities, the architecture principles stay the same.
Frequently Asked Questions
Do I need to replace my existing SCADA or DCS system to add IIoT monitoring?
In most cases, no. A properly layered IIoT monitoring architecture sits alongside the existing SCADA or DCS rather than replacing it. Edge gateways pull data from the same PLCs and controllers the SCADA system already talks to, normalize it, and publish it into an MQTT broker. The existing SCADA continues handling operator HMI and supervisory control on the plant floor, while the new monitoring layer feeds OEE dashboards, historians, and cloud analytics. The two systems share data sources but serve different jobs, which means IIoT monitoring can usually be added incrementally (one line or cell at a time) without disrupting the controls infrastructure that production depends on.
How do I prevent IIoT monitoring from opening a security gap between my OT network and the internet or corporate IT?
The short answer is segmentation and direction of traffic. Following NIST SP 800-82 Rev. 3 and the IEC 62443 zone-and-conduit model, the OT network should never have a direct routable path to the internet. Instead, the supervisory zone hosts an MQTT broker, and that broker initiates outbound connections to a second broker or endpoint sitting in an industrial DMZ. The DMZ is what corporate analytics and cloud platforms connect to, never the plant floor directly. Combine that with TLS encryption on every connection, certificate-based authentication for edge devices, per-device credentials on the broker, and firewalled boundaries between zones, and the monitoring system gains visibility into the plant without giving anything on the outside a path in.
Will adding network-connected monitoring devices to my plant floor affect my IATF 16949 or customer-specific OEM quality requirements?
Adding monitoring devices does not by itself create an IATF 16949 problem, but how they are deployed can. IATF 16949 and most customer-specific requirements expect controlled change management, documented configuration, and validated processes. A monitoring system that is patched into the network without documentation, that lacks a tag dictionary, or that pulls data the quality team cannot trace back to a source will create audit findings. The opposite is also true: a well-documented monitoring architecture that captures traceability data, downtime reason codes, and process parameters can strengthen the quality system by providing objective evidence that the OEMs and registrars are increasingly asking for. The deciding factor is whether the deployment is treated as a controls engineering project with the same rigor as any other change to the production system.
Build a Monitoring Architecture That Works for Your Plant
South Shore Controls helps automotive suppliers design and deploy IIoT monitoring architectures that deliver real visibility without compromising network stability or cybersecurity posture. From edge gateway selection through DMZ design, broker deployment, and ongoing support, our team handles the full stack of automation and controls services.
Reach out to our engineering team to discuss your monitoring goals and the existing controls infrastructure they need to work with.
