IEC 61131-3 Programming Model: POUs, Tasks, ST, LD, FBD & SFC
IEC 61131-3 standardizes typed program organization and a family of textual and graphical notations for programmable controllers. Its real leverage comes from separating configuration, resources, tasks, programs, functions, function blocks, and sequence structure—not from choosing one favorite PLC language.
IEC 61131-3 is often introduced as “the PLC languages standard.” That is true but incomplete. Its more important contribution is a software model that says what is scheduled, what owns state, what can be reused, and how a controller application is deployed. The 2025 fourth edition standardizes Structured Text (ST), Ladder Diagram (LD), and Function Block Diagram (FBD), with Sequential Function Chart (SFC) elements for organizing programs and function blocks.
Deployment and code structure are separate #
- Configuration
- The complete software arrangement for a control system, including processing resources and deployment-specific connections.
- Resource
- A processing facility able to execute IEC controller programs and access I/O or services. One physical controller commonly exposes one resource, but the concept is deliberately more general.
- Task
- An execution-control element that releases programs or function blocks periodically or on a trigger.
- Program
- The highest-level POU for an application. Program instances connect application logic to resource-level variables and task scheduling.
- Function block
- A reusable type with named inputs, outputs, and instance state. Two instances of the same type are two independent state machines.
- Function
- A reusable computation without persistent instance state. It is the natural home for conversions, limits, and mathematical transformations.
A function block type is not its instance. MotorControl can define behavior once; FeedPump and TransferPump hold different timers, latches, and outputs. Failing to distinguish them produces hidden shared state or duplicated logic.
Choose notation by the dominant relationship #
| Notation | Best fit | Strength | Common misuse |
|---|---|---|---|
| LD | contacts, coils, permissives, simple machine logic | reads like an energized Boolean circuit; familiar for maintenance | large arithmetic and state machines become cross-referenced rung mazes |
| FBD | signal flow, control blocks, transformations | data dependencies and reusable blocks are visible | execution order and feedback paths can be ambiguous without explicit conventions |
| ST | algorithms, structured data, loops, calculations | compact, typed, expressive | imperative code can hide plant-state transitions and output ownership |
| SFC | ordered phases, alternatives, parallel branches | exposes active steps, transitions, and actions | treating every Boolean as a step or using SFC as the only safety layer |
The notations are complementary, not interchangeable skins. PLCopen explicitly warns that arbitrary automatic conversion among them was never the standard's goal. An array expression natural in ST may have no clean FBD representation; an electrical-maintenance interlock may be much clearer in LD.
Types are part of the control contract #
Use Boolean only for genuine two-state facts. Preserve engineering meaning with enumerations, structures, arrays, time types, and explicitly scaled numeric types. A motor interface can group command, feedback, permissives, interlocks, state, fault, and diagnostics into one typed boundary instead of scattering aliases across global memory.
TYPE MotorState : (Stopped, Starting, Running, Stopping, Faulted); END_TYPE
FUNCTION ClampPercent : REAL
VAR_INPUT x : REAL; END_VAR
ClampPercent := LIMIT(0.0, x, 100.0);
END_FUNCTION
FUNCTION_BLOCK MotorUnit
VAR_INPUT StartReq, StopReq, Feedback, Permissive, Interlock : BOOL; END_VAR
VAR_OUTPUT State : MotorState; RunCmd : BOOL; END_VAR
(* Instance state and transition logic live here. *)
END_FUNCTION_BLOCK
The snippet is structural, not a complete motor design. It demonstrates the boundary: a function computes the same result from explicit inputs; a function-block instance remembers which state it is in.
Variable scope and ownership #
Prefer the narrowest scope that reflects ownership:
- function locals for transient calculations;
- function-block instance variables for equipment state;
- program variables for coordination within one application;
- resource/global variables only for intentional shared interfaces;
- directly located variables only at the I/O or compatibility boundary.
Global memory makes initial wiring easy and later reasoning hard. When any POU can write any tag, task order becomes an implicit API. Give each actuator command, sequence state, and alarm state one owner; expose other needs as inputs, requests, or status outputs.
Execution is outside the POU body #
The body of a program or function block does not choose when it runs. A task does. A correct code review therefore needs both the POU and its deployment:
- task period, priority, and trigger;
- instance binding and invocation order;
- I/O update boundaries;
- retain/non-retain behavior;
- restart and watchdog policy.
Two identical POUs attached to different task periods implement different dynamic systems. A timer or discrete controller parameterized in cycles rather than physical time will change behavior when the task configuration changes.
SFC is evaluated, not “played” continuously #
PLCopen's IEC expert FAQ describes each invocation as one evaluation: determine active steps, evaluate their outgoing transitions, execute active actions, and update the active-step set according to the defined semantics. The containing POU must be invoked repeatedly for the chart to progress. This matters when a transition condition and an action affect the same variable: the result follows evaluation semantics, not an imagined animation.
SFC steps encode control state; they do not prove that the physical process reached the state. A Running step should depend on confirmed feedback and should still handle loss of that feedback.
Portability has layers #
IEC syntax and common elements improve portability, but they do not make an application binary-portable. PLCopen identifies the practical gaps: I/O addressing, task rates, supported feature subsets, implementation limits, libraries, and exchange formats differ. Separate the application into layers:
- pure functions and equipment function blocks with explicit types;
- sequence and coordination logic;
- platform adapters for I/O, diagnostics, communications, motion, and safety;
- deployment configuration for tasks, memory, and hardware.
The upper layers are the plausible portability boundary. Pretending a vendor-specific motion block, retained-memory layout, and direct-address map are generic only moves the dependency into undocumented assumptions.
Review checklist #
For each POU, identify whether it is a type or instance, who owns its state, and which task invokes it. For each global or located variable, justify why a narrower interface is insufficient. Verify every timer against real elapsed time and task jitter. Make output ownership unique. Test cold start, warm restart, program download, mode change, and loss of physical feedback. Finally, use the notation that makes the dominant plant relationship visible to the people who must diagnose it under pressure.