1

K-ST: A Formal Executable Semantics of PLCStructured Text Language

Kun Wang, Jingyi Wang, Christopher M. Poskitt, Xiangxiang Chen, Jun Sun, and Peng Cheng

Abstract—Programmable Logic Controllers (PLCs) are responsible for automating process control in many industrial systems (e.g. inmanufacturing and public infrastructure), and thus it is critical to ensure that they operate correctly and safely. The majority of PLCs areprogrammed in languages such as Structured Text (ST). However, a lack of formal semantics makes it difficult to ascertain thecorrectness of their translators and compilers, which vary from vendor-to-vendor. In this work, we develop K-ST, a formal executablesemantics for ST in the K framework. Defined with respect to the IEC 61131-3 standard and PLC vendor manuals, K-ST is a high-levelreference semantics that can be used to evaluate the correctness and consistency of different ST implementations. We validate K-STby executing 509 ST programs extracted from Github and comparing the results against existing commercial compilers (i.e.,CODESYS, CX-Programmer, and GX Works2). We then apply K-ST to validate the implementation of the open source OpenPLCplatform, comparing the executions of several test programs to uncover five bugs and nine functional defects in the compiler.

Index Terms—Formal executable semantics, PLC programming, Structured text, K-framework, OpenPLC.

F

1 INTRODUCTION

P ROGRAMMABLE Logic Controllers (PLCs) are responsi-ble for automating process control in several modern

industrial systems, e.g. in manufacturing and public infras-tructure. It is critical to ensure that PLCs are operating cor-rectly, as any functional or security-related defects may leadto serious incidents in the system. This has most famouslybeen demonstrated by the Stuxnet worm [1], while manyother less-known safety and security incidents [2], [3], [4]and potential hazards [5], [6] related to PLCs have resultedin significant consequences, with an estimated $350,000 indamage on average [7].

The majority of PLCs are programmed using languagesdefined in the IEC 61131-3 open international standard [8].Programs can be written in graphical languages such asFunction Block Diagrams (FBD), but the standard also de-fines Structural Text (ST), a fully textual language basedon the idea of organizing code into ‘function blocks’ anddesigned with a syntax similar to Pascal. ST is a particularlyimportant IEC 61131-3 language given its utility for dataprocessing [9], and the fact that snippets of ST are actu-ally required in FBD and other graphical languages. It istherefore important that translators and compilers for ST arecorrectly implemented and exhibits only expected behavior

• K. Wang, and J. Wang are with the College of Control science andEngineering, Zhejiang University, Zhejiang 310027, China.E-mail: {kunwang yml, wangjyee}@zju.edu.cn.

• CM. Poskitt is with the School of Computing and Information Systems,Singapore Management University, Singapore.E-mail: cposkitt@smu.edu.sg.

• X. Chen is with the College of Control science and Engineering, ZhejiangUniversity, Zhejiang 310027, China.E-mail: chenxiangx@zju.edu.cn.

• J. Sun is with the School of Computing and Information Systems,Singapore Management University, Singapore.E-mail: junsun@smu.edu.sg.

• P. Cheng is with the College of Control science and Engineering, ZhejiangUniversity, Zhejiang 310027, China.E-mail: lunarheart@zju.edu.cn.

Fig. 1: High-level workflow of our approach

when the code is being run on a PLC.This has motivated a surge of research on analyzing and

verifying PLC programs [7], [10], [11], [12], [13], [14], [15],[16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27],although few work focuses on ST implementations/compil-ers. Specifically, Zhang et al. [22] propose VetPLC, a tem-poral context-aware, program-based approach to producetimed event sequences that can be used for automatic safetyvetting. McLaughlin et al. [19] propose TSV which translatesassembly-level code into an intermediate language (ILIL)to verify safety-critical code executed on PLCs. Mader andWupper [24] translate Instruction List (IL) into timed au-tomata [28]. Bauer et al. [23] similarly use timed automata asthe formalism for Sequential Function Chart (SFC). In [25],the proposed method transforms IL to Petri-nets [29], andmanually builds two additional Petri-nets for modeling thePLC and its environment. Xiong et al. [21] propose analgorithm based on variable state analysis for automaticallyextracting the behavior model (BM) from an ST program.These works attempt to transform PLC programs into anintermediate language or another programming language(i.e., C) which is suitable for verifying or detecting potentialissues using existing associated verifiers or checkers. Theissue of these approaches is that there lacks analysis and proofof equivalence in the conversion process. In addition, the anal-yses they perform are often limited (since the existing tools

arX

iv:2

202.

0407

6v1

[cs

.PL

] 8

Feb

202

2

2

are not designed for PLCs) and do not offer the feedbackto the level of source code. Canet et al. [20] propose formalsemantics for a significant fragment of the IL language, anda direct coding of this semantics into a model checkingtool. Huuck [26] develops a formal operational semanticsand abstract semantics for IL, which allows approximatingprogram simulation for a set of inputs in one simulationrun. However, IL is a low level assembly-like language thathas been deprecated from the IEC61131-3 standard.

To the best of our knowledge, a practical and completesemantics for the ST language does not exist, which makesit difficult to ascertain the correctness of ST translatorsand compilers (e.g. by comparing executions). There are anumber of reasons why such a reference semantics is yet toemerge. First, there is insufficient documentation definingor describing the complete features of the ST language [9].For instance, the official documentation introduces languagefeatures by only a few examples, based on which it isdifficult for readers to fully understand the behavior of thelanguage. Second, the ST compilers provided by differentvendors (e.g. Allen-Bradley, Siemens) can implement thelanguage differently, and their closed source solutions makeit difficult to fully assess how they behave systematically(other than through manual observation). A preliminaryattempt at defining a high-level semantics for ST was madeby Huang et al. [30]. However, it falls short of a referencesemantics as it misses several important features of thelanguage, e.g. certain data types, and key sentences.

In this work, we develop K-ST, a formal executable ref-erence semantics for ST in the K framework [31]. Our high-level semantics is both executable and machine readable,and can be used by the K framework to generate inter-preters, compilers, state-space explorers, model checkers,and deductive program verifiers. Our principal goals for thedesign of K-ST are as follows:

1) Validated reference semantics. K-ST is designedto cover all the main features of ST, and is vali-dated against hundreds of different real-world STprograms extracted from Github.

2) General and extendable. The semantics is high-level (rather than tied to a particular compiler), withthe goal of supporting different ST implementationsas well as extensions for vendor-specific functions.

3) Analyses of ST compilers. Most importantly, K-STcan be used to check the correctness and consistencyof different ST implementations, and thus ensurethat a compiler is not introducing an unintendedbehavior or compile-time threat [32], [33] into acritical industrial system.

Given the absence of complete feature descriptions forthe ST language in official documentation, we not only referto the definitions and code samples in the official docu-ments, but also extensively consult the guidance manualsprovided by multiple vendors to better define the semanticsof the ST language. For example, there is no specific docu-mentation on how integer overflow is handled in the offi-cial documents. Through investigating multiple instructionmanuals, we found that existing ST compilers generally usetruncation to handle integer overflow without any warning.The rewriting rule of the K framework provides a good

mechanism for expanding the unique features of ST. Forexample, we can rewrite REPEAT to WHILE to achieve theexecution effect of REPEAT.

We validate K-ST by extracting 567 real-world ST codesamples from Github and comparing their executions inour semantics against their executions under various com-mercial compilers (i.e., CODESYS, CX-Programmer, andGX Works2). We find that K-ST is sufficiently complete tosupport 509 of these programs (with 26,137 lines), miss-ing only vendor-specific functions and hardware-relatedfunctions that we did not formalize; and it executes thoseprograms correctly (i.e., producing the same outputs as thecorresponding existing compiler). Furthermore, to evaluatethe utility of K-ST for testing ST compilers, we comparedthe executions of the 567 programs (and several mutants)under K-ST and OpenPLC [34], a popular open source PLCprogram compiler. Through this semantics-based testing, weare able to uncover five bugs and nine functional defects inthe OpenPLC compiler, all of them are previously unknown.Fig. 1 summarises the high-level workflow of this process.

In summary, we make three main contributions.

• We propose an executable formal reference semanticsfor ST;

• We collect a set of 567 complete ST program samples,and validate the correctness of our executable seman-tics by running those programs in the semantics andin existing compilers (CODESYS, CX-Programmer,and GX Works2), comparing the results.

