ST

What is Structured Text (ST)?

Structured Text (ST) is the textual, Pascal-inspired programming language defined in IEC 61131-3 that engineers use to program PLCs and other industrial control systems with variables, conditions, loops and functions instead of graphical symbols. ST is used for everything that becomes cumbersome in graphical languages: calculations, control algorithms, recipes, data structures and state machines in industrial automation and process automation. Since Instruction List was removed from the standard in 2025, ST is the only textual language left in IEC 61131-3.

🧠 Where does Structured Text come from?

ST was already part of the first edition of IEC 61131-3 in 1993, alongside Ladder Diagram, Function Block Diagram, Sequential Function Chart and Instruction List. Its syntax borrows heavily from Pascal and Ada: assignment with :=, statements terminated by a semicolon, and blocks closed with END_IF, END_FOR or END_CASE.

Vendors sometimes give the language their own name. Siemens calls its variant in TIA Portal SCL (Structured Control Language), Rockwell Automation offers ST in Studio 5000, and Beckhoff builds TwinCAT 3 on CODESYS, which extends ST into Extended Structured Text with features such as the set and reset assignments S= and R=.

🔧 How does Structured Text work?

An ST program is made up of program organisation units (POUs): programs, function blocks and functions. Each POU starts with a declaration section in which the strongly typed variables are defined, followed by the statements. A simple function block for monitoring a pump:

FUNCTION_BLOCK FB_Pump
VAR_INPUT
    Start      : BOOL;
    Pressure   : REAL;   (* bar *)
END_VAR
VAR_OUTPUT
    Motor      : BOOL;
    Alarm      : BOOL;
END_VAR

IF Pressure > 10.0 THEN
    Motor := FALSE;
    Alarm := TRUE;
ELSIF Start THEN
    Motor := TRUE;
    Alarm := FALSE;
ELSE
    Motor := FALSE;
END_IF;
END_FUNCTION_BLOCK

The language has a fixed set of statements:

• Assignment - Value := Expression;
• Conditions - IF ... ELSIF ... ELSE ... END_IF and CASE ... OF ... END_CASE, the latter ideal for state machines
• Loops - FOR, WHILE (tested before each pass) and REPEAT ... UNTIL (tested after each pass, so it always runs at least once); EXIT leaves only the innermost loop
• Calls - functions and function blocks, such as the standard timer TON or counter CTU, and RETURN to leave a POU
• Comments - (* ... *) and, since the 2013 edition, // for a single line

Data types in ST are strictly defined:

Like the other languages, ST is executed by the PLC runtime in a cyclic scan: read inputs, execute code, write outputs. The deterministic behaviour therefore comes from the runtime, not from the language itself. A WHILE loop without a hard upper bound can make the cycle time explode; the watchdog then stops the CPU, which on a Siemens S7-1500 happens by default once the maximum cycle time of 150 ms is exceeded.

🔄 How does ST compare with the other IEC 61131-3 languages?

In practice, projects combine the languages: SFC for the step sequence of a batch process following ISA-88, LD or FBD for interlocks that a technician must be able to read at night, and ST for the computational core. Because ST is plain text, it also fits well with version control in Git, code reviews and static analysis. IEC 61499 reuses ST for the algorithms inside distributed, event-driven function blocks.

🏭 Where is Structured Text used in practice?

• Control engineering - PID control, filters, cascade control and advanced process control up to MPC algorithms
• Motion control - kinematics, cam profiles and trajectory calculations alongside the PLCopen motion blocks
• Batch and recipes - recipe parameters in structures and arrays, state machines with CASE
• Energy and utilities - load calculations, turbine and pump control, energy optimisation
• Data and analytics - scaling, averaging and buffering sensor values for historians, MES and AI models, which usually run outside the PLC
• Communication - handling telegrams and data blocks from Remote IO, actuators and VFDs over ProfiNET, IP, Modbus TCP or OPC UA, and delivering status and alarms to the HMI and SCADA

An example from control engineering: a PI controller with a fixed sample time and clamping against integrator windup. In production you would normally use the vendor’s PID block, such as PID_Compact in TIA Portal, but the example shows why ST feels natural here:

Error    := Setpoint - ProcessValue;
Integral := Integral + Ki * Error * Ts;
IF Integral > 100.0 THEN Integral := 100.0; END_IF;
IF Integral < 0.0   THEN Integral := 0.0;   END_IF;
Output   := LIMIT(0.0, Kp * Error + Integral, 100.0);

🧭 How do you write maintainable and secure ST code?

