Toward Real-Time Distributed Intelligent Control: A

744

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 37, NO. 5, SEPTEMBER 2007

Toward Real-Time Distributed Intelligent Control: A Survey of Research Themes and Applications Robert W. Brennan, Member, IEEE

Abstract—Distributed intelligent control involves matching the control model more closely with the physical system. This is particularly relevant to industrial control systems that are required to control widely distributed devices in an environment that is prone to disruptions. Although considerable work has been conducted on the application of agent technology to the upper levels of manufacturing control (e.g., scheduling, planning, supply chain management, enterprise integration), the application of these techniques to the physical level of control where real-time constraints are prevalent is relatively new. This paper provides background on the work in this area, discusses key research themes in developing real-time distributed intelligent control systems for industrial applications, and concludes by sharing thoughts about the future prospects in this area. Index Terms—Distributed control, intelligent control.

I. INTRODUCTION N RECENT years, there has been growing interest in the application of distributed artificial intelligence (DAI) in the industrial systems domain. This research has been primarily motivated by the promise that DAI can be applied to the complexity and unpredictability of modern industrial systems to make them more manageable and robust. Distributed intelligent control involves matching the control model more closely with the physical system. This is particularly relevant to industrial control systems that are required to control widely distributed devices in an environment that is prone to disruptions. With this model, control is achieved by the emergent behavior of many simple, autonomous, and cooperative entities (i.e., agents) that “decide locally not only how to act (as subroutines do), and what actions to take (as objects do), but also when to initiate their own activity” [1]. The natural fit of multiagent systems (MAS) technology [2], [3] to industrial control problems has resulted in many applications in this domain [4]. Consequently, this has led to holonic manufacturing systems (HMS), a manufacturing-specific application of the broader MAS approach [5]. More recently, there has been considerable interest in extending this research from the upper, planning, and scheduling level of control [6], [7] to the physical device level. For example, members of the HMS consortium focused on defining a lowlevel control (LLC) architecture [8]–[10] that is based on the

I

Manuscript received July 26, 2006; revised November 24, 2006. This work was supported in part by a Marie Curie Transfer of Knowledge Fellowship of the European Community’s 6th Framework Program under Contract MTKDCT-2005-029755: CzechVMXT. This paper was recommended by Associate Editor M. Fletcher. The author is with the Schulich School of Engineering, University of Calgary, Calgary, AB T2N 1N4, Canada (e-mail: [email protected]). Digital Object Identifier 10.1109/TSMCC.2007.900670

International Electro-Technical Commission (IEC) 61499 function block (FB) standard [11]. With this work as a basis, IEC 61499 FBs have been used at the device level for dynamic reconfiguration [12], [13], safety management [14], and system validation [15]. This work, and parallel work on the application of MAS has led to range of industrial applications of real-time distributed control [16] such as DaimlerChrysler’s holonic control implementation for engine assembly [17], Rockwell Automation’s design of a reconfigurable ship-based chilled-water system [18]–[20], the integration of radio-frequency identification (RFID) systems [21], and applications to municipal water systems [22] and military platforms [23], [24]. Despite a considerable amount of recent work on distributed real-time intelligent control systems, some key challenges remain. For example, Hall et al. [25] identify four barriers to widespread adoption of these systems: 1) lack of skills in distributed system design, 2) lack of a methodology to predict the aggregate behavior of agents, 3) the cost of adoption and implementation, and 4) lack of mature global standards. Additional challenges in this area include: 5) a lack of realtime agent development tools, 6) a lack of methodologies for verifications and validation [26], and 7) the need for formal work on safety-critical system design [27]. Currently, the key issues in distributed real-time intelligent control center around design. For example, the methodologies used to design these systems tend to be ad hoc (challenges 1 and 2), validation tends to be by trial and error (challenges 2 and 6), safety has been left to the application developer (challenge 7), there is a lack of industrial strength software development tools (challenge 5), and those that exist are not fully compliant with standards and/or the standards are vague with respect to compliance (challenge 4). In this paper, we look at the past work on the development of distributed real-time control systems as well as the recent work on tackling these outstanding challenges. The paper focuses specifically on this recent work on the application of DAI techniques at the device level, i.e., the realm of real-time, industrial automation and control. We begin in Section II with a summary of the general requirements for next-generation industrial systems, then focus specifically on extant and emerging industrial automation and control systems. Next, we review the main research themes in this area in Section III. In particular, we focus on the key research issues, current progress in this area, and identify outstanding and unresolved problems. As noted previously, although this research was initially motivated by problems in the manufacturing domain, the range of applications has broadened with the maturity of this field. The paper concludes with a section on the future of real-time distributed

1094-6977/$25.00 © 2007 IEEE Authorized licensed use limited to: Lamar University. Downloaded on June 10, 2009 at 10:49 from IEEE Xplore. Restrictions apply.

BRENNAN: TOWARD REAL-TIME DISTRIBUTED INTELLIGENT CONTROL

745

intelligent control. Based on our review of the present state of this research area, we provide our opinions of the directions and possibilities of future work in this area in this section.

II. BACKGROUND Current industrial automation systems are expected to operate in inherently complex and unpredictable environments that consist of a wide range of resources distributed across large areas. Unfortunately, these systems are not always well matched to this environment, i.e., they are typically implemented using large, and often expensive, computer hardware platforms that support monolithic computer control applications. As a result, when the control system is installed, it can take months before the system gets operational, and changes are inevitably complex and difficult to implement. Both of these factors contribute significantly to the total cost of the industrial control project. Additionally, when operational, these are characteristically “fragile” [5], or in other words, not easily adaptable, and as a result, unable to cope with change. In order to provide some context, we can look at a typical industrial control example such as a programmable logic controller (PLC) system used to control the ice temperature of a typical speed skating oval (e.g., the Calgary Olympic Oval [28]). This system involves direct control of multiple pumps and valves for brine water and multiple refrigeration units, the monitoring of a large number of temperature sensors, and logic for state control, alarm and shutdown monitoring, and human–machine interface (HMI). The resulting control system is complex. When developed using extant software, hardware, and design methodologies, programming and ultimate commissioning is inevitably timeconsuming and costly. Also, if any latent errors are found in the software, or if changes are required (e.g., the addition or removal of a pump), it takes the control engineering considerable time to get up to speed on the software and make the required changes: also, there is typically the added risk of introducing new errors to the system. To address this issue, researchers have identified various requirements or needs of the next generation of industrial systems. In this section, we summarize the primary needs that were identified in the early stages of Intelligent Manufacturing Systems research, and then, compare this with the more recent work in this area. These general needs will then be used to provide the context for our review of intelligent industrial automation systems that follows in the remaining sections of this paper.

A. Primary Needs for Next-Generation Industrial Systems Christensen [29] provides a good starting point for the basic requirements of next-generation manufacturing systems. In this paper on the initial architecture and standard directions for HMS, the primary needs are summarized in a list of “critical factors for system architecture.” These needs, which followed from the 1994 feasibility study on HMS, are summarized as follows [29].

Fig. 1.

Primary needs of next-generation industrial systems.

1) Disturbance handling provides better and faster recognition of and response to machine malfunctions, rush orders, unpredictable process yields, human errors, etc. 2) Human integration supports better and more extensive use of human intelligence. 3) Availability provides higher reliability and maintainability despite system size and complexity. 4) Flexibility supports continuously changing product designs, product mixes, and small lot sizes. 5) Robustness maintains system operability in the face of large and small malfunctions. Shortly after the HMS feasibility study, much of the fundamental work on the reference architecture for HMS was conducted at the Katholieke Universiteit Leuven [5], [30], [31]. Not surprisingly, the basic requirements for HMS remained relatively consistent with Christensen’s [29] list. For example, in the area of “disturbance handling,” Valckenaers et al. [5] identified “autonomy” as the “ability to work under permanent perturbation,” “flexibility” was identified as the “ability to accept modifications in the production settings” (this was extended to include the need for “agility,” or the “capacity to use different alternatives”), and “robustness” was identified as the “capability to stay in a legal and stable state under perturbations.” “Cost” was also added to the list of needs as the cost of the initial development of the control system [5] as well as the maintenance cost of the control system [31]. In his thesis on the reference architecture for HMS, Wyns [31] identified three interrelated sets of requirements: “system requirements,” “system architecture requirements,” and “reference architecture requirements.” In this case, the reference architecture “serves as a template for developing system architectures for specific problems” while the system architecture is “used to implement the final control system” [31]. In this paper, we focus on the “system requirements”; however, these requirements can be extended to the reference architecture as Wyns [31] suggests. More than a decade has passed since the HMS feasibility study reported by Christensen [29]; however, as illustrated in Fig. 1, the basic requirements for the next-generation manufacturing systems promised by HMS have not changed. For

Authorized licensed use limited to: Lamar University. Downloaded on June 10, 2009 at 10:49 from IEEE Xplore. Restrictions apply.

746


example, Marik et al. [32] hit all of the primary needs identified by Christensen [29]: disturbance handling (i.e., “anticipate critical situations and prepare . . . for them”), human integration (i.e., “system must by unified”), availability (i.e., “high degree of reliability”), flexibility [i.e., “reconfiguration (selforganization)”], and robustness (i.e., “reactive and proactive features”). Similarly, McFarlane and Bussmann [33] identify a set of “manufacturing system” and “control system” requirements in their paper that map closely to these primary needs. In some cases, however, the focus of work in this area has become more specific. For example, Fletcher et al. [34] focus more on the issue of the requirements at the device level, and as a result, focus less on human integration issues while Rahimifard et al. [35] focus on specialized IT design tools to support holonic manufacturing, and as a result, focus on human integration (see also [36] and [37] for more on human-centered manufacturing). More recently, Martinez Lastra and Colombo [26] focus on the engineering tools required for widespread adoption of holonic systems, and as a result, touch on all of the basic requirements. B. Extant Industrial Automation Systems Before looking at how these general needs are being tackled, we will first look at how industrial automation and control is performed in existing systems. In the vast majority of cases, PLCs are the preferred choice for user-customized automation on the shop floor, partially for historical reasons, but also for their many benefits in this domain. PLCs evolved from hard-wired relay logic, which was used for simple sequential control before programmable systems were a possibility on the shop floor. As a result, the relay logic diagrams used by electricians to describe these circuits strongly influenced the programming notation used by the first PLCs, which continues to be used today in standardized ladder diagram (LD) notation [38]. Although LD appears quite unwieldy to developers versed in modern programming languages, it does have advantages that have justified its longevity and continuity as an industrial automation and control programming language. In particular, LD-based systems have proved to be very maintainable by a wide range of personnel. For example, its ladder logic notation is intuitive to system developers, plant operation personnel, and technicians. It is also a relatively simple notation that allows the user to quickly visualize the control logic’s interface with physical devices as well as the current state of the system. The popularity of PLC-based systems is also tied to the suitability of PLC hardware in industrial environments. Current PLC systems tend to be fast (i.e., response times in the milliseconds), durable, and reliable (i.e., capable of continuous operation on the shop floor). Also, the scan-based execution cycle used by PLCs makes their behavior very predictable. Additionally, most PLC manufacturers provide “soft PLCs” that allow users to verify their software application prior to physical commissioning (e.g., Rockwell Automation’s SoftLogix controller [39]). The advent of soft PLCs provides users with increased levels of confidence in their final software implementation, and as will be discussed later, has the potential to

pave the way for more sophisticated software solutions such as agent systems via enhanced simulation environments for system verification. On the surface, PLC hardware is considerably more expensive than PC hardware (with equivalent processor capacity). However, when one considers their reliability and maintainability in industrial environments, they become the most cost-effective choice for typical industrial automation applications. Recently, general-purpose embedded devices have provided an alternative to PLCs. These devices are typically low-cost and can be programmed in a wide variety of languages. However, industry is still inclined toward PLCs. Although general-purpose embedded devices offer powerful programming features to control software developers, they typically do not support the entire software life cycle for industrial automation and control. In particular, one must consider that these devices must be accessible to a wide range of specialists with very different educational and practical backgrounds. Despite the popularity of LD, users quickly recognized its limitations. For example, a ladder logic program of a typical application often results in complex software that is difficult to manage during configuration, and especially, during maintenance. The difficulty lies in a typical problem with real-time control software that is exacerbated by ladder logic: individual components of PLC software are characteristically asynchronous, resulting in unpredictable interactions. This makes the initial configuration of the software (i.e., commissioning) extremely difficult and labor-intensive, but also makes reconfiguration risky. To address this, IEC 61131-3 has become the dominant standard for programming PLCs [38]. The authors of IEC 61131-3 recognized that to remedy this problem, modular software would be required, i.e., software that can be divided into understandable modules with well-documented interfaces between the modules. IEC 61131-3 overcomes many of the problems with conventional, ladder logic programming by incorporating many of the features of modern high-level programming languages and object-oriented languages. In support of good programming practice, IEC 61131-3 allows programs to be broken into functional elements [program organization units (POUs)], requires strong data typing, supports full execution control, and supports data structures (i.e., encapsulation). A strong contribution to the success of IEC 61131-3 is that it does not abandon LD. Instead, it provides the user with a choice of programming languages that include the assembler-like instruction list (IL), a Pascal-like structured text (ST), LD, and the object-based function block diagram (FBD). Additionally, IEC 61131-3 allows the user to specify overall program execution using a Grafcet-like sequential function chart (SFC). Unfortunately, when viewed in the context of the previous requirements for next-generation industrial automation and control systems, IEC 61131-3 alone does not offer salvation. As noted previously, a closer match between the control model and the physical system is required. In other words, the basic requirement is for a PLC-like system that consists of modular hardware and component-based software working together to support distributed intelligent control.



The main disadvantage of IEC 61131-3 in this context is that its execution semantics do not fit well with these new requirements for distributed, flexible automation systems. For example, IEC 61131-3 system’s flexibility and disturbance handling capabilities are limited because it is difficult to manage change dynamically. As Zoitl et al. [40] note, the timing of software switches cannot be easily controlled and it is difficult to synchronize internal states. Given the cyclically scan-based execution model of IEC 61131-3 programs, they are also very sensitive to the order in which POUs are placed in the program. For example, in an FBD-based program, individual FBs modify global data as they are executed, which, in turn, becomes input to other FBs. As a result, a change in the order of execution of the FBs can result in entirely different behavior of the program. Correspondingly, if the PLC hardware is distributed, complex synchronization problems can occur when a specific execution order is desired. As will be discussed next, this does not preclude IEC 611313’s use for distributed intelligent control. In fact, it can be argued that given IEC 61131-3’s popularity, the only logical means to industrial adoption of distributed intelligent control technology is to work around its limitations. However, these limitations have led to a range of alternative and complementary approaches to distributed intelligent control.

C. Approaches to Distributed Intelligent Control As discussed in the previously, extant PLC-based systems are not well suited to the new requirements for distributed intelligent control. However, given the ubiquity of PLC technology, it makes sense to approach distributed intelligent control from this perspective. Currently, researchers in this area have used two IEC standards for PLCs with this goal in mind: IEC 611313 and IEC 61499. The first approach is based on the philosophy that industry will be more inclined to adopt intelligent control technology if it is based on a proven technology such as IEC 61131-3 [25]. Distributed intelligent control is achieved in this approach by separating the “intelligent” part of the system from the realtime part of the system. For example, Tichy [41] uses a layered architecture for their distributed control agents (DCA) that use upper level software agents (implemented in C++) for planning and diagnostics and lower level IEC 61131-3 LD logic for realtime control. In order to allow users to develop their applications with familiar IEC 61131-3 languages while exploiting DAI through widely accepted software engineering approaches such as autonomous agents and MAS, a seamless interface between the real-time and “intelligent” layers is required with this approach. Currently, two techniques are used. The first is a data table approach [42] that parallels the approach used to share data in PLCs. The second is to use function block adapters (FBA) as proposed by Heverhagen and Tracht [43]. This approach is intended to provide a means to unambiguously express the interface mapping between Real-Time Unified Modeling Language (RT-UML) capsules and IEC 61131-3 FBs.

