A new tool-kit for designing complex material handling systems using IEC61499 function blocks

Proceedings of the 13th IFAC Symposium on Information Control Problems in Manufacturing Moscow, Russia, June 3-5, 2009

A new tool-kit for designing complex material handling systems using IEC61499 function blocks 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. However, 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 In recent years, the complexity of control and automation systems has been rapidly growing in response to the emerging needs of the manufacturing industry. At the same time, the increasingly short time-to-market has created an urgent need for software components that can be easily reused in new designs. Traditional techniques utilizing a bottom-up approach with programmable logic controller (PLC) languages have been found to be inadequate to meet these new demands (Vyatkin et al. (2007)). This has motivated a shift in the industry toward a model-driven approach for the design of complex industrial systems. Industrial systems are typically described as closed-loop systems, consisting of a plant and a controller. The modeldriven approach advocates the development of software models, which abstract the various physical subsystems of both the plant and the controller. This abstraction simplifies the design process and promotes the reuse of component models. The recent ratification of the IEC 61499 standard (IEC (2005)) has provided further impetus towards this modelling paradigm in the development of industrial systems. It prescribes a component-oriented approach using function blocks, which can be connected together in a network to form complete systems. Function blocks connected in a network communicate with each other through event and data lines. Modelling with IEC 61499 function blocks is appealing for numerous reasons. Such models are independent of any implementation target. The high-level of abstraction

978-3-902661-43-2/09/$20.00 © 2009 IFAC

afforded by function blocks simplifies the development of complex systems by making the design specification more intuitive and less error-prone. Fully executable code can then be automatically synthesized from these descriptions. 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 provides the means to schedule function blocks in a network for execution in response to events. A concrete implementation would require that the function blocks be compiled into appropriate objects, which can then be instantiated in the run-time environment for execution. Current function block implementations that make use of a run-time environment (see FORTE (2008) and FBDK (2008)) result in slow and bulky code. The behaviour of the system is also highly dependent on the subtle implementation details of the run-time environment (Ferrarini and Veber (2004); S¨ under et al. (2007)). To overcome this, we have adopted the synchronous semantics for function block execution proposed by Yoong et al. (2007, accepted for publication). This approach enables the automated transformation of function block models into executable code without the need of a run-time environment. We have applied this technique to the practical design of complex material handling systems, which are a commonly-found feature in many industrial process control settings, ranging from automotive production lines, meat packaging facilities to airport baggage handling systems (BHS). As a case study, we have developed a complete tool chain for the design of baggage handling systems. The design framework which we have created allows the

1412

10.3182/20090603-3-RU-2001.0448

13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009

Fig. 2. The interface of the

ConvBeltModel

function block

Fig. 1. The function block network of the ConveyorPlantModel modelling a single conveyor development of airport BHS using the model-view-control (MVC) paradigm. This approach enables the model of the plant and the controller to be simultaneously developed and tested using model-accurate visualizations of the physical bags and conveyor system. The plant model, controller, and visualization components can run in a distributed fashion over a communication network to simulate the final deployment scenario. Though applied to baggage handling, our work is a realistic case study of using function blocks for developing material handling systems in general. The ability to maintain the same system description throughout the entire development—from design conception, to architectural modelling, simulation, visualization, and synthesis— ensures coherency between user requirements and final implementation. The high-level description can be incrementally refined and tested, while necessary modifications can be easily fed back to the model throughout the entire design flow. The importance of thorough testing and simulation for complex material handling systems, like baggage handling in airports, has already been well-documented (de Neufville (1994)). In what follows, we first provide some background information on function blocks in Section 2. Then, in Section 3, we describe the model of a segment of an airport BHS, together with the controller and visualization. We show how complex systems can be specified and tested using model-accurate visualizations within the MVC framework. Section 4 then briefly describes how function block designs can be automatically converted to efficient executable code. To evaluate the benefits of our development tool chain, we compare the quality of our generated code with an existing function block code generator and run-time environment in Section 5. Section 6 then concludes with some possible directions for future research.

Fig. 3. The execution control chart for the function block

ConvBeltModel

