T he requirements of flexible manufacturing and material handling systems, such as rapid integration and reconfiguration, as well as the growing information intensity of the production environments imply that manufacturing equipment is becoming more autonomous and intelligent A large number of intelligent machine concepts have been proposed in the last decade (see overview in [10]) Their systematic discussion and evaluation is beyond the goals of this article A few characteristic concepts, however, need to be mentioned The holonic manufacturing systems (HMSs) [3] emphasize the idea of self-configurability, envisioning that holonic machines will form new production configurations “on the fly,” reacting to the external and internal changes For example, an external change could be a change in the product specification An internal change can be a break-down of a certain machine in the production system The reconfigurable manufacturing systems (RMSs) [2] and the intelligent mechatronic actors introduced by Lastra in [10] rely on the “offline” (in advance) customization of the machinery driven by the changing production Valeriy Vyatkin, Zoran Salcic, Partha S Roop, and John Fitzgerald ©Master Series, Tech Pool Studios 1932-4529/07/$25.00©2007IEEE Digital Object Identifier 10.1109/MIE.2007.909540 WINTER 2007 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 17 orders and specifications All these concepts imply the use of a powerful computer “brain” driven by sophisticated software Several computing architectures for enabling this have been developed, for example Prod- the device model providing the dynamic configurability features, and n the coherent model of the distributed system as a collection of devices populated by applications While the research and developn The function block architecture of IEC 61499 provides a new degree of flexibility in managing embedded control and information processing systems through the lifetime of industrial automation products uct-Resource-Order-Staff Architecture (PROSA) [4], Plant Automation Based on Distributed Systems (PABADIS) [4], and Malfunctioning Agent Simulation Tool (MAST) [5] All these require much higher intelligence and flexibility of the low-level control layer than can be provided by programmable logic controllers (PLCs)—current devices that drive automated machines The programming paradigm of PLCs imposes serious limitations both for efficient project engineering and the implementation of intelligent automation systems The latest development on this front is the function block architecture of IEC 61499 [1], which provides a new degree of flexibility in managing embedded control and information processing systems through the lifetime of industrial automation products The key enablers of the flexibility in this new standard are: n the encapsulation of knowledge into function blocks, n the application model as a network of function blocks, Conveyor ment on the IEC 61499 implementation and application is gaining momentum worldwide, especially in the last three years (see survey of the relevant research works in [6], [15], and [18]), there is a lack of case studies answering the following questions: n What differentiates the functionblock-based design from the design following the usual PLC paradigm or approaches used in the wider embedded systems? n Do function blocks really address development of truly intelligent solutions such as plug-and-play (PnP), service-oriented architecture (SOA), and agent-based systems? n How the existing computing platforms satisfy the requirements of function block architecture? This article is an attempt to address these questions and provide some answers We analyze the potential of the function block architecture on an example of the machinery used in material handling systems, in particular in airport baggage handling systems (BHSs) Embedded Controller-on-Chip Network Figure – Functions of intelligent conveyor 18 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n WINTER 2007 – Control – Communication – Device Management – Data Logging – Preventive Maintenance – Displaying Information on the Web – Answering Queries The functional requirements of an intelligent machine are discussed It is illustrated that the existing control architecture, based on the use of PLCs, falls short in fulfilling these requirements The function block model of IEC 61499 is discussed in more detail and the function block model is used to illustrate the features of intelligent machines and manufacturing systems We describe an experiment conducted on a laboratory model of an intelligent manufacturing system with the goal of achieving the PnP configurability and reconfiguration by employing IEC 61499 control Intelligent Machine Information Processing Infrastructure Even a relatively simple machine, like the conveyor belt unit shown in Figure 1, can increase its value significantly if equipped with a proper embedded control and information processing device The embedded device can simultaneously host and implement a number of functions, as shown in Figure The intelligence on the device level extends its functionality, increasing its performance, reliability, and ability to integrate into more complex production systems For example, connectivity function (the ability to communicate via networks is a very basic function of an intelligent machine) enables such a machine to communicate with other intelligent machines within a manufacturing cell, as well as with enterprise information systems and human operators A natural extension of general connectivity is the feature of “remote control” provided by the device to authorized clients This function, along with status rendering, can be implemented by an embedded Web server as illustrated in Figure To provide for connectivity, the embedded controller must implement certain communication protocols This can be the usual Internet protocol suite; this, however, has some inherited problems not allowing for reliable communication with guarantees of real-time delivery As a remedy, more robust field area networks can be used (field buses, see [8] for a comprehensive review of such networks) A device’s services implemented as its software can be fixed (factory set) or flexible, i.e., upgradeable by the vendor after deployment via the Web In this way, the whole business model of software vendors is changing, transforming the software from a kind of commodity to a kind of service Such an approach has proven its feasibility in industrial automation in the European R&D project Total Life Cycle WebIntegrated Control (TORERO) [11] The usual communication services of the network protocols can be used for implementation of higher-level communications and negotiations The device can become an active communication partner capable of describing its functionality to other devices to dynamically form the communities aimed at the implementation of new production goals This is illustrated in Figure 3, where an intelligent conveyor and an intelligent radio frequency identification (RFID) reader are communicating using a higherlevel negotiation protocol RFID is a technology seen to substitute current bar-code-based identification The main function of the reader is simple: it reads information from an RFID tag attached to baggage, and intelligence is required to simplify its integration with other devices Both devices describe their functionalities to the integrator — that is an “agent,” physical or virtual, that creates a new functional entity by combining the skills of its components (as, for example, in [10]) There are a number of higher-level intelligent negotiation protocols appropriate for this task One such example is the agent communication protocols developed by the Foundation for Physical Intelligent Agents (FIPA) [9] This kind of communication is the essential enabler for PnP reconfiguration in flexible manufacturing systems More generally, an intelligent device can be seen as a provider of various services which can be of an information and/or physical nature For example, the list of services provided by an autonomous “intelligent” conveyor may include: n discrete operations, like “move a piece of baggage from the left end to the right end” initiated by a single command (physical activity service) for service description and service request The service provision mechanism can be used for smooth integration of mechatronic components to a machine or a manufacturing cell, A composite function block is an encapsulation of a network of other function blocks as illustrated in Figure The components being integrated inform the cell supervisor about their skills Given this information, the supervisor draws conclusions about the skills of the resulting system These interactions can be facilitated if the devices talk a request to provide information about last ten activities (information service) Implementation of this view of the production machinery can be enabled by using some features of semantic Web services such as the mechanisms n Web Browser: Rendering and Remote Control LEFT RIGHT SPEED AUTOMATIC “Intelligent” Conveyor Network Figure – Remote rendering and control of the conveyor over the network supporting HTTP – Hey, I am a conveyor Integrator – Okay, together we are a conveyor with an RFID reader!!! – Hello, I am an RFID reader! Figure – Negotiation of intelligent machines towards formation of a manufacturing cell WINTER 2007 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 19 to each other using semantic Web technologies, as proposed by Jammes and Smit in [17], UPnP as in TORERO [11], or Jini technology, as explored by PABADIS [4] interface modules that gives the best performance/cost ratio for each particular application PLCs are durable and reliable; their hardware is developed for use in tough industrial environments and has been enhanced for years, while their software runs according to the simple, predictable, and deterministic cyclic scan pattern Programming of PLCs is intuitive to control engineers It is standardized by the International Standard IEC 61131-3 (IEC 61131-3, 1993) The standard has captured the most common ways of thinking of control engineers Once programming of one PLC type is learned, it is quite easy to apply these skills in programming the PLCs of other vendors However, despite all the mentioned virtues, a number of new challenges have highlighted the application limits of the PLC paradigm Intelligent machines imply distributed architecture of automation devices However, many features of PLCs not fit this concept As it happens sometimes in life, someone can be virtuous to a fault The same is true for PLCs: one of their serious drawbacks when applied PLCs and Intelligent Machines From the above discussion it becomes obvious that the use of embedded computers can bring numerous benefits to the manufacturing machines However, for decades the common approach for controlling machines has been to use PLCs PLCs use a specific programming model that has not changed for many years regardless of the computing machines used Two questions can be immediately asked: What are the reasons to prefer a PLC over other types of embedded microcomputers? And if an embedded microcomputer will be a part of the machine, is the additional PLC control needed at all? First, the PLCs are the readily available off-the-shelf solution The PLCs have a scaleable modular architecture primarily addressing hardware capacity of the device; the user can choose processor performance and make a custom configuration of input-output in distributed systems is the execution semantics of the scan-based programming architecture This will be illustrated by the following example Figure presents a part of an automated airport BHS The system consists of five components: two conveyors, an X-ray screening machine, a diverter that can push a piece of baggage from the conveyor, and a laser bar code scanner A PLC is connected to all sensors and actuators of the system The PLC program that implements the desired behavior of the cell is a single piece of code in the structured text (ST) language One of common reconfiguration tasks is to substitute a machine in a manufacturing cell by its functional equivalent If a mechatronic component such as the scanner is going to be substituted by a slightly different one, e.g., RFID reader or just a similar device from another vendor, the reprogramming task becomes complicated Most likely, the whole program needs to be rewritten, since the interaction of the scanner with other components is spread across the entire program text For example, in Figure all places in the code where the data from the scanner is read or set are highlighted References to the Scanner Data in the Code Diverter PLC Code Scanner Conveyor Conveyor X-Ray Screening PLC Figure – PLC control of the manufacturing cell model with a linear sequence of code in the ST language 20 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n WINTER 2007 IF STATE0 THEN READY:=1; STATE1:=1; STATE0:=0; ELSIF STATE1 & CONV1PRES THEN CONV1LEFT:=1; STATE2:=1; STATE1:=0; ELSIF STATE2 & NOT CONV1MOV THEN CONV1RGT:=0; SCAN ON:=1; STATE3:=1; STATE2:=0; ELSIF STATE3 & SCAN.OP1 THEN TP (TRUE, T#2s,TIMER1,T1LOG); CONV1RGT:=1 STATE4:=1; STATE3:=0; ELSIF STATE4 & NOT TIMER1 THEN DIVON:=1 STATE5:=1; STATE4:=0; ELSIF STATE5 & SCREEN–IN THEN CONV1:=0; SCREEN:=1 STATE6:=1; STATE5:=0; ELSIF STATE6 & SCREEN OUT THEN SCAN ON:=0; CONV2:=0; DIVERT:=0; STATE7:=1; STATE6:=0; ELSIF STATE7 & SCANOFF THEN SCREEN:=1 STATE8:=1; STATE7:=0; ELSIF STATE8 & SCREENED THEN CONV2:=1; SCANON:=1 STATE9:=1; STATE8:=0; ELSIF STATE9 & SCANOFF THEN CHECKUP:=0; BAD:=0; GOOD:=0; TP (TRUE, T#2s, TIMER2, T2LOG) This method of program organization makes the resulting program sensitive to the order in which the programs are included in the sequence since each block may modify the global variables which become the input data for other programs Clearly, Diverter tion, which is the core concept of the IEC 61131-3 architecture, limits the potential of software reuse and integration of components An attempt to organize control of a modular system in a decentralized manner using networking PLCs While IEC-61499-compliant devices and tools are starting to appear on the market, the whole issue of migration from the existing PLC-based control systems to IEC 61499 still requires further investigation raises another problem When PLCs communicate via a network, the most commonly used data exchange mechanism is via a pool of common network variables Values of these variables are updated by their respective controllers in the fixed cyclic order, and the update is tightly synchronized with the internal scan loops of the PLCs Thus, the order again is fixed and is subject to the Configuration Poll Input Variables Configuration Poll Input Variables Prog “Coord” Prog “Coord” Prog “Screen” Prog “Divert” Prog “Scan” Prog “Scan” Prog “Divert” Prog “Conv2” Prog “Conv1” Prog “Screen” Prog “Conv2” Prog “Conv1” Set Output Variables Set Output Variables Order of Execution the “right” order is not implied by the physical order (sequence) of machines or the order of their operation, so different engineers may prefer different execution sequences within programs However, changing the order may immediately change the behavior of the resulting program Thus, we see that the centralized programmable control model with cyclically scanned program execu- Order of Execution One can argue that this problem can be overcome by a better encapsulation of the code relevant to each mechatronic unit into a special program structure In IEC 61131, this structure is a program Let us assume that all the issues relevant to the control of a particular machine are nicely encapsulated in the corresponding program as shown in Figure 5, where two possible program configurations are shown The programs are lined up to be executed sequentially during a short time interval between update of inputs and outputs, which is called a scan A coordinating program Coord may be needed to determine the desired sequence of other program invocations The programs, however, need to exchange data The most commonly used data exchange mechanism between programs in PLCs is via global variables For example, when the diverter is extended, the corresponding program may set the variable DIVRTEXTD:51 The program implementing the control of the second conveyor will read this variable and will slow down the conveyor until the diverter is retracted Scanner Conveyor Conveyor PLC X-Ray Screening Figure – Integration of components in one scan of a PLC The behavior may depend on the order of program components WINTER 2007 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 21 same reordering issues described earlier The correct access to the common variables may require implementation of complex mutually exclusive access procedures Again, in this case the overheads of the integration may be as complex as complete program redesign As these examples illustrate, the IEC 61131-3 architecture implies the startover development of systems and, as a result, does not sufficiently support reuse of already existing components This moderates the flexibility since the reuse mechanism is the key factor that is required for modular organization of manufacturing systems and for their rapid reconfiguration In addition, despite the standardization effort of IEC 61131-3, different implementations of the same programming language of IEC 61131-3 often have different execution semantics Moreover, configuring the PLCs of different vendors requires proprietary configuration tools Function Block Model Thus, basic function blocks will exhibit equivalent execution semantics on different computing platforms, regardless of the sequence in which they are listed or called in the program An example of a basic function block description is shown in Figure Every function block consists of an interface, an execution control chart (ECC), and a set of algorithms that are invoked in specific states of the ECC The interface is explicitly separated on event and data parts The event inputs and outputs are connected to the head part of the interface shape, while the data are connected to the lower body part Basic function blocks are activated by event inputs The ECC is a state machine that decides in each state which algorithms to call and which output events to emit A composite function block is an encapsulation of a network of other function blocks (a set of function blocks that are interconnected using their respective interfaces in a point-to-point fashion) The example in Figure implements the same computation as the block in the preInterface Execution Control Chart Algorithm vious example and has ALGORITHM REQ IN ST: EVENT REQ CNF EVENT exactly the same interSTART OUT := (X−Y)*(X+Y); face Its internal logic, END_ALGORITHM however, is defined as X2Y2 REQ a network of three interconnected function REAL REAL X OUT blocks, each performREAL REQ REQ CNF Y ing basic arithmetic operations instead of ECC and algorithms Figure – Basic function block which computes OUT X 2 Y2 as initiated by event input REQ An application in IEC 61499 is also a network of function blocks A distributed apADDER plication is a number of applications REQ REQ CNF allocated across different computing devices The interblock connections FB_ADD_REAL in an application are extended across MULR boundaries of devices in distributed X IN1 OUT REQ CNF CNF SUBTR applications using communication Y IN2 REQ CNF function blocks Thanks to explicit event connecFB_MUL_REAL tions between function blocks, the FB_SUB_REAL OUT OUT IN1 execution semantics of the distribX IN1 OUT IN2 uted application not depend on Y IN2 the particular number and topology of computational resources or their cyclic scans as heavily as in the case Figure – Implementation of OUT X 2 Y2 as a composite function block, i.e., a network of of networking PLCs (certainly some other function blocks 22 The IEC 61499 standard [1] provides an open component architecture for distributed automation systems The architecture is built around the concept of a function block, which is a model for encapsulation of automation knowledge and for making such knowledge portable This model ensures compatibility of applications on the source code level and equivalence of their execution semantics on different platforms A comprehensive description of the IEC 61499 concepts can be found in [12], [14], and [15] Some concepts related to IEC 61499 are briefly described as follows A basic function block is an atomic program unit Basic function blocks are used to encapsulate algorithms written in one or several programming languages Execution sequence and semantics of the algorithms depend only on internal state of the block and on the input events but not on the properties of a particular execution platform IEEE INDUSTRIAL ELECTRONICS MAGAZINE n WINTER 2007 ependencies caused by different d speed of the resources and networks will still remain) As a consequence, no additional synchronization between devices would be required to ensure consistency of the data transmitted between them This will be true also for more complex applications that are represented as hierarchical networks of function blocks Thus, system development can now be done in a high-level platform-independent form of function block applications which can be mapped to different distributed structures of devices (and used computing platforms), and any legitimate mapping will preserve the semantics of the original application The abstract device model of IEC 61499 provides a mechanism for creating new device types as a set of resource types and function block libraries This method of device modeling is modular and uses a limited number of instruments It also allows modeling of a great variety of system configurations without going into unnecessary details The device management mechanism of IEC 61499 uses an Open XMLbased device management protocol The protocol enables configurability of compliant devices by compliant software tools Service interface function blocks provide the mechanism for encapsulation of hardware-dependent functions, thus contributing to the abstract device model Function Blocks and Intelligent Machines An embedded controller of an intelligent machine needs flexible mechanisms for adding and upgrading software and hardware components during its lifetime From this perspective, the encapsulation and device models of IEC 61499 look far better than the existing PLC realities The encapsulation mechanism of IEC 61499 supports a set of standard programming languages and ensures the platform independence of their semantics The device model of IEC 61499 provides flexible structure of the device, allowing creation and deletion of resources which are containers for applications Implementation of the higher-level intelligent negotiation protocols can be added to an intelligent IEC 61499compliant device during its operation without affecting other functions implemented by the device call the standard functions in the desired order This scenario is illustrated in Figure The engineering station connects into the intelligent conveyor controller and retrieves the interface of the The abstract device model of IEC 61499 provides a mechanism for creating new device types as a set of resource types and function block libraries Thus, embedding an on-chip controller compatible with IEC 61499 to the conveyor can increase the value of the conveyor while also protecting the investments of its users More features of IEC 61499 beneficial for the implementation of intelligent machines are discussed in the following subsections Programmability Although basic functions of a machine can be programmed by its manufacturer and stored in the embedded memory, the user may want to implement more complex functions or specific sequencing of these functions For this purpose, the device must provide several services, such as the provision of information about the device sensor/actuators interface, and/or functional components implementing basic device functions The users may then create their own program which will machine, i.e., names and data types of its inputs and outputs represented in the function block form Then the developer creates the controller function block that has the interfaces compatible (mirror) with the one retrieved Finally, the developer uploads the controller function block to the embedded control device and starts its operation The process can be rendered online in a Web browser to check the correct operation of the controller Moreover, the content of the function blocks can be hidden to protect the proprietary solutions of the intelligent device vendors System Modeling and Simulation When intelligent machines are integrated to more complex “communities” like manufacturing cells, the validation of their coordinated functioning becomes of the utmost importance Retrieve interfaces from the embedded storage Internet Upload the controller and start it remotely Render the process via the Web Engineering and Simulation Station Program the controller function block Figure – Open interfaces, remote programmability, and configurability provided by IEC 61499 WINTER 2007 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 23 Autonomous Control of the RFID Reader Autonomous devices provide description of their functionality in form of function blocks for control and simulation SYSTEM Autonomous Control of the Conveyor Simulation of the executable model of the system Figure – System analysis using a third-party tool Properties of the resulting system must be checked before its operation begins, and this can be done either by simulation or by formal verification The foundations of the formal verification of function block systems (proposed in [20]) implemented in the corresponding tools can extend the simulation by the exhaustive checking of the controller behavior in all possible scenarios Figure illustrates how the behavior of the system of conveyor and RFID reader will be verified The computing devices embedded to both machines store function blocks, implementing autonomous control and simulation of each machine’s behavior Once the machines have formed the system, the engineering station (laptop) retrieves controller and model function blocks from both machines and combines them into the model of the system This model can now be simulated Thanks to the compliance of the function block with the IEC 61499 standard, the semantics of the composed system model will be preserved when executed on the simulation station Moreover, IEC 61499 compliance will allow the use of software tools provided by independent third-party tool vendors, different from the vendors of the machines and embedded devices Intelligent Integration Intelligence may also be needed for the dynamic creation and/or change of a manufacturing schedule and negotiation with the manufacturing execution system (MES) For various application purposes and devices, the set of required and supported intelligent functions can also be different Server of Process Data Network Control Read sensors and publish them to the clients connected via the net Set actuators on remote request Engineering Station Figure 10 – Example of software allocation: control functions are executed on the PC The process data come from the embedded computing device of the conveyor 24 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n WINTER 2007 A minimal set of functions the device can provide is shown in Figure 10 The embedded controller on-chip executes the functions providing access to the object’s data from the network A control application can be executed elsewhere (e.g., on a PC) The control application requests the input data from the controller and sends the calculated output back to it These interactions can have the form of a service request from the embedded device Independence of Computing Platform Various business reasons may require the use of different hardware platforms to control a manufacturing cell, as illustrated in our example This implies the need for portability and distribution of software components, or even hardware components, implementing functionality of autonomous intelligent devices Ideally, it should not really matter where and how the function blocks are physically executed as long as they communicate via a transparent and compliant communication media Some interesting scenarios are illustrated on the familiar example of an automated airport BHS In the hardware configuration shown in Figure 11, a central controller collects the function blocks from the embedded data storage devices and executes them in a cyclic manner similar to that of a PLC The process data can arrive at the controller directly via its own peripheral modules or via the network The use of IEC 61499 function blocks makes the order of execution irrelevant, so that the configuration can be carried out even automatically once the embedded controllers of the machines are plugged into the network Alternatively, the configuration can be fully distributed with mechatronic units having their own embedded controllers that execute their respective function blocks, while the others share control devices Such a degree of flexibility can be achieved if the functional software, which captures the knowledge of object behavior and control, is separated from the specific hardware platform dependencies In IEC 61499, such separation is naturally supported by the encapsulation model and by the device model Device Model of IEC 61499 All the functions of an intelligent machine may coexist in one embedded controller The concept of an intelligent device with versatile functionality has been studied in several R&D projects For example the EU project TORERO [11] proposed a device architecture that combines connectivity, PnP, and IEC 61499 imple- mentation of the control That study is a very convincing test case in favor of the intelligent device concept The only drawback of the TORERO approach is its proprietary architecture On the other hand, IEC 61499 provides an open and flexible device model that can easily accommodate all the functions of the TORERO device and, in addition, offer the flexibility of reconfiguring the device for custom applications The IEC 61499 device model consists of independently operating resources The device management function is implemented as a function block and is allocated to one of such resources and performed via an open-XML-based protocol A device complying with this model can be (re)configured during its operation by sending management commands Thus, it would be possible to deploy a new “container” for a new application and send it there without Central Controller FB Diverter FB Scanner Diverter Scanner FB Scanner COORD FB Conveyor Conveyor Conveyor X-Ray Screening FB Conveyor Figure 11 – Centralized execution of control function blocks Controller of Next Station 7 Input Port Pusher Retracted Pusher Extended Transfer at Magazine Transfer at the Next Station Work Pieces Sucked In Magazine Empty ST2_OK Input Port RESET START STOP ACK Input Port Extended Pusher Move to Pos Magazine Move to Next Station Vacuum Off Vacuum On ALLOW_ST2 Input Port START LED RESTART LED ACK LED Figure 12 – Test bed model of a flexible material handling system WINTER 2007 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 25 disrupting the operation of other applications already running in the device Recent research conducted by Sünder et al [13] proves that even single function blocks can be upgraded on the fly without interrupting their operation This paves the way for implementing truly remote maintenance modes from which both device vendors and device users will strongly benefit PNP Experiments Fast reconfiguration of automated machinery which consists of adding and removing some machines and their elements is one of the main measures of success for intelligent manufacturing systems To prove the concept of the reconfiguration enabled by the use of the function block architecture, a simple laboratory model of a manufacturing system was set up The goals of the experiment were to check the IEC 61499 implementation concepts on a real physical system, in particular its reconfiguration aspects The reconfiguration scenarios considered in the previous projects (HMS, PABADIS, etc.) rather aimed at forming structures from autonomously operating machines and on their collaborative operation (online reconfiguration) These approaches, however, are too advanced to be immediately used in modern factory environments In this article, we illustrate an offline reconfiguration achieved via standardized interfaces of application layer intercontroller communication with mutually exclusive access to common resources This approach allows putting together several machines into STATION_“DISTRIBUTION” NEXT STATION LEFT_OK ALLOW_RIGHT LEFT_OK ALLOW_LEFT RIGHT_OK RIGHT_OK FEEDER LEFT_OK TRANSFER ALLOW_RIGHT RIGHT_OK ALLOW_LEFT LEFT_OK RIGHT_OK ALLOW_RIGHT ALLOW_LEFT Figure 13 – Signal interface of distributed controllers in the permit/block protocol [15] Controller of Next Station TCS Out Input Port Port 0 retracted extend 1 extended empty Input Port 0 7 Move to Pos Magazine Transfer at Magazine Move to Next Station Transfer at the Next Station Vacuum off Work Pieces Sucked in Vacuum on ALLOW_ST2 ST2_OK Input Port 1 Ethernet Figure 14 – Distributed control architecture 26 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n WINTER 2007 Output Port 0 RESET START STOP ACK Netmaster Output Port START LED RESET LED ACK LED 7 a single production system and its operation without a central controller Extensions of this approach were further developed in [18] The approach can be naturally extended to more autonomous behavior of the machine components Testbed The model of an automated material handling system called “Distribution Station” is shown in Figure 12 The “Distribution Station” is a part of a bigger manufacturing system model, which is a chain of several stations representing different stages of a manufacturing process The model consists of two mechatronic units: a feeder unit with a magazine of workpieces and a pusher, and a simple manipulator (transfer unit) which takes workpieces from the feeder (left position) and brings them to the opposite position (called next position or right position), where they are supposed to be taken by other automated machines In addition to the mechatronic models of machines, the station includes a small human-machine interface (HMI) panel of buttons with backlight: RESET, START, STOP, and ACK(nowledge) As an execution platform we have chosen two off-the-shelf devices: Netmaster-II, a product of Elsist, Italy (see [22] for details), and Modular Distributed Intelligence (MO-DI), a product of Tait Control Systems, New Zealand (further referred to as TCS device, see [27]) Netmaster-II comprises SNAP microprocessor (SNAP stands for Simple Network Application Platform), which is based on efficient hardware implementation of the JAVA virtual machine, and all necessary discrete input and output ports The function block run-time environment (FBRT) that is a part of the Function Block Development Kit (FBDK) [16] written in JAVA is executed on the Netmaster In the IEC 61499 terminology, a device type (also named Netmaster) has been developed The device type includes service interface function blocks nm_inputs and nm_outputs providing access to the input and output values, respectively (more details on how to make such a device IEC 61499 compliant can be found in [15]) The MO-DI device is delivered by its vendor TCS with IEC 61499 compliance Experiment Plan Three mechatronic components—feeder, transfer, and HMI panel—are treated in this experiment as prototypes of intelligent machines with autonomous control The experiment conducted with 2) Develop a distributed architecture of devices for the same system with separate embedded IEC61499-compliant control devices in feeder and transfer units Illustrate the remapping of the application developed in stage to the embedded controllers and their seamless integration and execution 3) Test the flexibility of the IEC 61499 device model by developing and The encapsulation mechanism of IEC 61499 supports a set of standard programming languages and ensures the platform independence of their semantics the model consisted of three stages: 1) Develop decentralized controllers of each mechatronic unit These controllers would be prototypes of autonomous controllers of intelligent machines • Encapsulate the controllers in two different function blocks synchronizing their activities via exchange of events and data • Develop a “universal protocol” of intercontroller synchronization that would allow gluing controllers into a distributed system in a PnP manner • Execute the autonomous controllers on a single IEC-61499-compliant control device deploying embedded device types capable of accommodating simulation models, visualization and HMI, and Web rendering of the process parameters Decentralized Control for PnP Integration The first step of the design is the development of decentralized controllers For that purpose, the activities of each “intelligent machine” were defined so that each controller attempts to perform operations as soon as it is not blocked by the controllers of other objects The interface is based on the mutually exclusive access to the areas where mechanical parts Figure 15 – Reconfigurations consisting of trading places of the transfer units or using two units simultaneously WINTER 2007 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 27 can clash Usually, these are the areas where the material transfer occurs In our example, such an area is the “end position” of the feeder unit where the workpiece is picked up by the transfer unit Access to such shared areas can be implemented by standard mutual exclusion algorithms, such as semaphore-based central algorithm, or distributed Ricart and Agrawala algorithm [21] In our experiment, a Distributed System The reader may have noted that although the control in the example discussed in the previous section is decentralized, the function block application is not yet distributed—it is allocated to a single Netmaster device At this stage of the experiment, we added to the system another embedded device capable of executing IEC 61499 function blocks The goal was to recon- The “autonomous” controllers of feeder and transfer discussed above allowed changing the transfer’s position from standing on the right of the feeder to standing on the left (see Figure 15) without program modifications Moreover, the controllers operate properly even if two transfer units are placed on both sides of the feeder In this case, their operations interleave one another Conclusions The IEC 61499 device model consists of independently operating resources simpler mechanism was used that is based on passing Boolean permission or blocking conditions from one controller to the other Partial interfaces of the controllers are illustrated in Figure 13 The operation of each mechatronic unit is essentially autonomous, but some actions have guard conditions “allowed by left/right neighbor” (LEFT OK/RIGHT OK) The permission or blocking conditions are set by the controllers of the neighbors on the right/ left (if any) This approach assumes a linear order of connections of mechatronic units in the production process As seen from Figure 13, this approach also fits well to the hierarchical structure of mechatronic systems Our sample system has a neighbor sorting station on its right side (not shown) The stations interface each other in exactly the same way as their components, i.e., using permission from their left/right neighbors The permission from the right neighbor is passed down to the component controller of the transfer station which is physically interacting with the sorting station If the neighbor station is not present, then the permission is set to the constant “true” as is the case in our example for the left neighbor of the distribution station and the feeder unit The decentralized controllers were implemented in IEC 61499 function blocks and simulated in an FBDK/ FBRT execution environment [16] More details on this implementation can be found in [15] 28 nect the feeder to the TCS device and to reallocate its controller there leaving the controller of the transfer in the Netmaster The transfer and the panel are still connected to the Netmaster device as shown in Figure 14 The devices communicate with each other via the Ethernet network In addition, the Netmaster device communicates with the controller of the next station (its right neighbor) via direct connection of the output ALLOW_ST2 to the corresponding input of the neighboring station controller and vice versa The previously developed function block application could have been very easily modified for execution on the new configuration One needs to create a system configuration with two devices and populate them with the corresponding function blocks Thus, the whole reconfiguration process has been conducted without any change of the control logic of either mechatronic unit One of them was simply removed from one device and “dropped” into another device almost in the drag-and-drop manner (which would be possible if supported by proper software tools) The results of the experiment have proven the assumption of suitability of IEC 61499 to capture elegantly the interprocess communications and preserve the semantics of the decentralized control after distribution Physical Reconfiguration We have experimented with several scenarios of physical reconfiguration IEEE INDUSTRIAL ELECTRONICS MAGAZINE n WINTER 2007 This article describes the features and development of future intelligent machines and concentrates on their information processing infrastructure IEC 61499 function blocks have been used in these experiments as the driving vehicle to achieve important features of the intelligent machines such as reconfigurability, PnP, independence of target execution platform(s), and independence of control strategy (centralized versus distributed) At the same time, a number of open issues require future research: 1) Performance issues that were not discussed in this article remain In the experiments conducted, performance of the Netmaster device was sufficient in most cases However, in general, performance is an issue well recognized by the “function block community,” and a lot of promising work is in progress around the globe (see, e.g., [24]) 2) Exploration of an intermediate format may enable mapping of the specification on various execution platforms and at the same time can be used for the purposes of formal verification and validation 3) Experimentation with large real-life systems is needed to gain insight into the properties of the function block technology While IEC-61499-compliant devices and tools are starting to appear on the market, the whole issue of migration from the existing PLC-based control systems to IEC 61499 still requires further investigation One avenue for facilitating the migration could be implementation of IEC 61499 with the cyclic scan paradigm on PLCs This approach has been explored in [24] and [26] and even used in the first commercial platform ISaGRAF [27] Another important enabler of IEC 61499’s future success is development of methodologies to automatically convert the existing PLC programs into function blocks This will allow building software tools for automated or computer-aided migration The industry is starting to realize the clear benefits of the component-based design using IEC 61499 Hence, the advent of powerful IEC-61499-based design tools and methodologies is the not-so-distant future Biographies Valeriy Vyatkin is a senior lecturer in the Department of Electrical and Computer Engineering of the University of Auckland His research interests are in the area of industrial informatics, including software engineering for industrial automation systems, distributed software architectures, methods of formal validation of industrial automation systems, and theoretical algorithms improving their performance He has published more than 100 papers in international journals and refereed conferences and three books, including the recently published IEC 61499 Function Blocks for Embedded and Distributed Control Systems Design Recently, he has been involved in international research around future architectures for industrial automation systems Zoran Salcic holds the chair in Computer Systems Engineering in the Department of Electrical and Computer Engineering of the University of Auckland His research interests are in complex digital systems architectures and design, prototyping and customization of digital systems, and new architectures and formal models for embedded systems for combined data- and control-driven applications He has published nearly 200 papers in journals and refereed conferences, seven books, and numerous technical reports In recent years, he has been involved in projects that are creating a bridge between function blocks, their formal foundation, and execution on novel embedded platforms Partha S Roop received a B.E degree in engineering from the College of Engineering, Anna University, an MTech degree from Indian Institute of Technology, Kharagpur, and a Ph.D in computer science from UNSW, Sydney He is a senior lecturer in the Department of Electrical and Computer Engineering at the University of Auckland in New Zealand His research interests include the design and verification of embedded systems, especially formal verification techniques such as model checking and module checking and the applications of concurrency theory He also works on system-level modeling languages and multiclock system design John Fitzgerald is engineering manager of Glidepath (New Zealand), the leading provider of innovative airport baggage handling systems integrating design, manufacture, and software solutions He has been involved in the automation industry for 18 years, for the last eight years in the baggage handling business His key responsibilities include management of software development, system commissioning, and product and project management Previously, when working for Fisher & Paykel, he worked in an R&D team involved in designing and manufacturing a proprietary industrial controller, the PSC (programmable state controller) Currently, he is in charge of R&D towards the next generation of baggage handling controls References [1] Function Blocks for Industrial-Process Measurement and Control Systems—Part 1: Architecture and Part 2: Software Tools Requirements, IEC, 2005 [2] Y Koren, U Heisel, F Jovane, T Moriwaki, G Pritchow, H Van Brussel, and A.G Ulsoy, “Reconfigurable manufacturing systems,” CIRP Annals, vol 48, no 2, pp 527–540, 1999 [3] Holonic Manufacturing Systems Consortium, “Holonic manufacturing systems overview,” 2002 [Online] Available: http://hms.ifw.unihannover.de [4] A Lüder, A Klostermeyer, J Peschke, A Bratoukhine, and T Sauter, “Distributed automation: PABADIS versus HMS,” IEEE Trans Ind Informatics, vol 1, no 1, pp 31–38, 2005 [5] H VanBrussel, J Wyns, P Valckenaers, L Bongaerts, and P Peeters, “Reference architecture for holonic manufacturing systems: PROSA,” Comput Ind., vol 37, no 37, pp 255– 274, 1998 [6] P Vrba, “MAST: Manufacturing agent simulation tool emerging technologies and factory automation,” in Proc ETFA’03, Sept 16–19 2003, vol 1, pp 282– 287 [7] K Thramboulidis, “IEC 61499 in factory automation,” in Proc Int Conf Industrial Electronics, Technology and Automation, Dec 10–20, 2005 [8] R Zurawski, Ed., The Industrial Information Technology Handbook Boca Raton, FL: CRC Press, 2005 [9] “Specifications of the foundation for physical intelligent agents (FIPA),” [Online] Available: http://www.fipa.org/specifications/index.html [10] L.M Martinez Lastra, “Reference mechatronic architectures for actor-based assembly systems,” Ph.D thesis, Tampere University of Technology, 2004 [11] C Schwab, M Tangermann, A Lüder, A Kalogeras, and L Ferrarini, “Mapping of IEC 61499 function blocks to automation protocols within the TORERO approach,” in Proc 2nd IEEE Conf on Industrial Informatics, Berlin, June 2004, pp 149–154 [12] R Lewis, Modelling Distributed Control Systems Using IEC 61499 London: IEEE, 2001 [13] C Sünder, B Favre-Bulle, and V Vyatkin, “Towards an approach for the verification of downtimeless system evolution,” in Proc IEEE ETFA 2006, Prague, 2006, pp 1133–1136 [14] J.L.M Lastra, A Lobov, L Godinho, and A Nunes, “Function blocks for industrial-process measurement and control systems: IEC61499 introduction and run-time platforms,” Institute of Production Engineering, Tampere University of Technology, Tampere, 2004 [15] V Vyatkin, IEC 61499 Function Blocks For Embedded and Distributed Control Systems Design Research Triangle Park, NC: ISA, 2007 [16] Function Block Development Kit (FBDK/FBRT) [Online] Available: http://www.holobloc.com/ doc/fbdk/index.htm [17] F Jammes and H Smit, “Service-oriented architectures for devices-The SIRENA view,” IEEE Trans Ind Inform., vol 1, no 1, pp 62–70, 2005 [18] M Hirsch, C Gerber, H.-M Hanisch, and V Vyatkin, “Design and implementation of heterogeneous distributed controllers—A case study,” in Proc 5th IEEE Conf Industrial Informatics, Vienna, 2007, pp 829–834 [19] V Vyatkin, “The potential impact of the IEC 61499 standard on the progress of distributed intelligent automation,” Int J Manufact Technol Manag., vol 8, no 1/2/3, pp 101–125, 2006 [20] V Vyatkin and H.-M Hanisch, “Verification of distributed control systems in intelligent manufacturing,” J Intell Manufact., vol 14, no 1, pp 123–136, 2003 [21] G Couloris, J Dollimore, and T Kindberg, Distributed Systems: Concept and Design Reading, MA: Addison-Wesley, 2005 [22] Netmaster controller Elsist s.r.l [Online] Available: www.elsist.it [23] G Black and V Vyatkin, “On practical implementation of holonic control principles in baggage handling systems using IEC 61499,” in Proc 4th Int Conf Holonic and Multi-agent Systems in Manufacturing, (HoloMAS 2007), Regensburg, 2007, pp 314–325 [24] A Zoitl, G Grabmair, F Auinger, and C Sünder, “Executing real-time constrained control applications modelled in IEC 61499 with respect to dynamic reconfiguration,” in Proc 3rd IEEE Conf Industrial Informatics, Perth, 2005 [25] J.L.M Lastra, A Lobov, L Godinho, and A Nunes, “An IEC 61499 application generator for scan-based industrial controllers,” in Proc 3rd International Conference on Industrial Informatics (INDIN 2005), Perth, 2005 [26] L Ferrarini, A Romano, and C Veber, “Automatic generation of AWL code from IEC 61499 applications,” in Proc 4th IEEE Conf Industrial Informatics, Singapore, 2006, pp 25–30s [27] ISaGRAF Workbench, May 2007 [Online] Available: www.isagraf.com [28] Tait Control Systems, June 2007 [Online] Available: www.tcs-nz.co.nz WINTER 2007 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 29 [...]... taken by other automated machines In addition to the mechatronic models of machines, the station includes a small human-machine interface (HMI) panel of buttons with backlight: RESET, START, STOP, and ACK(nowledge) As an execution platform we have chosen two off-the-shelf devices: Netmaster-II, a product of Elsist, Italy (see [22] for details), and Modular Distributed Intelligence (MO-DI), a product of ... the concept of a function block, which is a model for encapsulation of automation knowledge and for making such knowledge portable This model ensures compatibility of applications on the source... products The key enablers of the flexibility in this new standard are: n the encapsulation of knowledge into function blocks, n the application model as a network of function blocks, Conveyor... applications that are represented as hierarchical networks of function blocks Thus, system development can now be done in a high-level platform-independent form of function block applications which can be