See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4367046

Considering IEC 61131-3 and IEC 61499 in the context of component frameworks

Conference Paper · August 2008

DOI: 10.1109/INDIN.2008.4618109 · Source: IEEE Xplore

CITATIONS READS
41 553

5 authors, including:

Christoph Sünder Alois Zoitl

TU Wien Johannes Kepler University Linz
47 PUBLICATIONS 1,058 CITATIONS 300 PUBLICATIONS 3,905 CITATIONS

SEE PROFILE SEE PROFILE

James H. Christensen Heinrich Steininger

Holobloc Inc Independent Researcher
60 PUBLICATIONS 1,405 CITATIONS 14 PUBLICATIONS 180 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by James H. Christensen on 11 February 2020.

The user has requested enhancement of the downloaded file.

 Considering IEC 61131-3 and IEC 61499
in the context of Component Frameworks
Christoph Sünder1, Alois Zoitl1, James H. Christensen2, Heinrich Steininger3, Josef Fritsche4
1
Vienna University of Technology, Gusshausstraße 27-29/376, 1040 Vienna, Austria
2
Holobloc Inc., Cleveland, Ohio, USA
3
Logi.cals Austria—kirchner SOFT GmbH, Mailüfterlweg 1, 3124 Oberwölbling, Austria
4
Bachmann electronic GmbH, Kreuzäckerweg 33, 6800 Feldkirch-Tosters, Austria
{suender, zoitl}@acin.tuwien.ac.at; [email protected]; [email protected]; [email protected]

NOTE – This is a pre-publication draft!

 Abstract- Automation and control systems provide their own IEC 61131-3 and IEC 61499 in [6]. The idea of a platform that
