Sequencing With Decentralized Control Using Modular Highest-Density Conveyor Systems

We present a decentralized sequencing algorithm applicable to modular high(est)-density conveyor systems that enables items to enter the system randomly from multiple input points. They are rearranged within the system to be retrieved at an assigned output point observing a predefined sequence. A variety of applications benefits from this, such as storing and retrieving, order picking, packing and shipping operations as well as Just-in-Sequence (JiS) applications of production systems. We prove that our decentralized algorithm– based on the concept of logical time– is able to prevent deadlocks, livelocks, and starvation. It guarantees a complexity of order $\mathcal {O}(n^{2})$ at module level depending on system size $n$ . Using throughput evaluations, we show how to parameterize the decentralized sequencing algorithm to optimize its performance. Furthermore, we deduce that small batch sizes, high conveying speeds, a high number of output points, or non-perforated network structures increase system throughput. A simulative demonstration of the developed algorithm can be found at our institute channel. Note to Practitioners—The need for flexibility, scalability, and robustness has led to decentralized control concepts becoming more and more popular in practice. In the field of material handling systems, transportation, storage, sortation, and picking functionality is already being realized based on decentralized control. In this paper, we present a decentralized control algorithm which dispatches randomly introduced items to match a specified sequence at their assigned destination. It applies to systems including multiple input and output points ( $(m:n)$ setting) and thus allows for parallel order processing and customizable system configurations of various application scenarios. As sequencing combines routing, buffering and relocation functionality, additionally, an overall logic for implementing transport, storage and retrieval, sortation and picking systems is provided as well.

Sequencing With Decentralized Control Using Modular Highest-Density Conveyor Systems Julia Fleischmann and Kai Furmans , Member, IEEE Abstract-We present a decentralized sequencing algorithm applicable to modular high(est)-density conveyor systems that enables items to enter the system randomly from multiple input points.They are rearranged within the system to be retrieved at an assigned output point observing a predefined sequence.A variety of applications benefits from this, such as storing and retrieving, order picking, packing and shipping operations as well as Just-in-Sequence (JiS) applications of production systems.We prove that our decentralized algorithm -based on the concept of logical time -is able to prevent deadlocks, livelocks, and starvation.It guarantees a complexity of order O(n 2 ) at module level depending on system size n.Using throughput evaluations, we show how to parameterize the decentralized sequencing algorithm to optimize its performance.Furthermore, we deduce that small batch sizes, high conveying speeds, a high number of output points, or non-perforated network structures increase system throughput.A simulative demonstration of the developed algorithm can be found at our institute channel.
Note to Practitioners-The need for flexibility, scalability, and robustness has led to decentralized control concepts becoming more and more popular in practice.In the field of material handling systems, transportation, storage, sortation, and picking functionality is already being realized based on decentralized control.In this paper, we present a decentralized control algorithm which dispatches randomly introduced items to match a specified sequence at their assigned destination.It applies to systems including multiple input and output points ((m : n) setting) and thus allows for parallel order processing and customizable system configurations of various application scenarios.As sequencing combines routing, buffering and relocation functionality, additionally, an overall logic for implementing transport, storage and retrieval, sortation and picking systems is provided as well.

I. INTRODUCTION
T ODAY'S highly complex, dynamic, and uncertain industrial environments require sophisticated automated systems to operate efficiently.Firms are looking for solutions that can be deployed quickly, reconfigured without long The authors are with the Department of Mechanical Engineering, Institute for Material Handling and Logistics, Karlsruhe Institute of Technology, 76131 Karlsruhe, Germany (e-mail: julia.fleischmann@kit.edu;kai.furmans@kit.edu).
Color versions of one or more figures in this article are available at https://doi.org/10.1109/TASE.2023.3272971.
Digital Object Identifier 10.1109/TASE.2023.3272971downtimes, and are robust to local failures.Furthermore, automation is also being challenged to operate in smaller spaces to reduce costs or to operate closer to the customer.Decentralized systems offer such flexibility, robustness, scalability, and fault-tolerance [1] because of their modular design that only requires localized information and decision-making.This allows, for example, a company to flexibly extend or modify, maintain and move their material handling equipment without external expertise.While decentralized system design provides this number of benefits, a major challenge is their high risk for creating deadlocks, livelocks, and starvation [2], as the overall system state can never be analyzed in its entirety.Additionally, the necessary decentralized communication effort may affect system performance.Production and logistics environments often require products or parts to arrive in a pre-defined sequence for being handled or processed.In storing and retrieving, order picking, packing and shipping operations as well as Just-in-Sequence (JiS) applications, manual work is reduced and overall process efficiency increases if items arrive at their point of use in the correct order of consumption.This work thus presents a decentralized sequencing algorithm, where items -referred to as transport units (TUs) -randomly arrive at multiple input points, are rearranged within the system, such that they exit the system at an assigned output point observing the predefined sequence required at their point of use.TUs represent physical unit loads, such as parcels, boxes, small load carriers etc. or even bulk materials, liquids or gases when combined with suitable packaging and/or load carriers.These are organized in batches of a certain size k corresponding to the number of TUs included in the batch.Each TU of a batch is assigned a rank to specify the predefined unloading sequence at its output points.We consistently characterize batches using colors, while the ranks of TUs within a batch are denoted with numbers.
The system is made up of identical right-angle-transfer conveyor modules without any supervising element.These act autonomously based on local data bases and control units.Connecting several adjacent modules creates the overall sequencing system.The presented algorithm is capable of operating in highest-density1 conveyor systems, i.e., it guarantees maximum achievable space efficiency.In Figure 1 we show an example use case, where three input conveyors provide items from an upstream supplying station for sequenced delivery to four processing stations of a downstream process.
The paper is structured as follows: Section II reviews the current state of the art regarding the investigated sequencing problem.In Section III, we present the decentralized sequencing algorithm by specifying the interactions at module level as well as the decentralized system design.The absence of deadlocks, livelocks, and starvation is proven in Section IV.We investigate the algorithmic complexity in Section V. Section VI analyzes the system performance using simulation studies.We summarize the central conclusions of our work in Section VII.

