Industrial networks and IT/OT integration

A modern robot cell is a small network. The PLC exchanges data with the robot controller, servo drives, valve terminals, vision systems, safety devices and the operator panel, many times a second and with guaranteed timing. Above the cell, production data flows to manufacturing execution systems, maintenance software, dashboards and cloud analytics, while production orders and recipes flow down. This lesson explains the networks that carry this traffic: industrial Ethernet protocols for real-time control, device-level links such as IO-Link, and information-level technologies such as OPC UA and MQTT that connect operational technology (OT) to information technology (IT). It ends with the security architecture that keeps a connected factory from becoming an open door. ROB-320 covered real-time communication principles and ROB-360 covered security for connected robots; this lesson applies both to the factory floor.

Levels of automation and the flow of data

Factory data is usually described in levels. The Purdue Enterprise Reference Architecture, from the 1990s, and the ISA-95 standard (IEC 62264) both describe a hierarchy. Level 0 is the physical process: sensors, actuators and robots' motors. Level 1 is basic control: PLCs, robot controllers and drives. Level 2 is supervisory control: HMIs and SCADA systems. Level 3 is manufacturing operations management, including the manufacturing execution system (MES), which tracks orders, materials, quality and genealogy. Level 4 is business planning and logistics, including enterprise resource planning (ERP). Each level has different timing needs: microseconds to milliseconds at levels 0 and 1, seconds at level 2, minutes to hours at levels 3 and 4.

The neat pyramid is increasingly blurred. Smart sensors report diagnostics directly to maintenance systems, edge computers near machines run analytics, and cloud platforms collect data from many plants. The term Industry 4.0, coined in Germany around 2011, and the broader idea of the industrial internet of things describe this shift toward connected, data-driven production. Yet the timing requirements of the bottom levels have not changed: a servo loop still needs data every fraction of a millisecond, and a safety stop still has to arrive on time.

From fieldbuses to industrial Ethernet

Before Ethernet reached the factory floor, devices were connected by fieldbuses: serial networks such as Modbus RTU (1979), PROFIBUS (late 1980s), DeviceNet and CANopen (1990s), each promoted by different suppliers. They replaced bundles of individual wires with a single cable and allowed diagnostics, but they were slow by today's standards and incompatible with each other. Since the early 2000s, industrial Ethernet protocols have replaced most new fieldbus installations. They use standard Ethernet physical layers and often standard switches, but add mechanisms for deterministic timing.

The choice of protocol is usually dictated by the PLC brand the plant has standardized on, since each major PLC vendor favors one. Robot controllers, vision systems and drives therefore typically offer options for several protocols. Plants in North America have historically used a great deal of EtherNet/IP because of Rockwell Automation's market share, while PROFINET is common in Europe and in plants with Siemens controls, and EtherCAT is popular for high-performance motion and in machines built on PC-based control.

How the protocols achieve determinism

EtherNet/IP carries the Common Industrial Protocol (CIP), which DeviceNet also uses. Cyclic input and output data travel as implicit messages, UDP packets sent at a configured requested packet interval (RPI) by both sides of a connection, while configuration and diagnostics use explicit request-response messages over TCP. Determinism comes from keeping networks lightly loaded and using managed switches with quality of service, rather than from special hardware. A practical limit is how many packets per second the PLC's communication module and each device can handle.

PROFINET defines conformance classes. Real-time (RT) communication sends cyclic data directly in Ethernet frames, without IP and UDP, and gives them priority on switches; it covers most factory automation. Isochronous real-time (IRT) adds time scheduling in hardware: switches reserve a part of every cycle for real-time frames, and clocks are synchronized, allowing cycle times well below a millisecond with very low jitter for motion control. Time-sensitive networking (TSN), a family of IEEE 802.1 standards, brings similar scheduling to standard Ethernet, and both PROFINET and other protocols are adopting it.

EtherCAT takes a different approach. The master sends one Ethernet frame that passes through every device in a line or ring. Each device reads the outputs addressed to it and inserts its inputs as the frame passes, with a delay of well under a microsecond in hardware, and the frame returns to the master. Because one frame serves many devices, efficiency is very high and cycle times can be very short. Distributed clocks synchronize all devices to well under a microsecond.

# Rough EtherCAT cycle time: transmission plus per-device forwarding delay
def ethercat_cycle_us(n_devices, bytes_per_device, fwd_delay_us=0.7, overhead_bytes=60):
    payload = n_devices * bytes_per_device
    frame_bytes = payload + overhead_bytes          # headers, preamble, gap (approximate)
    t_tx = frame_bytes * 8 / 100e6 * 1e6            # 100 Mbit/s, microseconds
    t_fwd = n_devices * fwd_delay_us                # delay through each device
    return t_tx + t_fwd
for n in (8, 24, 50, 100):
    t = ethercat_cycle_us(n, 16)                    # e.g. 8 bytes out and 8 bytes in per servo drive
    print(f"{n:3d} drives: about {t:5.0f} us per frame, room for a {max(62.5, 2 * t):.0f} us cycle")

  8 drives: about    21 us per frame, room for a 62 us cycle
 24 drives: about    52 us per frame, room for a 105 us cycle
 50 drives: about   104 us per frame, room for a 208 us cycle