747

The second PLC-based approach to distributed intelligent control also recognizes the need to integrate new solutions with legacy systems, but recognizes that a new model is required to support current object- and component-oriented realities. Research in this area has focused on the use of the IEC 61499 standard, “function blocks for industrial process measurement and control” [11], which can be thought of as an extension of the IEC 61131-3 FB model to support event-based, distributed control while supporting efficient encapsulation of legacy software (e.g., IEC 61131-3 LD, ST, FBD, etc.). However, IEC 61499’s scope is broader than just a software model: it defines a system model to support portable, interoperable, and configurable distributed automation components [44]. With this as a basis, IEC 61499 has been central to work on the development of “automation objects” [44]–[46]. Broadly speaking, an automation object can be thought of as an abstraction for a mechanical device and its associated embedded intelligence. The resulting software components can be tailored to a variety of functional domains and can serve as the basic building blocks for distributed intelligent control applications. Rather than attempting to build the control application directly as in the previous approaches, the third approach attempts to synthesize the controller directly from a formal definition of the controlled system’s behavior and the control specifications. This process, first proposed by Ramadge and Wonham [47], is the foundation for discrete event systems (DES) theory: most commonly modeled using finite automata, though Petri nets and process algebra can also be used [48]. Central concerns of this approach are liveness (i.e., the control system is able to perform at a specified minimum level of performance) and safety (i.e., the system does not enter states that risk equipment or personnel). DES tends to focus on a more centralized model than we have looked at so far, with the formulation of a central controller or “supervisor” that observes system events and determines at discrete points in time which events must be prevented from occurring. Since the DES supervisor is in the form of a finite state machine, translation to a PLC is essentially a matter of making the PLC behave as a state machine. As Fabian and Hellgren [49] show, this is an automatic process for basic state-based logic (e.g., conventional LD programming); however, the translation becomes unwieldy for more complex programs (e.g., ST algorithms and FBD programs). Unfortunately, DES becomes unwieldy when considering real-life controllers, as the effort to compute the supervisor increases exponentially with the number of system components. As a result, decentralized approaches that consider the specific structure of the DES have been considered to reduce the computational cost [50], [51]. Recently, this has led to work on supervisor synthesis methodologies that analyze the concurrent actions of independent supervisors over shared resources, i.e., distributed DES [52]. Distributed intelligent DES is still in its early stages. However, work is currently being conducted on extending this work from deadlock avoidance to adaptive behavior [53]. More work is required in this area before intelligent control applications are realized. However, given the formal mathematical basis of DES, it does appear to have potential to support the research


748

Fig. 2.


Research themes in real-time distributed intelligent control.

on verification and validation, and safety critical design of distributed real-time intelligent control systems surveyed in this paper. In the remainder of this paper, however, we will focus almost exclusively on PLC-based systems approaches such as IEC 61131-3 and IEC 61499. III. RESEARCH THEMES IN REAL-TIME DISTRIBUTED INTELLIGENT CONTROL In this section, we provide an overview of the main research themes in real-time distributed intelligent control. Although researchers have tackled the needs described in the previous section from various angles, we have found it useful to organize the work in this area in four broad areas: architecture, reconfiguration, safety, and tools and techniques. As illustrated in Fig. 2, we view the work on architectures as spanning the fundamental research issues of safe system operation and dynamic and intelligent reconfiguration. The work on tools and techniques ultimately supports this fundamental research. In the following sections, each of these themes are first introduced in the context of the primary needs of next-generation industrial systems, then the relevant research in each area is summarized. A. Architecture The work on architecture spans all of the research themes in real-time distributed intelligent control and is tightly linked to the researchers’ individual solutions. For example, various architectures have been proposed to perform dynamic reconfiguration. As a result, rather than surveying all of these architectures in this section, we instead provide an overview of the work that served as a foundation for the later, more specialized architectures, i.e., the work on agent and holonic architectures. Individual solutions are then discussed in the context of the research themes in the later sections of this paper. 1) Background: In this paper, we approach architecture from the point of view of MAS, which can be thought of as a “general software technology that was motivated by fundamental research questions” [54] such as how groups of software agents work together to solve a common problem [55]. Huhns and Singh [56] define agents as “active, persistent (software) components that perceive, reason, act and communicate.” This definition follows from the notion of a software object where the focus is on data abstraction, encapsulation, modularity, and inheritance [57]. Typically, the term “architecture” is applied

to multiagents systems from two points of view: 1) agent architecture and 2) system architecture. By “agent architecture” we mean the internal structure that is used to define an agent, whereas “system architecture” focuses on how groups of agents interact and are organized. Beginning with agent architecture, two general classifications are typically used: 1) behavioral and 2) internal organization. Agent architectures that are classified by the agent’s behavior fall into four main categories: deliberative, reactive, collaborative, and hybrid. Deliberative agents (aka, cognitive agents, intentional, or goal-directed agents) have domain knowledge and the planning capability to undertake a sequence of actions with the intent of moving toward a goal [58]. One of the most well-known deliberative agent architectures is the BDI (belief, desires, intentions) architecture that describes the internal state of an agent by means of a set of mental categories; to control is actions, the agent rationally selects its course of actions based on its representations [59]. At the other end of the behavioral spectrum are reactive agents (aka behavior-based agents or simulated agent architectures), where agents do not have a model of the world and they respond in an event–condition–action mode [60]. This architecture tends to be used in LLC, robotics, and physical sensor applications because of its timeliness and emergent behavior. One of the earliest reactive agent architectures is the subsumption architecture proposed by Brooks [60] where multiple behaviors associated with a specific level of activities compete to win control over activities. As their name implies, collaborative agents (aka interacting agents or social agents) work together to solve problems. Clearly, for this type of architecture, communication and cooperation are important elements. An example of simple collaborative agents comes from Davis and Smith’s [61] contract net: the basis for collaboration in this architecture is an interagent negotiation protocol between manager agents and bidder agents. Mueller et al. [62] use a layered-architecture to implement collaborative agents. In their InteRRap architecture, the lowest level deals with reactive behavior, the middle level with planning and agent goals, and the uppermost layer deals with social interactions [62]. Finally, hybrid agents fall somewhere in the middle of the deliberative agent and the reactive agent scale. The motivation for this type of agent came about because purely reactive architectures cannot implement general goal-directed behavior, while purely deliberative architectures are not effective in large, complex systems due to their potentially huge symbolic knowledge representations. An example of a hybrid architecture can be found in Franklin’s [63] “general agent architecture.” It was noted previously that reactive agents architectures tend to be the choice for device level control. However, this does not discount other behavioral architectures. For example, Mali [64] compares reactive, deliberative, and hybrid architectures for autonomous robotics and proposes a taxonomy for cooperative problem solving in this domain. As noted previously, agents can also be classified by their internal organization. In particular, five main categories are typically used: modular, subsumption, blackboard, production



system, and layered. The modular agent architecture is typically organized as an assembly of agent modules that realize a particular agent function, e.g., planning, execution, perception, etc. These architectures tend to be associated with more complex agents, and in particular, deliberative agents. The artificial intelligence (AI) research community originally developed the blackboard architecture for single-agent systems [65]. However, recently it has been widely used as the architecture for various MAS. The main characteristic of the blackboard architecture is a global database (blackboard) that serves as the memory for the system. All computational and solution state data for the agents are stored in this central location. As the name implies, the production system agent architecture [66] is based on the production system approach to knowledge management. In this case, the production system is implemented as an agent and is capable of interacting with other agents. Finally, layered architectures are typically organized with components for perception and action at the bottom and reasoning at the top: perception feeds the reasoning subsystem, which governs action [56]. As such, these architectures fall in the “hybrid architecture” classification noted previously (i.e., a blend of deliberative and reactive). When designing an agent system with multiple agents, however, the question follows, how should one organize these independent decision-makers? This question of “system architecture” has led industrial and academic researchers to investigate a spectrum of decentralized control architectures ranging from hierarchical decomposition to a completely decentralized (heterarchical) approach where individual controllers are assigned to subsystems and may work independently or may share information. Much of the early work on nonhierarchical or heterarchical control architectures is based on the concept of distributed data processing systems (DDPS) described by Enslow [67] and the subsequent work on autonomy and cooperation in distributed systems by Vamos [68] and Hatvany [69]. This work led to the seminal work on distributed sensor systems by Davis and Smith [61], and more importantly, on the “contract net,” which is used to this day as a distributed problem solving protocol. For example, the early work in the manufacturing domain on yet another manufacturing system (YAMS) [70] and on nonhierarchical cell control [71] both relied on the contract net. Despite the benefits of a purely distributed or heterarchical approach, there are also many drawbacks. In particular, the disadvantages of this approach are that global optima cannot be guaranteed and predictions of the system’s behavior can only be made at the aggregate level [72]. However, even with conventional centralized approaches, global optima often cannot be achieved in practice and the detailed predictions provided by these systems are frequently invalidated. Hierarchical and heterarchical architectures lie at opposite ends of the distributed control architectures spectrum. The hierarchical approach is rigid and suffers from many of the shortcomings of the centralized approach, yet it offers clear advantages in terms of overall system coordination; alternatively, the heterarchical approach is flexible and fault-tolerant, but arguably difficult to coordinate. Federated architectures are in-

749

creasingly being considered as a compromise between these two extremes, particularly in the area of control of large-scale systems. Like heterarchical architectures, federated architectures have no explicit shared facility for storing data, i.e., data are stored locally. The structure of a federated architecture is achieved through message passing between agents and specialized agents called “middle agents.” In this section, we summarize four main federated architecture approaches that have been used in the MAS literature: 1) the facilitator approach, 2) the broker approach, 3) the matchmaker approach, and 4) the mediator approach. As the name implies, the facilitator approach utilizes a specialized agent called a facilitator to coordinate groups of agents. This approach was first proposed by McGuire et al. [73] for their SHADE project, where facilitator agents were used to provide a reliable network communication layer, route messages, and coordinate the control of multiagent activities. A key characteristic of this approach is that communication and coordination is facilitated by the middle agents, i.e., facilitator agents and agents communicate with each other, facilitator agents communicate with each other, but individual agents do not communicate with each other. In other words, agents do not direct their messages to other agents, but rely on facilitator agents to route their messages to agents that are able to handle them. This may involve translating the message, decomposing the problem, and scheduling the subproblems. Similarly, the broker approach uses a specialized agent to find suitable agents for a particular task [74]. The main difference between the two approaches is that all agents in the broker architecture may contact all brokers to find service agents; agents in the facilitator architecture must communicate through a single facilitator agent. The matchmaking approach uses brokering mechanisms to match agents together; however, it goes one step further by then allowing these agents to be directly linked. Once this link is established, the matchmaker agent removes itself from the group and allows the remaining agents to proceed with communication. An important application of this approach is that of Internet information retrieval [75]. This approach is often manifested with “yellow-page” agents, which can be thought of as a variation of the matchmaker agent: in this case, however, an explicit mechanism is required to allow agents to register their services on an agent services directory or “yellow pages.” The mediator approach shares many of the characteristics of the three federated architectures discussed previously, but brings an additional coordination role to the table. In other words, mediator agents use brokering and matchmaking mechanisms to help agents find other agents to establish collaborative subsystems of agents or coordination clusters. Once these clusters of agents are established, the mediator’s role is expanded to include mediation behaviors, which focus on high-level policies for situations such as breaking decision deadlocks. Early work on the mediator approach was conducted by Wiederhold [76] and Gaines et al. [77]. The enhanced coordination role of the mediator architecture has made it particularly popular for real-time distributed control applications. For example, as will be discussed next, this approach has close ties with holonic systems architectures,


750


which is where much of the early work on real-time distributed control began. Given the real-time constraints imposed on industrial control systems and their focus on state-based control, these systems tend to be most suited to reactive agents that are organized in a layered architecture. As will be discussed in Section IIIA3, coordination becomes an important architectural consideration in these systems, and arguably, the defining aspect of their intelligence. 2) Holonic Control Architectures: Holonic systems share many of the characteristics of MAS, and in fact, can be thought of as a specialized type of MAS [78]. More specifically, a holonic system “consists of autonomous, self-reliant units, called holons” [54] that cooperate to achieve overall objectives. Key properties of these systems include autonomy, cooperation, self-organization, and reconfigurability [6]. As a result, a holon can be thought of as a collaborative and reactive agent from an agent architecture point of view. A key characteristic of holons that distinguish them from software agent is that they consist of an information processing part and often a physical processing part. Although the Foundation for Intelligent Physical Agents [79] considered this use of agent technology as early as 1996, the vast majority of agent technology is concerned only with software agents. Given the close link that the research surveyed in this paper has with physical devices, we argue that all of the architectures proposed for realtime distributed intelligent control systems are characteristically holonic control architectures on this basis. Another important holonic concept is the notion of functional decomposition. Simon’s [80] observation that “complex systems evolve from simple systems much more rapidly if there are stable intermediate forms than if there are not” is at the heart of this. In other words, the complexity of dynamic systems can be dealt with by decomposing the systems into smaller parts. A consequence of this is the idea that holons can contain other holons (i.e., they are recursive). Also, problem solving is achieved by holarchies, or groups of autonomous and cooperative basic holons and/or recursive holons that are themselves holarchies. In order to achieve this form of cooperation, the notion of a “cooperation domain” (CD) was introduced in holonic systems, which as Fletcher et al. [81] note, “is considered a logical space in which holons communicate and operate, that provides the context where holons may locate, contact and interact with each other.” Within this framework, two types of cooperation occur among holons [81]. 1) Simple cooperation: A holon is committed to answer queries from another holon, even if the response is noncooperative. 2) Complex cooperation: Holons achieve a joint goal (e.g., agreeing upon a mutual plan of executing tasks for solving a distributed problem). The second form of cooperation is based on the concept of CDs, and requires an integration of the physical device level with the higher reasoning/deliberative level of the system. For example, Christensen [10] has proposed that the architecture of a HMS is split into two distinct levels: LLC and high-level

Fig. 3.

LLC architecture (adapted from [10]).

