PLCProgrammable Logic Controller

A Programmable Logic Controller is an industrial computer purpose-built to read physical inputs, execute a stored logic program, and drive physical outputs, deterministically and continuously, in an environment far harsher than an office server room — vibration, temperature swings, electrical noise, dust and washdown. It was invented in the late 1960s (Modicon 084, for General Motors) explicitly to replace racks of relay panels with something that could be reprogrammed instead of rewired.

In a regulated plant, the PLC is almost always the layer that actually does something: it opens a valve, starts a motor, drives a temperature loop, reads a load cell, latches an interlock. Everything above it — SCADA, MES, ERP — is watching, aggregating and directing, but the PLC is where electrons meet the process.

• Central Processing Unit (CPU) — executes the program on a fixed scan cycle.
• I/O modules — digital and analog inputs (sensors, switches, 4-20mA transmitters) and outputs (actuators, motor starters, valves, drives).
• Power supply — typically 24VDC field-side, isolated from the backplane.
• Communication modules — Ethernet/IP, Profinet, Modbus TCP, DeviceNet, and increasingly OPC-UA or MQTT for northbound data.
• Memory — program memory (the logic itself) and data memory (the live tag/register values).

Unlike a general-purpose computer running an operating system with pre-emptive multitasking, a PLC executes a repeating scan cycle, typically measured in single-digit to tens of milliseconds:

1. Input scan — read all physical inputs into an internal input image table (a snapshot, not a live read, so the logic sees a consistent picture for the whole scan).
2. Program execution — run the user logic top to bottom (or per configured task priority), using the input image and internal memory, writing results to an output image table.
3. Output scan — write the output image table to the physical output modules.
4. Housekeeping / communications servicing — process comms requests (HMI polls, OPC-UA reads, diagnostics) in the remaining scan time.

This 'freeze the inputs, run the logic, write the outputs' model is what makes PLC behaviour deterministic and testable: the same input pattern always produces the same output pattern, and a bench test with forced inputs will predict field behaviour precisely. It's also why scan-time budget matters — an overloaded CPU with too much logic per scan will lengthen the cycle, and safety-critical logic (E-stops, interlocks) is usually run at faster/higher-priority tasks or offloaded to a dedicated safety PLC certified to IEC 61508 / IEC 62061 / ISO 13849.

IEC 61131-3 standardises five PLC programming languages so logic (mostly) portable across vendors conceptually, even though the runtimes themselves are proprietary:

• Ladder Diagram (LD) — the original and still the most common on the factory floor; models relay logic visually as rungs of contacts and coils. Easy for electricians to read; awkward for complex math, string handling, or state machines.
• Function Block Diagram (FBD) — wires reusable blocks (PID, timers, counters) together; common in continuous-process and packaging logic.
• Structured Text (ST) — a Pascal-like text language; the right tool for recipe math, string/array manipulation, and anything a spreadsheet-style ladder rung struggles to express cleanly.
• Instruction List (IL) — a low-level assembly-like language; deprecated in the 2013 edition of the standard and rarely used in new work.
• Sequential Function Chart (SFC) — models a process as a sequence of steps and transitions; the natural fit for ISA-88 phase logic (state machine: idle → running → held → aborted → complete).

A well-structured batch or packaging PLC program typically mixes these: SFC for the phase state machine, ladder or FBD for the interlocks and discrete I/O, and ST for the setpoint/recipe calculations — rather than forcing everything into ladder because that's what the original programmer knew.

These five terms get used loosely on the floor and precisely in an audit. Knowing the boundary matters because crossing it in the wrong direction is the single most common architecture mistake in regulated automation.

ISA-95 (IEC 62264) formalises the automation pyramid into levels, precisely so organisations stop arguing about where a given piece of logic should live:

The reason MES logic must never be written in ladder is not stylistic — it's a validation and maintainability argument. Ladder logic is designed for I/O-scale, deterministic, single-machine control; it has no native concept of a user account, an e-signature, a document version, a genealogy tree, or a multi-step approval workflow, and it is validated and change-controlled by the automation engineering team on a completely different cadence than QA-owned business logic. Bury an e-signature requirement or a lot-release rule inside a PLC program and you've created a GxP business rule that: (1) only automation engineers can read or modify, (2) has no audit trail of who approved the logic change and why, (3) can't be unit-tested the way application code can, and (4) is invisible to the people who actually own that regulatory requirement. The ISA-95 boundary exists to keep the accountable owner of a rule and the system that enforces it aligned.