• We test OpenPLC, an open source PLC programcompiler, using our proposed semantics, and findfive bugs and nine functional defects.

The remaining part of this paper is organized as follows.Section 2 introduces the background of ST and the K-framework. The proposed executable operational semanticsof ST formalized in K is introduced in Section 3. Section4 shows some practical applications of formal semanticsthat we proposed. The evaluation results of the proposedsemantics are introduced in Section 5. Section 6 concludesthis work.

2 BACKGROUND

In this section, we briefly introduce the background of theStructured Text and the K-framework.

2.1 Structured TextThe Programmable Logic Controller, invented in 1969 byDick Morley, is specially designed for applications in indus-trial environments, e.g. assembly lines, robotic devices, orpublic infrastructure. These kinds of applications all requirehigh reliability and ease of programming.

Early PLCs were represented as a series of logic expres-sions in some kind of Boolean format. With the developmentof programming terminals and the complexity of existingcontrol procedures, Ladder Diagrams (LD) were developedto program PLCs. As of 1993, the IEC 61131-3 standard de-veloped by the International Electrotechnical Commission(IEC) defined five programming languages, including twotextual programming languages—ST and IL—as well asthree graphical languages—LD, Function Block Diagrams

3

Fig. 2: An ST programming example.

(FBD), and SFC. A simple example in Fig. 2 [35] shows aST code example which can be used for linear scaling of ananalog sensor signal.

ST is a high-level PLC programming language whichis similar to Pascal [36] (widely used from 1980 to 2000),C/C++ and Java. While it contains common constructsfrom modern programming languages such as FUNCTION,IF/ELSIF/ELSE and CASE branches, WHILE and FOR loops, ithas its own characteristics, such as the lack of recursion, cap-italized keywords, REPEAT statement, and FUNCTION BLOCKstructure. For instance, FUNCTION BLOCK as an importantpart of ST, has its own state. Its main purpose is to modular-ize and structure a straightforwardly defined portion of theprogram. It is analogical to the class-object manifestation inthe object oriented programming. Function blocks exist intwo forms: as a type or as an instance, but only the instancecan be called. For each function block, the local variablesretain their values between each “call”. TABLE 1 shows thecommon elements of ST.

ST as the only textual programming language supportedby new IEC standard, has a number of advantages com-pared to other PLC languages. First, ST programs can becopied relatively easily. Second, compared with the otherfour languages, it is more convenient for mathematicalcalculations, formulas and algorithms, and for managinglarge amounts of data [9]. Third, compared with 20 yearsago, PLC solutions are more in demand today and ST canbetter adapt to this change. Finally, LD, SFC and FBD also

require parts of the program to be written in ST anyway[37], [38].

Unfortunately, the absence of documents defining ordescribing the complete features of the ST language andthe implementation method customized by the vendor canlead to inconsistent implementations of ST. In addition,understanding the semantics of the ST language, and en-suring that it is formally defined is difficult for end usersaccustomed to graphical programming. A formal executablesemantics of ST not only provides a standard, but also helpsPLC engineers verify the completeness and correctness ofthese implementations.

2.2 The K Framework

K is a formal logic framework based on rewriting logic [39].It was developed with the overarching goal of pursuingthe ideal language framework, where all programming lan-guages have formal semantic definitions and all languagetools are automatically derived in a correct-by-constructionmanner at no additional cost. The K backends, such as theIsabelle theory generator, the model checker, and the de-ductive verifier, can be utilized to prove properties based onthe semantics and generated verification tools [40]. Severalexecutable semantics in K have been developed for main-stream programming languages, including C [41], Java [42],JavaScript [43], Rust [44], Solidity [45], and IMP [46].

A language semantics definition in the K consists ofthree parts: the language syntax, the configuration, and aset of semantics constructed based on the syntax and theconfiguration. Given the semantics definition for a program-ming language and some source programs, K executes theseprograms like a translator. For illustration, in the followingwe take a strict subset of the ST language, i.e., STdemo shownin Fig. 2 as an example to illustrate how to define languagesemantics in K.

Configuration. The whole configuration cell T of STdemo

contains two cells, namely k and state. The cell k is usedto store the source program $PGM for execution, and thecell state is used to record the mapping from a variableidentifier to its value. The configuration simulates the mem-ory status and environmental changes during runs of theprogram.

〈〈$PGM : Pgm〉k 〈.Map〉state〉TWith the configuration defined, we present the syntax of

STdemo in Fig. 3, which includes some numerical operations,logic operations and commonly used statements. Based onthe configuration and the syntax of STdemo, we introducesome basic rules in the semantics. The role of the semanticsis to tell K how to execute the source code, where Kexecutes the code and updates the configuration sentence-by-sentence after parsing the source program.

Here, we show the semantics of Allocate, Lookup andAssignment in Fig. 4 as they are the most commonlyused constructs in programming languages. Table 2 de-scribes some common semantic notations. Take Allocateas an example: when K runs to lines 9–13 in Fig. 2,the content in k cell is 〈VAR a : REAL; V Bs END VAR · · · 〉k,where V Bs stands for b : REAL; Error : BOOL := FALSE;.Then, K will rewrite 〈VAR a : REAL; V Bs END VAR · · · 〉k

4

TABLE 1: The common elements of ST language

Type Element Type Element Type Element

Program Organization Unit

FUNCTION BLOCK

Built-in Data Type

INTBuilt-in Data Type

ARRAY

FUNCTION DINT ...

PROGRAM SINT

Declaration Type

VAR GLOBAL

Main Statement

IF LINT VAR

CASE UINT VAR INPUT

WHILE UDINT VAR OUTPUT

FOR USINT VAR IN OUT

REPEAT ULINT VAR EXTERNAL

EXIT REAL VAR TEMP

RETURN LREAL AT

... BOOL RETAIN

User Data TypeENUM STRING PERSISTENT

STRUCT WSTRING CONSTANT

Built-in Data TypeTIME TIME OF DAY ...

DATE DATE AND TIME ...

Fig. 3: The syntax of STdemo.

to 〈VAR V Bs END VAR · · · 〉k, which means that a : REAL;has been executed according to rule Variable Allocate.Meanwhile, it adds the mapping between the variable nameand the corresponding value (a 7→ 0.0) in the current statecell Rho. Besides, “requires notBool (X in keys (Rho))”guarantees that the variable will not be re-declared.Similarly, variables b and Error will be allocatedseparately. After that, the content in the k cell is〈VAR .V arBodys END VAR · · · 〉k, where .V arBodys rep-resents an empty variable declaration list, that is,no additional variable needs to be allocated. Therule Variable Finish Allocate will be called to convert“VAR .V arBodys END VAR” in k to “.”, which means thatthere is no more code to execute in the VAR block and K

Fig. 4: The partial semantics of STdemo.

will continue to execute the subsequent code.

3 FORMAL SEMANTICS OF STRUCTURED TEXT INTHE K-FRAMEWORK

In this section, we introduce K-ST, the executable opera-tional semantics of ST formalized in K. Note that in practicethe PLC programming environment is provided by specificPLC manufacturers including Codesys and Siemens’s TIAportal (TIA, Structured Control Language (SCL)). As a con-sequence, the implementations of different manufacturersmay be different and may include their own unique func-tions or structures.

Our approach is therefore to focus on the common fea-tures, allowing other unique functions of the environment

5

TABLE 2: Summary of semantic notations.

Notation Description

rule The beginning of a semantic rule.

a requires b Execute a when b is true.⟨ab

⟩k

〈〉k stands for k cell in configuration.ab

means a will be rewritten by b.

〈· · · a · · · 〉 · · · represents the content in the a context.

. . stands for empty.

Any value.

a : b Variable a is type b.

a 7→ b, a← b Mapping from a to b.

a y b The execution of a, followed by execution of b.

a⇒ b Similar to ab

, it can only be used outside 〈〉.

to be implemented by extending the operational seman-tics. Specifically, the syntax of ST is constructed based onthe official IEC 61131-3 standard [38]. The configuration isspecifically designed for ST. Based on the syntax and theconfiguration, we then formalize the semantic rules for thelanguage features with rewriting logic. Next, we presenteach component of the semantic one by one.