control (HLC). LLC refers to normal, nonholonic control and automation functions where response times range from 10 to 100 ms [10]. At this level, the IEC 61499 standard for the use of FBs in distributed automation is particularly relevant [11]. As a result, the LLC architecture shown in Fig. 3 addresses the functions associated with real-time control. Unlike the LLC, the HLC sits more firmly in the IT world of software agents and, as such, is concerned with higher level reasoning. More specifically, the HLC architecture “addresses the functions associated with the domain of interholon cooperation, including negotiation and coordination of mutually agreed tasks and mutual action to recover from operational faults” [10]. Response times in this domain are much slower (100 ms to 10 s), and rather than the control-oriented FB, the main entity is the agent as described by the FIPA architecture standard for software agent systems [79]. As noted, Christensen’s LLC architecture is closely linked with the IEC 61499 architecture. The IEC 61499 standard addresses the need for modular software that can be used for distributed industrial process control. In particular, this standard builds on the FB portion of the IEC 61131-3 standard for PLC languages [38] and extends the FB language to more adequately meet the requirements of distributed control in a format that is independent of implementation. The IEC developed the function block architecture as a new standard to model industrial process control systems using decentralization and hard real-time design philosophies. The architecture permits access to the controlled manufacturing process via an IEC 61499 system that contains an organization of devices. The four main models of the IEC 61499 standard are illustrated in Fig. 4. These models are organized in increasing levels of granularity: system model, device model, resource model, and application model [11]. Each device comprises one or more resources (i.e., processor with memory) and one or more interfaces. Interfaces enable the device to interact with either the controlled manufacturing process (via a process interface) or with other devices through a communication interface. Resources are logical entities with independent control over their operations including the scheduling



Fig. 4.

IEC 61499 system, device, resource, and application models.

of their tasks. A resource can be created, configured, etc. (as part of the system’s life cycle) via a management model. Applications (software functional units spanning one or more resources and over one or more devices) are networks of FBs and variables connected by data and event flows. Such applications aid the modeling of cooperation between the autonomous agents. Finally, FBs receive events/data from interfaces, process them by executing algorithms and produce outputs, all handled by an event control chart. When combined, Christensen’s [10] LLC and HLC architectures provide the link between the information and physical worlds that is unique to holonic systems. For example, higher level reasoning tasks such as planning, scheduling, fault monitoring, and fault recovery can be accomplished by task decomposition and virtual clustering at the HLC level. Plans can be then realized by the physical machinery at the LLC level. For example, the PROSA reference architecture [30] architecture has served as a foundation for most of the holonic control architectures at the HLC level. PROSA is fundamentally a physical decomposition of the manufacturing system into product, resource, and order holons, with the option of a staff holon. The staff holon may play the role of a mediator as in the metamorph architecture [58], [82]. A wide variety of architectures for distributed intelligent control have been proposed that are based on the MAS and holonic systems architectures described earlier. Initially, these low-level, or real-time control architectures primarily followed from the work on holonic control architectures [5], [10], [29], [81], [83] given holonic systems close link with physical device control. Among the earliest work in this area is that by Balasubramanian et al. [8] who note that conventional, centralized, scanbased control systems are not suited to the evolutionary nature of HMS since these systems must dynamically adapt to change. On this basis, they identify the following basic requirements of any real-time distributed intelligent control architecture. 1) Real-time control: It must satisfy deadlines with both hard and soft real-time constraints. 2) Distributed control: It must have bounded message communication delays (i.e., deterministic behavior), must

751

maintain correct behavior and operation (i.e., trans-node consistency). 3) Event-driven control: It must provide system-level support for dynamic, event-driven control. 4) Intelligent control: It must support autonomous and cooperative behavior at various levels (e.g., reactive behavior at lower levels, deliberative behavior at higher levels, and dynamic reconfiguration at all levels). Chiu et al. [84] proposed a “metamorphic control architecture” to address these basic requirements that combined the then emerging IEC 61499 standard and MAS design, and was organized along the dimensions of system architecture, physical architecture, and software architecture. The system architecture consists of four major components: microcomputer-based system engineering hosts, primary factory control networks, intelligent controllers, and secondary Fieldbus networks. In order to manage resources on the factory floor, the architecture also consists of logical components, i.e., clusters of intelligent controllers or “distributed intelligent controllers.” The intelligent controllers themselves are described by the physical architecture. In order to deal with simple systems as well as fault-tolerant systems (via redundancy), two possible architectures are suggested for the physical architecture: a uniprocessor architecture and a dual-processor architecture, respectively. Finally, Chiu et al.’s [84] software architecture is specified as a heterogeneous MAS that is defined at two levels. First, the operational architecture specifies the essential software components for the holonic system. This architecture is local to every processor and includes distributed control application agents, distributed real-time operating system agents, hardware-independent virtual device interface with I/O drivers, and hardware-independent virtual network interface with network drivers. Secondly, the application architecture consists of reactive, behavior-based agents that are used to define the behavior of the distributed control system. As noted previously, these simple agents are specified by the IEC 61499 standard. In order to test their metamorphic architecture, Chiu et al. [84] implemented a proof of concept system using a custom distributed controller operating system. This work focused primarily on the real-time performance of the metamorphic architecture under a variety of configurations and reconfiguration. Further details of this implementation are provided in Section III-E. Around the same time, another HMS influenced real-time distributed intelligent control architecture was developed and implemented by Schnieder Automation and DaimlerChrysler Research and Technology [85]. This system, called FactoryBroker, is a heterogeneous agent-oriented control system that was designed to be integrated with legacy systems such as PLCs and CNCs. The FactoryBroker architecture is characterized by standardized agent-oriented interfaces and agent specifications, and clear definitions of critical and noncritical transactions. Like PROSA, FactoryBroker’s agent architecture primarily follows a physical decomposition, i.e., workpiece agents, machine agents,


752


and transportation agents. Communication among the agents is based on Distributed Component Object Model (DCOM). FactoryBroker was implemented on a flexible transfer line where it was shown to be both flexible and robust. Subsequent work on the link to agent systems by Suessmann et al. [86] also showed that this architecture is very suited in accommodating heterogeneous hardware and software components and integrating existing legacy systems. The FactoryBroker work shares many of the holonic principles of the work by Chiu et al. [84]; however, the focus is at a higher level. For example, Colombo et al. [85] focus on FactoryBroker’s flexibility in terms of the number of workpiece variations and its robustness in the face of machine breakdowns. Alternatively, Chiu et al. [84] focus on their architecture’s ability to support online changes to software components and the corresponding latencies. This split between the higher level information and the lower level physical worlds is a recurring theme in this area, and as noted by Christensen [10], characteristic of holonic systems. The work on real-time distributed intelligent control architectures reflects this split: the work at the lowest level focuses on agent architecture issues such as the structure of the software components themselves and on component-level reconfiguration; work at the “information” level tends to focus on interfacing agent systems with real-time control systems to provide higher degrees of fault management and recovery. In order to bring this together, however, effective coordination is required between and within these levels. 3) Agent Coordination: The two basic and opposed forms of coordination in MAS are cooperation and competition [2]. Given the nature of industrial control, holonic- and agent-based architecture design has focused exclusively on cooperation in order to achieve desired system goals. As Valckenaers [87] notes, three main approaches have been used: 1) auction based and negotiation based, 2) artificial markets, and 3) stigmergy. The first two approaches rely on explicit interactions between agents. For example, Martinez Lastra and Colombo [26] use propose an “actor-based assembly system” (ABAS) where agents negotiate to achieve a common goal, i.e., the accomplishment of an assembly task. Similarly, artificial-market-based approaches also use agent negotiation to reach common goals; however, these systems achieve adaptive resource allocation by establishing a market-like environment where agents carry “currency” and bargain for resources. This approach tends to be more popular at the higher levels of control (e.g., planning and scheduling level); however, it has been successfully applied to task and resource allocation in distributed multirobot control [88]. Unlike the previous approaches, stigmergy agents interact indirectly. For example, Valckenaers et al. [89] use ant colony behavior as a metaphor for agent coordination. Rather than relying on direct coordination between agents, communication takes place by local modifications to the environment by agents. Despite the promising work by Valckenaer et al. [89] on indirect communication, agent communication remains a key architectural consideration in the current work on real-time distributed intelligent control systems. As Obitko and Marik [90] note, communication problems can occur at “the level of phys-

ical communication, at the level of syntax of the message, and the level of the semantics of the message.” As a result, the key issue is ensuring that the architecture supports interagent communication in systems with a wide variety of agent types. When considering the real-time systems reviewed in this paper, agents typically only need to understand their own syntax and semantics: higher level agents typically deal with integration issues such as translation between heterogeneous agent systems. This is very much in line with the layered, holonic systems approach described previously where agents or holons are organized in increasing levels of abstraction and sophistication. To support interagent communication in this type of system, Obitko and Marik [90] propose handling translation at the level of the agent platform rather than having agents perform translations themselves or relying on specialized agents to perform translations for them. This approach is particularly well suited to real-time systems since it conserves the timeliness of direct translation without its added overhead. In the next sections, we look at specific solutions to intelligent control problems for real-time distributed control systems. However, as noted previously, architectural decisions are always present to varying degrees in each of these areas. B. Reconfiguration Reconfiguration implies a change to the control software or hardware that is instigated by the user and/or by some automatic process [91]–[93]. Typically, a change would be required in the event of a system upgrade (e.g., new software components, hardware drivers, or the hardware itself) or as a contingency to some event (e.g., the failure of a piece of hardware or a systematic error in the software). In terms of Christensen’s [29] requirements, the research focus is on “disturbance handling” and “robustness.” In other words, if the industrial system is to quickly respond to change while maintaining stable system operation, automatic reconfiguration is key. In conventional PLC systems, reconfiguration involves a process of first editing the control software offline while the system is running, then committing the change to the running control program. When the change is committed, severe disruptions and instability can occur as a result of high coupling between elements of the control software and inconsistent real-time synchronization. For example, a change to an output statement can cause a chain of unanticipated events to occur throughout a ladder logic program as a result of high coupling between various rungs in the program; a change to a proportional-integralderivative (PID) FB can result in instability when process or control values are not properly synchronized. Consequently, the current approach to reconfiguration is risky: to minimize the risk, the user must have intimate knowledge of scores of pages of code. This example highlights two fundamental requirements for reconfiguration: 1) the need to address and manage software coupling issues and 2) the need to manage the transition from offline to online operation of the software changes. In order to classify the reconfiguration process, we identify approaches that avoid software coupling issues during reconfiguration as simple



reconfiguration techniques. Since the second requirement is fundamentally concerned with timing (e.g., the changed application must be properly instantiated when it is committed to run-time), we identify approaches that properly synchronize software during reconfiguration as dynamic reconfiguration techniques. Clearly, these forms of reconfiguration are increasingly sophisticated. Dynamic reconfiguration will require the techniques of simple reconfiguration as support to manage the control software, but will also require techniques to ensure that when a change is made and committed to the resource, the application’s behavior remains predictable and stable. In existing PLC systems, this is achieved through the experience of the programmer and typically involves minor changes and a contingency plan in the event that the system becomes unstable [e.g., a colleague standing close to the emergency shutdown (ESD) button]. However, as the shop floor becomes more automated, and PLC systems become more sophisticated, dynamic reconfiguration will become a growing concern. Although techniques for simple and dynamic reconfiguration are fundamental to modern automation and control systems, they alone do not enable rapid adaptive response to change. If viewed in terms of Christensen’s [29] basic requirements for modern manufacturing systems (disturbance handling, human integration, availability, flexibility, and robustness), simple reconfiguration is fundamental. Also, to provide higher reliability and maintainability (availability) and to support product and process changes (flexibility), dynamic reconfiguration is important. However, to ensure that disturbance handling and robustness in a dynamic environment, intelligent control techniques are required. In this case, the intelligent reconfiguration classification can be thought of as an upper level that exploits DAI techniques to reconfigure automatically in response to change [29]. At this level, simple and dynamic reconfiguration can be thought of as additional techniques that support the overall reconfiguration process. In this section, we begin with some background on the general approaches to reconfiguration that have served as a foundation for the current work in this area. Next, we look more specifically on a reconfiguration of PLC-based systems, then provide a summary of the outstanding research questions in this area. 1. General Approaches to Reconfiguration: Among the earliest work on dynamic reconfiguration is the work of Kramer et al. [94], [95] on dynamic change management in distributed systems. Their idea was to allow changes to be specified at a high level, then executed by “configuration management” at the task level. With this model, structural changes are specified declaratively for configuration, and then passed to the control application through “operational change transactions.” These change transactions result in component nodes being created and deleted and interconnections being changed as required (i.e., dynamic reconfiguration). Oreizy et al. [96], [97] take a similar approach with their “selfadaptive software.” However, their work focuses more on the role of architecture in self-adaptive systems and the definition of a set of “change application policies” that dictate how to make changes to the system without violating reliability, safety, and consistency.

753

This early work on dynamic reconfiguration falls under the umbrella of what Guler et al. [98] refer to as “transition management,” i.e., reducing the impact of software reconfiguration at run-time and maintaining system consistency and stability. Their work focuses on hybrid control systems (i.e., systems that contain both continuous- and discrete-state variables) and the generic aspects of transition management and is motivated by the view that these systems “. . . require dynamic reconfiguration of the software components (i.e., switching and adapting of the components at run time) . . ..” Like others in this area, they recommend a component-based software architecture to reduce software development and validation costs [99]. Also, they focus on the development of a “transition management pattern” that can be used for generic reconfiguration support for common transition management strategies. In terms of our previous classifications, Guler et al.’s choice of component-based software architectures addresses simple reconfiguration; their work on transition management addresses dynamic reconfiguration. The work of Zoitl et al. [100] shares the broader philosophical aspects of these early works. More specifically, they identify a set of key reconfiguration services that should prove to be very useful for the ongoing research toward intelligent reconfiguration: structural services, execution control services, state interaction services, query services, and FB (component) library services. Although their work is focused on the IEC 61499 model, it could be applied to other component-based models by helping to identify the services required for configuration management. In the next section, we shift our focus to reconfiguration of industrial automation and control systems, and more specifically, PLC-based systems. 2. Reconfiguration of PLC-BASED Systems: Some of the earliest work on the use of IEC 61499 for dynamic reconfiguration was by the Intelligent Systems Group (ISG) [101]–[104]. This work focused on the FB or component level and concerned runtime reconfiguration (i.e., dynamic reconfiguration) of industrial automation systems. The central notion of this work is the “hierarchical reconfiguration manager” that specifies two concurrent control paths: 1) control of the process and 2) configuration control (i.e., software concerned with managing application configuration and reconfiguration. To test the model’s support of FB-based real-time task execution and run-time (re)configurability, a real-time Java implementation was conducted using the JBed platform [105]. These tests served as proof-of-concept for dynamic reconfiguration [103] and provided a framework for the ISG for further research on intelligent reconfiguration. More specifically, a general layered architecture was proposed to support intelligent reconfiguration [106]. At the most basic level, this architecture built on the basic distinction between agents and holons [5], i.e., that a holon consists of a software part and a physical part. When considering the competing requirements of control application execution and system fault monitoring and recovery, however, the architecture builds on the safety-critical systems’ firewall concept (i.e., the separation of control application code from safety-oriented code [107]). In


754


other words, the ISG’s layered architecture [106] allows control channels (managed by a top-down task decomposition process) to be separated from safety channels (managed by a bottom-up fault monitoring and recovery process). Following from this, general architecture for intelligent reconfiguration, two methodologies for intelligent reconfiguration were proposed: 1) a soft-wiring approach and 2) a contingencies-based approach. The soft-wiring approach built on the group’s earlier work on Distributed Computing Operating System (DCOS) [104], [106]. The basic idea behind this approach to reconfiguration is to enable higher layers to use higher level reasoning to analyze the current configuration and plan for reconfiguration when required. Alternatively, the contingenciesbased approach [12] takes a simpler approach: contingencies are made for all possible changes that may occur. In other words, alternate configurations are preprogrammed based on the system designer’s understanding of the current configuration, possible faults that may occur, and possible means of recovery. More recently, parallel work on dynamic reconfiguration of real-time, embedded systems has been conducted at ACIN (Automation and Control Institute, Vienna University of Technology) and PROFACTOR as part of the µCRONS (MicroHolons for Next Generation Distributed Automation and Control) and the CEDAC (Evolution Control Environment for Distributed Automation Components) projects [108]–[113]. The two projects are coupled very tightly together, as µCRONS aims at the implementation of a deterministic and reconfigurable run-time environment and CEDAC provides an engineering methodology and environment for modeling changes to the automation and control system in an appropriate way. As with the ISG work described previously, µCRONS and CEDAC focus primarily on the IEC 61499 for reconfiguration. In this case, the IEC 61499 device manager service interface FB (DEV_MGR) is the key to the configuration and reconfiguration management. It serves as the interface between other devices (via the devices network interface) and the engineering environment (i.e., services such as CREATE, START, STOP, etc.). This paper builds on the notion of hierarchical reconfiguration management from the ISG [101], [104], where each FB is considered an “automation component” with an execution flow path and a configuration flow path. The objective is to develop middleware for flexible, modular mechatronic components [114], which support reconfiguration in real-time (so called µCRONS) [115]. In this sense, “µCRONS” can be thought of as real-time mechatronic building blocks that are online-reconfigurable. The main intention of this approach is to encapsulate reconfiguration commands into the language constructs of the IEC 61499, as FBs. This is especially the case with the CEDAC engineering methodology, which is strongly based on the fact that the reconfiguration process can be described as an IEC 61499 application. Therefore, the same constructs are used for control modeling and reconfiguration modeling, thus overcoming the extraordinary complexity introduced. More specifically, reconfiguration applications are modeled to describe simple reconfiguration processes [111], these can be put together in ar-

