Design and implementation of a distributed part-routing algorithm for reconfigurable transportation systems

This article was downloaded by: [Consiglio Nazionale delle Ricerche]On: 17 July 2015, At: 09:48Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: 5 Howick Place,London, SW1P 1WG

Click for updates

International Journal of Computer IntegratedManufacturingPublication details, including instructions for authors and subscription information:http://www.tandfonline.com/loi/tcim20

Design and implementation of a distributed part-routing algorithm for reconfigurable transportationsystemsEmanuele Carpanzanoa, Amedeo Cestab, Andrea Orlandinib, Riccardo Rasconib, MarcoSurianob, Alessandro Umbricobc & Anna Valentea

a SUPSI, Institute of Systems and Technologies for Sustainable Production, Manno,Switzerlandb Institute of Cognitive Sciences and Technologies, National Research Council of Italy (CNR-ISTC), Rome, Italyc Department of Engineering, Roma TRE University, Roma, ItalyPublished online: 17 Jul 2015.

To cite this article: Emanuele Carpanzano, Amedeo Cesta, Andrea Orlandini, Riccardo Rasconi, Marco Suriano, AlessandroUmbrico & Anna Valente (2015): Design and implementation of a distributed part-routing algorithm for reconfigurabletransportation systems, International Journal of Computer Integrated Manufacturing, DOI: 10.1080/0951192X.2015.1067911

To link to this article: http://dx.doi.org/10.1080/0951192X.2015.1067911

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) containedin the publications on our platform. However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of theContent. Any opinions and views expressed in this publication are the opinions and views of the authors, andare not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon andshould be independently verified with primary sources of information. Taylor and Francis shall not be liable forany losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoeveror howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use ofthe Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

Design and implementation of a distributed part-routing algorithm for reconfigurabletransportation systems

Emanuele Carpanzanoa, Amedeo Cestab, Andrea Orlandinib, Riccardo Rasconib, Marco Surianob, Alessandro Umbricob,c

and Anna Valentea*aSUPSI, Institute of Systems and Technologies for Sustainable Production, Manno, Switzerland; bInstitute of Cognitive Sciences andTechnologies, National Research Council of Italy (CNR-ISTC), Rome, Italy; cDepartment of Engineering, Roma TRE University, Roma,

Italy

(Received 19 April 2014; accepted 31 May 2015)

The reconfigurability feature represents an instrumental characteristic for manufacturing systems that are required tofrequently adapt the architecture and functionalities to match evolving production environment where changes of productvariants and demand volumes frequently occur. Transportation systems embrace a major industrial application of thereconfiguration concept. Reconfigurable transportation systems (RTSs) are conceived as multiple independent modules toimplement alternative inbound logistic systems’ configurations. Together with mechatronic interfaces and distributedcontrol solutions, the full exploitation of reconfigurability strategies for transportation systems relies upon flexible produc-tion management policies. This enables the dynamic computation of part routings in RTSs after every reconfiguration andchange in the way transportation modules are exploited. The current work proposes an innovative agent-based algorithmthat combines global and local optimisation criteria to manage the part flow in RTS. The proposed approach is designed asfully distributed across transportation modules; based on current RTS’ topology and status, it ensures the autonomy inselecting routing decisions while embracing global and local evolving optimisation strategies. The benefits of the approachhave been investigated with reference to a set of realistic RTS topologies exhibiting different routing options, in order toassess the algorithm under different part-routing conditions.

Keywords: reconfigurable transportation system; part routing; auctioning algorithm

1. Introduction

The ability to match frequent product modifications andshorter product life cycles asks manufacturers to invest incompetitive factors such as short lead time, high quality ofproducts, reactivity to market-frequent changes and cost-effective production. Such objectives profoundly drive thenature of production systems, forcing their level of agilityand responsiveness to be directly proportional to the evol-ving pace of the production requirements to be accom-plished. Reconfigurable manufacturing systems (RMSs)could represent a viable solution to competitively operatein such dynamism (Koren, Hu, andWeber 1998; Koren et al.1999; Matta, Tomasella, and Valente 2007, Zhang and VanLuttervelt 2011). They are equipped with a set of reconfigur-able enablers (Koren and Shpitalni 2010) that can be relatedeither to the single component of the system (e.g. the mecha-tronic device, a machine tool spindle or fixturing system) orto the entire production cell and system layout (the systemtransportation system or machine topology). In this regard,the role of each enabler is to implement the correct systemreconfiguration in response to changes of the productionrequirements. In particular, reconfigurable transportationsystems (RTSs) play an instrumental role in empowering

manufacturing systems with the capability to adapt theirarchitecture and functionalities to evolving production envir-onments. Frequently, systems are upscaled or downscaled byintegrating, substituting or dismissing new devices such asmachines and robots, thus requiring a major change of theshop-floor layout and resource topological allocation. Suchmodifications can be robustly accomplished if the transpor-tation system is modular and reconfigurable. Moreover, rely-ing upon an RTS constitutes an instrumental key toefficiently manage changes in the production volumes sothat, for example a decreasing production demand corre-sponding to less parts circulating in the system could behandled by downscaling the transportation modules, conse-quently reducing the part transportation time.

RTSs’ ability to change the transportation layout, func-tionalities and logics – with no need to integrate new equip-ment or reprogramming the transportation control set-points– is ensured by conceiving RTS as an integration of auton-omous modules equipped with reconfiguration enablers (Ko,Hu, and Huang 2005; To and Ho 2002; Kuruvilla, Gokhale,and Sastry 2008). The modules of RTSs are designed asmechatronic devices equipped by standard interfaces to con-nect to each other, and by an embedded logic controller

*Corresponding author. Email: [email protected]

International Journal of Computer Integrated Manufacturing, 2015http://dx.doi.org/10.1080/0951192X.2015.1067911

© 2015 Taylor & Francis

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

which: (i) controls the module motion motor, (ii) reads anumber of proximity sensors indicating the presence andposition of parts circulating on the module and (iii) polls aseries of sensors indicating the nesting of modules’ extremi-ties to other modules. Every module is labelled with anumber of information such as the identification code,mean time to failure and possibly the history of the main-taining interventions executed in the past so as this informa-tion can be exchanged with other modules (Koren et al.1999; Koren and Shpitalni 2010).

The design and realisation of RTS requires three majorchallenges to be addressed (Carpanzano et al. 2014). Thefirst challenge refers to the development of transportationmodules that are reconfigurable from the hardware per-spective; this implies the design standard mechatronicinterfaces and multiple mechatronic configurations whoserobustness and accuracy is function of the manufacturingapplication and where the majority of plugging principlesare inspired by some industrial challenging applications ofthe reconfigurability concepts developed by machine toolbuilders such as Mori Seki, Panasonic, Zevac; providers ofrobotic solutions such as Schunk, Kuka, Mitsubishi,Robotnik; and modular equipment providers such asFlexlink and Festo. The second challenge concerns thedesign and development of distributed control and sensingsolutions where both the physical controllers and the con-trol functions reside in the autonomous mechatronicdevices such as the transportation modules (Carpanzanoet al. 2012). Similarly to the standard mechanical inter-faces, the control blocks embedded in every module mustrely upon a unique vocabulary and standard communica-tion protocols, while the control logics and algorithmsshould concurrently allow the discovery of new entities,the interpretation of their functionalities and the coordina-tion and adaptation of the module operating mode (Hegnyet al. 2008; Valente and Carpanzano 2011). The thirdchallenge concerns the production management policiesassociated to RTSs, particularly regarding part routings,fixturing and pallets; production control as well as therelated scheduling and dispatching policies; and the plan-ning of maintenance initiatives (Lee, Kumara, andChatterjee 2003; Duffie and Kaltjob 1998, Van Brussel1990, Rasconi, Cesta, and Policella 2010). When designedfor RTS, these production management policies requiremethodologies capable of adapting to the initial architec-ture of the inbound logistic system, as well as to themodifications of the reference layout as a result of possiblereconfigurations. The capability of parts and auxiliaries toreach a specific machine in a certain time in order toexecute the requested operations depends on the currenttransportation system layout. As the transportation systemreconfiguration is particularly efficient in terms of tem-poral effort associated to the set-up and ramp-up, it cannotsuffer inefficient production management tools whoseexecution represents a bottleneck. At the same time, static

routing policies generating predetermined paths for theparts in very short time, base the solution generation onthe assumption the transportation layout does not change.Thus, a fundamental requirement for RTSs in order toeffectively operate in a dynamic production environmentis to be empowered by real-time production managementsoftware capable of dynamically accomplishing the pro-duction targets while considering the occurring reconfi-gurations. This requires the production managementmethodologies to be (i) distributed across the RTS mod-ules and (ii) nested to the modules’ control layers(Carpanzano et al. 2012).

The current work focuses on the problem of generatingdynamic and adaptable part-routing policies for RTSs bypresenting a distributed part-routing approach inspired byadvanced auctioning techniques (Bertsekas 2001). Theprevious problem is solved through the employment of adistributed algorithm where the responsibility of the part-routing decisions is shared among all the transportationcomponents of the RTS. More precisely, the proposedsolution is designed to be embedded in all mechatronicmodules composing the RTSs, in order to provide themwith suitable autonomy features to decide whether to takepart in a certain transportation path and/or negotiate therouting policies, depending on the specific goals whilemaintaining full awareness of the surrounding productionenvironment. Together with the distribution feature, majoradvantages of the proposed approach are (i) the reconfi-gurability to face different RTS layouts and/or differenttransportation functionalities of single entities, (ii) thescalability to adapt to a variable number of modules andmultiple RTS layouts, (iii) the integration of local andglobal optimisation strategies and, finally, (iv) the supportof RTS design by means of a virtual assessment processfor the transportation system behaviours. The effective-ness of the solution proposed in this work is confirmed bya set of experiments where the performances (i.e. through-put, lead time, anomaly recovery abilities) of our auction-based part-routing algorithm are assessed against anumber of RTS layouts exhibiting different routingcharacteristics.

The rest of the paper is structured as follows: Section 2provides an analysis of the current state of the art, whereasSection 3 outlines the proposed approach together with itsanalytical formulation. Subsequently, Section 4 describesthe reference benchmark use cases, the experimental cam-paign and the results; some concluding remarks end thearticle.