II. STATE OF THE ART
Decentralized algorithms are already applied to realize specific material handling operations using modular conveyor systems (cf.Section II-A).Restrictive approaches for sequencing systems have been developed as well (cf.Section II-B).

A. Conveyor Systems With Decentralized Control
Existing approaches in the field of decentralized controlled conveyor systems enable transporting, storing, picking, and sorting functionalities.These are summarized in Table I.The system density follows from [3].In high-density systems, interfering items prevent accessing desired items.We further define highest-density systems as those which can operate with just one empty module.The implemented routing strategy is classified into offline and online approaches.With the former, item routes are planned entirely from start to destination before initiating transportation, whereas with the latter, they are planned incrementally with stepwise item movements [4].Systems with online routing are synchronized involving a higher level coordination element to ensure that all modules execute the algorithmic phases consistently.Therefore, buffer times are incorporated within the negotiation cycles, which can reduce system performance [5].Furthermore, they necessarily require rectangular grid layouts [6].Based on the deadlock handling strategies according to [7], we investigate whether and how the presented algorithms ensure system liveliness.
Low-density systems are studied most commonly incorporating an offline route planning approach.Route planning in high(est)-density systems requires relocating interfering items.So far, this is only possible using online approaches, which suffer from the drawbacks stated above.None of the existing 2 Not generally proven and only under certain conditions.approaches provides a decentralized algorithm based on offline route planning applying to high(est)-density conveyor systems.Thus, preventing deadlocks or ensuring system liveliness in general under these conditions remains unresolved as well.Apart from [11], complexity aspects of the presented decentralized algorithms are not studied.

B. Approaches for Conveyor-Based Sequencing Systems
Several approaches for conveyor-based sequencing systems have been proposed in scientific research (cf.Table II).We classify them according to their level of decentralization.Processing several batches simultaneously relies on an (m : n) setting with m > 1 input and n > 1 output points.We investigate density, routing, and integrated deadlock handling strategies by analogy with Section II-A.
All of the presented approaches of Table II offer a solution for sequencing in modular conveyor systems.The majority require centralized system functionality where essential algorithmic parts, such as path finding, data holding, or deadlock handling, are delegated to a centralized element.Often, single batch problems are considered.Several of the proposed systems reserve unoccupied parts for relocations, which reduces the achievable density.Online routing algorithms are used frequently, such that only synchronized systems with rectangular network structures can be realized [6].None of the presented approaches provides decentralized sequencing from multiple input to multiple output points in general high(est)-density conveyor systems while ensuring system liveliness in terms of deadlock, livelock, and starvation prevention.This paper aims to comprehensively close this research gap.

III. DECENTRALIZED SEQUENCING
We present a decentralized sequencing algorithm starting with the overall design approach to outline its main ideas at system level (cf.Section III-A).Based on that, we detail the concept of decentralized interactions at module level (cf.Section III-B).For demonstration, we use a showcase system based on square right-angle-transfer conveyor modules (cf.Section III-C).