bitrary manner as evolution applications to model changes in large systems on a very top-level point of view [112]. µCRONS and CEDAC are currently being implemented and evaluated with different platforms and use cases at the testbed at the Odo Struger Laboratory at the Vienna University of Technology [106]. This testbed consists of a distributed network of IEC 61499 devices based on a variety of small, embedded controllers suitable for industrial control. Rather than focusing on a specific solution to the problem of reconfiguration like the ISG and ACIN projects, Vyatkin and Martinez Lastra [116] focused on the more general problem of engineering environments for real-time distributed intelligent control system development that will support control application configuration and reconfiguration. More specifically, they investigate ways to bridge the work on object-oriented engineering methodologies (e.g., UML) with IEC 61499-based methodologies. This approach is realized by Thramboulidis et al. [117] with their RT-UML-based CORFU ESS and Archimedes system platform [118]–[122]. CORFU exploits similarities between the IEC 61499 FB model and RT-UML capsules, thus allowing developers to use commercial CASE tools to automatically generate control application code. This not only increases the portability of the models, but also eases the process of system configuration, and ultimately, system reconfiguration. Similarly, the total life cycle Web-integrated control (TORERO) project takes a total life cycle view of distributed control application development [123]–[128]. More specifically, a TORERO integrated development environment (TIDE) is provided for use “from the engineering phase and managing the system during run-time, to the maintenance/reconfiguration phase and termination” [124]. With this approach, FBs are specified as “plug-and-play” (PnP) Web-based field devices, or TORERO devices (TDs), that are used to support flexible system configuration and reconfiguration. Rockwell Automation has taken a different approach to intelligent reconfiguration with their autonomous cooperative system (ACS) [129]–[133]. Rather than attempting component-level reconfiguration like the previous projects, they have separated the low-level, real-time control portion of the system from the high-level, “intelligent” control portion of the system: reconfiguration is then managed and performed exclusively at the high level. The ACS architecture comprises an agent infrastructure that is built on the top of an IEC 61131-3 PLC firmware that supports real-time control. The advantage of this approach is that it truly integrates legacy control systems (providing greater familiarity for operators) while managing change. However, given the limitations of the IEC 61131-3 model with respect to component-level reconfiguration, it focuses on a different class of reconfiguration problems than those addressed by the previous projects. The reconfiguration approach discussed so far focuses on component-level reconfiguration, and as such, attempt to provide the basic services identified by Zoitl et al. [100], i.e., structural, execution control, state interaction, query, and component library. The work by ISG and ACIN primarily addresses the basic services required to add, remove, and/or replace software



components (i.e., FBs) on the fly (i.e., structural, execution control, state interaction services). However, later work by ACIN on the CEDAC engineering methodology builds on these basic services with the introduction of query services and component library services. Also, parallel work by ISG on architectures for reconfiguration focuses on additional services required for safety (e.g., fault monitoring and recovery). Finally, the work on CORFU ESS and TORERO adds further to Zoitle et al.’s services with higher level engineering environment services to support user interfaces and design methodologies. More specifically, the Rockwell Automation work focuses on complex redundancy problems such as their chill water system (CWS) application [84] where agents are assigned to physical equipment and systems. As a result, rather than attempting component-level reconfiguration like the previous projects, reconfiguration is at the physical equipment or system level. For example, when a part of the system fails (e.g., a valve jams or a cooler goes down), the agent system adapts to the change by reassigning resources without the need to stop and/or reinitialize the system. Despite the slightly different focus of the ACS project, it is arguably closest to achieving intelligent reconfiguration or selfadaptive software. In particular, the CWS application demonstrates that appropriately deployed agent technology can result in rapid and adaptive response to change when applied to complex redundancy problems. C. Safety Of the primary needs for next-generation manufacturing systems [29] noted in Section II, “disturbance handling,” “availability,” and “robustness” are the most tightly linked to the notion of “safety.” In other words, if a system is not to pose unnecessary risk to personnel and equipment, it must be reliable, maintainable, and capable of managing disruptions. This has become particularly relevant in recent years given the proliferation of ubiquitous computing, smart sensors, and certified embedded computers on aircraft, medical equipment, and other high-integrity devices [107]. Although the focus of this section is on “safety,” we can think of it more generally as being concerned with how the complexity of the new distributed systems discussed in this paper is managed. Given the nature of these systems, the real difficulty lies in the interaction and coupling between components. The problem is, we are designing systems with such complex interactions that their behavior “cannot be thoroughly planned, understood, anticipated, or guarded against” [107]. This becomes particularly challenging with software systems since there is almost no limit to their complexity: this is exacerbated by the fact that they can be reconfigured at any time. When agent technology is applied to physical devices, system design and analysis are of utmost concern given real-time and safety issues at this level of control. For example, as devices such as controllers, sensors, and actuators become “smarter,” safety functions that were previously performed by mechanical or electrical interlocks are assumed by computer software that may reside in a single device or might be distributed across

755

multiple devices. Failures in these systems can have a significant impact on a company’s bottom line (e.g., profit reduction due to temporary loss of equipment resulting in production downtime), and more importantly, on the lives of people. In this section, we begin with some background on safetycritical systems then focus our attention on the research on the design of safe real-time distributed intelligent control software. More specifically, we first look at how the software models discussed previously meet the requirements of safety then we focus on the specific area of the verification of these systems. 1. Safety-Critical Systems: Industrial automation and control systems clearly fall in the category of safety-critical systems since they should not incur too much risk to persons or equipment. Given the criticality of these systems, very specific requirements have been identified for all aspects of their operation. For example, Storey [134] identifies the following key requirements for safety-critical or “high-integrity” systems: reliability, availability, fail-safe operation, system integrity, data integrity, system recovery, maintainability, and dependability. When we compare industrial computers (e.g., PLCs) to office PCs, the need for reliability and availability becomes obvious. For example, PLCs must operate continuously in harsh industrial environments (i.e., they must be reliable) while maintaining a very high probability of functioning correctly at any given time (i.e., availability). Although one could argue that the reliability and availability of commercial PCs is improving, their suitability to safety-critical applications rapidly diminishes at this point. It is of utmost importance that safety-critical systems do not move into a state that can cause harm. As a result, they must be capable of detecting faults and informing human operators when they occur (i.e., system integrity). Similarly, they should be capable of detecting software errors and preventing damage to their internal data (i.e., data integrity). Regardless of the time and effort that is put into each of these requirements, faults still occur. As a result, it is important that a safety-critical system is capable of restarting itself (i.e., system recovery), and if not, at least moving into a state that does not cause harm to personnel or equipment (i.e., fail-safe operation). It is also important that the system can be maintained, and ideally, is designed such that maintenance-induced faults are minimized. Finally, if a system is to be deemed suitable for operation in a safety-critical environment, it is imperative that one can place their reliance on it (i.e., it is dependable). The question that follows at this point is, do the systems described in this paper meet these requirements? Arguably, PLCs have met the requirements of reliability, availability, maintainability, and (with proper configuration) fail-safe operation for years as a result of their hardware and firmware design. However, meeting these requirements is not necessarily synonymous with safety. For example, a system that functions correctly (i.e., is reliable and available) is not necessarily safe: this is particularly evident when “correct” operation (to the software) means doing something that the programmer did not expect. To illustrate this problem further, we can look at the problem of fault monitoring and recovery, which is at the heart of the remaining requirements for integrity and dependability.


756


The purpose of monitoring is to ensure that the control system performs as intended. In other words, this involves ensuring that no unidentified, or latent, faults occur. Fault monitoring is basically the process of watching for failures and errors that may occur when the system is running or that are present (but possibly undetected) in the system itself. Before going any further, we should look at the terms “failures” and “errors” more closely. Failures relate to events that occur at specific times. For example, breakage or excessive wear of mechanical components or overloading of electrical components often manifests failures. Since software does not “break” or “wear” (though, arguably, data may “wear” by becoming obsolete), the notion of “component failures” has little relevance for control software. Errors, however, are a different matter, i.e., an error is an inherent characteristic of the system. As a result, this concept is more relevant to software systems since errors are often manifested in program “bugs.” As a result, research in the area of safe real-time distributed intelligent control systems has focused primarily on the prevention systematic faults, or more specifically, software design. 2. Safe Software: Although there has been a considerable amount of work in the area of fault-tolerant design of industrial control systems [135], [136], fault-tolerant software, and particularly, fault-tolerant distributed software is a relatively new area of research. In this section, we start with the designer’s first choice, i.e., the choice of a programming language for system development. Given that the majority of the work in the area of real-time distributed intelligent control has focused on the use of IEC 61131-3 and IEC 61499, we place our survey in the context of these programming methodologies. Next, we look at how this software can be used to manage systematic errors in real-time distributed systems, i.e., the problem of fault monitoring and recovery. Given the increasing reliance on computer-based systems in high-integrity applications (e.g., medical monitoring systems, aviation systems, etc.), it is not surprising that there has been increasing interest in safety-critical software and computer systems. For example, current work in this area has focused on general approaches and international standards for the design of safety-critical computer systems [134], [137], safetycritical software development methodologies [138], [139], and the choice of programming languages for safety-critical systems [140]. For the purposes of this paper, the latter area is of particular relevance. For example, Cullyer and Wickmann [140] proposed a minimum set of question that should be considered when choosing a programming language for safety-critical applications. These questions focus on issues such as ease of programming, the ability to be analyzed (e.g., program semantics, operational arithmetic), and in particular, on issues relating to integrity (e.g., if wild jumps, memory exhaustion, misuse of variables, and/or overwrites are possible). Although these basic criteria facilitate the benchmarking of programming languages for safety-critical applications, some of the complex issues associated with guaranteeing real-time tasks, and in particular, distributed real-time communication and synchronization have not been covered in this benchmark.

Cullyer and Wickmann [140] made a comparison between common embedded systems programming languages of the time: assembly-level languages, C, CORAL 66, Pascal, Modula2, and Ada. Not surprisingly, Ada [141] came out on top by their criteria. Interestingly however, C (and its close relative C++) faired quite poorly in the comparison. This is of particular interest considering the continued use of C and C++ as the high-level languages of choice for many intelligent systems applications. Meanwhile, other investigations into the use of languages like Java or Prolog, as well as using modern AI frameworks, as suitable paradigms for building intelligent software do not take the key aspect of integrating with real-time operations into account as a basis for recommending how safety-critical should be written [142]. More recently, work has been reported on the suitability of IEC 61131-3 in the safety-critical domain; however, none of these provides the programmer with a clear indication of how these approaches compare with widely accepted safety-critical languages such as Ada. For example, Toon [143] places IEC 61131-3 in the context of the international safety-critical systems standard IEC 61508 [137], and comments on how some of the requirements of this standard are addressed by the IEC 61131-3 languages. Also, Lewis [144] investigates the usefulness of graphical languages such as IEC 61131-3 FBDs in safety-critical applications. For the most part, the IEC 61131-3 languages fair quite well for safety-critical systems applications. For example, Lewis [144] notes that ST has a formally defined syntax that is expressed as production rules and is amenable to static code analysis. In other words, ST can be analyzed offline for correctness. On this basis, it should be possible to translate any of the IEC 61131-3 graphical languages (LD, FB, SFC) into ST. For example, Lewis [144] showed how a program specified in an IEC 61131-3 language (in this case, LD) can be translated to a static code analysis friendly form (ST). Also, ST control flow constructs appear to be sound; however, as in Pascal, there is a potential trap with the CASE statement that may lead to a jump to an arbitrary location. Another potential problem is that of partial compliance: IEC 61131-3 implementations vary among PLC manufacturers. For example, commercial PLCs vary significantly in their behavior and architecture, resulting in various features of the standard being left as optional [144]. However, the PLCopen trade association is currently addressing the issue of software portability, and with the cooperation of PLC manufacturers, this issue should be eventually resolved. Another drawback of the IEC 61131-3 standard is that the handling of exceptions such as overflow and underflow is not defined [149]. Once again, this aspect of the PLC’s operation is dependent on the implementation. As Brennan et al. [27] note, IEC 61499 FBDs provide two important features that lend themselves to safety-critical implementation. First, the IEC 61499 FB provides an explicit representation of its state behavior with an execution control chart (ECC). As a result, it is possible to represent the overall state behavior of the FB application. Work is already being done by Vyatkin and Hanisch [145]–[148] and others on the use of IEC 61499 for the formal verification of embedded control systems



that takes advantage of this explicit state-based representation (this will be discussed further in the next section). A second important feature of IEC 61499 for safety-critical systems is its clearly defined textual syntax. Although IEC 61499 FB applications are typically represented in a graphical format, the standard defines a textual syntax for describing applications unambiguously. Also, the standard also allows applications to be described in XML [149]. The advantage of this textual representation is basically the same as that attributed to ST by Lewis [144], i.e., an unambiguous textual representation can be used as an input to static code analysis applications. However, the use of XML has the potential to strengthen this argument even more. Given the wide acceptance of XML as a rich data exchange format, it has the potential to be used as input for a wide variety of static code analysis tools in the future. The power and flexibility of IEC 61499 has made it the focus of device-level intelligent systems research; however, this also results in negative safety-critical characteristics. In particular, IEC 61499’s distributed programming model makes deterministic behavior very difficult. Also, although its flexible language support allows intelligent applications to be developed, it has the potential to introduce unsafe language constructs (e.g., algorithms implemented in C++). This is particularly relevant given the recent work on IEC 61499 tools and techniques: as is discussed in Section III-D, current research tools rely heavily on Java and C++, which do not guarantee safe operation. However, emerging industrial IEC 61499 software (e.g., ISaGRAF v. 5.0 [150]) limit the choice of programming languages to the IEC 61131-3 languages in recognition of the importance of safe software practices. As noted previously, systematic errors can be, and almost always are, present in control software. Also, random failures can, and typically do, occur in the controlled system. Given these eventualities, the control system must be capable of recovering from the resulting faults. To achieve a safe system, typically, two general concepts are used [138]. The first approach involves separating the fault monitoring and recovery code (i.e., the “safety channels”) from the control application code. This decomposition technique is typically referred to as the “firewall concept” [138], since one may think of the safety channels as providing a firewall for the control code. The second approach involves applying redundancy in the control system. This is a very common means of fault recovery and can be achieved in two basic ways: homogeneous redundancy and diverse redundancy. Homogeneous redundancy is the most basic form of redundancy, and involves “clones” or exact replicas of code to be used as backup code in the case of a failure. The main disadvantage with this technique is that it only protects against random failures. For example, if a piece of hardware fails, a copy of the code that was running on the failed device can be moved to another device to allow the system to continue operating. However, if the failure was caused by a systematic error in the software (e.g., a command that causes the process to go into a deadlock state), this technique will not work, i.e., the same failure will occur on the new device. To overcome this problem and provide protection against random and systematic failures, diverse redundancy