programming and modeling paradigms in parallel to theory well supports any control logic concerning to either one of the two
known from computer science. Especially the concepts of
component-based software engineering highly influence the design standards may be taken into consideration from three different
of embedded systems, which include automation and control viewpoints:
systems. This work analyses what is and is not a “software (1) Loosely coupled systems: In this approach, interaction
component” in the context of the two standards IEC 61131-3 and between the various systems is provided by a defined interface,
IEC 61499. Utilizing the definition of component frameworks and e.g. the communication function blocks defined in part 5 of
component system architectures, the potentials and problems of
an integrative approach in order to utilize both standards within IEC 61131 [7]. The runtime environments for each of the
the same platform will be discussed. standards are considered as stand-alone system, only by use of
some communication ports interoperability may be achieved.
(2) IEC 61131-3 based system: In this approach, execution
I. INTRODUCTION of IEC 61499 control logic is enabled within an IEC 61131-3
runtime environment. This approach has been implemented in
The standard IEC 61131-3 [1] is widely supported for a wide a commercial product by ICS Triplex [8]. As a consequence,
range of automation and control applications. Nearly every the cyclic execution of IEC 61131-3 is introduced in
Programmable Logic Controller (PLC) manufacturer provides IEC 61499, and some new aspects of IEC 61499 are neglected.
support for the programming languages defined by the One advantage of this approach is that connections between
standard. During the last 15 years, the International function blocks (FBs) of IEC 61131-3 and IEC 61499 are
Electrotechnical Commission (IEC) has developed a new possible.
standard dedicated to the field of automation and control (3) IEC 61499 based system: In this approach, execution of
systems, the IEC 61499 standard [2]. The reasons for the new IEC 61131-3 control logic is based on an IEC 61499 runtime
standard are manifold, for instance support for distribution as environment. This concept envisages the usage of new
well as dynamic reconfiguration. The development has been concepts introduced by IEC 61499 within existing systems
motivated by studies such as “Agile Manufacturing” from the based on IEC 61131-3.
Iacocca Institute [3]. Recently conducted surveys such as the The aim of this paper is to investigate the third possibility, as
MANUfuture Strategic Research Agenda [4], which is one of the discussion in [6] has pointed out this approach to be highly
the platforms that are integrated in the definition of the frame advantageous from different aspects: (i) enhancement of the
programs of the European Union, claim the same objectives. possibilities of existing IEC 61131-3 implementations, (ii) tight
The IEC 61499 standard seems to provide a good basis for coupling of IEC 61499 control logic to existing IEC 61131-3
these requirements, its main principles being, in addition to applications, and (iii) the ability to distribute also IEC 61131-3
those mentioned above: FB networks. The basis for this work is a well known approach
Portability: The ability of software tools to accept and from computer science, component-based software
correctly interpret library elements produced by other software development. Based on a short introduction and definition of
tools. terminology in Section 2, we will discuss the mapping of
Configurability: The ability of devices and their software software components to the elements of the two standards
components to be configured (selected, assigned locations, IEC 61131-3 (Section 3) and IEC 61499 (Section 4). We will
interconnected and parameterized) by multiple software tools. analyse the potentials and problems concerning a usage of both
Interoperability: The ability of devices to operate together to standards within a common component system architecture in
perform the functions specified by one or more distributed Section 5. The paper summarizes with conclusions in
applications. Section 6.
These objectives are missing in the IEC 61131 standard, and
II. COMPONENT-BASED SOFTWARE DEVELOPMENT:
hence are also missing in various IEC 61131-3 compliant INTRODUCTION AND TERMINOLOGY
products. Currently PLCopen (IEC 61131 user organization)
has defined an XML-based format [5] to provide portability The paradigm of component-based software development
also for IEC 61131-3 engineering systems, but configurability has become very important in the field of embedded systems
and interoperability are still missing. This is a great during recent years. As automation and control systems may be
disadvantage for users of IEC 61131 systems. With the new considered as a special class of embedded systems, this
standard IEC 61499, the situation seems to be even worse. The approach is also interesting for this field. The main elements of
users have invested reasonable amount of workforce into the this technology, software components, are introduced as
development of their applications and are not willing to start entities that may be composed to larger parts in order to fulfill
again from scratch. And the opportunity to use IEC 61131-3 system requirements. They can be considered in different
programming languages within algorithms of IEC 61499 basic shapes, from black boxes to gray and white boxes. And they
function blocks does not solve this problem. enable practical reuse of software parts and amortization of
The authors of the present paper have discussed several investments over multiple applications. In order to use clear
approaches in order to enable a symbiosis of both standards,
terminology for component-based software development, we The international standard IEC 61131 provides a set of eight
will refer to the definitions given by Szyperski [9]. parts concerning PLCs and their associated peripherals. The
“A software component is a unit of composition with most important part is (IEC 61131-3, 2003), which defines
contractually specified interface and explicit context programming languages, data types, and a software
dependencies only. A software component can be deployed architecture for PLCs.
independently and is subject to composition by third parties.”
A. Software model
([9], Section 4.1.5) There are three main characteristic
The main elements of the software architecture defined in
properties of a software component according to this definition
IEC 61131-3 are given in Fig. 1. The top element is called a
([9], Section 4.1.1):
configuration and represents a programmable controller (this
Unity of independent deployment: This property requires
term is used by the standard for a PLC). A configuration
for a clear separation from the software component’s
consists of one or more resources, which represent a signal
environment and other software components. Further, a
processing function. A resource consists of tasks and
software component will never be deployed partially.
programs. A task is an execution control element that provides
Unity of third-party composition: A third party means
periodic or triggered execution of associated program
someone that has no access to the construction details of all the
organization units (POUs). This association is depicted by the
components involved. Nevertheless, a third party has to be able
execution control paths in Fig. 1. In general POUs may be
to compose a software component with other software
programs, function blocks (FBs), or functions. Programs can
components. Therefore, a software component needs to be self-
only be instantiated within resources, while FBs can be
contained.
instantiated within programs and FBs. The difference between
No (externally) observable state: It is required that a
functions and FBs is that functions shall contain no internal
software component cannot be distinguished from copies of
state information.
itself.
Data types: (IEC 61131-3, 2003) defines a set of elementary
For the further discussion on an integration of the elements
data types, such as integers, strings, or real numbers, a
of IEC 61131-3 and IEC61499, some more definitions will be
hierarchy of generic data types in order to enable overload
helpful, which are noted in ([9], Section 20.4): “A component
mechanisms, and so-called derived data types. The last one
framework is a dedicated and focused architecture, usually
describes user-defined data types that are derived from the
around a few key mechanisms, and a fixed set of policies for
existing data types, for instance an enumeration or a structure.
mechanisms at the component level. … A component system
Variables: Variables are data objects associated with the
architecture consists of a set of platform decisions, a set of
inputs, outputs, or memory of the PLC. A variable can be
component frameworks, and an interoperation design for the
declared to be one of the elementary or derived data types.
component frameworks.”
There exist several variants of variables, which have important
Accordingly, the component framework and its policies are a
influence on the PLC programming methodology. A detailed
very important issue when thinking about component-based
list is given in ([1], Table 16). Some examples are directly
software development. With regard to this work of integration
represented variables (provide access to data elements with
of two different standards, the definition of component system
physical or logical locations in the PLC’s input, output, or
architecture is of special interest. When we consider each of
memory structure), VAR_GLOBAL (defines variables that can
the two standards as component architecture, the purpose of
be used within the whole scope of a configuration or resource,
integration of the standards is to define an appropriate
VAR_ACCESS (defines variables that can be used for remote
component system architecture, which provides a proper
access via the communication services specified in [7]), or
interoperation design. Obviously, both standards may violate
VAR_EXTERNAL (specifies that an organization unit has
the pure definition of software components in some details. But
access to a globally defined variable).
from a coarse point of view, the IEC 61131-3 component
framework may have evolved to the IEC 61499 component
framework. This is definitely true for the standardization
group, as the same people have developed the IEC 61499
standard after finishing their work on IEC 61131-3. But from a
practical point of view, current available implementations seem
to be more interested in achieving competitive advantages than
to provide a seamless integration. The motivation of this work
is therefore already given in ([9] Section 24.7) as “besides
coexistence of multiple versions, adaptation of incompatible or
older software using wrapper components is required to
address ‘legacy migration’ problems”.
III. IEC 61131-3 ELEMENTS
 Structuring of programs and FBs: A POU is considered as
a single action which is executed under control of the invoking
entity. Additional structuring for programs and FBs is possible
by means of the Sequential Function Chart (SFC) construct.
Herein actions are associated with states, and the active state
evolves according to interrelation of states via transitions and
evaluation of the transition conditions. For specification of
actions, [1] defines four programming languages, namely
Instruction List (IL). Structured Text (ST), Ladder Diagram
(LD), and Function Block Diagram (FBD).
B. Software components within IEC 61131-3 Fig. 2. IEC 61149 models, [2]
In order to find a relationship of the IEC 61131-3 constructs
and the paradigm of component-based software development
we will consider different scenarios for a mapping with the
Fig. 1. IEC 61131-3 software model, [1]
above mentioned definitions for software components and
component frameworks. In this context, the definition and Resource as software component: A resource includes
description of interfaces are very important. The interface has information about the control logic via the used program
to be defined in a clear manner and (as denoted in the instances as well as the execution behavior via the included
definition for a software component) represents a contract in tasks and their parameters. This reults in a rich description of a
order to separate the software component from the component resource as a software component. Nevertheless, there exists
framework and other components. There should not exist any also the VAR_EXTERNAL construct which enables an
hidden interface that may influence the behavior of a software interface with no behavior description in the resource.
component. Kopetz [10] describes such hidden interfaces for a Therefore a resource cannot be considered as a software
component-based distributed real-time system. He claims that component.
this leads to incorrect results when reasoning about the Configuration as software component: The configuration is
correctness of a composition. the highest level in the software model of IEC 61131. A global
Function as software component: A function is the most variable within the configuration would be an internal state of a
restricted element within the IEC 61131-3 software model. It software component and fulfils the requirements for a software
does not include state information and is not allowed to use the component. The interface of a configuration is given by the
VAR_EXTERNAL construct. Therefore, its interface and VAR_ACCESS definition. In case of a read-only restriction for
behavior is clearly described and a function can be seen as such an access path the output of a software component would
software component. be defined. Otherwise an input is defined without clear
FB as software component: A FB is able to have state behavior description, which is again a problem when
information; this does not contradict its mapping as a software considering the mapping to a software component. This is
component. But there exists additionally the especially problematic, when thinking of the use of network
VAR_EXTERNAL construct, which enables the relation to variables in order to establish communication between
any other element within a configuration or resource. The configurations.
interface is only described by use of a data element without
any further description of the behavior of this interface. If the IV. IEC 61499 ELEMENTS
counterpart (and even the number of these counterparts is not The IEC 61499 standard consists of four parts. Part one
limited) is related to another task with different execution (IEC 61499-1, 2005) includes all definitions and models in
settings, the behavior of a FB is in conflict with the principles order to describe the architecture of the standard. The above
of a software component. discussed portability, configurability and interoperability issues
Program as software component: Roughly speaking there is are mainly solved by the definition of compliance profiles,
no difference between a program and a FB instead of the which are a means to specify implementation dependent details
reusability of FB types. Therefore, the same argument of a given product.
concerning the VAR_EXTERNAL construct is true also for
programs. Another problem occurs from the execution control A. Basic architecture
of FBs within programs. As depicted also in Fig. 1 a FB within The architecture of the IEC 61499 standard is described as a
a program may be related to another task program itself, which list of models. Fig. 2 includes several of these models which
is specified within the resource. This results in another can be considered as basic architecture of the IEC 61499
problematic situation concerning the definition of software standard. A system consists of devices, which are interrelated
components, as the behavior of two program instances will be by some communication network, and applications. A device
different. includes resources and interfaces to the process and/or the
communication network. The resource1 is the element which C. Software components within IEC 61499
executes FBs independently. It makes use of the interfaces The main element of the IEC 61499 standard is the FB,
from the device. An application consists of a FB network, which is treated very differently from the ones discussed for
which is composed of FB instances, parameters and the IEC 61131-3 standard. The first element for the discussion
connections between the FBs. The execution of applications is about software components within the elements of IEC 61499
determined by the event and data flow within the FB network. standard is therefore the FB in its different occurrences:
An application can be distributed to different resources, which Basic FB as software component: The interface of an
may be located on different devices. In Fig. 2 ‘Application A’ IEC 61499 FB includes both data and events. Therefore also
is distributed to different devices, ‘Application C’ is distributed the execution of a FB is included in the FB interface. The
to two resources within the same device. ‘Application B’ is behavior is given by the ECC and is well defined. There exist
distributed to ‘Device 2’ and ‘Resource X’ in ‘Device 3’. As no hidden interfaces, as a BFB is only allowed to use input,
the execution flow of an application is given by events, a output and internal data. A BFB can be considered as a
distributed application will behave in the same manner as if it software component.
is located within one resource, if there are no significant delays Service Interface FBs as software component: The SIFB
or loss of data in the communication network. hides its concrete implementation. But the IEC 61499 standard
defines sequence diagrams in order to describe the
B. Function block model
functionality of a SIFB. If a SIFB is well described by use of
The most important element of the IEC 61499 standard is the
sequence diagrams, the SIFB can be considered as software
function block. In contrast to an FB defined by (IEC 61131-3,
component. This is independent from the concrete type of
2003) the interface is not only defined by variables but also by
SIFB. In case of a requester type SIFB, the execution behavior
events. The internals of a FB can be categorized in three main
is defined by the interface as this type does not become active
types, which are called Basic FB (BFB), Composite FB (CFB),
by itself. For the responder type SIFB, execution is triggered
and Service Interface FB (SIFB):
by the underlying services.
Basic function block: The behavior of a BFB is defined as
There are two possibilities to undermine the representation
event driven state machine, the so-called Execution Control
of a SIFB as a software component. The first one depends on
Chart (ECC). There can only be one transition that fires (there
the underlying functionality encapsulated by the SIFB. There
exists an order for evaluation) and the active state of the ECC
are no restrictions mentioned in the IEC 61499 standard for
changes (there is only one active ECC state at one time
these services. Therefore it is possible to implement also some
possible). When a new state is entered, the corresponding
hidden interfaces, e.g. a similar construct as global variables.
actions are executed. An action consists of an algorithm, or an
The second restriction concerns the definition of the SIFB
output event, or both. An algorithm within a BFB can be
behavior by use of sequence diagrams. This means may be not
written in any programming language, but the IEC 61499
powerful enough to describe the SIFB behavior in all details
standard especially mentions the languages defined in [1]. An
(e.g., temporal order) or is not used sufficiently.
algorithm can use only input data, output data, and internal
Composite FB as software component: The behavior of a
data of the FB type, therefore a BFB defines a very strong
CFB is defined by its component FB network. Therefore one
encapsulation of algorithms.
would expect that it is well defined. But the IEC 61499
Composite function block: The behavior of a CFB is
standard lacks for a concrete definition of the execution of FB
defined by a FB network. The FBs within a CFB are called
networks, as this is discussed by Sünder et al. [11]. Another
component FBs, and there is no restriction to a special FB type.
problem occurs by the use of SIFBs as component FBs within
For instance, hierarchical structures can be designed by reuse
a CFB. If such a SIFB cannot be considered as a software
of existing CFBs. The execution of a CFB is defined according
component, then this is also true for the CFB. But even if each
to the event and data connections of the component FB
component SIFB fulfills all requirements of a software
network. A CFB can not have internal data, since there is no
component, the CFB may still lack a good description of its
possibility to use them within component FB network.
interface and behavior. This is because of the possible
Service interface function block: The SIFB is a concept for
hierarchy of composition levels within the CFB. A SIFB on the
the encapsulation of the interaction with external elements,
lower levels is hardly visible at the interface of the CFB, and
which are not in the scope of the definitions of the IEC 61499
only detailed analysis of the overall structure of the component
standard. Within a SIFB any kind of functionality may be
FB network will clarify this situation.
hidden. But the interface is equal to a BFB or CFB. In order to
Subapplication as software component: A subapplication is
provide more information about the hidden functionality, a
very similar to a CFB and provides the possibility of
sequence diagram is defined by the standard. An SIFB may be
distribution in addition. Already the considerations about CFBs
either application triggered, resource triggered, or both.
have given rise to the consideration that a CFB may be
considered as a software component only in certain situations.
The same can be stated for subapplications, if we neglect the
1
The definition of a resource in IEC 61499 is not equivalent to the one of
IEC 61131-3.
impact of communication in case of a distributed  Access to directly represented variables has to be
subapplication. restricted to elements that do not implement any kind of
Application as software component: An application has no hidden interfaces.
separate interface in form of a FB shape. Its interface emerges If we consider any POU element (function, function block,
from the used FBs within the FB network, and therefore or program) as a software component, similar limitations have
especially by the used SIFBs. This fact and the above to be mentioned. The main difference is that the execution
considerations about SIFBs within FB networks yield to the context is provided within the component framework
conclusion that an application cannot be considered as a explicitly, which may be useful for a tight coupling to
software component. IEC 61499 (if the execution context can be separated from the
The elements resource, device and even system may also not control logic functionality).
be considered as software components. For all these elements IEC 61499 component framework:
exist no separate interface descriptions as this is based on the A similar differentiation may be possible in case of
FB network included. IEC 61499. The best context for an element without execution
V. ANALYSIS OF PROBLEMS AND POTENTIALS OF A COMMON context is a FB. But in order to consider an FB as software
COMPONENT SYSTEM ARCHITECTURE component, different enhancements are necessary.
 The interface description of SIFBs has to be enhanced in
The above considerations have shown clearly that both order to provide detailed information about their
IEC 611313-3 as well as IEC 61499 do not completely fulfill behavior, especially that of resource triggered types
the definition of software components. In the case of (events are generated based on the underlying system).
IEC 61131-3 standard this is clear due to the fact that the  Accordingly the interface of CFBs has to be enhanced in
origins of the standard are much earlier than the component- a similar way as for SIFBs, if a component FB within the
based software paradigm. For the IEC 61499 standard the CFB is an SIFB.
definitions of elements match much better with the software Within IEC 61499 the execution context is always part of
component definition, but it can not be considered as a each FB due to the event-driven nature. As comparable
component framework. This is on the one hand because also element for an element that includes the overall execution
the development of the IEC 61499 standard was done during behavior an application may be considered as software
the mid 1990’s, but much more important is the fact that the component. In this case a similar extension as mentioned for
needs of the automation and control industry are different from CFBs has to be applied.
the ones of computer science:
 Interaction with hardware is deeply entwined with the VI. RECOMMENDATIONS FOR FUTURE WORK:
control logic We recommend that future work on a component system
 Typical automation and control system users are not architecture be based on an IEC 61499 component framework
skilled in computer science (simply speaking a runtime environment), enhanced in order to
 Hard real-time constraints are in the foreground of control support also the elements defined in IEC 61131-3 standard. A
programs. simple schematic of such an enhanced IEC 61499 component
In order to propose a component system architecture for both framework is depicted in Fig. 3. Common elements of
standards the different inadequacies of both standards have to IEC 61499 standard are white shaded, while enhancements
be fixed. A component framework for each of the standards concerning the IEC 61131-3 standard are drawn as grey shaded
has to provide the following characteristics: boxes. There are two different kinds of enhancements that need
IEC 61131-3 component framework: to be considered. On the one hand, there are several services
There may be different levels of component frameworks that need to be added for the use of variables. The IEC 61131-3
taken into consideration for IEC 61131-3. On the one hand we standard offers the possibility to use global variables, directly
can define a component framework for the elements represented variables, or access paths. Of course, the use of
configuration or resource. For both options the overall these elements needs to be supported in an IEC 61131-3
execution behavior is defined including the execution context. component framework and—as we ask for full support of both
The following points have to be incorporated: standards—the enhanced IEC 61499 component framework
 Interface description: The VAR_ACCESS construct needs to provide these services, too. The second type of
needs to be enhanced in order to provide a clear interface enhancements refers to the architectural elements of the
description. IEC 61131-3 software model. Herein especially configurations,
 In case of resources, VAR_EXTERNAL declarations resources and programs need to be supported in the proposed
have to be neglected. This may be substituted via component system architecture. The situation of a program is
appropriate VAR_ACCESS declarations as mentioned simply depicted by triggering of cyclic execution by use of an
above. E_CYCLE FB. But the integration of programs in IEC 61499
application may be more comprehensive (see discussion
below).
 Cooperation of IEC 61131-3 and IEC 61499 control logic: VII. CONCLUSION
Up to now we have described a kind of component system This paper analyses the capabilities of the both standards
architecture that is capable of the execution of IEC 61131-3 as IEC 61131-3 and IEC 61499 to be treated as component
well as IEC 61499 control logic. But there is no interaction framework. The inadequacies of the standards are discussed.
possible between these two kinds of control logic. Within From the user’s point of view an integrative approach for the
IEC 61131-3 communication between programs is done via use of both standards (even in any arbitrary combination)
data inputs and outputs, global variables, and access paths. As would be favored in order to use the best concepts for new
the definition of data types is similar in both standards, applications without loosing existing experiences. Therefore, a
connections can be simply established. In case of access to component system architecture is envisaged that is based on an
global variables via access paths the FBs defined in enhanced IEC 61499 runtime environment.
IEC 61131-5 may be used as this has been already proposed in
[12]. REFERENCES
Wrapper for POUs: The execution of POUs within an [1] IEC 61131-3, “Programmable Controllers—Part 3: Programming
IEC 61499 application has to take into consideration especially languages”, International Standard, Second Edition, 2003
[2] IEC 61499-1, “Function blocks—Part 1: Architecture”, International
the execution flow. The execution of a program is related to a Standard, First Edition, 2005
task, the execution of an IEC 61131-3 FB or function is related [3] Iacooca Institute, 21st Century Manufacturing Enterprise Strategy: An
to the network within it is being used. In order to interact with Industry-Led View, Lehigh University Press, 1991, ISBN 0-9624866-3-9
[4] European Commission, “MANUfuture: Strategic Research Agenda,
an IEC 61499 application, the interface for execution has to be Assuring the future of Manufacturing in Europe”, Report of the High-
defined in terms of events: Level-Group, 2006, ISBN 92-79-01026-3
 IEC 61499  IEC 61131-3: If a POU is triggered for [5] PLCopen Technical Committee 6, “XML Formats for IEC 61131-3”,
Technical Paper, Version 1.01, 2005
execution by an event, this would be equivalent to setting [6] C. Sünder, A. Zoitl, H. Steininger, J. Fritsche, „Symbiose von
EN true and triggering for execution. IEC 61131-3 und IEC 61499: Integration von scheinbar sehr
 IEC 61131-3  IEC 61499: This case is more unterschiedlichen Welten“, (in german), In: Proceedings of Conference
Entwurf komplexer Automatisierungssysteme (EKA’08), Magdeburg
problematic, as it may not be necessary to transfer the (Germany), April 2008, pp. 185-196, ISBN 978-3-940961-01-3
cyclic execution of IEC 61131-3 into the IEC 61499 part. [7] IEC 61131-5, “Programmable Controllers—Part 5: Communications”,
The wrapper may utilize additional data of the POU in International Standard, First Edition, 2005
[8] ICS Triplex, ISaGRAF v.5, [Online], http://www.isagraf.com, February
order to decide whether an output event should be issued 2008
or not (filter functionality). [9] C. Szyperski, Component Software: Beyond Object-Oriented
Wrapper for POU regions: The above considerations may Programming, Second Edition, Addison-Wesley, ACM Press New York,
ISBN 0-201-74572-0
be simply enlarged also for interconnected POUs, especially [10] H. Kopetz, Real-Time Systems: Design Principles of Distributed
FBs and functions. In detail, this is the case for FBD, a Embedded Applications, Kluwer Academic Publisher, Boston, 1997,
graphical programming language, where control logic is ISBN 0-7923-9894-7
[11] C. Sünder, A. Zoitl, J. H. Christensen, M. Colla, T. Strasser, „Execution
defined by interconnection of these elements. A wrapper for an Models for the IEC 61499 elements Composite Function Block and
interconnected area of POUs is similar to the one described Subapplication“, In: Proc. 5th IEEE Int. Conf. on Industrial Informatics
above for a single POU. (INDIN’07), Vienna (Austria), July 2007, pp. 1123-1129
[12] IEC 61131-3, Draft-Annex H: Interoperability with IEC 61499 devices,
Separation of POU regions: If there exists a well defined [Online], http://www.holobloc.com/stds/iec/sc65bwg7tf3/html/news.htm
interface for interconnection of FBD and IEC 61499
applications, this may be used also for separation of existing
FBD networks. Breaking a FBD network into smaller parts and
identification of their interfaces makes also distribution
possible for IEC 61131-3 in a similar manner as for
IEC 61499.

Fig. 3. Enhanced IEC 61149 component framework

View publication stats