A PLC's internal memory is just addresses and registers — DB1.DBD20, %MW100, Tag_Weight_Actual — meaningless outside the program that wrote them. Turning that into usable process data for a historian, SCADA screen or MES requires tag mapping: an explicit, documented crosswalk between a PLC address and a named, typed, unit-of-measure-tagged data point (e.g. Line3.Mixer.Temp_PV, °C, float32, updates every 250ms).

• OPC-UA is the dominant standard for this handoff today: a PLC or an OPC-UA server sitting in front of it exposes an address space of typed nodes that a client (SCADA, historian, MES) can browse, subscribe to, and read/write with built-in security (certificates, encryption) — a major upgrade over the older OPC Classic (DA/HDA) which relied on Windows DCOM.
• MQTT (often with Sparkplug B for payload structure) is the common choice for lightweight, publish/subscribe telemetry, especially from remote or edge devices where a persistent broker connection is more practical than polling.
• Legacy protocols (Modbus TCP/RTU, Ethernet/IP explicit messaging, proprietary vendor drivers) remain common on older equipment and usually route through a gateway that republishes as OPC-UA or MQTT for the modern stack to consume.

Good tag-mapping discipline treats the map itself as a controlled document: every tag has an owner, a data type, an engineering unit, an update rate, a description, and — critically for a regulated environment — a statement of which tags are GxP-relevant (feed a batch record, a CQA/CPP, or an alarm that requires investigation) versus purely diagnostic. Undocumented or 'orphan' tags (see below) are one of the most common findings when a site tries to reconstruct exactly what data an MES or historian is actually consuming.

GAMP 5 categorises automated systems by configurability and risk to scope validation effort proportionately, and PLC-based systems typically land in one of two buckets:

• Category 3 — Non-configured products. Off-the-shelf instrumentation or a PLC running only vendor firmware with no custom application logic (e.g. a fixed-function weigh indicator). Validation focuses on verifying the product operates per the vendor's published functional spec in the actual use environment.
• Category 4 — Configured products. A PLC or SCADA platform where the vendor supplies the runtime/engine but the site has written custom application logic (ladder/ST/SFC programs, HMI screens, alarm configuration, recipe parameters). This is where most process-control PLCs sit, and it drives full URS → FS → DS → code review → IQ/OQ/PQ.
• Category 5 — Custom application code is rare at the pure-PLC layer (more common at MES/data-layer) but appears when a site writes bespoke drivers, custom OPC-UA server logic, or non-standard communication middleware.

A common audit gap is qualifying the PLC hardware and I/O (IQ) thoroughly, then treating OQ as 'the vendor's factory acceptance test was fine' — skipping site-specific OQ against the as-installed, as-configured logic. Interlocks and alarm setpoints must be challenged in the qualified environment, not assumed from the FAT.

21 CFR Part 11 applies the moment a PLC, its HMI, or its historian is the system of record for a GxP decision — not just when a document explicitly says 'electronic record.' If the only place a critical process value (mixing time, autoclave temperature, tablet-press compression force) is captured is an HMI trend or a PLC-resident recipe, that HMI/PLC combination is in scope for electronic-record and, where applicable, electronic-signature controls: secure, computer-generated, time-stamped audit trails for operator actions that create, modify or delete GxP records; access controls tied to individual identity, not shared operator logins; and record retention that survives a PLC firmware upgrade or program re-download.

In practice, most PLCs and HMIs are not good at this natively — PLC memory is small, HMI historians are often a rolling buffer, and 'who changed the setpoint' is frequently answered only by 'someone with the operator password, at some point.' This is precisely the gap that a validated data historian or an MES sitting above the control layer is supposed to close: capture the same PLC data with attributable, contemporaneous, immutable recording before it ages out of the controller's own limited buffer.