757

can be used. With this approach, the redundant code is implemented in a different way. For example, the redundant code for a PID controller could be implemented using fuzzy logic. As discussed previously, Brennan and Norrie [78] use the “firewall concept” in a layered architecture for control application development, reconfiguration, and fault recovery. In other words, they suggest that control channels (managed by a topdown task-decomposition process) to be separated from safety channels (managed by a bottom-up fault monitoring and recovery process). In this way, the safety code is not mixed with the application code, allowing for cleaner development and less chance of unexpected changes to the behavior of the safety code. The research discussed so far assumes that, despite the designer’s efforts, latent faults in the form of systematic errors will always be present in our industrial automation and control systems. This is a fair assumption since it is highly improbable that any computer software can be completely bug free. However, this should not prevent designers from attempting to eliminate as many of these errors as possible. In the next section, we look at the work in this area. 3. Verification and Validation: In simplest terms, verification and validation are concerned with the prevention of systematic errors in control software. However, as noted by Storey [134], there is an important distinction between the terms. Verification focuses on the control software specification, and more specifically on ensuring that the software meets its specification (i.e., “specification” refers to the high-level description of what the control application must achieve such as “monitor the position of a robot arm”). A specification does not ensure safety though. For example, a poorly written or ambiguous specification could lead to software that behaves in unsafe ways (e.g., moving equipment into states that were not anticipated in the specification). “Validation” gets us closer to system safety as it is concerned with determining that a system is appropriate for its purpose. Unfortunately, this is often a difficult and impractical goal as it is often impossible to determine if a system is completely validated. Instead, we typically think of validation in terms of the degree of confidence that we have in the validity of the system given the test that were carried out on the software. As a result, one should view the work in this area as focusing on verification despite the use of the term “validation” in much of the literature. Of course, these verification techniques can be used as tools for system validation; however, the designer should be careful to realize that this is a higher level process with typical engineering tradeoffs such as quality (of the validation) versus time (spent validating). In the area of real-time distributed intelligent control systems, verification and validation falls into two general areas: formal validation and simulation. In this section, we begin with an overview of the work on formal validation, then look at the recent research into simulation of real-time distributed control systems. There is extensive literature on formal modeling and validation of automation systems that has served as a basis for the work on real-time distributed control system validation. Given


758


the focus of this paper, we will focus on the latter area in this section; however, [151] can be referenced for a survey of formal modeling and verification. The early work in this area focused on the verification of IEC 61131-3 systems using a compositional approach to verification [152]. To manage the verification process, they use a theoremprover tool and split the process into two parts: 1) verification of library components and 2) verification of applications. Voelker and Kraemer’s [152] approach represents IEC 61131-3 FBs by higher order logic (HOC); however, it supports the verification of programs written in FBD, SFC, and ST. Vyatkin and Hanisch [145]–[148] have led the work on formal modeling and verification of IEC 61499 FB applications. Their approach is based on the net condition event systems (NCES) formalism developed by Hanisch and Rausch [153]. This approach, which has close links to the DES theory [47] discussed previously, is an extension to Petri nets that supports modularity. Vyatkin and Hanisch [145]–[148] use the NCES formalism to verify models with a structure very similar to the original IEC 61499 source. The work on the NCES formalism was further extended by Vyatkin et al. [154], [155] and Lobov et al. [156] into an integrated framework of tools for system design and verification. With their approach, a wide range of PLC programming languages could be validated. Similar work on the use of timed automata to model IEC 61499 basic FBs was performed by Stanica and Guedguen [157]. Their approach uses a freeware tool from Aalborg University called UPPAAL [158] for model checking. Although their work focuses solely on individual FB verification, it has the potential to be extended to applications using a network of timed automata. In order to help system designers with the validation process, various frameworks for application development and verification have been proposed recently. For example, Bonfe and Fantuzzi [159] have proposed a framework that supports an engineering methodology for system design, simulation, and implementation. Vyatkin and Martinez Lastra [116] and Vyatkin and Peniche [160] have extended this approach with the use of design patterns for “intelligent mechatronic actors.” This idea is taken one step further with the validatable architecture for industrial automation systems (VAIAS) framework [155]. The general idea here is to combine system engineering and design with an architecture that supports “inherent validatability” (i.e., formal analysis methods through the architecture). The research described so far in this section focuses on testing control software using formal methods to determine whether or not it will perform as expected. However, when one takes a higher level view and considers the emergent behavior that results from the interaction of software components, this form of validation, though needed, is not sufficient. Given the complex behavior that can emerge from even a simple distributed intelligent control system, it is necessary to test the overall system behavior to ensure that it works properly. Since it is often infeasible to test these systems on the physical system (i.e., it is often too dangerous, expensive, and/or timely), simulation is typically used for this form of verification.

In the real-time control domain, simulation has involved linking a commercial simulation tool to the distributed control system via a network. The idea is to be able to test the distributed control system with simulated devices, then replace the simulated devices with physical devices one the system is validated. Brennan and coworkers [161], [162] developed a hybrid discrete event simulation approach for validating real-time distributed intelligent control systems. Their approach uses an interface between the simulation software and the physical devices to the real-time aspects of the system to be tested. This is strictly an experimental system that uses tiny Internet interface (TINI) boards [163] for real-time control, linked to Arena Real Time [164] discrete event simulation software via Java socket-based communication. Maturana et al. [19] have developed a more commercially oriented system for agent systems development and validation that is based on Rockwell Automation SoftLogix controllers and Matlab continuous simulation. Their system is divided into a configurator and a synchronizer that allow the user to specify the distributed system configuration and run the simulations, respectively. This approach has the advantage of allowing the developer to run the entire system in a software environment (with soft controllers and simulation) before downloading the code to physical controllers in the physical environment. In a similar vein, Rockwell Automation is also working on linking the MAST agent simulation tool [165] to real-time systems such as the µCRONS/CEDAC at the Odo Struger Laboratory at the Vienna University of Technology [109]. D. Tools and Techniques The main tools and techniques for the development of realtime distributed intelligent control systems are primarily from the area of agent systems and PLC software. The literature devoted to agent systems tools and techniques is quite large (e.g., [2] serves as a good starting point) and will not be focused on in this section. However, the reader is referred to [166] for an excellent survey of Java agent platforms. In this section, we focus on PLC software tools and techniques for these new distributed control systems, and in particular, IEC 61499-based tools and techniques. Given the focus on the IEC 61499 standard for real-time distributed intelligent control, it is not surprising that much of the effort on the development of tools and techniques has focused on IEC 61499 tools. Despite a strong interest in IEC 61499 from the research community, however, there has been a lack of software tools for industrial automation and control developers. In particular, extant software tools have been focused on the research community for simulation and testing, and are arguably, not suitable for industrial applications. Presently, an overall design methodology for real-time distributed intelligent control is not available, and as a result, is the subject of ongoing research. However, various tools have been proposed to assist developers in most phases of the engineering life cycle such as system configuration, application programming, verification, and run-time execution.



The most widely used research tool for IEC 61499 application development and testing is Function Block Development Kit (FBDK), which was originally developed by Rockwell Automation and is now managed by Holoboc, Inc. [167]. This is a Javabased software development tool that is freely distributed for research and education purposes. The tool is primarily intended to allow users to develop and simulate IEC 61499 applications on a single platform (e.g., PC, Linux); however, there is also a run-time version available (FBRT) that allows users to execute their IEC 61499 applications on embedded Java controllers such as the TINI [163], Systronix aJile Euroboard [168], and the Simple Network Application Platform (SNAP) [168] platforms. Work is currently underway on an open-source Java-based integrated development environment (IDE) for the development of IEC 61499-compliant library elements for industrial automation and control. This project is currently managed through SourceForge as the O3NEIDA Workbench project [169]. The first testbed for studying the feasibility of IEC 61499, and in particular its intervendor feasibility, was developed in a joint venture between Rockwell Automation [170], Profactor GmbH [115], and Softing AG [171]. This testbed was demonstrated at the International HMS Symposium in Kitakyushu City, Japan, on October 19–20, 2000 [172]. Also, as part of the HMS Consortium, Yamatake Electric created a LEGO-based testbed [173] that used to test the FBRT [167]. Parallel work by Rumpl et al. [174] investigated the suitability of various Javabased embedded run-time platforms to support FBDK-based IEC 61499 applications. In addition to FBDK, there have been various other researchoriented IEC 61499 software development environments. For example, as noted previously, Thramboulidis et al. [117] have developed the CORFU ESS and Archimedes System Platform that extends the IEC 61499 model to software design through the use of the Unified Modeling Language (UML). This approach goes beyond the existing IEC 61499 implementations by the user to simultaneously consider the engineering process for all constituent parts (i.e., mechatronic system, application, resources, and mechanical process) [175]. The TORERO project takes a total life cycle view of distributed control application development [124], [125]. More specifically, a TIDE is provided for use “from the engineering phase and managing the system during run-time, to the maintenance/reconfiguration phase and termination” [124]. With this approach, FBs are specified as PnP Web-based field devices, or TDs, that are used to support flexible system configuration and maintenance. Other IEC 61499 implementations have tended to be very specific to individual research projects. For example, Wang et al. [176] developed a simple FB editor called ICS Developer for use with a distributed real-time operating system and Brennan et al. [102] developed a Java-based tool for dynamic reconfiguration experimentation. Also, recent non-FBDK environments have focused on integrating FBDK into a engineering framework such as VAIAS [155]. The first commercial software environment for IEC 61499, introduced recently by ICS Triplex [150], is ISaGRAF v. 5.0. This tool extends earlier versions of ISaGRAF to support the design

759

TABLE I RESEARCH THEMES IN REAL-TIME DISTRIBUTED INTELLIGENT CONTROL (ARCHITECTURE)

of automation controllers and devices that meet the IEC 61131-3 and IEC 61499 standards. ISaGRAF allows the designer to use the full suite of IEC 61131-3 languages to specify the behavior of individual FBs. Once the application is developed within ISaGRAF 5.0, it can then be compiled into target independent code (TIC) for execution on the target platform [150]. The philosophy behind TIC is to provide the user with target hardware flexibility. More specifically, the TIC technology enables the control engine to be implemented on any hardware platform (embedded, Motorola, Intel, ARM, etc.) and on any operating system (Win XP, CE, 2000, Linux, VxWorks, QNX, etc.). TIC can also be used to build automation devices such as tiny controllers, RTUs, PLCs, DCS, and safety systems. In fact, in using ISaGRAF 5.0, any field device manufacturer will have the ability to turn their equipment into an IEC 61499 product. For example, intelligent flow meters can act as a regulator and control a valve while being part of an integrated distributed control system. IV. SUMMARY AND OUTLOOK As this paper has attempted to demonstrate, research on the development of real-time distributed intelligent control systems has progressed rapidly in recent years. Although considerable progress has been made both in hardware and in software technology, work is still required to realize truly “intelligent” systems at this level of control. In this section, we begin with a brief summary of the work in this area then provide some suggestions for future research. A. Summary At the beginning of this paper, we noted that the primary needs of next-generation industrial systems identified by Christensen [29] provided the context for the work on real-time distributed intelligent control systems. In this section, we look at how the research in this area has addressed the need for disturbance handling, human integration, availability, flexibility, and robustness. A summary of this research is provided in Tables I–IV. Disturbance handling requires better and faster recognition of and response to disturbances. Although much of the research described previously focuses broadly on this problem, the work on safety, and in particular fault monitoring and recovery, comes the closest to addressing this problem directly. The early work in this area by the ISG [106] focused primarily on an architecture for fault monitoring and recovery and


760


TABLE II RESEARCH THEMES IN REAL-TIME DISTRIBUTED INTELLIGENT CONTROL (RECONFIGURATION)

TABLE III RESEARCH THEMES IN REAL-TIME DISTRIBUTED INTELLIGENT CONTROL (SAFETY)

TABLE IV RESEARCH THEMES IN REAL-TIME DISTRIBUTED INTELLIGENT CONTROL (TOOLS AND TECHNIQUES)

an experimental prototype implementation [8]. Although subsequent work has not addressed the issue of safety directly, the architectural work on FactoryBroker [85] and Rockwell’s ACS [129] have provided industrial implementations of systems with the goal of disturbance handling. The work on reconfiguration summarized in Table II is also closely linked to the need for disturbance handling. In particular, dynamic reconfiguration methodologies have the aim of supporting higher level fault recovery techniques, whether by human intervention or by automatic, intelligent software. Correspondingly, intelligent reconfiguration or self-adaptive software goes one step further with the aim of achieving automatic fault recovery at the device level. It should be noted, however, that this does not discount intervention from higher levels of control. For example, in some cases (e.g., overall machine failure), device-level recovery may be limited to ensuring that the device is moved to a fail-safe state: system recovery would then rely on higher level support from the planning and scheduling system (to reroute parts to other machines). Christensen’s [29] definition of human integration involves better and more extensive use of human intelligence in the distributed control system. Although none of the research described in Section III directly addresses this issue, human integration is an important requirement in all of these systems. For example, the work on the HMS architecture [10] does reference human interfaces to the system. Also, all of the work on tools and techniques listed in Table IV is focused on varying degrees on making the software development process more seamless to users. For more details on human–machine interactions in cooperative problem solving, however, the reader is referred to [177]. Availability is concerned with reliability and maintainability, and as a result, relates to the work on safety and reconfiguration, respectively. In particular, the work on safe programming languages [27], [143], [144] focuses on the characteristics of the main programming languages for real-time distributed intelligent control that make them reliable. Also, the work on verification [152], [154], [155], [157] focuses on ensuring that the applications developed from these languages are reliable. Although the research on reconfiguration listed in Table II goes beyond problems of maintainability, it is key to this need. For example, to be maintainable, techniques are required to help the user make changes to the software system without introducing new errors. Arguably, all of the projects listed in Tables I–IV focus to some degree on flexibility, or the system’s ability to support continuously changing product designs, product mixes, and small lot sizes. This, however, is a higher level issue (e.g., planning and scheduling) that we can think of real-time distributed intelligent control playing a supporting role for. For example, to support changes to the process (e.g., addition and/or removal of resources), appropriate tools and techniques are required to reconfigure the software/hardware and ensure that it is done safely. The final requirement, robustness, is closely linked to reconfiguration, and especially, intelligent reconfiguration. In order to maintain system operability in the face of large and small malfunctions, the system should ideally be capable of adapting to change. This is still an open area for component-level



