What does IEC 61131-3 compliant mean? Editions, statements and PLCopen

"IEC 61131-3 compliant" is a claim, not a certificate, unless a certificate is named. This article explains what the claim should contain, how to check it, and why two products that both make it can still run the same program differently. We read the public parts of the standard (contents, foreword, change lists) and PLCopen's certification pages; the clause text itself is sold, so we describe its structure and not its wording.

The short answer

A compliant product has a compliance statement: a document, or a report the tool produces, that says which language features it implements and states the choices the standard leaves to it. The third edition's contents list this as clause 5, Compliance, with Feature tables (5.2) and Implementer's compliance statement (5.3), and shows an example statement as a figure. Beyond that statement, independent certification is optional and comes from PLCopen, not IEC.

The IEC foreword to the 2013 edition says IEC provides no attestation of conformity itself and that independent certification bodies do. So "compliant" with no named tester means the vendor says so. That is not worthless: a detailed statement is checkable, and a vendor that publishes one is easier to hold to it. But read it as a claim.

The editions

Three editions matter today. What follows is what IEC and national-body pages let us verify.

That is all we state about edition 4, because the clause text is not public. Annex B of the standard is where to check whether a feature is in or out, and a vendor claiming edition 4 should point at it. Instruction List is deprecated from the third edition, which is why many statements mark it "not implemented".

What a compliance statement contains

Read a statement as three parts. The names below are ours, the structure follows the contents of the third edition.

1. Feature tables. One row per feature in the standard, usually numbered to match the standard's tables, with the vendor's answer: supported, not supported, supported with a difference.
2. Implementation-dependent parameters. The values the standard leaves open. Examples: the longest identifier, the default and maximum string length, the range of the time type, what integer overflow does, what a division by zero does, how a real is rounded to an integer, how tasks are scheduled, what a warm restart keeps. A statement that lists no values leaves you to find them by experiment.
3. Implementer's notes. Everything that does not fit a yes or no: extensions, limits, a different spelling, a feature that works only in one language.

The statement may be in the manual or generated by the programming system. What matters is that two engineers would agree on what it says.

PLCopen: the certification that exists

PLCopen is the independent body that certifies IEC 61131-3 programming systems. From its certification pages: testing is done by an audited independent laboratory (it lists ifak in Germany and the Shenyang Institute of Automation in China), the lab and applicant arrange it privately, and PLCopen issues the certification when it receives a passing report. Certification is open to PLCopen members, lasts three years and covers later versions the vendor declares compliant.

There are three levels.

• Base Level. The lowest, covering a core kernel for each language. PLCopen notes that for Structured Text it is superseded by the two higher levels.
• Conformity Level. The supplier chooses which of the 26 IEC data types the product supports, and only those are tested. PLCopen says plainly that, because the test is pass or fail, two certified products can differ in the data types they support, which can affect reuse of function blocks.
• Reusability Level. Tests exchanging functions and function blocks as plain-text Structured Text files, each with one FUNCTION_BLOCK or TYPE section. Reuse is guaranteed only for matching supported data types and standard functionality, and supplier-specific elements may have no equivalent on the receiving system.

PLCopen also lists eight checks for recognising an IEC 61131-3 programming system, from standard and derived data types to programs, functions and function blocks, local data, defined interfaces, symbolic code independent of addresses, standard languages and library, and certification by an independent tester. Only the last needs a third party. The others you can check yourself in an afternoon.

Why two compliant products still differ

Because compliance is a subset plus choices. The usual sources of difference are these.

• Vendor extensions. Pragmas, extra types, extra statements, special-purpose blocks. Allowed, and the main reason code does not move.
• Object-oriented features. Classes, methods, interfaces and properties came in with the third edition. Many compliant systems do not implement them, and many ladder-first systems never will.
• Data type widths and the types supported. Under PLCopen's conformity level the supplier picks the types. A system without LINT or LREAL cannot take a program that uses them.
• Strings. Default and maximum length, single-byte or wide characters, and in the fourth edition UTF-8 handling.
• Timers. Where a timer ticks from: the scan, a task interval, a hardware clock. A timer's resolution is a property of the system, not of TON.
• Edge cases. Overflow, rounding, division by zero, out-of-range array indexes, and whether any of them stops the controller.
• Scheduling and restarts. What runs when, whether a higher priority task can interrupt a lower one, what survives a warm restart. The standard sets a model; the implementation sets the details. The tasks and watchdog article goes through this one.

