Industrial Networks, Connectivity, and Data Acquisition
This domain tests network segmentation, industrial protocol selection, deterministic behavior, and reliable data acquisition from controllers to historians and cloud services.
Core rules
- Segment by Purdue level and by function. A DMZ between IT and OT prevents direct enterprise-to-controller traffic.
- Modbus TCP is simple request/response and has no built-in authentication or encryption; protect it with conduits and compensating controls.
- PROFINET and EtherNet/IP are fieldbus/control protocols; OPC UA provides structured, secure client/server and publish/subscribe data exchange; MQTT is lightweight publish/subscribe, and Sparkplug B adds state awareness and payload structure.
- Real-time closed-loop control stays on deterministic wired networks. Wi-Fi, public cloud, and best-effort routing are for supervisory or analytical traffic, not motion or interlock control.
- Acquisition design must define polling rate, deadband, timestamp source, buffering, and time synchronization (NTP or PTP).
Worked example
An ERP system needs work orders from MES, while a cloud dashboard needs machine temperature. Do not connect ERP directly to a PLC. Place MES and the historian at Level 3, an MQTT broker or OPC UA gateway in the Level 3.5 DMZ, and allow only required flows: OPC UA from Level 3 to the DMZ, MQTT over TLS from the DMZ to cloud, and no inbound sessions from Level 4 to Level 2. The reasoning is blast-radius reduction: each conduit carries only the protocol, direction, and data needed for the use case.
Traps
Assuming Modbus has security; polling every tag at maximum rate and overloading controllers; using a cloud broker for control loops; omitting buffering during network outages; and confusing OPC UA with a fieldbus.
Key points
- Use Purdue-level segmentation and a DMZ.
- Match protocol to purpose: control, supervisory, or cloud.
- Protect legacy protocols with conduits and compensating controls.
- Define polling, deadband, timestamps, and buffering explicitly.