Evaluation of a Multi-Agent Approach for a RealTransportation System

Wilfried Lepuschitz, Benjamin Groessing, Munir Merdan and Georg SchitterAutomation and Control InstituteVienna University of Technology

Vienna, AustriaEmail: {lepuschitz, groessing, merdan, schitter

@acin.tuwien.ac.at}

Abstract—Transportation systems represent the backbone ofmanufacturing systems and significantly influence their efficiency.Component failures or disturbances generally lead to trafficjams decreasing thereby the throughput and system performanceif not even completely interrupt the production process. Tocope with such situations, recently a multi-agent system for thetransportation domain with capabilities for reconfiguration andadaptive routing has been introduced.

The main contribution of this paper is to present the imple-mentation of this multi-agent system on a real pallet transportsystem. The results of the experiments show the feasibility ofthe approach on a real manufacturing system and its capabilityfor enhancing the system’s fault tolerance preventing thereby asignificant loss of production performance.

I. INTRODUCTION

Transportation systems are regarded as the backbone ofmanufacturing systems and offer many possibilities for capac-ity optimization. They can significantly influence the efficiencyof the overall system [1]. The occurrence of traffic jams,caused by component failures or disturbances, may lead to adeviation from the initial production schedule, to degradationsof the system performance or, in the worst case scenario,may even interrupt the production process. Furthermore, thiscan significantly increase production costs and consequentlylower the economical competiveness of the product on themarket. Due to this reason there is an increasing demandfor more flexibility and reconfigurability in routing processes,which however significantly complicates the control of thosesystems. Nowadays the typical approach used in factories isa centralized global routing control with standardized pathplanning algorithms calculating all possible routing pathsin advance. This is required as the programming languagesfor programmable logic controllers (PLCs) are generally notdesigned for carrying out such complex computations as pathplanning during operation [2].

The technology of multi-agent systems has been recognizedas a powerful tool for developing highly flexible, robust,and reconfigurable industrial control solutions [3]. However,although confirmed as a promising approach and deployed in anumber of different applications throughout the last few years,the widespread adoption of agent-based concepts by industryis still missing. Lack of awareness about the potentials ofagent technology [4] and paradigm misunderstanding [5] due

to the lack of real industrial applications, missing trust in theidea of delegating tasks to autonomous agents [6] as well as a“pioneer” risk, which accompanies every new technology thathas not been proven in large scale industrial applications [7],are the main hindering factors for preventing the widespreadadoption of agent technology in the manufacturing domain.

For showing the feasibility and benefits of multi-agentsystems on real systems, this paper presents the outcomeof long-run tests of a multi-agent system implemented ona transportation system. In order to measure the system’sagility—the capability to react in a short period of time on theoccurrence of unexpected disturbances—as well as introducedreconfiguration advantages the loss of productivity in thepresence of disturbances is analyzed. The target transportationsystem at which the developed multi-agent system is imple-mented and tested in reality is the “Testbed for DistributedControl”.

This paper is structured as follows. Section II discussesrelated works. In the third section we present in detail the con-trol architecture introducing the target system, the automationagents and their capability for system reconfiguration. SectionIV describes the test cases and Section V discusses the results.Finally the paper is concluded in the sixth section.

II. RELATED WORKS

Recent works address the problem of building confidencein agent-based systems with particulars techniques basedon testing and monitoring or on simulation. An autonomicmanagement execution system (MES) based on agents wasdesribed by Rolon and Martınez [8]. The MES was operatedin a simulation environment for the production of numerousproducts using several reactor tanks and packaging units.The simulation results showed that the agent-based MESwas able to keep the processing times of frequent orderswithin acceptable boundaries despite the failure of a brokenpackaging unit by rescheduling the orders to the remainingunits using different strategies.

Bussmann and Schild reported the development of a flexibletransportation system with an associated agent-based con-trol within the frame of the Production 2000+ project [9].The overall goal of the system is to continuously optimizethe throughput while machine agents manage buffer sizes,

workpiece agents manage the processing state of a specificworkpiece and shifting table agents try to optimize the routing.The system has been evaluated in a series of simulationsbased on real manufacturing data (product types, processingtimes, disturbance characteristics, etc.). The simulations haveshown that the agent-based control is extremely robust againstdisturbances of machines as well as failures of control unitsachieving a performance near to the theoretical optimum.Moreover, the control system has been installed in the Daimlerplant in Stuttgart validating the results of the simulations underreal manufacturing conditions.