A. Design Approach
The overall route of each TU initially starts at its assigned input module where it is introduced and ends at its assigned output module where it is unloaded.To observe the predefined unloading sequences at the output modules, buffering is necessary.We split the overall routes of buffered TUs into sub-routes, where buffer modules are used as intermediate destinations (cf.Section III-A1).These need to be allocated to support efficient sequencing (cf.Section III-A2).Path finding for each (sub-)route considers the resulting system occupation (cf.Section III-A3).
1) Transport Unit Routing: Processing a TU means specifying its route through the system.We refer to a TU as requested if its corresponding output module is able to claim this TU, as all necessary preceding TUs have already been scheduled there.Thus, only requested TUs may be routed to their output module.
Within the decentralized sequencing algorithm, we define two types of routes: • active routes starting at an input module and/or ending at an output module and • passive routes starting and ending at a sequencing module for buffering.Active routes are necessary to introduce arriving TUs into the system and to unload requested TUs at their output modules.Thus, active routes generally guide the process of sequencing.Passive routes, instead, depend on active routes.If a buffered TU interferes with an active route, a passive route is initiated for relocation.This allows us to represent the overall route of each buffered TU from the input to the output module as a combination of one active route at the beginning and end and an arbitrary number of passive routes in between (cf. Figure 2).In case a TU is requested when arriving at its input module, the two active routes are consolidated such that it is routed directly from the input to the output module.
From the perspective of a TU, sequencing follows the flowchart given in Figure 3.This is achieved by decentralized interaction of the autonomous conveyor modules (cf.Section III-B).

TABLE III BUFFER MODULE ALLOCATION
2) Buffer Module Allocation: To enable efficient sequencing, we develop the unloading sequence-based buffer selection rule for active routes, while for passive routes, the distancebased buffer selection rule applies (cf.Table III).Both are designed to meet different requirements of the specific route type when identifying buffer modules.
3) Path Characteristics: While the path of an active route generally includes multiple modules, each passive route represents exactly one relocation step of a TU to an adjacent module (cf.Table III).Therefore, clearing the path of an active route due to an interfering buffered TU may require moving several TUs in a chain -especially when system density is high.We refer to this chain of relocation steps as a relocation route, i.e. a relocation route may combine multiple passive routes in direction to a non-buffering module (cf. Figure 4).
For efficiently processing TUs, paths of active as well as relocation routes aim to consider: • the length of the route, as this defines the time for transferring the TU, • the number of buffered TUs on the route, as these need to be relocated to be able to access there, and • the number of directional changes on a route, as this implies a certain delay due to acceleration and Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.deceleration as well as switching the conveyor modules between their rectangular transport directions.

B. Algorithm Concept
The decentralized interactions of the autonomous modules are designed to process TUs within the system as illustrated in Figure 3. Active routes are initiated observing the necessary predecessor-successor relations (cf.Section III-B1).Each active route is planned from start to destination (cf.Section III-B2) before being executed (cf.Section III-B3).
1) Route Initiation: Route initiation notifies the module currently assigned to a TU that planning an active route for this TU can start.Input modules identify arriving TUs and register them at their output module.Based on the current state of its unloading sequence, the latter is able to determine whether the active route for the corresponding TU requires a buffer module or goes directly to the output module.In case of buffering, the output module requests potential buffer modules based on the unloading sequence-based buffer selection rule for active routes (cf.Section III-A2).The output module then returns the destination of the active route to the requesting input module.When scheduling a TU at its output module, previously buffered ones might become requested.Their assigned output module requests such buffered TUs directly at their allocated buffer module to initiate an active route for unloading.Due to relocations of interfering buffered TUs, the local information at the output module about allocated buffer modules may be outdated up to this request.Buffer modules discard outdated requests if the allocation no longer applies.Additionally, each reallocated buffer module updates the corresponding output module, which we will discuss in more detail when presenting passive route planning in Section III-B2.c.For each active route, the message received from the output module triggers route planning at the input and buffer module, respectively.
2) Route Planning: Planning an active route follows the series of acquiring the planning authorization (cf.Section III-B2.a),selecting the path of modules forming the active route (cf.Section III-B2.b), and negotiating reservations for the active and all of its induced passive routes for relocation (cf.Section III-B2.c).
a) Authorization procedure: The decentralized authorization procedure (cf. Figure 5) guarantees deadlock-free system operation within route planning as all routes are planned sequentially.Executing these routes occurs independently of planning procedures (cf.Section III-B3).At any time, there is exactly one authorized module within the system.Only this module is entitled to plan an active route.At system configuration, it is initialized with the first input module of the system.Whenever the authorization is passed, all input and sequencing modules are notified as only these initiate active routes.
Each time a module intends to start planning an active route, it first sends a request to the currently authorized module to be authorized next.As soon as this completed planning its active route, it passes the authorization to the next module among the incoming requests.Active routes for unloading are prioritized over those for buffering, as the former directly contribute to system throughput.If an authorization request is not granted, the notification of changed authorization triggers a new request to the currently authorized module.
b) Path selection: Path selection aims to identify the path of modules for an active route based on the criteria defined in Section III-A3.We develop an adapted decentralized A* algorithm, which starts at the initiating module of the active route.Every search iteration occurs locally at the currently best module to be explored.This module is notified to continue the A* search providing all currently available path information to it.It updates this path information, while continuing the open list of known modules by its adjacent modules, and identifies the best module to be explored next.The tentative path cost t n for an adjacent module n proceeding from module m is calculated as follows: The current tentative value t m represents the sum of penalty terms, resulting from relocations and directional changes from the start module to the path predecessor of module m so far.Added to this is the length of the detour (d n e − d * e ) measured in module lengths when routing via neighbor n.The penalty term for buffer module relocation p b results from the current module state, while the penalty term for directional change p c results from the transmitted path predecessor of module m ( p b , p c > 0).p b and p c can be parameterized to Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.[14]) specifically influence path selection.However, optimality is guaranteed only if the tentative cost estimation is admissible according to the A* requirements, i.e. path costs must never be overestimated (cf.[20]).Adding p c depends on the path predecessor and may retroactively change the cost estimate of different paths.To satisfy admissibility, p c cannot be set arbitrarily, which we will discuss in more detail in Section VI-B.Path selection is finished, when the route destination module is notified.The identified path is fixed by confirming the corresponding predecessor modules backward up to the start module of the active route.

