A Syntactic Specification for the Programming ...

Advances in Computational Intelligence, Man-Machine Systems and Cybernetics

A Syntactic Specification for the Programming Languages of the IEC 61131-3 Standard FLOR NARCISO§

ADDISON RIOS-BOLIVAR§ OLGA GONZALEZ§

FRANCISCO HIDROBO‡

‡

§

Universidad de Los Andes Departamento de F´ısica La Hechicera, M´erida 5101 VENEZUELA [email protected]

Universidad de Los Andes Escuela de Ingenier´ıa de Sistemas La Hechicera, M´erida 5101 VENEZUELA fnarciso,ilich,[email protected]

Abstract: In order to implement a translator, a syntactic specification for the programming languages of the IEC 611131-3 standard is presented in this paper. This specification is built in function of the components of a formal grammar, which are the set of terminal symbols, the set of non terminal symbols, the start symbol or axiom and the set of production rules. The formal grammar described corresponds to a context-free grammar; which is currently being used to describe most of the programming languages. With the definition of this grammar, the programming languages of the IEC 611131-3 standard are formally described and is presented as an example, the syntactic specification of the textual programming languages, known as Instruction List and Structured Text. Then, the graphical programming languages (Ladder Diagram and Functional Block Diagram) can be specified in the same way. With the grammar described is possible to build a translator using open standards and open source that can generate code in high level programming language (like C programming language) to support the management of control logics. Key–Words: Context-Free Grammar, Programming Languages, IEC 611131-3 standard, Industrial Automation, Translator.

1

Introduction

tomatas and their peripherals, including the programming languages to be used: textual or literals programming languages (Instructions List (IL) and Structured Text (ST)) and graphical programming languages (Ladder Diagram (LD) and Functional Block Diagram (FDB)) [2]. The main objective of this computational tool, called open source SoftPLC [5, 7], is to offer a development environment for control applications that provides the programming languages of the IEC 611131-3 standard, for PLC programmers and engineers to build applications using the services and resources that form part of this tool. These services and resources, in their basic form, are joined in components well defined, such as an editor, a translator and a graphical user interface. This draws a substantial difference with respect to similar commercial tools, because the proposed tool meets all requirements of the standard and it is open source. As stated earlier, one of the components of the proposed computational tool is a translator, which is a software application that reads a program written in a language, called the source language, and translates it into an equivalent program written in another language, called the target language or object language. As an important part of the translation process, the translator informs to the user the presence of errors, if any, in the program written in the source language [3]. In the particular case of this tool, the translator must transform a program written in any of

A Programmable Logic Controller (PLC) is an electronic system of digital operation, which is designed to be used on industrial environments. This system uses a programmable memory for storage of the users instructions, these instructions are implemented through specific functions as logical, sequential, temporal, counters and arithmetic, to control, using analogical or digital input/output, diverse types of machines or processes [8]. The PLCs are well known systems in the industrial field, and they are widely used, along with personal computers (PCs) in control applications, conducing to the development of applications that allow a PC to function as a PLC. This kind of applications are called SoftPLC. Then, a SoftPLC is an application that runs in real time on a PC allowing to emulate the behavior of a PLC by software. In order to assist control engineers in the development of control applications, using one or several standard programming language of PLC, and fulfilling with the premises of open source and the IEC 611131-3 standard [1], in [5, 7] the design of a computational tool for managing the control logics is described. The IEC 611131-3 standard aims to present an industrial standardization of programables automatas and their peripherals, including the programming languages to be used [2]. This standard provides an industrial standardization of programmable au-

ISBN: 978-960-474-257-8

171

Advances in Computational Intelligence, Man-Machine Systems and Cybernetics

2

the programming languages provided by the IEC 611131-3 standard to an equivalent program written in an intermediate language. In this case the intermediate language under consideration is the C programming language [9], then obtained as a result of the translation process a code in C programming language that can be compiled and executed. Conceptually, a translator works in phases, each of which transforms the program written in source language (source program) from one representation to another to get the program written in intermediate language (object program). Figure 1 shows a typical structure of a translator as the one proposed in [7] where the two functions, error management and administration of the symbol table are continuously interacting with the analysis and synthesis phases.