Another successful deployment of a multi-agent system byRockwell Automation was the distributed control of a chillwater system applied to reduce the manning as well as toimprove readiness and survivability of US Navy shipboardsystems [10]. A simulation environment as well as physical,table-top demonstrator was built in the Rockwell Automationresearch laboratories in Cleveland for testing the system’sfunctionality in a set of scenarios that mimic the transactionsof the real shipboard systems. The successful deploymentof the Manufacturing Agent Simulation Tool (MAST) on asmall scale transport system was reported by Vrba et al. [11]This conveyor system is used to transport palettes carryingraw materials or products between docking stations, wherethe palettes are held until a particular manufacturing processfinishes. The palettes are routed by the diverters that usereachability knowledge to send the palette to the requireddocking station at the lowest cost, i.e. using the shortestpossible path.

Besides the fact that the multi-agent systems presentedabove were implemented and their routing abilities testedin a real system presenting the advantages of the approach,a missing point is that these systems did not tackle anyreconfiguration issue. The capability of the system to performa reconfiguration of the control software in conjunction witha physical reconfiguration of the system in order to achievefunctionality and efficiency is of vital importance. In previouswork an agent-based approach combining local reconfigura-tion of control software with ontology-driven reasoning forimproving performance and fault-tolerance was presented [12].Ontologies are used to ensure the shared understanding amongagents when exchanging information about their activities,which in this case directly reflects the configuration of theircontrol software. Two simulation experiments were performedto analyze the impact of this approach on a transportationsystem’s performance. In the first one only one agent, whichis controlling an intersection, performs local diagnostics andreconfiguration. The second experiment analyzes the impactof local reconfiguration on the functionality of the globalsystem. The results of the experiments in the simulationunderline the increased reconfigurability, agility, robustnessand fault tolerance of the transportation system based onagent technology. To show the feasibility and benefits of thisapproach on a real system, the experiments presented andevaluated in this paper represent the logical next step aftersimulation.

Fig. 1. Picture of the pallet transport system.

III. CONTROL ARCHITECTURE

The following sections introduce the target system and theapplied control strategy using automation agents and theircapability for reconfiguration.

A. Testbed for Distributed Control

The “Testbed for Distributed Control”, located at the OdoStruger Laboratory of the Automation and Control Institute(ACIN), Vienna University of Technology, acts as the targetsystem for the implementation and the performed tests. Thetestbed comprises workstations such as an industry robot, anautomatic storage system with a handling unit for extractingparts and a portal robot for assembly tasks as well as apallet transport system with redundant paths encompassing 45conveyors with 32 intersections and a set of indexstations withgrippers for holding pallets (see Figure 1).

Within this system, the major transport tasks are the de-livery of a part from the storage to a machine, to carry anunfinished sub-assembly between the machines, and to removethe finished product from the system. A main objective is totransport pallets between index stations in a minimum amountof time, usually following the shortest path and avoidingbroken components and congested ways. As the presented testswere focused on the routing of pallets, only the pallet transportsystem is described in the following in more details.

The main mechatronic components of the pallet transportsystem are:

• Conveyor belts, which move pallets from one place toanother.

• Indexstations, which comprise a gripper for holding apallet in a defined position, so that a workstation canprocess its content.

• Intersections, which represent a connection between sev-eral conveyors. Depending on the direction of its adjacentconveyors, an intersection operates either as a diverter,which receives pallets from one input conveyor and routes

Physical Layer

Functional Layer

Automation Agent

Automation Agent

Automation Agent

Automation Agent

A

B

Work AgentA

B

Work Agent

Order AgentContact Agent

Directory Facilitator

Fig. 2. Agent types of the multi-agent system.

them to one of its output conveyors according to theirtarget destinations, or as a junction, which receives palletsfrom two input conveyors and feeds them to one outputconveyor according to their priorities.

The indexstations and intersections also incorporate sensorsfor detecting pallets and blockers for stopping them. Toidentify the pallets and their destinations, the indexstations andintersections rely on Radio Frequency Identification (RFID)tags, which are accessed through RFID readers. Furthermore,grippers, switches and blockers are equipped with sensors forverifying their momentary state.

