PLC

A programmable logic controller is the computer at the bottom of an industrial control system, the one wired directly to the physical world. It reads sensors, evaluates logic, and drives outputs: it is what actually opens a valve, starts a motor or trips a breaker.

The scan cycle

A PLC does not run an event loop or a scheduler. It runs one fixed deterministic cycle, forever, typically every 1 to 100 milliseconds:

1. Read inputs        sample every input, copy into the process image
2. Execute program    evaluate the whole program against that frozen snapshot
3. Write outputs      copy the output image to the physical terminals
4. Housekeeping       comms, diagnostics, watchdog

Everything follows from this. The program sees a consistent snapshot rather than inputs changing mid-evaluation. Execution time is bounded and predictable, which is what "real-time" means here. And a watchdog resets the controller if a cycle overruns, because a controller that stops scanning has stopped controlling something physical.

Memory model

PLC memory is addressed rather than allocated, and the address is part of the engineering documentation:

Inputs (I / %I), one bit or word per physical terminal.
Outputs (Q / %Q on Siemens, O elsewhere). A coil is a single output bit.
Markers / internal memory (M), the program's own flags.
Data blocks (DB on Siemens), structured storage for setpoints, recipes and counters.
Timers and counters, first-class objects rather than library calls.

An attacker who can write to this memory does not need an exploit. Writing a 1 to an output bit energises the corresponding terminal. That is the controller working correctly.

Programming languages

IEC 61131-3 defines five, and you will meet three:

Ladder logic (LD). A graphical notation drawn as relay rungs. Dominant, because it was designed to be readable by electricians replacing relay panels.
Structured text (ST). Pascal-like text, used for anything with real arithmetic.
Function block diagram (FBD). Blocks and wires, common in process industries.

Programs are downloaded from an engineering workstation over the vendor's protocol. That download path is the highest-value target on the network: whoever can download logic owns the process.

Why it matters to security

The protocols have no authentication. s7comm, modbus, dnp3 and their siblings let anyone who can reach the port read and write memory. Some vendors add a password; it is often optional, frequently weak, and historically bypassable.
Run/stop is remote. Many controllers accept a stop command over the network. Stopping a PLC stops the process.
Logic can be replaced. A download of modified logic persists, survives reboots, and is invisible from the HMI unless someone compares the running program to the engineering baseline.
Firmware is rarely updated. A controller commissioned a decade ago runs decade-old firmware, because updating means a scheduled outage and revalidation.
They are fragile. Small TCP stacks fall over on traffic a desktop would ignore. Port scanning a live PLC has caused real outages.

The safety layer is deliberately separate: a safety instrumented system is an independent controller whose only job is to bring the process to a safe state, and it is designed not to depend on the PLC being correct.

Pitfalls

Reporting "unauthenticated write to a PLC" as a device vulnerability. It is the protocol as specified; the finding is that the port is reachable.
Assuming the HMI reflects reality. The HMI reads what the PLC reports, and both can be manipulated independently.
Testing on a live controller. Use a simulator or a lab unit; the physical consequence is the whole point of this class of device.

What it pairs with

scada is the supervisory layer above it, ot-security the discipline around it, purdue-model the network layering, and modbus, s7comm, dnp3 and opcua the protocols it speaks.