In [4], a language, from the linguistic point of view, is defined as “a set (finite or infinite) of sentences, each one of them with finite length and constructed with a finite number of elements”. This definition can be used both for natural language (specific to humans) and for programming languages (specific to computers). A language formally specified is called formal language. The basic concept in formal language theory is the word, which consists of an ordered sequence of symbolsPfrom a specific alphabet, being the alphabet, denoted by , the set of all symbols that form the language words. On the other hand, a set of words form a a sentence of the language. In order to make the definition of the sentences of a language the grammar are used. These allow to make the syntactic specification of the programming languages, taking in account that these languages, like natural languages, are formed by a set of valid words (vocabulary), a set of grammatical rules that allow the construction of valid sentences of the language (syntax) and a set of rules that determine the meaning of the sentences of the language (semantics). The term formal grammar refers to the grammar that is defined in the computational linguistic. A formal grammar is formally defined as the ordered quadruple G = ( N, T, S, P) [4]. The set of non-terminal symbols (N) is the finite set of symbols introduced as auxiliary elements for definition of the production rules of the grammar, none of which appear in the words of language. The set of terminal symbols (N) P is the set of atomic symbols (indivisible) of the alphabet , that are combined to form the words of language. The start symbol (S) is a non-terminal symbol from which all sentences of the language generated by the grammar are obtained by applying its rules of production. The set of production rules (P) are transformations of strings of symbols that can be applied successively from the start symbol to get a string of terminals that form a sentence of the language. To represent a production rule the notation α → β is used. The syntax of natural languages, programming languages and other formal languages are defined using context-free grammars (CFG) [3], in which the production rules of P have the form A → β, such that, A ∈ N and β ∈ (N ∪ T )∗ , where (N ∪ T )∗ represent the set of all possible words that can be formed with the symbols of (N ∪T ) including the empty word [3]. Generally, the EBNF (Extended Backus Naur Form) notation is used to specify the production rules of a CFG, which is an extension of BNF (Backus Naur Form) notation, and it is defined as metalanguage that is used to express the syntax of programming languages. This notation uses the symbols shown in the table 1. In order to obtain a syntactic specification of the programming languages of the IEC 611131-3 standard, in the section 3 it is described a CFG whose production rules are specified using the EBNF notation.

Figure 1: The graphical representation of the translation process To make the syntactic specification of a programming language the Context-Free Grammars (CFG) are used, which allow to describe most of the programming languages [3]. Generally, these grammars are simple, allowing the design of syntactic-analysis algorithms which can determine whether a sequence of tokens correspond to a valid sentence of the programming language. Also, the CFG can be used in the design of lexical analyzers contributing to the identification and structuring of the collection of lexical components or tokens. In this paper, the syntactic specification of the PLC programming languages is presented, according to the established in the IEC 6111313 standard, based on the description presented in [5] for the common elements of these programming languages (textual and graphicals). Following, the syntactic specification of the IL programming language is presented. Finally, the syntactic specification of the ST programming language is presented. The syntactic specification of the LD and FDB programming languages can be reviewed in [5]. ISBN: 978-960-474-257-8

Formal Grammar and Language

172

Advances in Computational Intelligence, Man-Machine Systems and Cybernetics

Table 1: EBNF notation symbols Symbol ::= | {} []

3

Description It separates the left and right part of the production rule and it is read: “it defined as” It separates the alternatives of the right part of the production rules and it is read “or” Repetition, it means zero or more concatenations of items enclosed Option, it means zero or one occurrence of the items enclosed

Figure 2: Example of a program written in the programming languages of the IEC 611131-3 standard

Syntactic specification of the textual programming languages for PLC

As it is defined in the IEC 611131-3 standard, the non-terminal symbols are represented by strings of lowercase letters, numbers and the underscore ( ) character starting with a lowercase letter. For example, term1 and term 2 are valid non-terminal symbols, while 3noterm and Noterm4 are invalid non-terminal symbols [2]. The start symbol corresponds to the non-terminal symbol library element name. The production rules for textual programming languages of PLCs have the form Non-terminal symbol ::=extended structure. This production rule can be read as “a non-terminal symbol is defined as an extended structure”. The extended structures can be constructed according to the following criteria:

