1. technology and computing
2. software

TM5-4
Proceedings of the 2000 IEEE
International Conference on Control Applications
Anchorage, Alaska, USA ,, September 25-27, 2000
2:00
Mechatronic Objects encapsulation in IEC 1131-3
Norm
M a r c e l l o Bonf~ a n d C e s a r e F a n t u z z i
U n i v e r s i t y of F e r r a r a , v. S a r a g a t , 1, 44100 F e r r a r a - Italy.
E-mail: {mbonfe, c f a n t u z z i } © i n g , u n i f e , i t
Abstract
overtake these problems ([2], [3], [4], [5]), trying
to exploit its basic concepts (abstraction, encapsulation, inheritance), which showed effectiveness in increasing software modularity and
reusability in many Personal Computer applications.
This paper concerns with the definition and use
of "mechatronic objects" for the design of complex manufacturing system as large machinery.
In particular the programming languages and
structures defined under the IEC 1131-3 norm
are considered regarding the software encapsulation of the mechanical system. The paper
reports about a real application example of the
proposed concepts showing effectiveness of the
object-oriented framework for industrial applications.
A leading common theme between these works
is the use of object-oriented methodology in
system modeling and designing phase, that
leads to a very powerful description of the physical devices in which the system can be split.
Unfortunately, the description so obtained is
hard to translate i~ a PLC-based environment,
without introducing limitations or loss of powerness or without developing a specific intermediate tool between the high-level objects model
and the low-level programming environment
for the controlling device chosen. In fact, even
if the objects model in itself is general and abstract, its implementation requires an adaptation to the PLC language characteristics, which
change dramatically among different producers
and, sometimes, from different series within a
single producer.
1 Introduction.
Large automated machines designed and developed for goods production are complex systems
in which mechanical and electronic parts are often designed separately, even if they are structurally close connected. Moreover, the software
developing tools for programmable controllers
are very primitive, especially when compared
to those designed for high level languages such
as C or Java. As matter of fact, industry standards PLC (Programmable Logic Controllers)
relies on low level programming languages such
as Ladder Diagram and Instruction List [1] for
control program implementation, with evident
limits with respect to software structuring and
modularization, not mentioning lack of parameterizable procedures.
However, PLC users and developers had recently risen requests of standardized languages
and tools to PLC manufacturers, so that International Electrotechnical Commission (IEC)
organization, aiming to cope with this request,
issued the IEC 1131-3 standard [6] that regards
the main aspects of industrial controllers programming languages and structures. This international norm is going to be widely accepted
from PLC producers, and it seems that in the
next years it will be an establishment.
This scenario leads to very inefficient developing cycle for manufacturing machineries, and
often few components (e.g. mechanical, electrical and software parts) can be reused in subsequent projects, increasing overall machinery
costs.
This paper aims principally to explore how
the languages and the structures of the cited
norm can be exploited to develop industrial
software object-oriented. Right before to discuss the main topic, we should discuss the
Object-oriented philosophy has been recently
introduced in the industrial field in order to
0-7803-6562-3/00510.00@2000 IEEE
598
or its resetting phase, and a state represented
by the last value sensed. A DC motor, a transporting conveyor, even a simple button can also
be described as objects. Nevertheless, the implementation of the control software needed to
automate the system modeled is still a hard job,
especially when considering a PLC-based application, typically non-object oriented. That
kind of model is probably too much sophisticated for this environment. It would be more
effective to consider only those objects (and
within them only some aspects) strictly related
to control aspects. Back to the sensor example, the programmable controller needs only to
receive the value sensed as an input to perform a control algorithm. The designing approach to a complex machine controlled by a
PLC should then be slightly different: more attention must be given to interactions between
the electro-mechanical project and the control
software project. The system must be split into
physical-functional modules, even distributed
onto several hierarchical levels, that can be considered as stand-alone components each performing a specific functionality in the productive process. For example, in a products packaging machine there can be a single product
transport cell, a pick-up cell, and a box transport cell. Maybe a transport cell can be composed by two or more simple conveyors, moved
by motors actuated as an incoming product is
detected by a photo-cell. The conveyor-motorphoto-cell ensemble can then represent an object composed by mechanic and electronic parts
(a mechatronic object) that works together to
transport the products to the subsequent working cell. The control algorithm needed by the
object should also be considered as part of it,
like a method is encapsulated in a software object. Of course, this control 'method' remains
almost independent by the rest of the control
program and can be encapsulated in a software
block. It is evident that as an identical conveyor is used in another machine, or in another
part of the same machine, the control block defined can be reused.
definition of a "mechatronic object" in industrial environment, that is treated in the next
Section. Then Section 3 gives a quick survey on the main concepts defined in part 3
("Programming Languages") of the IEC 1131
standard, that can be helpful for implementing a mechatronic object-oriented architecture.
Subsequent section presents a practical application of the projecting methodology discussed
with regards to a packaging machine.
2 D e f i n i t i o n of mechatronic object.
When the object-oriented paradigm was introduced, in the first 80's, it changed dramatically the approach to software development.
The main difference with traditional process of
program construction was in shifting the focus
point from algorithm to data structure. This
means: "ask not first what the system does,
but what it does it to" [7].
As the object-oriented approach was gaining space in software development field, its
potential in modeling and abstracting physical complex systems attracted the attention
of automation engineering specialists ([8], [9],
[10]). However, some aspects peculiar of automated systems where difficult to describe
without improving the capabilities of objects
model, especially with regards to the operational features of the physical devices. A
specific object-oriented technique for modeling
real-time working systems, called OMT (Object Modeling Technique [11]), has been developed. The work of the engineering group
behind this technique leaded to the formal description of an object-oriented language, called
UML (Unified Modeling Language [12]), specific for expressing the constructs and relationships of complex physical architectures 1.
A model obtained applying UML concepts to
an automated machine will be a set of heterogeneous objects, some describing mechanical parts and some describing electronic parts.
For example, a sensor (of any type) could be
an object with an attribute related to the value
sensed, methods related to its acquiring phase
3 Object-oriented technology under
I E C l 1 3 1 - 3 n o r m languages
1 UML is intended to be a visual modeling language,
programming language, despite its powerness in specifying and c o n s t r u c t i n g a software system.
However, a tight m a p p i n g into an object-oriented prog r a m m i n g language can be done.
n o t a visual
The implementation aspects concerning control software for mechatronic objects described
above, regard mainly the modularization and
599
encapsulation facilities that can be used in the
programming tools. This is a typical weak
point of the PLC systems, mainly beacuse the
characteristics of the Ladder Diagram language
which is by far the most used programming language. As people with different background get
close to PLC programming, they perceived its
characteristics as limitations, so has been introduced new languages (e.g. the assemblerlike Instruction List [1] language and the statetransition chart Grafcet [13]) and facilities to
split large programs in smaller blocks and subroutines. Unfortunately, every company producer of programmable controllers followed a
different road to improve its products, that resulted in a Babel of languages and software
structures. In this confused situation, the request for standardization grew up from PLC
users until it has been recognized by the international industrial community. So, in 1979,
the IEC set up a task force with the objective
of defining a norm that could, from one side,
identify a common syntax for the several programming languages and, from the other side,
fix a guideline for future application of highlevel software developing concepts in the PLC
scenario. The result of the IEC 65B/WGT/TF3
work is the IEC 1131 Standard, published in
19932. Let's focus on part 3 of this norm, the
one devoted to 'Programming Languages', and
its two cardinal concepts:
• the definition of four different programming languages and a graphic formalism
for structuring the internal organization
of software blocks; and
Graphical languages are instead: L a d d e r Dia g r a m (LD), based on most known PLC programming logic, suitable for managing directly
the boolean inputs and outputs coming from
sensors and going to physical actuators; Funct i o n B l o c k D i a g r a m ( F B D ) , a powerful formalism for describing signal and data connections between function blocks, that are software
elements, as will be better described later, basic
for encapsulation and reuse of code segments.
Another graphical syntax is described in
the definition of Sequential Function Chart
(SFC), a state-transition diagram derived from
Grafcet [13], very expressive for describing, in
a readable and intuitive way, sequential behavior of complex systems. Even if many people consider SFC as an effective programming
language and several programming tools are
equipped with a SFC editor, it cannot be considered as a full language, because some of its
parts (actions and transitions) require an internal implementation with instructions from
other languages.
Another innovative concept proposed in the
IEC standard regards the structure of a control
application. As said above, a software model
has been defined for this purpose. The IEC
software model allows the decomposition of the
application into functional components that are
defined 'Program Organization Units' (POUs).
The description of the three types of POUs is
the following:
Program: it is the larger container of
all programming elements and constructs
necessary for the control of a machine
or a process. Each of the software elements composing a program can be programmed in any IEC languages and will
be an instance of the following POUs;
• the definition of the software model of a
control application.
The programming languages described in IEC
1131-3 can be divided in two families: textual and graphical. Textual languages are: Ins t r u c t i o n List (IL), a low-level (similar to
assembler) language that, because of its 1:1 relation to machine code, is suitable for generating optimized code; S t r u c t u r e d T e x t (ST), a
high-level language, with some resemblance to
PASCAL, suitable for complex computations
on numerical data or any other operation hard
to describe with a low-level language.
Function Block: it is a software element
defined by two parts: (i) a d a t a set,
which describes the input/output parameters that permit connections to the other
POUs (its external interface) and internal
variables that can maintain their value
between two subsequent executions (this
allows storing the state of function block
elaboration); (ii) an a l g o r i t h m , which is
the code executed every time the function
block is called and perform elaboration
on the data set described above.
~a proposal for a revision came during 1999.
600
As said, a Function Block can be programmed in any of the five IEC languages, also using calls to other Function
Blocks, t h a t results in a strong hierarchical decomposition.
the entire program. Another important aspect
of implementing a machine control program under IEC 1131-3 software model is related to its
nested architecture, that suggests a top-down
approach to the designing phase. In practice,
the system is decomposed step by step until elemental devices are recognized. For a manufacturing machine these steps could be determined
by the following decomposition levels:
Function: it is a software element that
differs from Function Block only in the
lack of permanent internal variables (so
that it can't maintain an internal state)
and in having a single output parameter.
(i) Cell: this level corresponds to a work-cell in
which, for example, raw materials are processed
or transported by a belt system between two
neighboring work-cell.
The parametric definition of POUs, in particular Function Blocks, is the major point indicated in the IEC norm for software reuse. For
example, a program may contain several instances of a specific Function Block (FB), each
one independent from the others because it is
executed upon different variables and its internal data is allocated in a reserved memory area.
Furthermore, the same FB can be used in several different programs, reducing time spent on
rewriting code tested for a preceding project.
This means that a growing library of userdefined software blocks can be constructed as
programs end their 'on-the-field' test phase
and show effectiveness. Another notable aspect
of the IEC 1131-3 definition of POUs, related to
hierarchical decomposition, is that FB parameters may even be other FB or Functions. This
means that some functionalities of an FB internal algorithm can be associated to generic FBs,
which will be specified only when an instance
of that FB is called. This mechanism resemble the "genericity" concept of object-oriented
programming languages [7].
(ii) U n i t : it is a subset of devices in a cell
which are related to a particular function. For
example, considering a filling system for a can
machine, the set of devices (actuators and sensors) used by the filling control.
(iii) D e v i c e : the b o t t o m level corresponding
to "atomic" devices, provided directly "offthe-shelf" by manufacturers, even if composed themselves by mechatronic components
(e.g. pneumatic actuators with embedded endstroke sensors).
Once determined the definition of the nested
mechatronic components, the external interface
of the FBs related to control their functioning
is fixed by the input and o u t p u t signals coming
from machine parts. The FBs internal algorithm is then programmed, that could be done
with the help of a user-defined library of FBs
related to standard machine components defined in previous projects. This means that the
designing and programming process for control
application results in a combination of a t o p down and a b o t t o m - u p approach. The first one
is more oriented to the complexity management
of the high-level point of view of the project,
while the second is better suited to deal with
the low-level implementing phase, making easier the maintainability and reuse of the modules. Figure 1 shows the projecting steps on
the left and their results on the right. Vertical arrows should be followed according to the
top-down or b o t t o m - u p approach chosen.
It is evident that the software component appointed to implement the mechatronic objects
model of Section 2 is identifiable in the Function Block (FB). This one is in fact the structure that can encapsulate the functional description of the behavior of a physical object.
Its data section permits to keep memory of preceding executions, so the operative state of the
object is well identifiable. Input and o u t p u t
parameters can represent signals (from sensors
and to actuators) needed by the algorithm of
the FB to control the object it is related to and,
as said above, is part of. Furthermore, input
and output parameters are also the interface of
the object with the rest of the program. This
means that they can be used to represent interlocks and relationships with the rest of the
machine, that is, from a control point of view,
4 A practical example
The projecting methodology discussed in previous sections can be applied to any automated
601
Physical-functional
Modularizatlon
I
Phase ........
I
I
Control Software
Phase
[ ~Re°dyl
KSI t N
FunctionBlocks
-
Reody:= false
St_Mot'.= false
i
q Ok_S
_ oko
Ready[i......
.ot i_
F
OK_SANDNot[OK_DELl-~- NoIIOK_S)
Ready
Start
F i g u r e 3: Sequential Function Chart of the "conveyor" Function Block internal behavior.
F i g u r e 1: The projecting methodology oriented
to mechatronic objects.
motors. The central conveyor differs only in
that it shifts products under a metal detector,
needed to reveal faults 3 , while the last conveyor
differs in that it is controlled by an inverter,
so that the device can signals when the motor
moves at the operative speed, condition necessary to start the first conveyor. This physicalfunctional decomposition leads to the definition
of an elementary class of objects related to a
conveyor type. This object type is composed
by the physical metal conveyor and its motor,
together with the driving electronics needed by
the motor. With regards to controlling aspects
of the 'conveyor' type, it is obvious that it will
result in a FB definition, with an external interface of input variables, that correspond to a
"get ready" and a "go" commands, and output
variables, that correspond to actuating commands going to motor driver. The control algorithm encapsulated in the 'conveyor' FB can be
expressed in any of IEC 1131 languages and, of
course, it will be easy to develop than the entire
control program, because of the small number
of input and output variables. In this paper, a
Sequential Function Chart description has been
chosen, essentially because of its effectiveness
in describing sequential behavior. The SFC diagram is fully described in Figure 3.
._..,,
|
...... Cony r
'-~ Not[OK_S)
MovLL~ N St Mot:=true Start
Software
Modules
Library
programrnlng
Phase
Readyi= true
-'--~OK_SANDOK_DEL
Interface
$
,
N
Objects
l
$
Stucturlng
-~t~
Mechatronic
i
Boxes transportingcell I
F i g u r e 2: Schematic layout of the packaging machine considered.
machine. The packaging machine briefly described in Section 2 can be an effective example, so its detailed analysis is given in the following. The system described in Figure 2 can
be decomposed in four main cells. The first
cell receives products and delivers them to the
following manipulations, so it is mainly composed by transporting conveyors. The s e c o n d
cell is also a transporting system, but its purpose is to put products, falling down from the
preceding conveyors cell, into individual carriers, so they can be easily placed to compose
a matrix that can be picked by the robot in
the following cell. In the r o b o t cell products
are picked up from their individual carrier and
placed in boxes. In the l a s t cell, boxes filled
with well ordered products can proceed to their
final destination: customer.
Next step of the control application construction consists in describing the entire cell behavior, that will be done declaring and using instances of different FBs, either user-defined or
defined in the IEC standard. In this example,
three instances of the FB described above and
As can be seen, the decomposition done at a
machine level can be done also at a cell level,
so the transporting cell results in the combination of three conveyors, powered by identical
athe discarding system is not considered.
602
|
Launch_Cony
r--ioa8
[1] R. Lewis, Programming industrial control
systems using IEC 1131-3. The Institute of
Electrical Engineers, revised ed., 1998.
R...yl-- I
~ _ ~
~ - ~
• NO Emerg --
TRUE
References
/
Detect_Cony
~:-sDel
I
S~M::--
I J. . . .
[
$tarlM2
[2] O. Duran and A. Batocchio, "A highlevel object-oriented programmable controller
programming interface," in ISlE '94 (I. E. S.
IEEE, ed.), pp. 226-230, 1994.
i
[3] F. Bonfatti, P. Monari, and G. Gadda,
"Bridging structural and software design of
PLC-based system families," in ICECCS '95
(IEEE, ed.), pp. 377-384, 1995.
"
LOAD CONV
[4] K. Williams, "Using object oriented analysis and design in a non-object oriented environment experience report," in International
Conference on Sofware Maintenance, pp. 109114, 1995.
Ok_l:~ SLM~|
[5] C. Maffezzoni,
L. Ferrarini,
and
E. Caxpanzano,
"Object-oriented models
for advanced automation engineering," Control
Engineering Practice, vol. 7, no. 8, pp. 957-968,
1999.
F i g u r e 4: Internal implementation of the "transporting_cell" Function Block (with
Function Block Diagram).
[6] I. 1131-3, "Programmable controllers part 3: Programming languages," 1993.
an on-delay timer FB [6] are used. The timer
delays the start of the first conveyor, so the
operative speed of the two following conveyors
is assured before products are forwarded. The
connections between "conveyor" FB instances,
related to the three conveyors that compose the
transporting cell, and the timer is better described with a Punction Block Diagram, shown
in Figure 4.
[7] B. Meyer, Object-oriented software construction. Prentice-Hall, 1997.
[8] R.. Joannis and M. Krieger, "Object oriented approach to the specification of manufactuirng system," Computer-Integrated Manufacturing System, vol. 5, no. 2, pp. 27-35,
1992.
[9] B. Abou-Haider, E. Fernandez, and
T. Horton, "An object-oriented methodology
for the design of control software for flexible
manufacturing systems," in 2nd Workshop on
Parallel and Distributed Real-Time Systems,
pp. 144-149, 1994.
5 Conclusion
This paper has treated the implementation
of the "object-oriented" technology for industrial automation environment. In particular,
have been discussed those aspects that are
strictly related to the peculiar characteristics
of the software for industrial automation, like
the necessity of combining together mechanical and electrical devices, leading to "mechatronic" components, and some characteristics
of the industry standard IEC 1131 norm permitting the implementation of object-oriented
technology. In particular we focused to the use
of FBs that permits module encapsulation and
reuse complying to object-oriented methodology. The paper ends with a simple, real example showing the effectiveness of the concepts
here treated.
[10] M. Andersson, Object-oriented modeling
and simulation of hybrid systems. PhD thesis,
Department of Automatic Control, Lund Institute of Technology, 1994.
[11] J. Rumbaugh, M. Blaha, W. Premerlani,
F. Eddy, and W. Lorensen, Object-Oriented
Modeling and Design. Prentice-Hall, 1991.
[12] B. Douglass, Real-Time UML, developing efficient objects for embedded systems. Addison Wesley Longman, 1999.
[13] R. David and H. Alia, Petri Nets and
Grafcet: Tools for modelling discrete events
systems. Prentice-Hall, 1992.
603