3.1 The Syntax of STTABLE 3 presents the syntax of ST defined in K-ST, whichcovers most of the core syntax. We remark that TABLE 3only contains the main part of K-ST while omitting oth-ers, e.g., some built-in functions (LEN, DELETE and so on)for space reason. The syntax is described by a dialect ofExtended Backus-Naur Form (EBNF) [47] according to thegrammar of ST, where ∗ means zero or more repetitions.In the ST, the top grammatical structures mainly includesuser-defined type – TYPE statements and three ProgramOrganization Units (POUs) - FUNCTION, FUNCTION BLOCKand PROGRAM. The other parts are included in the top gram-matical structures.

3.2 The Configuration of STThe execution of an ST programs need to update the follow-ing kinds of state: data segment, code segment and stack.Among them, the data segment is used to store global vari-ables, the code segment is used to store program executioncode, and the stack is used to store local variables of theprogram. Note that running environment switching causedby function calls is also achieved by the operation of stack.The overall runtime configuration of ST in K is presented inFig. 5. We highlight our careful design choices as follows.

Overview. There are 11 main cells in the configurationT , i.e., k, control, allenv, genv, gvenv, store, type, constantinput, output and nextLoc. The value of each cell is initial-ized according to its specified type. For instance, for cellswith a mapping relationship, their values are initialized toMap type, and for cells that store a collection, they areinitialized to List type. A ‘.’ followed by any type meansan empty set of this type. For instance, .Map in the cellgenv represents that genv is initialized with an empty map.

Enumeration type. By default, when an enumerationtype is defined in ST, PLC compilers will automaticallyassociate a number (indexed from 0 and added by 1 eachtime) to each variable in the enumeration. For repeateddeclarations, we use count cell to record the value of thecurrent enumeration.

Global variables. There are two types of global variables.One is the POUs and customized types that users define.These variables can be accessed anywhere in the program.We store these variables in genv cell as the basis for programoperation. The other is the variables defined in VAR GLOBAL.These variables cannot be directly accessed in the programunless they are declared with VAR EXTERNAL. We store thesevariables in gvenv cell and provide them on demand.

Program execution. The source code parsed by the syn-tax SourceUnit, called $PGM , are stored in the cell k forexecution. Then the $PGM will be executed unit by unit.If the program terminates normally, there will be a ‘.’ inthe k cell, denoting that no more unit needs to be executed.In the preprocessing phase (the first pass of K), the k cellonly contains the token execute. Afterwards, K will startexecuting from the MAIN program.

Stack operations. The cell control contains sevensubcells—fstack, env, temp, count, gvid, print and break—which record the operating environment of the currentlyrunning code segment. Specifically, the function stackfstack is a list used to store the environment before ex-ecuting other POUs, including variables in the currentenvironment and subsequent program. After that, the cellenv is to store the mapping relationship between variablesand indexes in the current environment during programexecution. Besides, cells temp and count are used in ENUMand STRUCT, where temp is for temporary mapping andcount is used as a counting pointer. The cell gvid is to recordall identifiers of global variables to assist the generation ofglobal variables. The cell print is to record variables whichneed to be output. Finally, break stores the program afterthe loop in order to support the implementation of the EXITstatement in FOR, WHILE and REPEAT loops.

Execution environment. The allenv cell is to cache theexecution environment before function calls (for strict typechecking of parameter passing in function calls1). The cellgenv is to record the result of the pre-processing (includingPOUs and custom types) and will be copied to env whenenv is refreshed. The last cell related to the environment iscalled gvenv and is used to index global variables.

Memory operation. The store cell is used to simulatememory to record the mapping relationships of indexesand variables values. After that, the cells input and outputare used to realize external inputs and external outputrespectively. And the last cell nextLoc ensures that the indexof variable can always be incremented without duplication.The design consideration behind is that for complex lan-guages, it is more effective to explicitly manage arbitrarilylarge memory than use garbage collection [48].

3.3 Semantics of the Core FeaturesWe implement the executable semantics covering most corefeatures of ST and leave the vendor-specific functionalities

1. This is optional but recommended for ST compilers.

6

TABLE 3: The syntax of ST

Syntax Description

Id ::= [a− zA− z ] [a− zA− Z0− 9 ]∗

Ids ::= Id∗

IdV al ::= Id := Expression

Identifier

EnumStructDeclaration ::= TY PE EnumDeclarationExp∗ END TY PE

| TY PE StructDeclarationExp∗ END TY PE

EnumBlock ::= Ids | IdV al∗

EnumDeclarationExp ::= Id : (EnumBlock) ; | Id : (EnumBlock) := Id;

StructDeclarationExp ::= Id : STRUCT V arDeclarationExp∗ END STRUCT

Enum and Struct declaration

Function ::= FUNCTION Id : Type V arDeclaration∗ Statements END FUNCTION Function declaration

FunctionBlock ::= FUNCTION BLOCK Id V arDeclaration∗ Statements END FUNCTION Function block declaration

Program ::= PROGRAM Id V arDeclaration∗ Statements END PROGRAM Program declaration

Type ::= INT |DINT |SINT |LINT |UINT |UDINT |USINT |ULINT |BY TE|WORD|DWORD|REAL

|LREAL|STRING|STRING [Expression] |WSTRING|WSTRING [Expression] |TIME|DATE

|TIME OF DAY |DATE AND TIME|Id|ARRAY [Expression] OF Type

Variable types

V arType ::= V AR GLOBAL | V AR | V AR INPUT | V AR OUTPUT | V AR IN OUT | V AR TEMP

V arDeclarationExp ::= Ids : Type; | Ids : Type := Expression;

V arDeclaration ::= V arType V arDeclaration END V AR

Variable declaration

Operation ::= + | − | ∗ | / | ∗ ∗ |MOD | < | > | = | <= | >= | <> | AND | &| AND THEN | XOR | OR | OR ELSE | ..Expression ::= Int | Float | String | Bool | Bit | AllT ime | Id | Expression Operation Expression

Expression (Expressions) | Expression.Expression | Expression [Expressions] | (Expression)

Expressions ::= Expression∗

Expressions

Assignment ::= Expression := Expression; Assignment statement

ElseIfBlock ::= ELSE Statements | ELSE IF Expression THEN Statements ElseIfBlock∗

If ::= IF Expression THEN Statements ElseIfBlock∗ END IF ;

CaseBlock ::= Expression : Statements | Expression .. Expression : Statements

Case ::= CASE Expression OF CaseBlock∗ END CASE;

| CASE Expression OF CaseBlock∗ ELSE Statements END CASE;

Branch statements

While ::= WHILE Expression DO Statements END WHILE;

For ::= FOR Expression TO Expression DO Statements END FOR;

| FOR Expression TO Expression BY Expression DO Statements END FOR;

Repeat ::= REPEAT Statements UNTIL Expression END REPEAT ;

Loop statements

Return ::= RETURN ; Return statement

Exit ::= EXIT ; Exit statement

Statement ::= Expression; | Assignment | If | Case |While | For | Repeat | Return | Exit

Statements ::= Statement∗Statements

as potential extensions. For example, some compilers woulduse additional keywords to distinguish the declaration partand the execution part of the program. In the following,we provide an overview of four core semantic features ofST, including 1) data types, 2) main control statements, 3)declarations and calls of POUs and 4) memory operations.Before diving into the details, we present the notations asfollows. The rule symbol represents the beginning of asemantic rule. The symbol ⇒ means “rewritten by”, forinstance A⇒ B denotes that A can be replaced by B.

3.3.1 Extended Data Types

The K framework supports diverse data types includingidentifiers (Id), integers (Int), bools (Bool), floats (Float)and strings (String), etc, which cover most of the require-ments. However, there are still some unsupported datatypes needing additional implementation in K-ST, which wecall extended data types. These extended data types can becategorized into two kinds: 1) elementary types (TIME, BYTE,WORD, DWORD, TIME OF DAY, DATE and DATE AND TIME) and2) compound types (ENUM and STRUCT). We implement theseextended data types by the composition of built-in types andmethods in K as follows.

7

Fig. 5: The runtime configuration of ST in K

Fig. 6: Implementation of TIME OF DAY in K.

We take TIME OF DAY as an example to introduce the re-alization of extending elementary types. There are two typesof TIME OF DAY in ST, e.g., TIME OF DAY#23 : 45 : 56.30and TOD#23 : 45 : 56.30. Fig. 6 shows our implementationof TIME OF DAY type together with its relevant operations.Line 1 and 2 defines the syntax of TIME OF DAY and howto parse it (Get TIME OF DAY) respectively. Line 3 is usedto convert Get TIME OF DAY to TIME OF DAY, which isachieved by two steps—Gtd2Td and Standardization—where Gtd2Td realizes the conversion of the format andStandardization realizes content conversion, e.g., replacing60 minutes with 1 hour. Lines 4–11 define some arithmeticand relational operations of TIME OF DAY.