ST gives you a lot of freedom, and with it room for poor code. An approach that holds up in practice:

1. Follow a coding guideline - the PLCopen Coding Guidelines (version 1.0, April 2016) contain more than sixty rules on naming, comments, coding practice, language use and the handling of vendor extensions
2. Build modular code - one function block per object type (pump, valve, motor) with fixed interfaces, in a shared library; no monolithic programs of thousands of lines
3. Bound every loop - use FOR with a fixed upper limit, check array indexes and avoid WHILE loops that wait on process conditions
4. Choose data types deliberately - DINT or LREAL where an INT could overflow, and no = comparisons on REAL values
5. Build security into the code - the Top 20 Secure PLC Coding Practices (June 2021) call for, among other things, validating HMI input in the PLC, checking indirect addressing, testing inputs for physical plausibility and trending cycle times
6. Test before commissioning - unit tests and simulation on a soft PLC, followed by a FAT with a process model
7. Control changes - keep projects under version control, compare online and offline code before every download, and route every change through change management

Common errors and their causes:

🔐 What role does ST play in OT security and safety?

PLC code is an attractive target, because whoever changes the logic controls the physical process. Stuxnet demonstrated this in 2010: the worm placed its own code in organisation blocks OB1 and OB35 of Siemens S7-315 controllers and hid it from the engineer. Attackers therefore target the engineering station, project files and the download function. Measures in line with IEC 62443:

Functional safety follows its own rules. IEC 61508, IEC 61511, ISO 13849 and IEC 62061 set requirements for the software of a safety PLC, and many safety environments restrict programming to LD or FBD with certified function blocks. ST is only used in safety logic where the certified tooling allows it, and then usually as a restricted subset without dynamic constructs.

For Dutch organisations in critical infrastructure, demonstrable management of PLC software falls under the duty of care of the Cybersecurity Act (Cyberbeveiligingswet), which entered into force on 15 August 2026. Structured, version-controlled ST code makes that management considerably easier.

🌐 Why is ST gaining ground in Industry 4.0?

In Industry 4.0, OT is moving towards software-defined architectures: soft PLCs on industrial PCs, virtualised controllers and edge computing. Textual code, object orientation and tooling from the IT world fit those far better than graphical languages. Young engineers with a software background also pick up ST faster than ladder logic. The flip side is that latency and jitter matter more as soon as a general-purpose operating system shares control over timing.

❓ Frequently asked questions

Is Structured Text the same as SCL?

SCL (Structured Control Language) is the name Siemens uses for its implementation of Structured Text in TIA Portal and Step 7. The basis is the same as ST in IEC 61131-3, but Siemens adds its own instructions, data types and addressing. Code is therefore not interchangeable with other ST environments without changes.

Is Structured Text hard to learn?

Structured Text is easy to learn for anyone with basic programming knowledge, because its syntax resembles Pascal. The harder part is thinking in cycles: ST code runs again on every PLC scan, so waiting inside a loop is a mistake. Once you master that principle, you can quickly write useful ST programs.

When should you choose Structured Text instead of Ladder Logic?

Structured Text is the best choice for calculations, control algorithms, recipes, arrays and state machines. Ladder Logic remains stronger for simple discrete logic and interlocks that technicians need to follow online. Many projects combine both languages within the same PLC program.

Does Structured Text support object-oriented programming?

Structured Text has supported object-oriented concepts such as methods, interfaces and function block inheritance since the third edition of IEC 61131-3 in 2013. Environments such as CODESYS and TwinCAT 3 have offered this for years. Not every PLC platform implements these extensions fully.

Can Structured Text be used in safety PLCs?

Structured Text is only allowed in safety PLCs when the vendor’s certified engineering tool supports it. Many safety environments restrict programming to Ladder Diagram or Function Block Diagram with certified blocks. The requirements follow from standards such as IEC 61508 and IEC 61511.

Can Structured Text code be moved between PLC brands?

Structured Text is the easiest IEC 61131-3 language to port, because it is plain text. Vendor extensions, libraries and I/O addressing still differ, so some manual work is almost always needed. The PLCopen XML format (IEC 61131-10) helps when exchanging projects.

📌 In summary

Structured Text is the textual programming language of IEC 61131-3 and the natural choice for calculations, control algorithms, recipes and state machines in PLCs. With strong typing, object orientation since 2013 and a good fit with version control, ST is the language of software-defined OT. Combine it with LD, FBD or SFC where readability for technicians matters, bound every loop, and build in validation and change management in line with IEC 62443.