Automation Agents for Controlling the Physical Components of a Transportation System
Wilfried Lepuschitz1,3; Benjamin Groessing1; Munir Merdan2,3 1 Vienna University of Technology, Vienna, Austria
2 Austrian Institute of Technology, Vienna, Austria
3 Practical Robotics Institute Austria, Vienna, Austria
Abstract
Transportation systems are regarded as the backbone of manufacturing systems and have a significant influence on the facility’s efficiency and throughput. In the case of conveyor systems, traffic jams can occur due to component failures, which may lead to degradations of the system performance or even a total halt of the production process. This can be avoided by an increase of flexibility and reconfigurability of the control infrastructure and in particular of the routing functionality. This chapter presents an implementation of agent technology for a pallet transport system. The introduced multi-agent system constitutes a control system with failure diagnosis and reconfiguration capabilities for minimizing the consequences of component failures. Details of the pallet transport system are given, as well as of the agents responsible for controlling the physical components. Moreover, test cases are introduced for the evaluation of the presented approach, as well as the results of performed experiments, which show the feasibility and benefits of the multi-agent approach.
Acknowledgments
The authors would like to thank Christoph Krofitsch for his contribution concerning the implementation and performed experiments. Furthermore, the authors acknowledge the financial support of the BRIDGE program from the Austrian Research Promotion Agency under contract FFG 829576.
18.1 Introduction/Motivation
With the rising dynamics of the twenty first century market due to custom-based products and shorter product life cycles, manufacturing systems need to support the paradigm of mass customization with a focus on “made-to-order” instead of “made-to-stock” (Marík et al., 2002). Even though the concept of mass customization was already described before the turn of the millennium, its importance as a major manufacturing strategy has only increased during the last decade, thus introducing new technological demands (Fogliatto et al., 2012). To put these demands in a nutshell, manufacturing control systems are forced to produce customized products with small and medium lot sizes in a short time at a low price under dynamic conditions. A way to realize mass customization is to employ the paradigm of reconfigurable manufacturing (ElMaraghy, 2006). A manufacturing system based on this paradigm has to possess the capability of dynamically modifying its behavior to deal with unusual conditions such as equipment failures and to enable modification of the shop floor layout without stopping production (Vrba and Marík, 2010).
Similar conditions prevail for transportation systems, which are regarded as the backbone of manufacturing systems and have a significant influence on the facility’s efficiency and throughput (Byrne and Chutima, 1997). In the case of conveyor systems, traffic jams can occur due to component failures, which may lead from deviations of the production schedule and degradations of the system performance to a total halt of the production process. Consequently, production costs increase and the economic competitiveness decreases, which can be avoided by increasing the flexibility and reconfigurability of the routing process and infrastructure. However, currently applied control approaches based on the rather static programming languages for programmable logic controllers (PLCs) are not suitable for dynamic path planning and modification during operations (Vrba and Marík, 2010). Generally, it is nearly impossible to predefine adequate top-down responses for a broad range of abrupt changes, which would be necessary in the case of a rigid hierarchical control architecture (Monostori et al., 2006). On the contrary, a distributed architecture composed of modular components offers modularity and customization capabilities, allowing the alteration of the provided functionality (Mehrabi et al., 2000). Ultimately, for realizing a highly flexible and reconfigurable control system, the application of a multi-agent system (MAS) is regarded as an enabling approach (Jennings and Bussmann, 2003; Leitao, 2009). Such a system constitutes a network of autonomous entities (i.e., agents), with each entity having individual goals, capabilities, and behaviors. The agents have to cooperate and communicate with each other in order to achieve common aims, which are beyond the individual capabilities and knowledge possessed by each agent.
This book chapter presents a MAS implementation for a pallet transport system, which is denoted as the “testbed for distributed control” and is located at the Odo Struger Laboratory of the Automation and Control Institute (ACIN), Vienna University of Technology. The aim of the MAS is to constitute a control system with reconfiguration capabilities for minimizing the consequences of component failures. Details of the testbed are described, as well as the agents responsible for controlling the testbed’s components. Emphasis is put on the reconfiguration mechanisms for maintaining system performance in the case of a component failure. Moreover, three test cases are introduced, which are used for evaluating the presented approach.
18.2 Application Overview
The “testbed for distributed control” is composed of 45 conveyors with 32 intersections and a set of indexstations with grippers for holding pallets (see Figure 18.1). The topology of the system provides various redundant paths the pallets can take in case of component failures. Moreover, several workstations are arranged around the pallet transport system, such as an industry robot, a storage system with a handling unit for extracting parts, and a portal robot for assembly tasks.
Transport tasks encompass the delivery of a part from its storage to a machine or to carry parts between the machines. Hence, the objective is to transport pallets between indexstations in a minimum amount of time, following the shortest path and avoiding broken components. Because the MAS implementation is focused on the routing of pallets, only the pallet transport system is described in the following section in more detail.
Following the principle of physical decomposition (Shen, 2002), each entity, such as an intersection, is represented by a distinct agent, denoted as an automation agent (AA). Thus, the AAs serve as the basic building blocks of this distributed control system and are responsible for directly controlling the physical components.
Tasks such as the scheduling of jobs can be performed by different types of functional agents, which do not represent physical entities. For the work presented in this book chapter, only the contact agent (CA) type is of importance because it is responsible for carrying out algorithms encompassing the complete testbed. Detailed information about the provided functionality of the functional agents can be found in Merdan (2009) and Merdan et al. (2011a).
The agent system incorporates reconfiguration mechanisms, which provide a grade of fault-tolerance in case of a component failure. These mechanisms encompass, on the one hand, the global reconfiguration of the system topology by changing conveyor directions and recalculating routing paths, and on the other hand, local reconfiguration for adapting an agent’s provided functionality.
18.3 Application Details
The following sections describe the target system, as well as the AA architecture, in more detail. Moreover, the reconfiguration capabilities are explained and three test cases are introduced, which are used for evaluating the MASs.
18.3.1 Testbed for Distributed Control
The pallet transport system consists of the following mechatronic components, which represent the main entities to be controlled by the MAS:
• Conveyor belts have the task of actually moving the pallets from one place to another.
• Intersections represent the connection of several conveyors. Depending on the adjacent conveyors’ directions, an intersection operates either as a diverter (receiving pallets from one input conveyor and routing them to one of the output conveyors) or as a junction (receiving pallets from two input conveyors and feeding them to the one output conveyor).
• Indexstations are located at the outer loops of the pallet transport system next to the workstations. They comprise a gripper for holding a pallet in a defined position, so that a workstation has access to its load.
Sensors are employed at the indexstations, as well as at intersections, for detecting pallets, and blockers are used for stopping them. For the identification of the pallets and their destinations, the indexstations and intersections rely on radio frequency identification (RFID) tags, which are accessed through RFID modules. The basic components of the intersections and indexstations (i.e., grippers, switches, and blockers) are moreover equipped with sensors for verifying their momentary state.
For controlling the indexstations and intersections, as well as the conveyors, a set of 38 embedded controllers of the type CPX-CEC-C1 by Festo is employed. Each of these controllers incorporates an Xscale-PXA255 agile Intel microprocessor with 400 MHz, 28 MB Flash, 24 MB RAM, and several input/output (I/O) modules (digital inputs, digital outputs, and valves) for accessing the sensors and actuators. The RFID modules are controlled by small embedded controllers of the type Digi Connect ME, which act as decentral I/Os for the Festo CPX controllers.
18.3.2 Architecture of an Automation Agent
Considering the requirements of the manufacturing environment for real-time tasks, it is widely agreed to split agent-based manufacturing control into two parts: the high-level control (HLC) and the hardware-near low-level control (LLC) (Christensen, 2003). Accordingly, a generic agent architecture following this separation of concerns represents the basis for the design of the AAs (Vallée et al., 2009). The two control levels are organized in a layered architecture, with the HLC being superjacent to the LLC. For communication between the two layers, an interface is applied for exchanging data (Lepuschitz et al., 2009).
18.3.2.1 High-Level Control of an Automation Agent
The HLC, implemented in Java within the Java Agent DEvelopment framework (JADE) (Telecom Italia Lab, 2000), is responsible for the “global” behavior of the AA, using information from the subjacent LLC in conjunction with information gathered from other agents of the system. It relies on a world model repository realized with JavaBean classes, which contains a symbolic representation of the agent’s inner states, as well as the surrounding environment. The world model’s contents can be queried for reasoning about the states of the world, which may result in performing actions such as communicating with another agent. During operation, the world model is updated due to performed actions or recognized world condition changes. The world model repository consists of two parts: the situation model and the activity model (see Figure 18.2).
The situation model contains knowledge about the agent’s own characteristics and its relations to other entities in the world (e.g., an intersection has input as well as output conveyors) in the form of an ontology. Storing knowledge in such a form brings advantages such as extensibility and a common format for expressing and sharing data between agents (González et al., 2006). Furthermore, the situation model incorporates a representation of facts for expressing knowledge about the current state of the world. The situation model is not intended to represent the complete environment of the agent, only an abstraction of meaningful aspects for realizing high-level control tasks.
The activity model is composed of activity classes, which represent the actions, tasks, and goals of the agents. These activity classes are used for diagnostic tasks by forming expectations that should be observed when a specific action is carried out. Thus, the agent is able to recognize inconsistencies between the desired system state and the information received from the environment, which allows the detection and identification of failures in the event of unfulfilled expectations (Merdan et al., 2011b; Vallée et al., 2011). The cooperation between agents even allows the detection of anomalies that involve more than one agent. For example, a pallet that left an agent’s area of influence should appear at a neighboring agent after a certain amount of time. If this is not the case, the pallet is declared missing. Such a case can occur due to a mechanical issue blocking the pallet somewhere on the conveyor, or the pallet’s removal by a human operator.
18.3.2.2 Low-Level Control of an Automation Agent
The LLC, realized with a network of IEC 61499 function blocks (FBs) (International Electrotechnical Commission, 2005), provides the basic functionality of a component (i.e., routing a pallet in the case of an intersection operating as a diverter onto one of two outgoing conveyors and blocking other pallets in the meantime). Following a component-oriented design, a typical LLC application for an entity contains only a small number of FBs. In the case of a diverter, the LLC encompasses 11 FBs (see Figure 18.3). By using the adapter concept for the connections between the FBs, only a few connections between them are necessary.
To allow easy reuse, the control software for each type of basic component is encapsulated in a specific composite FB type. All these FB types offer access to the corresponding I/Os responsible for controlling the distinct basic components (blocker, switch, etc.). They also incorporate simple diagnostic algorithms for detecting failures of the basic components. Higher functionalities, such as communication with the HLC or the algorithm for the routing of pallets, are provided by the central composite FB (i.e., FB_Diverter in the given example). A local routing table, which is calculated depending on the topology of the system and stored within the FB, determines the outgoing conveyor for a passing pallet. The main operational sequence of an entity’s functionality is realized using the concept of finite state machines.
Both the Festo CPX and Digi Connect ME controllers host instances of the Framework for Distributed Industrial Automation and Control Runtime Environment (FORTE), which is a small portable C++ runtime environment for running IEC 61499 applications on embedded control devices (4DIAC-Consortium, 2013). The FORTE incorporates a reconfiguration infrastructure, which allows the modification of the FB network during runtime. By making use of this reconfiguration infrastructure, the AA is able to modify its LLC according to new requirements set by the agent’s environment.
18.3.2.3 Agent Configuration and Reconfiguration
A resource ontology manifested in an eXtensible Markup Language (XML) format describes the concepts and topology of the pallet transport system (see Figure 18.4) (Lepuschitz et al., 2011). The classes of the resource ontology with their relations are stored in a module specification file, and their instances are stored in a corresponding instance specification file. According to the ontology’s contents, the agents’ HLCs are automatically created in JADE at system startup. Furthermore, the AA concept incorporates an approach for automatically configuring the agents’ LLCs. It makes use of the resource ontology, which encompasses entities such as intersections and their accompanying basic components, as well as the necessary controller infrastructure with its input/output modules. Based on this representation, an agent’s HLC is able to perform a specification check and carry out the LLC configuration by creating, wiring, and parameterizing the IEC 61499 FBs. Thus, an executable implementation is generated for each entity within the corresponding Festo CPX controller.
Based on the configuration approach, AAs are also able to adjust their functionality during runtime. On the one hand, the world model is updated in the HLC, which allows the AA to perform its diagnostic tasks in the new configuration. On the other hand, using the knowledge provided by the resource ontology in conjunction with the knowledge stored in the agent’s world model, the HLC is able to modify the FB network of the LLC (Lepuschitz et al., 2011b). The following section describes the reconfiguration mechanisms.
18.3.3 System Reconfiguration due to a Component Failure
This section is concerned with a reconfiguration process, which is triggered due to a detected component breakdown. In the given case, a failure of a conveyor is detected by an AA, which consequently notifies the CA about the detected anomaly.
After receiving the notification from the affected AA, the CA updates its representation of the system topology with the fact of the unusable conveyor. For calculating routing paths and verifying the reachability of all destinations in the system, the CA relies on a shortest path algorithm (Merdan et al., 2008), which is based on Dijkstra’s algorithm (Dijkstra, 1959). The result of the algorithm leads to one of the following two cases:
1. If routes are found from and to each destination, the AAs controlling the intersections update their routing tables and store them in the LLC.
2. In the case of one or several unreachable destinations, the CA employs a change direction algorithm (CDA) for determining the necessary direction changes of conveyors (Koppensteiner et al., 2008). This algorithm calculates a new system configuration based on the ontology representation and thereby requests specific conveyors to change their direction to make destinations reachable that were otherwise inaccessible. Messages about this are then sent by the CA to the concerned conveyors. Hence, the AAs controlling the conveyors change their direction and inform the AAs controlling the adjacent components (i.e., the adjacent intersections) about the direction changes.
The global topology configuration of case 2 requires the local reconfiguration of the functionality provided by the AAs controlling the affected intersections. Based on the information such an AA receives from its neighboring conveyors, it updates its world model. The resulting world model then reflects the current knowledge about the state of the world.
Reconfiguring the intersection AA’s functionality involves several steps. The first step encompasses updating the facts in the situation model according to the received information. During this step, the HLC ensures that the received knowledge is expressed correctly in its situation model. Figure 18.5 illustrates the modification of the facts in the situation model. In this case, the fact (i1 hasOutput c25) is replaced by the fact (i1 hasInput c25).
The second step handles the update of the activity types in the activity model. On the basis of the new situation, a different type of activity is introduced. As c25 now represents an input conveyor instead of an output conveyor, the automation agent is now able to perform the activity “Routing a Pallet from (c12 or c25) to c33” instead of “Routing a Pallet from c12 to (c25 or c33)” (see Figure 18.6).
The fourth and final step is to express the goal configuration to be attained. Activities are mapped to possible configurations, which indicate to the agent the goal configuration to adopt. In the presented example case, two types of configurations exist:
• routingAsDiverter(inConv,outConv1,outConv2): In this configuration, the intersection receives pallets from one input conveyor and routes them to one of the output conveyors. Such a configuration enables the AA to perform any activity of the type “Routing Pallets from inConv to (outConv1 or outConv2).”
• routingAsJunction(inConv1,inConv2,outConv): In this configuration, the intersection receives pallets from one of two input conveyors and routes them to the output conveyor. Hence, any activity of the type “Routing Pallets from (inConv1 or inConv2) to outConv” can be performed by the AA.
In the considered case, the intersection agent is able to perform the activity “Routing Pallet from (c12 or c25) to c33” and so the AA has to achieve the goal configuration routingAsJunction(c12,c25,c33). Based on the determined goal configuration in combination with knowledge about the generated LLC during system startup, the AA infers that the momentarily available pivotal functionality (manifested by FB_Diverter) is no longer required.
First of all, the operational state of the pivotal FB needs to be changed from “running” to “stopped” to make it deletable. However, before it can actually be deleted from the LLC, its connections to the other FBs need to be removed. Consequently, after the deletion of the connections the FB itself can be removed from the LLC. As soon as the deletion of the no longer required FB is finished, a new pivotal FB instance is created, parameterized and wired to the other FBs. Afterward, the newly created FB is started by issuing a start command.
Due to the modified conveyor directions, the routing tables of the intersection AAs are updated accordingly. After performing the presented steps, the previously unreachable indexstations are again reachable for restoring the system’s performance.
18.3.4 Example Process
For investigating the benefits of using a control system based on AAs, an example process is evaluated by means of throughput and path duration of the pallets within the pallet transport system. The process is composed of two process steps. At first, the pallets are located at indexstation D1 for being processed for a period of 10 seconds. Consecutively, they need to be processed as a second step at a different indexstation D2 for a longer period than at D1, which is 20 seconds. However, for avoiding a bottleneck at this second indexstation, the indexstation D3 is available as an alternative. Hence, at each of the two redundant indexstations only half of the pallets in the system need to be processed. Finally, each pallet has to return to indexstation D1 to begin another process cycle.
Three test cases are performed using 10 pallets:
(a) Test case without conveyor failures: All indexstations are reachable. Figure 18.7a depicts the shortest paths the pallets should take. At D1, one half of the pallets is sent to D2, and the other half to D3 as the next destination. Hence, pallets heading for D2 should follow the green path and afterward move back to D1 along the shaded green path. On the other hand, pallets heading for D3 should move along the red path to D3 and return afterward along the shaded red path to D1.
(b) Test case with a broken crucial conveyor and no resolving solution: Indexstation D2 cannot be reached, which means that all pallets have to be sent to D3 after being processed at D1. Therefore, in Figure 18.7b both the green and red path are shown as identical because all pallets have to move along the same path from D1 to D3 and back.
(c) Test case with a broken crucial conveyor, including a resolving solution: After detection of the broken component, the system reconfigures itself as mentioned in the previous section. Thus, indexstation D2 is accessible again. Figure 18.7c shows an unchanged red path for the one half of the pallets heading to indexstation D3 and back. However, the green path to indexstation D2 and back to D1 for the other half of the pallets is modified and slightly longer compared to the one in test case (a).
The measurement data is obtained by the indexstations by recording the processed pallets using their identity and a timestamp. This allows the calculation of the average time a pallet needs for completing a process cycle. Evidently, the throughput per hour of the system representing the number of processed pallets can easily be determined because it is inversely proportional to the average process cycle time.
18.4 Benefits and Assessment
The presented agent approach provides benefits in the context of failure diagnosis and reconfiguration for enhancing a system’s fault-tolerance. Besides, due to the component-based approach in conjunction with an ontology for representing the system topology, it is possible to modify the agent system without extensive efforts in the case of a changed system layout.
18.4.1 Diagnostic Mechanisms
The automatic detection of failures and unexpected behaviors is of significant importance for achieving fault-tolerant manufacturing systems. Thus, the AAs incorporate diagnosis mechanisms for observing their controlled entity’s behavior. On the one hand, an agent’s LLC is able to detect failures such as a not moving blocker by using sensor data for verifying a position change of the blocker after an according issued command. On the other hand, the HLC uses its activity model for monitoring state sequences. Thus, it is possible to identify causes for failures when differences between expected and occurred states are detected. Merging the information of multiple agents allows the detection of a wide range of failures.
18.4.2 Reconfiguration Mechanisms
The gray bars in Figure 18.8 show the average duration the pallets require for traveling between the indexstations for the three test cases. In test case (a), it can happen that pallets return from D2 and D3 at the same time, leading to traffic jams at D1. Therefore, the return path from indexstations D2 and D3 to D1 requires, on average, a longer duration of about 20 seconds.
Evidently, no data is available concerning the paths to and from D2 in test case (b) due to the unavailability of indexstation D2. This results in D3 being a bottleneck for the given process as the processing time at D3 is longer than the one at D1. Serious traffic jams occur at D3, which increases the travel duration from D1 to D3 by 75 seconds compared to test case (a). In contrast, in test case (b) the return path to D1 is slightly shortened compared to test case (a) as the pallets return from D3 with enough time difference that there are no traffic jams at D1.
The longer path between D1 and D2 in test case (c) increases the travel time accordingly between those indexstations, while the path duration between D1 and D3 is roughly the same as in test case (a). In contrast, the return path durations from indexstations D2 and D3 to D1 are a bit shorter, which can be explained by fewer traffic jams at D1 due to a longer path to D2, resulting in a better distribution of the pallets on the testbed.
Figure 18.9a shows the average process cycle duration, which incorporates travel and processing times. In failure-free test case (a), it takes 260.7 seconds, on average, for a pallet to complete a process cycle, which encompasses pallets going to both redundant indexstations. The failure of the crucial conveyor in test case (b) increases the average process cycle duration by 18.4% to 308.7 seconds compared to failure-free test case (a). Thus, the average throughput drops from 138.1 pieces to 116.6 pieces per hour, as shown in Figure 18.9b, which represents a decrease of 15.6%.
However, if the reachability of D2 is restored due to the reconfiguration performed by the agents, the process cycle takes only slightly more time compared to failure-free test case (a). The average process cycle time of 264.4 seconds represents an increase of only 1.4%. Accordingly, with 136 pieces per hour, the throughput is lower by 1.4% compared to test case (a). It can thus be concluded that for the given example the application of the presented agent approach improves the system efficiency significantly compared to a system without means of reconfiguration.
18.4.3 Modification of the System
Apart from the benefits regarding failure detection and recovery, the presented approach is also well-suited concerning an intended change of the physical layout of the pallet transport system. In such a case, only the topology of the system stored in the resource ontology needs to be adapted. Changing the system topology leads in most cases to a modified set of created AAs at system startup. By modifying the adjacency information of the components, the routing information is automatically generated, just as at system startup. Hence, the process of modifying the control software of the system after modifying its physical layout only requires a few minutes. Recently, the pallet transport system has been modified due to a reorganization of the laboratory. While the physical adaption took a few hours of work, the control software adaption was done in approximately ten minutes by updating the XML files of the resource ontology.
18.5 Discussion
The experimental results provided in the previous section show the benefits of the introduced agent-based approach regarding an occurring failure, but evidently a change of the process parameters leads to different results. As mentioned before, pallets are processed at D1 for 10 seconds and at D2 and D3 for 20 seconds. Shorter processing times reduce the amount of traffic jams occurring in test cases (a) and (c) when pallets return to D1 at the same time, and even lead to no traffic jams in test case (b). It can be concluded that in such a case it would be better to send all pallets to only one of the redundant workstations for the second process step. In contrast, longer processing times will likely lead to an increase in traffic jams. They are also more likely to happen if more pallets are added to the system. For such cases, keeping redundant workstations is of utmost importance to keep up the throughput of the system. Consequently, the presented approach is appropriate for systems with redundant paths but not for those structured as a single line.
As the approach is based on a resource ontology that allows an easy modification regarding the system layout, it is well suited for quick adaptions in case the already-used component types are still used. Thus, a pallet transport system with physical components suitable for being relocated can be modified quickly without any elaborate reprogramming efforts. Besides, due to the implemented reconfiguration capabilities of the individual AAs, the approach can also be adopted for target systems with different types of components. However, such an adaption requires significantly more efforts than a simple layout change. The contents of the resource ontology need to be modified, and the software components for the control layers have to be provided for enabling the AA initialization. This encompasses the behaviors for the HLC in the form of Java classes, as well as IEC 61499 FBs, for realizing the functionalities of the LLC.
For the presented implementation, the HLC behaviors and models have been implemented manually in the Java and JavaBean classes, which has been a rather elaborate process requiring appropriate programming skills. However, by developing and employing a suitable code parser, the world model classes especially could be exported from tools such as Protégé for designing ontologies. In general, it seems advisable to enable easier management and configuration of such a MAS. For instance, a kind of modular agent architecture, which can be configured instead of programmed to provide the distinct behaviors of an agent, would represent a feasible way of making agent technology usable for various target systems. The concept of modularity means that an agent gets only a specifically composed set of behavior modules containing declarative and procedural knowledge that is needed to provide this agent’s functionality. Thus, the agent system designer could reuse existing behavior modules for assembling new types of agents for different components. Considering that most current agent applications are mostly custom-developed, costs can be spread neither over multiple customers nor over time. Hence, a kind of modular approach would support the direction of generality and reusability of this technology.
Likewise, even though wired automatically by the agents at system startup, the IEC 61499 FB types have been designed manually using the Framework for Distributed Industrial Automation and Control Integrated Development Environment (4DIAC-IDE). Also, these FB types could be generated using abstract definitions provided, for instance, in Unified Modeling Language (UML) (Panjaitan and Frey, 2006).
A missing asset of the presented implementation is an extensive visualization during system operation. Because the agents operate asynchronously, in parallel and concurrently, which can lead to nonreproducible effects (Nguyen et al., 2011), it is of vital importance to provide an adequate overview of the agent activities, as well as the possibility to supervise their actions using an appropriate human–machine interface (HMI). The human operator needs to get the possibility for following and understanding the current process state. Thus, trust in the idea of delegating tasks to autonomous agents could be increased, which is a significant aspect to consider in future agent-based solutions (Pechoucek and Marík, 2008).
Even though the presented approach has shown benefits regarding fault-tolerance in simulations (Vallée et al., 2011), as well as in experiments (Lepuschitz et al., 2013), the system has not yet been analyzed mathematically regarding its stability. However, doubts regarding the reliability of an agent-based system cannot be ignored, especially in the case of a system, which might not be under direct human supervision (Vrba et al., 2011). Reported research on the stability of a MAS is mainly concerned with rather homogeneous entities and swarm theory, such as the approach described by Moreau (2005). Therefore, more advanced models and means for stability analyses might be required, which take the individual complex behaviors of intelligent agents in a heterogeneous MAS into account.
18.6 Conclusions
This book chapter presents an implementation of a MAS and its evaluation on a real pallet transport system. Each system component is controlled by one agent, which is able to observe its environment by combining information from the component’s sensors, as well as from other agents. By employing diagnostic mechanisms on the two control layers of each agent, failures can be detected. After detecting a failure such as a broken conveyor, the reconfiguration mechanisms of the system, in conjunction with local reconfiguration capabilities, allow a restoration of the system functionality in case redundant paths exist.
Performed experiments show the benefits of a MAS in the event of a conveyor breakdown. Depending on the process parameters, the throughput of the system can be restored to an amount slightly lower than the failure-free case. By contrast, if a breakdown renders a destination unreachable without such restoring mechanisms, the system throughput will decrease far more significantly.
The presented approach allows the application of more sophisticated routing algorithms, which can further enhance the system throughput even in the failure-free case. Thus, traffic jams could be reduced by routing pallets on alternative routes or by changing conveyor directions for enabling these routes. Moreover, by optimizing the distribution of pallets to redundant workstations, the throughput of the system could be improved as well. However, such algorithms have not yet been implemented in the presented MAS and are under consideration for future research.
Despite the described benefits of the presented MAS, its development has required appropriate programming skills and it cannot be adopted easily for systems with different physical components because the accompanying agent behaviors need to be developed. This might possibly hinder widespread application of this technology in the industry. In this context, the introduction of tools, techniques, and methodologies, which ensure easier and more abstract ways of agent system development, modification, and management, could lead to a higher rate of acceptance, as well as an understanding of this promising technology.