Industrial Automation: PLCs, SCADA & Fieldbus

Every factory you walk into runs on a stack you probably can't see. The robot arm is the part that moves and the part that gets photographed, but the thing that actually decides whether the cell ships product is a beige box bolted in a cabinet, scanning a program a few thousand times a second and talking to a network of drives, valves, and sensors over a fieldbus that was a religious war twenty years ago and is mostly settled now. That box has been running the same loop (read, solve, write) since a Bedford-Massachusetts engineer named Dick Morley built the first one in 1969 to kill the relay panel. Fifty-plus years and six orders of magnitude of compute later, it still runs that loop, on purpose, because the loop is the whole point. That box is a PLC, the network is a fieldbus, and the screen the operator stares at is SCADA or an HMI. Understand those three things and how they fit together, and you can interface a robot to anything.

This is the long version, written for the people who have to make a robot, a vision system, or an AMR play nicely with a brownfield line that's been running since before some of those engineers were born. We'll go layer by layer: the automation pyramid, the PLC and its scan cycle, the IEC 61131-3 languages you'll actually write, the hardware and the vendors, the fieldbus war and who won which battle, EtherCAT and motion, OPC UA as the IT/OT bridge, SCADA and HMI, then the two things robotics engineers chronically underestimate: the safety handshake and OT cybersecurity. Real products, numbers with units, opinions with reasons.

The take: The PLC is a deterministic machine, and that determinism is the entire point. The fieldbus war is over: PROFINET and EtherNet/IP own discrete automation by region and brand loyalty, EtherCAT owns motion, Modbus refuses to die because it's free, and OPC UA is the only thing everyone agrees to use to get data out. For a robotics engineer, the robot is almost never the master of the cell (the PLC is), and the single most common integration failure is treating the safety handshake as an afterthought rather than the contract that lets the cell legally run with a human nearby.

Companion reading: industrial robot arms, collaborative robots (cobots), real-time control systems, motor controllers & FOC, and mobile robots (AMR/AGV).

Table of contents

1. Key takeaways
2. The automation pyramid: where everything sits
3. What a PLC actually is
4. The scan cycle in detail
5. The IEC 61131-3 languages
6. PLC hardware & the vendors
7. Fieldbus & industrial Ethernet: the war
8. EtherCAT & motion
9. OPC UA & the IT/OT bridge
10. SCADA & HMI
11. Integrating robots with PLCs
12. Functional safety
13. Industrial cybersecurity & the modern stack
14. Frequently asked questions

The automation pyramid: where everything sits

The classic mental model is the automation pyramid (it maps loosely to ISA-95 / IEC 62264), and it's still the fastest way to orient yourself in a plant. From the bottom up:

            ┌───────────────────────┐
   Level 4  │          ERP          │   business: orders, finance
            │   (SAP, Oracle)       │   timescale: days/weeks
            ├───────────────────────┤
   Level 3  │          MES          │   manufacturing execution:
            │ (scheduling, OEE,     │   batch, traceability, quality
            │  recipes, genealogy)  │   timescale: shifts/hours
            ├───────────────────────┤
   Level 2  │     SCADA / HMI       │   supervisory: tags, alarms,
            │  (Ignition, WinCC)    │   historian, operator UI
            ├───────────────────────┤   timescale: seconds
   Level 1  │     CONTROL (PLC,     │   deterministic logic,
            │  PAC, DCS, robot ctrl)│   closed-loop, interlocks
            ├───────────────────────┤   timescale: ms
   Level 0  │  FIELD: sensors,      │   the physical process:
            │  actuators, drives,   │   I/O, valves, motors,
            │  motors, robots       │   encoders, photoeyes
            └───────────────────────┘   timescale: µs-ms

The timescales are the real story. Level 0/1 lives in microseconds to milliseconds and must be deterministic: if a sensor trips, the output has to react this scan, every scan, forever. Level 2 lives in seconds and is best-effort: if the trend chart lags 200 ms nobody cares. Level 3/4 lives in minutes to days and is firmly the IT world. The further up you go, the more you trade determinism for flexibility and data richness.

OT vs IT: the cultural fault line

Operational Technology (OT) is everything from the SCADA layer down: it values availability and determinism above all, runs on 10 to 20 year lifecycles, and treats an unplanned reboot as a production-line stoppage that costs real money per minute. Information Technology (IT) values confidentiality and integrity, patches monthly, and reboots Tuesday night without a second thought.

The OT priority order is A-I-C (availability first); the IT order is C-I-A (confidentiality first). Almost every IT/OT conflict on a plant floor traces back to those two triangles being upside down relative to each other.

This matters enormously for robotics engineers, because a robot cell straddles the line. The robot controller and PLC are OT. The vision system's training PC, the cloud dashboard, the OEE reporting, that's IT reaching down. The bridge between them is, increasingly, OPC UA, which we'll get to.

Where robots and PLCs sit

The PLC is Level 1, the orchestrator. The robot controller is also Level 1: it's a specialized motion controller, peer to the PLC, but in a cell the PLC almost always plays cell master and the robot plays subordinate executor. SCADA at Level 2 watches the whole line, aggregates, and lets the operator intervene. Get this hierarchy clear in your head and most integration questions answer themselves. "Who decides when the robot starts?" The PLC. "Who logs the cycle count for the shift report?" SCADA. "Who closes the servo loop on joint 3?" The robot's own drive, at Level 0/1, far faster than either.

What a PLC actually is

A PLC is a purpose-built industrial computer for deterministic, real-time control of machines and processes. That sounds like a PC with a fancy enclosure, and people who say "it's just a computer" are missing the entire point.

What sets a PLC apart from a general computer

A general-purpose PC running a desktop OS is optimized for average throughput: get a lot of work done over a second, even if any individual task occasionally stalls for 50 ms while the OS does garbage collection or services an interrupt. A PLC is optimized for worst-case latency: every cycle completes within a guaranteed bound, no exceptions, because the alternative is a press cycling while the safety light curtain's reaction got delayed.

The differences that matter:

• Determinism. The PLC executes its program on a fixed cyclic schedule (the scan, next section). Worst-case execution time is bounded and known. A watchdog timer faults the CPU if a scan overruns.
• Ruggedization. Operating temperature −25 °C to +60 °C, conformal-coated boards, DIN-rail mounting, 24 VDC logic, tolerance to vibration, shock, dust, and the electrical noise of a factory floor (think VFDs switching kiloamps nearby). IP20 in a cabinet is typical; field-mounted blocks go IP65/67.
• Robust, repairable I/O. Optically isolated digital inputs, relay or transistor outputs rated to drive real loads, hot-swappable modules, screw or push-in terminals you can wire with cold hands.
• 20-year lifecycles. A ControlLogix or S7 platform is supported and spare-stocked for decades. Try buying a motherboard for a 2006 laptop. The installed base of a factory cannot be re-engineered every three years.
• Ladder heritage and ease of maintenance. The PLC was invented (the Modicon 084, 1969) explicitly to replace banks of relays so a plant electrician (not a programmer) could troubleshoot logic. Ladder Diagram looks like the relay schematics those electricians already read. More than fifty years later, that lineage is why ladder still rules the discrete-logic world: the night-shift maintenance tech can find the fault.