In this section, a syntactic specification for the common parts of the programming languages for PLC (textual and graphicals) as well as those specific for the textual programming languages for PLC (IL and ST) is presented, in terms of a CFG. The syntactic specification for the graphical programming languages for PLC (LD and FBD) have been described in [5], which completes the definition of the CFG that generates the four programming languages provided by the IEC 61131-3 standard. IL is a low-level programming language (machine dependent) that is similar to an assembly language for simple applications. ST is a high-level programing language (machine independent) that is similar to Pascal. LD is based on the graphical representation of the relay logic and it allow to describe an input logical sequence of a specific process using connections, contacts and coils. FBD is very common in applications involving information flows or data among control components, and it uses the functional block form the area of control process, which are combined in a logic by mean of signals. Figure 2 shows an example of a program written in each of the programming languages for PLC. In addition,the IEC 611313 standar provides a fifth programming language known as Sequential Function Chart (SFC), which allows to develop programs of sequential control, graphically, and its elements can be used in conjunction with any of the graphical programming languages described before. In order to make the syntactic specification, the guidelines established in the IEC 611131-3 standard are followed, where the terminal symbols consist of a string enclosed in single or double quotes, for example, “ABC” or ‘ABC’. A special terminal symbol used in this syntax is the end-of-line delimiter, which is represented by the string without quotes EOL. Normally, this symbol consists of the character “paragraph separator” defined as the hexadecimal code 2029 by the ISO/IEC 10646-1. A second special symbol used in this specification is the “NULL string”, which have no characters, and it is represents by the terminal symbol NIL [2]. ISBN: 978-960-474-257-8

1. The NULL string, NIL, is an extended structure. 2. A terminal symbol is an extended structure. 3. A non-terminal symbol is an extended structure. 4. If S is an extended structure, then these expressions also are extended structures: (S), meaning the same S; {S}, repetition, meaning zero or more concatenations of S; [S], option, meaning zero or one occurrence of S. 5. If S1 and S2 are extended structures, then these expressions are extended structures: S1|S2, alternative, meaning an option of S1 or S2; S1 S2, concatenation, meaning S1 followed by S2. 6. The concatenation precede to alternative, S1|S2 S3 is equivalent to S1|(S2 S3), and S1 S2|S3 is equivalent to (S1 S2)|S3. In next section, the production rules that describe the common elements of the programming languages of the IEC 611131-3 standard are presented. These production rules represent the fundamental base for the design and implementation of a translator that allow the generation of high-level code from a program written in any of programming languages provided by this standard. 173

Advances in Computational Intelligence, Man-Machine Systems and Cybernetics

3.1

Production rules for the common elements of the programming languages for PLC

A programming model is defined according to the following production rules: library_element_name ::= data_type_name | function_name | function_block_type_name | program_type_name | resource_type_name | configuration_name library_element_declaration ::= data_type_declaration | function_declaration | function_block_declaration | program_declaration | configuration_declaration

These production rules express the basic programming model defined in [6], where declarations are the basic mechanism for production of the library elements. Next, the production rules for the common elements of the programming languages of the IEC 611131-3 standard are described, which correspond to characters, digits and identifiers; constants; data types; variables; units of programs organization; and configuration elements: letter ::= ’A’ | ’B’ | | ’Z’ | ’a’ | ’b’ | | ’z’ digit ::= ’0’ | ’1’ | ’2’ | ’3’ | ’4’ | ’5’ | ’6’ | ’7’ | ’8’ |’9’ octal_digit ::= ’0’ | ’1’ | ’2’ | ’3’ | ’4’ | ’5’ | ’6’ | ’7’ hex_digit ::= digit | ’A’| ’B’ | ’C’ | ’D’ | ’E’ | ’F’ identifier ::= (letter | (’_’ (letter | digit))) {[’_’] (letter | digit)} constant ::= numeric_literal | character_string | time_literal | bit_string_literal | boolean_literal