reconfiguration (i.e., self-adaptive PLC software); however, the ACS project [129] achieves intelligent reconfiguration at the system level for complex redundancy problems such as the Chilled Water System project [132]. In this case, rather than reconfiguring the control software itself, higher level software agents are used to reconfigure the system by, for example, replacing failed resources with alternative resources to allow the system to continue to operate. B. Research Outlook In the previous sections, a number of open issues and research challenges were identified around the main themes of architecture, reconfiguration, safety, and tools and techniques. Based on our survey of the work in these areas, we identify the following broad areas that need to be addressed in order to move the work on real-time distributed intelligent control forward to wider-spread adoption. Software Architecture: As noted previously, the ACS project by Rockwell Automation [129] shows that intelligent control can be achieved by a layered architecture that separates the real-time system (i.e., IEC 61131-3 software) from the intelligent system (i.e., agent software). This appears to be the most logical system architecture approach at this level of control. However, given the recent advances in IEC 61499 research, a promising future direction for architecture research is the integration of IEC 61499 “agents” at the real-time level. As noted previously, IEC 61499 offers a number of advantages at the component level over extant PLC software: most notably in the area of reconfiguration. The integration of IEC 61499 intelligent mechatronic components/actors [114], [155] with system-level intelligent software should help to achieve intelligent control at all levels of the industrial control system. Reconfiguration: The IEC 61131-3 standard for programming languages opened the door for simple reconfiguration by specifying software that could be divided into understandable modules with well-documented interfaces. This has allowed work on dynamic reconfiguration to move forward, especially by taking advantage of the IEC 61499 models such as the work on µCRONS/CDEAC. However, intelligent reconfiguration at the component level is still an open issue. As noted previously, this work is closely linked with ongoing work on software architectures, and in particular, the notion of a layered architecture to support intelligent fault monitoring and recovery. However, at the component level, further work is required on agent architectures: in other words, work in this area will need to focus on how intelligent agents can be implemented in a real-time and resource constrained environment. Current work on the development of automation objects [44]–[46] is a promising start to the realization of device level, physical agents that will ultimately be required for intelligent reconfiguration. Despite the recent advances in the areas of dynamic and intelligent reconfiguration, there is still the problem of industry acceptance of these techniques. The automation and control industry is characteristically conservative [25], and as noted in Section II, slow to adopt new software techniques given the success of LD and other IEC 61131-3 programming languages. For

761

the work reconfiguration to eventually gain wide acceptance, it will be important to move this work from the laboratory to the shop floor. In particular, users will benefit from reconfiguration services that will make the process more automatic and seamless such as those identified by Zoitl et al. [40]. Additionally, reconfiguration services could include a reconfiguration wizard application that can lead the user through the process. Also, background reconfiguration services will be required to help with the details (e.g., parameter initialization, interconnections) and to ensure that all of the checks have been made (e.g., whether the reconfiguration is safe, possible, etc.). Ideally, reconfiguration should appear like many “drag-and-drop” applications in current office computing applications where all of the details are handled by background services. Safety: Although there is a growing body of literature on safe real-time hardware and software [134], [138], [139], the work on real-time distributed intelligent control and safety is in its very early stages. Programming languages such as those defined by IEC 61131-3 and IEC 61499 appear to be widely accepted by the research community; however, the work on evaluating these languages has only scratched the surface. Thorough analysis of the IEC languages as well as popular object-oriented languages (e.g., C++ and Java) along the lines of the work by Cullyer and Wickmann [140] is required. Verification and Validation: As illustrated in Section III, research in this area is quite well developed. However, the techniques that have come out of this research need to become more accessible to industrial practitioners. This is particularly important as industrial software systems grow in size and complexity and traditional verification techniques become more difficult and costly (e.g., in terms of engineering time). As noted by Vyatkin et al. [154], verification and validation needs to be integrated into engineering environments as part of the overall design process. This will require further work on tools and techniques as well as training on verification and validation methodologies and their limitations. Simulation: As with formal verification and validation, simulation needs to be integrated into the overall design process [19]. As a result, robust commercial tools are required for agent-based simulation as well as training on the proper use and interpretation of simulation software. REFERENCES [1] H. V. D. Parunak, Autonomous Agent Architectures: A Non-Technical Introduction. Colombo, Sri Lanka: Ind. Technol. Inst., 1993. [2] G. Weiss, Multi-Agent Systems. Cambridge, MA: MIT Press, 1999. [3] AgentLink. (2006). [Online]. Available: http://www.agentlink.org/ [4] W. Shen and D. H. Norrie, “Agent-based systems for intelligent manufacturing: A state-of-the-art survey,” Knowl. Inf. Syst., vol. 1, pp. 129–156, 1999. [5] P. Valckenaers, H. Van Brussel, L. Bongaerts, and J. Wyns, “Holonic manufacturing systems,” Integr. Computer-Aided Eng., vol. 4, pp. 191– 201, 1997. [6] D. C. McFarlane and S. Bussmann, “Developments in holonic production planning and control,” Prod. Plan. Control, vol. 11, pp. 522–536, 2000. [7] W. Shen, L. Wang, and Q. Hao, “Agent-based distributed manufacturing process planning and scheduling: A state-of-the-art survey,” IEEE Trans. Syst., Man, Cybern. C, Appl. Rev., vol. 36, no. 4, pp. 563–577, Jul. 2006. [8] S. Balasubramanian, R. W. Brennan, and D. H. Norrie, “An architecture for metamorphic control of holonic manufacturing systems,” Comput. Ind., vol. 46, pp. 13–31, 2001.


762


[9] J. H. Christensen, “IEC 61499 architecture, engineering methodologies and software tools,” in Knowledge and Technology Integration in Production and Services. Balancing Knowledge and Technology in Product and Service Life Cycle. IFIP TC5/WG5.3. Proc. 5th IEEE/IFIP Int. Conf. Inf. Technol. Balanced Autom. Syst. Manuf. Services (BASYS 2002), Sep. 25–27, pp. 221–228 [10] J. H. Christensen, “HMS/FB architecture and its implementation,” in Agent-Based Manufacturing: Advances in the Holonic Approach, S. M. Deen, Ed. Berlin, Germany: Springer-Verlag, 2003, pp. 53–88. [11] International Electrotechnical Commission, “Function blocks—Part 1: Architecture,” International Electrotechnical Commission, Geneva, Switzerland, Tech. Rep. IEC 61499-1, 2005. [12] S. Olsen, J. Wang, A. Ramirez Serrano, and R. W. Brennan, “Contingencies-based reconfiguration of distributed factory automation,” in Proc. 14th Int. Conf. Flexible Autom. Intell. Manuf., 2005, pp. 379–390. [13] T. Strasser, K. Fessl, A. Hämmerle, and M. Ankerl, “Rapid reconfiguration of machine-tools for holonic manufacturing systems,” presented at the 16th IFAC World Congr., Prague, Czech Republic, 2005. [14] J. Scarlett, R. W. Brennan, and D. H. Norrie, “A proposed high-integrity communication protocol for real-time control,” in Proc. IMS Int. Forum Global Challenges Manuf., 2004, pp. 759–766. [15] H.-M. Hanisch, A. Lobov, J. L. Martinez Lastra, R. Tuokko, and V. Vyatkin, “Formal validation of intelligent-automated production systems: Towards industrial applications,” Int. J. Manuf. Technol. Manage., vol. 8, pp. 75–106, 2006. [16] V. Marik and D. McFarlane, “Industrial adoption of agent-based technologies,” IEEE Intell. Syst., vol. 20, no. 1, pp. 27–35, Jan./Feb. 2005. [17] S. Bussmann and J. Sieverding, “Holonic control of an engine assembly plant: An industrial evaluation,” in Proc. IEEE Int. Conf. Syst., Man, Cybern. vol. 1, Oct. 7–10, 2001, pp. 3151–3156. [18] F. Maturana, R. Staron, P. Tichy, and P. Slechta, “Using dynamically created decision-making organizations (holarchies) to plan, commit, and execute control tasks in a chilled water system,” in Proc. 13 th Int. Workshop Database Expert Syst. Appl. Sep. 2–6, 2002, pp. 613– 619. [19] F. P. Maturana, R. J. Staron, P. Tichy, P. Slechta, and P. Vrba, “A strategy to implement and validate industrial applications of holonic systems,” in Proc. 2nd Int. Conf. Ind. Appl. Holonic Multi-Agent Syst. (HoloMAS 2005), Aug. 22–24, pp. 111–120. [20] V. Marik, P. Vrba, K. H. Hall, and F. P. Maturana, “Rockwell automation agents for manufacturing,” in Proc. 4th Int. Conf. Auton. Agents Multi Agent Syst. (AAMAS 2005), Jul. 25–29, pp. 147–153. [21] P. Vrba, F. Macurek, and V. Marik, “Using radio frequency identification in agent-based manufacturing control systems,” in Proc. 2nd Int. Conf. Ind. Appl. Holonic Multi-Agent Syst. (HoloMAS 2005), Aug. 22–24, pp. 176–187. [22] L. Giannetti, F. P. Maturana, and F. M. Discenzo, “Agent-based control of a municipal water system,” in Proc. Multi-Agent Syst. Appl. IV. 4th Int. Central Eastern Eur. Conf. Multi-Agent Syst. (CEEMAS 2005), Sep. 15–17, pp. 500–510. [23] P. McGuire, G. Liggins, A. Benaskeur, R. W. Brennan, and P. Wojcik, “The application of holonic control to tactical sensor management,” in Proc. IEEE 2006 Workshop Distrib. Intell. Syst., 2006, pp. 225– 230. [24] M. Fletcher and P. Vrba, “A brace of agent simulation scenarios,” in Proc. IEEE 2006 Workshop Distrib. Intell. Syst., 2006, pp. 169–176. [25] K. H. Hall, R. J. Staron, and P. Vrba, “Experience with holonic and agentbased control systems and their adoption by industry,” in Proc. Holonic Multi-Agent Syst. Manuf. 2nd Int. Conf. Ind. Appl. Holonic Multi-Agent Syst. (HoloMAS 2005), Aug. 22–24, pp. 1–10. [26] J. L. Martinez Lastra and A. W. Colombo, “Engineering framework for agent-based manufacturing control,” Eng. Appl. Artif. Intell., vol. 19, pp. 625–640, 2006. [27] R. W. Brennan, M. Fletcher, S. Olsen, and D. Norrie, “Safety-critical software for holonic control devices,” in Proc. IMS Int. Forum Global Challenges Manuf., 2004, pp. 767–774. [28] Calgary. (2006). Olympic Oval Web Site [Online]. Available: http://oval.sunergon.com/ [29] J. H. Christensen, “Holonic manufacturing systems: Initial architecture and standards directions,” presented at the 1st Eur. Conf. Holonic Manuf. Syst., Hannover, Germany, 1994. [30] H. Van Brussel, J. Wyns, P. Valckenaers, L. Bongaerts, and P. Peeters, “Reference architecture for holonic manufacturing systems: PROSA,” Comput. Ind., vol. 37, pp. 255–274, 1998.

[31] J. Wyns, “Reference architecture for holonic manufacturing systems,” Ph. D. Thesis, Katholieke Univ. Leuven, Leuven, Belgium, 1999. [32] V. Marik, M. Fletcher, and M. Pechoucek, “Holons and agents: Recent developments and mutual impacts,” in Multi-Agent Syst. Appl. II, Lecture Notes in Computer Science. Berlin, Germany: Springer-Verlag, 2002. [33] D. C. McFarlane and S. Bussmann, “Holonic manufacturing control: Rationales, developments and open issues,” in Advances in the Holonic Approach to Agent-Based Manufacturing, S. M. Deen, Ed. New York: Springer-Verlag, 2003, pp. 303–326. [34] M. Fletcher, D. C. McFarlane, J. P. Brusey, D. Jarvis, V. Marik, M. Pechoucek, and R. W. Brennan, “Towards a methodology for holonic manufacturing systems” in Proc. IMS Int. Forum Global Challenges Manuf., 2004, pp. 792–800. [35] S. Rahimifard, S. T. Newman, and R. Bell, “Distributed autonomous real-time planning and control of small to medium enterprises,” in Proc. Inst. Mech. Eng. B. J. Eng. Manuf., vol. 213, pp. 475–489, 1999. [36] K. T. K. Toh, S. T. Newman, and R. Bell, “An information systems architecture for small metal-working companies,” in Proc. Inst. Mech. Eng. B. J. Eng. Manuf., vol. 212, pp. 87–103, 1998. [37] F. Schmid, S. Evans, A. W. S. Ainger, and R. J. Grieve, Computer Integrated Production Systems and Organizations: The Human-Centred Approach. vol. 134. New York: Springer-Verlag, 1994, p. 347. [38] R. W. Lewis, Programming Industrial Control Systems Using IEC 11313. London, U.K.: Institution of Electrical Engineers (IEE), 1996. [39] SoftLogix, (2006). [Online]. Available: http://www.ab.com/programmab lecontrol/pac/softlogix/index.html. [40] A. Zoitl, R. Smodic, and G. Grabmair, “Enhanced real-time execution of modular control software based on IEC 61499,” in Proc. IEEE Int. Conf. Robot. Autom., May 2006, pp. 327–332. [41] P. Tichy, “Fault tolerant and fixed scalable structure of middle-agents,” in Proc. 4th Int. Workshop CLIMA IV: Comput. Logic Multi-Agent Syst. Jan. 6–7, 2004, pp. 53–70. [42] R. W. Brennan and J. Wang, “A simulation-based approach to developing real-time distributed control systems,” in Proc. Summer Comput. Simul. Conf., 2003, pp. 24–29. [43] T. Heverhagen and R. Tracht, “Integrating UML-Real Time and IEC 61131-3 with function block adapters,” in Proc. 4th IEEE Int. Symp. Object-Oriented Real-Time Distrib. Comput. (ISORC 2001), May 2–4, pp. 395–402. [44] F. Auinger, R. Brennan, J. Christensen, J. L. Martinez Lastra, and V. Vyatkin, “Requirements and solutions to software encapsulation and engineering in next generation manufacturing systems: OOONEIDA approach,” Int. J. Comput. Integr. Manuf., vol. 18, pp. 572–85, 2005. [45] A. Valentini, A. Martel, B. Ferroni, J. Martinez Lastra, R. W. Brennan, J. H. Christensen, V. Vyatkin, and G. Brown, “O3NEIDA activity report,” O3NEIDA. Ottawa, ON, Canada, Tech. Rep. 04-2006, 2006. [46] V. V. Vyatkin, J. H. Christensen, and J. L. Martinez Lastra, “OOONEIDA: An open, object-oriented knowledge economy for intelligent industrial automation,” IEEE Trans. Ind. Inf., vol. 1, no. 1, pp. 4–17, Feb. 2005. [47] P. J. Ramadge and W. M. Wonham, “Supervisory control of a class of discrete event processes,” SIAM J. Control Optim., vol. 25, pp. 206–30, 1987. [48] P. Leitao, A. W. Colombo, F. Restivo, and R. Schoop, “Formal specification of holonic control system ADACOR product holon, using high-level Petri nets,” in Proc. IEEE Int. Conf. Ind. Inf. Aug. 21–24, 2003, pp. 263– 272. [49] M. Fabian and A. Hellgren, “PLC-based implementation of supervisory control for discrete event systems,” in Proc. IEEE Conf. Decis. Control, vol. 3, 1998, pp. 3305–3310. [50] K. Rudie and W. M. Wonham, “Think globally, act locally: Decentralized supervisory control,” IEEE Trans. Autom. Control, vol. 37, no. 11, pp. 1692–1708, Nov. 1992. [51] P. Kozak and W. M. Wonham, “Fully decentralized solutions of supervisory control problems,” IEEE Trans. Autom. Control, vol. 40, no. 12, pp. 2094–2097, Dec. 1995. [52] A. Ramirez Serrano and B. Benhabib, “Supervisory control of multiwork cell manufacturing systems with shared resources,” IEEE Trans. Syst., Man, Cybern. B, Cybern., vol. 30, no. 5, pp. 668–683, Oct. 2000. [53] S. C. Zho, A. Ramirez Serrano, and R. W. Brennan, “Cooperative multiagent reconfigurable manufacturing environments,” Int. J. Manuf. Technol. Manage., vol. 8, pp. 283–303, 2006. [54] S. Bussmann, “An agent-oriented architecture for holonic manufacturing control,” in Proc. 1st Int. Workshop Intell. Manuf. Syst. Apr. 15–17, 1998, pp. 1–12.