PLC vs PAC vs DCS vs IPC

Some vocabulary you'll trip over:

• PLC: the classic. Modern high-end PLCs blur into PAC (Programmable Automation Controller), same hardware lineage but with more memory, structured data types, motion, and IT connectivity. Rockwell's ControlLogix is marketed as a PAC; functionally it's a very capable PLC.
• DCS (Distributed Control System): the process-industry cousin (oil, chemical, power). Optimized for thousands of analog loops, redundancy, and continuous control rather than fast discrete machine logic. Emerson DeltaV, Siemens PCS 7, ABB 800xA, Honeywell Experion.
• IPC / soft PLC: an industrial PC running a real-time PLC runtime (Beckhoff TwinCAT, CODESYS Control). The hardware is a PC; the determinism comes from a real-time kernel. This is the future of a big slice of the market.

The scan cycle in detail

The scan cycle is the heart of the PLC and the single concept that, once it clicks, makes everything else make sense. The CPU does not run your program "continuously." It runs it cyclically, in a fixed loop:

        ┌──────────────────────────────────────────┐
        │                                          │
        ▼                                          │
  ┌───────────────┐                                │
  │ 1. READ INPUTS│  Copy ALL physical input       │
  │  (input image)│  states into a memory image     │
  └───────┬───────┘  table (PII). One snapshot.     │
          │                                         │
          ▼                                         │
  ┌───────────────┐                                │
  │ 2. EXECUTE    │  Run the user program top-to-   │
  │   PROGRAM     │  bottom, left-to-right, reading │
  │  (logic solve)│  the input IMAGE, not the wires.│
  └───────┬───────┘                                 │
          │                                         │
          ▼                                         │
  ┌───────────────┐                                │
  │ 3. WRITE      │  Copy the output image table    │
  │   OUTPUTS     │  (PIO) to the physical output   │
  │ (output image)│  terminals all at once.         │
  └───────┬───────┘                                 │
          │                                         │
          ▼                                         │
  ┌───────────────┐                                │
  │ 4. HOUSEKEEP  │  Comms, diagnostics, watchdog,  │
  │  (overhead)   │  I/O updates, online edits.     │
  └───────┬───────┘                                 │
          └─────────────────────────────────────────┘
            one full loop = one SCAN (typ. 1-20 ms)

The input/output image: why it exists

The crucial subtlety: the program does not read the physical input pins while it executes. At the top of the scan it takes a single snapshot of all inputs into a memory image (Siemens: the Process Image Input, PII; Rockwell: input tags). Throughout the program solve, every reference to an input reads that frozen snapshot. Outputs are written to a memory image and pushed to the terminals all at once at the end.

This gives you consistency: an input cannot change value halfway through your logic and make a rung true at the top and false at the bottom of the same scan. The whole program sees one coherent picture of the world per scan. It also has a consequence new engineers get bitten by: if a fast pulse arrives and disappears between two input reads, the PLC never sees it. For pulses shorter than the scan time you need a hardware latch, a high-speed counter input, or an interrupt OB.

The worst-case reaction time (do this arithmetic before you promise anything)

Here is where most engineers get burned: they quote a machine's reaction time as "one scan" and forget that the scan model doubles it in the worst case. An input that changes state one microsecond after the input snapshot won't be seen until the next scan reads it, then acts on it, then writes the output at the end of that scan. The full worst-case end-to-end reaction time is a sum of independent delays:

t_react(worst) = t_input_filter + T_scan(input latency)
               + T_scan(logic+output)
               + t_output_switch
             ≈ t_filter + 2·T_scan + t_out

Two scan periods, not one, because the event has to first survive to a snapshot, then survive a solve. Add the physical layers most people forget: the digital input's hardware debounce/anti-noise filter (often 0.1 to 3 ms, and configurable; factory-default 3 ms filters have quietly wrecked many high-speed-count applications), the output device's switching delay (a mechanical relay output is 5 to 10 ms of contact bounce; a transistor output is microseconds), and, if the I/O is remote, the fieldbus update period on top. A "10 ms PLC" driving relay outputs through default input filters can easily present a 25 to 30 ms real-world reaction. The controller was never the slow part.

For remote I/O the network adds its own term, so the honest budget is:

t_react = t_filter + 2·T_scan + n_hops·t_fieldbus_cycle + t_out

This same worst-case arithmetic reappears, with certified pessimism, when we compute a safety function's response time later: the light curtain's stopping distance is literally this number multiplied by the hazard's approach speed.

Scan time, and why determinism is the product

Scan time is how long one full loop takes. Typical values:

• Small machine PLC (S7-1200, CompactLogix): 2 to 10 ms
• Mid/large PLC (S7-1500, ControlLogix): 0.5 to 5 ms for the logic, plus comms
• Fast/IPC (TwinCAT, CODESYS on a fast CPU): a real-time task at 1 ms, 500 µs, 250 µs, or down to motion-grade cycles

The number itself matters less than its bound and stability. A watchdog faults the CPU if any scan exceeds the configured maximum (e.g. 100 ms), forcing the system to a safe state rather than silently lagging. Modern controllers also run periodic/time-interrupt tasks (e.g. a 1 ms PID task) and event tasks alongside the main scan, so time-critical loops get a guaranteed slot independent of the housekeeping in the main program.

Rule of thumb: your scan time must be comfortably shorter than the fastest event you must catch. Formally it is a sampling problem: a Nyquist argument for logic. A detection window of duration t_visible = w / v (a sensor "seeing" width w over a part moving at speed v) is only reliably caught when T_scan ≤ t_visible / 2, and comfortably caught at T_scan ≤ t_visible / 5. To detect a part on a 0.3 m/s conveyor with a sensor visible for 30 mm, t_visible = 0.03 / 0.3 = 100 ms; a 10 ms scan catches it ten times over. Speed the line to 3 m/s and that window collapses to 10 ms; now the scan is marginal and you move the detection to a latching high-speed input. To catch a 5 ms pulse, don't use the normal scan at all.

War story: A palletizer that ran flawlessly for a year started dropping counts after the line was sped up for a new SKU. The logic was untouched; the maintenance team chased "flaky sensors" for a week. The real culprit was the sampling inequality above quietly flipping sign: the faster line shortened t_visible below 2·T_scan, so the photoeye pulse occasionally landed entirely between two input snapshots and vanished. The fix was one dropdown (reassign the sensor to a high-speed counter input), plus a lesson that "we didn't change the program" is not the same as "nothing changed."