A PLC program is GxP-relevant configuration, and every edit — a new interlock, a changed timer value, a modified alarm limit, even a comment-only cleanup that touches a rung — should go through the same change-control discipline as any other validated system change: documented request, impact assessment (does this touch a CPP, a safety interlock, a batch-record data point?), review and approval, testing proportionate to risk, and an updated, checksummed program backup with version history.

• Maintain an as-built vs as-designed comparison — field modifications made under time pressure during a breakdown are the most common source of undocumented drift.
• Version and checksum every program backup; store it under document control, not just on the programmer's laptop.
• Require a documented reason and approver for any online edit made while the process is running (forcing an output, changing a timer preset live) — these are exactly the changes that later show up as unexplained deviations.
• Re-run the relevant OQ test cases after any change that touches an interlock, alarm setpoint or control-loop tuning parameter.
• Restrict online/download access to the PLC by role — a floor operator's HMI login should not be able to modify ladder logic.

The most common finding is not a missing change-control SOP — most sites have one — it's evidence that the SOP wasn't actually followed for a specific, dated logic change that the investigator can trace to a process anomaly.

PLCs and the HMIs above them are usually where alarms originate — a value crossing a high/low limit, an interlock tripping, a communications fault. ISA-18.2 defines the discipline for making that stream useful rather than overwhelming: alarm rationalization (every alarm has a documented cause, consequence and operator response, and exists because it requires action — not just because a tag could be flagged), alarm shelving with time-limited, logged suppression instead of silent acknowledgement, and alarm flood prevention so a single upset doesn't bury the operator under hundreds of chattering, low-value alarms exactly when they need to think clearly.

In a regulated context, alarms that indicate a CPP excursion or an equipment state that could affect product quality need a defined path from 'alarm fired' to 'documented response' — ideally captured automatically rather than relying on an operator's memory of what they did and why, hours later during batch record review.

The recurring pattern across PLC/HMI findings is the same one described throughout this page: control-layer flexibility without control-layer discipline.

• Uncontrolled setpoint changes — an operator or engineer adjusts a temperature, speed or timer setpoint from the HMI with no change-control record, no reason code, and no link to the batch that was running at the time. The process data looks fine in isolation; the missing context is what an investigator flags.
• No audit trail on the HMI — password-protected screens that log 'who' but not 'what changed, from what value, to what value, when, and why' fail the Part 11 audit-trail test even though they look like access control is in place.
• Orphan tags — PLC registers or HMI tags that exist in the program but aren't documented in the current tag map, often left over from a decommissioned feature or a contractor's undocumented addition. They're invisible until someone asks 'what does this actually do' during an investigation and nobody can answer confidently.
• Shared/generic logins on the HMI, defeating individual accountability for setpoint or recipe changes.
• Firmware/program version drift between what's installed on the floor and what's on file as the validated baseline, discovered only when a fault-finding session pulls the live program and compares it to the archived one.
• Safety interlocks bypassed via an HMI 'maintenance mode' or forced I/O left engaged after the maintenance window closed, with no automatic timeout or reminder.
• Alarm setpoints changed without re-qualification, silently shifting what the process considers 'in control.'

The correct integration pattern is one-directional and evidentiary: the MES subscribes to PLC/SCADA tags to capture what happened, attaches that data to the work order/batch step it belongs to, and — where the process calls for operator or QA action — surfaces it as a workflow step (confirm, sign, investigate). It does not write setpoints, force outputs, or override interlocks. The PLC remains sole owner of real-time control; the MES remains sole owner of the record, the recipe parameters as approved, the exception workflow and the genealogy.

• Read-only subscription to defined, documented tags via OPC-UA or MQTT, mapped to named process parameters on the batch/work-order record.
• Time-stamped, attributable landing of every value change relevant to a CQA/CPP, closing the audit-trail gap the raw PLC/HMI often leaves open.
• Deviation/CAPA triggers when a subscribed value breaches a defined limit, rather than relying on an operator noticing and manually logging it.
• Recipe parameters flow one way — from the approved, version-controlled MES recipe down to the PLC as a set of validated parameters at batch start — never back up as an uncontrolled runtime edit.
• Any operator action that changes a live process value still happens at the PLC/HMI where the interlocks live; the MES's job is to make sure that action is captured, contextualised and, where required, signed off.