[55] B. Moulin and B. Chaib-draa, Foundations of Distributed Artificial Intelligence, G. O’Hare and N. Jennings, Eds. Hoboken, NJ: Wiley, 1996, pp. 3–56. [56] M. Huhns and M. Singh, Readings in Agents. San Mateo, CA: Morgan Kaufmann, 1998. [57] G. Booch, Object-Oriented Analysis and Design With Applications, 2nd ed. Reading, MA: Addison-Wesley, 1994. [58] W. Shen, F. Maturana, and D. H. Norrie, “MetaMorph II: An agentbased architecture for distributed intelligent design and manufacturing,” J. Intell. Manuf., vol. 11, pp. 237–251, 2000. [59] A. S. Rao and M. P. Georgeff, “Modeling agents within a BDI architecture,” in Proc. 2nd Int. Conf. Principles Knowl. Represent. Reason., 1991, pp. 473–484. [60] R. A. Brooks, “A robust layered control system for a mobile robot,” IEEE J. Robot. Autom., vol. RA-2, no. 1, pp. 14–23, Mar. 1986. [61] R. Davis and R. G. Smith, “Negotiation as a metaphor for distributed problem solving,” in Communication in Multiagent Systems. Agent Communication Languages and Conversation Policies. Lecture Notes in Artificial Intelligence, vol. 2650. Berlin, Germany: Springer-Verlag, 2003, pp. 51–97. [62] J. P. Mueller, M. Pischel, and M. Thiel, “Modelling reactive behaviour in vertically layered agent architectures,” in Intelligent Agents: Theories, Architectures, and Languages. Lecture Notes in Artificial Intelligence, vol. 890. M. Wooldrige and N. R. Jennings, Eds. Berlin, Germany: Springer-Verlag, 1995, pp. 261–276. [63] S. Franklin, “Autonomous agents as embodied AI,” Cybern. Syst., vol. 28, pp. 499–520, 1997. [64] A. D. Mali, “On the behavior-based architectures of autonomous agency,” IEEE Trans. Syst., Man, Cybern. C, Appl. Rev., vol. 32, no. 3, pp. 231–242, Aug. 2002. [65] B. Hayes-Roth, K. Pfleger, P. Lalanda, P. Morignot, and M. Balabanovic, “A domain-specific software architecture for adaptive intelligent systems,” IEEE Trans. Softw. Eng., vol. 21, no. 4, pp. 288–301, Apr. 1995. [66] T. Ishida, Parallel, Distributed and Multiagent Production Systems, 878th ed. Berlin, Germany: Springer-Verlag, 1994. [67] P. H. Enslow, Jr., “What is a ’distributed’ data processing system?,” Computer, vol. 11, pp. 13–21, 1978. [68] T. Vamos, “Cooperative systems: An evolutionary perspective,” IEEE Control Syst. Mag., vol. 3, no. 3, pp. 9–14, 1983. [69] J. Hatvany, “Intelligence and cooperation in heterarchic manufacturing systems,” Robot. Comput. Integr. Manuf., vol. 2, pp. 101–104, 1985. [70] H. V. D. Parunak, “Manufacturing experience with the contract net,” in Distributed Artificial Intelligence, vol. 1, M. Huhns, Ed. New York: Pitman, 1987, pp. 285–310. [71] N. A. Duffie and R. S. Piper, “Non-hierarchical control hierarchical control of a flexible manufacturing cell,” Robot. Comput. Integr. Manuf., vol. 3, pp. 175–179, 1986. [72] H. V. D. Parunak, “Applications of distributed artificial intelligence in industry,” in Foundations of Distributed Artificial Intelligence, G. O’Hare and N. Jennings, Eds. Hoboken, NJ: Wiley, 1996, pp. 139–164. [73] J. G. McGuire, D. R. Kuokka, J. C. Weber, J. M. Tenenbaum, T. R. Gruber, and G. R. Olsen, “SHADE: Technology for knowledge-based collaborative engineering,” Concurrent Eng.: Res. Appl., vol. 1, pp. 137–146, 1993. [74] H. Park, M. R. Cutkosky, A. B. Conru, and S. Lee, “Agent-based approach to concurrent cable harness design,” Artif. Intell. Eng. Des., Anal. Manuf. (AIEDAM), vol. 8, pp. 45–61, 1994. [75] K. Decker, K. Sycara, and M. Williamson, “Middle-agents for the Internet,” in Proc. 15th Int. Joint Conf. Artif. Intell. (IJCAI 1997), Aug. 23–29, pp. 578–583. [76] G. Wiederhold, “Mediators in the architecture of future information systems,” Computer, vol. 25, pp. 38–49, 1992. [77] B. R. Gaines, D. H. Norrie, and A. Z. Lapsley, “Mediator: An intelligent information system supporting the virtual manufacturing enterprise,” in Proc. 1995 IEEE Int. Conf. Syst., Man, Cybern. 1, Oct. 22–25,, pp. 964– 969. [78] R. W. Brennan and D. H. Norrie, “Agents, holons and functions blocks: Distributed intelligent control in manufacturing,” J. Appl. Syst. Stud., vol. 2, pp. 1–19, 2001. [79] FIPA. (2006). Foundation for intelligent physical agents. [Online]. Available: http://www.fipa.org/ [80] H. Simon, The Sciences of the Artificial. Cambridge, MA: MIT Press, 1996. [81] M. Fletcher, E. Garcia-Herreros, J. H. Christensen, S. M. Deen, and R. Mittmann, “An open architecture for holonic cooperation and auton-

763

[82] [83] [84]

[85] [86]

[87] [88] [89] [90]

[91] [92] [93]

[94] [95] [96]

[97] [98] [99] [100]

[101] [102]

[103]

omy,” in Proc. 11th Int. Workshop Database Expert Syst. Appl. Sep. 4–8, 2000, pp. 224–230. F. Maturana, W. Shen, and D. H. Norrie, “MetaMorph: An adaptive agent-based architecture for intelligent manufacturing,” Int. J. Prod. Res., vol. 37, pp. 2159–2173, 1999. T. Neligwa and M. Fletcher, “An HMS operational model,” in AgentBased Manufacturing: Advances in the Holonic Approach, S. M. Deen, Ed. Berlin, Germany: Springer-Verlag, 2003, pp. 163–192. S. Chiu, G. Provan, Y.-L. Chen, F. Maturana, S. Balasubramanian, R. Staron, and D. Vasko, “Shipboard system diagnostics & reconfiguration using model-based autonomous cooperative agents,” in Proc. Conf. Control Appl. Marine Syst., Jul. 18–20, 2002, pp. 323–329. A. W. Colombo, R. Neubert, and R. Schoop, “A solution to holonic control systems,” in Proc. 8th IEEE Int. Conf. Emerging Technol. Factory Autom., 2001, pp. 489–498. B. Suessmann, A. W. Colombo, and R. Neubert, “An agent-based approach towards the design of industrial holonic control systems,” in Knowledge and Technology Integration in Production and Services. Balancing Knowledge and Technology in Product and Service Life Cycle. IFIP TC5/WG5.3. Proc. 5th IEEE/IFIP Int. Conf. Inf. Technol. Balanced Autom. Syst. Manuf. Services (BASYS 2002), Sep. 25–27, pp. 255–262. P. Valckenaers, “Tutorial on multi-agent manufacturing control,” in Proc. 1st IEEE Int. Conf. Ind. Inf., Banff, AB, Canada, 2003. D. Goldberg, V. Cicirello, and M. B. Dias, “Task allocation using a market-based planning mechanism,” in Proc. Int. Conf. AAMAS 2003, vol. 2, Melbourne, Australia, pp. 996–997. P. Valckenaers, M. Kollingbaum, and H. Van Brussel, “Multi-agent coordination and control using stigmergy,” Comput. Ind., vol. 53, no. 1, pp. 75–96, 2004. M. Obitko and V. Marik, “Integration of multi-agent systems: Architectural considerations,” in Proc. 11th IEEE Int. Conf. Emerging Technol. Factory Autom., Prague, Czech Republic, Sep. 20–22, 2006, pp. 1145– 1148. Y. Koren, U. Heisel, F. Jovane, T. Moriwaki, G. Pritschow, G. Ulsoy, and H. Van Brussel, “Reconfigurable manufacturing systems,” CIRP Ann. Manuf. Technol., vol. 48, pp. 527–540, 1999. Y. Koren, “Reconfigurable manufacturing systems,” J. Soc. Instrum. Control Eng., vol. 42, pp. 572–582, 2003. B. Ravindran, P. Kachroo, and T. Hegazy, “Intelligent feedback controlbased adaptive resource management for asynchronous, decentralized real-time,” IEEE Trans. Syst., Man, Cybern. C, Appl. Rev., vol. 31, no. 2, pp. 261–265, May 2001. J. Kramer and J. Magee, “Dynamic configuration for distributed systems,” IEEE Trans. Softw. Eng., vol. SE-11, no. 4, pp. 424–36, Apr. 1985. J. Kramer, J. Magee, and A. Young, “Towards unifying fault and change management,” in Proc. 2nd IEEE Workshop Future Trends Distrib. Comput. Syst., Sep./Oct. 1990, pp. 57–63. P. Oreizy, M. M. Gorlick, R. N. Taylor, D. Heimhigner, G. Johnson, N. Medvidovic, A. Quilici, D. S. Rosenblum, and A. L. Wolf, “An architecture-based approach to self-adaptive software,” IEEE Intell. Syst., vol. 14, no. 3, pp. 54–62, May/Jun. 1999. P. Oreizy, N. Medvidovic, and R. N. Taylor, “Architecture-based runtime software evolution,” in Proc. 20th Int. Conf. Softw. Eng. Apr. 19–25, 1998, pp. 177–186. M. Guler, S. Clements, L. M. Wills, B. S. Heck, and G. J. Vachtsevanos, “Transition management for reconfigurable hybrid control systems,” IEEE Control Syst. Mag., vol. 23, no. 1, pp. 36–49, Feb. 2003. W. Han and M. A. Jafari, “Component and agent-based FMS modeling and controller synthesis,” IEEE Trans. Syst., Man, Cybern. C, Appl. Rev., vol. 33, no. 2, pp. 193–206, May 2003. A. Zoitl, C. Seunder, and I. Terzic, “Dynamic reconfiguration of distributed control applications with reconfiguration services based on IEC 61499,” in Proc. IEEE 2006 Workshop Distrib. Intell. Syst., Jun. pp. 109–144. R. W. Brennan, M. Fletcher, and D. H. Norrie, “An agent-based approach to reconfiguration of real-time distributed control systems,” IEEE Trans. Robot. Autom., vol. 18, no. 4, pp. 444–451, Aug. 2002. R. W. Brennan, X. Zhang, Y. Xu, and D. H. Norrie, “A reconfigurable concurrent function block model and its implementation in real-time Java,” Integr. Comput.-Aided Eng., vol. 9, pp. 263–279, 2002. X. Zhang, S. Balasubramanian, R. W. Brennan, and D. H. Norrie, “Design and implementation of a real-time holonic control system for manufacturing,” Inf. Sci., vol. 127, pp. 23–44, 2000.


764


[104] X. Zhang, R. W. Brennan, Y. Xu, and H. N. Douglas, “Runtime adaptability of a concurrent function block model for a real-time holonic controller,” in Proc. 2001 IEEE Int. Conf. Syst., Man, Cybern., Oct. 7–10 pp. 164–168. [105] Esmertec 2006. [Online]. Available: http://www.esmertec.com/ [106] R. W. Brennan and D. H. Norrie, “Managing fault monitoring and recovery in distributed real-time control systems,” in Knowledge and Technology Integration in Production and Services. Balancing Knowledge and Technology in Product and Service Life Cycle. IFIP TC5/WG5.3. Proc. 5th IEEE/IFIP Int. Conf. Inf. Technol. Balanced Autom. Syst. Manuf. Services (BASYS 2002), Sep. 25–27, pp. 247–254. [107] N. G. Leveson, System Safety Engineering: Back to the Future. Cambridge, MA: MIT Press, 2002. [108] R. Froschauer, F. Auinger, G. Grabmair, and T. Strasser, “Automatic control application recovery in distributed IEC 64199 based automation and control systems,” in Proc. IEEE 2006 Workshop Distrib. Intell. Syst., 2006, pp. 103–108. [109] T. Strasser, I. Müller, C. Sünder, O. Hummer, and H. Uhrmann, “Modeling of reconfiguration control applications based on the IEC 61499 reference model for industrial process measurement and control systems,” in Proc. IEEE 2006 Workshop Distrib. Intell. Syst., Jun. pp. 127–132. [110] T. Strasser, I. Müller, A. Zoitl, C. Sünder, and G. Grabmair, “A distributed control environment for reconfigurable manufacturing,” in Proc. 1st I*PROMS VirSystems, 2005. [111] C. Sünder, A. Zoitl, M. Rainbauer, and B. Favre-Bulle, “Hierarchical control modeling architecture for modular distributed automation systems,” in Proc. 4th Int. IEEE Conf. Ind. Inf., Aug. 2006, pp. 12– 17. [112] O. Hummer, C. Sünder, A. Zoitl, T. Strasser, M. N. Rooker, and G. Ebenhofer, “Towards zero-downtime evolution of distributed control applications via evolution control based on IEC 61499,” in Proc. 11th IEEE Int. Conf. Emerging Technol. Factory Autom. (ETFA), 2006, pp. 1–10. [113] G. Grabmair, R. Froschauer, T. Strasser, and A. Zoitl, “Modelling execution order and real-time constraints in IEC 61499 control applications,” in Proc. IEEE Workshop Distrib. Intell. Syst., 2006, pp. 115– 120. [114] V. Vyatkin, “Intelligent mechatronic components: Control system engineering using an open distributed architecture,” in Proc. 2003 IEEE Conf. Emerging Technol. Factory Autom., Sep. 16–19, pp. 277–284. [115] Profactor GmbH. (2006). Micro holons for next generation distributed embedded automation and control. [Online]. Available: http://www. microns.org/nopunc. [116] V. Vyatkin and J. Martinez Lastra, “Architectural foundations for reconfigurable manufacturing system,” in Proc. 3rd Int. Symp. Open Control Syst., 2003. [117] K. Thramboulidis, D. Perdikis, and S. Kantas, “Model driven development of distributed control applications,” Int. J. Adv. Manuf. Technol., 2006. DOI: 10.1007/s00170-006-0455-0 [118] CORFU Framework. 2006. [Online]. Available: http://seg.ee.upatras.gr/ corfu/dev/index.htm [119] K. Thramboulidis and A. Zoupas, “Real-time Java in control and automation: A model driven development approach,” in Proc. 10th IEEE Int. Conf. Emerging Technol. Factory Autom., vol. 1, Sep. 2005, p. 8. [120] K. Thramboulidis, G. Doukas, and A. Frantzis, “Towards an implementation model for FB-based reconfigurable distributed control applications,” in Proc. 7th IEEE Int. Symp. Object-Oriented Real-Time Distrib. Comput. May 12–14, 2004, pp. 193–200. [121] G. S. Doukas and K. C. Thramboulidis, “A real-time linux execution environment for function-block based distributed control applications,” in Proc. 3rd IEEE Int. Conf. Ind. Inf. (INDIN 2005), Aug. 10–12, pp. 56– 61. [122] C. Tranoris and K. Thramboulidis, “Integrating UML and the function block concept for the development of distributed control applications,” in Proc. 2003 IEEE Conf. Emerging Technol. Factory Autom., Sep. 16–19, pp. 87–94. [123] TORERO. (2006). Total life cycle web-integrated control. [Online]. Available: http://www.uni-magdeburg.de/iaf/cvs/torero/ [124] C. Schwab, M. Tangermann, and L. Ferrarini, “Web based methodology for engineering and maintenance of distributed control systems: The TORERO approach,” in Proc. 3rd IEEE Int. Conf. Ind. Inf. (INDIN 2005), Aug. 10–12, pp. 32–37. [125] C. Schwab, M. Tangermann, A. Luder, A. Kalogeras, and L. Ferrarini, “Mapping of IEC 61499 function blocks to automation protocols within the TORERO approach,” in Proc. 2nd IEEE Int. Conf. Ind. Inf. Jun. 24–26, 2004, pp. 149–154.