A set of 38 embedded controllers of the type CPX-CEC-C1by Festo is employed to control the indexstations and inter-sections as well as the conveyors. Each controller comprisesan Xscale-PXA255 agile Intel microprocessor with 400MHz,28 MB Flash and 24 MB RAM and several I/O-modules(digital inputs, digital outputs and valves) for connecting thesensors and actuators. On the contrary, every RFID moduleis controlled by a small embedded controller of the type DigiConnect ME.

B. Automation Agents and the Multi-Agent System

The multi-agent system controlling the testbed is based onthe Jade [13] platform for agent management and inter-agentcommunication. The system is divided into two layers: thefunctional layer and the physical layer (see Figure 2). Thefunction layer contains a set of different functional agents,which carry out higher level functions such as system manage-ment (contact agent), the scheduling of jobs (order agent) orthe distribution of tasks (work agent). To avoid bottlenecks, thefunctional agents may also exist in redundant forms. Detailedinformation about the provided functionality of these higherlevel agents can be found in [4], [14].

Each component such as an intersection is represented andcontrolled by an automation agent and thereby embeddedinto the multi-agent system in its physical layer. Accordingly

High Level Control (HLC)

Low Level Control (LLC)

Software Component

Automation Agent

Physical Component

FB_Sensor FB_Diverter

FB_Blocker

FB_Switch

Intersection

OutputConveyor

InputConveyor

Pallet

Fig. 3. Architecture of an Automation Agent.

the physical component can be regarded as each agent’sembodiment and the software acts as the agent’s intelligence.The automation agents register their offered services to afunctional agent of the type directory facilitator.

To facilitate the design of a multi-agent control system inthe manufacturing domain, a generic agent architecture forthe automation agents was introduced [15]. As can be seenin Figure 3, this architecture clearly separates the controlsoftware into the high level control (HLC) and the lowlevel control (LLC) as it is widely agreed to split agent-based manufacturing control into these two layers [16]. Forthe communication between the two layers an interface wasdeveloped to easily exchange data [17].

The HLC, implemented in JavaTM, controls the behavior ofthe automation agent in conjunction with the other agents ofthe system. It comprises a world model repository for storing asymbolic representation of the surrounding environment. Theworld model is used by the agent to reason about the states ofthe world and to perform diagnostic tasks by detecting incon-sistencies with the information received from the environment(i.e. sensors and other agents). In general the world model isupdated after recognizing changed world conditions or afterperforming actions. The well-disposed reader may find moredetails about the world model in [15].

The hardware-near LLC provides the basic functionality ofa component, i.e. routing a pallet in the case of an intersectionoperating as a diverter, and has access to the sensors andactuators. It comprises a limited set of reactive behaviors,collects and processes the information from sensors and basedon the result performs particular actions or informs the HLCabout significant events. The LLC was developed using the4DIAC-IDE [18] for designing control applications based

on the industrial standard IEC 61499 [19]. Both the FestoCPX and Digi Connect ME controllers host instances of theFORTE, which is a small portable C++ runtime environmentfor running IEC 61499 applications on embedded controldevices.

C. System Reconfiguration

Based on Dijkstra’s algorithm [20], a shortest path algorithmwas implemented, which is used for calculating routing tablesfor each intersection [21]. Furthermore, an algorithm wasdeveloped which is used by higher level agents of the typecontact agent (CA) for estimating the reachability of alldestinations (i.e. in general the workstations for manipulatingthe pallets’ loads) in the system which is important in thecase of component breakdowns. In the case of unreachabledestinations, this so-called change direction algorithm (CDA)determines necessary direction changes of specific conveyors[22].

In the case of failures, such as a breakdown of a componentor a stuck pallet inside an intersection, the system reacts asfollows:

1) The failure is detected either by the automation agent’sLLC using the sensors or by the HLC using its worldmodel for determining inconsistencies [23].

2) Based on the given information the automation agentinforms a CA which starts the CDA and compares itsresults with the actual system state.

3) In the case that the CDA recommends a new configura-tion, the CA updates its ontology, requests the automationagents of the concerned conveyors to change their direc-tions and informs the adjacent intersection automationagents to update their world model.

4) After updating their world model, the intersection au-tomation agents start reconfiguration mechanisms foradjusting the components’ functionality according to thenew conditions (e.g. a junction now becomes a diverter)[24].

5) According to the changed conveyor directions, the routingtables of the intersection automation agents are updatedto route pallets to their appropriate output conveyors.

IV. TEST CASES