TABLE IV NOTATION FOR DEFINING RESERVATION CONDITIONS (BASED ON
c) Route reservation: We apply a time window-based approach using the concept of logical time.It builds upon the preliminary work of [21] and [14].Each conveyor module is assigned a local logical clock.Transferring a TU requires reserving a logical time window at all modules of its route.Therefore, each module of the system locally holds a reservation table in which all of its transfers are scheduled.These are executed in ascending order of their reserved logical time windows.When completing a transfer, the involved modules update their logical clocks accordingly.Thus, clock times refer to events rather than physical time points.
For route reservation within the developed decentralized sequencing algorithm, the involved modules negotiate logical time windows matching their local reservation tables.Sequencing requires the following reservation conditions (R1) to (R6) to be satisfied.We use the notation according to [14] (cf.Table IV).
The outgoing transport of each TU at each module is scheduled after its incoming transport there.
Each pair of adjacent modules i and j along the transport route of a TU agrees on the timing regarding their common event.Combining (R1) and (R2) yields ascending logical time windows within the event sequence of each process.
Each module can hold only one TU at a time.Thus, the respective logical time windows according to (R1) for two routes scheduled at the same module may not overlap.Upcoming events are scheduled in future logical time regarding the reserved module to satisfy the causal event dependencies (cf.[21]).
Each succeeding TU may not enter at the assigned output module before any of its predecessors.This upholds the predefined unloading sequences.
Each buffered TU blocks its allocated buffer module for an unlimited time period until its predecessor is planned or it is relocated (cf. Figure 3).Thus, (R6) defines a buffer module.Establishing a set of feasible logical time windows adhering to reservation conditions (R1) to (R6) is realized via decentralized negotiations according to Figure 6.Adjacent modules iteratively suggest time windows based on their existing reservations until an agreement is found.Due to reservation condition (R6), this requires a passive route planning subroutine for buffer modules of active routes to relocate their blocking TUs.
To negotiate a finite logical time window on buffer modules after the buffered TU enters, the indefinite reservation of reservation condition (R6) needs to be resolved first, i.e. it becomes a non-buffering module.According to Table III, we apply a step-wise relocation approach which moves a buffered TU from its currently allocated buffer module to an adjacent one.As we operate in highest-density systems, this might involve relocating several other buffer modules (cf. Figure 4).
Figure 7 shows the passive route planning.The assigned buffer module of the blocking TU first identifies the closest Fig. 7. Passive route reservation. 4  non-buffering module using the distance-based buffer selection rule for passive routes.Then, relocation requests are successively sent via the port of a shortest path directing to the identified module.To end up with feasible logical time windows at all involved modules according to the defined reservation conditions, the logical time at which a non-buffering module can take over an indefinite buffer reservation dictates the relocation negotiations.After receiving the relocation confirmation at the initially blocked module of the active route, it is now able to respond to its received reservation request (cf. Figure 6).
3) Transport Execution: After confirming the reservation at the start module of an active or passive route, TU movement is initiated.In the decentralized system, transferring a TU occurs if and only if both involved modules agree on the next logical time event within their respective reservation tables.This is coordinated by exchanging transport request and confirmation messages.Whenever a transport event is executed, the involved modules forward their logical clocks: The sending module updates its logical clock to T out , the receiving one to T in of their reserved logical time windows for the corresponding TU.This guarantees an unambiguous transport execution sequence for every module in the system providing deadlock-free system operation during transport execution (cf.Section IV-A).