function block models the movement of the conveyor belt as it operates. The relative displacement of the belt is indicated by the EncCount output, which increments by one for every millimeter of movement. This value is fed to the ConveyorModel block, which models the infra-red detectors or photoeyes attached to the conveyor. On the physical system, the photoeye is used to detect the presence of bags on the conveyor belt. Using a model of bag positions on the conveyor and the current position of the belt, the ConveyorModel can accurately simulate instances when the photoeye would be obstructed by bags on the conveyor. Both the ConvBeltModel and the ConveyorModel blocks are known as basic function blocks. Besides basic function blocks, the IEC 61499 standard also defines two other kinds of function blocks: • Composite function blocks. These provide a way to encapsulate a network of function blocks within another block. The ConveyorPlantModel in Fig. 1, which encapsulates the ConvBeltModel and ConveyorModel blocks, is an example of this. • Service interface function blocks. These serve as device drivers to bind the function block application to a specific hardware target.

2. IEC 61499 FUNCTION BLOCKS

All function blocks, irrespective of their type, consist of a well-defined interface that specifies its event and data inputs, as well as its event and data outputs. This is illustrated in Fig. 2 with the ConvBeltModel function block. Event lines are drawn on the upper part of the block, while data lines are connected to the lower part. Eventdata 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 use this as an example to introduce the essential elements of IEC 61499 function blocks. In Fig. 1, the ConvBeltModel

While the behaviour of composite function blocks depends on the network of their subcomponents, the behaviour of basic function blocks is defined by their execution control chart (ECC), as illustrated in Fig. 3 for the ConvBeltModel function block. An ECC consists of EC (execution control)

1413

13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009

states, EC transitions, and EC actions. These elements are labelled in the ECC of Fig. 3. The initial state of an ECC 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. 3. MODELLING BAGGAGE HANDLING SYSTEMS Existing approaches for designing a BHS usually begin from the bottom-up. The process typically starts by creating a computer-aided design (CAD) drawing of the system. This CAD drawing is used to plan out the interconnections of the various BHS components, such as conveyors, Xray machines, divert and merge sections, and so on. This constitutes the 3-D view of the physical plant. Subsequently, the designers must decide on the appropriate points in the system for placing the controllers. These controllers are typically implemented using PLC languages prescribed by the IEC 61131 standard (IEC (2003)). A physical test system will then be assembled using the appropriate mechanical components and PLCs in order to test the system before final deployment. 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 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 with the plant can only be done on the physical system. To overcome the problems associated with such a monolithic approach to control software development, the IEC 61499 standard has introduced a more component-oriented methodology to facilitate reuse of existing software. We advocate leveraging this component-based approach within the MVC paradigm to simplify the development of complex systems. In order to do this effectively, we must first partition the system into three orthogonal subsystems. These include the model of the plant, the controller, and the visualization for the whole system. The latter helps the developer to visualize the behaviour of the plant and the controller off-line. IEC 61499 enables a BHS to be designed in a componentoriented manner by allowing different modules of the system to be modelled as separate function blocks (Vyatkin et al. (2007)). These blocks can then be connected together within a network to implement the overall system. Moreover, each block may be further refined using a network

Fig. 4. Visualization of the baggage handling system simulation of blocks as well. Such hierarchy allows the well-known software engineering concept of refinement to be applied to a design. Each block has an explicit input-output interface, which connects to other components of the plant. This forms a very high-level model of the physical plant. The functionality of the controller may similarly be described as a network of function blocks. The plant and the controller can be made to exchange information using dedicated service interface function blocks for communication. Such a design of the plant and the associated controller constitutes a closed-loop model of the overall system. In order to visualize the behaviour of the resulting control system, we can also describe the view of the system using another network of function blocks, or with other tools for graphical visualization. We start, first, by discussing the design of the visualization for the BHS to give a bird’s eye perspective of the system. Then, in the later subsection, we will elaborate on the plant and controller models. 3.1 Simulation and Visualization of a BHS We have developed a visualization tool, called mhvis, which can create a 3-D OpenGL (OpenGL (2008)) representation of the BHS, together with a graphical interface for user interaction. Figure 4 shows the visualization of our BHS. This system consists of six conveyors, including one merging and one diverting conveyor. Each conveyor has three photoeyes. In this model, there is a single bag source and a single bag sink. mhvis generates the 3-D representation of the BHS by parsing the plant’s function block description to create the layout of conveyors. This approach enables mhvis to accurately visualize any baggage handling system, given it’s function block model. Once the view has been created, mhvis animates each component based on data from both the plant and the controller. The generated visualization communicates with the plant and controller function block models using UDP sockets. Based on the outputs from the plant and controller, the 3-D representation of the BHS can graphically show the position of the bags on the conveyor belts, the conveyor movement, and the status of the diverter all in simulated real-time. This enables visual simulation of both the plant and the controller at the same time, without needing to deploy the control code on the actual physical system.

1414

