Industrial Automation: PLCs, SCADA & Fieldbus — The Ultimate Guide

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 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 not a slow computer — it 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–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.

Why it's not just a 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.

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–10 ms
• Mid/large PLC (S7-1500, ControlLogix): 0.5–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. To reliably detect a part on a 0.3 m/s conveyor with a sensor that's "visible" for 30 mm, the part is in front of the eye for ~100 ms — a 10 ms scan catches it ten times over. To catch a 5 ms pulse, don't use the normal scan; use a high-speed input.

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, not just what's 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–2 A per point). Densities of 8, 16, or 32 points per module.
• Analog I/O modules — inputs for 4–20 mA, 0–10 V, RTD, thermocouple; outputs for 4–20 mA / 0–10 V. Resolution 12–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 is mostly geography and brand lock-in, not capability. 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–20 mA).

The industrial-Ethernet generation (the present)

Plain Ethernet isn't deterministic — TCP/IP with standard switching has unbounded latency. The industrial-Ethernet protocols solve this in different ways, which is the whole reason there are several incompatible ones.

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.

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. Sub-microsecond sync is what lets a multi-axis machine hold a smooth, accurate path at speed.

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 doesn't just move a tag value; it carries a typed, structured, self-describing model. 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 part of the spec, not bolted on. 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're complementary, not competing.

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 command/status protocol, not a stream of trajectory points. 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.

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, not an engineering nicety. 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, diagnostic coverage, and 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 probability of dangerous failure per hour (PFHd). For machinery, SIL 2 roughly corresponds to PLd and SIL 3 to PLe.

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 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. This is what lets you run one cable instead of two and still hit SIL 3 / PLe.

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–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–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, not the compute.

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–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–PLe) and SIL (Safety Integrity Level, IEC 62061/61508, SIL 1–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.