C. Showcase System
The presented decentralized sequencing algorithm is implemented within a showcase system using right-angle-transfer conveyor modules, such as the FlexConveyor of [8].They can be flexibly combined via Plug-&Play technology, which allows creating any kind of customized sequencing system.Each module uses its own control unit for decision making based on a local database.At each of the four module edges, there is an interface for communication with the adjacent modules.Communication with non-adjacent modules within the network requires a corresponding message transmission mechanism, which forwards messages via a series of adjacent modules to the respective recipient.Therefore, any communication protocol is valid which allows specifying the payload as well as the sender and recipient of a message, e.g.TCP/IP. 4The legend of Figure 6 also applies to Figure 7.As we presented the algorithmic operations assuming faultless communication and uninterrupted availability of conveyor modules, suitable error handling is vital within real-world applications.The decentralized system architecture based on the local attributes and methods of the conveyor modules to enable sequencing are summarized in Figure 8.
Each module can handle one TU at a time (cf.[8]).Transferring a TU between two adjacent modules requires occupying both of these modules until the TU is entirely located on the next module along its route.We divide the set of all installed conveyor modules into input, output and sequencing modules based on their role within the network.The input modules link from the upstream process to the sequencing system to introduce arriving TUs.Output modules provide them to the downstream process after processing by the intermediate sequencing modules.
For demonstrating our showcase system, we implemented an agent-based simulation model using the simulation software AnyLogic.Each conveyor module is represented by an own agent instance.These agents interact by events, such as sending or receiving messages.Generally, stable system operation can only be guaranteed if the inflow of TUs arriving at the system can be physically processed using the available buffer capacity of the network.TU movements necessarily require at least one unoccupied sequencing module in the system.Thus, when introducing new TUs, the input modules need to ensure that the sum of TUs within the system does not exceed (c − 1) for a network comprising c sequencing modules.Within our simulation model, we generate the input data such that sequencing is always feasible for the set of arriving TUs by restricting the maximum processable batch size to (c − 1) as well as the mixing of batches within the arrival characteristics at the input modules.

IV. PREVENTING DEADLOCKS, LIVELOCKS AND STARVATION
Deadlocks, livelocks, and starvation represent a major risk in decentralized controlled systems, as the states of all Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
processes and resources are only locally available.In the following, we prove that the presented sequencing algorithm structurally prevents those due to the specified reservation conditions and communication procedures.We subdivide our investigations into the algorithmic operations as well as the allocation of resources for physically moving TUs, as these both are processed at decentralized module level.

A. Deadlocks
A deadlock arises within a set of processes if each process is waiting for an event of another process in this set [7].
1) Algorithm Operations: The algorithmic operations are deadlock-free if we can guarantee that for each arriving TU a complete route from its input to its output module is initiated in finite time, observing the predefined predecessorsuccessor dependencies.Assuming that there is always at least one unoccupied sequencing module within the system (cf.Section III-C), a feasible solution exists for the set of all necessary active and passive routes.To ensure that this is found, all modules need to use consistent information.Outdated or incomplete local information may create requests which are mutually exclusive.
Local module information is updated when receiving confirmations.The decentralized authorization concept (cf.Section III-B2.a)guarantees that active routes are planned sequentially based on updated system information.Each request is confirmed before receiving a new request concerning another active route.This ensures that each module is in the correct state to respond to an incoming request at any time.As passive route planning interrupts route reservation on the active route, multiple relocation routes are never planned at the same time.Therefore, one non-buffering sequencing module is generally sufficient within the network.The algorithmic operations for sequencing can continuously proceed preventing the system or parts of it from becoming deadlocked.
2) Resource Allocation: Resource allocation for physically transferring the corresponding TUs implies coordinating the utilization of the common system resources.According to [22], a resource deadlock requires the following four conditions to coexist: (D1) Mutual exclusion: Processes claim exclusive control of their required resources.(D2) Hold and wait: Processes hold allocated resources while waiting for further resources.(D3) No preemption: Allocated resources are used to completion and released by the process holding them.(D4) Circular waiting: There is a circular chain of processes, each of which is requesting a resource held by the next process in the chain.To prevent deadlocks, at least one of these four conditions needs to be excluded [22].In modular conveyor systems, conditions (D1) to (D3) are intrinsically satisfied [8].Thus, we need to demonstrate that condition (D4) is prevented.
Referring to Table IV, the overall route of each TU through the system corresponds to a cohesive process starting at an input module and ending at an output module.To observe the necessary predecessor-successor dependencies, planning the overall process of a TU is decomposed by defining active and passive routes.For each buffered TU, an indefinite buffer reservation is created at the allocated resource for buffering according to reservation condition (R6).It is resolved entirely when initiating the active route from the buffer module to the output module.Thus, we obtain a finite overall process for each TU ending up at its output module.It represents a series of ascending logical time windows according to reservation conditions (R1) and (R2).This is used to demonstrate deadlock prevention for resource allocation similar to [14].
The circular wait condition (D4) for a resource deadlock implies a set of TUs holding a chain of conveyor modules within a closed loop.Assuming process P 1 is currently holding resource R 1 , process P 2 resource R 2 and so on, within a circle of adjacent resources R 1 . . .R n .Due to reservation conditions (R1) and (R3), satisfying circular waiting results in the following reservation dependencies for processes P 1 . . .P n : . . .
Based on reservation condition (R2), we obtain for the circular chain of adjacent resources R 1 . . .R n : From this, it follows: which is a contradiction.Thus, circular waiting is excluded by observing the defined reservation conditions such that deadlocks during resource allocation are prevented.