For compound types, we take STRUCT as an exam-ple and show its semantics in Fig. 7 including STRUCTdeclaration and instantiation. Declarations are shown inrule Struct Declaration, where we allocate memory for

Fig. 7: The partial semantics of STRUCT in K.

each defined data structure. The instantiation of STRUCTconsists of four main steps: 1) rule Struct Instantiation:CreatStruct allocates memory for I1, 2) StructInits gener-ates each variable in turn according to V ds in STRUCT, 3) Setassigns values to the corresponding variables according toIdvs, and finally, 4) Update stores the mapping relationshipof variables related to I1 into the memory of I1 to facilitatesubsequent use.

8

Fig. 8: The partial semantics of main control statements.

3.3.2 Main Control StatementsControl statements are important in ST for achieving com-plex program logic (as in most other programming lan-guages). We show the rules for CASE, REPEAT and EXIT inFig. 8 (as the semantics of IF, WHILE and FOR are typical).A CASE statement can be rewritten as a combination ofan IF and CASE through rule Case. The rule REPEATis implemented as follows. We first store the subsequentstatements outside the loop (recorded as K) in cell break todeal with the EXIT statement that may appear, and thenrewrite it into the form of WHILE for further execution.During the execution of the loop body, once EXIT is exe-cuted, all the statements in the current cell k are discardedand rewritten to K (storing the subsequent statements), asshown in rule Exit.

3.3.3 The Declaration and Call of POUsIn ST programs, statements are inside Program Organi-zation Units (POUs), i.e., FUNCTION, FUNCTION BLOCK orPROGRAM. A FUNCTION is a stateless POU type, comparingto a FUNCTION BLOCK which stores its own state after execu-tion. The design of FUNCTION BLOCK is to similar to a classobject in the object-oriented programming (OOP) for bettermodularization. FUNCTION BLOCKs exist in two forms: as atype or as an instance, and only the instance can be called.For FUNCTION BLOCK instance, the local variables retaintheir values between each “call”. PROGRAMs are defined bythe IEC 61131-3 standard as a “logical assembly of all theprogramming language elements and constructs necessaryfor the intended signal processing required for the control ofa machine or process by a PLC-system” [38]. Due to spacelimit, we show the declaration, call and return operationof FUNCTION BLOCKs in Fig. 9 as an example for illustration(FUNCTION and PROGRAM are shown in Fig. 10 and explainedonly when necessary).

Declaration. The declaration of FUNCTION BLOCKis similar to the STRUCT. As shown inrule Function Block Declaration, we first assign an

Fig. 9: The partial semantics of FUNCTION BLOCK.

index in memory for FUNCTION BLOCK X , set the type to thebuilt-in FunctionBlock, and convert the entire declarationstatement to the built-in type funblambde(X, void, V ds, S)for storage, where void means no return value, V ds and Sare variable declarations and operations in X respectively.The purpose of setting const to true is to prevent it frombeing modified. Note that FUNCTION and PROGRAM set typeand store to Function, funblambde(X,T, V ds, S) and

9

Program, plambde(X, void, V ds, S, .Map).Instantiation. The instantiation of FUNCTION BLOCK

is achieved through variable declarations, as shownin rule Function Block Instantiation. However, thevalue is set to runfunblambde(X, void, V ds, S, .Map) todistinguish it from funblambde and .Map is designed tostore the FUNCTION BLOCK environment for next call andexternal query. This is because a FUNCTION BLOCK can onlybe called after instantiation, i.e., runfunblambda can beexecuted but funblambda can not. Since FUNCTION andPROGRAM have no such restrictions, funlambde and plambdacan be directly called and executed.

Call. There are two cases when a FUNCTION BLOCKis called. The first case is that the FUNCTION BLOCKis called for the first time, as shown inrule Function Block Call First. Since there is noinitial environment (the last value of runfunblambda is.Map), we will first store the current execution environmentinfo in fstack, including subsequent statements K , theAllenv of the current environment, and the parametersC in cell control. Then we reset parameters C throughrenew. After that, K executes the variable declaration V ds(including index application, initialization and assignment)and statements S in the function block. Besides, Updateis used to update the .Map in runfunblambde to recordthe current environment. Finally, RETURN can return tothe calling program and configure the correspondingenvironment. In other cases (not called for the first time),as shown in rule Function Block Call Others, there isalready a mapping relationship between related variablesand values in cell store and the mapping relationshipbetween identifiers and indexes is also stored in therunfunblambde. Therefore, no new memory allocation willbe made during the execution process and the existingenvironment will be used. Note that the value of thevariable in the FUNCTION BLOCK will not be initialized,which means that the execution result for the same inputmay be different.

Regardless of whether RETURN appears in theFUNCTION BLOCKk, we add a RETURN by default for eachFUNCTION BLOCK as a sign that the FUNCTION BLOCK hasfinished running and returned to the calling POUs. SinceFUNCTION BLOCKs and PROGRAMs do not have a return value,we set null as the return value. Note that a FUNCTIONhas a return value, and the returned value is the valuecorresponding to the function identifier, so we need touse ClearEnv to clean up the memory environment corre-sponding to the function identifier after calling procedurerenew and add the declaration of the function identifiervariable in V ds.

3.3.4 Memory OperationsHere, we present the rules for memory operations on ele-mentary types in ST, such as built-in types and extendedelementary types. What elementary types have in commonis that they take only one memory slot. For complex types,such as enums, structs, arrays, etc, which are compositionsof elementary types, the memory operation can be regardedas a set of memory operations on elementary types. Forinstance, the assignment to struct can be equivalent to assignvalue for each variable of this struct.

Fig. 10: The partial semantics of FUNCTION and PROGRAM.

Similar to STdemo, main memory operations of ST arestill composed of allocation, lookup, assignment and addi-tional clearenv. Where allocation implements the allocationof memory for variables in the store, lookup is used tofind variable values in store cell, assignment implementsthe assignment of variables, and clearenv implements therecovery of memory in the store. However, because thecomplete ST semantics has a more complex type design,they will involve more cells in configuration, and are morecomplicated, as shown in Fig. 11.

Note that HOLE is just a variable, but it has specialmeaning in the context of sentences with the “heat” or“cool” attribute. In short, “heat” is to lookup the corre-sponding content of the HOLE in the formula, and “cool”

10

Fig. 11: The partial semantics of memory operations.

is to put the recheck results back into the formula. Forexample, in expression a+ b where a is represented HOLE,“heat” is to take a out of the formula and find its corre-sponding value. If it is 3, and “cool” puts 3 back into theoriginal formula, at the formula becomes 3 + b.

Let us start with the assignment operation (we omitlookup as it is straightforward). The assignment ofST divides the assignment of STdemo into two steps,where context and rule Find Index are used to deter-mine the index L of the assigned variable X in store,rule Assignment implements the update of the storeat index L. The purpose of this division is to make theassignment operation better applicable to complex types,because in some cases the index of the assigned variable cannot be directly obtained and multiple queries are required.For instance, when assigning a value to A [3, 5, 7], where Ais a multi-dimensional array, we need to look up one byone dimension to finally determine the index. In addition,we refer to the state of X in type and constant duringthe assignment process. On the one hand, we use Limit toensure that the assigned value meets the type requirements,and on the other hand, we ensure that the variable can beassigned through the value in constant, that is, this variableis not a constant. Although the memory cleaning operationis not necessary for ST in K, a simple clearenv operationcan effectively reduce repetitive code and improve codereadability. For rule clearenv, what needs attention is theoperation on cell env, it replaces the index L of variable Xwith undef which means null in the map supported by K.

Fig. 12: The partial semantics of variables declaration.

ST has relatively complex and strict type definition,therefore the rule Allocation of ST involves more cells andoperations, such as type and constant for storing variabletypes and whether they are constants, where Undefinedis used to generate the default of the specified type. Inaddition, according to the content in TABLE 1, not onlyVAR will be used in the variable declaration process, butalso other keywords, such as VAR INPUT, VAR IN OUT, etc.In order to reduce the complexity of the code, we alsoimplement these declarations through VAR declaration. Forinstance, Fig. 12 shows the implementation of VAR GLOBALand CONSTANT. We realize regional change (from env cell togvenv cell) through letogv, and SetConstant realizes themodification of the value in const cell. Remark that, K-STcovers 259 core features with 876 rules in total and 2315lines of K code.