13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009

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 3.2 Function Block Implementation of a BHS Each of the six conveyors in the BHS plant has inputs to control the belt motor and a diverter. It has two outputs, one representing the movement of the conveyor belt (a boolean state change every 50mm travelled), and an array containing detection values of the photoeyes. The controller, in turn, must track the positions of all the bags in the system. In addition, it must control each conveyor to start, stop, and divert appropriately so as to dispatch each bag to its intended destination. Function block systems can be developed by incrementally refining the design. A designer can start with a very highlevel model consisting of a network of function blocks. Each of these blocks may be further refined by lower-level networks. For example, we begin constructing the BHS plant model by modelling a conveyor at a very high-level; this is the ConveyorPlantModel block in Fig. 5. The figure also shows the input-output interface of a single conveyor connected to two different networking blocks. At the input side, there is a subscriber block, ConveyorToPlant Sub, from which it receives control commands. At its output side, there is a publisher block, PlantToConveyor Pub, through which it sends the belt position and photoeye detection data to the controller. The ConveyorPlantModel block is further refined to a network of blocks as shown in Fig. 1. This network captures the actual behaviour of the conveyor by modelling the behaviour of the photoeye and that of the physical conveyor as the ConveyorModel and ConvBeltModel blocks respectively. After the implementation of the ConveyorModel function block, we extend the interface of the ConveyorPlantModel block so that each conveyor can receive new bag data to enter into the ConveyorModel’s virtual model and send old bag data as it removes it. Once the plant model of an individual conveyor is obtained, the entire plant can be created. Outputs of an upstream conveyor (the BagOut event and data) will be connected to the inputs of a downstream conveyor (either the BagIn or the BagMerge events and data). Unconnected inputs are still read by blocks within the ConveyorPlantModel, but no new bag data will be received.

The controller system is similar to the plant, with six ConveyorController blocks representing each of the six conveyors. Figure 6 shows a conveyor controller’s functionality contained within a ConveyorController block and the associated network interfaces to communicate with the plant. Each conveyor controller must create a model of the bags on the conveyor using the toggling boolean value of the photoeye input data (PEDetects) and the belt movement (EncoderState) coming from the plant. The controller also requires additional bag data indicating the desired destination. By correlating the belt position with the changes in the photoeye boolean values, the controller can determine the position of the leading and the trailing edges of a bag. The controller compares the destination of each bag with the destination codes of each diverter to determine whether or not to divert. If it needs to divert a bag, a signal is sent to the plant to push the diverter arm into the stream, deflecting the bag to an alternate stream. The diverter is then returned to its normal position. Another advantage of function blocks is the use of refinement to hide or preset static values for lower-level function blocks. We make use of this in the controller by creating a generic conveyor controller that is able to control the merging, diverting, and straight-line conveyors. Relevant parameters specific to each conveyor controller type, such as the position of photoeyes and the actual physical conveyor type being controlled, are abstracted within another block. For example, the ConveyorController 3PEs Divert block sets some values for the three photoeyes and diverter attribute internally, exposing only data signals that may vary between instances. 4. COMPILING IEC 61499 FUNCTION BLOCKS In order to derive executable code for the BHS model, we compile the function block description using the approach presented by Yoong et al. (2007, accepted for publication). That work applies the synchronous model of execution (Benveniste et al. (2003)) to function blocks, modelling each function block in a network as a concurrently executing module. In practice, this concurrency is simulated using a non-terminating loop, which executes a segment of code for every function block during each iteration, similar to that done by Lastra et al. (2005).

1415

13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009

This approach closely mimics the execution of a PLC scan cycle. In fact, the synchronous approach formalizes the notion of a scan cycle by dividing time into discrete instants, known as a tick. Computations performed within a tick are assumed to be instantaneous, with time progressing only when crossing tick boundaries. This notion is prevalent in various fields of engineering, and has been used extensively by control engineers in discrete-time dynamic systems, as well as hardware engineers in digital logic design. In our model, the tick is mapped directly to the period of a scan cycle. Thus, in each tick, execution takes place, first, by taking a snapshot of the input signals, then performing some computation, and finally, generating the output signals. For a basic function block, this involves the evaluation of EC transitions in the current EC state, and the corresponding computation of the action(s) in the destination state, should a transition be taken. The lifespan of an event is strictly defined to persist for the duration of the tick in which it occurred. Thus, no more than one EC transition can occur within a tick in each basic function block of a network. Throughout this process, all function blocks in a network are conceptually running concurrently in lock-step with one another. The formal semantics offered by the synchronous model overcome many of the ambiguities (discussed in Vyatkin and Dubinin (2007)) plaguing run-time environments adopting event-based schemes for scheduling function blocks. While the semantic clarity definitely lends mathematical rigour to function block designs, it also appeals to practitioners by yielding the following benefits: • Predictable temporal properties – The execution order of function blocks is completely known at compiletime, thus, removing the need for an event-based scheduler during execution. • Deterministic behaviour – The behaviour of function block designs is determined solely by the semantics without needing to consider their interaction with a run-time environment. Subtle variations in runtime environment implementations have already been shown to result in very different application behaviour (S¨ under et al. (2007); Ferrarini and Veber (2004)). • Code efficiency – The clear semantics facilitate the generation of fast and compact code, while avoiding the overhead of a run-time environment.