2. Related work

The exploitation of part-routing policies for RTSs isenabled by a distributed control system and efficient rout-ing algorithms. The first aspect ensures the autonomy incontrolling the RTS modules while managing the part

2 E. Carpanzano et al.

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

flow; the second aspect is instrumental to efficiently pro-cess parts while concurrently having a global and localunderstanding of the system behaviour. With regard tothese two research topics, the current section overviewssome of the more important related works available in theliterature.

The traditional approach to manufacturing control sys-tems, based on centralised/hierarchical control structures,presents good performance in terms of productivity over arestricted and specific product range, essentially due to itsintrinsic optimisation capabilities. However, when dynamicand adaptive response to change is needed for competitive-ness, traditional approaches to manufacturing control typi-cally fall into large monolithic software packages, manuallydeveloped and adapted case by case, requiring a huge andexpensive effort to implement, maintain or reconfigure thecontrol application. They result to be not adequate as they donot support efficiently the current requirements imposed tomanufacturing systems, namely in terms of flexibility,expansibility, agility and reconfigurability. Current chal-lenges deal with the development of manufacturing controlsystems that exhibit distributed intelligence, robustness andadaptation to the environmental changes and disturbances(Qiao and Zhu 2001; Valente, Mazzolini, and Carpanzano2015). Two paradigms integrate and complement tacklingthis issue: holonic manufacturing systems (HMS) and agenttechnology. Holonic manufacturing is characterised byautonomous and cooperative entities, called holons, whichrepresent the entire range of manufacturing entities (VanBrussel et al. 1998; Valckenaers and Van Brussel 2005). Inthis regard, there are still some important issues that remainopen, regarding the global optimisation in decentralised sys-tems, the evolution of the production control structure toadapt to change, the formal specification of the dynamicbehaviour of holonic systems, the introduction of learningand self-organisation capabilities, the automatic integrationof resources and the development of holonic-based controlapplications.

The introduction of multi-agent paradigm addressesthese requirements, bringing the advantages of modularity,decentralisation, autonomy, scalability and re-usability.The definition of agent concept is neither unique norconsensual (Ferber 1999; Wooldridge 2002). The mostimportant properties of an agent are the autonomy, intelli-gence, adaptation and co-operation (Heragu et al. 2002;Babiceanu et al., 2004; Vrba 2005).

However, only few industrial/laboratorial applicationswere developed and reported in the literature. InBussmann, Jennings, and Wooldridge (2004) and Schildand Bussmann (2007) agent technology is utilised todesign a flexible and robust production system in a factoryplant of DaimlerChrysler, producing cylinder heads forfour-cylinder diesel engines (AgentLink 2005). The adap-tive holonic control architecture (ADACOR) for distribu-ted manufacturing systems (Leitãoa and Restivob 2006) is

an example of architecture combining the holonic- andagent-based approaches. In Borgo et al. (2014), an adap-tive control infrastructure has been proposed in which theproduction environment is modelled as a community ofautonomous, self-declaring and collaborating entitiesencapsulated in the physical mechatronic equipment.Then, the reconfigurability concept is applied to both thelogic and physical aspect of control. Logic reconfigura-tions can result from the need to adjust the control func-tionalities and policies as a consequence of a productionchange (e.g. new part type), an event affecting the physi-cal equipment (e.g. anomalous behaviours) or a change inthe production goals (e.g. minimisation of energy con-sumption vs. minimisation of idle times). Physical recon-figurations imply that the control physical device and therelated control software will manage modifications of thecontrol system, such as entity insertions or removals. Thisrequires a more complex reconfiguration process whoseanalysis goes beyond the scope of this paper.

As a matter of fact, an extensive adoption of agent-basedtechnology is still severely limited by organisational andtechnical obstacles (Wooldridge 1999; Weyns, Parunak,and Shehory 2008). In the organisational world, agent-based technology proves – to some extent – to be still atthe academic level and industrially quite immature due to thelack of focus and misperceptions of real industrial problems.On the other hand, the technical area has also its own limita-tions. First, the immaturity of agent technology and the biggap between the theory and concrete usable assets, whichmakes it difficult to develop real solutions. Second, theexisting agent-based platforms are too tight to agent theory,though a promising trend to connect them to the softwareengineering mainstream has already been started(Zambonelli and Omicini 2004). Another obstacle is thelack of integration with general-purpose technologies typi-cally employed in the industrial environments, like legacysystems, frameworks, etc. The last obstacle is the limitedscope of programming languages: software developers are inneed of adequate programming languages, without whichtechnology adoption is practically infeasible.

Alternative approaches to be considered in dealingwith reconfigurable control solutions rely upon the webservice-based technologies (Cucinotta et al. 2009). In par-ticular, service-oriented architectures (SOA) enable thedevelopment of systems where control modules can coop-erate at different levels and with different roles coherentlywith client–server architecture. One of the main advan-tages of SOA refers to its nature of open web services tocommunicate completely platform-independently but theoverhead required to develop the platform and a reliableorchestration of the services represent the main obstaclesto their adoption. Standard IEC 61499 also plays a crucialrole in supporting the development of distributed controlsolutions where each control module can encapsulate con-trol logic concerning different levels of complexity (IEC

International Journal of Computer Integrated Manufacturing 3

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

61499 2005; Strasser et al. 2012; Vyatkin 2011).Advanced control design approaches supporting reconfi-guration are described in Brennan et al. (2008), Valleeet al. (2011) and Valente and Carpanzano (2011), whereasfirst industrial applications of IEC 61499-based automa-tion solutions can be found in Carpanzano and Jovane(2007) and Gungor et al. (2011).

The production management and control for modularand RTSs present a number of challenges both in theproblem modelling and algorithms’ execution aspects. Theworks addressing such challenges are typically dealing withthe field of adaptive scheduling and routing of parts. Theinteraction between production and transportation control isdiscussed by Mantel and Landeweerd (1995). Petri net isused to analyse deadlock and conflict-free conditions(Dotoli and Fanti 2004; Wu and Zhou 2005). Singh andTiwari (2002) presented an intelligent agent framework tofind a conflict-free shortest-time path. An overview of thewide range of constraint-based scheduling techniques isgiven (Baptiste, Le Pape, and Nuijten 1995, 2001).Interesting insights on the topic of adaptive scheduling arepresented in Fazlollahtabar and Saidi-Mehrabad (2014) andFazlollahtabar and Mahdavi-Amiri (2013) with regards toautomated guided vehicles (AGVs). Many approaches haveaddressed the synthesis of robust scheduling solutionsexploiting the knowledge about possible and uncertainevents in order to produce schedules able to absorb someamount of execution unpredictability (Jorge Leon, DavidWu, and Storer 1994, Jensen 2001; Sevaux and Sorensen2002; Davenport, Gefflot, and Beck 2001; Leus 2003;Herroelen and Leus 2004). Then, temporally flexible sche-dules are usually defined as a partial order of the schedulingtasks and take advantage of such flexibility to hedge againstunforeseen events. In this case, no uncertainty knowledge isused. Also, rescheduling is considered when a current sche-dule is adjusted online, once an unexpected change doesnot allow the execution. Among these approaches, it ispossible to make a further distinction between the methodswhich try to maintain the repair as local as possible topreserve the stability of the solutions (Smith 1994), andthose which exploit the possibility of a more global repairto obtain better quality schedules (El Sakkout and Wallace2000). Finally, dynamic scheduling approaches support nobaseline schedule, that is at any time interval during theexecution the next set of activities to be executed is selectedaccording to specific policies and/or priorities(Demeulemeester and Herroelen 2002; Stork 2001).Recent works on adaptive routing address the ant colonyoptimisation algorithms which take inspiration from ants’behaviour in finding shortest paths (Bonabeau, Dorigo, andTheraulaz 1999). Most of the state of the art on routingalgorithms adopts standard or adapted network and graphstheories such as open shortest path first, shortest path first,Bellman–Ford, asynchronous online Bellman–Ford(Magzhan and Mat Jani 2013).

An auction-based approach to support dynamic rout-ing for RTSs is proposed in Carpanzano et al. (2014). Thislast research area highlights some major open questionsrelated to: (i) the ability of globally ensuring the partshortest path while concurrently leaving the single modulewith the autonomy of accommodating the part passage onthe basis of local criteria, (ii) building a persistent knowl-edge of the system status for any step of the routingdecision process and (iii) relying upon the capability toefficiently respond to any new event or even anticipate it.

The proposed approach described in Section 3 can beconsidered as a contribution in such research areas. Thepresented dynamic routing approach is conceived ascoupled to a distributed control system as described inValente, Cataldo, and Carpanzano (2013).

3. The RTS intelligent dynamic routing approach

From the previous analysis, a scenario emerges where it isdesirable to ‘push the envelope’ towards solutions thatmerge dynamic reconfiguration capabilities (i.e. capableof better fulfilling adaptive responses w.r.t. change) withagent-based technologies (i.e. capable of guaranteeingbetter autonomy, scalability and re-usability perfor-mances). In the following, we start describing the techni-cal characteristics of the modules composing the RTS, andthat guarantee the previously described capabilities.

In order to endow every RTS module with the cap-ability to determine the best routing for the transportedparts while cooperating in a community, the controlsoftware of each mechatronic module establishes a con-tinuous data exchange loop with the part-routing com-ponent (Figure 1) as described in Valente, Cataldo, andCarpanzano (2013). In order to implement intelligentrouting policies, the part-routing component is supportedby other system modules, in the three following steps.Initially, the topology recognition phase requires everymodule to dynamically build, and keep updated, a localmap of the shop-floor topology by exchanging informa-tion with its direct neighbours (this step is executedevery time the system senses a topology change). Thisensures that at the end of the topology recognition

Figure 1. Dispatching and routing approach.

4 E. Carpanzano et al.

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

phase, each module locally acquires a complete layoutof the RTS, thus having the knowledge about the mutualconnections of all the other modules. Subsequently, thepart-routing management phase determines the routingof the working parts by assigning them to the most sui-table modules as a result of a negotiation process imple-mented through an auction-based mechanism associated toa multi-objective function (see Section 3.2). Finally, withinthe supervision phase, the completion state of each task iscontinuously checked by means of a dynamic and flexibleexecution monitoring system. This system checks the pal-let routings in order to identify routing redundancies anddeadlocks (in which case the part-routing manager isnotified and the path revised); moreover, a path re-computation mechanism is triggered in case of unforeseenevents such as RTS module failures.