In order to investigate the effectiveness of the systemreconfiguration using the CDA and local reconfiguration ofcontrol software in the case of a detected failure, a set ofexperiments with the pallet transport system is conducted.The process flow for the performed tests consists of twoprocess steps. At first the pallets start at a workstation atindexstation D1 where they have to be processed for a periodof 10 seconds. As a second step they need to be processed atanother workstation at a different indexstation D2 for a longerperiod than at D1, which is 20 seconds. In order to avoid abottleneck at this second workstation, a redundant workstationis used at indexstation D3 within the testbed. Hence, each ofthe redundant two workstations only needs to process half ofthe pallets in the system. After the second step, each pallet

CC3

CC3

CC3

CC3

CC3

CC3

Fig. 4. Layout of the pallet transfer system.

shall return to the workstation at D1 to start another processcycle.

Three test cases are performed with a number of 10 palletsin the system:(a) Test case without conveyor failures: All destinations are

reachable. Figure 4a shows the shortest paths the palletsshould take. At D1, half of the pallets receives D2 as nextdestination while the other half is sent to D3. Therefore,those pallets with D2 as next destination should follow thegreen path and afterwards return to D1 along the shadedgreen path. On the other hand, those pallets with D3 asnext destination should follow along the red path to D3to return afterwards along the shaded red path to D1.

(b) Test case, when one critical conveyor fails: IndexstationD2 is not reachable. Hence, all pallets need to be sent toD3 after being processed at D1. It can be seen in Figure 4bthat both the green and red path are similar as all palletshave to move from D1 to D3 and back.

(c) Test case, when one critical conveyor fails but a resolvingsolution is found by the system: The system is recon-

0

50

100

150

200

250

300

0

50

100

150

200

250

300

a b c a b c a b c a b c

Duration [s]

D1 ‐> D2            D2 ‐> D1            D1 ‐> D3            D3 ‐> D1

Fig. 5. Path durations for all test cases.

figured using the CDA and indexstation D2 is thereforeaccessible again. Figure 4c shows that the red path forone half of the pallets to indexstation D3 and back isunchanged, but the green path to indexstation D2 and backto D1 for the other half of the pallets is different and abit longer compared to the one in test case (a).

The following assumption is defined in the context of theperfomance tests: Applying the CDA and system reconfigu-ration mechanisms enhances fault tolerance in the case of acomponent failure leading to a throughput comparable to thecase without failures.

V. DISCUSSION OF RESULTS

In order to gain measurement data, all indexstations log theprocessed pallets using their ID and a time stamp. This allowsthe calculation of the following characteristic numbers:

• Throughput per hour, which represents the number ofproduced products per hour in the manufacturing system;

• Duration of a complete process cycle starting at indexs-tation D1 until a pallet returns to D1 for beginning thenext process cycle;

• Travel duration on a path from one indexstation to aparticular other indexstation, which includes also waitingtimes at intersections and indexstations due to otherpallets.

Figure 5 depicts the travel time of the pallets between theindexstations representing therefore the duration of the pathsfor all test cases. Each grey bar represents the average durationof a certain path (e.g. the path from D1 to D2) for a giventest case. The vertical black stroke shows the spread fromthe minimum to the maximum value and the small horizontalblack stroke represents the median value of a path’s duration.

It can be seen that in test case (a) the returning path fromD2 and D3 to D1 takes in average a longer time of about 20seconds. This can be explained with occuring traffic jams atD1 when pallets return from D2 and D3 at the same time.

As indexstation D2 is not reachable in test case (b), thereis no data concerning paths to and from D2. The duration forthe path from D1 to D3 is obviously significantly longer thanin the other test cases. This is evident, as D3 represents abottleneck in this test case due to the longer processing time

0

50

100

150

200

250

300

350

a b c

Average du

ratio

n [s]

0

20

40

60

80

100

120

140

160

a b c

Throughp

ut per hou

r

a) b)

Fig. 6. Average duration of a process cycle (a) and throughput per hour (b)for all test cases.

leading therefore to serious traffic jams. On the other hand,the return path to D1 takes in average a slightly shorter timethan in test case (a) as the pallets return from D3 with enoughtime difference leading therefore to no traffic jams at D1.

As the path in test case (c) from D1 to D2 is longer, so isthe travel time, which can be clearly seen in the diagram. Thepath from D1 to D3 takes roughly the same time as in testcase (a). However, the returning paths from D2 and D3 to D1are slightly shorter, which might be explained by less trafficjams at D1 due to a longer path to D2 resulting in a betterdistribution of the pallets on the testbed.