B. Livelocks
A livelock refers to a process indefinitely repeating the same execution sequence without progressing [23].
1) Algorithm Operations: Livelocks exist if modules send and receive messages in an endless loop.Due to sequential route planning (cf.Section IV-A1), we can consider each active route individually.The algorithmic operations terminate at its initiating module if path selection, route reservation, as well as all induced relocation operations terminate.
In path selection (cf.Section III-B2.b),modules which have already been explored are never selected for re-exploration such that messaging loops are generally excluded.Route reservation requires all involved modules of active and passive routes to achieve a feasible reservation schedule according to the defined reservation conditions (R1) to (R6).At any time, there are no more than two actively negotiating modules (cf.Figures 6 and 7).All other involved modules Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
either already received a confirmation or are awaiting a response to their request to continue negotiations.Therefore, we show that each pair of adjacent modules always reaches an agreement on the logical time of transferring the corresponding TU.
Non-buffering modules only hold finite reservations within their local reservation tables.Thus, reservation requests to non-buffering modules are feasible at the latest when the new reservation is scheduled last at both negotiating modules.Repeating identical reservation requests is impossible as the next open time window, the requested module suggests, is later than the requested one.The initiating module of the active route does not hold any reservation scheduled later than that of its allocated TU such that postponing reservations is always possible.Reservation requests to buffer modules induce passive route planning for relocation before continuing reservation on the active route.This resolves the indefinite buffer reservation according to reservation condition (R6) such that it becomes a non-buffering module.
When negotiating passive routes, the non-buffering module sets the time at which it confirms the indefinite buffer reservation.At the requesting module of the passive route, reservation condition (R6) holds.Therefore, it can postpone the scheduled outgoing transport of the relocated buffered TU such that the relocation request is accepted.
2) Resource Allocation: In Section IV-A we showed that dispatching a TU from its input to its output module represents a coherent process composed of active and passive routes.Transport execution follows the set of logical time window reservations in ascending order and defines the order of resource utilization.As input and output modules are distinct, this never creates a closed loop, even if the same resources may be reused within the overall TU process.

C. Starvation
Starvation occurs if a process -not being deadlockedneeds to wait indefinitely as its requested resource is never assigned to it [24].Thus, it will never terminate.
1) Algorithm Operations: Requesting modules await the response of the requested module.Assuming faultless communication, each request returns a valid response in finite time, so starvation is excluded within the algorithmic operations.In Section IV-B, we showed that route planning always terminates.Likewise, the authorization is granted to each requesting input module in finite time.Due to the limited system size and the predecessor-successor relations, an initiating module of an active route cannot be disadvantaged indefinitely when passing the authorization.After a limited number of requests, there will be no other module awaiting to be authorized.
2) Resource Allocation: Resource allocation for transport execution follows the total ordering of the reserved logical time windows.Thus, any process can use the requested resource in finite time.This excludes starvation within resource allocation.