tion of subcomponents to be done together with the formal synchronous modelling approach. Practice has found that high-level model-based programming and formal verification do not replace traditional simulation-based testing, but complement it instead. One other feature found to be desirable for automatic synthesis tools is the ability to maintain code traceability between the model and the generated code. fbc supports this by producing highly-readable code that can be easily traced back to the function block model by retaining similar identifier names and propagating function block comments into the generated code. This feature gives confidence to practitioners accustomed to low-level handcrafted code to make the transition to a model-based approach. The ability to automatically generate clear and efficient code, comparable to those written by professionals, facilitates the practical adoption of the model-driven approach in the development of industrial systems. In the following section, we present experimental results that compare the quality of the code generated by fbc with that of an existing function block tool. 5. EXPERIMENTAL EVALUATION Tables 1 and 2 present the results for the experiment we conducted to evaluate the code produced by fbc. The first row of each table shows the results obtained for the BHS described in Section 3. The other entries in the tables have been reproduced from Yoong et al. (2009) to provide further indication of the quality of code generated by fbc. In this experiment, the code from fbc was compared with that produced by the 4diac-ide (FORTE (2008)). The 4diac-ide is an open-source function block development tool, which provides a widely-accepted approach for function block execution through its run-time environment, forte. Using the 4diac-ide, the function block programs in the benchmark suite were first converted into C++ code before being executed in forte. Similarly, fbc was used to convert the same benchmark programs into Esterel and C. The generated Esterel programs were subsequently compiled into C using the V7 Esterel compiler (Esterel (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)). Esterel code can be readily verified using industry-proven tools, like Esterel Studio, by employing a combination of assertions and synchronous observers (Berry et al. (2003)). Verified code can then be automatically compiled into C using the compiler provided by Esterel Studio. However, the C code produced directly by fbc is much more efficient than the corresponding C code obtained after translation into Esterel. This has been found to be consistently the case in experimental tests (see Section 5). Both the Esterel and C code produced by fbc are ensured to be functionally equivalent through the underlying synchronous semantics. fbc is also capable of generating a graphical simulator for any given function block model to facilitate rapid testing. This capability is essential in practical development efforts, like that undertaken for the BHS, as it allows the simula-

1416

Table 1. Execution time for one million input vectors (in milliseconds) System Baggage Handling System Cruise Control Drill Station LED Flasher Speed Regulator

Forte 9817 1200 789 649 1648

Esterel 7019 274 194 154 125

C 3572 147 78 67 73

Table 2. Object code size (in kilobytes) System Baggage Handling System Cruise Control Drill Station LED Flasher Speed Regulator

Forte 337 123 70.6 22.2 98.8

Esterel 138 12.0 6.46 6.80 6.28

C 24.4 7.65 3.52 2.04 4.62

13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009