Figure 6a shows the average duration of one process cyclefor 10 pallets which encompasses travel times and processingtimes. While in test case (a) the processing time is in average260.7 seconds, test case (b) reveals a processing time of 308.7seconds resulting therefore in an increase of 18.4%. Due tothis, the average throughput per hour with 10 pallets dropsfrom 138.1 pieces to 116.6 pieces as can be seen in Figure 6b,which is a loss of 15.6%.

On the other hand when the system is reconfigured by theagents to restore the reachability of D2, one process cycletakes in average 264.4 seconds, which is an increase of only1.4% compared to the failure free test case (a). With 136pieces per hour the throughput is correspondingly a bit lowercompared to test case (a) by only 1.4%. Thus, the applicationof our approach significantly improves the system efficiencycompared to a conventional system without reconfigurationcapabilities. Therefore, the assumption stated at the end ofSection IV is confirmed by the measurements performed onthe real system.

However, evidently the results depend on certain systemparameters. As mentioned in Section IV, the processing timeat D1 is 10 seconds while at D2 and D3 it is 20 seconds.Tests with shorter processing times result in only rare trafficjams for the test cases (a) and (c) when pallets return toD1 at the same time and no traffic jams in test case (b).Hence, in this case a better routing strategy would be to send

all pallets to only one of the redundant workstations for thesecond process step. For 10 pallets, the size of the testbedis large enough so that the pallets are evenly distributed onthe paths between two indexstations. However, in the case ofmore pallets in the system, traffic jams would certainly occurat single workstations despite the small processing time.

On the other hand a longer processing time than the onein the given test cases will likely lead to more traffic jams.Hence, in such a case the availability and reachability of aredundant workstation is of utmost importance to keep up thesystem’s throughput.

VI. CONCLUSION

This paper presents the implementation and evaluation ofa multi-agent system on a real pallet transport system. Theautomation agents are able to observe their environment byusing information from sensors or from other agents of thesystem. Hence, failures can be detected by the agents and dueto the conjunction of local reconfiguration of control softwarewith agent technology, the system is able to react adequatelyon these disturbances.

The results of the experiments clearly show the benefits ofthe multi-agent system in the case of a conveyor breakdown.Identifying an alternative route and reconfiguring the systemaccordingly results in a better performance for most cases.However, if the processing time is too short and the numberof pallets in the system is rather small, jams will not occureven though certain destinations of the system are unreachablemaking therefore such a reaction obsolete. On the contrary, inthe case of an unreachable system part and longer processingtimes or a higher number of pallets, a direction change ofa conveyor significantly increases the performance back tothe failure free case due to the regained reachability of thosedestinations.

Further research work will be concerned with using likewisemechanisms for avoiding traffic jams even in a failure freecase by routing pallets on alternative routes or by changingconveyor directions to enable such routes. Also, the distribu-tion of pallets to redundant workstations could be optimizedto increase the throughput of the system. It is also planned toadapt the previously used simulation environment to the actuallayout of the testbed to carry out further long-run simulationexperiments and compare their results with the outcome of thework presented in this paper.

ACKNOWLEDGMENT

The authors acknowledge the financial support from theBRIDGE program by the Austrian Research PromotionAgency under contract FFG 829576 as well as from the Euro-pean Community’s Seventh Framework Program (FP7/2007-2013) under grant agreement No. 284573.

REFERENCES

[1] M. D. Byrne and P. Chutima, “Real-time operational control of anfms with full routing flexibility,” International Journal of ProductionEconomics, vol. 51, no. 1-2, pp. 109–113, 1997.

[2] P. Vrba and V. Marık, “Capabilities of Dynamic Reconfiguration ofMultiagent-Based Industrial Control Systems,” IEEE Transactions onSystems, Man and Cybernetics, Part A: Systems and Humans, vol. 40,no. 2, pp. 213–223, 2010.

[3] P. Leitao, “Agent-based distributed manufacturing control: A state-of-the-art survey,” Engineering Applications of Artificial Intelligence,vol. 22, no. 7, pp. 979–991, Oct. 2009.

[4] M. Merdan, “Knowledge-based Multi-Agent Architecture Applied inthe Assembly Domain,” PhD Thesis, Vienna University of Technology,2009.

[5] G. Candido and J. Barata, “A Multiagent Control System for Shop FloorAssembly,” in 3rd International Conference on Industrial Application ofHolonic and Multi-Agent Systems, 2007, pp. 293–302.

