|
Achieving Reconfigurability of Automation Systems by Using the New
International Standard IEC 61499: A Developer’s View
(Copyright CRC Press)
Hans-Michael
Hanisch and Valeriy Vyatkin
Martin Luther University of Halle–Wittenberg, Germany
1
Reasons for a New Standard
The development
of the IEC 61499 has been stimulated by new requirements coming mainly
from the manufacturing industry and by new concepts and capabilities
of control software and hardware engineering.
To survive
growing competition in more and more internationalized global markets,
the production systems need to be more flexible and reconfigurable.
This demand is especially strong in highly developed countries with
high labor costs and individual customer demands. Acting successfully
in such markets means decreased lot sizes and therefore frequent
changes of manufacturing orders that may require changes of the
manufacturing system itself. This means either a change of parts of
the machinery or a change of the interconnection of subsystems by flow
of material.
Each change corresponds to a partial or complete redesign of the
corresponding control system. The more frequent the changes are the
more time and effort has to be spent on the redesign. As a
consequence, there is a growing economic need to minimize these costs
by application of appropriate methodologies of control system
engineering. The desire of control engineers is to reach so called
“plug and play” integration and reconfiguration.
When the
production systems are built from automated units the control
engineers naturally try to reuse the software components of the units.
This is especially attractive in case of a reconfiguration, when the
changes of units functionality may seem to be minor. However, the
obstacles come from the software side.
The currently
dominating International Standard IEC 61131 for programming of
Programmable Logic Controllers (PLCs) [2] is reaching the end of its
technological lifecycle, and its execution semantics do not fit well
into
the new requirements for
distributed, flexible automation systems. The IEC61331 systems rely on
the centralized programmable control model with cyclically scanned
program execution. Integration of this kind of systems via
communication networks may require quite complex synchronization
procedures. Thus, overheads of the integration may be as complex as
the start-over system development. Furthermore, even different
implementations of the same programming language of IEC61131 may have
different execution semantics.
Moreover,
PLCs of different
vendors are not interoperable and require vendor-dependent
configuration tools.
For dealing with
distributed non-heterogeneous systems it would be convenient to define
control applications in a way that is independent from a particular
hardware architecture. However, the architectural concept for such
definition is missing.
These are severe
obstacles towards the plug and play integration and reconfiguration of
flexible automation systems.
The newly
emerging International Standard IEC 61499 [1] is an attempt to provide
the missing architectural concept. The standard defines a reference
architecture for open, distributed control systems. This provides the
means for real compatibility between automation systems of different
vendors. The standard incorporates advanced software technologies,
such as encapsulation of functionality, component-based design,
event-driven execution, and distribution. As
a result,
specific implementations of different providers of field devices,
controller hardware, human-machine interfaces, communication networks,
etc. can be integrated in component-based, heterogeneous systems. The
IEC 61499 standard stimulates the development of new engineering
technologies that are intended to reduce the design efforts and to
enable fast and easy reconfiguration.
This
chapter
provides
an overview of the concepts and design principles of the standard.
For
the
internal details of the standard, the reader is referred to [1], for a
more systematic introduction into the subject
to [4],
and to [7] for the evolution of the idea. Since the design principles
differ considerably from
those of
the well known
IEC 61131,
the
general issues
are introduced
in a
rather intuitive way.
To
illustrate
the design
principles and new features,
an example
is
presented in this chapter.
Real applications – although sparse – do exist but are too complex to
be explained here in detail. The interested reader is referred to [9].
This
chapter is
based on
the publicly available specification (PAS) of the IEC TC65 from March
2000. The final form of the standard is expected in
the
early 2004.
2
Basic Concepts of IEC 61499
The standard
defines several basic functional and structural
entities. They can be used for specification, modeling and
implementation of distributed control applications. Some of them stand
for pure software components. Others
represent logical abstractions of a mixed software/hardware nature. The
main
functional entities are function block types, resource types, device
types, and applications that are built of function block instances.
System configurations include instances of device types and
applications that are placed (mapped) into the devices. The following
sub-sections will briefly discuss all these entities.
The specification
of functionality of
a
control application and the specification of a system architecture can
be performed independently. An implementation of an application on a
given system architecture is done by mapping of its function blocks
onto the devices and their resources. Each function block must be
mapped to a single resource and cannot be distributed over different
resources.
Thus, Section 2.1
discusses the means to define the functionality of a distributed
control application, and Section 2.2 shows how a particular system
configuration can be defined.
2.1
Describing the Functionality of Control Applications
2.1.1
Overview of the Function Block concept
Figure 1.
External interface of a Function Block.
The basic entity
of a portable software component in IEC 61499 is a so-called
function block. The new standard defines several types of blocks:
basic function blocks, service interface function blocks, and
composite function blocks. Although the term function block is known
from IEC 61131, a function block of IEC 61499 is different from
IEC61131 function blocks. Figure 1 shows a function block interface following
the standard (note that the graphical appearance is not normative).
The upper part is often referred to as the “head” and the lower as the
“body” of the function block. A block may have inputs and outputs.
There is a clear distinction between data and event input/output
signals. Events serve for synchronization and interactions among the
execution control mechanisms in interconnected networks of function
blocks. The
concept of
data types is
adopted as in any programming language.
In
particular,
the standard refers to the data types of IEC61131. In the graphical
representation in Figure 1, the event inputs and outputs are associated with
the head of the function block, and the data inputs and outputs are
associated with the body.
The IEC 61499
defines a number of standard function blocks for manipulations with
events, such as splitting or merging events, generation of events with
delays or cyclically, etc.
The definition of
the function block external interface includes also an association
between the events and relevant data. It is
denoted by
vertical lines connecting an event and its associated data
inputs/outputs in the graphical representation. The association
literally means that the values of the variables associated with a
particular event (and only these!) will be updated when the event
occurs.
The IEC61499
standard uses the typing concept of function blocks that is similar to
that in IEC61131 and in the object-oriented programming. Once a
function block type is defined, it can be stored in the library of
function block types and later instantiated in applications over and
over again.
The standard does
not determine in detail the languages to define the internal
functionality of a function block. However, for each type of blocks
the ways of structuring the functionality are identified. These will
be discussed in the following sections.
2.1.2
Basic Function Blocks
Basic function
blocks are software structures intended to implement basic functions
of distributed control applications. The standard says that in
addition to inputs and outputs, the internal structure of a basic
function block may include internal variables, one or several
algorithms, and an execution control chart.
An algorithm is a
structure of finest granularity. It represents a piece of software
code operating on the common input, output and internal data of the
function block. The algorithms can be specified,
for example,
in languages defined in IEC 61131. But in general,
they can be given in any form supported by the implementation
platform. Important
to observe
is that an
algorithm has to be implemented in one programming language. The
internal data of a function block cannot be accessed from outside and
can only
be used by
the internal algorithms of the particular function block.
Figure 2.
A Basic
Function Block.
The execution
control function specifies the algorithm that must be invoked after a
certain input event in a certain state of the execution control
function. It is specified by means of Execution Control Charts (ECC
for short). Figure 3 shows an example. An Execution Control Chart is a
finite state machine with a designated initial state. An ECC consists
of states with associated actions (designated by ovals in the
Figure) and of state transitions (designated by arrows). The actions
contain algorithms to invoke and output events to issue upon the
completion of the algorithms’ execution.
Each state
transition is labeled with a BOOLEAN condition that is a logic
expression utilizing one or more event input variables, input
variables, output variables, or internal variables of the function
block. The event inputs are represented in the conditions as BOOLEAN
variables that are set to TRUE upon an event and cleared after all
possible state transitions (initiated by a single input event) are
exhausted.
Figure 3.
An
example
of the Execution Control Chart [1].
An input event
causes the invocation of the execution control function that in
more detail is as follows (see Figure 4):
Step 1: The
input variable values relevant to the input event are made available.
Step 2: The
input event occurs, the corresponding BOOLEAN variable is set, and the
execution control of the function block is triggered.
Step3: The
execution control function evaluates the ECC as follows. All the
transition conditions going out of the current ECC state are
evaluated. If no transition is enabled, then the procedure goes to the
Step 8. Otherwise, if one or several state transitions are enabled
(i.e. if the corresponding conditions evaluated to TRUE), a single
state transition takes place.
The current state is substituted by the following one. The algorithms
associated with the new current state will be scheduled for execution.
The execution control function notifies the resource scheduling
function to schedule an algorithm for execution.
Step 4:
Algorithm execution begins.
Step 5: The
algorithm completes the establishment of values for the output
variables.
Step 6: The
resource scheduling function is notified that algorithm execution has
ended.
Step 7: The
scheduling function invokes the execution control function. The
procedure resumes from the Step 3.
Step 8:
When some of the output event variables were set during this
invocation of the execution control function then the execution
control function signals the corresponding event output and clears the
BOOLEAN variables corresponding to the triggered input and output
events.
Figure 4.
Execution of a Function Block.
First conclusions
can be drawn at this point:
-
A
Basic Function Block is an abstraction of a software component
adjusted for the needs of measurement and control systems. Its
execution semantic is event-driven and platform independent. Basic
Function Blocks are intended to be main instruments of an application
developer.
-
The
standard implies separation of the functions, implemented by
algorithms, from the execution control. The algorithms encapsulated in
a function block can be programmed in different programming languages.
-
The
execution of function blocks is event-driven. This means that
algorithms are executed only if there is a need to execute them in
contrast to the cyclically scanned execution in IEC 61131. The need
has to be indicated by events. The source of events can be other
function blocks. Some of them may encapsulate interfaces to the
environment (controlled process, communication networks, hardware of a
particular computational device).
-
The
execution function of a Basic Function Block is defined in a form of a
state machine that is available for documentation and specification
purposes even if the algorithms are hidden.
-
The
function block abstracts from a physical platform (the resource)
on
which it is
located. This means that the specification of the function block can
be made without any knowledge of the particular hardware on which it
will be later executed.
2.1.3
Composite Function Blocks
The standard also
defines Composite Function Blocks, functionality
of which,
in contrast to Basic Function Blocks, is determined by a network of
interconnected function blocks inside. Figure 5 shows the principle.
Figure 5.
Composite Function Block.
More precisely,
members of the network are instances of function block types. These
can be either Basic Function Blocks,
or other Composite Function Blocks. Therefore, hierarchical
applications can be built.
It is important
to note that Composite Function Blocks have no internal variables,
except for those storing the values of input and output events and
data. Thus, the functionality of Composite Function Blocks completely
depends on the behavior of the constituent function blocks and their
interconnections by events and data.
Along with Basic
Function Blocks, the Composite Function Blocks are intended to be main
instruments of an application developer.
2.1.4
Service Interface Function Blocks
In contrast to
Basic and Composite Function Blocks, Service Interface Function Blocks
are not intended to be developed by an application developer. These
have to be provided by vendors of the corresponding equipment, e.g.
controllers, field buses, remote input/output modules, intelligent
sensors, etc. The application scope determines the differences of this
kind of function blocks from the previously considered ones.
To hide the
implementation-specific details of the system from the application,
the IEC 61499 defines the concept of services the system provides to
an application. A service is a functional capability of a resource
that is made available to an application. A service is specified by a
sequence of service primitives which define properties of the
interaction between an application and a resource during the service.
The service primitives are specified in a graphical form of the
time-sequence diagrams described in Technical Report 8509 of the
International Standard Organization (ISO) [3]. This is rather a
qualitative specification form as it does not specify exact timing
requirements to the services. An example of time-sequence diagrams is
presented in Figure 7 and will be briefly discussed later in this
section.
Figure 6.
Generic
REQUESTER [1].
A Service Interface Function Block is an abstraction of a software
component implementing the services. Figure 6 shows an example of a Service Interface Function
Block REQUESTER that provides some service upon request to an
application (examples of possible services: read the values of
sensors, increase the memory used by a resource, shut down a resource,
send a message, access remote database, etc.). The standard
pre-defines some names for input/output parameters of Service
Interface Function Blocks such as INIT for initialization, INITO for
confirmation of the initialization, QI for input qualifier, etc.
Some of the
services provided by this block are specified in
the
form of
time-sequence diagrams in Figure 7. These are “normal establishment”
of the service, “normal service”, and “application initiated
termination” of the service.
The input event
INIT serves for initialization / termination of the service, depending
on whether the BOOLEAN input QI is true or false. The notation INIT+
means the occurrence of the event INIT with the qualifier value QI=true,
and INIT- correspondingly with QI=false.
The input
parameter PARAMS stands for the service parameters that have to be
taken into account during the service initialization. At the end of
the initialization/termination procedure, the Service Interface
Function Block responds by event INITO its completion and indicates
by the BOOLEAN data output QO whether initialization / termination was
successful (QO=true) or not (QO=false).
Figure 7.
Diagrams
of service sequences for application-initiated interactions.
The input data
needed to perform the service are denoted as inputs SD_1 ... SD_m.
Note that these data are associated with the event input REQ. The data
outputs RD_1 ... RD_n stand for the data computed as a result of the
service. These data are associated with event CNF that represents
confirmation of the service. The output STATUS provides information
about the status of the service upon the occurrence of an event
output.
The execution of
Service Interface Function Blocks is initiated by input events. The
internal structure of Service Interface Function Blocks is not
specified as firmly as for Basic Function Blocks. For example, a
programming implementation of a Service Interface Function Block can
be done in
the
form of several
encapsulated algorithms (methods, procedures) that are invoked upon a
particular event (say algorithm init stands for the event
INIT). The algorithms may check the value of the qualifier QI and
call then either the subroutine responsible for the “normal service
establishment” (if QI=true) or the one responsible for the
“application initiated termination” (if QI=false). Note that the
concept of Service Interface Function Blocks does not presume the need
for internal variables – the conditions for initiating services are
described by input events and data (qualifiers).
A particular case
of Service Interface Function Blocks are Communication Interface
Function Blocks. The standard explicitly defines two generic
communication patterns: PUBLISH/SUBSCRIBE for uni-directional
transactions and CLIENT/SERVER for bi-directional communication. These
patterns can be adjusted to a particular networking or communication
mechanism of a particular implementation. Otherwise, a provider of
communication hardware/software can specify his own patterns if they
differ from the above mentioned ones. Figure 8 illustrates the generic PUBLISH and SUBSCRIBE
blocks performing uni-directional data transfer via a network.
Figure 8.
Publish and Subscribe communication interface blocks.
The PUBLISHER
serves for publishing data SD_1 ... SD_m that come from one or more
function blocks in the application. It is therefore initialized /
terminated by the application in the same way as described above.
Upon the
request-event REQ from the application, the data that need to be
published are sent by the PUBLISHER via an implementation-dependent
network. When this is done, the PUBLISHER informs the publishing
application via event output CNF.
The SUBSCRIBER
function block is initiated by the application that reads the data
RD_1 ... RD_m in the same way as described above. Normal data transfer
is initiated by the sending application via the REQ input event to the
PUBLISHER. This is illustrated in Figure 9 by means of time-sequence diagrams. The PUBLISHER
sends the data and triggers the IND-event at the outputs of the
SUBSCRIBER to notify the reading applications that new values of data
are available at RD_1 ... RD_m outputs of the SUBSCRIBER. The reading
application notifies the SUBSCRIBER by the RSP-event that the data are
read.
Figure 9.
Communication establishment and normal data transfer sequence.
In summarizing
this subsection,
one can see that Service Interface Function Blocks implement the
interface between an application and the specific functionality that
is provided by control hardware or system software. The content of
Service Interface Function Blocks can be hidden, but the means are
reserved to specify their functionality in a visual form.
2.1.5
Application
An application
following IEC 61499 is a network of function block instances whose
data inputs and outputs and event inputs and outputs are
interconnected (see Figure 10).
Figure 10.
An
application .
An application
can be considered as an intermediate step in the system development.
It already defines the desired functionality of the system completely,
but it does not specify the system’s structure in terms of
computational devices where the function blocks can be executed. The
next step in the engineering process is to define a particular set of
devices and to “cut” the application, assigning the blocks to the
devices as illustrated in Figure 11.
Figure 11.
The application distributed onto two devices.
The way in which
the separated parts of the distributed applications communicate with
each other has to be explicitly defined. This can be done by adding
Communication Function Blocks in the places where the “cut” took place
(see Figure 12).
A network of
function blocks (forming the application) can be encapsulated in a
Composite Function Block if needed. In this case, however, it could
not be distributed across several devices or resources as a function
block can be executed only in a single resource.
Figure 12.
Communication Function Blocks explicitly connecting parts of the
distributed application.
In fact,
the standard provides a structure (called subapplication) that
combines features of Composite Function Blocks and of applications.
The content of a subapplication can be distributed across several
devices. However, practical applicability of this structure is quite
questionable.
The following
subsection will show the concepts and specifications of a system
following IEC 61499 as a platform for implementation and execution of
an application.
2.2
Specification of the System Architecture
A device in
IEC61499 is an atomic element of a system configuration. The standard
provides architectural frames for creating models of devices,
including their subdivision in computationally independent resources.
A device type
(Figure 13) is specified by its process interface and
communication interfaces. A device can contain zero or more resources
(see the description below) and function block networks (this option
is reserved for the devices having no resources).
Figure 13.
A device
model.
A "process
interface" provides a mapping between the physical process (analog
measurements, discrete I/O, etc.) and the resources. Information
exchanged with the physical process is presented to the resource as
data or events, or both.
Communication
interfaces provide a mapping between resources and the information
exchanged via a communication network. In particular, services
provided by communication interfaces may include presentation of
communicated information to the resource and additional services to
support programming, configuration, diagnostics, etc.
The interfaces
are implemented by the libraries of corresponding Service Interface
Function Blocks. The libraries of these blocks form the “identity” of
a device. A device that contains no resources is considered to be
functionally equivalent to a resource.
A resource
(Figure 14) is considered to be a functional unit, contained
in a device, that has independent control of its operation. It may be
created, configured, parameterized, started up, deleted, etc., without
affecting other resources within a device. The functions of a resource
are to accept data and/or events from the process and/or communication
interfaces, process the data and/or events, and to return data and/or
events to the process and/or communication interfaces, as specified by
the applications utilizing the resource.
Furthermore, a
resource provides physical means for running algorithms. This means
storage for data, algorithms, execution control, events etc. It also
has to provide software capabilities for managing and controlling the
function blocks’ behavior, scheduling its algorithms (scheduling
function), etc.
Figure 14.
A model of resource.
2.2.2
System Configuration
A system is a
collection of one or more devices (Figure 15). The devices communicate with each other over
communication networks. Also the devices are linked with the
controlled process via sensor and actor signals.
Figure 15.
A system
configuration.
Applications are
mapped on
to the
devices. This means that their function blocks are assigned to the
resources of the corresponding devices. In this way a system,
configuration is formed. A system configuration is feasible if each
device in it supports the function block types that are mapped on it.
Otherwise, the block would not be instantiated, and the system will
not run.
3
Illustrative example
3.1
Desired Application Functionality
The example
“FLASHER” that is used in this section was borrowed from the set of
samples provided with the Function Block Development Kit (FBDK). This
is the first software tool supporting IEC61499 system development. It
was developed by Rockwell Automation,
USA. The toolset
can be downloaded from [5]. The example represents an abstraction of
an automation system. It is supposed to make 4 lamps blinking
according to a preprogrammed mode of operation.
The system
consists of human-machine interface components and of a core
functional component. The core component generates the output signals
determined by input parameters. The output values are delivered then
to the visualization device (lamps). In the form presented here, the
system is completely simulated in a computer. All human-machine
interface components and lamps exist only on the computer screen. The
example visually shows how easy each of the software components that
interact with a simulated object can be replaced by components that
would interact with the real physical equipment (e.g. buttons,
switchers, knobs). After such a reconfiguration, the whole system will
show then the same functionality without changing its structure and
without redesign of the other components.
Figure 16.
FLASHER
in centralized system configuration.
Figure 16 shows a screenshot of the FBDK containing a system
configuration. As a result of its execution, the output frame is
produced. The output frame is located in the Figure below the FBDK
screen. The arrows connect the function blocks with the screen objects
created by them.
The system
configuration includes one application. It is placed in one device
with only one resource. An instance of the device type FRAME_DEVICE is
used in this example. This type of device creates a windows frame on
the computer screen. The resource of type PANEL_RESOURCE creates a
rectangular panel within this frame. If a function block creates an
output to the screen, it will be placed in the corresponding panel.
In this
particular case, the system configuration implements the application
in a centralized fashion. The application includes all the blocks
shown in Figure 16 in the shaded rectangular area. The only block
which falls out of the application is the block START of type
E_RESTART. It belongs to the resource type PANEL_RESOURCE.
The application
creates the following models of human-machine interface primitives.
Buttons START and STOP are created by the blocks START_PB and STOP_PB.
Both are instances of the type IN_EVENT. Block DT creates the input
field for the TIME parameter. It is an instance of type IN_ANY. Block
MODE creates the pull-down menu to select a desired mode of operation.
The block that
produces the output combination is FLASHIT. It is an instance of type
FLASHER4. The output values are visualized then by the block LEDS of
type LED_HMI. The FLASHER4 generates the output values at every input
pulse of the input REQ. The pulses are generated by the block PERIODIC
with the frequency determined in the field that is created by the
block DT.
The operation of
the system configuration is started when the resource is initialized,
for example when the device is created (or switched on for more
realistic devices). At that moment the Service Interface Function
Block START produces the event COLD (cold restart). It is connected to
the input event INIT of the block START_PB. This input event causes
the block of type IN_EVENT to place a button image in the resource’s
panel. The caption of the button is given by the input parameter
“LABEL” of the block, i.e. “START” in our case. After that, an output
event INITO is generated that is connected to the input INIT of the
block STOP_PB. It leads to the creation of the button “STOP” and so
forth in the chain until the whole picture is created on the resource
panel as shown in Figure 16.
Once a button
START is pressed (e.g. by a mouse click), it ignites the event output
IND. This event propagates through the chain of blocks DT and
PERIODIC. It makes the latter to generate the output event EO with the
desired frequency. Every moment the event comes to the input REQ of
the FLASHIT, the output combination of LED0..LED3 is created, and the
output event CNF notifies the block LEDS which updates the picture.
If the operating
mode is changed during the operation, the corresponding event
IND
of the block MODE would notify the FLASHIT. Then FLASHIT will change
the pattern according to which its outputs are generated.
Figure 17.
FLASHER4: Execution Control Chart.
A more detailed
description of the function block type FLASHER4 is given now. Figure
17 shows the Execution Control Chart of this block.
The state machine either switches to the desired algorithm
corresponding to the selected MODE of operation (number in the
interval 1..5) at input event REQ, or to the initialization algorithm
INIT at the input INIT.
Note that one
half of the algorithms encapsulated in the FLASHER4 is programmed in
Structured Text (ST), while the other half is programmed in Ladder
Logic Diagrams (LD). This is shown in Figure 18 and Figure 19. This illustrates the opportunities the IEC61499
function blocks provide to reuse the legacy code and even to combine
different programming languages in a single software component.
Figure 18.
Algorithm COUNT_UP programmed in structured text.
Figure 19.
Algorithm CHASE_UP programmed in ladder logic.
3.2
Distribution
The distributed
version of the same application is shown in Figure 20. The system configuration includes two devices:
CTL_PANEL and FLASHER. The function blocks of the application are
mapped to either of these devices. In addition, the Communication
Function Blocks PUBLISH and SUBSCRIBE are added to connect the parts
of the application. The devices may be started or shut down completely
independently from each other. As soon as the part located in
CTL_PANEL produces any changes in the operation parameters, it will
notify the FLASHER’s part via the communication channel.
Figure 20.
Application FLASHER distributed across 2 devices.
Figure 21 shows a distribution of the same application across
three devices. Device “FLASHER” (on the right) produces no picture. It
produces the output values and sends them to the device DISPLAY given
the input parameters received from the CTL_PANEL.
Figure 21.
Distribution of the FLASHER application across 3 devices.
4
Engineering Methods and Further Development
In contrast to
present practice of IEC 61131, the specification of a control system
following IEC 61499 is a complete change of paradigms. Execution of
control code in IEC 61131 is sequential and time-driven. The control
engineer who uses the IEC 61499 needs to think in terms of
event-driven execution of encapsulated pieces of code. The execution
is distributed and concurrent. This requires new methodologies for
control system design, verification/validation, and implementation.
A natural way of
system engineering using IEC61499 is a method with the following
steps:
1.
Identification of the functionality of system components.
2.
Encapsulation of basic functionality in these components. This gives
the Basic Function Blocks or even Composite Function Blocks.
3.
Interconnection of the function blocks to build an application.
External coordination of the network of function blocks may be needed
and added.
4.
Mapping of the application
in
o a control
system architecture.
At least the
following questions must be answered to make such a methodology
applicable.
o
How
to encapsulate the existing controllers (sometimes implementing very
sophisticated ad hoc algorithms) into new event-driven capsules?
o
How
to specify the component controllers in a way allowing
(semi-)automatic integration into distributed systems?
o
Conversely, given a desired behavior of the integrated system, how to
decompose it to the control actions of the component controllers?
This requires
further research and development, in particular around the concept of
Automation Objects [11]. The concept of Automation Objects is
understood as a framework for encapsulation and handling of the
diverse knowledge relevant to automation systems. This includes
operation semantics as well as layouts, CAD data, circuitry, etc. As
the scope of IEC61499 cannot cover all these issues, it probably needs
to be combined with ideas arising from other developments, in
particular with IEC68104 [12] for more detailed description of device
types.
Conducting such
a
work requires
integration of development activities among leading vendors and users
of automation technologies on a global scale. Currently, such an
activity is being organized under support of the Intelligent
Manufacturing Systems Research and Development program (www.ims.org)
in the form of OOONEIDA project [13].
Currently
available engineering methodologies can be found in [6,10]. Also the
idea of combining Unified Modeling Language (UML) with the IEC61499
promises to provide a consistent engineering methodology for control
system engineering. Some details on that can be found in [11].
Another major
future issue is how to bring the ideas of reconfiguration to practical
applications. The standard itself provides the following means.
1.
Basic Function Blocks do not depend on a particular execution
platform. They will show equivalent execution semantics on different
platforms, regardless, for example, in which sequence they are listed.
This is not the case in the current implementations based on IEC
61131.
2.
The
functionality of whole applications that are represented as
hierarchical networks of function blocks also does not depend on a
particular number and topology of computational resources. Thus,
system engineering can be done in an implementation independent way.
3.
Models of various devices are represented as device types. This will
allow anticipation of the system’s behavior after reconfiguration. On
the one hand, the way of modeling of devices and resources is very
modular. On the other hand, it uses a very limited number of
constituent instruments. It allows modeling of a great variety of
system configurations without going to unnecessary details.
4.
There are also more technical concepts for reconfiguration. One is
the use of adapter interfaces to minimize inter-block connections by
means of predefined patterns. Another one are standard function blocks
for manipulations with events. This, however, goes beyond the scope of
this contribution.
Another open
question for future research and development is how the correctness of
the system can be validated. This requires more formal models for
simulation or even for formal analysis of the behavior. The concept of
encapsulation is extremely useful for embedding such models in the
design. In principle, it allows modeling of the whole measurement and
control systems with all their diverse components, such as sensors and
actuators, networks, computational resources etc. The models could
reproduce the execution semantics of the real system taking into
account also such factors as communication delays of particular
networks. Moreover, models of the controlled objects can be
encapsulated in function blocks as well This allows to study the
behavior of the controller and the controlled object in closed loop.
Desired properties could be validated by simulation or even formally
verified. A first approach for formal modeling and verification of
IEC61499-compliant designs was applied in [8]. This approach can also
be used for prototyping of the distributed control systems based on
their formal models.
It is obvious
that all these future developments must be supported by appropriate
tools, compliant devices, runtime systems, etc.
Last but not
least, there is a considerable need for training and education of
engineering staff to understand and to apply the new concepts of the
standard.
Nonetheless,
despite of the amount of development that still lies ahead, the
potential benefits of
using
IEC 61499 are
very clear, and the ideas and concepts define cornerstones of future
development and design of distributed control systems.
5
Acknowledgements
The authors thank
Sirko Karras for help in managing the graphic material of this
contribution. The authors furthermore express their gratitude to
Rockwell Automation and personally to Dr. James Christensen for
providing the FLASHER example, for the permission of using Figures 8
and 9, and for the fruitful ideas expressed in the personal
communication.
6
References
1.
Function Blocks for Industrial Process Measurement and Control
Systems. Publicly Available Specification, International
Electrotechnical Commission, Part 1: Architecture, Tech. Comm. 65,
Working group 6, Geneva, 2000.
2.
International Standard IEC 1131-3, Programmable Controllers - Part 3,
International Electrotechnical Commission, 1993, Geneva,
Switzerland
3.
ISO
TR 8509-1987, Information processing systems - Open Systems
Interconnection - Service conventions
4.
R.
Lewis: Modeling Distributed Control Systems using IEC 61499,
Institution of Electrical Engineers;
London,
2001, ISBN: 0852967969
5.
www.holobloc.com – web site devoted to IEC61499.
6.
J.H.
Christensen: IEC 61499 ARCHITECTURE, ENGINEERING, METHODOLOGIES AND
SOFTWARE TOOLS, 5th IFIP International Conference BASYS’02,
Proceedings, Cancun, Mexico, September, 2002
7.
R.
Schoop and H.-D. Ferling: Function Blocks for Distributed Control
Systems, DCCS’97, Proceedings, pp.145--150
8.
Vyatkin V., Hanisch H.-M.: Verification of Distributed Control Systems
in Intelligent Manufacturing, Journal of Intelligent Manufacturing,
vol.14, N.1, 2003, pp.123-136
9.
Vyatkin V., “Intelligent
Mechatronic Components: Control System Engineering using an Open
Distributed Architecture”, IEEE Conference on Emerging Technologies
and Factory Automation (ETFA'03), Proceedings, vol. II, pp.277—284,
Lisbon,
September, 2003
10.
C.
Tranoris and K. Thramboulidis, “Integrating UML and the Function Block
Concept for the Development of Distributed Applications”, IEEE
Conference on Emerging Technologies and Factory Automation (ETFA'03),
Proceedings, vol.II, pp.87—94, Lisbon, September, 2003
11.
IEC
61804 Function Blocks for Process Control, Part 1 - General
Requirement; Part 2 - Specification, Publicly Available Specification,
International Electrotechnical Commission, Working group 6,
Geneva,
2002
12.
Automation Objects for Industrial-process Measurement and Control
systems, Working draft , International Electrotechnical Commission,
Technical Committee No. 65
13.
OOONEIDA: open object-oriented network economy in intelligent
industrial automation: a proposal for an international research and
development project. Official web-site:
http://www.oooneida.net
Copyright notice:
In The Industrial Information Technology Handbook, Zurawski R.
(Ed.), CRC Press, Boca Raton, FL, 2004. With permission
|