This is the answer to "isn't a PLC slow?" A 10 ms scan is glacial by CPU standards and irrelevant by machine standards: it's the guarantee that you get a complete, consistent logic solve every 10 ms without fail that you're paying for.

The IEC 61131-3 languages

IEC 61131-3 is the standard that defines the PLC programming languages. Every serious platform implements some or all of it, which is why a controls engineer can move between brands without relearning to program from scratch: the languages are portable even when the IDEs and the I/O addressing are not.

There are five languages: three graphical (LD, FBD, SFC), one textual (ST), and one textual-and-deprecated (IL). The standard also defines the data types, the POU (Program Organization Unit) concept (programs, function blocks, and functions), and crucially the function block with internal state, which is how you build reusable, instance-based logic.

Language	Type	Looks like	Best for	Avoid for
LD: Ladder Diagram	Graphical	Relay schematic (rungs, contacts, coils)	Discrete/boolean logic, interlocks, maintenance-friendly machines	Math, loops, string handling, complex state
FBD: Function Block Diagram	Graphical	Signal-flow blocks wired together	Process/analog, PID loops, signal processing, "data flow" thinking	Dense sequential logic, branching
ST: Structured Text	Textual	Pascal / structured C	Math, algorithms, state machines, loops, anything you'd write in code	Code maintained by non-programmer electricians
SFC: Sequential Function Chart	Graphical	Flowchart of steps + transitions	Sequential processes, batch, machine state sequencing	Continuous logic, fast scanning of all states
IL: Instruction List	Textual	Assembly / mnemonics	(Legacy only, deprecated in IEC 61131-3 3rd ed.)	New development. Don't.

When you use each

Ladder (LD) is still the default for discrete logic in North America and in any plant where maintenance techs, not software engineers, own the troubleshooting. Its superpower is visual fault-finding: stand at the HMI, open the rung that drives the stuck output, and the live-highlighted contacts show you exactly which condition isn't met. Its weakness is that anything with arithmetic or iteration becomes an unreadable mess of move and compute blocks.