V. COMPLEXITY ANALYSIS
The complexity of our presented decentralized sequencing algorithm is measured by the number of messages N required to sequence a given set of TUs B using the set of conveyor modules M. As the specified routing operations apply to every TU, N linearly depends on |B|.Dispatching a TU from its input to its output module is organized via active routes.No more than two active routes are planned for each TU (cf. Figure 2).Therefore, N = γ • |B| • N a , where N a is the average number of messages required per active route as well as the induced passive routes and γ a non-negative constant (γ ≪ |M|).We derive an upper bound Na based on the given conveyor system indicating the maximum complexity of the presented sequencing algorithm.Na results from the sum of the upper bounds of messages N X a required for every algorithmic sub-part: • Allocating buffer modules N B a : Each active route cannot require more than |M| buffer modules for the planned and blocking TUs, respectively.For allocating a buffer module, no more than |M| requests are necessary to identify an empty module for buffering.This implies • Initiating active routes N I a : Route initiation is triggered when the output module notifies the module currently assigned to a TU.This requires updating the output module every time the TU is relocated.Each active route incorporates less than |M| interfering buffered TUs, each of which is relocated using less than |M| passive routes.Thus, • Authorization procedure N A a : Acquiring the authorization for planning an active route requires less than |M| requests to the authorized module.When the authorization is passed all other relevant modules are notified.This gives • Path selection N S a : Messaging for path selection is driven by the system size, i.e., |M| as each module is notified no more than once for exploration.Thus, • Active route reservation N R a a : Rejecting suggested logical time windows within active route reservation increases with the number of existing reservation entries per module.At any time, there cannot be more than |M| TUs present within the system.Each of these induces less than |M| relocation reservations per module when planning an active route.Thus, the number of reservation entries per module scales with |M| 2 .Each active route incorporates less than |M| negotiating adjacent modules.This results in • Passive route reservation N R p a : Rejecting relocation requests within passive route reservation is finite as due to reservation condition (R6), only reservations scheduled after the last existing outgoing reservation are feasible.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
As discussed for active route initiation, each active route causes less than |M| 2 relocation steps to be negotiated.This implies, • Transport execution N T a : For each active route, no more than |M| 2 reservations are scheduled, as its length as well as the length of its induced relocation routes is limited by |M|.Agreeing on a TU transfer between adjacent modules requires a constant number of messages as transport requests are only sent if the two adjacent modules are ready to execute the next reserved TU transfer.Therefore, From all that follows the upper bound of the number of messages required for the given sequencing problem as Due to the decentralized system design, forwarding these messages is necessary via a series of adjacent modules in case the message sender and recipient are non-adjacent.This represents a linear scaling factor and is therefore incorporated in γ .As we always assume |M| involved modules when determining N a , this indicates an upper bound at module level as well.The system offers |M| control units for message processing -one installed at every module.Therefore, based on the overall algorithm complexity of O(n 3 ) according to (5), the complexity at the level of a single module decreases to O(n 2 ) scaling with system size n in terms of the number of installed modules |M|.

VI. PERFORMANCE ANALYSIS AND ALGORITHM PARAMETERIZATION
In simulation studies, we evaluate the performance of our decentralized sequencing algorithm.We take a 5 × 5 square arrangement of sequencing modules including five input and five output points as a reference network (cf. Figure 9(a)).Batches are randomly assigned to one of the output points with equal probability.Likewise, arriving TUs of these batches are randomly assigned to input points.The time for transferring a TU between two adjacent modules is denoted by t conv , while t li f t represents the time for switching a module between its rectangular transportation modes.We focus on system throughput as key performance indicator. 5

A. Impact of Conveying Speed and Relocation Penalty p b
For isolating the effects of conveying speed, i.e., t conv , in relation to varying values of relocation penalty p b , we initially fix t li f t at 0 s.p c is set to 0 accordingly.The results indicate that system throughput is directly proportional to the conveying speed of the modules (cf. Figure 10).If p b is within the interval of (0 . . .2] the throughput of the given setting is at its maximum.This applies regardless of the batch size k (cf. Figure 11).Increasing or decreasing system occupation is possible by varying the number of input |I | and output points |O| of a given network.Assuming |I | ≫ |O| creates a bottleneck at the unloading process such that system occupation increases.Likewise, when |I | ≪ |O|, system occupation is reduced as the unloading capacity exceeds the loading capacity of the input points.Varying the reference network with 15 input or output points ceteris paribus yields the results shown in the charts of Figure 12.
This implies that the range of p b which maximizes system throughput is not affected by varying batch sizes or system occupation.The minimum at p b = 0 results from setting modules with interfering buffered TUs equal to empty modules.The optimal range is within the interval 0 < p b ≤ 2. p b > 2 causes a major reduction in throughput due to overweighting buffer modules.Within the given grid structure every shortest detour omitting a single buffer module induces two additional steps compared to the shortest route from start to destination.Thus, for p b > 2, this detour is always preferred instead of the shortest path with an induced relocation.This causes interfering buffered TUs to be relocated only if there is no alternative path using detours.Analyzing the average path length of a TU confirms these statements (cf. Figure 13).Transforming the reference network according to Figure 9(b) increases detour lengths within the system.In this case, throughput reduction is observed at p b > 2 as shown in Figure 14.Higher weights for buffer modules are necessary until detours are preferred instead of relocations.
Executing a detour increases solely the transport time of the TU on the active route, while an interfering TU remains positioned at its currently assigned buffer module.However, active and passive routes can be executed simultaneously.While the TU of the active route is moving towards a buffer module, the necessary passive routes for relocation are already processed.To optimize throughput, p b needs to be set greater than 0 and smaller than the difference in the lengths of the shortest path and the shortest detour path between all modules within the network.