out on an AMD Turion 64 ML-32 processor with 1GB of RAM. Table 1 shows the average time taken to compute the reaction to one million input vectors. These input vectors have been randomly generated beforehand for each program. The C code generated by fbc consistently ran much faster than the others. In particular, the baggage handling system we modelled ran 2.7 times faster than the corresponding code in forte. On average, the C code from fbc performed 3.6 times faster than its counterparts running in forte. The code generated by fbc is also more compact than that produced by the 4diac-ide, as can be seen from Table 2. The object code size for the baggage handling system obtained from the 4diac-ide is 2.4 times larger than that obtained from the Esterel code, and 13.8 times larger than that obtained from the C code of fbc. Average object code size for the C code is 15.4 times smaller than their counterparts in forte for the programs in the benchmark. The significantly smaller memory footprint required to run function block programs synthesized by fbc is remarkable, even without considering the fact that the overhead for the forte run-time environment has not yet been taken into account. The vastly superior code produced by fbc paves the way for complex industrial systems modelled in function blocks to be executed even on resource-constrained embedded controllers. 6. CONCLUSION This paper has presented an approach for the development of complex material handling systems based on the model-driven approach. This has been demonstrated with a case study using IEC 61499 function blocks within the MVC framework. At present, we have already developed a complete tool chain based on this framework for designing airport baggage handling systems. We believe that the use of function blocks in this context is highly advantageous, as it leverages on an existing industry standard to bring about high-level abstract specification, modelaccurate visualization, and automatic code synthesis all within a single design flow. While this idea is not new in itself, the ability to generate very fast and compact embeddable code for realistic applications is significant. As a future addition to the presented design flow, we are now working toward a compositional verification approach for function blocks using synchronous observers (Westhead and Nadjm-Tehrani (1996)). This approach, made possible through our synchronous semantics for function block execution, will provide another tool to aid the designer. We believe that automatically synthesized code from formally verified models will be crucial for the future development of reliable industrial automation systems. REFERENCES Benveniste, A., Caspi, P., Edwards, S.A., Halbwachs, N., Guernic, P.L., and de Simone, R. (2003). The synchronous languages 12 years later. Proceedings of the IEEE, 91(1), 64–83. Berry, G., Kishinevsky, M., and Singh, S. (2003). System level design and verification using a synchronous

language. In IEEE/ACM International Conference on Computer-aided Design (ICCAD), 433–439. San Jose, California. de Neufville, R. (1994). The baggage system at Denver: Prospects and lessons. Journal of Air Transport Management, 1(4), 229–236. Esterel (2005). The Esterel v7 Reference Manual: Version v7 30 for Esterel Studio 5.3. Esterel Technologies SA, Villeneuve-Loubet, France. FBDK (2008). Function Block Development Kit. Holobloc Inc., http://www.holobloc.com (Last Accessed: 28/7/2008). Ferrarini, L. and Veber, C. (2004). Implementation approaches for the execution model of IEC 61499 applications. In 2nd IEEE International Conference on Industrial Informatics (INDIN), 612–617. Berlin, Germany. FORTE (2008). 4DIAC-RTE (FORTE): IEC 61499 Compliant Runtime Environment. PROFACTOR Produktionsforschungs GmbH, http://www.fordiac.org (Last Accessed: 28/7/2008). IEC (2003). International Standard IEC 61131-3: Programmable Controllers – Part 3: Programming Languages. International Electrotechnical Commission, Geneva, 2nd edition. IEC (2005). International Standard IEC 61499-1: Function blocks – Part 1: Architecture. International Electrotechnical Commission, Geneva, 1st edition. Lastra, J.L.M., Godinho, L., Lobov, A., and Tuokko, R. (2005). An IEC 61499 application generator for scanbased industrial controllers. In 3rd IEEE International Conference on Industrial Informatics (INDIN). Perth, Australia. OpenGL (2008). OpenGL. Khronos Consortium, http://www.opengl.org/ (Last Accessed: 22/9/2008). S¨ under, C., Zoitl, A., Christensen, J.H., Colla, M., , and Strasser, T. (2007). Execution models for the IEC 61499 elements composite function block and subapplication. In 5th IEEE International Conference on Industrial Informatics (INDIN), 1169–1175. Vienna. Vyatkin, V. and Dubinin, V. (2007). Sequential axiomatic model for execution of basic function blocks in IEC 61499. In 5th IEEE International Conference on Industrial Informatics (INDIN), 1183–1188. Vienna. Vyatkin, V., Salcic, Z., Roop, P.S., and Fitzgerald, J. (2007). Information infrastructure of intelligent machines based on the IEC 61499 architecture. IEEE Industrial Electronics Magazine, 1(4), 17–29. Westhead, M. and Nadjm-Tehrani, S. (1996). Verification of embedded systems using synchronous observers. Lecture Notes in Computer Science: Formal Techniques in Real-Time and Fault-Tolerant Systems, 1135, 405–419. Yoong, L.H., Roop, P., Vyatkin, V., and Salcic, Z. (2007). Synchronous execution of IEC 61499 function blocks using Esterel. In 5th IEEE International Conference on Industrial Informatics (INDIN), 1189–1194. Vienna. Yoong, L.H., Roop, P.S., and Salcic, Z. (2009). Efficient implementation of IEC 61499 function blocks. In IEEE International Conference on Industrial Technology (ICIT). Gippsland. Yoong, L.H., Roop, P.S., Vyatkin, V., and Salcic, Z. (accepted for publication). A synchronous approach for IEC 61499 function block implementation. IEEE Transactions on Computers.

1417