![](bg3.png)
versatility that DMS was chosen to analyze
Rockwell Automation’s PLC code.
A very simple model of DMS is that of an
extremely generalised compiler, having a parser
generator capabilities for arbitrary parseable
languages, a semantic analysis framework and a
general program transformation engine. It is
particularly important that the analyzer output can be
used to choose the desired transforms. Unlike a
conventional compiler, in which each component is
specific to its task of translating one source language
to one target machine language, each DMS
component is highly parameterized, enabling a wide
variety of effects. This means one can choose the
input language, the analysis, the transforms, and the
output form in arbitrary ways.
The computation of software metrics is based on
the structure of the source code. This means metrics
can be extracted from a parse of the program text.
DMS® has the ability to parse large scale software
systems based on the language definition modules
used to drive DMS® for software reengineering
tasks.
The language definition for PLC control
programs is Rockwell Automation’s Logix5000
Controllers Import/Export Format Version 2.6. This
version was introduced when RSLogix5000
(Rockwell’s development environment program)
Version 15 was introduced. The language definition
module is intended to be backwards compatible.
Although many earlier examples of code have been
parsed by the module, it has not been extensively
tested for every prior version of the import/export
language (which will from here-on be referred to as
‘L5K’, the file-type used by the import/export
language.
Some other things to note about this language
module are that
The Motion Instruction set is included owing to
the extensive use of these instructions in
industry. Consequently, much of the example
code used to test the parser made use of these
instructions.
Of the five IEC 61131 languages (ladder logic,
sequential function charts, function block
diagram, structured text and instruction list), the
only one that the parser is presently designed
process is ladder logic. Further expansion to
extend the functionality to the remaining
languages is possible and would be a logical
continuation of this work.
RSLogix5000 version 16 has subsequently been
released along with version 2.7 of the
import/export format language.
3.1 Lexical Analysis
The job of the lexer is to read in a source l5k
program and to ‘tokenize’ it; that is to convert it
from a stream of characters that make up the
program body, to a sequence of lexemes. A lexeme
is a single atomic unit of the language, for example a
keyword. This sequence can then be input to the
parser, which in turn will attach structure to the
sequence and produce an abstract syntax tree.
3.1.1 Lexical Definition Macros
Macros are definitions of characters, character sets
and other useful blocks of text that are made up from
regular expressions. Macros may be defined to
abstract lexical notions like blank or newline
whitespace, case insensitive letters, digits,
hexadecimal digits and floating point numbers.
3.1.2 Lexical Modes
DMS® supports the use of lexical modes to lex
different source file sections that contain passages of
distinct lexical vocabularies. Lexical modes used to
lex L5K programs include:
ModuleDeclarations. Lexes module declarations
after module attributes have been collected.
DataDeclarations. This lexes DATATYPE and
TAG block contents.
RLL. This lexes the PROGRAM section
containing the body of ladder logic code.
ParameterValue. Includes various types of
structured values and unstructured strings. This
is the lexical mode to collect attribute values
including names, numbers etc.
Depending on where they are defined, macros
are global (meaning they can be referred to from
every lexical mode) or local (meaning that only the
lexical mode in which the macro was defined can
use that particular macro).
Lexical modes are stored in a stack. The mode
that is at the top of the stack is the mode used to
process the next token.
Operations performed on the mode stack are
nearly always prompted by the occurrence of a
specific token in a given lexical mode. Certain
tokens encountered in one mode can trigger a
change to another mode, reflected in a mode stack
modification.
If there is no token found in the current lexical
mode then the lexer can perform a last ditch error
recovery. This is usually either a switch to another
lexical mode, or popping the current lexical mode
CALCULATING SOFTWARE METRICS FOR LADDER LOGIC
145