A PLC is an industrial controller that runs the logic of a machine or process in a closed, bounded cycle: it reads inputs, evaluates the program and writes outputs, over and over, under watchdog supervision. It is built from a CPU, input and output modules and a power supply, and its program follows the IEC 61131-3 languages.
What it is made of
PLC stands for Programmable Logic Controller. The device appeared in the late 1960s to replace the hard-wired relay cabinets of the automotive industry with something that could be changed without rewiring, and that genealogy still shows in how it is programmed.
Physically there are three mandatory parts and several optional ones. The power supply converts cabinet voltage into internal rails and usually feeds the I/O backplane as well. The CPU holds the processor, program memory, data memory and the vendor’s real-time operating system, together with the memory areas the program manipulates: the process image of inputs and outputs, flags or markers, timers and counters, and data blocks, part of which is declared retentive so it survives a power cut. Input and output modules are the boundary with the physical world: digital inputs for limit switches, sensors and pushbuttons; digital outputs for solenoid valves, contactors and indicators; analogue inputs for temperature probes, load cells and pressure transmitters on standard 4-20 mA or 0-10 V signals; analogue outputs for setpoints to drives and proportional valves. Depending on the machine there are also high-speed counting, motion, weighing, communication and safety-certified modules.
The form factor may be compact, with CPU, supply and a few I/O points in a single block for small machines, or modular, with a rack and a backplane taking interchangeable cards. I/O need not sit in the same cabinet either: distributing it around the machine and connecting it back to the CPU over a fieldbus such as PROFIBUS, PROFINET or EtherNet/IP is common practice, with sensors and actuators hanging off it over IO-Link.
The scan cycle and why determinism matters
A PLC does not execute its program continuously or event-driven, but in a closed cycle that repeats indefinitely and has four phases. First it reads every input and copies the values into the process image. Then it executes the program from start to finish, operating exclusively on that copy. Next it writes the output image to the physical modules. Finally it spends what is left on background tasks: diagnostics, self-test, servicing communications and updating the programming terminal.
The process image is not an implementation detail, it is the consistency guarantee. Because the program works on a frozen snapshot of the inputs, a signal that changes mid-execution cannot make the first half of the logic see one state and the second half another. The price is that inputs are sampled once per cycle: a pulse shorter than the cycle time may pass entirely unnoticed, which is why pulse-catch inputs, high-speed counters and hardware interrupts exist: they are the paths for whatever does not fit in the normal cycle.
The cycle time is the sum of all the above and depends on program size, CPU power and the amount of I/O. On manufacturing machines it typically ranges from fractions of a millisecond to a few tens of milliseconds. What matters is not that it is short but that it is bounded and repeatable: the CPU has a configured maximum cycle time and a watchdog that forces it to stop if exceeded, so a fault surfaces as a safe stop rather than as logic responding late in unpredictable ways. On that basis, modern controllers also let the program be organised into tasks: a background cyclic task for the general sequence and constant-period interrupt tasks for whatever needs a fixed rhythm, such as a PID loop or an axis controller. That determinism, knowing the logic is always evaluated within a known window, is what allows an emergency stop to act within a demonstrable time, and it is why machine logic lives in a PLC rather than in a conventional computer.
The IEC 61131-3 languages
IEC 61131-3 standardises programmable controller programming languages and the software model underneath them: programs, function blocks, functions, data types and tasks. It defines five notations.
Ladder diagram (LD) represents logic as rungs with contacts and coils, copied from the relay schematics it replaced; it is the most widespread in maintenance precisely because any plant electrician reads it without extra training. Function block diagram (FBD) chains blocks with inputs and outputs and feels natural for control loops and signal processing. Structured text (ST) is a high-level textual language, related to Pascal, gaining ground for calculations, recipe handling and algorithms that would be unreadable in ladder. Sequential function chart (SFC) describes the machine sequence as steps and transitions and works as a structuring element: inside each step the action is written in any of the other languages. Instruction list (IL) is a low-level textual notation close to assembly, deprecated by the standard in its third edition and no longer recommended for new development, although it still turns up in legacy programs.
The existence of the standard does not mean a program moves from one brand to another for free. Every vendor has its own development environment, block libraries and extensions, and real portability is limited to structure and concepts. For a data project the consequence is direct: the signal map of a machine has to come from the specific program running that machine, not from a generic catalogue.
The installed base: layers on top of layers
A typical Spanish plant does not have one generation of controllers, it has several living side by side. It is normal to find, in the same building, a CPU installed twenty years ago from a range long withdrawn from the catalogue but perfectly operational, running a line that still produces; next to it a recently imported machine with another vendor’s controller and its own programming console; and beside them auxiliary equipment (compressors, chillers, weighing systems, power analysers) with no PLC at all, exposing only serial Modbus. Each with its brand, its programming software, its network and its protocol: PROFINET or PROFIBUS in the Siemens world, EtherNet/IP in Rockwell installations, FINS on Omron controllers, EtherCAT in motion control, and proprietary serial protocols on the oldest equipment.
That heterogeneity is not a management failure: it is the logical result of buying machines when they are needed, from whoever builds them best, over thirty years. And it is the real starting point of any data project. The operational question is never “which PLC do we have” in the singular, but what each device speaks, who keeps the source program and what can be read without renegotiating machine maintenance with its builder.
PLC, industrial PC, microcontroller and PAC
All four are computers and the resemblance ends there.
A microcontroller is a generic integrated circuit: it needs custom electronics around it, power, protection against cabinet interference, a general-purpose language and documentation. It belongs inside a mass-produced product, where unit cost rules and the design is done once. It does not belong in charge of an installation someone else will have to diagnose and repair ten years from now, with the machine stopped and production waiting.
An industrial PC is a computer hardened for the plant (fanless, tolerant of vibration, dust and temperature) running a general-purpose operating system. It is the right tool for machine vision, a demanding operator interface, data storage or edge computing workloads. What it does not provide out of the box is the timing guarantee: its scheduler makes no promise about when a task runs, unless a real-time kernel or a soft-PLC runtime reproducing the scan model is added on the same hardware.
A PAC (Programmable Automation Controller) is a term coined by market analysis in the early 2000s, not a normative category: no standard defines what is and is not a PAC. It describes controllers combining the ruggedness and deterministic cycle of a PLC with capabilities traditionally associated with the PC: generous memory and processing power, symbolic tag-based addressing instead of physical addresses, motion control, process regulation and vision integrated in the same device, mixed programming in IEC 61131-3 and high-level languages, and rich network connectivity. In practice, today’s high-end ranges from the main vendors match that description and are called PLC or PAC depending on each vendor’s marketing; the boundary is blurred and should not drive a technical decision.
Against those three, the PLC is a product built around one specific promise: a bounded, watchdog-supervised cycle, modules replaceable with the installation running, integrated diagnostics, spares and support over decades, standardised languages that can be maintained without depending on whoever wrote them, and certified variants for safety functions under the functional safety standards. When an emergency stop is in the loop, none of the other options matches that combination.
Getting data out without interfering with control
A machine PLC already holds almost everything management needs: run, stop and fault states with their reason, good and reject piece counters, times, alarms and process variables. Moving that to a data layer is, in the vast majority of cases, a reading problem rather than a reprogramming one. It helps to understand exactly what happens when someone asks.
Where the request is served. Communications are handled in the background part of the cycle, after outputs are written. An external read never interrupts program evaluation and cannot alter interlocks: reading is inherently passive. What excessive polling does do is stretch the cycle time and increase its jitter, to the point that some controllers let you explicitly cap the percentage of the cycle devoted to communications, precisely so that data load does not degrade control. The engineering rule is to size frequency from the dynamics of each variable (a piece counter does not need reading every hundred milliseconds) and to group contiguous signals into a few large requests instead of many small ones.
What is readable and what is not. Not everything in the program is accessible from outside. Temporary variables of a block and the internals of an instance may have no stable existence between cycles; to be queryable, a signal has to live in a global data area. Some vendors also offer optimised data blocks that are not addressable by absolute offset, so classic address-based drivers cannot see them and they must be read symbolically, typically over OPC-UA.
Consistency of the set. A multi-word read is not necessarily atomic with respect to the cycle: if the program updates those values while the request is being served, the result can mix data from before and after. When a coherent set is needed, a batch of values describing the same instant, the clean solution is an interface block: a data area the program fills once per cycle, meant exclusively to be read from outside. That block does two jobs at once: it guarantees consistency and it insulates the data layer from program internals, so a future change to the logic does not break the integration. Agreeing it with whoever maintains the machine is also what prevents arguments about responsibility.
The three access paths. The first is a direct protocol read from the CPU itself: Modbus TCP or serial at the open end, or the vendor’s native protocol over its own network. The second is the embedded OPC-UA server that modern ranges include, which solves typing and symbolic addressing and allows subscription on value change instead of polling; the cost is that it consumes memory, sessions and monitored items of the controller itself, with limits worth checking in the datasheet before designing the integration. The third is an external industrial gateway that reads the PLC over whatever it speaks and republishes upwards with type, units and timestamp, typically over MQTT. This last one has a structural advantage: the controller is read once no matter how many consumers exist afterwards, instead of receiving one poll per interested system as happens with classic OPC DA clients. On older equipment without Ethernet the path is usually serial, and when there is absolutely nothing to read, instrumenting the physical signal before it reaches the input card remains an option.
Time and fast events. The controller does not date its data unless programmed to, so the timestamp comes from the reader and should be stamped as close to the machine as possible. For events faster than the read cycle the answer is not to poll harder, which degrades control without solving anything, but to latch them in the PLC: an accumulated counter, a latched bit or a small event buffer with its own instant preserve what happened between reads and are drained when the reader arrives. A piece counter never loses information between two reads; an instantaneous run bit does.
And the line not to cross. The data layer reads, it does not write. Extracting data requires no line stoppage and no recompilation if the area to be read already exists, and when an interface block has to be created the change is additive and lands in a planned shutdown. Writing setpoints from outside is a different matter: it is a control function, and it deserves the same design, validation and accountability as any change to the machine program.
Related terms
The PLC is the lower boundary of the OT/IT bridge and the primary source of machine data. Above it, the SCADA supervises and the MES manages orders; in the ISA-95 functional hierarchy the PLC occupies the automatic control level, just above the sensors and actuators touching the physical process. Upstream, its data feeds the historian and the calculation of indicators such as OEE without manual reports. Connecting controllers of any brand to a common data layer is the scope of PLC connectivity, while developing or modifying the logic itself belongs to PLC, SCADA and HMI programming.