4 TESTING AND ANALYSING ST COMPILERS

In addition to providing formal references for defined lan-guages, our formal semantics also has several applicationsthat use language-independent tools provided by K, such asstate space exploration, model checking, symbol executionand deductive program validation. We omit demonstrationof these applications in this paper since they have beenwell illustrated in related works [43], [44]. In this work, weintroduce the testing of ST implementation/compiler basedon executable semantics K-ST.

As discussed earlier, because ST compilers are typicallyprovided by vendors, the execution behavior of compilersmay be different, and may even be inconsistent with respectto the high-level semantics [49]. One of the main applica-tions of the proposed semantics is to define the correct andsecure ‘reference’ execution behavior of ST, which can helpprogrammer detect bugs in existing ST compilers.

To explore this application (and given the closed natureof commercial compilers), we choose OpenPLC2 as our testobject, which is open source and supports ST programming.Our overall workflow of our testing approach is depictedin Fig. 13. It includes three parts: program variation, pro-gram execution and result comparison. First, seed programsare mutated is to improve the diversity of test samples.Program execution uses the mutated program as input torun OpenPLC and executable semantics respectively, andthe result comparison is to compare the consistency of thetwo running results. It should be noted that we use a policysimilar to [50], that is, the program does not need input,

2. https://www.openplcproject.com/

11

Fig. 13: Overview of the test process.

TABLE 4: The measure of consistency.

The result of K-ST

Successful

execution(Q)

Unusual

termination(I)

Successful Q = Q′ "%

The result execution(Q′) Q 6= Q′ %

of OpenPLC Unusual%

I = I′ "

termination(I′) I 6= I′ %

and the category of result consistency comparison includesthe values of all variables in the program. TABLE 4 showsthe measure of consistency, where Q and Q′ represent thevalues of each variable after the program executes, I and I ′

represent the commands corresponding to the exception ter-mination, "and %represent consistency and inconsistencyrespectively. Specifically, unless K-ST and OpenPLC success-fully execute the program and the result is exactly the sameor terminated abnormally due to the same statement, theperformance of both is considered to be inconsistent.

In order to better mutate seed programs to improvethe diversity of test samples, we propose specific mutationoperations in TABLE 5 to generate mutated test samples.These mutation operations can enrich the test samples whileminimizing program errors. Our method for generatingmutant ST programs is shown in Algorithm 1. Given an STprogram Si, the algorithm makes a copy, assigns randomlyinitial values to all variables at the time of declaration, andapplies some applicable mutation operators to randomlyselected lines in the program. The test is done by comparingresults of these samples on K-ST and OpenPLC. It shouldbe noted that the correct program and the error program inthe test sample are meaningful for checking the consistencyof execution behavior. Because K-ST and OpenPLC reporterrors to a program at the same time also belong to thecategory of consistency verification. In addition, consideringthe lag of OpenPLC updates, we also tested it on the latest

TABLE 5: Mutation operations

Mutation Operation Example

Variable Random Assignment a : INT ; a : INT := 3527;

Scalar Variable Replacement a := b; a := c | 30;Arithmetic Operator Replacement a+ b a− b

Arithmetic Operator Insertion a+ b a+ b− c

Arithmetic Operator Deletion a+ b− c a+ b

Relational Operator Replacement a > b a <= b

Logical Connector Replacement a AND b a OR b

Logical Connector Insertion a AND b a AND b OR c

Logical Connector Deletion a AND b OR c a AND b

“NOT” Mutation NOT a a | a NOT a

Statement Insertion IF · · ·END IF ;

Statement Deletion EXIT ;

Beremiz3 which uses the same underlying implementation(MATIEC 4) as OpenPLC. The specific results of the test areshown in Section 5.

5 EVALUATION

In order to evaluate the semantics of ST which definedin K, we deployed K-ST on the K version 5.1.11 (Intel(R)Core(TM) i7-9750H CPU @ 2.60GHz). In the following, wedesign multiple experiments to systematically answer thefollowing research questions (RQs).

• RQ1: How much of the ST language is the K-ST cover-ing? Completeness of the semantics is an importantindicator to measure executable formal semantics.The lack of key semantics will seriously affect theusefulness of formal semantics.

3. https://beremiz.org/4. https://github.com/thiagoralves/OpenPLC Editor/tree/master/matiec

12

• RQ2: Is K-ST correct? Semantic correctness is thebasis for ensuring the usability of executable formalsemantics, so we need to analyze the correctness offormal semantics implemented.

• RQ3: Can K-ST be used to discover bugs in the compiler?This is important since an important application ofexecutable formal semantics is to identify compilerbugs.

5.1 Test Setting

For the purpose of evaluating the coverage and the correct-ness of K-ST, the test data set that we used comes fromGitHub. We searched 4853 programs in GitHub throughkeywords in the ST language. Then we screened thesesamples. We first automatically screen out samples contain-ing other programming languages (2516) and XML forms(1542). After that, we manually splice the remaining pro-grams and remove samples that lack the components re-quired for operation (such as POUs). After screening, 567complete programs written in pure ST formed our test set. Inother words, these 567 samples contain all the componentsrequired for operation and do not use other languages, suchas C, and Python.

With the aim of testing the correctness of the execu-tion behavior of OpenPLC comprehensively, we use twosample sets, including test samples collected from Github(Github set) and test samples obtained through mutation(Mutated set). The Github set is the sample set with 567 testsamples mentioned before. The Mutation set is generatedby Algorithm 1. We selected 30 high-quality samples fromGithub set as initial mutant seeds. These 30 samples containall the key features of ST. Then three rounds of iterativemutation are carried out through Algorithm 1. Each roundof iteration produces 10 mutation samples per seed. Exceptfor the initial seed used in the first round, the seeds of each

round of mutation are the result of the previous round ofmutation. We get a set containing 33,330 mutation samples.

5.2 Experiment Result and Analyses5.2.1 Semantic completeness (RQ1)We executed K-ST on 567 test samples collected fromGithub. Among these 567 test samples, K-ST supports theexecution of 509 of them. For these 509 tests which K-ST cansupport, Fig. 14 lists the number of tests for some importantfeatures which showed in TABLE 1 used in the evaluation.Specially speaking, there are six kinds of features, namelyFUNCTION, FUNCTION BLOCK, PROGRAM, Declaration types,Date types and Statements. For Declaration types,we list the number of tests for CONSTANT, VAR GLOBAL,VAR, VAR INPUT, VAR OUTPUT, VAR IN OUT, VAR TEMP andVAR EXTERNAL. For Data types, we list the number of testsfor elementary types – signed integer (INT, DINT, SINT,LINT), unsigned integer (UINT, UDINT, USINT, ULINT), float(REAL, LREAL), boolean (BOOL), byte (BYTE, WORD, DWORD),string (STRING, WSTRING), time (TIME, DATE, TIME OF DAY,DATE AND TIME), compound type – enum (ENUM) and struct(STRUCT) and array type – ARRAY. For Statements, we listthe number of tests for main control statements – IF, CASE,FOR, WHILE, REPEAT, EXIT and RETURN.

As indicated in Fig. 14, compared with the FUNCTION,the FUNCTION BLOCK is more favored by programmers(the PROGRAM is necessary for ST program operation).For Declaration types, the most used is the VAR (witha ratio of 470/509), followed by VAR INPUT (386/509),VAR OUTPUT (360/509) and VAR IN OUT (313/509). Amongall the Data types, BOOL is the most used, followed byunsigned integer and ARRAY varied slightly, constitutingwith 322/509 and 311/509, respectively. For the Data types,BOOL is the most common type. In addition, we must remarkthat we do not count the type of array members. At last, IFis the most common statement in all the tests considered.This is also in line with the main working scenarios of PLC.

Remark that, we do not consider the vendor-basedfunctions. Because these functions vary not only fromvendor to vendor, but even from product to product.In particular, Mitsubishi PLC provides completely dif-ferent data types, including Bit, Word[Signed/Unsigned],Double Word[Signed/Unsigned], Bit STRING[16-bit/32-bit], FLOAT, STRING[32] and Time. Siemens PLC supportskeyword BEGIN to represent the end of variable declarationand the beginning of operation instructions. In addition,there are also obvious differences between different prod-ucts of the same vendor. For example, the S7-1500 and theS7-1200 of Siemens support different type conversion meth-ods 5. Where the S7-1500 only provides explicit conversionsof types, and the S7-1200 provides both explicit and implicitconversions.duiy