B. Interdependencies of Conveying Speed, Lift Time and Path Selection Parameters p b and p c
Due to the linear correlation of t conv and system throughput observed within the previous evaluations, we fix t conv at 1 s for all evaluations of this section.With p b = 1, the effects Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.    of t li f t and p c arise as shown in Figure 15.The effects on throughput are equal for the given setting independent of t li f t , so even if t li f t ≫ t conv holds.This results from the minimum number of directional changes on a particular path which is predetermined by the given network.With p c > 0, unnecessary directional changes can be avoided.However, the  minimum number of direction changes is incurred regardless of t li f t .
As indicated in Section III-B2.b,p c must not be set arbitrarily, as this will prevent path cost estimation from guaranteeing optimality.In this case, the overall optimal path cannot be derived from combining all optimal sub-paths, which is a necessary condition for optimality (cf.Bellman's principle of optimality).Thus, p c must be chosen sufficiently small such that for all possible sub-paths p and p * no identical path costs are generated at any explored module, where p is non-optimal and p * is optimal.For this, p c < ϵ must hold, which, however, also includes highly infrequent constellations.From the results shown in Figure 16, we conclude that p c < p b represents a reasonable requirement as throughput is increased if 0 < p c < p b .

C. Overall Results to Maximize System Throughput
From all the preceding numerical investigations, we derive that improving system throughput is achieved by: • increasing conveying speed, • decreasing batch sizes, • increasing the number of output points, Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.• creating non-perforated network structures, and • setting 0 < p c < p b 2 for the algorithmic parameterization.This parameterization is also stable concerning the given batch size, network structure, or resulting system occupation.

VII. CONCLUSION AND OUTLOOK
In this paper, we introduced a decentralized algorithm for sequencing transport from multiple input to multiple output points in highest-density conveyor systems.The developed system is composed of identical right-angle-transfer conveyor modules, which are combined via Plug-&Play technology.Each of these modules decentrally executes the developed sequencing algorithm and takes decisions locally.The implementation is based on the concept of logical time.Combined with a decentralized authorization procedure for route planning, this prevents deadlocks, livelocks, and starvation as shown.The algorithmic complexity at module level is of order O(n 2 ) and scales with system size.Within our simulation studies, we deduce that high conveying speed, small batch sizes, increasing the number of output points, nonperforated network structures, and setting 0 < p c < p b ≤ 2 for the algorithmic parameterization are for high system throughput.
Future work will be dedicated to investigations of more variable network configurations as the number of conveyor modules is crucial for the maximum batch size which can be sequenced.Analyzing the impact of the number and position of input and output points reveals profitable system setups in practical use cases.Furthermore, comparing the performance of our decentralized sequencing algorithm to centralized approaches allows to investigate the trade-off between optimality and flexibility, which we aim to address in further contributions.

Manuscript received 31
October 2022; revised 8 March 2023; accepted 26 April 2023.Date of publication 15 May 2023; date of current version 8 August 2024.This article was recommended for publication by Associate Editor Y. Tong and Editor C. Seatzu upon evaluation of the reviewers' comments.This work was supported by the Bundesministerium für Wirtschaft und Klimaschutz (BMWK) through by the Research Project "MultiSequencer-Development of a Compact, Flexible m:n Sequencer" under Grant ZF4251413DB8.(Corresponding author: Julia Fleischmann.)

Fig. 1 .
Fig. 1.Sequencing use case, where items are sequenced according to their number.

Fig. 2 .
Fig. 2. Splitting the overall route of a TU into active and passive routes.

Fig. 3 .
Fig. 3. Flow chart for sequencing from the perspective of a TU.

Fig. 4 .
Fig. 4. Use case of two active routes from buffer to output and from input to buffer module, respectively, including their induced passive routes.

Fig. networks
Fig. networks for performance analysis.

10 .
Impact of p b on throughput for selected values of conveying speed t conv (k = 5).

Fig. 11 .
Fig. 11.Impact of p b on throughput for selected values of batch size k (t conv = 1s).

Fig.
Fig. Average TU path for selected values of p b (k = 5).

Fig. 15 .
Fig. 15. of p c on throughput for selected values of lift time t li f t (t conv = 1s, k = 5).

Fig. 16 .
Fig. 16.Impact of p c on throughput for selected values of p b (t conv = 1s, k = 5).