Model-driven Approach for Complex Material Handling Systems

Document Sample
Model-driven Approach for Complex Material Handling Systems Powered By Docstoc
					                             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 first 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 flow of the system, thereby increasing confidence of
           the design’s correctness and its adherence to user requirements. Moreover, since the design
           is specified 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 inefficient compared to hand-crafted code. In this paper,
           we demonstrate an approach for generating efficient 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 significantly 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
specifications). 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 afforded   development of airport BHS using the model-view-control
by function blocks simplifies the development of complex      (MVC) paradigm. This approach enables the model of
control systems by making the design specification 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 final 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 final           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 refined and tested, while necessary modifications       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 flow. 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 defines 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 first 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 specified 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 briefly describes how function block designs         a specific hardware target.
can be automatically converted to efficient executable
code. To evaluate the benefits 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-defined interface that specifies 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 defined 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
                                                                overall system.
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, first, 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 final 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 specific 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 difficult. 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 effectively, we        MHVIS generates the 3-D representation of the BHS by
must first 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 off-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 different 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 refined 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 refinement 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
                                                                testing.
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
refining 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 refined by lower-level       the stream, deflecting 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 refine-
figure also shows the input-output interface of a single         ment to hide or preset static values for lower-level function
conveyor connected to two different 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 specific 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 refined 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 verifica-
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 fields 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 identifier names and propagating function block
first, by taking a snapshot of the input signals, then           comments into the generated code. This feature gives
performing some computation, and finally, generating the         confidence 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           ficient 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 defined 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 offered 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 definitely lends         first 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 benefits:       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 first converted into C++ code
    shown to result in very different 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 efficiency – 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 verified 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
Verified 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 efficient             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
efforts, 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,
                                                                 California.
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
                                                                 Villeneuve-Loubet, France.
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.
                                                                 cessed: 28/7/2008).
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 significantly 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,
                                                                 Australia.
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 specification, 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 flow. 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 significant.        chines based on the IEC 61499 architecture. IEEE
As a future addition to the presented design flow, we are         Industrial Electronics Magazine, 1(4), 17–29.
now working toward a compositional verification approach        Westhead, M. and Nadjm-Tehrani, S. (1996). Verification
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
verified 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). Effi-
                     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 verification using a synchronous