5.2.2 Semantics Correctness (RQ2)On the other hand, in order to evaluate the correctness ofK-ST, we compared the running results of K-ST with thoseof vendor compilers CODESYS, CX-Programmer and GX

5. https://support.industry.siemens.com/dl/dl-media/272/109742272/att 918238/v6/93516999691/zh-CHS/index.html#ae443583b99950f7cca0d7237fe81ad4

13

Fig. 14: Number of tests for each features in the ST.

Works2 respectively. We consider the proposed semantics iscorrect if the execution behaviors of K-ST are consistent withthe ones of the CODESYS, CX-Programmer and GX Works2compilers. We list the coverage of the K-ST semantics inTABLE 6 from the perspective of each feature specified bythe official ST documentation, where FC, C and N mean“Fully Covered and Consistent with Compilers”, “Coveredand Consistent with Compilers” and “Not Covered”, re-spectively.

From TABLE 6, we can see clear that for POUs, we fullycover the declaration and call. In variable declarations, ATis related to input and output. We remark, however, thatthe storage mode of variables in K is very different fromthat in real PLCs, so we just support simple computer-sideinput and output. In addition, RETAIN and PERSISTENT arerelated to the actual situation in the PLC, so they are notimplemented. For instance, AT is used to bind the actualpoint of the PLC, RETAIN and PERSISTENT support thepreserve of variable value after a power failure or powerloss. The Array is the only one which be covered but notfully covered in all data types. Limited by the realization ofarrays, it is temporarily impossible to achieve the array forenum and struct, and to assign values to multi-dimensionalarrays as a whole. In statements, ⇒ has been used in theK and can be replaced by :=. For built-in functions, weshow a list which we supported, including 30 numericalfunctions, 9 logical functions, 9 string functions and 160translate function.

In the process of comparing with CODESYS, CX-Programmer and GX Works2, the following points need tobe explained. Firstly, due to the closed nature of these com-pilers, they cannot be simply called, so we have to manuallyfill the code in the specified way into the compiler to compile

and run, and compare the results, which is laborious andtedious work. This also hinders us from testing these com-mercial compilers in an extensively large scale. After that,different vendors have obvious differences in the implemen-tation of compilers, so the source code needs to be adaptedto a certain extent. For example, only 10 basic data types Bit,Word[Signed/Unsigned], Double Word[Signed/Unsigned],Bit STRING[16-bit/32-bit], FLOAT, STRING[32] and Timeare provided in the GX Works2 compiler, so we need toadapt the variable types of the source program.

5.2.3 The Result of Testing for OpenPLC (RQ3)We execute OpenPLC and K-ST with Github set and Mu-tation set as input. The execution results of the two datasets are shown in TABLE 7. Where KpOf is the number ofprograms that K-ST can be executed normally and OpenPLCcannot compile and run; KfOp is the number of programsthat K-ST cannot run normally, and OpenPLC can executenormally.

For the Github set, K-ST supports 509 of them, andOpenPLC supports 490. Through analysis, we found that thereason for this phenomenon is that OpenPLC has some func-tional deficiencies. For example, OpenPLC does not supportthe initialization of variables using formulas at the timeof declaration; numerical calculations of BYTE, WORD, DWORDtypes are not supported, etc.

For the Mutation set, there is a big difference betweenthe execution results of K-ST and OpenPLC. First of all,we filter 2271 timeout programs that timed out both inOpenPLC and K-ST with 10 seconds as the time limit. Afterthat, we manually analyzed these samples with inconsistentresults to determine the causes. For the large KpOf value,functional deficiencies remain the main reason. We do find

14

TABLE 6: Coverage of the proposed ST semantics

Feature Coverage Feature Coverage Feature Coverage

POUs(core) Data types(core) Enum instantiation FC

POUs declaration SINT FC Struct

FUNCTION FC INT FC Struct declaration FC

FUNCTION BLOCK FC DINT FC Struct instantiation FC

PROGRAM FC LINT FC Function block

POUs calls USINT FC Function block instantiation FC

FUNCTION FC UINT FC Array

FUNCTION BLOCK FC UDINT FC One− dimensional array C

PROGRAM FC ULINT FC Multi− dimensional array C

Variable Declaration(core) REAL FC Statements(core)

CONSTANT FC LREAL FC Assignment statement

V AR GLOBAL FC BOOL FC := FC

V AR FC BY TE FC ⇒ N

V AR INPUT FC WORD FC Branch statement

V AR OUTPUT FC DWORD FC IF FC

V AR IN OUT FC STRING FC CASE FC

V AR EXTERNAL FC WSTRING FC Loop statement

V AR TEMP FC TIME FC WHILE FC

AT C DATE FC FOR FC

RETAIN N TIME OF DAY FC REPEAT FC

PERSISTENT N DATE AND TIME FC Break statement

Typed constant Enum RETURN FC

Type # Data FC Enum declaration FC EXIT FC

Built− in function

Numerical function (30)

ADD, SUB, MUL, SQR, INC, DEC, MAX , MIN , MUX , ABS, SQRT , TRUNC, FRAC, FLOOR, LN , LOG, EXP , SIN

COS, TAN , COS, TAN ASIN , ACOS, ATAN , NEG, EXPT , DIV , MOD, LIMIT

Logical function (9)

GT , LT , GE, LE, EQ, NE, AND, OR, SEL

String function (9)

CONCAT , INSERT , DELETE, REPLACE, FIND, LEN , LEFT , RIGHT , MID

Translate function (160)

� FC: Fully Covered and Consistent with Compilers (256/262) � C: Covered and Consistent with Compilers (3/262) � N: Not Covered (3/262)

TABLE 7: The results of K-ST and OpenPLC.

Data Set Github Set Mutation Set

Number of samples 567 31059 (2271)

Number of program K-ST 509 15850

run completely OpenPLC 490 11581

Inconsistent

KpOf 30 5664

KfOp 11 1395

Different Result 0 735

an interesting bug of OpenPLC. The bug is a “VAR” parsingexception in OpenPLC. If the first operation instructionstarts with “VAR”, such as “VAR0 := 1;”, OpenPLC ter-minates abnormally. The interesting phenomenon is whenan error statement appears in the unexecuted part of the

program, such as after the ”RETURN;”, K-ST can provide theexecution of the program, while OpenPLC cannot. The mainreason for this phenomenon is that K adopts an operation-based detection mechanism. Because the error code will notbe executed, it will not lead to the termination of executablesemantics. The case study is shown in APPENDIX A.

After that, by analyzing those programs that have differ-ent results on K-ST and OpenPLC, we find that the reasonsfor the different results are mainly due to the differencesin underlying implementations between K and OpenPLC.For example, for integer mode operation −7 MOD 3, therunning result of K-ST is −1, and the running result ofOpenPLC is 2. From a mathematical point of view, bothresults are correct, but they will have a completely differ-ent impact on the following operations. Then we run theprogram again in CODESYS, and the results of CODESYSare the same as K-ST.

15

TABLE 8: The bugs and functional deficiencies of OpenPLC

Type Problem Description

Bug

“VAR” parsing exception The first operation instruction starts with “VAR”, and OpenPLC terminates abnormally.

Division by zero OpenPLC can check explicit division 0 but allow the execution of implicit division 0.

Overflow access OpenPLC can check explicit overflow access but allow the execution of implicit overflow access.

MOD by zero OpenPLC provides MOD 0 operation, and the result is 0.

MOD Exception The divisor of MOD operation can be empty.

Functional

deficiencies

Numerical

calculation defects

OpenPLC does not support normal numerical calculation ∗∗.Numerical calculations of BYTE, WORD, DWORD types are not supported.

Array functions defects Parentheses are not allowed in array assignments.

FUNCTION BLOCK

instantiation defectsMultiple instantiation of function blocks in one statement is not allowed.

ENUM defects OpenPLC does not support normal assignment of ENUM type.

Variable

declaration defects

Some non-keyword strings cannot be used as variable names, such as “ramp”, “LocalVar0 ”, etc.

OpenPLC can not support formula and other variables previously declared as initial value.

Structural defectsWithout operation or variable declarations, OpenPLC cannot compile ST program.