A central aspect of our analysis on RTSs is the part-routing management phase; in this respect, the present studyfocuses on the formalisation and resolution of the problem ofsynchronising the use of the RTS’s set of mechatronic mod-ules in order to transport all the parts to be processed towardstheir respective destinations in the production plant, that isthe online part-routing problem (OPRP). According to theOPRP’s definition, parts are transported by a set of availablepallets and are supposed to enter the system at a given rate.Each part is characterised by an entry point, a destination anda workplan, which is assigned depending on the part’s type.Workplans define the number, type and ordering of theworking stations each part requires to be processed on,ultimately defining the part’s high-level routing within theRTS. A solution for the OPRP must ensure that all the partsare properly worked (according to their workplan) as well asguarantee the routing consistency so that all paths satisfy thetemporal constraints related to the mechanical properties ofthe transportation modules as well as those of their subcom-ponents. Also, the routings must be collision-free so as toguarantee the correct execution of all pallets’motions, avoid-ing all physical clashes. Finally, routings must be efficient,thus being as short (hence as fast) as possible.

As anticipated in the Introduction, in the next sections weprovide the detailed formalisation of our dynamic approachto the RTS part-routing problem, followed by a descriptionof the auction-based distributed part-routing algorithm thatwill be used in the experimental section. The algorithmdescription will mainly focus on all the aspects related tothe auction mechanism, with particular attention to (i) thebehaviours enacted by all agents as they dynamicallyexchange between the auctioneer’s and bidder’s roles, and(ii) the bid assessment variables and procedures.

3.1. Part-routing problem formulation

In this work, the OPRP is addressed as a distributedproblem solving instance, as its solution entails the col-lective effort of a team of agents (i.e. the transportation

modules) each endowed with autonomous reasoning andcommunication capabilities used to sense the environmentand exchange proper communication with all the inter-ested peers. The proposed solving procedure takes theform of a distributed algorithm where the autonomousoptimisation capabilities of each transportation moduleplay a very important role to improve the overall systemefficiency. Within our multi-agent framework, the overallsystem’s behaviour will emerge as a result of the coopera-tion and coordination of all the agents that constitute thewhole production system under analysis, that is bothtransportation modules and machines. Given that allagents will generally retain a set of individual interests,it is of extreme importance that they are endowed with thecapability to negotiate possibly conflicting goals effi-ciently, ultimately producing routing solutions that arebased on both the global (i.e. the system’s) and the local(i.e. the individual agent’s) information. These circum-stances require the development of optimisation strategieswhere the complexity is shared among all modules, andwhere the phenomena that typically affect the modules,such as performance degradations and failures, are con-sidered. The generic manufacturing system is modelled asthe integration of the following elements:

● s working stations M = {m1, . . ., ms}● r (≤s) I/O working stations MI/O = {mio1, . . ., mior}

2 M● n transportation modules T = {t1, . . ., tn}● c parts to be processed Pa = {pa1, . . ., pac}● l pallets P = {p1, . . ., pl}

According to the production layout, a connectivity func-tion Cn(t1,t2,τ) can be defined, that states whether or nottwo transportation modules t1 and t2 2 T are allowed toexchange parts at a certain time τ:

Cn ti; tj; τ� � ¼ ? if ti and tj are not connected at instant τ

