IEC 61131-3
The PLC and IED programming-languages standard. Five textual and graphical languages — Ladder Diagram, Function Block Diagram, Structured Text, Sequential Function Chart, and the deprecated Instruction List — that define what's actually written into the protection and control logic of every modern substation device.
Also: 61131-3, PLC programming languages, IEC 61131, ladder logic, structured text
IEC 61131-3 standardises the programming languages used in PLCs and, by extension, in the logic engines embedded in modern protection and control IEDs. It defines five languages that share a common type system and execution model, and it is the standard that turns “the relay does X when condition Y” from a vendor-specific drawing into a portable, peer-reviewable program.
The five languages
Three are graphical, two are textual; one (IL) was deprecated in the 2013 edition and is fading from use:
| Language | Style | Used for |
|---|---|---|
| Ladder Diagram (LD) | Graphical, ladder-rung style | Protection schemes that engineers can read like circuit diagrams |
| Function Block Diagram (FBD) | Graphical, block-and-wire | Signal-processing chains, math-heavy logic |
| Structured Text (ST) | Textual, Pascal-like | Complex algorithms that don’t fit graphical metaphors |
| Sequential Function Chart (SFC) | Graphical, state-machine | Sequencing logic — auto-reclose schemes, breaker operations |
| Instruction List (IL) | Textual, assembly-like | Deprecated in the 2013 edition |
The 2013 edition added object-oriented extensions to ST (classes, interfaces, inheritance), reflecting how complex protection and control logic had become.
Where it lives in a substation
Most substation users never touch raw 61131-3. They configure protection functions through vendor tools that ultimately compile down to it. But the standard matters in three places:
- Vendor-portable engineering — a 61131-3 program written for one PLC can in principle be moved to another, with caveats. PLCopen certifies vendors against the standard’s compliance levels, which is the closest the industry has to a promise of portability.
- Custom protection schemes — when the off-the-shelf protection functions don’t cover what a particular site needs, the engineer writes the missing logic in ST or LD. Modern protection IEDs from SEL, Siemens, GE, ABB/Hitachi all expose a 61131-3 logic engine for this purpose.
- Audit and review — a logic program written in 61131-3 is reviewable by engineers who didn’t write it, in a way that proprietary scripting languages or vendor configuration trees historically were not.
Where it intersects IEC 61850
IEC 61850 says nothing directly about how IED logic is written; it defines the interface through logical nodes and data objects. The internal logic that decides whether the trip output goes high or stays low is in 61131-3.
The two standards therefore compose: 61850 is the wire and the data model; 61131-3 is the program. A protection scheme might use a custom 61131-3 ST program to decide a trip condition, then use the IEC 61850 LN PTRC (protection trip conditioning) to publish the trip via GOOSE to the breaker.
Why this matters for the modernisation story
As more protection moves into virtualised compute (the vPAC pattern), the question of what language the protection logic is written in becomes more pointed. A virtualised protection function still runs 61131-3 logic in most cases, just on x86 rather than embedded ARM. The portability the standard promises matters more in that world than in a world of fixed-function relays.
It also matters for change management: a substation modernisation that replaces relay A from vendor X with relay B from vendor Y has historically been a major engineering exercise because the protection logic had to be rewritten in vendor Y’s tool. With both vendors implementing 61131-3 to PLCopen-certified compliance levels, the rewrite becomes notably less painful — although not painless, because the logical-node mappings and the configuration tooling still differ.