Without statements in FOR, WHILE, IF, CASE, REPEAT, OpenPLC cannot compile ST.

For those samples that K-ST cannot run normally, butOpenPLC can execute normally, our analysis found somebugs in OpenPLC, which cause some error programs can beexecuted in OpenPLC. For example, OpenPLC can checkexplicit division 0 operations but allow the execution ofimplicit division 0 operations. TABLE 8 details all functionaldeficiencies and bugs we found in OpenPLC. We showsome relevant case studies in APPENDIX B. Consideringthat Beremiz can be regarded as an updated version ofOpenPLC, we have retested the inconsistencies we found inBeremiz. We found that in the latest Beremiz, it fixes someproblems, including negative MOD operation results and“VAR” parsing exceptions. But other bugs and shortcomingsstill exist. So in response to these problems in OpenPLC, wehave submitted them to OpenPLC and Beremiz developersand are waiting for their confirmation 6.

6 RELATED WORK

In this section, we discuss some other PLC program analysistechniques, summarize their characteristics, and distinguishthem from our work.

Keliris et al. [17] propose a framework (ICSREF) whichcan automate the reverse engineering process for PLC bina-ries. They instantiate ICSREF modules for reversing binariescompiled with CODESYS and getting the complete ControlFlow Graph (CFG). And they provide an end-to-end casestudy of dynamic payload generation and attack deploy-ment. Tychalas et al. [7] analyze the binary files generatedby all control system programming languages in CODESYSto understand the differences and even the vulnerabilitiesintroduced during the program compilation process. Andbased on this analysis, they provide a fuzzing framework(ICSFuzz) to perform security evaluation of the PLC bina-ries. Our work differs from them because we focus on the

6. https://bitbucket.org/automforge/matiec git/issues?status=new&status=open

source code and do not rely on any specific compilationenvironment.

Kuzmin et al. [51] propose to use linear-time tem-poral logic (LTL) to guide program behavior and checkwhether ST program meets the corresponding temporallogic through Cadence SMV. Darvas et al. [13] propose rule-based reductions and Cone of Influence (COI) reductionvariant for state explosion problems that may be encoun-tered in the formal analysis of ST code, and use NuSMVmodel checker to verify temporal logic. After that, they[52] provide a state machine and data-flow-based formalspecification method for PLC modules. In addition, they[35] analyze the feasibility of converting between the 5 PLCprogramming languages provided by Siemens, and pointout that the extended SCL (a vendor-defined ST) can beused as the target language for conversion. Adiego et al.[53] propose an intermediate model-based method whichcan transform PLC programs written to different modelinglanguages of verification tools to facilitate checking tempo-ral logic. Hailesellasie et al. [54] provide the UBIS whichconverts potential intrusion ST program and trusted versionof the program into attributed graphs through UPPAALand compares their nodes and edges to detect stealthy codeinjections. Bohlender et al. [55] apply formal verificationand falsification of temporal logic specifications to analyzechemical plant automation systems. Rawlings et al. [56] usesymbolic model checking tools st2smv and SynthSMV toverify and falsify a ST program controlling batch reactorsystems. Xiong et al. [21] use the behavior model (BM)to specify the behavior of ST programs, and provide anmethod based on automatic theoretical to verify LTL at-tributes on BM. Our work differs from them because theseworks attempt to transformed PLC programs into inter-mediate languages or other programming language whichare suitable for verifying or detecting potential issues inassociated versifiers or checkers lack analysis and proof ofequivalence in the conversion process, and the analysis theycan perform is very limited. In addition, these methods do

16

not offer the feedback to the level of source code.Huang et al. [30] maybe the closest work to ours. They

first defined the executable semantics of ST language in theK and use it to check some security properties. Our workdiffers from them because we covered more complete STlanguage and we can use it to discover the error of STcompilers.

7 CONCLUSION

In this paper, we introduce an executable operational se-mantics of ST formalized in the K-framework. We presentthe semantics of the core features of ST, namely data types,memory operations, main control statements and functioncalls. Experiment results show that the proposed ST seman-tics has already covered the main core language featuresand correctly implements 26,137 lines of public ST codeon Github. Furthermore, the applications of the proposedsemantics in the testing and analysing of PLC compilerare discussed. By comparing and analyzing the executionresults of OpenPLC and executable semantics, we foundfive bugs and some functional deficiencies in OpenPLC. Inthe future, we hope to further improve the definition ofST semantics to adapt to the programming environmentprovided by different vendors. Because the vendor maycustomize keywords (Bit STRING of GX Works2), add ad-ditional structures (LABEL of Siemens), and even extend STwidely (ExST of CODESYS) when implementing.

REFERENCES

[1] R. Langner, “Stuxnet: Dissecting a cyberwarfare weapon,” IEEESecurity & Privacy, vol. 9, no. 3, pp. 49–51, 2011.

[2] G. Liang, S. R. Weller, J. Zhao, F. Luo, and Z. Y. Dong, “The 2015ukraine blackout: Implications for false data injection attacks,”IEEE Transactions on Power Systems, vol. 32, no. 4, pp. 3317–3318,2016.

[3] K. Zetter, “The ukrainian power grid was hacked again,” Mother-board, 2017.

[4] N. Perlroth and C. Krauss, “A cyberattack in saudi arabia had adeadly goal,” Experts fear another try, 2018.

[5] D. Tychalas and M. Maniatakos, “Open platform systems underscrutiny: A cybersecurity analysis of the device tree,” in 2018 25thIEEE International Conference on Electronics, Circuits and Systems(ICECS). IEEE, 2018, pp. 477–480.

[6] A. Nochvay, “Security research: Codesys runtime, a plc controlframework,” Kaspersky ICS CERT, 2019.

[7] D. Tychalas, H. Benkraouda, and M. Maniatakos, “Icsfuzz: Manip-ulating i/os and repurposing binary code to enable instrumentedfuzzing in {ICS} control applications,” in 30th {USENIX} SecuritySymposium ({USENIX} Security 21), 2021.

[8] “Programmable controllers - Part 3: Programming languages,”International Electrotechnical Commission, Standard, 2013.

[9] T. M. Antonsen, PLC Controls with Structured Text (ST), V3: IEC61131-3 and best practice ST programming. BoD–Books on Demand,2020.

[10] T. Ovatman, A. Aral, D. Polat, and A. O. Unver, “An overview ofmodel checking practices on verification of plc software,” Software& Systems Modeling, vol. 15, no. 4, pp. 937–960, 2016.

[11] H. Janicke, A. Nicholson, S. Webber, and A. Cau, “Runtime-monitoring for industrial control systems,” Electronics, vol. 4, no. 4,pp. 995–1017, 2015.

[12] L. Garcia, S. Zonouz, D. Wei, and L. P. De Aguiar, “Detectingplc control corruption via on-device runtime verification,” in 2016Resilience Week (RWS). IEEE, 2016, pp. 67–72.

[13] D. Darvas, B. F. Adiego, A. Voros, T. Bartha, E. B. Vinuela, andV. M. G. Suarez, “Formal verification of complex properties onplc programs,” in International Conference on Formal Techniques forDistributed Objects, Components, and Systems. Springer, 2014, pp.284–299.

[14] D. Darvas, I. Majzik, and E. B. Vinuela, “Formal verification ofsafety plc based control software,” in International Conference onIntegrated Formal Methods. Springer, 2016, pp. 508–522.

[15] L. Garcia, F. Brasser, M. H. Cintuglu, A.-R. Sadeghi, O. A. Mo-hammed, and S. A. Zonouz, “Hey, my malware knows physics!attacking plcs with physical model aware rootkit.” in NDSS, 2017.

[16] R. Spenneberg, M. Bruggemann, and H. Schwartke, “Plc-blaster:A worm living solely in the plc,” Black Hat Asia, vol. 16, pp. 1–16,2016.

[17] A. Keliris and M. Maniatakos, “Icsref: A framework for automatedreverse engineering of industrial control systems binaries,” arXivpreprint arXiv:1812.03478, 2018.

[18] S. Guo, M. Wu, and C. Wang, “Symbolic execution of pro-grammable logic controller code,” in Proceedings of the 2017 11thJoint Meeting on Foundations of Software Engineering, 2017, pp. 326–336.

[19] S. E. McLaughlin, S. A. Zonouz, D. J. Pohly, and P. D. McDaniel,“A trusted safety verifier for process controller code.” in NDSS,vol. 14, 2014.