[126] L. Ferrarini, M. Romanò, and C. Veber, “Automatic generation of AWL code from IEC 61499 applications,” in Proc. 4th Int. IEEE Conf. Ind. Inf., 2006, pp. 25–30. [127] L. Ferrarini, C. Veber, C. Schwab, M. Tangermann, and A. Prayati, “Control functions development for distributed automation systems using the TORERO approach,” presented at the 16th IFAC World Congr., Prague, Czech Republic, 2005. [128] K. Lorentz, A. P. Kalogeras, T. Bauten, L. Ferrarini, C. Schwab, J. Thieme, G. Fogliazza, and A. Vontas, “Next generation integrated development of automation control code in TORERO,” in Proc. 2003 IEEE Int. Symp. Ind. Electron., Jun. 9–11, pp. 858–861. [129] G. Provan and Y. Chen, “Agent-based, distributed diagnosis for shipboard systems,” in Knowledge and Technology Integration in Production and Services. Balancing Knowledge and Technology in Product and Service Life Cycle. IFIP TC5/WG5.3. Proc. 5th IEEE/IFIP Int. Conf. Inf. Technol. Balanced Autom. Syst. Manuf. Services (BASYS 2002), Sep. 25–27, pp. 281–288. [130] F. P. Maturana, R. J. Staron, and K. Hall, “Real time collaborative intelligent solutions,” in Proc. 2004 IEEE Int. Conf. Syst., Man, Cybern. (SMC 2004), Oct. 10–13, pp. 1895–1902. [131] F. P. Maturana, R. J. Staron, and K. H. Hall, “Methodologies and tools for intelligent agents in distributed control,” IEEE Intell. Syst., vol. 20, no. 1, pp. 42–49, Jan./Feb. 2005. [132] F. P. Maturana, P. Tichy, P. Slechta, F. Discenzo, R. J. Staron, and K. Hall, “Distributed multi-agent architecture for automation systems,” Expert Syst. Appl., vol. 26, pp. 49–56, 2004. [133] F. P. Maturana, P. Tichy, P. Slechta, R. J. Staron, F. M. Descenzp, and K. Hall, “A highly distributed intelligent multi-agent architecture for industrial automation,” in Proc. 3rd Int. Central Eastern Eur. Conf. MultiAgent Syst. (CEEMAS 2003), Jun. 16–18, pp. 522–532. [134] N. Storey, Safety-Critical Computer Systems. Englewood Cliffs, NJ: Prentice-Hall, 1996. [135] T. Anderson and P. Lee, Fault Tolerance Principles and Practice. Englewood Cliffs, NJ: Prentice-Hall, 1981. [136] D. Siewiorek and R. Wsarz, The Theory and Practice of Reliable System Design. Bedford, MA: Digital, 1982. [137] International Electrotechnical Commission (IEC), “International standard 1508, functional safety: Safety-related systems,” IEC. Geneva, Switzerland, Tech. Rep. 1508. 1995. [138] N. G. Leveson, Safety-Critical Computer Systems. Reading, MA: Addison-Wesley, 1995. [139] B. Douglass, Doing Hard Time: Developing Real-Time Systems With UML, Objects, Frameworks, and Patterns. Reading, MA: AddisonWesley, 1999. [140] W. J. Cullyer and B. A. Wickmann, “The choice of computer languages for use in safety-critical systems,” Softw. Eng. J., vol. 6, pp. 51–8, 1991. [141] J. Barnes, Programming in Ada 95, 2nd ed. Reading, MA: AddisonWesley, 1998. [142] G. Tecuci, Building Intelligent Agents—An Apprenticeship Multistrategy Learning Theory, Methodology, Tool and Case Studies. New York: Academic, 1998. [143] K. Toon, “IEC 61131-3 in safety applications,” in Proc. IEE—Appl. IEC 61131 Ind. Control. Making High Value Ind. Control Syst. Work for You 6, 2002, pp. 7–11. [144] R. W. Lewis, “Can IEC 61131 graphical languages be used for safety related PLC applications?,” in Proc. IEE—Appl. IEC 61131 Ind. Control. Making High Value Ind. Control Syst. Work for You Feb. 6, 2002, pp. 2– 11. [145] V. Vyatkin and H. Hanisch, “Verification of distributed control systems in intelligent manufacturing,” J. Intell. Manuf., vol. 14, pp. 123–136, Feb. 2003. [146] V. Vyatkin and H. Hanisch, “Compensation design and formal validation of SFA systems: A case study,” in Knowledge and Technology Integration in Production and Services. Balancing Knowledge and Technology in Product and Service Life Cycle. IFIP TC5/WG5. 3. Proc. 5th IEEE/IFIP Int. Conf. Inf. Technol. Balanced Autom. Syst. Manuf. Services (BASYS 2002), Sep. 25–27, 2002, pp. 313– 322. [147] V. Vyatkin and H. Hanisch, “Application of visual specifications for verification of distributed controllers,” in Proc. IEEE Int. Conf. Syst., Man, Cybern., Oct. 7–10, 2001, pp. 646–651. [148] V. Vyatkin and H. Hanisch, “Bringing the model-based verification of distributed control systems into the engineering practice,” in Proc. Intell. Manuf. Syst. 2001, Apr. 24–26, pp. 155–160.



[149] W3C. (2006). World wide web consortium. [Online]. Available: http:// www.w3c.org [150] ICS Triplex. (2006). [Online]. Available: http://www.isagraf.com [151] M. B. Younis and G. Frey, “Formalization of existing PLC programs: A survey,” in Proc. CESA, Lille (France) CD-ROM. Paper S2-R-00-0239, July, 2003. [152] N. Voelker and B. J. Kramer, “Automated verification of function block based industrial control systems,” in Proc. 1998 ARO/ONR/NSF/DARPA Monterey Workshop Eng. Autom. Comput. Based Syst., Oct. 23–26, pp. 97–110. [153] H. Hanisch and M. Rausch, “Synthesis of supervisory controllers based on a novel representation of condition/event systems,” in Proc. 1995 IEEE Int. Conf. Syst., Man, Cybern. Intell. Syst. 21st Century, Oct. 22– 25, pp. 3069–3074. [154] V. Vyatkin, H. Hanisch, and T. Pfeiffer, “Modular typed formalism for systematic modeling of automation systems,” in Proc. IEEE Conf. Industrial Informatics (INDIN 2003). [155] V. Vyatkin, S. Karras, and T. Pfeiffer, “Architecture for automation system development based on IEC 61499 standard,” in Proc. 3rd IEEE Int. Conf. Ind. Inf. (INDIN 2005), Aug. 10–12, pp. 13–18. [156] A. Lobov, J. L. Martinez Lastra, R. Tuokko, and V. Vyatkin, “Methodology for modeling visual flowchart control programs using net condition/event systems formalism in distributed environments,” in Proc. 2003 IEEE Conf. Emerging Technol. Factory Autom., Sep. 16–19, pp. 329–336. [157] M. Stanica and H. Guedguen, “A timed automata model of IEC 61499 basic function blocks semantic,” in Proc. Euromicro Euro. Conf. RealTime Syst., 2003. [158] UPPAAL. (2006). [Online]. Available: http://www.uppaal.com [159] M. Bonfe and C. Fantuzzi, “Design and verification of mechatronic object-oriented models for industrial control systems,” in Proc. IEEE Conf. Emerging Technol. Factory Autom. Sep. 16–19, 2003, pp. 253– 260. [160] V. Vyatkin and C. Peniche, “How does the IEC61499 architecture fit the requirements of intelligent automation systems?,” in Proc. 2nd IEEE Conf. Ind. Inf., 2004, pp. 575–580. [161] R. W. Brennan and K. Soundararajan, “A hybrid simulation/physical environment for benchmarking real-time distributed control systems,” presented at the 16th IFAC World Conf. Prague, Czech Republic, 2005. [162] R. W. Brennan, K. Hall, V. Marik, F. Maturana, and D. H. Norrie, “A realtime interface for holonic control devices,” in Proc. 1st Int. Conf. Ind. Appl. Holonice Multi-Agent Syst. (HoloMAS 2003), Sep. 1–3, pp. 25–34. [163] D. Loomis, The TINI Specification and Developer’s Guide. London, U.K.: Pearson, 2001. [164] W. Kelton, R. Sadowski, and D. Sadowski, Simulation With Arena. New York: McGraw-Hill, 1998. [165] P. Vrba, “Simulation in agent-based control systems: MAST case study,” Int. J. Manuf. Technol. Manage., vol. 8, pp. 175–187, 2006. [166] P. Vrba, “JAVA-based agent platform evaluation,” in Proc. 1st Int. Conf. Ind. Appl. Holonice Multi-Agent Syst. (HoloMAS 2003), Sep. 1–3, pp. 47– 58. [167] Holobloc. (2006). [Online]. Available: http://www.holobloc.com

765

[168] SaJe. (2006). Real-time native Java execution. [Online]. Available: http:// www.saje.systronix.com/ [169] O3neida. (2006). O3NEIDA workbench. [Online]. Available: http:// sourceforge.net/projects/oooneida-wb/ [170] Rockwell Automation. (2006). [Online]. Available: http://www. rockwellautomation.com [171] Softing. (2006). [Online]. Available: http://www.softing.com [172] HMS. (2006). Holonic manufacturing systems. [Online]. Available: http://hms.ifw.uni-hannover.de/public/hms16open/index2.htm [173] H. Tsunematsu, H. Sasajima, and T. Hojo, “A low-cost experimental system and engineering methodology for IEC 61499 applications,” in Knowledge and Technology Integration in Production and Services. Balancing Knowledge and Technology in Product and Service Life Cycle. IFIP TC5/WG5.3. Proc. 5th IEEE/IFIP Int. Conf. Inf. Technol. Balanced Autom. Syst. Manuf. Services (BASYS 2002), Sep. 25–27, pp. 229–236. [174] W. E. Rumpl, F. Auinger, C. Dutzler, and A. Zoitl, “Platforms for scalable flexible automation considering the concepts of IEC 61499,” in Knowledge and Technology Integration in Production and Services. Balancing Knowledge and Technology in Product and Service Life Cycle. IFIP TC5/WG5.3. Proc. 5th IEEE/IFIP Int. Conf. Inf. Technol. Balanced Autom. Syst. Manuf. Services (BASYS 2002), Sep. 25–27, pp. 237–246. [175] K. Thramboulidis, “Model-integrated mechatronics—Toward a new paradigm in the development of manufacturing systems,” IEEE Trans. Ind. Inf., vol. 1, no. 1, pp. 54–61, Feb. 2005. [176] L. Wang, R. W. Brennan, S. Balasubramanian, and D. H. Norrie, “Realizing holonic control with function blocks,” Integr. Comput.-Aided Eng., vol. 8, pp. 81–93, 2001. [177] P. M. Jones and J. L. Jacobs, “Cooperative problem solving in human– machine systems: Theory, models, and intelligent associate systems,” IEEE Trans. Syst., Man, Cybern. C, Appl. Rev., vol. 30, no. 4, pp. 397– 407, Nov. 2000.

Robert W. Brennan (M’01) received the B.Sc. and Ph.D. degrees in mechanical engineering from the University of Calgary, Calgary, AB, Canada, in 1984 and 1997, respectively. He is currently an Associate Professor of mechanical and manufacturing engineering and the Associate Dean (Academic and Planning) at the Schulich School of Engineering, University of Calgary. His current research interests include distributed realtime control of manufacturing systems, modeling and analysis of manufacturing systems, and manufacturing control architectures. He has more than seven years of industrial experience in project management and control systems. Prof. Brennan is a Professional Engineer, and a member of the Society of Manufacturing Engineers (SME) and the Instrument Society of America (ISA).


Toward Real-Time Distributed Intelligent Control: A

Toward Real-Time Distributed Intelligent Control: A

Suggest Documents

Modeling Intelligent Control of Distributed Cooperative Inferencing

Distributed Control Patterns for Intelligent Mechatronic ... - CiteSeerX

Intelligent Control of a Distributed Energy Generation System ... - MDPI

An Intelligent System for Therapy Control in a Distributed ... - CiteSeerX

Distributed Realtime Interaction and ... - Jan-Michael Frahm

AN INTELLIGENT DISTRIBUTED SURVEILLANCE

Toward Intelligent Traffic Light Control with Quality-of-Service ...

Distributed Sensor Architecture for Intelligent Control that ... - MDPI

Distributed Intelligent Microgrid Control Using Multi-Agent Systems

Distributed control system for robotic cells and intelligent building ...

The Penn State intelligent distributed control research laboratory ...

The Penn State intelligent distributed control research laboratory ...

Towards a distributed intelligent ICT architecture for

Personal Intelligent Travel Assistant A distributed approach

A Distributed Approach for Intelligent Reconfiguration ...

A Multiagent Model for Intelligent Distributed

Intelligent Image Management in a Distributed

A Distributed Intelligent Computerffelephony Network ... - Springer Link

A Distributed, Collaborative Intelligent Agent System ...

INGate: a distributed intelligent network approach to

Toward Efficient and Equitable Distributed Air Traffic Flow Control

Multimodal Approach toward Intelligent Video

Toward Intelligent Drawing Constraints - CiteSeerX

Distributed coordination space: toward a theory of distributed team ...