simple_type_name ::= identifier subrange_type_name ::= identifier enumerated_type_name ::= identifier array_type_name ::= identifier structure_type_name ::= identifier data_type_declaration ::= ’TYPE’ type_declaration ’;’ {type_declaration ’;’} ’END_TYPE’ type_declaration ::= single_element_type_declaration | array_type_declaration | structure_type_declaration | string_type_declaration single_element_type_declaration ::= simple_type_declaration | subrange_type_declaration | enumerated_type_declaration simple_type_declaration ::= simple_type_name ’:’ simple_spec_init simple_spec_init ::= simple_specification [’:=’ constant] simple_specification ::= elementary_type_name | simple_type_name subrange_type_declaration ::= subrange_type_name ’:’ subrange_spec_init subrange_spec_init ::= subrange_specification[’:=’ signed_integer] subrange_specification ::= integer_type_name ’(’ subrange’)’ | subrange_type_name subrange ::= signed_integer ’..’ signed_integer enumerated_type_declaration ::= enumerated_type_name ’:’ numerated_spec_init enumerated_spec_init ::= enumerated_specification [’:=’ numerated_value] enumerated_specification ::= (’(’ enumerated_value {’,’ enumerated_value} ’)’) | enumerated_type_name enumerated_value ::= [enumerated_type_name ’#’] identifier array_type_declaration ::= array_type_name ’:’ array_spec_init array_spec_init ::= array_specification [’:=’ array_initialization] array_specification ::= array_type_name | ’ARRAY’ ’[’ subrange {’,’ subrange} ’]’ ’OF’ non_generic_type_name array_initialization::= ’[’ array_initial_elements {’,’ array_initial_elements} ’]’ array_initial_elements ::= array_initial_element | integer ’(’[array_initial_element] ’)’ array_initial_element ::= constant | enumerated_value | structure_initialization | array_initialization structure_type_declaration ::= structure_type_name ’:’ structure_specification structure_specification ::= structure_declaration | initialized_structure initialized_structure ::=structure_type_name [’:=’ structure_initialization] structure_declaration ::=’STRUCT’ structure_element_declaration ’; ’{structure_element_declaration ’;’}’END_STRUCT’ structure_element_declaration ::= structure_element_name ’:’(simple_spec_init | subrange_spec_init | enumerated_spec_init | array_spec_init | initialized_structure) structure_element_name ::= identifier structure_initialization ::= ’(’ structure_element_initialization {’,’ structure_element_initialization} ’)’ structure_element_initialization ::= structure_element_name ’:=’ (constant | enumerated_value | array_initialization | structure_initialization) string_type_name ::= identifier string_type_declaration ::= string_type_name ’:’ (’STRING’|’WSTRING’) [’[’ integer ’]’] [’:=’ character_string]

numeric_literal ::= integer_literal | real_literal variable ::= direct_variable | symbolic_variable integer_literal ::= [ integer_type_name ’#’ ]( signed_integer | binary_integer | symbolic_variable ::= variable_name | multi_element_variable octal_integer | hex_integer) variable_name ::= identifier signed_integer ::= [’+’ |’-’] integer integer ::= digit {[’_’] digit} direct_variable ::= ’%’ location_prefix size_prefix integer {’.’ integer} binary_integer ::= ’2#’ bit {[’_’] bit} location_prefix ::= ’I’ | ’Q’ | ’M’ bit ::= ’1’ | ’0’ size_prefix ::= NIL | ’X’ | ’B’ | ’W’ | ’D’ | ’L’ octal_integer ::= ’8#’ octal_digit {[’_’] octal_digit} hex_integer ::= ’16#’ hex_digit{[’_’] hex_digit} multi_element_variable ::= array_variable | structured_variable real_literal ::= [ real_type_name ’#’ ] array_variable ::= subscripted_variable subscript_list signed_integer ’.’ integer [exponent] subscripted_variable ::= symbolic_variable exponent ::= (’E’ | ’e’)[’+’|’-’] integer bit_string_literal ::= [ (’BYTE’ | ’WORD’ | ’DWORD’ | ’LWORD’) ’#’ ]( unsigned_integer |subscript_list ::= ’[’ subscript {’,’ subscript} ’]’ subscript ::= expression binary_integer | octal_integer | hex_integer) structured_variable ::= record_variable ’.’ field_selector boolean_literal ::= ( [ ’BOOL#’ ] (’1’ | ’0’ ) )| ’TRUE’ | ’FALSE’ record_variable ::= symbolic_variable field_selector ::= identifier character_string ::= single_byte_character_string | double_byte_character_string single_byte_character_string ::= "’" {single_byte_character_representation} "’" double_byte_character_string ::= ’"’ {double_byte_character_representation} ’"’ single_byte_character_representation ::= common_character_representation | "$’" | ’"’ | ’$’ hex_digit hex_digit double_byte_character_representation ::= common_character_representation | ’$"’ | "’"| ’$’ hex_digit hex_digit hex_digit hex_digit common_character_representation ::=