Structured Text (ST) is what experienced engineers reach for the moment there's math, a loop, a CASE state machine, or string handling. It's compact, version-controls cleanly (it's text!), and reads like real code. The tradeoff is maintainability culture: in a plant where the night-shift electrician fixes faults, a wall of ST is opaque to them. Pick the language to match who maintains it, above what's merely elegant.

FBD shines in process and motion where you're wiring named blocks (a PID, a scale, a filter) into a signal chain. SFC is the right tool for an inherently sequential process (fill, heat, hold, drain, clean) where each step has entry actions and a transition condition to the next. Many real programs mix all of them: SFC for the sequence, ST inside the steps, ladder for the safety interlocks and manual overrides.

A Structured Text example

A debounced start/stop with a retentive run latch and a fault interlock, the kind of thing you write a hundred times:

FUNCTION_BLOCK FB_MotorControl
VAR_INPUT
    StartPB    : BOOL;          // momentary start pushbutton
    StopPB     : BOOL;          // momentary stop (NC wired, so TRUE = OK)
    Fault      : BOOL;          // TRUE = fault present
    AutoMode   : BOOL;
END_VAR
VAR_OUTPUT
    RunCmd     : BOOL;          // to the contactor / VFD run bit
END_VAR
VAR
    debounceT  : TON;           // IEC standard on-delay timer
END_VAR

// Debounce the start request by 50 ms
debounceT(IN := StartPB, PT := T#50ms);

// Seal-in (latch) logic: start, then hold, unless stopped or faulted
IF debounceT.Q AND StopPB AND NOT Fault AND AutoMode THEN
    RunCmd := TRUE;
ELSIF NOT StopPB OR Fault OR NOT AutoMode THEN
    RunCmd := FALSE;   // stop, fault, or mode loss drops the motor
END_IF;

Note TON, the IEC standard on-delay timer function block. The standard library (TON, TOF, TP, CTU, CTD, R_TRIG, F_TRIG) is the same set of primitives on every compliant platform, even if the vendors dress them up differently.

The same logic as a ladder rung

The classic three-wire motor seal-in, in ASCII ladder. Start is an N.O. pushbutton, Stop is wired normally-closed (so the contact is held closed when everything's healthy), Motor is the output coil, and the Motor contact across Start is the seal-in that holds the rung after you release the button:

    Start      Stop       Fault            Motor
  ───┤ ├──┬────┤/├────────┤/├──────────────( )───
          │
    Motor │
  ───┤ ├──┘   (seal-in / latch around Start)

Read it left to right as power flow: energize Motor when (Start OR already-running Motor) AND Stop-is-healthy AND no Fault. That single rung is the most-written piece of logic in the history of manufacturing, and the fact that it reads like the relay panel it replaced is exactly why ladder won and never left.

PLC hardware & the vendors

A PLC system is modular. The pieces:

The anatomy

• CPU / processor module: runs the scan, holds the program and data memory, hosts the communication ports. Memory ranges from tens of KB on a micro-PLC to tens of MB on a ControlLogix or S7-1500.
• Power supply: usually a separate module providing backplane and 24 VDC logic power.
• Rack / backplane / chassis: the bus the modules plug into. ControlLogix uses a parallel backplane; many modern systems use a backplane bus that's electrically a fieldbus (the S7-1500 uses a fast internal bus).
• Digital I/O modules: discrete inputs (24 VDC sinking/sourcing, 120 VAC) and outputs (transistor for fast/DC loads, relay for flexible/AC loads, typically 0.5 to 2 A per point). Densities of 8, 16, or 32 points per module.
• Analog I/O modules: inputs for 4 to 20 mA, 0 to 10 V, RTD, thermocouple; outputs for 4 to 20 mA / 0 to 10 V. Resolution 12 to 16 bit. This is where process control lives.
• Specialty modules: high-speed counters, motion/axis modules, weigh scales, communication modules (e.g. a PROFIBUS or serial gateway).
• Remote I/O: racks of I/O sitting out near the machine, connected back to the CPU over a fieldbus (PROFINET, EtherNet/IP, EtherCAT). This is how you avoid running 200 sensor wires back to a central cabinet: you put a small I/O block near the sensors and run one network cable.
• Safety PLC / safety I/O: a certified processor and dual-channel safety I/O for the safety function, covered in its own section below.

The vendor landscape

Vendor	Flagship hardware	Software / IDE	Native fieldbus	Where it dominates
Siemens	S7-1200 (compact), S7-1500 (performance)	TIA Portal (STEP 7, WinCC)	PROFINET, PROFIBUS	Europe, process, OEM machinery, broad
Rockwell / Allen-Bradley	CompactLogix, ControlLogix, Micro800	Studio 5000 (Logix Designer)	EtherNet/IP, DeviceNet	North America, automotive, discrete
Beckhoff	PC-based controllers (CX series), EtherCAT terminals	TwinCAT 3 (Visual Studio-based)	EtherCAT	Motion, high axis count, PC-control, OEM
Mitsubishi Electric	MELSEC iQ-R, iQ-F	GX Works3	CC-Link IE, CC-Link	Asia, semiconductor, high-speed machinery
Omron	NX/NJ series (Sysmac)	Sysmac Studio	EtherCAT, EtherNet/IP	Asia, packaging, vision-integrated machines
CODESYS (runtime, many OEMs)	Runs on 3rd-party hardware (WAGO, Schneider, Festo, etc.)	CODESYS Development System	EtherCAT, PROFINET, EtherNet/IP, Modbus	The "everyone else" runtime; OEM controllers
Schneider Electric	Modicon M580, M340	EcoStruxure / Control Expert	Modbus TCP, EtherNet/IP	Process, infrastructure, the Modbus originator

A few opinions worth stating plainly:

• Siemens vs Rockwell comes down mostly to geography and brand lock-in. Both are excellent. TIA Portal is a single integrated environment that some love and some find heavy; Studio 5000 has the cleanest tag-based data model in the business (you reference Conveyor1.Motor.Run, not %Q0.3). Pick the one your plant standardizes on: mixing them doubles your spare-parts inventory and your engineers' training.
• Beckhoff is the engineer's PLC. PC-based, EtherCAT-native, programmed in TwinCAT 3 inside Visual Studio with full IEC 61131-3 plus C++ and Matlab/Simulink integration. If you have a lot of axes or want to do real computation on the controller, this is the platform. The tradeoff is it feels more like software engineering and less like plant maintenance.
• CODESYS is the hidden giant. A huge fraction of non-big-three controllers (WAGO, Festo, many drives and OEM boxes) run the CODESYS runtime under the hood. Learn CODESYS and you can program a startling range of "other" hardware.

Fieldbus & industrial Ethernet: the war

A fieldbus is the digital network that connects the controller to field devices (I/O, drives, sensors, robots), replacing the bundle of point-to-point wires that used to run back to the cabinet. The history is a religious war; the present is a regional détente.

The legacy generation (still everywhere)

• PROFIBUS DP: Siemens-world serial fieldbus, RS-485, up to 12 Mbit/s. Decades of installed base in Europe. Still runs millions of devices; new installs are rare but you'll maintain it for years.
• DeviceNet: Rockwell-world, CAN-based. The North American counterpart to PROFIBUS for device-level networking.
• Modbus RTU: Modicon's 1979 serial protocol over RS-485/232. Dead simple, register-based, royalty-free, and immortal because of it.
• Also: ControlNet, CC-Link, AS-i (sensor-level), HART (smart 4 to 20 mA).

The industrial-Ethernet generation (the present)

Plain Ethernet isn't deterministic, and it's worth being precise about why, because each industrial protocol is an answer to a specific one of its sins. Original shared-medium Ethernet used CSMA/CD, where two nodes transmitting at once collide, back off a random interval, and retry, random by design, so worst-case delivery time is formally unbounded. Modern switched full-duplex Ethernet kills collisions, but replaces them with queuing latency: when two frames arrive at a switch port destined for the same egress, one waits in a buffer behind the other, and under load those buffers grow without a hard ceiling (the same head-of-line blocking that gives your home network its jitter). TCP makes it worse with retransmission and Nagle batching. The industrial-Ethernet protocols each eliminate one of these: scheduling the medium (PROFINET IRT, POWERLINK), processing in transit so nothing ever queues (EtherCAT), or, in the newest generation, standardizing the switch behavior itself with TSN (Time-Sensitive Networking, the IEEE 802.1 family) so time-critical and best-effort traffic can finally share one wire with a bounded latency guarantee. The whole standards stack lives under IEC 61158 / IEC 61784 (the fieldbus and real-time-Ethernet profile specs); the incompatibility is deliberate: several vendors each patenting a different escape from the same queuing problem.

Protocol	Backed by	Real-time mechanism	Typical cycle	Best at
PROFINET	Siemens / PI	RT (prioritized) and IRT (scheduled, hardware-timed)	RT ~1-10 ms; IRT ≤1 ms	Discrete automation, Siemens plants, Europe
EtherNet/IP	Rockwell / ODVA	CIP over standard Ethernet; CIP Sync/Motion for time	~1-10 ms; motion <1 ms	Discrete automation, Rockwell plants, N. America
EtherCAT	Beckhoff / ETG	"Processing on the fly" + distributed clocks	31.25 µs - 250 µs	Motion, servo, high axis count
Modbus TCP	Open / Schneider	None (best-effort TCP)	10-100 ms	Simple, cheap, universal interop
CC-Link IE	Mitsubishi / CLPA	Gigabit token / TSN	<1 ms	Asia, semiconductor, high-speed
POWERLINK	B&R / EPSG	Polled, slotted time	<1 ms	Motion (B&R world), declining

How to actually choose

You usually don't choose; the plant chooses for you. The driving question is: what does the existing line speak? A Siemens plant is PROFINET top to bottom; bring an EtherNet/IP device and you're adding a gateway and a headache. A Rockwell automotive plant is EtherNet/IP; the same logic applies in reverse.

If you're a robotics integrator dropping a cell into a brownfield line, the cell's "uplink" fieldbus to the plant PLC is dictated by the plant. Inside your cell you can run whatever you like: many robot cells run EtherCAT internally for the drives and expose a PROFINET or EtherNet/IP interface to the plant. The robot becomes a translator at the boundary.

And Modbus TCP is the universal fallback for the same reason it never dies: it's free, trivially simple (read/write 16-bit registers and coils), and everything speaks it. When you need a cheap sensor, a power meter, or a third-party box to hand a few values to the PLC and you don't care about determinism, Modbus is the path of least resistance. For deeper treatment of how these protocols achieve determinism, see the real-time control systems guide.

EtherCAT & motion

EtherCAT (Ethernet for Control Automation Technology, Beckhoff/ETG) deserves its own section because it won the motion war outright, and motion is where robotics lives.

Why EtherCAT is fast: processing on the fly

Conventional Ethernet sends a separate frame to each node and waits for replies: overhead per device kills you when you have 50 servo drives. EtherCAT does something clever: one frame passes through every node in the network, and each node reads its piece of data out of the frame and writes its piece back as the frame goes by, in hardware, on the fly. The frame is processed in transit, nanoseconds of delay per node, and returns to the master with everyone's data updated.

The result: a single Ethernet frame can service hundreds of axes, and the whole network updates in one shot. Effective data rates approach the wire limit because there's almost no protocol overhead per node. This is why network cycle times of 31.25 µs, 62.5 µs, 125 µs, or 250 µs are normal, fast enough to close position loops over the network.

The efficiency is worth quantifying, because it's the whole argument. On classic switched Ethernet, exchanging a few process-data bytes with N drives costs you N separate frames, each dragging the full Ethernet tax (14-byte MAC header, 4-byte CRC, plus the 8-byte preamble and 12-byte inter-frame gap on the wire), call it ~38 bytes of overhead to carry maybe 8 bytes of payload. Bus utilization scales like:

η_switched ≈ payload / (payload + overhead) ≈ 8 / (8 + 38) ≈ 17%

EtherCAT instead packs every node's process data into one frame as consecutive datagrams, so the fixed Ethernet tax is paid once for the whole network rather than once per node:

η_ethercat ≈ Σ payload_i / (Σ payload_i + overhead_frame) → 80-95%

That 5 to 6× improvement in wire efficiency is exactly what converts "one frame per drive, tens of microseconds of latency each" into "one frame for the whole ring, tens of microseconds total." The ETG's published figure (1000 distributed digital I/O in ~30 µs, or 100 servo axes in ~100 µs) falls straight out of this arithmetic.

Distributed clocks: the synchronization that matters for robots

The other half of EtherCAT's motion dominance is Distributed Clocks (DC). Every node has a local clock, and the protocol synchronizes them all to a reference (usually the first DC-capable slave) with jitter typically < 1 µs, often < 100 ns. That means every servo drive across a six-axis arm samples its command and applies its torque at the same instant.

For coordinated motion (a robot arm tracing a straight line, a CNC interpolating an arc, a gantry where two motors must move in lockstep), synchronization jitter directly becomes path error. The relationship is embarrassingly direct: if two axes that should act simultaneously actually fire Δt apart while the tool moves at velocity v, the geometric error is

ε_path ≈ v · Δt_jitter

Run the numbers. A conventional soft-synchronized bus with ~100 µs of timing jitter, on a tool moving 1 m/s, smears the path by 1 m/s × 100 µs = 100 µm, visible as chatter or a stepped contour. EtherCAT distributed clocks pin Δt below 100 ns, dropping the same error to 1 m/s × 100 ns = 0.1 µm, a hundredth of a micron, comfortably below the encoder resolution and mechanical repeatability of the machine. Sub-microsecond sync is the term that makes coordinated multi-axis motion smooth instead of stepped. The clock discipline itself is a first-order feedback loop (each slave's local timer is corrected toward the reference by a controller measuring propagation delay round-trip), the same PI-regulation idea IEEE 1588 (PTP) uses; the two are essentially contemporaneous (PTP v1 in 2002, EtherCAT DC in 2003) and share the same control-loop principle.

The link to robot drives

This is why so many modern robot controllers, CNCs, and high-end motion systems use EtherCAT internally as the drive bus: the controller runs a fast cyclic task (say 250 µs or 1 ms), and on each cycle it ships new position/velocity/torque setpoints to every drive and reads back every encoder, all synchronized. The drives themselves run their fast FOC current loops locally (see the motor controllers & FOC guide) while EtherCAT carries the coordinated position/velocity layer. The standard application profile for this is CoE (CANopen over EtherCAT) with the CiA 402 drive profile (the same device profile used over CANopen and EtherCAT), giving a portable state machine and object dictionary for servo drives across vendors.

OPC UA & the IT/OT bridge

Everything above is about control: moving bits deterministically. OPC UA (Open Platform Communications Unified Architecture, IEC 62541) is about data: getting information out of the control layer to the systems that analyze, schedule, and report on it, securely and without a proprietary driver per device.

What it actually is

OPC UA is a vendor-neutral, platform-independent, secure machine-to-machine communication standard. Three things make it the modern default:

• Information modeling. OPC UA carries a typed, structured, self-describing model rather than a bare tag value. A node has a data type, engineering units, an address-space hierarchy, and metadata. Industry groups define Companion Specifications, standardized models for robotics (the OPC UA Robotics companion spec), CNC (umati), injection molding (Euromap), and more, so a robot from any vendor exposes the same standardized information model. That's the dream IT always wanted: self-describing devices.
• Security built in. Encryption (TLS), authentication (certificates, user tokens), and signing are built into the spec. This is what makes it acceptable to run across the IT/OT boundary.
• Two transports. Classic client/server (request/response, browse the address space, subscribe to changes) for SCADA-to-PLC and HMI-to-device. And pub/sub for one-to-many, low-latency, broadcast-style data, often over MQTT for cloud/IT integration or over UDP for fast local distribution.

MQTT and Sparkplug B

For Industry 4.0 / IIoT, the pattern that's winning is MQTT with the Sparkplug B specification. MQTT is a lightweight publish/subscribe broker protocol (devices publish to topics, subscribers receive); Sparkplug B layers on a standardized topic namespace, payload encoding, and crucially a state-management / birth-death model so a consumer always knows whether a device is alive and what its full tag set is. It's report-by-exception and bandwidth-thrifty, which is why it dominates cellular/remote and cloud telemetry. Ignition's MQTT modules made this combination mainstream.

Practical rule: use OPC UA client/server inside the plant for SCADA and engineering tools talking to PLCs; use MQTT/Sparkplug B (often carrying OPC UA payloads) to push data up and out to MES, historians, and the cloud. They complement each other.

For a robotics engineer, OPC UA is how you expose cell data (cycle counts, quality results, fault codes, vision inspection data) to the plant's MES and dashboards without writing a custom integration for every customer's SCADA.

SCADA & HMI

SCADA (Supervisory Control And Data Acquisition) is the Level 2 software layer that lets humans supervise (not directly control in real time) a plant. HMI (Human-Machine Interface) is the operator-facing screen; a standalone HMI is usually a local panel on a machine, while SCADA is plant-wide software running on servers and PCs. The line blurs (an HMI panel runs SCADA-like software), but the hierarchy is real: PLCs do the control, SCADA watches and lets people intervene.

The core concepts

• Tags. A SCADA system is organized around tags: named data points (Line1.Filler.Speed, Tank3.Level) that map to PLC addresses or OPC UA nodes. Everything (displays, alarms, trends) references tags.
• Historian. A time-series database that logs tag values over time. This is where OEE, root-cause analysis, and "what was the tank temperature at 3 AM last Tuesday" come from. Historians compress aggressively (swinging-door / deadband) because they store millions of points.
• Alarms. Configured conditions (tag out of range, equipment fault) with priority, acknowledgment, and logging. Good alarm design (per ISA-18.2 / EEMUA 191) is its own discipline; alarm floods are a classic SCADA failure mode.
• Trends. Real-time and historical charting of tag values. The operator's window into process behavior.
• Recipes / parameters. Stored sets of setpoints for different products, downloaded to the PLC on a product changeover.

The products

• Ignition (Inductive Automation): the modern favorite. Server-based, web-deployed (Perspective for browser/mobile, Vision for desktop), unlimited-tag licensing (you pay per server, not per tag, a genuinely disruptive model), Python scripting, native MQTT/Sparkplug and OPC UA. If you're starting greenfield, this is the one most independent integrators reach for.
• Siemens WinCC (and WinCC Unified): the Siemens-world SCADA/HMI, tightly integrated with TIA Portal and S7 PLCs. The default in a Siemens plant.
• Rockwell FactoryTalk View (SE for SCADA, ME for machine-level HMI): the Rockwell-world counterpart, integrated with Logix and FactoryTalk Linx.
• AVEVA (Wonderware) System Platform, GE iFIX/Proficy: long-established platforms, big in process and brownfield.

What SCADA does NOT do

SCADA is not hard real-time. It polls or subscribes to PLC tags every few hundred milliseconds to a second; a hiccup in the SCADA server, the network, or the Windows box it runs on must never affect the machine. The interlocks, the e-stop logic, the closed loops: those live in the PLC and the safety system, by design, precisely so that SCADA can crash and the machine still fails safe. A robotics engineer who puts a safety-relevant decision in SCADA has made a serious architectural mistake.

Integrating robots with PLCs

This is the section robotics engineers came for. In a production cell, how does the robot talk to the PLC, and who's in charge?

The robot as a fieldbus device

Almost universally, the robot controller is configured as a fieldbus adapter/slave to the PLC's scanner/master: a PROFINET IO-Device or an EtherNet/IP Adapter (or a PROFIBUS slave / DeviceNet node in older cells). The PLC sees the robot as a block of I/O: a handful of bytes in each direction, exchanged every scan.

Robot vendors ship exactly this. FANUC has PROFINET and EtherNet/IP option boards; ABB, KUKA, Yaskawa, and Universal Robots all expose fieldbus interfaces. You configure the robot's I/O map (a GSDML file for PROFINET, an EDS for EtherNet/IP) into the PLC project, and now PLC bits map to robot signals. See the industrial robot arms and cobots guides for the arm side of this.

A typical handshake

The data exchanged is deliberately minimal: a compact command/status protocol. The PLC doesn't tell the robot how to move; it tells the robot which taught program to run and when to go. A common interface:

  PLC ──► Robot (command word + bits)        Robot ──► PLC (status word + bits)
  ─────────────────────────────────────      ──────────────────────────────────
  ProgramSelect : INT  (which routine)        RobotReady   : BOOL
  CycleStart    : BOOL                        ProgramRunning: BOOL
  Hold/Pause    : BOOL                        ProgramDone  : BOOL  (cycle complete)
  Reset/Ack     : BOOL                        AtHome       : BOOL
  EnableMotion  : BOOL                        Fault        : BOOL
  PartPresent   : BOOL                        FaultCode    : INT
  GripperState  : BOOL                        InPosition   : BOOL

The PLC sequence is roughly: confirm RobotReady and AtHome → set ProgramSelect → pulse CycleStart → wait for ProgramRunning → wait for ProgramDone → read result → repeat. It's a classic master/slave handshake, and getting the edge-triggering right (don't latch CycleStart high forever) is where the bugs live.

The take: Treat the handshake as an explicit state machine with a timeout on every wait. The failure that eats a shift lives in the race window where the robot latches ProgramDone for one cycle and the PLC's scan, running asynchronously to the robot controller's own cycle, misses the pulse. Because the two controllers are free-running clocks, any single-scan status bit is a lost-pulse waiting to happen (the exact same sampling problem as the conveyor sensor, one abstraction layer up). The professional fix is a fully interlocked, level-based handshake: the robot holds ProgramDone true until it sees the PLC's Reset/Ack go true, and only then drops it, so no edge can fall between two scans. Every state also gets a watchdog timer, so a robot that dies mid-cycle faults the cell in seconds instead of hanging the line until someone notices.

Who's the master?

The PLC is the cell master. The robot is a very capable peripheral. The PLC sequences the cell (index the conveyor, clamp the fixture, tell the robot to run program 7, wait for done, unclamp, index) and the robot executes its self-contained motion programs on command.

There are exceptions. A standalone robot work cell programmed entirely on the teach pendant may have the robot orchestrate simple I/O directly with no separate PLC. And in tightly coupled motion (robot tracking a moving conveyor with vision), the data exchange gets richer (frame offsets, coordinate transforms), but the architecture is the same: PLC coordinates the line, robot owns the motion. For mobile robots feeding a cell, the AMR/AGV guide covers the fleet-manager-to-PLC handshake, which is the same pattern one level up.

Don't forget the safety handshake

Standard fieldbus I/O is not safety. The robot's safety-rated stop, the cell's e-stop, the light-curtain mute, the safe-zone monitoring: those travel on a safety fieldbus (PROFIsafe, CIP Safety) or hardwired safety circuit, in parallel with the standard command/status I/O. This is the part that's most often left until last and most often blows the schedule. It's important enough to get its own section.

Functional safety

Functional safety is a certified, parallel control architecture whose job is to bring the machine to a safe state when something goes wrong, with a quantified, proven reliability. It is governed by standards, validated by risk assessment, and, critically for integrators, it's a legal requirement. For the robot-cell-specific safety story (safe zones, speed-and-separation, power-and-force limiting) see the cobots guide.

The standards and the ratings

Two parallel rating systems you must know:

• ISO 13849-1 uses Performance Level (PL), from PLa (lowest) to PLe (highest), derived from architecture (Category B, 1, 2, 3, 4), MTTFd (mean time to dangerous failure), DC (diagnostic coverage), and CCF (common-cause failure). Most machine guarding targets PLd, Category 3 (single fault tolerant); high-risk functions target PLe, Category 4.
• IEC 62061 / IEC 61508 uses SIL (Safety Integrity Level), SIL 1 (lowest) to SIL 3/4 (highest), defined by the average probability of a dangerous failure per hour (PFHd). The bands are decade-wide reliability targets baked into the standard:

Level	PL (ISO 13849)	PFHd band (per hour)	Interpretation
SIL 1	PLb / PLc	1e−6 ≤ PFHd < 1e−5	~1 dangerous failure per 100k+ hours
SIL 2	PLd	1e−7 ≤ PFHd < 1e−6	single-fault tolerant guarding
SIL 3	PLe	1e−8 ≤ PFHd < 1e−7	~1 per 10M-100M hours

So SIL 2 ≈ PLd and SIL 3 ≈ PLe rests on these overlapping numeric bands. The subtlety that catches people: PFHd is a property of the whole safety function (sensor + logic + actuator in series), so the channel is only as good as its worst reliability term summed across the chain, and adding an unmonitored contactor at the output can quietly drag a PLe architecture down to PLc.

You select the required PLr/SIL from a risk assessment (ISO 12100): severity of injury × frequency of exposure × possibility of avoidance gives you the target, and your safety design must meet or exceed it. Industrial robots fall under ISO 10218-1/-2; collaborative operation under ISO/TS 15066 (folded into the 2025 revision of ISO 10218).

The safety PLC

A safety PLC (Siemens S7-1500F, Rockwell GuardLogix, Pilz PNOZmulti, Beckhoff TwinSAFE) is a certified controller that runs the safety logic with internal redundancy and self-diagnostics: dual processors comparing results, output testing, the works. You program it in a restricted, certified subset of the languages with certified safety function blocks (emergency stop, guard monitoring, two-hand control, safe speed). It typically lives in the same CPU or rack as the standard PLC but runs the safety program in a protected, certified context.

Safety fieldbuses and the black channel

The clever modern trick: safety data rides the same network wire as standard I/O, using a safety protocol layered on top: PROFIsafe over PROFINET/PROFIBUS, CIP Safety over EtherNet/IP, FSoE (Fail Safe over EtherCAT) over EtherCAT, the family standardized under IEC 61784-3 (the functional-safety companion to the IEC 61158/61784 fieldbus specs). The underlying network is treated as an untrusted "black channel"; the safety layer adds sequence numbers, timeouts, CRCs, and a unique connection ID so that any corruption, delay, loss, or misrouting of a safety frame is detected and forces a safe state.

The elegance is that the safety layer makes no assumption whatsoever about the transport: it will run over the same switch, the same cable, even the same corrupt Wi-Fi, because it is designed to detect every credible failure mode of an arbitrary channel: a message that is corrupted (caught by the CRC), delayed (caught by the watchdog timeout), lost, repeated, inserted, or delivered out of order (caught by the running sequence number), or delivered to the wrong node (caught by the unique connection ID). This is a small formal miracle (you get a provably SIL 3 channel over an unproven network), and it is what lets you run one cable instead of two.

Safety response time: the number the light curtain actually cares about

A functional-safety function has its own worst-case reaction time, and it is the earlier scan arithmetic wearing a certified, pessimistic hat. The total safety function response time (SFRT) is the sum of every stage's worst case:

SFRT ≈ t_sensor + t_input + 2·T_safety_scan + t_watchdog(F-comms) + t_output + t_actuator

Note the t_watchdog term: safety-over-network standards budget the full communication timeout (typically 2 to 3× the F-cycle) into the response time, because a message that is merely late is treated as lost. Then the physics closes the loop. For a light curtain guarding a hazard, the minimum mounting distance follows the classic formula in ISO 13855:

S = K · T + C

where S is the separation distance, K is the approach speed (the standard uses 2000 mm/s for a hand/arm), T is the total system stopping time (sensor + SFRT + the machine's own mechanical run-down), and C is an intrusion allowance for reaching through/over the field. Every millisecond you shave off SFRT buys back K·Δt of floor space: at 2000 mm/s, cutting 10 ms of response time lets the curtain sit 20 mm closer to the pinch point, which on a tight cell is the difference between fitting the guard and re-quoting the layout. This single equation is why safety-rated I/O and fast F-scans are worth paying for, and why "we'll speed it up later" is not a plan you can keep.

E-stop architecture, in practice

A minimal robot-cell safety architecture:

• Dual-channel e-stop circuit (Category 3+): two redundant normally-closed contacts, monitored, so a single welded contact or broken wire is detected.
• Interlocked guards (gates with safety switches) that command a safe stop when opened, plus light curtains / safety scanners for access points that can't be physically gated.
• Safe stop categories (IEC 60204-1): Stop Category 0 (immediate power removal, uncontrolled), Category 1 (controlled deceleration then power removal), Category 2 (controlled stop, power maintained). Robots increasingly use safe drive functions: STO (Safe Torque Off), SS1/SS2 (Safe Stop 1/2), SLS (Safely-Limited Speed) per IEC 61800-5-2, so the robot can stop safely without dumping all power and losing position.
• A safety handshake to the robot: the cell safety PLC commands the robot's safety-rated inputs (safe stop, reduced-speed mode for collaborative operation), and the robot reports its safety status back. Speed-and-separation monitoring lets the robot run fast when the human is far and slow or stop when they're close.

Design the safety architecture first, from the risk assessment, and let the productivity design fit around it. The single most expensive mistake in cell integration is bolting safety on at the end and discovering the cell can't legally run at the throughput the customer was quoted.

Industrial cybersecurity & the modern stack

For most of their history, OT networks were secure by being isolated: air-gapped, proprietary, and obscure. That's gone. Industry 4.0, OPC UA bridges, remote access, and cloud analytics have connected the plant floor to everything, and the attacks (Stuxnet, Triton/Trisis, Colonial Pipeline's IT spilling into OT shutdown, repeated ransomware) have made OT security board-level.

IEC 62443: the framework

IEC 62443 is the standard for industrial automation and control system (IACS) security. Its core ideas:

• Zones and conduits. Segment the network into security zones (cell, line, plant, DMZ) with controlled conduits (firewalled, monitored connections) between them. A compromised HMI in one cell should not reach the PLC in another.
• Defense in depth. No single control is trusted; layer firewalls, segmentation, authentication, monitoring, and physical security.
• Security Levels (SL 1 to 4) assigned per zone based on the threat (casual, intentional-with-simple-means, intentional-with-sophisticated-means, nation-state).
• Roles: requirements for the asset owner, the system integrator, and the product supplier; security is a shared responsibility across the lifecycle.

The practical OT security baseline

What actually shows up in a competent plant:

• A purpose-built OT DMZ between the IT network and the control network: the historian, the patch server, and the OPC UA aggregation server live here, so nothing on the corporate LAN talks directly to a PLC.
• Segmentation down to the cell level, often with industrial firewalls (Cisco IE, Fortinet, Hirschmann, Moxa) at the conduits.
• Hardened remote access: no flat VPN into the PLC network; jump hosts, MFA, session recording, time-boxed access for vendor support.
• Signed firmware and secure boot on newer controllers; integrity verification so a tampered firmware image won't load.
• OT-aware monitoring / IDS (Claroty, Nozomi, Dragos) that understands industrial protocols and flags an unexpected PLC program download or a rogue device.
• Asset inventory: you can't protect what you don't know is there. This is the unglamorous foundation.

The modern stack: soft PLCs, containers, and the edge

The biggest architectural shift in years is software PLCs: the control runtime decoupled from proprietary hardware, running as software on industrial PCs or even in containers (Docker/Kubernetes) at the edge. Siemens, Rockwell, CODESYS, and Beckhoff all ship virtualizable/containerized control runtimes now. The appeal is huge: DevOps-style deployment, version control, redundancy by spinning up a replica, and converging the IT and OT toolchains.

The danger is equally huge: a containerized PLC inherits the entire attack surface and patch cadence of the platform it runs on, and the determinism that made the PLC trustworthy now depends on a real-time kernel and resource isolation done correctly. Edge compute (running analytics, ML inference, and OPC UA aggregation next to the line) sits in the same uncomfortable space: powerful, and a new front door.

The honest summary for 2026: the PLC is becoming software, the network is becoming standard Ethernet with TSN and security layered on, and the bridge to IT is becoming OPC UA over MQTT. All three trends make the plant more capable and more connected, which is to say, the determinism and isolation that used to be free now have to be engineered and defended on purpose. For robotics integrators, that means cybersecurity is no longer the customer's problem you can ignore; it's part of the cell you ship.

Frequently asked questions

What's the difference between a PLC and a microcontroller (or a Raspberry Pi)? A microcontroller or Pi is a general-purpose computer; a PLC is a ruggedized, deterministic controller with a guaranteed scan cycle, isolated industrial I/O, a watchdog, a 10 to 20 year support lifecycle, and IEC 61131-3 programming that a plant electrician can troubleshoot. You can control a machine with a Pi, and people do for prototypes and light-duty jobs, but it won't survive the temperature, vibration, electrical noise, and longevity demands of a real production line, and it has no certified safety story. The PLC's value is the guarantee it makes.

Why is the scan cycle so important? Because it's what makes a PLC deterministic. The CPU reads all inputs into a snapshot, solves the entire program against that consistent snapshot, then writes all outputs at once, every cycle, within a bounded time enforced by a watchdog. That bound-and-consistency is the product. It also has a trap: a pulse shorter than the scan time can be missed entirely, so fast events need high-speed inputs or interrupt tasks rather than normal scanned logic.

Should I program in ladder or structured text? Match the language to who maintains the code and what the logic does. Ladder for discrete/boolean interlocks in plants where maintenance techs do the troubleshooting: it reads like the relay schematic and live-highlights faults beautifully. Structured Text for anything with math, loops, or state machines, and where the maintainers are comfortable with code. Most real programs mix them: SFC or ladder for the sequence and interlocks, ST for the algorithms.

PROFINET or EtherNet/IP: which should I use? Whichever your plant already runs. PROFINET dominates Siemens-world and Europe; EtherNet/IP dominates Rockwell-world and North America. They're comparably capable for discrete automation. Mixing them means gateways, extra spares, and engineers who have to know both. If you're an integrator dropping a cell into an existing line, the uplink fieldbus is dictated by the plant; inside your cell you can run something else (often EtherCAT for the drives) and translate at the boundary.

Why does EtherCAT win for motion? Two reasons. "Processing on the fly" lets a single Ethernet frame service hundreds of axes with near-zero per-node overhead, enabling network cycle times of 31.25 to 250 µs. And Distributed Clocks synchronize every node to under a microsecond (often under 100 ns), so every servo across a multi-axis machine samples and acts at the same instant, and synchronization jitter is what becomes path error in coordinated motion. Fast plus tightly synchronized is exactly what robot and CNC drives need.

What is OPC UA and why do I keep hearing about it? It's the vendor-neutral, secure, information-modeled standard for getting data out of the control layer to IT systems (SCADA, MES, historians, the cloud) without a proprietary driver per device. Unlike a raw fieldbus that moves bytes, OPC UA moves typed, self-describing models, with standardized companion specs for robotics, CNC, and more. It comes in client/server (inside the plant) and pub/sub (often over MQTT/Sparkplug for cloud) flavors. It's the IT/OT bridge of Industry 4.0.

Is SCADA real-time control? No, and designing as if it were is a serious mistake. SCADA is supervisory (tags, trends, alarms, historians, recipes), polling or subscribing every few hundred milliseconds to a second. It runs on PCs that can crash or lag without consequence. All hard real-time control (interlocks, closed loops, the safety function) lives in the PLC and the safety system precisely so the machine fails safe even if SCADA dies.

How does a robot talk to a PLC, and who's in charge? The robot is configured as a fieldbus slave/adapter (PROFINET IO-Device or EtherNet/IP Adapter) to the PLC master, exchanging a small command/status block: program-select, start, hold, reset from the PLC; ready, running, done, fault back from the robot. The PLC is the cell master: it sequences the line and tells the robot which taught program to run and when. The robot owns its motion but answers to the PLC. Safety travels separately, on a safety fieldbus or hardwired circuit.

What are PLr and SIL, and which do I need? Both are functional-safety ratings. PLr (Performance Level required, ISO 13849, PLa to PLe) and SIL (Safety Integrity Level, IEC 62061/61508, SIL 1 to 4) quantify how reliable a safety function must be. You derive the target from a risk assessment (severity × exposure × avoidability). Most machine guarding lands at PLd / Category 3 (single-fault tolerant); high-risk functions at PLe / Category 4. SIL 2 ≈ PLd, SIL 3 ≈ PLe.

What's a "black channel" in safety networking? It's how safety data shares the same wire as standard I/O. The underlying network (PROFINET, EtherNet/IP, EtherCAT) is treated as untrusted, and a safety protocol layered on top (PROFIsafe, CIP Safety, FSoE) adds sequence numbers, timeouts, CRCs, and unique connection IDs so any corruption, delay, loss, or misrouting of a safety message is detected and forces a safe state. That's what lets you run one cable and still certify to SIL 3 / PLe.

Are software PLCs and containerized control the future? They're a major and growing slice of it. Decoupling the control runtime from proprietary hardware enables DevOps-style deployment, version control, and redundancy, and converges the IT and OT toolchains: Siemens, Rockwell, Beckhoff, and CODESYS all offer it. The catch is that determinism now depends on a correctly configured real-time kernel and resource isolation, and the container inherits the host's attack surface. Powerful, but it shifts the security and determinism burden onto you.

As a robotics engineer, what's the one thing I should not get wrong? The safety handshake. Standard fieldbus I/O between the PLC and robot is not safety-rated; the e-stop, safe-stop, guard, and speed-and-separation functions must travel on a safety fieldbus or hardwired circuit with the right PLr/SIL, designed from the risk assessment first. Teams that treat safety as an end-of-project bolt-on routinely discover the cell can't legally run at the throughput they quoted, the most expensive integration mistake there is.