` if ti and tj are connected at instant τ

�

(1)

A pallet pi can be exchanged between two transportationmodules at time τ if and only if they are connected at timeτ. Given two contiguous transportation modules ti, tj 2 T,the connectivity function Cn(ti,tj,τ) basically determineswhether or not the transportation module(s) ti and tj areconfigured to allow the exchange of a pallet at time τ.

Generally, production connectivity may change overtime when multiple part shifting is possible, usually alsoentailing additional set-up times (Heineman, Pollice, andSelkow 2008). In general, each transportation module th 2T can find itself in nh different configurations σ (i.e. states),where σ(th,τ) indicates the configuration of th at time τ, anddur(σ) indicates the time interval during which th persists

International Journal of Computer Integrated Manufacturing 5

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

in the configuration σ. By selecting the proper configura-tion σ, each transportation module is capable of determin-ing the pallet’s correct management and routing towardsits destination. In order to correctly redirect all the incom-ing pallets, each transportation module th generally mustrepeatedly modify its configuration. However, changing aconfiguration takes time; set-up(σx, σy) is defined as thetransition time necessary to transit from configuration σx toconfiguration σy. The following example describes a typi-cal reconfiguration process involving two modules (th andtk) that must coordinate in order to exchange a pallet atsome time τ.

Example 1. With the help of Figure 2, let us describethe modules’ initial situation as follows: σx1(th,τ1) is theconfiguration that the module th will hold at τ1 beforetransitioning to the next planned configuration σx2(th,τ2)at τ2, while σx3(tk,τ3) is the configuration that the module tkwill hold at τ3 before transitioning to the next plannedconfiguration σx4(tk,τ4) at τ4. Since configurations σx1, σx2,σx3 and σx4 are supposed to be the results of previousplanning actions, they cannot be changed. Let us alsoassume that, in order to guarantee a proper pallet exchangebetween th and tk by the time τ (with (τ1 ≤ τ ≤ τ2) ^ (τ3 ≤ τ≤ τ4), th and tk must transition to the configurations σy(th,τ)and σz(tk,τ), respectively, with dur(σy) = Δτy anddur(σz) = Δτz, as depicted in Figure 2. In other words,both modules must carefully plan their reconfigurationoperations so as to satisfy the following condition:

ðτ > maxðτ1 þ set-upðσx1 ; σyÞ; τ3þset-upðσx3 ; σzÞÞÞðτ > minðτ2 ��τy � set-upðσy; σx2Þ;τ4 ��τz � set-upðσz; σx4ÞÞÞ

(2)

Condition (2) basically states that in order to properlyexchange a pallet between the modules th and tk, bothmodules must mutually synchronise at time τ, allowingthemselves sufficient time to: (i) transit from the initialconfigurations to the ones deputed to the pallet exchange,(ii) concurrently maintain such configurations long enoughto ensure pallet exchange completion and (iii) transit againto the modules’ respective final configurations, as statedby the original plan.

Each pallet is equipped with a programmable memorychip storing the information about the pallet ID, the hostpart ID, the part program, the operations still to be doneand the history of transportation modules visited so far. Atevery time instant, the number of pallets lc concurrentlycirculating on the transportation system cannot be higherthan the maximum pallet volume in the system (lc ≤ l).

3.2. A fully distributed and auction-based solution forthe OPRP

The solution proposed here to the previously describedpallet-routing problem is fully distributed. Each transpor-tation module is provided with the following autonomousreasoning capabilities: context recognition, used to sensethe environment; capability assessment, used to assess themodule’s capabilities (which may typically depend on thesensed environmental factors); and finally optimisation,used to participate to the distributed route finding problemas an autonomously reasoning agent. The solution wepropose takes the form of a decentralised algorithmwhere the autonomous optimisation capabilities of eachtransportation module (i.e. the agent) play a very impor-tant role to improve the overall system efficiency.Additionally, the realisation of the control solution interms of a multi-agent paradigm enables the developmentof optimisation strategies where the complexity is sharedamong all modules; finally, the exploitation of the distrib-uted paradigm inherently brings the advantage of a grace-ful degradation of performances in case some of themodules should fail.

In more details, the solving procedure proposed in thiswork reduces the OPRP to a task assignment problemtackled by means of an auction algorithm (Koenig et al.2006; Bertsekas 2001; Lagoudakis et al. 2005). Auctionalgorithms constitute a well-known methodology to solvetask assignment problems that have been shown to effi-ciently produce near-optimal solutions in terms of bothcommunication and computation efforts. In such algo-rithms, bidder agents place bids on tasks with values thatdepend on their individual situational awareness assess-ment, and the agent that offers the highest bid wins theassignment. Traditionally, the winner is determined by acentral system acting as auctioneer who receives all thebids and evaluates the best one based on a predefinedscoring metric (see below). In other versions of the pro-blem the central system is replaced by one of the agents,who temporarily take the role of the auctioneer. In ordernot to have any centralised feature in our architecture andkeep it fully distributed, we have chosen to adopt thesecond approach. At the end of each auction, the taskwill be assigned to one agent only, and all pallet routingswill be finalised through iteratively issuing a set of auc-tions for each pallet.

Figure 2. Different reconfigurations for the transportationmodule th and tk.

6 E. Carpanzano et al.

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

Formally, a task assignment problem is specified by aset of agents R = {r1, r2,. . ., rn}; a set of targets (tasks),Π = {π1, π2,. . ., πm}; their locations; and a non-negativecost function c(i,j), i,j 2 R [ Π, which denotes the cost ofmoving between locations i and j. The objective of multi-agent routing is to find an allocation of targets (i.e. anassignment of tasks) to agents and a way for each agent toperform all the tasks allocated to it so that a team objectiveis optimised. In general, all involved agents place bids onthe available tasks and the winner (i.e. generally the agentthat bids the highest value based on the scoring metric) isassigned the task. The winner determination is performedby an auctioneer, whose role is played in turn by one ofthe agents participating to each auction round (i.e. theagent that starts the auction), in order to eliminate anycentralised feature and maintain a fully distributedapproach.

3.3. Task assignment problem and auction algorithms

The task assignment problem we tackle here resembles itsclassic formulation in that we have a set of agents (i.e. thetransportation modules) and, for each pallet that enters thesystem and that must be routed to its destination, a set oftasks that realise such routing to be assigned to the agents.The main differences with respect to the classical problemare the following:

● The total number of tasks that have to be assignedto the agents for each incoming pallet is not knownin advance.

● Not all the agents participate to a given auction, butonly those that may potentially acquire the task atthat particular auction round. It remains howevertrue that all the agents may potentially participateto the auctions while the pallet path is being con-structed.

3.3.1. The bidding rule

In general, for a distributed task assignment problem theteam objective can be expressed as follows:

minA f g t1;A1ð Þ; . . . ; g tn;Anð Þð Þ (3)

where the function f measures the performance of the team(e.g. the total transportation path length among the com-munity of modules), the function g measures the perfor-mance of each module (e.g. the reconfiguration time) andA = {A1,A2,. . .,An} is a partition of the set of tasks, wherethe tasks in Ai are those allocated to the module ti.

Let TAC(ti,Ai) denote the minimum task allocation costfor the transportation module ti to be assigned the tasks 2Ai. As we will see shortly, in our particular test case, TACwill be expressed in terms of multiple parameters (local

and global ‘costs’) that will have to be kept as low aspossible; therefore, in this case the team objective can beexpressed as:

minAXi

TAC ti;Aið Þ (4)

Let (Apa1, A

pa2,. . ., A

pan) be the current partial allocation of

tasks to pallet, and let π[p] be an unallocated task relativeto the pallet p; the following bidding rule can be proposed,directly derived from the team objective: the transportationmodule t bids on an unallocated task π[p], the difference inperformance for the given team objective between theallocation that results if module t is additionally allocatedtask π[p], and the current allocation of tasks to modules. Inother words, the transportation module ti should bid ontarget π[p] the difference:

f g t1;A01ð Þ; . . . ; g tn;A

in

� �� �� f g t1;A1ð Þ; . . . ; g tn;Anð Þð Þ (5)

where Aʹi = Ai ⋃ {π[p]} and Aʹ

j = Aj for i ≠ j. For the teamobjective expressed in Equation (4), the transportationmodule ti bids on task π[p]:

Xj

TAC tj;A0j

� ��Xj

TAC tj;Aj

� �

¼ TAC ti;Ai [ π p½ �f gð Þ � TAC ti;Aið Þ (6)

In this work, TAC is expressed as a weighted sum of anumber of both local and global parameters describedbelow, such as the distance L that the pallet p must travelto reach its destination passing through ti, the set-up cost Cthat ti must pay in accepting p (both L and C should bekept as small as possible) and the possibility X that ti hasto accept p. Each bidder places a bid whose value(bidValue) depends on multiple parameters (i.e. is multi-objective), and is inversely proportional to the TAC – asindividually assessed by each bidder module – by meansof the following function:

bidValue X ; L;Cð Þ ¼ X � exp � αLþ βCð Þð Þ (7)

Function (7) is designed to ensure convexity of thereward/cost (it is monotone), and returns values 2 [0,1],provided all parameters are positive. The lower the globalcost value αL + βC, the higher is the reward returned bythe bidValue function. All the parameters involved in thebid evaluation will be explained in detail in the followingsections.

International Journal of Computer Integrated Manufacturing 7

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

3.3.2. Inside a single auction

The objective of every single auction is to decide the nexttransportation module which will take charge of a movingpallet during the path towards its destination. The com-plete path will be synthesised by means of a series ofconsecutive auctions (rounds), each of which has theobjective of assigning the pallet to another transportationmodule until it arrives to its destination. For each auction,the involved agents can generally participate with twodifferent roles, the auctioneer and the bidder. The role ofthe auctioneer is particularly important as it is the agentthat starts the auction and receives the bids, while all theremaining agents will play the role of bidders. For eachtransportation module, winning an auction related to apallet p (i.e. winning the related task π[p]) entails:(i) becoming part of p’s path from its source to its destina-tion, and (ii) committing to play the auctioneer role for thesuccessive auction related to the p’s remaining path seg-ment. The auctioneer and the bidder roles will beexplained in more detail in the following sections.

3.3.3. The auction tasks

Figure 3 presents a particular case of a general productionplant, showing how the transportation modules can bepositioned to allow pallet routings. In particular, eachtransportation module ti is composed of three transporta-tion units {uk}, which are the module components whosereconfiguration allows the module to implement the dif-ferent paths for the pallets. Figure 3 shows how theauctioneer agent (i.e. the t1 agent currently owning thepallet, in the figure) offers a single task to its neighbours(t2, t13 and t15) for bidding. The three ‘task arrows’ in thefigure represent the pallet’s possible movements related tothe offered task; for each bidder participating to the auc-tion, bidding for a task entails the auto-assessment of itsown convenience to take active part in the transportationof the pallet towards its destination, as it travels from itscurrent source location (in this case, t1) passing throughthe bidder’s entry point.

For example, let us focus on the bidding agent t2 inFigure 3. The routing distance to the pallet’s destinationpassing through t2 – computed as the total number oftraversed transportation units – is clearly determined bythe (not unique!) path composed of the {u1 → u2, u2 →u3, u3 → u4} segment plus the {u4 → u5, u5 → u6, u6 →u8, u8 → u29, u29 → u28} segment, which totally corre-sponds to eight steps. The routing distances passingthrough the modules t13 and t15 can be computed simi-larly; the reader can easily verify that these distances sumup to 8 steps ({u1 → u37, u37 → u38, u38 → u39, u39 →u34, u34 → u35, u35 → u36, u36 → u7, u7 → u28}) and 10steps ({u1 → u45, u45 → u42, u42 → u37, u37 → u38, u38 →u39, u39 → u34, u34 → u35, u35 → u36, u36 → u7, u7 →u28}), respectively.

3.3.4. The auction algorithm

The single auction’s dynamics can be described from boththe auctioneer’s and the bidder’s standpoint, as follows. Itshould be again underlined here that the agents are repre-sented by the transportation modules, the tasks are asso-ciated to the pallets that have to be transported from asource to a destination, and the best assignment coincideswith the best path for each pallet. By best path we intendthe path that creates no conflict with other pallets that arealready travelling in the shop-floor, and that is as short aspossible, taking into account any constraints in the system(e.g. energy, possibility to stop a pallet, broken modules).In other words, the best path coincides with the shortesttopological path only in the most simple cases.

3.3.5. The bidder’s role

The algorithm related to the bidder’s activity is shown inFigure 4; in the following, such algorithm will beexplained in detail (the algorithm related to the auctioneerwill be described in the next section). At line 3, the biddermodule tbidder receives from the auctioneer a request tomake a bid for a task π[ph] related to the pallet ph (as will

Figure 3. Offering a task to the neighbours.

8 E. Carpanzano et al.

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

be explained in the next section, the auctioneer sends a bidrequest to its direct neighbours only). The bidder, whenreceiving a request for bid from the auctioneer, is forced tooffer a bid; it first extracts the task it is called to bid on,and then evaluates a bid value for the task. It should beunderscored at this point that the overall approach fol-lowed in our multi-agent system is consistent with thebenevolence assumption (Wooldridge 2002); all biddersare cooperative in that they are designed to help outwhenever needed, even if doing so should imply commit-ting resources w.r.t. inactivity. In other words, the overallsystem objective matters more than the agents’ individualinterests, even if, as we will see shortly, each agent canoffer its services according to its own private (local)interests.

As previously expressed in Formula (7), the bid valuerepresents an autonomous assessment of the proficiencywith which the bidder can possibly manage the task underanalysis. The bid is evaluated by means of the computeBid() procedure at line 5; such procedure entails taking intoaccount the following variables, assessed through the ela-boration of either global and local information on behalfof each agent:

Shortest topological path assessment value (L 2 [0,1]): Lrepresents an evaluation of the path’s length from theauctioneer to the pallet’s destination passing through thecurrent transportation module (i.e. the bidder). Such eva-luation is performed by the bidder on the basis of itsknowledge of the topological structure of the transporta-tion system (see Example 1). Every bidder is in fact awareboth of the global system topology and of its direct neigh-bours (as a result of the topology recognition step), thus itcan assess the global path length. In other words, L’s valueis computed on the basis of information mostly pertainingto the whole system (global information), as follows:

L ¼ sp tbid; tauctð Þj j þ sp tbid; tdestð Þj j � sp tauct; tdestð Þj jmax sp th; tkð Þð Þ

(8)

where sp(ti, tj) is the shortest path between the transporta-tion modules ti and tj, with (i,j) 2 {bidder, auctioneer,start, destination}, and the denominator represents themaximum of all the shortest paths between any two mod-ules th, tk 2 T.

As opposed to the previous topological path value L,whose assessment is performed on the basis of the mod-ules’ knowledge about the entire transportation system’stopology, the following two parameters will be computedon the sole basis of each module’s knowledge of its ownlocal status. In this regard, the agent is endowed with atimeline-based planning component (Muscettola 1994;Cesta et al. 2009) responsible to maintain a temporalmodel of its reconfiguration plan relatively to the palletsthat have been won by the module in previous auctionsbut that have not yet been executed. Such timeline-basedtechnology provides functionalities to reason about a mod-ule’s temporal evolution in terms of causal and temporalconstraints. Then, every time a new pallet request occurs,an off-the-shelf timeline-based planner, called EPSL(Cesta, Orlandini, and Umbrico 2013), is exploited toevaluate whether the module can accept a new task (i.e.can participate in a new auction) as well as which is theadditional local cost for scheduling that new task withinthe current reconfiguration plan (i.e. the needed set-uptime and the required energy). Every time a new pallet iswon in an auction, the component updates the planningmodel. The parameters computed by the component are aConflict detection flag and a Local Cost value.

Conflict detection flag (X 2 {0,1}): X is a flag taking 0 or1 values, determining whether or not a transportationmodule is capable of accepting a pallet at a given timewithout generating a conflict with all the previouslyaccepted pallet commitments. If X = 1, no conflict isgenerated, and the module is therefore entitled to place abid ≥ 0. In the opposite case (X = 0), the pallet cannot beaccepted because the module is oversubscribed. The mod-ule’s bid will therefore be equal to zero, according toFormula (7).

Local Cost value (C 2 [0,1]): C represents an evaluationof the cost the transportation module is going to pay inpotentially accepting the pallet in terms of time and energyspent for all the set-up changes. Such evaluation is per-formed on the sole basis of information pertaining to themodule’s local situational assessment, as follows:

C ¼ C E1 � E0ð Þ ¼ � E1 � E0ð Þ þ 1

2(9)

makeBid()

1. {2. //The bidder extracts the current task from the remote bid request3. π[ph] = remoteBidRequest();4. //Bid assessment step5. bidValue = computeBid(π[ph]);6. //Bid communication step7. sendBidResult(bidValue);8. //The auction’s outcome is received from the auctioneer9. taskIsWon = retrieveAuctionOutcome();10. //Update the bidder’s task list11. if(taskIsWon == true)12. {13. //Insert the task in the bidder’s task list14. taskList[] = insertTask(π[ph], taskList[]);15. }16. else17. discard(π[ph]);18. }

Figure 4. Auction algorithm (bidder’s side).

International Journal of Computer Integrated Manufacturing 9

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

where E0 and E1 evaluate the efficiency of the modulebefore and after accepting the pallet, respectively. In par-ticular, the efficiency E is computed by means of thefollowing formula:

E ¼ 1��τmk

0; 1½ � (10)

where Δτ represents the total time spent by the module forreconfigurations, and mk represents the makespan (i.e. thetemporal horizon) of the module’s local operations plan.The higher the measure of E, the more efficient is themodule’s behaviour; ideally, when Δτ = 0 (i.e. no reconfi-gurations are expected) the efficiency E reaches its max-imum value (i.e. E = 1).

As previously stated, the last two variables (X andC) are assessed as a result of a planning procedurecarried out by each module on its own reconfigurationtimeline, aiming at autonomously evaluating both theviability and the cost of the reconfiguration operationthe module should undergo in order to properly dispatchthe pallet it is called to bid for. For every module, theplan obtained at the end of the planning process containsthe projection in time of the hypothetical execution planthe module should commit to in case the pallet is won,included the precise temporal information of the recon-figuration changes, as well as the related space occu-pancy data. Should the resulting plan be infeasible, thatis accepting the pallet inevitably entails a temporal orresource conflict for the module, the conflict detectionflag X returned value will be null and the local costvalue C will not be computed; in the opposite case,the X value will be equal to 1, and the local costvalue C will be assessed based on the produced plan.At the end of the auction, the winning module willretain the new plan as its current plan, whereas theplans obtained by all the other bidders will be discarded,and they will revert to their pre-auction timelines.

It should be underscored at this point that the previousbidding mechanism rules out the possibility for an agent toparticipate to multiple auctions concurrently, as eachagent’s bid should be based on a stable status quo on itslocal timeline. Once an auction is started and the agentparticipates as a bidder, it is not possible for the agent tosafely bid any other value on any concurrent auction untilit receives the present auction’s outcome from theauctioneer.

The success of a bid leads to an update of the palletmemory. Once the multivalued bid value (bidValue) isassessed, the bidder finally sends it to the auctioneer(line 7), and waits for the bid’s outcome. Eventually, thebid’s result is communicated back by the auctioneer (line9). If the bidder agent results the winner of the task t[ph](taskIsWon = = true, at line 11), the task is immediately

inserted in the bidder’s list of owned tasks (line 14);otherwise, the task is discarded (line 17).

3.3.6. The auctioneer’s role

As described in the previous section, each transportationmodule tk maintains a list of ‘pending’ tasks (taskList[])corresponding to the pallets that have been won by tk inprevious auctions, and that therefore will eventually travelthrough tk. Each module that has a non-empty list ofpending tasks must issue new auctions with the objectiveof emptying such list. The modules with a temporarilyempty taskList[] cannot play the role of auctioneers, butcan participate as bidders to auctions issued by othermodules. Let π[ph] be a task associated to the pallet phbelonging to tk’s list of pending tasks: unless tk is thedestination module of the pallet ph, for each task π[ph] 2taskList[], tk is entitled to set up a new auction among itsneighbours in order to decide the next pallet’s assignment(i.e. tk takes up the role of the auctioneer). Once the task isassigned, it can be erased from tk’s list of pending tasks;the task is added to another list (AssignedTaskList[]) thatmaintains all the tasks that have been assigned to othermodules but that have not yet been executed (i.e. trans-ported) by tk. It should be underscored that there is norelation between the time τa the auction for a task isfinalised, and the time τexec at which the task’s pallet isactually executed on the winning module, except theobvious relation τa < τexec.

From the previous analysis it is clear that the palletpath construction, being realised as a series of successiveauctions carried out by all interested modules, can besensible to the task selection policy carried out by eachauctioneer, as different policies may results in differentpaths and different routing efficiency. At each auction, theselection of the next task from the list of pending tasks isperformed by choosing the task characterised by the high-est priority P. Such priority can be decided according todifferent criteria; in the analysis performed in this work,we use three different task-selection priority modes:urgency-based, ageing-based and FIFO-based, describedas follows:

● [Urgency-based priority]: In this case, the auction-eer agent tk selects the task π[pi] associated to thepallet pi whose expected arrival time τi

eta on tk isclosest to the current execution time τexe. Accordingto the urgency-based selection approach, each task π[pi] in the auctioneer’s task list is assigned a priorityPi computed as follows:

Pi ¼ 1

τetai � τexeð Þ (11)

10 E. Carpanzano et al.

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

The smaller the difference (τieta – τexe), the more urgent

the pallet, and the higher its priority.

● [Ageing-based priority]: In this case, the auctioneeragent tk selects the task π[pi] associated to the palletpi whose cumulative permanence time in the pro-duction plant is the highest. Let us define τi

arr as thetime at which the pallet entered the shop-floor;according to the ageing-based selection approach,each task π[pi] in the auctioneer’s task list isassigned a priority Pi computed as follows:

Pi ¼ τexe � τarri (12)

The greater the difference (τiarr – τexe), the longer the

time spent by the pallet in the production plant, andthe highest its priority.

● [FIFO-based priority]: In this case, the auctioneeragent tk selects the task according to a first-in-first-out policy, relatively to the entry order in the auc-tioneer’s task list.

The auctioneer’s algorithm is shown in Figure 5. Line 4 ofthe algorithm outlines the priority-driven task selectionoperation, previously described, that is the task π[ph] isselected according to the priority mode P. Subsequently,the auctioneer retrieves the set of tk’s direct neighbours

(the neighbors[] array, in the algorithm), that is the trans-portation modules deputed to participate to the auction asbidders (function getNeighbors(), line 6). As clarified inthe next section, this operation is of particular importance;at the beginning of every new auction, the auctioneerrequests the list of possible bidders as such list mayhave become obsolete due to possible modifications ofthe plant topology that may have occurred (because offailures, maintenance operations or additions/removals ofmodules).

The getNeighbors() function actually performs threeactivities: (i) retrieves the list of the auctioneer’s neigh-bouring modules, (ii) sends to all such modules an auctionparticipation request and (iii) waits for the response fromall of them. Only when all responses are received and thelist of all neighbours is known to the auctioneer, can theauction begin (see also Section 3.3.7 for more details).

Afterwards, a request for a bid is issued to all suchneighbours t 2 neighbors[] (lines 8−12). In particular, therequestForBid(t[ph],t) function triggers the previouslyanalysed makeBid() algorithm of Figure 4. Finally, whenall bids are received from the bidders and saved in thebidResult[] set (line 11), the auctioneer extracts the winnerby comparing all the received values and selecting the bestbid bid* as follows (getBestBid() function, line 14):

bid� ¼ maxt bidResult t½ �ð Þ t 2 neighbors½� (13)

In order to decrease the possibility that a pallet is sentback again to the module it arrives from (hence reducingthe chances of routing deadlocks), the auctioneer penalisesthe bid offered by the source module by a determinedamount, before proclaiming the winner. In case all biddersshould provide zero-valued bids, that is no agent canmomentarily accept the pallet, the related task is retainedby the auctioneer, who will re-issue a successive auction,as soon as possible. Ties are randomly resolved by theauctioneer at bid reception time. Once the winner isselected, all the participants will be notified about thebid’s outcome by the auctioneer tk (lines 16−22), and therelated task is finally removed from tk’s local task list (line24). As already stated, all the previous steps are repeateduntil tk’s list of pending tasks is empty, meaning that tk hasno more pallets to be redirected.

3.3.7. Contingency and deadlock management

During the normal operations of the transportation system,contingencies may occur. In the present study, we takeinto account contingencies as single module failures, thatis time intervals during which one transportation moduleis unable to carry out its tasks, that is participating toauctions and/or dispatching the pallets that it has alreadywon. As demonstrated in the experimental section of thiswork, one of the most evident benefits of the distributedFigure 5. Auction algorithm (auctioneer’s side).

International Journal of Computer Integrated Manufacturing 11

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

approach illustrated in this work rests in the recoverycapabilities of the overall system. In fact, capability decen-tralisation greatly contributes to system robustness, allow-ing hedging against local failures realising a gracefuldegradation of performances. Without loss of generality,we consider such failures as temporary; the modulesaffected by the contingencies eventually recover all theirabilities and are re-introduced in the nominal activity ofthe plant.

In case of module failure, the following activities takeplace:

(1) Topology re-assessment phase: The first neighbourof the collapsed module that becomes aware of theoccurred contingency immediately initiates anassessment of the new topology by means of itscontext recognition component. The assessment ofthe new topology is an operation that involves thecontext recognition components of all the activemodules, and terminates when all such moduleshave updated their plant topology knowledge.

(2) Pallet re-routing phase: Each neighbour of thecollapsed module that has assigned one or moretask to such module in previous auctions will re-assign to itself such tasks (i.e. it will add themagain at the top of its list of pending tasks), henceimmediately starting all necessary auctions toguarantee a safe path towards their respective des-tinations for all the interested pallets. Obviously,the new paths will be computed on the base of thenewly assessed topology, that is in the absence ofthe failed module.

When the failed module revives, step 1 of the previous listis enacted again, while step 2 is optional.

It is clear at this point that the path computationmechanism entails the concurrent activities of more mod-ules, some acting as auctioneers and some as bidders, andthat paths for different pallets may be under constructionat the same time in the plant. These concurrent activitiesmay lead to some deadlock situations, especially con-nected to the activity synchronisation during the enact-ment of the auction protocol. One typical deadlock thatmay occur is when two neighbouring modules (both act-ing as auctioneers) concurrently send to each other theauction participation request (getNeighbors() function,Section 3.3.6), waiting indefinitely for each other’sanswer, therefore creating a deadlock. This situation issolved by imposing a time limit within which the auction-eer can receive the answers from its neighbours. If allanswers are received within such time limit, the auctionmay proceed; otherwise the auction is aborted (to bereprised in a later moment) and the auctioneer sends theabort message to all the actively participating neighbourssetting them free to participate to other auction activities.

Moreover, in order to avoid situations where two auction-eers enter a resonance state by mutually synchronising ona continuous ‘wait & abort’ cycle, a mechanism has beenintroduced by which each aborting auctioneer suspendsitself returning to a listening state for a time intervalproportional to the task’s priority P, before re-issuing theauction.

4. Experimental evaluation in a realisticmanufacturing case study

This section illustrates the assessment of the intelligentdynamic routing approach presented in the previous sec-tions. Here, the aim is to assess the performance of thedistributed auction-based mechanism while addressing theOPRP in a real-world scenario in order to show its viabi-lity with respect to main concrete RTSs requirements, thatis throughput and average lead time within a time shift aswell as to compare it with a well-defined benchmark case.

4.1. Real case study

The proposed approach and the OPRP model have beenevaluated with reference to a case study of RTSs resultingfrom the integration of multiple modules (Carpanzanoet al. 2014). Figure 6a illustrates a view of a referencetransportation module whose major movements are shownin Figure 6b. The module can perform forward and back-ward movements as well as cross-movements enabled by across-transfer device. The module is equipped with a PC-based PLC system and a number of sensors such asproximity and pallet reference sensors. All modules areequipped to be interfaced to one another, as well to theworking machines. The considered shop-floor is organisedas one (un)load station, three working machines and aRTS. Pallets with parts are injected in the system by theload station and, depending on the system configurationthey reach the working machines by following differentroutings. Once processed, the finished parts are redirectedto the unload station to be allocated in the finished partstorage system. The three machines perform, respectively,a visual inspection and a functional testing (M1) and twoseparate types of repairing (M2 and M3).

(a) (b)

Figure 6. RTS autonomous module: (a) generic RTS moduleand (b) 2D view of the module.

12 E. Carpanzano et al.

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

The considered RTS is composed of 20 transportationmodules which can be connected to one another to formalternative layouts. The transportation modules areequipped with a number of cross-transfer devices enablingthe cross-transportation between transportation moduleswhose main movement directions are parallel. Machinesand transportation modules are modelled as not perfectlyreliable; times to resource failures are modelled usingexponential distributions. Only one failure mode is cur-rently considered in this paper. In order to be completelyprocessed, pallets with parts must accomplish a workplanwhich first entails a visit to M1 followed by a visit toeither M2 or M3.

As an example, Figure 7 illustrates seven such layouts(named A, B, Cross, Eight, Full, Ring and Star, where thebold black segments represent cross-transfer devices).

4.2. Experimental results

Runs are performed considering different combinations ofthe weights associated to the bid value (Equation (7)). Inparticular, two different settings for alpha and beta (asso-ciated weights for L and C parameters in the biddingfunction) are employed: (i) alpha 0.7 and beta 0.3; and(ii) alpha 0.5 and beta 0.5. Moreover, transportation mod-ules are endowed with different priority policies whileissuing auctions (Equations (11) and (12)). In the follow-ing, we will refer to them as: urgency-based (U), ageing-based (A) and FIFO-based (F).

During the runs, all the possible combinations of theabove settings are considered. In the following, differentsettings are named OPRP-XY where X and Y refer, respec-tively, to the exploited priority and the combination alpha–beta (1: alpha = 0.7, beta = 0.3; and 2: alpha = beta = 0.5).

Thus, for instance, OPRP-U2 refers to the followingOPRP setting: urgency-based priority and alpha = beta = 0.5.The benchmark selected to assess the performance of theOPRP different solutions is the shortest path (SP) algo-rithm. It relies on a procedure minimising the path withoutany additional dispatching reasoning, with the exceptionof the part collision avoidance policy, simply enacted bypreventing any pallet movement towards the next moduleunless the latter is free.

The experimental campaign has been structured inthree major testing runs aiming to: (i) evaluate RTSthroughput and parts lead time considering different lay-outs so as to support RTS design phase, (ii) compare thefeatures of the proposed auction-based method withrespect to a well-defined benchmark case and (iii) assessthe benefits of the distributed approach when temporaryand dynamic changes occur within the RTS. The obser-ving horizon corresponds to the work shift (8 hours) andthe rate of parts entering the system from the load stationis kept constant.

The OPRP solving algorithm has been implemented inJava SE 7 by developing a multi-agent simulation frame-work in the JADE platform.1 The experimental campaignhas been executed on a workstation MacBook Pro withIntel Core i5 2.4 GHz and 8 GB RAM.

4.3. Evaluating throughput and lead time

The first experimental run proves the benefits associated tosolving the OPRP as a means to support the RTS config-uration solution, by evaluating the system throughputs andthe part lead times associated to each RTS layout. Ifassisted by the OPRP solving algorithm, the transportationsystem configuration process should lead to more accurate

(a) (b) (c) (d)

(g)(f)(e)

Figure 7. Some RTS layouts used for the experimental evaluation: (a) RTS A, (b) RTS B, (c) RTS Cross, (d) RTS Eight, (e) RTS Full,(f) RTS Ring, (g) RTS Star.

International Journal of Computer Integrated Manufacturing 13

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

analyses compared with traditional static techniquesinspired by analytical methods or simulation-basedapproaches where there is no chance to assess the dynamicgeneration of alternative routings.

The system’s behaviour has been observed by consid-ering 15 alternative transportation system configurationscharacterised by the same number of machines, all sharingthe identical topological position in the shop-floor.

Within the 8 hours work shift and considering theabove layouts, OPRP settings show different perfor-mances. In particular, Table 1 shows throughput valuesand Table 2 shows average lead time values in the sevenselected layouts. Considering average throughput valuesin each layout, the results are 19 parts/h for the A, 20parts/h for the B, 28 parts/h for the Cross, 21 parts/h for

the Full, 20 parts/h for the Ring and 23 parts/h for the Star.For each layout, average part lead times are 933 sec for theA, 889 sec for the B, 627 sec for the Cross, 848 sec for theEight, 840 sec for the Full, 840 sec for the Ring and746 sec for the Star. Figure 8 shows the volume curveprofiles of finished parts in the observing horizon asso-ciated to the previous configurations and the OPRP-A2setting.

As a result of these analyses, the system designer canevaluate the alternatives more precisely, and select themost efficient RTS configuration given the productionand technological requirements. In this particular case,the best topology is the RTS Cross configuration consider-ing its average throughput and part lead times. And morein detail, OPRP-A2 results as the best OPRP variantfeaturing a throughput of almost 29 parts/h and an averagelead time of 627 sec. Then, good results are also obtainedin Star layout. In this case, OPRP-F1 is the best combina-tion with almost 25 parts/h and 706 sec as average leadtime.

Further observing the results in Table 1 and Table 2, itis possible to evaluate the goodness of OPRP variants. Inparticular, OPRP-A1 and OPRP-A2 show in generalhigher values (e.g. in Cross, Ring and Full). Then,OPRP-F2 behaves well in five layouts (i.e. B, Cross,Eight, Full and Ring). On the contrary, OPRP-U2 seemsto be the worst deployed setting.

Table 1. Throughputs for the different OPRP settings andlayouts.

Throughput A B Cross Eight Full Ring Star

OPRP-U1 21.00 19.63 28.50 20.63 20.88 19.63 24.75OPRP-A1 19.88 20.88 28.38 20.63 22.38 21.75 23.00OPRP-F1 20.25 19.13 27.75 20.25 21.38 19.63 24.88OPRP-U2 16.63 17.63 27.75 21.00 19.00 18.75 24.25OPRP-A2 18.63 22.25 28.63 21.00 19.63 19.38 23.13OPRP-F2 18.13 21.88 28.13 21.00 22.38 21.00 21.63

Table 2. Average lead times (in seconds) for the different OPRP settings and layouts.

Lead time A B Cross Eight Full Ring Star

OPRP-U1 846.96 931.03 622.55 848.45 841.39 906.32 714.22OPRP-A1 903.62 859.05 624.74 843.89 790.79 805.90 759.77OPRP-F1 877.51 936.42 638.46 867.11 828.02 903.81 705.95OPRP-U2 1074.09 1011.50 641.45 835.21 904.59 905.17 727.03OPRP-A2 942.22 783.86 613.93 845.74 884.73 900.31 753.71OPRP-F2 955.50 811.15 622.89 845.74 792.20 832.10 814.06

Figure 8. Production volumes for OPRP-A2 associated to examples of RTS layouts.

14 E. Carpanzano et al.

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

4.4. Comparing OPRP variants with shortest pathbenchmark

The second experimental run concerns the evaluation of theOPRP features compared with the SP algorithm across all the15 layout options. In all the 15 analysed configurations, apartthe Eight layout and few other cases (i.e. OPRP-U2 for Ringand OPRP-F2 for Star), the throughput of OPRP variants isalways higher than the one associated to SP benchmark, in a5–63% average range, within the observing horizon. InTable 3, results show that in Eight layout, SP and OPRPvariants show nearly the same performance. This gapincreases for complex RTS layouts where the chances toincur bottlenecks are higher and the SP deteriorates furthercompared with OPRP. For instance, OPRP-A1 and OPRP-A2 outperform SP in a 69–80% range in B layout. Then,Figure 9 illustrates an example of finished part volumesassociated to a configuration representing an average case:the Full configuration where the gap reaches 30%.

4.5. Assessing benefits of variants of OPRP solver inpresence of temporary reconfigurations

The last experimental run assesses the benefits associatedto the adoption of OPRP while matching permanent or

temporary changes of the RTS layout, that is reconfigura-tions. As explained in Section 3.3.7, when the RTS isreconfigured, the OPRP algorithm is capable of automati-cally recognising the new RTS topology and referring to itwhile generating the various routing tasks. This cannot beachieved by the SP algorithm, which requires the user tomanually adapt the reference layout as well as the relatedsoftware code. Temporary reconfigurations embrace thecase of RTS module failures. The occurrence of failuresmust be very carefully evaluated in RTS, considering thenumber of mechatronic modules involved in the systems.The failure generates a temporary unavailability of themodule that corresponds to a temporary change (or asoft reconfiguration) of the RTS layout in the systemabstract model. Once the new RTS layout is generated,OPRP resumes the production of new routing policiesuntil the original layout is restored. This capabilityincreases the difference between the OPRP and SP results.The throughput and lead times are severely influenced bythe module undergoing the failure and its position in thetopology. For the reference configurations the gap betweenthe production volumes produced with the best OPRPvariant and SP in the presence of failure in one specificmodule, whose temporarily unavailability is kept at30 min, ranges between 20% and 67%. The maximumgap of 25% associated to nominal working conditionsbecomes 30% in the case of failure occurrence. InFigure 10, the volumes for SP and OPRP variants aredepicted for the Cross layout. In this case, the exhibitedbehaviours of OPRP variants outperform SP, exceptOPRP-F1 that is pretty much comparable with it.

5. Conclusions

The current work introduces a novel approach for the partdispatching and routing in RTSs where transportationmodules are empowered by a reasoning infrastructure,formalised as the OPRP, for autonomously determining

Table 3. Throughputs percent difference w.r.t. SP for the dif-ferent OPRP settings and layouts.

ThroughputSP percentdifference A B Cross Eight Full Ring Star

OPRP-U1 145% 159% 127% 99% 121% 104% 110%OPRP-A1 137% 169% 126% 99% 130% 115% 102%OPRP-F1 140% 155% 123% 97% 124% 104% 111%OPRP-U2 115% 142% 123% 101% 110% 99% 108%OPRP-A2 128% 180% 127% 101% 114% 103% 103%OPRP-F2 125% 177% 125% 101% 130% 111% 96%

Figure 9. OPRP variants versus SP volumes with reference to Full configuration solutions in the whole observing horizon.

International Journal of Computer Integrated Manufacturing 15

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

the part routing while addressing local and global optimi-sation objectives. Compared with traditional dispatchingpolicies, such as greedy and fixed path-routing policies,this approach enables the modules to become ‘plug andproduce’ while concurrently leading to an averagethroughput improvement up to 25% assuming a perfectreliable behaviour of equipment while in system degradedoperation modes the maximum gain is 30%. This enablesthe accomplishment of productivity thresholds by realisinga persistent adaptation of part dispatching and routing bymanaging system bottlenecks, deadlock and resourcesanomalies.

Future work will refer to more comprehensive experi-mental analyses, addressing a sensitivity analysis on thebid value function coefficients, as well as multiple failuremodes of the RTS modules. Further activities will refer tothe software in the loop architecture development whoseobjective would be the real-time evaluation of the dis-patching policies generated from the algorithm beforedeploying the commands to the physical equipmentcontrollers.

Disclosure statementNo potential conflict of interest was reported by the authors.

FundingSUPSI-ISTePS authors are supported by EU FoF 2012 ProjectwhiteR – white room based on Reconfigurable Robotic Island forOptoelectronics [contract 609228]. CNR authors are supportedby MIUR Flagship Initiative [FdF-SP1-T2.1] Project GenericEvolutionary Control Knowledge-based mOdule (GECKO).

Note1. http://jade.tilab.com – version 4.3.0.

ReferencesAgentLink. 2005. “Agent Technology: Computing as Interaction.”

Accessed July 2015. www.agentlink.org/roadmap/al3rm.pdfBabiceanu, R., F. Chen, and R. Sturges. 2004. “Framework for

the Control of Automated Material Handling Systems Usingthe Holonic Manufacturing Approach.” InternationalJournal of Production Research 42 (17): 3551–3564.doi:10.1080/00207540410001705284.

Baptiste, P., C. Le Pape, and W. Nuijten. 1995. “IncorporatingEfficient Operations Research Algorithms in Constraint-Based Scheduling.” Proceedings of the First InternationalWorkshop on Artificial Intelligence and OperationsResearch, Timberline, OR, June 6–10.

Baptiste, P., C. Le Pape, and W. Nuijten. 2001. “Constraint-Based Scheduling, Applying Constraint Programming toScheduling Problems.” International Series in OperationsResearch & Management Science 39 (1): 1–18.

Bertsekas, D. P. 2001.“Auction Algorithms.” In Encyclopedia ofOptimization, 73–77. Springer US. doi:10.1007/0-306-48332-7_15.

Bonabeau, E., M. Dorigo, and G. Theraulaz. 1999. SwarmIntelligence: From Natural to Artificial System. New York:Oxford University Press.

Borgo, S., A. Cesta, A. Orlandini, R. Rasconi, M. Suriano, and A.Umbrico. 2014. “Towards a Cooperative Knowledge-basedControl Agent for a Reconfigurable Manufacturing Plant.”In Proceedings of the 19th IEEE International Conferenceon Emerging Technology and Factory Automation. IEEE.doi:10.1109/ETFA.2014.7005226.

Brennan, R., P. Vrba, P. Tichy, A. Zoitl, C. Sünder, T. Strasser,and V. Marik. 2008. “Developments in Dynamic andIntelligent Reconfiguration of Industrial Automation.”Computers in Industry 59 (6): 533–547. doi:10.1016/j.compind.2008.02.001.

Bussmann, S., N. Jennings, and M. Wooldridge. 2004.Multiagent Systems for Manufacturing Control. Berlin:Springer.

Carpanzano, E., A. Cesta, F. Marinò, M. Mazzolini, A. Orlandini,R. Rasconi, and A. Valente. 2012. “Closed-Loop Productionand Automation Schedule Execution in RMSs under UncertainEnvironmental Conditions.” In Proceedings of the 17th IEEE

Figure 10. Volumes comparison for Cross layout in presence of module failures occurring during the period depicted by the grey areas.

16 E. Carpanzano et al.

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

International Conference on Emerging Technology andFactory Automation, Krakow.

Carpanzano, E., A. Cesta, A. Orlandini, R. Rasconi, and A.Valente. 2014. “Intelligent Dynamic Part Routing Policiesin Plug&Produce Reconfigurable Transportation Systems.”CIRP Annals – Manufacturing Technology 63 (1): 425–428.doi:10.1016/j.cirp.2014.03.111.

Carpanzano, E., and F. Jovane. 2007. “Advanced AutomationSolutions for Future Adaptive Factories.” CIRP Annals –Manufacturing Technology 56 (1): 435–438. doi:10.1016/j.cirp.2007.05.104.

Cesta, A., G. Cortellessa, S. Fratini, and A. Oddi. 2009.“Developing an End-to-End Planning Application from aTimeline Representation Framework.” In Proceedings ofthe 21st Innovative Applications of Artificial IntelligenceConference, Pasadena, CA.

Cesta, A., A. Orlandini, and A. Umbrico. 2013. “Toward aGeneral Purpose Software Environment for Timeline-BasedPlanning.” 20th RCRA International Workshop onExperimental Evaluation of Algorithms for SolvingProblems with Combinatorial Explosion, Rome, June 14.

Cucinotta, T., A. Mancina, G. F. Anastasi, G. Lipari, L.Mangeruca, R. Checcozzo, and F. Rusina. 2009. “A Real-Time Service-Oriented Architecture for IndustrialAutomation.” IEEE Transactions on Industrial Informatics5 (3): 267–277. doi:10.1109/TII.2009.2027013.

Davenport, A. J., C. Gefflot, and J. C. Beck. 2001. “Slack-basedTechniques for Robust Schedules.” In Proceedings of the 6thEuropean Conference on Planning, Toledo, Spain.

Demeulemeester, E. L., and W. Herroelen. 2002. “ProjectScheduling: A Research Handbook.” In InternationalSeries in Operations Research & Management Science.Vol. 49. Boston, MA: Kluwer Academic Publishers.

Dotoli, M., and M. P. Fanti. 2004. “Coloured Timed Petri NetModel for Real-Time Control of Automated Guided VehicleSystems.” International Journal of Production Research 42(9): 1787–1814. doi:10.1080/00207540410001661364.

Duffie, N., and P. Kaltjob. 1998. “Dynamics of Real-TimeDistributed Scheduling in Multiple-Machine HeterarchicalManufacturing Systems.” CIRP Annals - ManufacturingTechnology 47 (1): 415–418. doi:10.1016/S0007-8506(07)62864-9.

El Sakkout, H. E., and M. G. Wallace. 2000. “Probe BacktrackSearch for Minimal Perturbation in Dynamic Scheduling.”Constraints 5 (4): 359–388. doi:10.1023/A:1009856210543.

Fazlollahtabar, H., and N. Mahdavi-Amiri. 2013. “Producer’sBehavior Analysis in an Uncertain Bicriteria Agv-BasedFlexible Jobshop Manufacturing System with ExpertSystem.” The International Journal of AdvancedManufacturing Technology 65 (9–12): 1605–1618.doi:10.1007/s00170-012-4283-0.

Fazlollahtabar, H., and M. Saidi-Mehrabad. 2014. “DelayOptimization in a Multiple AGV System.” InternationalJournal of Swarm Intelligence and EvolutionaryComputation 3 (109): 1–4.

Ferber, J. 1999. Multi-Agent Systems: An Introduction toDistributed Artificial Intelligence. Vol. 1. Reading: Addison-Wesley.

Gungor, V. C., D. Sahin, T. Kocak, S. Ergut, C. Buccella, C.Cecati, and G. P. Hancke. 2011. “Smart Grid Technologies:Communication Technologies and Standards.” IEEETransactions on Industrial Informatics 7 (4): 529–539.doi:10.1109/TII.2011.2166794.

Hegny, I., O. Hummer, A. Zoitl, G. Koppensteiner, and M. Merdan.2008. “Integrating Software Agents and IEC 61499 Realtime

Control for Reconfigurable Distributed ManufacturingSystems.” In International Symposium on IndustrialEmbedded Systems, 249–252. France: Le Grand Motte.

Heineman, G., G. Pollice, and S. Selkow. 2008. “GraphAlgorithms.” In Algorithms in a Nutshell, 136–171.Sebastopol, CA: O’Reilly Media.

Heragu, S., R. Graves, B. Kim, and A. St. Onge. 2002.“Intelligent Agent-Based Framework for ManufacturingSystems Control.” IEEE Transactions on Systems, Man andCybernetics, Part A: Systems and Humans 32 (5): 560–573.doi:10.1109/TSMCA.2002.804788.

Herroelen, W., and R. Leus. 2004. “The Construction of StableProject Baseline Schedules.” European Journal ofOperational Research 156 (3): 550–565. doi:10.1016/S0377-2217(03)00130-9.

IEC 61499. 2005. “Function Blocks, Part 1–4. InternationalElectrotechnical Commission Std. IEC 61499.” AccessedApril 2014. www.iec.ch

Jensen, M. T. 2001. “Improving Robustness and Flexibility ofTardiness and Total Flow-time Job Shops Using RobustnessMeasures.” Journal of Applied Soft Computing 1: 35–52.doi:10.1016/S1568-4946(01)00005-9.

Jorge Leon, V., S. D. David Wu, and R. H. Storer. 1994.“Robustness Measures and Robust Scheduling for JobShops.” IIE Transactions. 26 (5): 32–43. doi: 10.1080/07408179408966626.

Ko, J., S. J. Hu, and T. Huang. 2005. “Reusability Assessmentfor Manufacturing Systems.” CIRP Annals – ManufacturingTechnology 54 (1): 113–116. doi: 10.1016/S0007-8506(07)60062-6.

Koenig, S., C. Tovey, M. Lagoudakis, V. Markakis, D. Kempe,P. Keskinocak, A. Kleywegt, A. Meyerson, and S. Jain.2006. “The Power of Sequential Single-Item Auctions forAgent Coordination.” In Proceedings of the NationalConference on Artificial Intelligence, 1625–1629. PaloAlto, CA: AAAI.

Koren, Y., U. Heisel, F. Jovane, T. Moriwaki, G. Pritschow, G.Ulsoy, and H. Van Brussel. 1999. “ReconfigurableManufacturing Systems.” CIRP Annals – ManufacturingTechnology 48 (2): 527–540. doi:10.1016/S0007-8506(07)63232-6.

Koren, Y., S. J. Hu, and T. W. Weber. 1998. “Impact ofManufacturing System Configuration on Performance.”CIRP Annals – Manufacturing Technology 47 (1): 369–372.doi:10.1016/S0007-8506(07)62853-4.

Koren, Y., and M. Shpitalni. 2010. “Design of ReconfigurableManufacturing Systems.” Journal of Manufacturing Systems29 (4): 130–141. doi:10.1016/j.jmsy.2011.01.001.

Kuruvilla, S., S. Gokhale, and S. Sastry. 2008. “ReliabilityEvaluation of Reconfigurable Conveyor Systems.” InProceedings of IEEE International Conference onAutomation Science and Engineering, 929–934. Arlington, VA

Lagoudakis, M. G., E. Markakis, D. Kempe, P. Keskinocak, A.Kleywegt, S. Koenig, C. Tovey, A. Meyerson, and S. Jain.2005. “Auction-Based Multi-Robot Routing.” In Proceedingsof Robotics: Science and Systems, Cambridge, MA.

Lee, Y.-H., S. R. T. Kumara, and K. Chatterjee. 2003.“Multiagent-Based Dynamic Resource Scheduling forDistributed Multiple Projects Using a Market Mechanism.”Journal of Intelligent Manufacturing 14 (5): 471–484.doi:10.1023/A:1025753309346.

Leitãoa, P., and F. Restivob. 2006. “ADACOR: A HolonicArchitecture for Agile and Adaptive ManufacturingControl.” Computers in Industry 57 (2): 121–130.doi:10.1016/j.compind.2005.05.005.

International Journal of Computer Integrated Manufacturing 17

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5

Leus, R. 2003. “The Generation of Stable Project Plans.” PhDdiss., Katholieke Universiteit Leuven.

Magzhan, K., and H. Mat Jani. 2013. “A Review andEvaluations of Shortest Path Algorithms.” InternationalJournal of Scientific & Technology Research 2 (6): 99–104.

Mantel, R. J., and H. R. A. Landeweerd. 1995. “Design andOperational Control of an AGV System.” InternationalJournal of Production Economics 41 (1–3): 257–266.doi:10.1016/0925-5273(95)00018-6.

Matta, A., M. Tomasella, and A. Valente. 2007. “Impact ofRamp-Up on the Optimal Capacity-Related ReconfigurationPolicy.” International Journal of Flexible ManufacturingSystems 19 (3): 173–194. doi:10.1007/s10696-007-9023-7.

Muscettola, N. 1994. “HSTS: Integrating Planning and Scheduling.”In Intelligent Scheduling, edited by M. Zweban and M. S. Fox,169–212. Palo Alto, CA: Morgan Kaufmann Publishers.

Qiao, B., and J. Zhu. 2001. “Agent-Based IntelligentManufacturing System for the 21st Century.” InProceedings of the International Forum for Graduates andYoung Researchers of EYPO. Hannover: The WorldExposition in Germany.

Rasconi, R., A. Cesta, and N. Policella. 2010. “ValidatingScheduling Approaches against Executional Uncertainty.”Journal of Intelligent Manufacturing 21 (1): 49–64.doi:10.1007/s10845-008-0172-7

Schild, K., and S. Bussmann. 2007. “Self-Organization inManufacturing Operations.” Communications of the ACM50 (12): 74–79. doi:10.1145/1323688.

Sevaux, M., and K. Sorensen. 2002. A Genetic Algorithm forRobust Schedules in a Just-in-Time Environment. TechnicalReport, University of Antwerp, Faculty of Applied Economics.

Singh, S. P., and M. K. Tiwari. 2002. “Intelligent AgentFramework to Determine the Optimal Conflict-Free Pathfor an Automated Guided Vehicles System.” InternationalJournal of Production Research 40 (16): 4195–4223.doi:10.1080/00207540210155783.

Smith, S. F. 1994. “OPIS: A Methodology and Architecture forReactive Scheduling.” In Intelligent Scheduling, edited byM. Zweban and M. S. Fox. San Francisco, CA: MorganKaufmann Publishers.

Stork, F. 2001. “Stochastic Resource-Constrained ProjectScheduling.” PhD diss., Technische Universitat Berlin.

Strasser, T., A. Valentini, V. Vyatkin, A. Zoitl, J. Christensen, A.Valente, E. Carpanzano, J. Chouinard, H.Mayer, and A. Kopitar.2012. “The IEC 61499 Function Block Standard: Launch andTakeoff.” In ISA Automation Week Conference, Orlando, FL.

To, T., and J. Ho. 2002. “A Genetic Algorithm for ConfiguringReconfigurable Conveyor Components in a FlexibleAssembly Line System.” In Proceedings of ManufacturingComplexity Network Conference, Cambridge, UK.

Valckenaers, P., and H. Van Brussel. 2005. “HolonicManufacturing Execution Systems.” CIRP Annals –Manufacturing Technology. 54 (1): 427–432. doi:10.1016/S0007-8506(07)60137-1.

Valente, A., and E. Carpanzano. 2011. “Development of Multi-Level Adaptive Control and Scheduling Solutions for

Shop-Floor Automation in Reconfigurable ManufacturingSystems.” CIRP Annals – Manufacturing Technology. 60(1): 449–452. doi:10.1016/j.cirp.2011.03.036.

Valente, A., A. Cataldo, and E. Carpanzano. 2013. “ADispatching Algorithm and Software Tool for Managingthe Part Flow on Reconfigurable Transportation System.”In CIRP Sponsored Conference on Manufacturing Systems,Vol. 7, 497–502. Setubal, Portugal.

Valente, A., M. Mazzolini, and E. Carpanzano. 2015. “AnApproach to Design and Develop Reconfigurable ControlSoftware for Highly Automated Production Systems.”International Journal of Computer IntegratedManufacturing 28 (3): 321–336. doi:10.1080/0951192X.2014.880810.

Vallee, M., M. Merdan, W. Lepuschitz, and G. Koppensteiner2011. “Decentralized Reconfiguration of a FlexibleTransportation System.” IEEE Transactions on IndustrialInformatics 7 (3): 505–516. doi:10.1109/TII.2011.2158839.

Van Brussel, H. 1990. “Planning and Scheduling of AssemblySystems.” CIRP Annals - Manufacturing Technology 39 (2):637–644. doi:10.1016/S0007-8506(07)63000-5.

Van Brussel, H., J. Wyns, P. Valckenaers, L. Bongaerts, and P.Peeters. 1998. “Reference Architecture for HolonicManufacturing Systems: PROSA.” Computers in Industry37 (3): 255–274. doi:10.1016/S0166-3615(98)00102-X.

Vrba, P. 2005. “Simulation in Agent-Based Control Systems:MAST Case Study.” International Journal ofManufacturing Technology and Management 8 (1–2–3):175–187.

Vyatkin, V. 2011. “IEC 61499 as Enabler of Distributed andIntelligent Automation: State-of-the-Art Review.” IEEETransactions on Industrial Informatics 7 (4): 768–781.doi:10.1109/TII.2011.2166785.

Weyns, D., H. Parunak, and O. Shehory. 2008. “The Future ofSoftware Engineering and Multiagent Systems.”International Journal of Agent-Oriented SoftwareEngineering 3 (4): 369–377.

Wooldridge, M. 1999. Intelligent Agents, Multiagent Systems: Amodern Approach to Distributed Artificial Intelligence.Weiss: MIT Press.

Wooldridge, M. 2002. An Introduction to Multiagent Systems.New York: Wiley.

Wu, N., and M. Zhou. 2005. “Modeling and DeadlockAvoidance of Automated Manufacturing Systems withMultiple Automated Guided Vehicles.” IEEE Transactionson Systems, Man and Cybernetics, Part B (Cybernetics). 35(6): 1193–1202. doi: 10.1109/TSMCB.2005.850141.

Zambonelli, F., and A. Omicini. 2004. “Challenges and ResearchDirections in Agent-Oriented Software Engineering.”Autonomous Agents and Multi-Agent Systems 9 (3): 253–283. doi:10.1023/B:AGNT.0000038028.66672.1e.

Zhang, W. J., and C. A. Van Luttervelt. 2011. “Toward aResilient Manufacturing System.” CIRP Annals –Manufacturing Technology 60 (1): 469–472. doi:10.1016/j.cirp.2011.03.041.

18 E. Carpanzano et al.

Dow

nloa

ded

by [

Con

sigl

io N

azio

nale

del

le R

icer

che]

at 0

9:48

17

July

201

5