[20] G. Canet, S. Couffin, J. Lesage, A. Petit, and P. Schnoebelen,“Towards the automatic verification of PLC programs written ininstruction list,” in Proceedings of the IEEE International Conferenceon Systems, Man & Cybernetics: ”Cybernetics Evolving to Systems,Humans, Organizations, and their Complex Interactions”. IEEE, 2000,pp. 2449–2454.

[21] J. Xiong, X. Bu, Y. Huang, J. Shi, and W. He, “Safety verificationof iec 61131-3 structured text programs,” IEEE Transactions onIndustrial Informatics, vol. 17, no. 4, pp. 2632–2640, 2020.

[22] M. Zhang, C.-Y. Chen, B.-C. Kao, Y. Qamsane, Y. Shao, Y. Lin,E. Shi, S. Mohan, K. Barton, J. Moyne et al., “Towards automatedsafety vetting of plc code in real-world plants,” in 2019 IEEESymposium on Security and Privacy (SP). IEEE, 2019, pp. 522–538.

[23] N. Bauer, S. Engell, R. Huuck, S. Lohmann, B. Lukoschus,M. Remelhe, and O. Stursberg, “Verification of plc programs givenas sequential function charts,” in Integration of software specificationtechniques for applications in Engineering. Springer, 2004, pp. 517–540.

[24] A. Mader and H. Wupper, “Timed automaton models for simpleprogrammable logic controllers,” in Proceedings of 11th EuromicroConference on Real-Time Systems. Euromicro RTS’99. IEEE, 1999, pp.106–113.

[25] T. Mertke and G. Frey, “Formal verification of plc programs gener-ated from signal interpreted petri nets,” in 2001 IEEE InternationalConference on Systems, Man and Cybernetics. e-Systems and e-Man forCybernetics in Cyberspace (Cat. No. 01CH37236), vol. 4. IEEE, 2001,pp. 2700–2705.

[26] R. Huuck, “Semantics and analysis of instruction list programs,”Electronic Notes in Theoretical Computer Science, vol. 115, pp. 3–18,2005.

[27] J. Sadolewski, “Conversion of st control programs to ansi c forverification purposes,” e-Informatica Software Engineering Journal,vol. 5, no. 1, 2011.

[28] O. Maler and S. Yovine, “Hardware timing verification usingkronos,” in Proceedings of the Seventh Israeli Conference on ComputerSystems and Software Engineering. IEEE, 1996, pp. 23–29.

[29] M. Heiner and T. Menzel, “Petri net semantics for the plc userprogramming language instruction list,” Techn. Report BTU Cot-tbus, I-20/1997, Cottbus December, 1997.

[30] Y. Huang, X. Bu, G. Zhu, X. Ye, X. Zhu, and J. Shi, “Kst: Executableformal semantics of iec 61131-3 structured text for verification,”IEEE Access, vol. 7, pp. 14 593–14 602, 2019.

[31] G. Rosu, “K: A semantic framework for programming languagesand formal analysis tools,” Dependable Software Systems Engineer-ing, vol. 50, p. 186, 2017.

[32] M. J. Hohnka, J. A. Miller, K. M. Dacumos, T. J. Fritton, J. D. Erdley,and L. N. Long, “Evaluation of compiler-induced vulnerabilities,”Journal of Aerospace Information Systems, vol. 16, no. 10, pp. 409–426,2019.

[33] M. Marcozzi, Q. Tang, A. F. Donaldson, and C. Cadar, “Compilerfuzzing: How much does it matter?” Proceedings of the ACM onProgramming Languages, vol. 3, no. OOPSLA, pp. 1–29, 2019.

[34] T. R. Alves, M. Buratto, F. M. De Souza, and T. V. Rodrigues,“Openplc: An open source alternative to automation,” in IEEEGlobal Humanitarian Technology Conference (GHTC 2014). IEEE,2014, pp. 585–589.

[35] D. Darvas, I. Majzik, and E. Blanco Vinuela, “Generic represen-tation of plc programming languages for formal verification,” in

17

23rd PhD Mini-Symposium. Budapest University of Technologyand Economics, 2016, pp. 6–9.

[36] N. Roos, “Programming plcs using structured text,” in Interna-tional Multiconference on Computer Science and Information Technol-ogy. Citeseer, 2008, pp. 20–22.

[37] F. Markovic, “Automated test generation for structured text lan-guage using uppaal model checker,” 2015.

[38] M. Tiegelkamp and K.-H. John, IEC 61131-3: Programming indus-trial automation systems. Springer, 2010.

[39] N. Martı-Oliet and J. Meseguer, “Rewriting logic: roadmap andbibliography,” Theoretical Computer Science, vol. 285, no. 2, pp. 121–154, 2002.

[40] A. Stefanescu, D. Park, S. Yuwen, Y. Li, and G. Rosu, “Semantics-based program verifiers for all languages,” ACM SIGPLAN Notices,vol. 51, no. 10, pp. 74–91, 2016.

[41] C. Ellison and G. Rosu, “An executable formal semantics of c withapplications,” ACM SIGPLAN Notices, vol. 47, no. 1, pp. 533–544,2012.

[42] D. Bogdanas and G. Rosu, “K-java: A complete semantics ofjava,” in Proceedings of the 42nd Annual ACM SIGPLAN-SIGACTSymposium on Principles of Programming Languages, 2015, pp. 445–456.

[43] D. Park, A. Stefanescu, and G. Rosu, “Kjs: A complete formalsemantics of javascript,” in Proceedings of the 36th ACM SIGPLANConference on Programming Language Design and Implementation,2015, pp. 346–356.

[44] F. Wang, F. Song, M. Zhang, X. Zhu, and J. Zhang, “Krust: A formalexecutable semantics of rust,” in 2018 International Symposium onTheoretical Aspects of Software Engineering (TASE). IEEE, 2018, pp.44–51.

[45] J. Jiao, S. Kan, S.-W. Lin, D. Sanan, Y. Liu, and J. Sun, “Semanticunderstanding of smart contracts: Executable operational seman-tics of solidity,” in 2020 IEEE Symposium on Security and Privacy(SP). IEEE, 2020, pp. 1695–1712.

[46] T. Nipkow and G. Klein, “Imp: A simple imperative language,” inConcrete Semantics. Springer, 2014, pp. 75–94.

[47] D. D. McCracken and E. D. Reilly, “Backus-naur form (bnf),” inEncyclopedia of Computer Science, 2003, pp. 129–131.

[48] G. Rosu and T. F. Serbanuta, “K overview and simple case study,”Electronic Notes in Theoretical Computer Science, vol. 304, pp. 3–56,2014.

[49] R. Schumi and J. Sun, “Spectest: Specification-based compilertesting,” Fundamental Approaches to Software Engineering, vol. 12649,p. 269, 2021.

[50] V. Le, M. Afshari, and Z. Su, “Compiler validation via equivalencemodulo inputs,” ACM Sigplan Notices, vol. 49, no. 6, pp. 216–226,2014.

[51] E. V. Kuzmin, A. Shipov, and D. A. Ryabukhin, “Construction andverification of plc programs by ltl specification,” in 2013 Tools &Methods of Program Analysis. IEEE, 2013, pp. 15–22.

[52] D. Darvas, E. Blanco Vinuela, and I. Majzik, “A formal specifica-tion method for plc-based applications,” 2015.

[53] B. F. Adiego, D. Darvas, E. B. Vinuela, J.-C. Tournier, S. Bliudze,J. O. Blech, and V. M. G. Suarez, “Applying model checkingto industrial-sized plc programs,” IEEE Transactions on IndustrialInformatics, vol. 11, no. 6, pp. 1400–1410, 2015.

[54] M. Hailesellasie and S. R. Hasan, “Intrusion detection in plc-basedindustrial control systems using formal verification approach inconjunction with graphs,” Journal of Hardware and Systems Security,vol. 2, no. 1, pp. 1–14, 2018.

[55] D. Bohlender and S. Kowalewski, “Compositional verification ofplc software using horn clauses and mode abstraction,” IFAC-PapersOnLine, vol. 51, no. 7, pp. 428–433, 2018.

[56] B. C. Rawlings, J. M. Wassick, and B. E. Ydstie, “Application offormal verification and falsification to large-scale chemical plantautomation systems,” Computers & Chemical Engineering, vol. 114,pp. 211–220, 2018.