[6] K. P. Sycara, “Multiagent Systems,” AI Magazine, vol. 19, no. 2, pp.79–92, 1998.

[7] M. Pechoucek and V. Marık, “Industrial deployment of multi-agenttechnologies: review and selected case studies,” Autonomous Agents andMulti-Agent Systems, vol. 17, no. 3, pp. 397–431, 2008.

[8] M. Rolon and E. Martınez, “Agent-based modeling and simulation ofan autonomic manufacturing execution system,” Computers in Industry,vol. 63, no. 1, pp. 53–78, 2012.

[9] S. Bussmann and K. Schild, “An agent-based approach to the controlof flexible production systems,” in Proc. of the 8th IEEE Int. Conf. onEmergent Technologies and Factory Automation (ETFA 2001), 2001, pp.488, 481.

[10] F. P. Maturana, P. Tichy, P. Slechta, F. Discenzo, R. J. Staron, andK. Hall, “Distributed multi-agent architecture for automation systems,”Expert Systems with Applications, vol. 26, no. 1, pp. 49–56, 2004.

[11] P. Vrba, V. Marık, and M. Merdan, “Physical deployment of agent-based industrial control solutions: MAST story,” in Proceedings of theIEEE International Conference on Distributed Human-Machine Systems,Athens, Greece, 2008.

[12] M. Vallee, M. Merdan, W. Lepuschitz, and G. Koppensteiner, “Decen-tralized Reconfiguration of a Flexible Transportation System,” IEEETransactions on Industrial Informatics, vol. 7, no. 3, pp. 505–516, 2011.

[13] “Jade - Java Agent Development Framework,” access date September2012. [Online]. Available: http://jade.tilab.com

[14] M. Merdan, T. Moser, P. Vrba, and S. Biffl, “Investigating the robustnessof re-scheduling policies with multi-agent system simulation,” Interna-tional Journal of Advanced Manufacturing Technology, vol. 55, no. 1–4,pp. 355–367, 2011.

[15] M. Vallee, H. Kaindl, M. Merdan, W. Lepuschitz, E. Arnautovic, andP. Vrba, “An Automation Agent Architecture with A Reflective WorldModel in Manufacturing Systems,” in IEEE International Conferenceon Systems, Man, and Cybernetics, San Antonio, Texas, USA, 2009,pp. 305–310.

[16] J. Christensen, “HMS/FB architecture and its implementation,” in Agent-based manufacturing: Advances in the Holonic Approach, S. M. Deen,Ed. Springer-Verlag, Berlin, Germany, 2003, pp. 53–88.

[17] W. Lepuschitz, M. Vallee, M. Merdan, P. Vrba, and J. Resch, “Integrationof a Heterogeneous Low Level Control in a Multi-Agent System for theManufacturing Domain,” in IEEE International Conference on EmergingTechnologies and Factory Automation, 2009, pp. 1–8.

[18] 4DIAC-Consortium, “4DIAC - Framework for Distributed IndustrialAutomation and Control, Open Source Initiative,” access date September2012. [Online]. Available: http://www.fordiac.org

[19] IEC 61499-1, Function blocks – Part 1: Architecture. Geneva:International Electrotechnical Commission, 2005.

[20] E. W. Dijkstra, “A note on two problems in connexion with graphs.”Numerische Mathematik, vol. 1, p. 269271, 1959.

[21] M. Merdan, G. Koppensteiner, I. Hegny, and B. Favre-Bulle, “Appli-cation of an ontology in a transport domain,” in IEEE InternationalConference on Industrial Technology, 2008, pp. 1–6.

[22] G. Koppensteiner, M. Merdan, I. Hegny, and G. Weidenhausen, “Achange-direction-algorithm for distributed multi-agent transport sys-tems,” in IEEE International Conference on Mechatronics and Automa-tion, 2008, pp. 1030–1034.

[23] M. Merdan, M. Vallee, W. Lepuschitz, and A. Zoitl, “Monitoring anddiagnostics of industrial systems using automation agents,” InternationalJournal of Production Research, vol. 49, no. 5, pp. 1497–1509, 2011.

[24] W. Lepuschitz, A. Zoitl, M. Vallee, and M. Merdan, “Towards self-reconfiguration of manufacturing systems using automation agents,”IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applica-tions and Reviews, vol. 41, no. 1, pp. 52–69, 2011.