- Email: [email protected]
Computational Complexity and Scalability Analysis of PROSA and delegate MAS*
11th IFAC Workshop on Intelligent Manufacturing Systems The International Federation of Automatic Control May 22-24, 2013. São Paulo, Brazil
WeDT2.1
Computational Complexity and Scalability Analysis of PROSA and delegate MAS ? Johan Philips ∗ Bart Saint Germain ∗ Jan Van Belle ∗ Paul Valckenaers ∗ ∗
Department of Mechanical Engineering, KU Leuven, Celestijnenlaan 300B box 2420, B-3001 Heverlee, Belgium, (e-mail: [email protected]).
Abstract: This paper discusses the results of the computational complexity analysis with respect to time, which was performed on the Holonic Manufacturing Execution System (HMES) following the Product-Resource-Order-Staff Architecture (PROSA) and delegate Multi-Agent System (D-MAS). A practical approach was used instead of a theoretical or formal analysis. The analysis shows a polynomial relationship between the time complexity and number of resources and orders in the system and highlights where optimisations could improve the current implementation. Scalability experiments in the domain of multi-robot navigation, with respect to number of robots and environment size, shows this complexity is an upper bound. Keywords: Holonic Manufacturing, Multi-Agent Systems, Biologically Inspired Techniques 1. INTRODUCTION The holonic reference architecture PROSA and its antcolony-inspired coordination mechanism D-MAS have contributed to the state of the art in the domain of manufacturing execution systems, see e.g. Valckenaers and Brussel (2005). Figure 1 shows the main components of PROSA. Overall, PROSA is the translation of the architecture of a modern computer operating system into the manufacturing control domain. The CPU cores have been generalized into resource holons; the code segments became the product holons; the data segments became the order holons. Resource allocation to order holons - compliant with the requirements expressed by the product holons and within the capabilities and availabilities indicated by the resource holons - is a key functionality of a PROSA implementation. PROSA separates two concerns. First, product holons and resource holons address technical feasibility (making the right product in a technically correct and validated manner). Product holons are knowledgeable concerning the capabilities of resources that are relevant to them. They ignore resource capacity and availability aspects. Order holons are informed by product holons about (all) technically correct manners to fulfil their task (production order completion). Second, order holons and resource holons address the issue of resource allocation and product flow coordination. Within their solution space, identified by the product holons in cooperation with the resource holons, the order holons arrange the resource allocations and the execution of process, storage and transportation steps that suffice ? The paper reflects the work funded by the Research Council of the KU Leuven - concerted research action GOA-ACDPS (Autonomic Computing in Decentralised Production Systems) and European project BRICS (FP7-231940, Best Practice in Robotics).
978-3-902823-33-5/13/$20.00 © 2013 IFAC
Fig. 1. Overview of the PROSA reference architecture.
to fulfil their task. In view of the complexity of resource allocation, staff holons may assist through advice but order and resource holons take the final decisions (further discussion of staff holons is out of scope; more information can be found in Verstraete et al. (2008)). A straightforward implementation of PROSA will handle product routing and resource allocation as if (intelligent) product parts are cars in (congested) traffic, deciding about the next processing step and resource allocation while trying to guess what the others are about to do. Here, significant margin for improvements remains. A bio-inspired coordination mechanism, enabling the holons to achieve improvements by generating the required information, accompanies PROSA: the D-MAS or delegate multi-agent system (e.g. Holvoet and Valckenaers (2006), Holvoet et al. (2009), Valckenaers and Brussel (2005)). PROSA holons create (many) lightweight agents, called ants, to perform some task on their behalf. E.g. the resource holons and/or product holons can use a feasibility D-MAS to attach digital road signs showing technically correct routings to the order holons. The order holons have two D-MAS: • Exploring D-MAS to find feasible routings, accounting for resource availability and capacity, capable of fulfilling their task.
29
• Intention D-MAS to propagate the order’s intentions, informing resource holons about future visits (allocations). The resource holons maintain an agenda in which future allocations are registered based on the information from the second D-MAS. This agenda is accounted for when lightweight agents from the first D-MAS interact with the resource holon while constructing their candidate routing. During the development of PROSA and D-MAS, the research team has minimized the introduction of constraints on the applicability of its results. Basically, the technology can be applied to applications with the following characteristics: • Activities are executed on resources and are subject to technical constraints. • Virtual execution of these activities in a digital mirror image of the world-of-interest is possible and can be much faster than in reality. • The socio-economic value of enhanced coordination more than compensates the cost and effort for the virtual execution. Relative to the amount of research into decentralized MES, few results are available on performance aspects. E.g. Cavalieri et al. (2000) have investigated the performance of work by others. In contrast, this paper investigates the computational complexity of the Holonic Manufacturing Execution System (HMES) itself. This is the current implementation of PROSA and D-MAS which was developed for manufacturing control and currently used in a range of applications, from manufacturing control, to logistics and robotics. An overview of these different applications is given in Van Belle et al. (2012). A scalability experiment, in the domain of multi-robot navigation, in which both the number of resource and the order holons are increased, illustrates the computational complexity estimation as an upper bound.
2. COMPUTATIONAL COMPLEXITY The computational complexity of the HMES implementation will provide an estimate of the system response time in function of a set of system parameters discussed in the following paragraphs. Typically in computational complexity analysis of algorithms, their response time is computed with respect to the input size N . Although, a distinction can be made between best case, average case and worst case complexity, but commonly worst case or upper bounds are calculated. To denote these upper bounds, the big O notation is used, hiding constant factors and lower terms. For example, a binary search algorithm on a sorted list has a worst case complexity of O(log2 (N )), since it cuts the list in halve until it reaches the desired element. In the case of the HMES, there is no single input size but a set of parameters which determine how well the system responds. Besides the number of orders, also the number resources, the complexity of the process plans and all the tunable parameters contribute to the system performance. 978-3-902823-33-5/13/$20.00 © 2013 IFAC
Due to the complex nature of the HMES and its internal interactions, a practical approach was chosen to determine its computational complexity, as opposed to providing a mathematical proof. Also, for some parameters empirical estimates will be provided to illustrates the difference between worst case and average case. It should be noted that such a practical approach will result in an estimation of the computational complexity of the current implementation developed for the research applications which are currently being investigated. Also, the code was not especially optimized for its current use. In the discussion section the trade-off between optimizations and general applicability will be explained. More information on computational complexity can be found in Fortnow and Homer (2003), providing a brief history, and Hartmanis and Stearns (1965) laying the definitions of time and space complexity. 3. SYSTEM PARAMETERS In Table 1 the set of parameters and their abbreviations, used in the computational complexity estimation, is given. Table 1. System parameters used in complexity analysis. Parameter Exp [#] Int [#] Hop [#] Sol [#] Slot [#] Res [#] Ord [#] Ops [#] Req [#] P ro [#] Con [#]
Description Average # Exploring Ants per Order Average # Intention Ants per Order Hop Limit Average # of Solutions per Order Average # of Slots per Resource # of Resources # of Orders Average # of Operations per Solution Average # of Requests Average Process Plan Size Average # of Connection Points
The first two parameters, Exp and Int, determine the average number of lightweight D-MAS exploring and intention ants per order are active in the system. Since these agents virtually traverse the different resource holons and respectively ask what-if questions and request allocations, a high number of ants could severely impair system performance. The hop limit, represented by Hop, configures how many resource holons each ant is allowed to traverse, or hop on, before terminating its execution. This hop limit ensures ants are not stuck in infinite loops between resources or return with solutions containing an unnecessary high number of resources. The average number of solutions each order is considering is represented by Sol. This parameter indicates, for example, how many comparisons the order holon has to make in order to determine if a new solution is better than the already received solutions from previous explorations. Each resource has a scheduler, which processes the resource allocation requests it receives from the D-MAS. The average number of occupied time slots per resource are captured by the Slot parameter.
30
Order Holon
Resource Holon
Send explorers
Dispatching
Choose intention
Update state
Dispatching Update state
Fig. 2. Cycles in holons which contribute the most to the system’s computational complexity. The product holon has no separate cycle, since it is not an active object. Rather, it is consulted by the order holon’s exploring D-MAS.
Fig. 3. Histogram of the number of hops exploring ants made in an environment of 16 rooms and 24 corridors in which the shortest path solution is 5 hops.
Two determining factors in the computational complexity are the number of active resources, Res, and orders, Ord, in the system. The scalability example at the end of this paper illustrates the effect on system computation time when these parameters increase. Each order holon has to follow a set of operations, determined by the corresponding product holon. The average number of operations per solution is represented by Ops. The average number of requests, Req, indicates how many requests resource holons have to process. These requests origin from exploring and intention ants, which either request a virtual execution or either request an allocation. Each product holon contains a process plan to determine how an order should be executed. The size of this process plan, in number of operations it ideally contains, is represented by P ro. This plan size is not necessarily identical to the actual solution size, averaged by Ops, provided by the exploring D-MAS. Finally, each resource holon is connected to other resource holons by connection points. The number of connection points determines the number of possible paths exploring and intention ants are able to take. The parameter Con represents the average number connection points. 4. ANALYSIS Figure 2 shows which cycles in which holons contribute the most to the system’s computational complexity. The product holon has no separate cycle, since it is not an active object. Rather, it is consulted by the order holon’s exploring D-MAS. In the subsequent sections, each of these cycles will be analysed in more detail to determine their computational complexity with respect to the above mentioned system parameters. 5. ORDER HOLON In the order holon several cycles with distinct periodicities are maintained simultaneously. Exploring ants are sent at a faster rate than intention ants. The dispatching cycle represents the communication towards the real world or emulation, while the update state cycle represents the processing of events received from the real world or emulation. 978-3-902823-33-5/13/$20.00 © 2013 IFAC
Fig. 4. Scatterplot of number of hops exploring ants made in an environment of 16 rooms and 24 corridors in which the shortest path solution is 5 hops. 5.1 Send explorers Each exploring ant performs in the worst case Hop number of hops, in which each hop consists of consulting the product holon for options, choosing an option and allocating a resource. However, the hop limit Hop is an overestimate and in this case an empirical estimate is more appropriate. The analysis of the exploring ants sent out during scalability experiments, presented in section 8, is depicted in Figure 3 and Figure 4. This histogram and scatter plot show an average hop count of 4.781 in an environment of 16 rooms and 24 corridors in which the shortest path solution was 5 hops. Exploring ants are continuously sent out, also after a part of a solution is already executed. Therefore, many ants find a solution in less than 5 hops. Consulting the product holon has a complexity of O(P ro+ Con), since the product holon has to determine the next operation according to the process plan and check for each connection point if this next operation is possible. Choosing an option out of the proposed next steps is constant (O(1)) and, thus, can be discarded in the overall calculation. Allocating a resource is a complex process and will be discussed in a separate paragraph, in which its complexity will be estimated as O(Req · Slot) on average and in the worst case ≈ O(Hop2 ). This worst-case situation only occurs if an exploring ant with a maximum length solution would allocate each of its operations on the same resource. Figure 5 and Figure 6 show empirical estimates for Req and Slot respectively. These averages are calculated using an environment with 16 rooms, 24 corridors and 16 naviga-
31
Next, among the set of solutions the best alternative is chosen. The solution set size Sol is the determining factor here. This size is the ratio between the exploring rate and evaporation rate. For instance, if every 100ms an exploring ant is sent out and solutions evaporate after 5 seconds, the 5s average amount of solutions Sol = 0.1s = 50.
Fig. 5. Average number of requests over time on all resources in an environment with 16 rooms, 24 corridors and 16 navigation requests.
After a best alternative has been chosen, this solution is refreshed and if still valid an intention ant is sent out to commit the solution. Sending out an intention ant has the same complexity as sending a refreshing ant. Thus, the worst case complexity estimate of the choose intention cycle is the sum of the above estimates: O(Choose intention, worst case) ≈ O(Hop3 + Sol + Hop3 + Hop3 ) ≈ (3) O(Hop3 ) The average complexity is: O(Choose intention, avg. case) ≈ O(Hop · Req · Slot)
(4)
5.3 Dispatching Fig. 6. Average number of slots per resource in an environment with 16 rooms, 24 corridors and 16 navigation requests. tion requests, in which the robots move from one room to one of their neighbouring rooms. These data clearly show hop limit Hop is an upper bound. Thus, the worst-case complexity of sending an exploring ant is: O(Send explorer, worst case) ≈ O(Hop · (Rec + Con + Hop2 ) + Hop · Exp) ≈ (1) O(Hop3 ) The hop limit is used here as an upper bound for the average hop count by an ant and the average requests and average slots on a resource. The average complexity of sending an explorer is: O(Send explorer, avg. case) ≈ O(Hop · Req · Slot)
(2)
If an exploring ant fails, it backtracks to invalidate its solution. In the worst case, Exp ants have to backtrack over Hop resources, resulting in O(Hop · Exp).
For each operation the order holon sends an event to the real world or emulation to start the execution. Processing this event is constant (O(1)). Before it sends out this event, it refreshes the solution one last time. The worst case complexity of the dispatching cycle then becomes: O(Dispatching, worst case) ≈ O(Hop3 ) In the average case, this yields again: O(Dispatching, avg. case) ≈ O(Hop · Req · Slot)
(5)
(6)
The amount of events sent to the real world or emulation depends on the number of operations Ops. 5.4 Update state The order holon updates its state each time it receives an event from the real world or emulation. In this implementation, each time an operation starts and stops an event is sent. Processing a state update is constant and the amount of events is again dependent on the number of operations Ops. O(Update state) ≈ O(1) (7)
5.2 Choose intention
In worst case the average number of operations is equal to the hop limit Hop.
At a lower frequency than the exploring rate, the order holon evaluates its set of received solutions and commits to the most appropriate one based on its selection criteria.
5.5 Total
In this cycle first the current solution is refreshed, i.e. an ant is sent out to check if the current solution is still valid. Sending out a refreshing ant has a similar complexity as sending out an exploring ant. However, the product holon does not need to be consulted in this case. Since the allocations are still made for at most Hop resources, the resulting complexity remains ≈ O(Hop · Req · Slot) on average and O(Hop3 ) in the worst case.
Combining all the order execution cycles with their respective frequencies yields: O(Orders, worstcase) ≡ O(Ord · (Exp · ((1)) + Int · ((3)) + Ops · ((5)) + Ops · ((7)))) = (8) O(Ord · (Exp · Hop3 + Int · Hop3 + 3 Ops · Hop + Ops · 1)) ≈ O(Ord · Hop3 · (Exp + Int + Ops))
978-3-902823-33-5/13/$20.00 © 2013 IFAC
32
O(Orders, avg.case) ≡ O(Ord · (Exp · ((2)) + Int · ((4)) + Ops · ((6)) + Ops · ((7)))) = O(Ord · Hop · Req · Slot · (Exp + Int + Ops))
(9)
in the order cycles. Therefore, the overall complexity becomes: (12) O(Resources, worst case) ≈ O(Res · Hop2 ) O(Resources, avg. case) ≈ O(Res · Slot · Ops)
(13)
6. RESOURCE HOLON
7. SUMMARY & DISCUSSION
Each resource holon has its own dispatching and update state cycle and also handles the allocation requests from the ants sent out by the order holon.
Combining both the order holon cycle ((8) for worst case, (9) for average case) and resource holon cycle (respectively (12) and (13)) yields the following estimates of the total computational complexity: O(HMES, worst case) ≡ (8) + (12) = (14) O(Ord · Hop3 · (Exp + Int + Ops) + Res · Hop2 )
6.1 Dispatching & Update state The dispatching cycle in the resource holon is negligible, since it only sends events at a fixed rate to the real world or emulation. Every event the resource holon receives from the real world or emulation has an influence on its current schedule. Thus, the complexity of processing a state update is ≈ O(Slot). Similar to the order holon, the amount of received events is dependent on the number of operations Ops and in the worst case Hop. 6.2 Resource allocation For each request the scheduler receives, it evaporates old slots, consults its cache or schedules a new request and restores the previous state in case of virtual execution. In the evaporation step, the scheduler reviews all slots and removes those slots which are older than the time window defined by the evaporation rate. The resulting complexity is O(Slot). Next, it consults the cache to check if the request has been scheduled before, so it can be updated. Browsing and comparing in a list of previous requests is O(Req) since a hash map is used, which has constant lookup time. In the worst case one order visits the same resource Hop times and the complexity becomes O(Hop). If the cache returns no result, it checks all slots for an already existing request from this order and removes it. Since a binary tree is used, removing this request is O(log2 (Slot)). Adding the new request has a complexity of O(Req · Slot), since all slots are reviewed for each request. Finally, restoring the previous state requires O(Slot), since a copy of all slots is restored. The overall computational complexity of resource allocation is the sum of above estimates. The addition of a new request is the determining factor.
O(HMES, avg. case) ≡ (9) + (13) = O(Ord · Hop · Req · Slot · (Exp + Int + Ops) + Res · Slot · Ops)
(15)
These calculations show the order holon cycles contribute far more to the complexity than those in the resource holon and, in worst case, the hop limit Hop is the determining factor. Note that, as was stated before, this complexity analysis concerns the current implementation of the HMES and not PROSA and D-MAS in general. In order to look at the complexity of PROSA and D-MAS in general, abstraction has to be made from implementation specifics. Each virtual exploration or allocation step made by respectively exploring or intention ants is then denoted as a tick in the system. The actual computational complexity of this tick depends on how the resource graph traversal and resource scheduling are implemented. Also the resource state updates have an implementation specific part, which will be denoted as update. The overall complexity then becomes: O(PROSA&DMAS) ≈ O(Ord · Hop · tick · (Exp + Int + Ops) + Res · Ops · update)
(16)
Optimisations are possible in both the order and resource cycles and above analysis indicates that optimising the resource scheduler could improve the overall performance. However, there is always a trade off to be made between optimisations specific to an application and the general applicability of the system. Also, it is not guaranteed that an optimised scheduler with respect to computational complexity will deliver similar results with respect to the application. 8. SCALABILITY
6.3 Total
In this section a scalability experiment in the domain of mobile robotics will be discussed, demonstrating how the HMES’ performance is influenced by an increase in robots and environment size, respectively resulting in an increase in the number of order and resource holons in the HMES.
Only the dispatching and update state cycle are counted here, since the allocation is already taken into account
The experiment was performed in simulation and compares the execution time of each robot to number of robots and size of the environment.
O(Resource allocation, worst case) ≈ O(Hop2 )
(10)
O(Resource allocation, avg. case) ≈ O(Req · Slot) (11)
978-3-902823-33-5/13/$20.00 © 2013 IFAC
33
1.43e−06. This indicates the HMES performance decreases when increasing the environment, though this decrease is rather small.
Fig. 7. Simulation environment with 32 rooms, each connected to its neighbours by a narrow corridor. All rooms and corridors are represented by resource holons. 80
70
Execution Time [s]
It also shows complexity analysis does not capture the fact that typical trajectories, executed by the robots, do not necessarily increase proportional to the environment increase. Nevertheless, the introduction of guidance markers, such as colour code routes, could improve the time exploring ant require to find a valid solution. Still, the parallel execution of the order holons and their D-MAS and the distributed planning among the resource holons show that also in larger environments the performance is still acceptable.
60
50
40
30
20
10
The complexity analysis in the previous section indicated an increase in execution time whenever the number of order or resource holons increase. This scalability experiment shows a small increase in execution time in larger environments with more robots. However, the experimentally measured increase is sublinear and shows the complexity analysis is an upper bound.
16 robot s in 4x4
32 robot s in 4x8
Fig. 8. Box plots of navigation durations in seconds in both environments for 8 runs in each environment. 8.1 Setup The simulation environment consisted of rooms interconnected by corridors, as shown in Figure 7. Each room is connected to its neighbouring rooms through narrow corridors and all rooms and corridors are represented by resource holons. In each room a mobile robot is deployed and its task is to navigate to one of the adjacent rooms. Robots cannot simultaneously enter the same narrow corridor. This navigation tasks are represented by order holons and the coordination of the different robots is taken care of by the HMES. Two environments are tested, one with 16 rooms and 24 corridors, one with 32 rooms and 52 corridors. 8.2 Results In both environments 8 runs are performed and the execution times are compared. The execution time is defined as the difference between the creation time of the navigation requests and the navigation finish time. In Figure 8 two box plots are depicted, showing the differences between the two environments. The box defines the interquartile range (IQR = Q3 − Q1), while the whiskers are positioned at Q1 − 1.5IQR and Q3 + 1.5IQR respectively. The average value is displayed by a ? symbol. These box plots show that the majority of the navigation requests in the larger environment are executed with a similar duration. The median and average values, 21.0s and 28.34s for the small environment, and 26.0s and 39.73s for the large environment do not differ that much.
REFERENCES Cavalieri, S., Garetti, M., Macchi, M., and Taisch, M. (2000). An experimental benchmarking of two multiagent architectures for production scheduling and control. Computers in Industry, 43(2), 139–152. Fortnow, L. and Homer, S. (2003). A short history of computational complexity. Bulletin of the EATCS, 80, 95–133. Hartmanis, J. and Stearns, R.E. (1965). On the computational complexity of algorithms. Transactions of the American Mathematical Society, 117, 285–306. Holvoet, T. and Valckenaers, P. (2006). Beliefs, desires and intentions through the environment. In Proceedings of the fifth international joint conference on Autonomous agents and multiagent systems, AAMAS ’06, 1052–1054. ACM, New York, NY, USA. Holvoet, T., Weyns, D., and Valckenaers, P. (2009). Patterns of delegate mas. In Proceedings of the 2009 Third IEEE International Conference on Self-Adaptive and Self-Organizing Systems, SASO ’09, 1–9. IEEE Computer Society, Washington, DC, USA. Valckenaers, P. and Brussel, H.V. (2005). Holonic manufacturing execution systems. CIRP Annals - Manufacturing Technology, 54(1), 427–432. Van Belle, J., Philips, J., Ali, O., Saint Germain, B., Van Brussel, H., and Valckenaers, P. (2012). A serviceoriented approach for holonic manufacturing control and beyond. In T. Borangiu, A. Thomas, and D. Trentesaux (eds.), Service Orientation in Holonic and Multi-Agent Manufacturing Control, volume 402 of Studies in Computational Intelligence. Springer Berlin / Heidelberg. Verstraete, P., Valckenaers, P., Van Brussel, H., Saint Germain, B., Hadeli, K., and Van Belle, J. (2008). Towards robust and efficient planning execution. Eng. Appl. Artif. Intell., 21, 304–314.
However, a Wilcoxon rank sum test rejects the null hypothesis that two sets of measurements are drawn from the same distribution with a z-score of −4.82 and p-value 978-3-902823-33-5/13/$20.00 © 2013 IFAC
34
WeDT2.1
Computational Complexity and Scalability Analysis of PROSA and delegate MAS ? Johan Philips ∗ Bart Saint Germain ∗ Jan Van Belle ∗ Paul Valckenaers ∗ ∗
Department of Mechanical Engineering, KU Leuven, Celestijnenlaan 300B box 2420, B-3001 Heverlee, Belgium, (e-mail: [email protected]).
Abstract: This paper discusses the results of the computational complexity analysis with respect to time, which was performed on the Holonic Manufacturing Execution System (HMES) following the Product-Resource-Order-Staff Architecture (PROSA) and delegate Multi-Agent System (D-MAS). A practical approach was used instead of a theoretical or formal analysis. The analysis shows a polynomial relationship between the time complexity and number of resources and orders in the system and highlights where optimisations could improve the current implementation. Scalability experiments in the domain of multi-robot navigation, with respect to number of robots and environment size, shows this complexity is an upper bound. Keywords: Holonic Manufacturing, Multi-Agent Systems, Biologically Inspired Techniques 1. INTRODUCTION The holonic reference architecture PROSA and its antcolony-inspired coordination mechanism D-MAS have contributed to the state of the art in the domain of manufacturing execution systems, see e.g. Valckenaers and Brussel (2005). Figure 1 shows the main components of PROSA. Overall, PROSA is the translation of the architecture of a modern computer operating system into the manufacturing control domain. The CPU cores have been generalized into resource holons; the code segments became the product holons; the data segments became the order holons. Resource allocation to order holons - compliant with the requirements expressed by the product holons and within the capabilities and availabilities indicated by the resource holons - is a key functionality of a PROSA implementation. PROSA separates two concerns. First, product holons and resource holons address technical feasibility (making the right product in a technically correct and validated manner). Product holons are knowledgeable concerning the capabilities of resources that are relevant to them. They ignore resource capacity and availability aspects. Order holons are informed by product holons about (all) technically correct manners to fulfil their task (production order completion). Second, order holons and resource holons address the issue of resource allocation and product flow coordination. Within their solution space, identified by the product holons in cooperation with the resource holons, the order holons arrange the resource allocations and the execution of process, storage and transportation steps that suffice ? The paper reflects the work funded by the Research Council of the KU Leuven - concerted research action GOA-ACDPS (Autonomic Computing in Decentralised Production Systems) and European project BRICS (FP7-231940, Best Practice in Robotics).
978-3-902823-33-5/13/$20.00 © 2013 IFAC
Fig. 1. Overview of the PROSA reference architecture.
to fulfil their task. In view of the complexity of resource allocation, staff holons may assist through advice but order and resource holons take the final decisions (further discussion of staff holons is out of scope; more information can be found in Verstraete et al. (2008)). A straightforward implementation of PROSA will handle product routing and resource allocation as if (intelligent) product parts are cars in (congested) traffic, deciding about the next processing step and resource allocation while trying to guess what the others are about to do. Here, significant margin for improvements remains. A bio-inspired coordination mechanism, enabling the holons to achieve improvements by generating the required information, accompanies PROSA: the D-MAS or delegate multi-agent system (e.g. Holvoet and Valckenaers (2006), Holvoet et al. (2009), Valckenaers and Brussel (2005)). PROSA holons create (many) lightweight agents, called ants, to perform some task on their behalf. E.g. the resource holons and/or product holons can use a feasibility D-MAS to attach digital road signs showing technically correct routings to the order holons. The order holons have two D-MAS: • Exploring D-MAS to find feasible routings, accounting for resource availability and capacity, capable of fulfilling their task.
29
• Intention D-MAS to propagate the order’s intentions, informing resource holons about future visits (allocations). The resource holons maintain an agenda in which future allocations are registered based on the information from the second D-MAS. This agenda is accounted for when lightweight agents from the first D-MAS interact with the resource holon while constructing their candidate routing. During the development of PROSA and D-MAS, the research team has minimized the introduction of constraints on the applicability of its results. Basically, the technology can be applied to applications with the following characteristics: • Activities are executed on resources and are subject to technical constraints. • Virtual execution of these activities in a digital mirror image of the world-of-interest is possible and can be much faster than in reality. • The socio-economic value of enhanced coordination more than compensates the cost and effort for the virtual execution. Relative to the amount of research into decentralized MES, few results are available on performance aspects. E.g. Cavalieri et al. (2000) have investigated the performance of work by others. In contrast, this paper investigates the computational complexity of the Holonic Manufacturing Execution System (HMES) itself. This is the current implementation of PROSA and D-MAS which was developed for manufacturing control and currently used in a range of applications, from manufacturing control, to logistics and robotics. An overview of these different applications is given in Van Belle et al. (2012). A scalability experiment, in the domain of multi-robot navigation, in which both the number of resource and the order holons are increased, illustrates the computational complexity estimation as an upper bound.
2. COMPUTATIONAL COMPLEXITY The computational complexity of the HMES implementation will provide an estimate of the system response time in function of a set of system parameters discussed in the following paragraphs. Typically in computational complexity analysis of algorithms, their response time is computed with respect to the input size N . Although, a distinction can be made between best case, average case and worst case complexity, but commonly worst case or upper bounds are calculated. To denote these upper bounds, the big O notation is used, hiding constant factors and lower terms. For example, a binary search algorithm on a sorted list has a worst case complexity of O(log2 (N )), since it cuts the list in halve until it reaches the desired element. In the case of the HMES, there is no single input size but a set of parameters which determine how well the system responds. Besides the number of orders, also the number resources, the complexity of the process plans and all the tunable parameters contribute to the system performance. 978-3-902823-33-5/13/$20.00 © 2013 IFAC
Due to the complex nature of the HMES and its internal interactions, a practical approach was chosen to determine its computational complexity, as opposed to providing a mathematical proof. Also, for some parameters empirical estimates will be provided to illustrates the difference between worst case and average case. It should be noted that such a practical approach will result in an estimation of the computational complexity of the current implementation developed for the research applications which are currently being investigated. Also, the code was not especially optimized for its current use. In the discussion section the trade-off between optimizations and general applicability will be explained. More information on computational complexity can be found in Fortnow and Homer (2003), providing a brief history, and Hartmanis and Stearns (1965) laying the definitions of time and space complexity. 3. SYSTEM PARAMETERS In Table 1 the set of parameters and their abbreviations, used in the computational complexity estimation, is given. Table 1. System parameters used in complexity analysis. Parameter Exp [#] Int [#] Hop [#] Sol [#] Slot [#] Res [#] Ord [#] Ops [#] Req [#] P ro [#] Con [#]
Description Average # Exploring Ants per Order Average # Intention Ants per Order Hop Limit Average # of Solutions per Order Average # of Slots per Resource # of Resources # of Orders Average # of Operations per Solution Average # of Requests Average Process Plan Size Average # of Connection Points
The first two parameters, Exp and Int, determine the average number of lightweight D-MAS exploring and intention ants per order are active in the system. Since these agents virtually traverse the different resource holons and respectively ask what-if questions and request allocations, a high number of ants could severely impair system performance. The hop limit, represented by Hop, configures how many resource holons each ant is allowed to traverse, or hop on, before terminating its execution. This hop limit ensures ants are not stuck in infinite loops between resources or return with solutions containing an unnecessary high number of resources. The average number of solutions each order is considering is represented by Sol. This parameter indicates, for example, how many comparisons the order holon has to make in order to determine if a new solution is better than the already received solutions from previous explorations. Each resource has a scheduler, which processes the resource allocation requests it receives from the D-MAS. The average number of occupied time slots per resource are captured by the Slot parameter.
30
Order Holon
Resource Holon
Send explorers
Dispatching
Choose intention
Update state
Dispatching Update state
Fig. 2. Cycles in holons which contribute the most to the system’s computational complexity. The product holon has no separate cycle, since it is not an active object. Rather, it is consulted by the order holon’s exploring D-MAS.
Fig. 3. Histogram of the number of hops exploring ants made in an environment of 16 rooms and 24 corridors in which the shortest path solution is 5 hops.
Two determining factors in the computational complexity are the number of active resources, Res, and orders, Ord, in the system. The scalability example at the end of this paper illustrates the effect on system computation time when these parameters increase. Each order holon has to follow a set of operations, determined by the corresponding product holon. The average number of operations per solution is represented by Ops. The average number of requests, Req, indicates how many requests resource holons have to process. These requests origin from exploring and intention ants, which either request a virtual execution or either request an allocation. Each product holon contains a process plan to determine how an order should be executed. The size of this process plan, in number of operations it ideally contains, is represented by P ro. This plan size is not necessarily identical to the actual solution size, averaged by Ops, provided by the exploring D-MAS. Finally, each resource holon is connected to other resource holons by connection points. The number of connection points determines the number of possible paths exploring and intention ants are able to take. The parameter Con represents the average number connection points. 4. ANALYSIS Figure 2 shows which cycles in which holons contribute the most to the system’s computational complexity. The product holon has no separate cycle, since it is not an active object. Rather, it is consulted by the order holon’s exploring D-MAS. In the subsequent sections, each of these cycles will be analysed in more detail to determine their computational complexity with respect to the above mentioned system parameters. 5. ORDER HOLON In the order holon several cycles with distinct periodicities are maintained simultaneously. Exploring ants are sent at a faster rate than intention ants. The dispatching cycle represents the communication towards the real world or emulation, while the update state cycle represents the processing of events received from the real world or emulation. 978-3-902823-33-5/13/$20.00 © 2013 IFAC
Fig. 4. Scatterplot of number of hops exploring ants made in an environment of 16 rooms and 24 corridors in which the shortest path solution is 5 hops. 5.1 Send explorers Each exploring ant performs in the worst case Hop number of hops, in which each hop consists of consulting the product holon for options, choosing an option and allocating a resource. However, the hop limit Hop is an overestimate and in this case an empirical estimate is more appropriate. The analysis of the exploring ants sent out during scalability experiments, presented in section 8, is depicted in Figure 3 and Figure 4. This histogram and scatter plot show an average hop count of 4.781 in an environment of 16 rooms and 24 corridors in which the shortest path solution was 5 hops. Exploring ants are continuously sent out, also after a part of a solution is already executed. Therefore, many ants find a solution in less than 5 hops. Consulting the product holon has a complexity of O(P ro+ Con), since the product holon has to determine the next operation according to the process plan and check for each connection point if this next operation is possible. Choosing an option out of the proposed next steps is constant (O(1)) and, thus, can be discarded in the overall calculation. Allocating a resource is a complex process and will be discussed in a separate paragraph, in which its complexity will be estimated as O(Req · Slot) on average and in the worst case ≈ O(Hop2 ). This worst-case situation only occurs if an exploring ant with a maximum length solution would allocate each of its operations on the same resource. Figure 5 and Figure 6 show empirical estimates for Req and Slot respectively. These averages are calculated using an environment with 16 rooms, 24 corridors and 16 naviga-
31
Next, among the set of solutions the best alternative is chosen. The solution set size Sol is the determining factor here. This size is the ratio between the exploring rate and evaporation rate. For instance, if every 100ms an exploring ant is sent out and solutions evaporate after 5 seconds, the 5s average amount of solutions Sol = 0.1s = 50.
Fig. 5. Average number of requests over time on all resources in an environment with 16 rooms, 24 corridors and 16 navigation requests.
After a best alternative has been chosen, this solution is refreshed and if still valid an intention ant is sent out to commit the solution. Sending out an intention ant has the same complexity as sending a refreshing ant. Thus, the worst case complexity estimate of the choose intention cycle is the sum of the above estimates: O(Choose intention, worst case) ≈ O(Hop3 + Sol + Hop3 + Hop3 ) ≈ (3) O(Hop3 ) The average complexity is: O(Choose intention, avg. case) ≈ O(Hop · Req · Slot)
(4)
5.3 Dispatching Fig. 6. Average number of slots per resource in an environment with 16 rooms, 24 corridors and 16 navigation requests. tion requests, in which the robots move from one room to one of their neighbouring rooms. These data clearly show hop limit Hop is an upper bound. Thus, the worst-case complexity of sending an exploring ant is: O(Send explorer, worst case) ≈ O(Hop · (Rec + Con + Hop2 ) + Hop · Exp) ≈ (1) O(Hop3 ) The hop limit is used here as an upper bound for the average hop count by an ant and the average requests and average slots on a resource. The average complexity of sending an explorer is: O(Send explorer, avg. case) ≈ O(Hop · Req · Slot)
(2)
If an exploring ant fails, it backtracks to invalidate its solution. In the worst case, Exp ants have to backtrack over Hop resources, resulting in O(Hop · Exp).
For each operation the order holon sends an event to the real world or emulation to start the execution. Processing this event is constant (O(1)). Before it sends out this event, it refreshes the solution one last time. The worst case complexity of the dispatching cycle then becomes: O(Dispatching, worst case) ≈ O(Hop3 ) In the average case, this yields again: O(Dispatching, avg. case) ≈ O(Hop · Req · Slot)
(5)
(6)
The amount of events sent to the real world or emulation depends on the number of operations Ops. 5.4 Update state The order holon updates its state each time it receives an event from the real world or emulation. In this implementation, each time an operation starts and stops an event is sent. Processing a state update is constant and the amount of events is again dependent on the number of operations Ops. O(Update state) ≈ O(1) (7)
5.2 Choose intention
In worst case the average number of operations is equal to the hop limit Hop.
At a lower frequency than the exploring rate, the order holon evaluates its set of received solutions and commits to the most appropriate one based on its selection criteria.
5.5 Total
In this cycle first the current solution is refreshed, i.e. an ant is sent out to check if the current solution is still valid. Sending out a refreshing ant has a similar complexity as sending out an exploring ant. However, the product holon does not need to be consulted in this case. Since the allocations are still made for at most Hop resources, the resulting complexity remains ≈ O(Hop · Req · Slot) on average and O(Hop3 ) in the worst case.
Combining all the order execution cycles with their respective frequencies yields: O(Orders, worstcase) ≡ O(Ord · (Exp · ((1)) + Int · ((3)) + Ops · ((5)) + Ops · ((7)))) = (8) O(Ord · (Exp · Hop3 + Int · Hop3 + 3 Ops · Hop + Ops · 1)) ≈ O(Ord · Hop3 · (Exp + Int + Ops))
978-3-902823-33-5/13/$20.00 © 2013 IFAC
32
O(Orders, avg.case) ≡ O(Ord · (Exp · ((2)) + Int · ((4)) + Ops · ((6)) + Ops · ((7)))) = O(Ord · Hop · Req · Slot · (Exp + Int + Ops))
(9)
in the order cycles. Therefore, the overall complexity becomes: (12) O(Resources, worst case) ≈ O(Res · Hop2 ) O(Resources, avg. case) ≈ O(Res · Slot · Ops)
(13)
6. RESOURCE HOLON
7. SUMMARY & DISCUSSION
Each resource holon has its own dispatching and update state cycle and also handles the allocation requests from the ants sent out by the order holon.
Combining both the order holon cycle ((8) for worst case, (9) for average case) and resource holon cycle (respectively (12) and (13)) yields the following estimates of the total computational complexity: O(HMES, worst case) ≡ (8) + (12) = (14) O(Ord · Hop3 · (Exp + Int + Ops) + Res · Hop2 )
6.1 Dispatching & Update state The dispatching cycle in the resource holon is negligible, since it only sends events at a fixed rate to the real world or emulation. Every event the resource holon receives from the real world or emulation has an influence on its current schedule. Thus, the complexity of processing a state update is ≈ O(Slot). Similar to the order holon, the amount of received events is dependent on the number of operations Ops and in the worst case Hop. 6.2 Resource allocation For each request the scheduler receives, it evaporates old slots, consults its cache or schedules a new request and restores the previous state in case of virtual execution. In the evaporation step, the scheduler reviews all slots and removes those slots which are older than the time window defined by the evaporation rate. The resulting complexity is O(Slot). Next, it consults the cache to check if the request has been scheduled before, so it can be updated. Browsing and comparing in a list of previous requests is O(Req) since a hash map is used, which has constant lookup time. In the worst case one order visits the same resource Hop times and the complexity becomes O(Hop). If the cache returns no result, it checks all slots for an already existing request from this order and removes it. Since a binary tree is used, removing this request is O(log2 (Slot)). Adding the new request has a complexity of O(Req · Slot), since all slots are reviewed for each request. Finally, restoring the previous state requires O(Slot), since a copy of all slots is restored. The overall computational complexity of resource allocation is the sum of above estimates. The addition of a new request is the determining factor.
O(HMES, avg. case) ≡ (9) + (13) = O(Ord · Hop · Req · Slot · (Exp + Int + Ops) + Res · Slot · Ops)
(15)
These calculations show the order holon cycles contribute far more to the complexity than those in the resource holon and, in worst case, the hop limit Hop is the determining factor. Note that, as was stated before, this complexity analysis concerns the current implementation of the HMES and not PROSA and D-MAS in general. In order to look at the complexity of PROSA and D-MAS in general, abstraction has to be made from implementation specifics. Each virtual exploration or allocation step made by respectively exploring or intention ants is then denoted as a tick in the system. The actual computational complexity of this tick depends on how the resource graph traversal and resource scheduling are implemented. Also the resource state updates have an implementation specific part, which will be denoted as update. The overall complexity then becomes: O(PROSA&DMAS) ≈ O(Ord · Hop · tick · (Exp + Int + Ops) + Res · Ops · update)
(16)
Optimisations are possible in both the order and resource cycles and above analysis indicates that optimising the resource scheduler could improve the overall performance. However, there is always a trade off to be made between optimisations specific to an application and the general applicability of the system. Also, it is not guaranteed that an optimised scheduler with respect to computational complexity will deliver similar results with respect to the application. 8. SCALABILITY
6.3 Total
In this section a scalability experiment in the domain of mobile robotics will be discussed, demonstrating how the HMES’ performance is influenced by an increase in robots and environment size, respectively resulting in an increase in the number of order and resource holons in the HMES.
Only the dispatching and update state cycle are counted here, since the allocation is already taken into account
The experiment was performed in simulation and compares the execution time of each robot to number of robots and size of the environment.
O(Resource allocation, worst case) ≈ O(Hop2 )
(10)
O(Resource allocation, avg. case) ≈ O(Req · Slot) (11)
978-3-902823-33-5/13/$20.00 © 2013 IFAC
33
1.43e−06. This indicates the HMES performance decreases when increasing the environment, though this decrease is rather small.
Fig. 7. Simulation environment with 32 rooms, each connected to its neighbours by a narrow corridor. All rooms and corridors are represented by resource holons. 80
70
Execution Time [s]
It also shows complexity analysis does not capture the fact that typical trajectories, executed by the robots, do not necessarily increase proportional to the environment increase. Nevertheless, the introduction of guidance markers, such as colour code routes, could improve the time exploring ant require to find a valid solution. Still, the parallel execution of the order holons and their D-MAS and the distributed planning among the resource holons show that also in larger environments the performance is still acceptable.
60
50
40
30
20
10
The complexity analysis in the previous section indicated an increase in execution time whenever the number of order or resource holons increase. This scalability experiment shows a small increase in execution time in larger environments with more robots. However, the experimentally measured increase is sublinear and shows the complexity analysis is an upper bound.
16 robot s in 4x4
32 robot s in 4x8
Fig. 8. Box plots of navigation durations in seconds in both environments for 8 runs in each environment. 8.1 Setup The simulation environment consisted of rooms interconnected by corridors, as shown in Figure 7. Each room is connected to its neighbouring rooms through narrow corridors and all rooms and corridors are represented by resource holons. In each room a mobile robot is deployed and its task is to navigate to one of the adjacent rooms. Robots cannot simultaneously enter the same narrow corridor. This navigation tasks are represented by order holons and the coordination of the different robots is taken care of by the HMES. Two environments are tested, one with 16 rooms and 24 corridors, one with 32 rooms and 52 corridors. 8.2 Results In both environments 8 runs are performed and the execution times are compared. The execution time is defined as the difference between the creation time of the navigation requests and the navigation finish time. In Figure 8 two box plots are depicted, showing the differences between the two environments. The box defines the interquartile range (IQR = Q3 − Q1), while the whiskers are positioned at Q1 − 1.5IQR and Q3 + 1.5IQR respectively. The average value is displayed by a ? symbol. These box plots show that the majority of the navigation requests in the larger environment are executed with a similar duration. The median and average values, 21.0s and 28.34s for the small environment, and 26.0s and 39.73s for the large environment do not differ that much.
REFERENCES Cavalieri, S., Garetti, M., Macchi, M., and Taisch, M. (2000). An experimental benchmarking of two multiagent architectures for production scheduling and control. Computers in Industry, 43(2), 139–152. Fortnow, L. and Homer, S. (2003). A short history of computational complexity. Bulletin of the EATCS, 80, 95–133. Hartmanis, J. and Stearns, R.E. (1965). On the computational complexity of algorithms. Transactions of the American Mathematical Society, 117, 285–306. Holvoet, T. and Valckenaers, P. (2006). Beliefs, desires and intentions through the environment. In Proceedings of the fifth international joint conference on Autonomous agents and multiagent systems, AAMAS ’06, 1052–1054. ACM, New York, NY, USA. Holvoet, T., Weyns, D., and Valckenaers, P. (2009). Patterns of delegate mas. In Proceedings of the 2009 Third IEEE International Conference on Self-Adaptive and Self-Organizing Systems, SASO ’09, 1–9. IEEE Computer Society, Washington, DC, USA. Valckenaers, P. and Brussel, H.V. (2005). Holonic manufacturing execution systems. CIRP Annals - Manufacturing Technology, 54(1), 427–432. Van Belle, J., Philips, J., Ali, O., Saint Germain, B., Van Brussel, H., and Valckenaers, P. (2012). A serviceoriented approach for holonic manufacturing control and beyond. In T. Borangiu, A. Thomas, and D. Trentesaux (eds.), Service Orientation in Holonic and Multi-Agent Manufacturing Control, volume 402 of Studies in Computational Intelligence. Springer Berlin / Heidelberg. Verstraete, P., Valckenaers, P., Van Brussel, H., Saint Germain, B., Hadeli, K., and Van Belle, J. (2008). Towards robust and efficient planning execution. Eng. Appl. Artif. Intell., 21, 304–314.
However, a Wilcoxon rank sum test rejects the null hypothesis that two sets of measurements are drawn from the same distribution with a z-score of −4.82 and p-value 978-3-902823-33-5/13/$20.00 © 2013 IFAC
34