100 drives: about   203 us per frame, room for a 406 us cycle

The estimates show why EtherCAT is used for machines with dozens of synchronized servo axes. They are simplified: real cycle times also depend on the master's processing, the number of frames, cable lengths and the slowest device's capabilities, and a cycle is normally chosen with margin above the frame time.

IO-Link and smart devices

Not every sensor needs Ethernet. IO-Link, standardized as IEC 61131-9, is a point-to-point serial link that runs over the same unshielded three-wire cable as a conventional 24 V sensor. An IO-Link master, itself connected to the PLC over industrial Ethernet, talks to several devices. Each device can send process data, such as a distance or a vacuum level, along with diagnostics and identification, and the master can download parameters. Replacing a failed sensor becomes plug-and-play: the master restores the parameters automatically. For robot grippers, IO-Link vacuum switches, valve terminals and electric grippers reduce wiring through the dress pack and allow condition monitoring, such as watching vacuum build-up times to detect worn cups, which Lesson 10 uses for predictive maintenance.

OPC UA: interoperable information

OPC Unified Architecture (OPC UA), standardized as IEC 62541, is the main technology for exchanging structured information between machines and higher-level systems. Unlike earlier OPC, which depended on Microsoft Windows, OPC UA is platform-independent. A server exposes an address space of nodes, such as variables, methods and objects, organized by an information model, and clients browse, read, write, subscribe to changes and call methods. Security, with authentication, signing and encryption, is built into the specification. Companion specifications define standard information models for whole classes of equipment; the OPC UA for Robotics companion specification, developed with the VDMA, describes robot identification, status, axes and diagnostics in a vendor-independent way, so that the same dashboard can read data from robots made by different companies.

OPC UA originally used a client-server model, which suits supervisory systems that poll or subscribe to specific data. A publish-subscribe extension supports one-to-many distribution, over UDP for fast local exchange or over MQTT toward cloud systems. Work under the OPC Foundation's Field Level Communications initiative aims to carry OPC UA down to the controller-to-controller and field device level using TSN, though conventional industrial Ethernet protocols remain dominant there in 2026.

MQTT and the unified namespace

MQTT, a lightweight publish-subscribe protocol originally designed in 1999 for monitoring oil pipelines over satellite links and now an OASIS standard, has become popular for sending factory data to IT systems. Devices publish messages on hierarchical topics to a broker, and any number of clients subscribe to the topics they need. Publishers and subscribers do not need to know about each other, which makes systems easy to extend. Three quality-of-service levels trade reliability against overhead: at most once, at least once, and exactly once. The Sparkplug specification, now managed by the Eclipse Foundation, adds a standard topic structure, payload encoding and device state management for industrial use.

Topic:   acme/hamilton/press-shop/cell-07/robot-1/status
Payload: {"timestamp": "2026-10-24T14:03:12.481Z",
          "mode": "AUTO", "program": "tend_lathe_v3", "step": 30,
          "cycle_time_s": 41.8, "parts_good": 1123, "parts_rejected": 7,
          "joint_temps_c": [41.2, 44.0, 39.8, 36.1, 35.7, 33.9],
          "fault_code": 0}

A design pattern called the unified namespace organizes all of a company's real-time data into a single topic hierarchy, often following the ISA-95 structure of enterprise, site, area, line and cell, so that any authorized application can find current data in a predictable place instead of through point-to-point integrations. Whether an organization uses OPC UA, MQTT or both, the hard work is the same: agreeing on names, units, data types and meanings, so that a dashboard showing cycle time in seconds does not quietly mix in values from a robot reporting milliseconds.

Security: zones and conduits

Connecting machines to plant and cloud networks creates paths for attackers. Industrial control systems have been targeted by malware designed to sabotage processes, such as Stuxnet, discovered in 2010, and many plants have been halted by ransomware that entered through business IT networks. The IEC 62443 series is the main international framework for industrial automation and control system security. Its central idea is to divide the system into zones of equipment with similar security needs, connected through conduits whose traffic is controlled and monitored. A typical architecture places an industrial demilitarized zone (DMZ) between the business network and the plant network, so that no traffic passes directly from one to the other; data is relayed through servers in the DMZ.

Robot-specific concerns include remote access used by integrators for support, which should go through a controlled gateway and be switched on only when needed, and the ability of anyone on the network to change robot programs or parameters. The 2025 robot safety standards, ISO 10218-1 and -2, added requirements to consider cybersecurity threats where they could affect safety functions, reflecting the recognition that a network attack could change speeds, zones or safety configurations. Safety configurations should be protected by passwords and checksums that are recorded at commissioning and checked periodically. In Canada and the United States, government agencies such as the Canadian Center for Cyber Security and the US Cybersecurity and Infrastructure Security Agency (CISA) publish guidance and advisories for industrial control systems.