How to read a vendor's compliance table

Work through it in this order. It takes ten minutes and saves a port.

1. Find the edition it cites. A 2003 statement says nothing about references, namespaces or classes.
2. Check the languages row. "Supported" for ladder may mean the vendor's dialect. Look for SFC and FBD separately; they are often absent.
3. Read the not implemented list before the implemented one. It is shorter and it is where your code breaks.
4. Find the implementation-dependent parameters. If there are none, ask. If there are, compare each with the target you have in mind: string length, integer behaviour, time type, task rules.
5. Look for a certificate: which level, which version, which lab, which date. Three years is the validity PLCopen states.
6. Look for extensions and decide which of them your code already uses.
7. Then test. A program that depends on a corner of the standard is a test case, and it should run on both systems before you trust either statement. Ideas for how are in moving PLC code between vendors.

A worked example: LADV's own statement

The Wartens LADV virtual PLCs publish a statement at LADV-CS, and it is a fair example because it says what is missing. It opens with a sentence that matters more than any table: it is a statement by Wartens of what LADV implements, not a certification by PLCopen or any test body. LADV is a behavioural IEC 61131-3 controller in the browser for learning and for testing logic before commissioning. It is not certified, real time or safety rated, and it does not control machinery.

The languages table reads like this.

Within Structured Text, the elementary types (BOOL through LWORD, REAL, LREAL, TIME, LTIME, the date types, STRING, WSTRING, CHAR, WCHAR), enumerations, subranges, arrays, structures, the variable sections, RETAIN, direct addresses, functions, function blocks and programs, all the statements, and CONFIGURATION, RESOURCE and TASK are implemented. Not implemented: classes, methods, interfaces and properties; REF_TO and dereferencing; namespaces; and actions and SFC elements in Structured Text source. So an object-oriented third-edition program will not compile on LADV, and it will say so with a line number.

Then the implementation-dependent parameters, which are the part most statements skip. A selection:

Several of those are corners where products differ. This program shows three; run it on LADV, then run the equivalent on your target.

PROGRAM Main
VAR
  Big : INT := 32767;
  Wrapped : INT;
  Half : INT;
  Next_Half : INT;
  Chopped : INT;
END_VAR
  Wrapped := Big + 1;
  Half := REAL_TO_INT(2.5);
  Next_Half := REAL_TO_INT(3.5);
  Chopped := DINT_TO_INT(TRUNC(2.5));
END_PROGRAM

On LADV Wrapped is -32768, Half is 2, Next_Half is 4 and Chopped is 2: wrap at 16 bits, round half to even, truncate toward zero. Another system could saturate the INT, round 2.5 up to 3, or fault. None of those would necessarily make it non-compliant, as long as it says so. That is the whole point of the parameters table.

What to do with this

If you are choosing a platform, ask for the statement and read the not-implemented list against your code. If you are moving code, test the corners above on both sides. If you are teaching or learning, use a system whose statement is honest about its limits, because behaviour you learn from a simulator that silently differs from the standard is behaviour you will unlearn on a real controller. For a map of the five languages see the IEC 61131-3 languages; for the Structured Text itself, Structured Text examples has twelve programs that compile on LADV; CODESYS explained covers the most widely licensed implementation of the standard.

How we tested

On 2026-11-01 we compiled and ran the program in this article on the LADV controller model CPU 310 and checked the four values quoted. The LADV statement was read from the same source that generates the page at /vplc/docs/iec-61131-3-compliance, so the tables above match it. Every Structured Text program on this page compiles on the LADV compiler, checked automatically in the site's test suite.

Not tested or not verified: we did not read the clause text of any edition of the standard, only the public contents, foreword and national-body listings. We did not confirm PLCopen's current list of certified products, or whether any product is certified against edition 4. PLCopen's certification fee and member-only rules are as stated on its pages and may change. We did not test any other vendor's compliance statement.