Model-driven Approach for Complex
Material Handling Systems
Gareth Shaw Li Hsien Yoong Partha S Roop Zoran Salcic
Department of Electrical and Computer Engineering,
University of Auckland, Auckland, New Zealand
Abstract: The model-driven approach to software development has been increasingly applied
to manage the growing complexity in modern manufacturing systems. With this approach, a
model of a system is ﬁrst created at a high-level of abstraction. The model is then converted into
an executable program by means of automatic code generation tools. Models can be simulated
and visualized throughout the entire design ﬂow of the system, thereby increasing conﬁdence of
the design’s correctness and its adherence to user requirements. Moreover, since the design
is speciﬁed at a higher level of abstraction, the description itself is easier to understand,
and consequently, less prone to errors. Unfortunately, automated code generation from high-
level models have typically been ineﬃcient compared to hand-crafted code. In this paper,
we demonstrate an approach for generating eﬃcient code for systems modelled using IEC
61499 function blocks. We have also developed a tool chain that allows complex material
handling systems to be modelled, visualized, and synthesized in a seamless fashion. Experimental
evaluations show that our approach produces signiﬁcantly faster and smaller code compared to
an existing tool.
Keywords: Distributed control, industrial control, material systems, synchronous
1. INTRODUCTION Typical implementations of IEC 61499 systems rely on
some run-time environment to dispatch events between
function blocks in a network. The run-time environment
In recent years, the complexity of control and automation provides the means to schedule function blocks in a net-
systems has been rapidly growing in response to the work for execution in response to events. A concrete
emerging needs of the manufacturing industry. At the implementation would require that the function blocks
same time, the increasingly shorter time-to-market has be compiled into appropriate objects, which can then be
created an urgent need for software components that instantiated in the run-time environment for execution.
can be easily reused in new designs (closed-loop system Current function block implementations that make use of
speciﬁcations). Traditional techniques utilizing a bottom- a run-time environment (see FORTE (2008) and FBDK
up approach with programmable logic controller (PLC) (2008)) result in slow and bulky code. The behaviour of
languages have been found inadequate to meet these new the system is also highly dependent on the subtle imple-
demands (Vyatkin et al. (2007)). This has motivated a mentation details of the run-time environment (Ferrarini
shift in the industry toward a model-driven approach u
and Veber (2004); S¨ nder et al. (2007)). To overcome this,
for the engineering of complex manufacturing systems, we have adopted the synchronous semantics for function
wherein a software component represents or models a block execution proposed by Yoong et al. (2007, accepted
subsection of the system. for publication). This approach enables the automated
The IEC 61499 standard (IEC (2005)) has emerged out of transformation of function block models into executable
this need to provide a standardized model-driven frame- code without the need of a run-time environment.
work to develop distributed industrial systems. It pre- We have applied this technique to the practical de-
scribes a component-oriented approach using function sign of complex material handling systems, which are a
blocks, which can be connected together in a network to commonly-found feature in many industrial process con-
form complete systems. Function blocks connected in a trol settings, ranging from automotive production lines,
network communicate with each other through event and meat packaging facilities to airport baggage handling sys-
data lines. tems (BHS). As a case study, we have developed a com-
Modelling with IEC 61499 function blocks is appealing for plete tool chain for the design of baggage handling systems.
numerous reasons. Such models are independent of any im- The design framework which we have created allows the
plementation target. The high-level of abstraction aﬀorded development of airport BHS using the model-view-control
by function blocks simpliﬁes the development of complex (MVC) paradigm. This approach enables the model of
control systems by making the design speciﬁcation more the plant and the controller to be simultaneously devel-
intuitive and less error-prone. Fully executable code can oped and tested using model-accurate visualizations of
then be automatically synthesized from these descriptions. the physical bags and conveyor system. The plant model,
Fig. 2. The interface of the ConvBeltModel function block
Fig. 1. The function block network of the ConveyorPlantModel
modelling a single conveyor
controller, and visualization components can run in a dis-
tributed fashion over a communication network to simulate
the ﬁnal deployment scenario.
Fig. 3. The execution control chart for the ConvBeltModel
Though applied to baggage handling, our work is a re- function block
alistic case study of using function blocks for develop-
ing material handling systems in general. The ability to
maintain the same system description throughout the or photoeyes attached to the conveyor. On the physical
entire development—from design conception, to architec- system, the photoeye is used to detect the presence of
tural modelling, simulation, visualization, and synthesis— bags on the conveyor belt. Using a model of bag positions
ensures coherency between user requirements and ﬁnal on the conveyor and the current position of the belt, the
implementation. The high-level description can be incre- ConveyorModel can accurately simulate instances when the
mentally reﬁned and tested, while necessary modiﬁcations photoeye would be obstructed by bags on the conveyor.
can be easily fed back to the model throughout the entire Both the ConvBeltModel and the ConveyorModel blocks are
design ﬂow. The importance of thorough testing and simu- known as basic function blocks. Besides basic function
lation for complex material handling systems, like baggage blocks, the IEC 61499 standard also deﬁnes two other
handling in airports, has already been well-documented kinds of function blocks:
(de Neufville (1994)).
• Composite function blocks. These provide a way to en-
In what follows, we ﬁrst provide some background informa- capsulate a network of function blocks within another
tion on function blocks in Section 2. Then, in Section 3, block. The ConveyorPlantModel in Fig. 1, which encap-
we describe the model of a segment of an airport BHS, sulates the ConvBeltModel and ConveyorModel blocks, is
together with the controller and visualization. We show an example of this.
how complex systems can be speciﬁed and tested using • Service interface function blocks. These serve as de-
model-accurate visualizations within the MVC framework. vice drivers to bind the function block application to
Section 4 then brieﬂy describes how function block designs a speciﬁc hardware target.
can be automatically converted to eﬃcient executable
code. To evaluate the beneﬁts of our development tool All function blocks, irrespective of their type, consist of
chain, we compare the quality of our generated code with a well-deﬁned interface that speciﬁes its event and data
an existing function block code generator and run-time inputs, as well as its event and data outputs. This is
environment in Section 5. Section 6 then concludes with illustrated in Fig. 2 with the ConvBeltModel function block.
some possible directions for future research. Event lines are drawn on the upper part of the block,
while data lines are connected to the lower part. Event-
2. IEC 61499 FUNCTION BLOCKS data associations may be created at the interface to update
the values of input data and to produce new output data
together with the associated event(s).
Fig. 1 shows the function block model of the plant for
a single conveyor forming part of an airport BHS. We While the behaviour of composite function blocks depends
use this as an example to introduce the essential elements on the network of their subcomponents, the behaviour of
of IEC 61499 function blocks. In Fig. 1, the ConvBeltModel basic function blocks is deﬁned by their execution control
function block models the movement of the conveyor belt chart (ECC), as illustrated in Fig. 3 for the ConvBeltModel
as it operates. The relative displacement of the belt is function block. An ECC consists of EC (execution control)
indicated by the EncCount output, which increments by one states, EC transitions, and EC actions. These elements are
for every millimeter of movement. This value is fed to the labelled in the ECC of Fig. 3. The initial state of an ECC
ConveyorModel block, which models the infra-red detectors is represented with a double-box by convention.
The transition conditions between states in an ECC are
evaluated whenever the function block receives an input
event. These conditions are expressed using an input event
and/or a boolean guard condition. Each state can be
associated with zero or more actions, which may consist of
an algorithm and a possible output event to be issued at
the algorithm’s completion. The action(s) associated with
a given state will be executed once on entry to the state.
When connected together in a network, the output events
from one function block may in turn trigger the execution
of other blocks.
In the following section, we will demonstrate how this
modelling framework can be applied to the practical design
of an airport BHS.
Fig. 4. Visualization of the baggage handling system
3. MODELLING BAGGAGE HANDLING SYSTEMS simulation
Existing approaches for designing a BHS usually begin
from the bottom-up. The process typically starts by creat- This forms a very high-level model of the physical plant.
ing a computer-aided design (CAD) drawing of the system. The functionality of the controller may similarly be de-
This CAD drawing is used to plan out the interconnections scribed as a network of function blocks. The plant and
of the various BHS components, such as conveyors, X- the controller can be made to exchange information using
ray machines, divert and merge sections, and so on. This communication blocks. Such a design of the plant and the
constitutes the 3-D view of the physical plant. associated controller constitutes a closed-loop model of the
Subsequently, the designers must decide on the appropri-
ate points in the system for placing the controllers. These In order to visualize the behaviour of the resulting control
controllers are typically implemented using PLC languages system, we can also describe the view of the system using
prescribed by the IEC 61131 standard (IEC (2003)). A another network of function blocks, or with other tools for
physical test system will then be assembled using the graphical visualization. We start, ﬁrst, by discussing the
appropriate mechanical components and PLCs in order to design of the visualization for the BHS to give a bird’s eye
test the system before ﬁnal deployment. perspective of the system. Then, in the later subsection,
we will elaborate on the plant and controller models.
There are two key problems with this bottom-up approach
to the design of such complex systems. Firstly, every
design created is speciﬁc to a given airport. Once the BHS
company is commissioned with a new project, the process
3.1 Simulation and Visualization of a BHS
described above has to be repeated. Secondly, debugging
such systems is diﬃcult. Without access to model-accurate
visualizations of the system, testing of the control software We have developed a visualization tool, called MHVIS,
with the plant can only be done on the physical system. which can create a 3-D OpenGL (OpenGL (2008)) repre-
sentation of the BHS, together with a graphical interface
To overcome the problems associated with such a mono- for user interaction. Figure 4 shows the visualization of
lithic approach to control software development, the IEC
our BHS. This system consists of six conveyors, including
61499 standard has introduced a more component-oriented
one merging and one diverting conveyor. Each conveyor
methodology to facilitate reuse of existing software. We ad- has three photoeyes. In this model, there is a single bag
vocate leveraging this component-based approach within
source and a single bag sink.
the MVC paradigm to simplify the development of com-
plex control systems. In order to do this eﬀectively, we MHVIS generates the 3-D representation of the BHS by
must ﬁrst partition the system into three orthogonal sub- parsing the plant’s function block description to create
systems. These include the model of the plant, the con- the layout of conveyors. This approach enables MHVIS to
troller, and the visualization for the whole system. The accurately visualize any materials handling system, given
latter helps the developer to visualize the behaviour of the it’s function block model. Once the view has been created,
plant and the controller oﬀ-line. MHVIS animates each component based on data from
both the plant and controller.
IEC 61499 enables a BHS to be designed in a component-
oriented manner by allowing diﬀerent modules of the sys- The generated visualization communicates with the plant
tem to be modelled as separate function blocks (Vyatkin and controller function block models using UDP sockets.
et al. (2007)). These blocks can then be connected together Based on the outputs from the plant and controller, the
within a network to implement the overall system. More- 3-D representation of the BHS can graphically show the
over, each block may be further reﬁned using a network position of the bags on the conveyor belts, the conveyor
of blocks as well. Such hierarchy allows the well-known movement, and the status of the diverter all in simulated
software engineering concept of reﬁnement to be applied real-time. This enables visual simulation of both the plant
to a design. Each block has an explicit input-output in- and the controller at the same time, without needing to
terface, which connects to other components of the plant. deploy the control code on the actual physical system.
Fig. 6. Controller model for a conveyor
At the top-most level, the plant has Init and Rate events,
which are passed to all the lower-level blocks. The Init
event, common to almost all function blocks, initialises
the required data, while the Rate event is used to control
the speed of execution of the blocks, aiding debugging and
Fig. 5. Plant model of a conveyor The controller system is similar to the plant, with six
ConveyorController blocks representing each of the six con-
3.2 Function Block Implementation of a BHS veyors. Figure 6 shows a conveyor controller’s functionality
contained within a ConveyorController block and the associ-
Each of the six conveyors in the BHS plant has inputs ated network interfaces to communicate with the plant.
to control the belt motor and a diverter. It has two Each conveyor controller must create a model of the bags
outputs, one representing the movement of the conveyor on the conveyor using the toggling boolean value of the
belt (a boolean state change every 50mm travelled), and photoeye input data (PEDetects) and the belt movement
an array containing detection values of the photoeyes. The (EncoderState) coming from the plant. The controller also
controller, in turn, must track the positions of all the bags requires additional bag data indicating the desired desti-
in the system. In addition, it must control each conveyor nation. By correlating the belt position with the changes in
to start, stop, and divert appropriately so as to dispatch the photoeye boolean values, the controller can determine
each bag to its intended destination. the position of the leading and the trailing edges of a
bag. The controller compares the destination of each bag
Function block systems can be developed by incrementally with the destination codes of each diverter to determine
reﬁning the design. A designer can start with a very high- whether or not to divert. If it needs to divert a bag, a
level model consisting of a network of function blocks. signal is sent to the plant to push the diverter arm into
Each of these blocks may be further reﬁned by lower-level the stream, deﬂecting the bag to an alternate stream. The
networks. For example, we begin constructing the BHS diverter is then returned to its normal position.
plant model by modelling a conveyor at a very high-level,
this is the ConveyorPlantModel block within Figure 5. The Another advantage of function blocks is the use of reﬁne-
ﬁgure also shows the input-output interface of a single ment to hide or preset static values for lower-level function
conveyor connected to two diﬀerent networking blocks. At blocks. We make use of this in the controller by creating
the input side, there is a subscriber block FromController 1 a generic conveyor controller that is able to control the
from which it receives control commands. At its output merging, diverting, and straight-line conveyors. Relevant
side, there is a publisher block ToController 1 through which parameters speciﬁc to each conveyor controller type, such
it sends the belt position and photoeye detection data to as the position of photoeyes and the actual physical con-
the controller. veyor type being controlled, are abstracted within another
block. For example, the ConveyorController 3PEs Divert block
The ConveyorPlantModel block is further reﬁned to a network sets some values for the three photoeyes and diverter
of blocks as shown in Figure 1. This network captures attribute internally, exposing only data signals that may
the actual behaviour of the conveyor by modelling the be- vary between instances.
haviour of the photoeye and that of the physical conveyor
as the ConveyorModel and ConvBeltModel blocks respectively. 4. COMPILING IEC 61499 FUNCTION BLOCKS
After the implementation of the ConveyorModel function
block, we extend the interface of the ConveyorPlantModel In order to derive executable code for the BHS model, we
block so that each conveyor can receive new bag data to en- compile the function block description using the approach
ter into the ConveyorModel’s virtual model and send old bag presented by Yoong et al. (2007, accepted for publication).
data as it removes it. Once the plant model of an individual That work applies the synchronous model of execution
conveyor is obtained, the plant system can be created. (Benveniste et al. (2003)) to function blocks, modelling
Outputs of an upstream conveyor (the BagOut event and each function block in a network as a concurrently exe-
data) to the inputs of a downstream conveyor (either the cuting module. In practice, this concurrency is simulated
BagIn or the BagMerge events and data). Unconnected inputs using a non-terminating loop, which executes a segment of
are still read by blocks within ConveyorPlantModel, but no code for every function block during each iteration, similar
new bag data will be received. to that done by Lastra et al. (2005).
This approach closely mimics the execution of a PLC scan system simulation to be done together with the formal
cycle. In fact, the synchronous approach formalizes the no- synchronous modelling approach. Practice has found that
tion of a scan cycle by dividing time into discrete instants, high-level model-based programming and formal veriﬁca-
known as a tick. Computations performed within a tick are tion do not replace traditional simulation-based testing,
assumed to be instantaneous, with time progressing only but complement it instead.
when crossing tick boundaries. This notion is prevalent in
One other feature found to be desirable for automatic
various ﬁelds of engineering, and has been used extensively
synthesis tools is the ability to maintain code traceability
by control engineers in discrete-time dynamic systems, as
well as hardware engineers in digital logic design. between the model and the generated code. fbc supports
this by producing highly-readable code that can be easily
In our model, the tick is mapped directly to the period of traced back to the function block model by retaining
a scan cycle. Thus, in each tick, execution takes place, similar identiﬁer names and propagating function block
ﬁrst, by taking a snapshot of the input signals, then comments into the generated code. This feature gives
performing some computation, and ﬁnally, generating the conﬁdence to practitioners accustomed to low-level hand-
output signals. For a basic function block, this involves crafted code to make the transition to a model-based ap-
the evaluation of EC transitions in the current EC state, proach. The ability to automatically generate clear and ef-
and the corresponding computation of the action(s) in ﬁcient code, comparable to those written by professionals,
the destination state, should a transition be taken. The facilitates the practical adoption of model-driven approach
lifespan of an event is strictly deﬁned to persist for the in the development of industrial systems.
duration of the tick in which it occurred. Thus, no more
In the following section, we present experimental results
than one EC transition can occur within a tick in each
that compare the quality of the code generated by fbc
basic function block of a network. Throughout this process,
all function blocks in a network are conceptually running with that of an existing function block tool.
concurrently in lock-step with one another.
5. EXPERIMENTAL EVALUATION
The formal semantics oﬀered by the synchronous model
overcome many of the ambiguities (discussed in Vy-
atkin and Dubinin (2007)) plaguing run-time environ- Tables 1 and 2 present the results for the experiment we
ments adopting event-based schemes for scheduling func- conducted to evaluate the code produced by fbc. The
tion blocks. While the semantic clarity deﬁnitely lends ﬁrst row of each table shows the results obtained for the
mathematical rigor to function block designs, it also ap- BHS described in Section 3. The other entries in the tables
peals to practitioners by yielding the following beneﬁts: have been reproduced from Yoong et al. (2009) to provide
further indication of the quality of code generated by fbc.
• Predictable temporal properties – The execution order
of function blocks is completely known at compile-
time, thus, removing the need for an event-based In this experiment, the code from fbc was compared with
scheduler during execution. that produced by the 4diac-ide (FORTE (2008)). The
• Deterministic behaviour – The behaviour of function 4diac-ide is an open-source function block development
block designs is determined solely by the semantics tool, which provides a widely-accepted approach for func-
without needing to consider their interaction with tion block execution through its run-time environment,
a run-time environment. Subtle variations in run- forte. Using the 4diac-ide, the function block programs
time environment implementations have already been in the benchmark suite were ﬁrst converted into C++ code
shown to result in very diﬀerent application behaviour before being executed in forte. Similarly, fbc was used
(S¨ nder et al. (2007); Ferrarini and Veber (2004)).
u to convert the same benchmark programs into Esterel
• Code eﬃciency – The clear semantics facilitate the and C. The generated Esterel programs were subsequently
generation of fast and compact code, while avoiding compiled into C using the V7 Esterel compiler (Esterel
the overhead of a run-time environment. (2005)). All the C and C++ code were then compiled with
gcc and g++ respectively. The experiment itself was carried
Our function block compiler, called fbc, is capable of
generating C and/or Esterel code (Esterel (2005)). Es- Table 1. Execution time for one million input
terel code can be readily veriﬁed using industry-proven vectors (in milliseconds)
tools, like Esterel Studio, by employing a combination of
System Forte Esterel C
assertions and synchronous observers (Berry et al. (2003)). Baggage Handling System 9817 7019 3572
Veriﬁed code can then be automatically compiled into C Cruise Control 1200 274 147
using the compiler provided by Esterel Studio. However, Drill Station 789 194 78
the C code produced directly by fbc is much more eﬃcient LED Flasher 649 154 67
than the corresponding C code obtained after translation Speed Regulator 1648 125 73
into Esterel. This has been found to be consistently the
case in experimental tests (see Section 5). Both the Esterel Table 2. Object code size (in kilobytes)
and C code produced by fbc are ensured to be functionally
equivalent through the underlying synchronous semantics. System Forte Esterel C
Baggage Handling System 337 138 24.4
fbc is also capable of generating a graphical simulator Cruise Control 123 12.0 7.65
for any given function block model to facilitate rapid test- Drill Station 70.6 6.46 3.52
ing. This capability is essential in practical development LED Flasher 22.2 6.80 2.04
eﬀorts, like that undertaken for the BHS, as it allows sub- Speed Regulator 98.8 6.28 4.62
out on an AMD Turion 64 ML-32 processor with 1GB of language. In IEEE/ACM International Conference on
RAM. Computer-aided Design (ICCAD), 433–439. San Jose,
Table 1 shows the average time taken to compute the
de Neufville, R. (1994). The baggage system at Denver:
reaction to one million input vectors. These input vec-
Prospects and lessons. Journal of Air Transport Man-
tors have been randomly generated beforehand for each
agement, 1(4), 229–236.
program. The C code generated by fbc consistently ran
Esterel (2005). The Esterel v7 Reference Manual: Version
much faster than the others. In particular, the baggage
v7 30 for Esterel Studio 5.3. Esterel Technologies SA,
handling system we modelled ran 2.7 times faster than
the corresponding code in forte. On average, the C code
FBDK (2008). Function Block Development Kit.
from fbc performed 3.6 times faster than its counterparts
Holobloc Inc., http://www.holobloc.com (Last Ac-
running in forte.
The code generated by fbc is also more compact than that Ferrarini, L. and Veber, C. (2004). Implementation ap-
produced by the 4diac-ide, as can be seen from Table 2. proaches for the execution model of IEC 61499 applica-
The object code size for the baggage handling system tions. In 2nd IEEE International Conference on Indus-
obtained from the 4diac-ide is 2.4 times larger than that trial Informatics (INDIN), 612–617. Berlin, Germany.
obtained from the Esterel code, and 13.8 times larger than FORTE (2008). 4DIAC-RTE (FORTE): IEC 61499
that obtained from the C code of fbc. Average object Compliant Runtime Environment. PROFACTOR Pro-
code size for the C code is 15.4 times smaller than their duktionsforschungs GmbH, http://www.fordiac.org
counterparts in forte for the programs in the benchmark. (Last Accessed: 28/7/2008).
IEC (2003). International Standard IEC 61131-3: Pro-
The signiﬁcantly smaller memory footprint required to run grammable Controllers – Part 3: Programming Lan-
function block programs synthesized by fbc is remarkable, guages. International Electrotechnical Commission,
even without considering the fact that the overhead for the Geneva, 2nd edition.
forte run-time environment has not yet been taken into IEC (2005). International Standard IEC 61499-1: Func-
account. The vastly superior code produced by fbc paves tion blocks – Part 1: Architecture. International Elec-
the way for complex industrial systems modelled in func- trotechnical Commission, Geneva, 1st edition.
tion blocks to be executed even on resource-constrained Lastra, J.L.M., Godinho, L., Lobov, A., and Tuokko, R.
embedded controllers. (2005). An IEC 61499 application generator for scan-
based industrial controllers. In 3rd IEEE International
6. CONCLUSION Conference on Industrial Informatics (INDIN). Perth,
This paper has presented an approach for the development OpenGL (2008). OpenGL. Khronos Consortium,
of complex material handling systems through the use http://www.opengl.org/ (Last Accessed: 22/9/2008).
of model-driven engineering. This has been demonstrated u
S¨ nder, C., Zoitl, A., Christensen, J.H., Colla, M., , and
with a case study using IEC 61499 function blocks within Strasser, T. (2007). Execution models for the IEC 61499
the MVC framework. At present, we have already devel- elements composite function block and subapplication.
oped a complete tool chain based on this framework for de- In 5th IEEE International Conference on Industrial
signing airport baggage handling systems. We believe that Informatics (INDIN), 1169–1175. Vienna.
the use of function blocks in this context is highly advan- Vyatkin, V. and Dubinin, V. (2007). Sequential axiomatic
tageous, as it leverages on an existing industry standard model for execution of basic function blocks in IEC
to bring about high-level abstract speciﬁcation, model- 61499. In 5th IEEE International Conference on In-
accurate visualization, and automatic code synthesis all dustrial Informatics (INDIN), 1183–1188. Vienna.
within a single design ﬂow. While this idea is not new Vyatkin, V., Salcic, Z., Roop, P.S., and Fitzgerald, J.
in itself, the ability to generate very fast and compact (2007). Information infrastructure of intelligent ma-
embeddable code for realistic applications is signiﬁcant. chines based on the IEC 61499 architecture. IEEE
As a future addition to the presented design ﬂow, we are Industrial Electronics Magazine, 1(4), 17–29.
now working toward a compositional veriﬁcation approach Westhead, M. and Nadjm-Tehrani, S. (1996). Veriﬁcation
for function blocks using synchronous observers (Westhead of embedded systems using synchronous observers. Lec-
and Nadjm-Tehrani (1996)). This approach, made possible ture Notes in Computer Science: Formal Techniques in
through our synchronous semantics for function block Real-Time and Fault-Tolerant Systems, 1135, 405–419.
execution, will provide another tool to aid the designer. We Yoong, L.H., Roop, P., Vyatkin, V., and Salcic, Z. (2007).
believe that automatically synthesized code from formally Synchronous execution of IEC 61499 function blocks
veriﬁed models will be crucial for the future development using Esterel. In 5th IEEE International Conference
of reliable industrial automation systems. on Industrial Informatics (INDIN), 1189–1194. Vienna.
Yoong, L.H., Roop, P.S., and Salcic, Z. (2009). Eﬃ-
REFERENCES cient implementation of IEC 61499 function blocks. In
IEEE International Conference on Industrial Technol-
Benveniste, A., Caspi, P., Edwards, S.A., Halbwachs, N., ogy (ICIT). Gippsland.
Guernic, P.L., and de Simone, R. (2003). The syn- Yoong, L.H., Roop, P.S., Vyatkin, V., and Salcic, Z.
chronous languages 12 years later. Proceedings of the (accepted for publication). A synchronous approach
IEEE, 91(1), 64–83. for IEC 61499 function block implementation. IEEE
Berry, G., Kishinevsky, M., and Singh, S. (2003). Sys- Transactions on Computers.
tem level design and veriﬁcation using a synchronous