Routing Driverless Transport Vehicles in Car Assembly with Answer Set Programming

04/27/2018 ∙ by Martin Gebser, et al. ∙ 0

Automated storage and retrieval systems are principal components of modern production and warehouse facilities. In particular, automated guided vehicles nowadays substitute human-operated pallet trucks in transporting production materials between storage locations and assembly stations. While low-level control systems take care of navigating such driverless vehicles along programmed routes and avoid collisions even under unforeseen circumstances, in the common case of multiple vehicles sharing the same operation area, the problem remains how to set up routes such that a collection of transport tasks is accomplished most effectively. We address this prevalent problem in the context of car assembly at Mercedes-Benz Ludwigsfelde GmbH, a large-scale producer of commercial vehicles, where routes for automated guided vehicles used in the production process have traditionally been hand-coded by human engineers. Such ad-hoc methods may suffice as long as a running production process remains in place, while any change in the factory layout or production targets necessitates tedious manual reconfiguration, not to mention the missing portability between different production plants. Unlike this, we propose a declarative approach based on Answer Set Programming to optimize the routes taken by automated guided vehicles for accomplishing transport tasks. The advantages include a transparent and executable problem formalization, provable optimality of routes relative to objective criteria, as well as elaboration tolerance towards particular factory layouts and production targets. Moreover, we demonstrate that our approach is efficient enough to deal with the transport tasks evolving in realistic production processes at the car factory of Mercedes-Benz Ludwigsfelde GmbH.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Automated guided vehicles play a key role in modern industries, let it be in warehouses, mines, or as in our case production facilities. Most of the time, however, these vehicles are programmed by human engineers to execute specific tasks. This makes it impossible to quickly reassign tasks in case of breakdowns or to easily react to changing production requirements, not to mention the missing portability between different production plants and factory layouts. The lack of elaboration tolerance does not only lead to high expenditures, but the resulting rigid control also rules out any flexible fleet management. In particular, no conclusions can be drawn about the effectiveness or even optimality of pre-programmed vehicle routes.

In view of these common circumstances, we address the challenge of devising a new control system for automated guided vehicles supplying the assembly lines at the car factory of Mercedes-Benz Ludwigsfelde GmbH, which is expected to be flexible enough to adapt to malfunctions and emerging requirements, and whose quality of operation can be measured and optimized relative to given objectives. To make our specific task more precise, consider the retouched layout of an assembly hall at the production plant of Mercedes-Benz Ludwigsfelde GmbH in Figure 1.

Figure 1: Real-world factory layout with transport corridors and directions indicated by arrows

The overall goal is to guarantee that all car components are at their designated place next to the assembly line when they are due for installation. The corresponding transport tasks are accomplished by a heterogeneous fleet of automated guided vehicles that fetch the necessary components from several storage areas. For instance, a vehicle may first halt at some storage location to load production material, then move on to an assembly station in need of the material, and from there cart off leftover material to a recycling facility. The sketched task thus involves stopovers at three distinct locations, between which the vehicle must pick a route without getting blocked by others, where dedicated parking spaces are included in the layout to let vehicles make room. Notably, the regular production process runs periodically, so that the given transport tasks have to be repeatedly executed in fixed intervals.

To make the execution of transport tasks more effective, we propose to perform task assignment and vehicle routing by means of Answer Set Programming (ASP; lifschitz99b), given its declarative and elaboration tolerant approach to combinatorial multi-objective problem solving. This results in a transparent and easily adjustable problem description along with optimal solutions relative to objective criteria. Regarding performance, it also turns out that our approach is efficient enough to meet the industrial-scale requirements of production processes at the car factory of Mercedes-Benz Ludwigsfelde GmbH.

The paper is structured as follows. In the next section, we start by formalizing automated guided vehicle routing for transport tasks evolving in production processes at the car factory of Mercedes-Benz Ludwigsfelde GmbH. Once this is accomplished, we provide in Section 3 a corresponding ASP encoding, incorporating the hard and soft constraints on solutions. In Section 4, we empirically evaluate our approach on use cases designed to test the practical applicability of control systems for automated guided vehicles. Finally, we conclude the paper with a brief discussion of related work and the achieved results.

2 Problem Formalization

In what follows, we formally describe the automated guided vehicle routing scenarios faced in production processes at the car factory of Mercedes-Benz Ludwigsfelde GmbH, the conditions on their solutions, as well as objective criteria concerning solution quality devised together with production engineers at Mercedes-Benz Ludwigsfelde GmbH.

An automated guided vehicle routing scenario is specified in terms of a directed graph , where the nodes  stand for locations of interest and the edges provide connections between them, along with a set  of transport tasks. Among the nodes in , we distinguish particular halt and park nodes, given by and such that holds. Moreover, each task has an associated non-empty sequence of subtasks, whose elements are halt nodes, i.e., , and we write and , for , to refer to the number of or individual subtasks, respectively, associated with . In addition, every edge, halt or park node, and task is characterized by some positive integer, denoted by for , where expresses the move duration for a connection , provides the halt or park duration for a location , and constitutes the deadline for completing a task . Finally, a set  of vehicles usable for transport tasks is given together with, for each , an initial location such that when . The vehicles can accomplish transport tasks by taking connections and halting at the locations of respective subtasks, whose halt durations reflect time spent to operate carried materials (e.g., loading or unloading), while further stops are admitted at park nodes only, included for allowing a vehicle to wait in case its subsequent route is temporarily blocked by others.

Example 1

The scenario depicted (in black) in Figure 2 consists of the nodes and edges . The halt nodes are indicated by diamonds in Figure 2, and the park node in is marked by a square. The two tasks in include three subtasks each, where the respective sequences of halt nodes, and , are listed within red or blue labels, respectively, near the subtasks. Similarly, the initial locations and of the vehicles in are indicated by corresponding labels. While Figure 2 does not display the durations, we assume a uniform move duration per connection , a halt duration at each of the four halt nodes , and a park duration at the park node . Moreover, the deadline for both tasks, and , is given by and also omitted in Figure 2 for better clarity.

Figure 2: Optimal routes to accomplish two transport tasks with three subtasks each by two vehicles

A solution to a guided vehicle routing scenario comprises a task assignment along with a strict partial order on such that either or holds when for tasks . In addition, for each vehicle , it contains a route , where , subject to the following conditions:

  1. If , for , or , for , holds for some , then we require that or , where we let .

  2. For any subtask of a task with , we define its completion index by and require that . In words, the subtasks of all tasks assigned to a vehicle  have to be completed in the order given by (as well as sequences of subtasks) within their respective deadlines, where a subtask is completed once the route includes a halt at its location such that all preceding subtasks have been completed before.

  3. If for a halt node and , then we require that for some subtask of a task with . That is, halts may be included in the route of a vehicle  exclusively for completing subtasks of tasks assigned to .

  4. With each , we associate a set of occupation times defined as . For any vehicle , the following requirements check that the routes of  and  do not both lead to a joint location at the same time, and that  and  do not meet in between nodes by taking connections in opposite directions: for each location , we require that , while must hold for each bidirectional connection pair .

Example 2

The red and blue arrows and labels in Figure 2 indicate the routes of a solution to the automated guided vehicle routing scenario from Example 1, where the task assignment is given by and . As no distinct tasks are assigned to the same vehicle, we have that the order relation is empty, while and have to complete the subtasks of or , respectively, in order. The routes taken by and can be traced by considering the times of completing route elements, included in labels along nodes and edges, in increasing order, starting from and at the initial locations and . For vehicle , this yields the route , where the four stops at halt or park nodes in are of particular interest. In fact, the inclusion of the park node  at the second position of delays the subsequent move by the park duration in order to avoid arriving at node  at the same time as the other vehicle . Unlike that, the later stops at the halt nodes , , and  are made to complete the sequence of subtasks. While makes revisit the halt nodes and , a halt would not be admitted on the first arrival because the preceding subtask or , respectively, has not yet been completed. Hence, the halt at  comes before returning to and halting at , and then in turn at  at the very end of the route . As one can check, the sum of durations over connections as well as halt and park nodes in is , which means that the task  gets completed within its deadline . Regarding the other vehicle , tracing the blue labels in Figure 2 yields the route for completing the sequence of subtasks. Along this route, visits the halt nodes and twice, where halts are in both cases made on the second arrival for completing the subtasks of  in order. Moreover, no stop at the park node  is needed to avoid meeting the other vehicle , and the durations of connections and halt nodes in sum up to , so that also the task  gets completed within its deadline .

While an automated guided vehicle routing scenario may have plenty feasible solutions, we apply the following objective criteria, below ordered by significance, to distinguish preferred collections of routes for the vehicles :

  1. The makespan of a solution is the maximum sum of durations over the route elements of some vehicle, i.e.,

  2. The route length of a solution is the sum of durations over elements in the routes of all vehicles, i.e.,

  3. The crossing number is the number of pairs such that , , and we have that and for some connections with , , and , i.e.,

    In words, the crossing number estimates how often the routes of distinct vehicles come together at a joint location (at different times). Although solutions are such that vehicles do not share any location at the same time, it is desirable to make routes as disjoint as possible to keep knock-on effects in case of a disruption short.

  4. The overlap number is the number of triples such that , , and we have that and (or ) for some connection (or connections ), , and , i.e.,

    The motivation for aiming at a small overlap number is the same as with the crossing number, while connections taken by distinct vehicles are considered instead of crossing locations. Note that, for a bidirectional connection pair , two vehicles and that move between and in either direction can contribute one, two, or four triples , depending on whether neither, one, or both include as well as in their routes. Unlike that, only the triple is obtained when but .

For each of the four objective criteria specified above, a smaller value is preferred to greater ones. The order of significance is chosen such that the completion of all transport tasks in as little time as possible has the highest priority, minimizing the overall utilization of vehicles comes second, keeping routes disjoint is third, and the avoidance of overlapping connections takes the lowest priority.

Example 3

The solution to the automated guided vehicle routing scenario from Example 1 indicated in Figure 2 and described further in Example 2 happens to be optimal relative to the applied objective criteria. Given that the sums and are obtained for the durations of elements of the route or , respectively, the makespan matches the maximum , and the route length amounts to . Regarding the crossing number , and visit three locations, , , and , via different connections, as witnessed by occurrences of and , and , as well as and in or , respectively. Moreover, the overlap number is obtained in view of the inclusion of the connections , , , , , and in both and along with moves between the nodes  and  as well as and  in either direction, each of the latter contributing four triples counted together by . While the gap between the makespan and the deadline for and may seem small, let us mention that 561 solutions are feasible and that only one of them is optimal. Such discrepancy clearly indicates that human engineers will hardly be able to perform an exhaustive optimization of routes in realistic scenarios of greater size only by hand.

3 Problem Encoding

Fact Meaning
halt(,) with halt duration
park(,) with park duration
stay(,) with halt or park duration
edge(,,) with move duration
less(,,) for lexicographically consecutive locations
task(,) with deadline
tasks(,) and
subtask(,s()) with
subtask(,s(),) , , and with
vehicle(,) with initial location
Table 1: Fact format for specifying automated guided vehicle routing scenarios in ASP

Following the common modeling methodology of ASP, we represent (optimal) solutions to automated guided vehicle routing scenarios by facts specifying an instance along with a uniform problem encoding. To begin with, Table 1 surveys the format of facts describing the locations, connections, tasks, and vehicles belonging to an automated guided vehicle routing scenario. The respective fact representation of the scenario from Example 1 is given in Listing 1, using the shorthands ‘..’ and ‘;’ of clingo [Gebser et al. (2015)] to abbreviate facts for a range or collection of arguments, respectively. Note that facts of the form stay(,) combine halt and park nodes whose associated duration is greater than one, as such non-atomic durations are subject to dedicated conditions in our problem encoding below. For locations that have several incoming connections, facts of the form less(,,) provide lexicographically consecutive locations such that , based on the standard term order of the ASP-Core-2 language [Calimeri et al. (2012)]. Our encoding below makes use of the lexicographical order of predecessor locations for a compact formulation of conditions to detect crossings. Moreover, facts time() give time points of interest, ranging from zero to the latest deadline of any transport task, and tasks(,) holds for distinct tasks and , which have to be ordered by when . Facts of the remaining predicates list further properties of automated guided vehicle routing scenarios in a straightforward way, and their respective meanings are summarized in Table 1.

halt(v(2),3). stay(v(2),3).
halt(v(4),3). stay(v(4),3).
halt(v(5),3). stay(v(5),3).
halt(v(6),3). stay(v(6),3).
park(v(7),2). stay(v(7),2).
edge(v(6;7),v(1),4). less(v(6),v(7),v(1)).
edge(v(3;7),v(4),4). less(v(3),v(7),v(4)).
edge(v(1;4),v(7),4). less(v(1),v(4),v(7)).
task(t(1)). task(t(1),60). tasks(t(1),t(2)).
task(t(2)). task(t(2),60). tasks(t(2),t(1)).
subtask(t(1),s(1)). subtask(t(1),s(1),v(5)).
subtask(t(1),s(2)). subtask(t(1),s(2),v(4)).
subtask(t(1),s(3)). subtask(t(1),s(3),v(2)).
subtask(t(2),s(1)). subtask(t(2),s(1),v(6)).
subtask(t(2),s(2)). subtask(t(2),s(2),v(4)).
subtask(t(2),s(3)). subtask(t(2),s(3),v(2)).
vehicle(c(1)). vehicle(c(1),v(1)).
vehicle(c(2)). vehicle(c(2),v(2)).
Listing 1: Instance of automated guided vehicle routing with two tasks and two vehicles
Atom Meaning
assign(,) for and
share(,) for such that lexicographically
order(,) for and such that
check() is topological in order(,) holds
check(,) or check() holds for and
pass(,,s(),,,) , , , and
for and with such that
done(,s(),) , , and such that
for with
wait(,) and for and
such that ,
where with
at(,,) for and with
move(,,,) for , , ,
and with
move(,) move(,,,) holds for some connection
moving(,,,) for , , ,
moving(,,) moving(,,,) holds for some vehicle
free(,,) , , and
with and such that
, for some
, and
free(,) and such that
or free(,,) holds,
where for some
used(,) and with
move(,,) move(,,,) holds for some
mark(,,) move(,,) holds for some connections
such that lexicographically
same(,,,) move(,,) and move(,,) hold for
such that lexicographically
Table 2: Atoms characterizing solutions to automated guided vehicle routing scenarios

Our uniform problem encoding, given in Listings 2 and 3, can be understood as a merger of four logical parts, addressing task assignment and ordering, task completion, vehicle routing, as well as objective criteria (the latter part shown separately in Listing 3). Table 2 follows this logical structure in providing the meanings of predicates defined in each of the four parts, where a condition written in the right column applies if and only if a corresponding atom of the form given in the left column belongs to a stable model.

23% task assignment
25{assign(C,T) : vehicle(C)} = 1 :- task(T).
27 share(T1,T2)  :- assign(C,T1), assign(C,T2), T1 < T2.
28{order(T1,T2)} :- share(T1,T2).
29 order(T2,T1)  :- share(T1,T2), not order(T1,T2).
31check(T1,T2) :- tasks(T1,T2), not order(T1,T2).
32check(T1,T2) :- tasks(T1,T2), check(T1).
33check(T2)    :- task(T2), check(T1,T2) : tasks(T1,T2).
34:- task(T2), not check(T2).
36% task completion
38pass(C,T,s(1),V,D,N) :- assign(C,T), at(C,V,N), halt(V,D), task(T,M),
39                        subtask(T,s(1),V), not wait(T,N), N < M.
40pass(C,T,s(I),V,D,N) :- assign(C,T), at(C,V,N), halt(V,D), task(T,M),
41                        subtask(T,s(I),V), done(T,s(I-1),N), N < M.
43done(T,S,N+D) :- pass(C,T,S,V,D,N), task(T,M), not move(C,N), N+D <= M.
44done(T,S,N+1) :- done(T,S,N), not task(T,N).
45:- task(T,M), subtask(T,S), not done(T,S,M).
47wait(T2,N) :- order(T1,T2), task(T1,M1), task(T2,M2), time(N),
48              subtask(T1,s(I)), not subtask(T1,s(I+1)),
49              not done(T1,s(I),N), N < M1, N < M2.
51% vehicle routing
53at(C,V,0)    :- vehicle(C,V), time(0).
54at(C,V2,N+D) :- move(C,V1,V2,N), edge(V1,V2,D).
55at(C,V,N+1)  :- at(C,V,N), park(V,D), time(N+1), not move(C,N).
56at(C,V,N+1)  :- pass(C,T,S,V,D,N), not done(T,S,N), not move(C,N).
57:- node(V), time(N), #count{C : at(C,V,N)} > 1.
58:- vehicle(C), time(N), #count{V : at(C,V,N)} > 1.
60{move(C,V1,V2,N) : edge(V1,V2,D), time(N+D)} < 2 :- vehicle(C), time(N).
61 move(C,N) :- move(C,V1,V2,N).
62:- move(C,V1,V2,N), not at(C,V1,N).
64moving(C,V1,V2,N+1) :- move(C,V1,V2,N).
65moving(C,V1,V2,N+1) :- moving(C,V1,V2,N), time(N+1), not at(C,V2,N).
66moving(V1,V2,N)     :- moving(C,V1,V2,N).
67:- moving(V1,V2,N), moving(V2,V1,N).
69free(C,D,N)   :- at(C,V,N), stay(V,D), not at(C,V,N-1).
70free(C,D,N+D) :- free(C,D,N), time(N+D), not move(C,N).
71free(C,N)     :- free(C,D,N).
72free(C,N)     :- vehicle(C), time(N), not at(C,V,N) : stay(V,D).
73:- move(C,N), not free(C,N).
Listing 2: Encoding of task assignment, completion, and automated guided vehicle routing

In more detail, the encoding part addressing task assignment and ordering is shown in Lines 3–12 of Listing 2. The choice rule in Line 3 makes sure that exactly one atom of the form assign(,) holds per task , providing the vehicle such that . Further rules deal with the order  among tasks assigned to a common vehicle, where share(,) is derived by the rule in Line 5 if for tasks . The choice rule in Line 6 then either picks order(,), expressing that , or the rule in Line 7 yields order(,), standing for , otherwise. The remaining rules in Lines 9–12 check that the order relation is acyclic, utilizing modeling methods detailed in [Gebser, Janhunen, and Rintanen (Gebser et al.)].

The second encoding part in Lines 16–27 deals with the completion of transport tasks. To this end, the two rules in Lines 16–19 indicate time points  such that the vehicle with visits the halt node given by a subtask , while any preceding subtasks according to as well as the sequence of subtasks of  are already completed at time . In case , the latter condition is in Line 17 checked by the absence of yet incomplete tasks such that , and otherwise the completion of up to time  is required by preconditions in Line 19. The rule in Line 21 then derives done(,s(),), signaling the completion of , provided that does not exceed the deadline for and the vehicle  to which is assigned halts at time . Note that the occurrence of a halt in the route of  is determined by the absence of move(,) from a stable model, an atom that would otherwise indicate that  takes some connection at time . The condition that all transport tasks have to be completed within their respective deadlines is further taken care of by the rule in Line 22, which successively propagates the completion of a subtask on to the deadline , along with requiring the completion of any subtask at by means of the integrity constraint in Line 23. Finally, the rule in Lines 25–27 derives wait(,), an atom inspected in Line 17, in view of a yet incomplete subtask of some task such that at time , where considering the last subtask of only is sufficient because the subtasks of  must be completed in order.

The actual routes of vehicles are tracked by the third encoding part in Lines 31–51. To begin with, the rule in Line 31 derives at(,,), expressing that any vehicle starts from its initial location at time . The new location resulting from a move at time  is reflected by the rule in Line 32 yielding at(,,). A stop at some park node is addressed by the rule in Line 33, deriving at(,,) from at(,,) in the absence of any move made by  at time . Moreover, the rule in Line 34 takes care of a halt to complete some subtask by deriving at(,,) in case no subtask preceding is yet incomplete and itself is not already completed at time , provided that the vehicle  with does not make any move at . As a consequence, atoms of the form at(,,) in a stable model match times for vehicles and locations , where halts can only be made for completing assigned subtasks. Given this, the integrity constraint in Line 35 makes sure that for any , and the one in Line 36 asserts that for any , thus constituting a redundant/entailed state constraint that may still be helpful regarding solving performance [Gebser et al. (2012)].

Unlike stops at halt or park nodes, a move by some vehicle at time  such that is still of interest is signaled by an atom move(,,,), picked by means of the choice rule in Line 38. The rule in Line 39 then provides the projection of such an atom to move(,), and the integrity constraint in Line 40 requires to be at the location  at time . Moreover, atoms moving(,,,), derived by the rules in Lines 42–43 for , yield time points . Their projection to moving(,,) in Line 44 is inspected by the integrity constraint in Line 45 to, in case , make sure that holds for any . The remaining rules in Lines 47–51 check that the moves of a vehicle  respect non-atomic durations of halt and park nodes . To this end, an atom free(,,) is derived by the rule in Line 47 when is not already at  at time , and then propagated on in steps of the halt or park duration by the rule in Line 48 as long as does not make any move. The projection to free(,) in Line 49 along with the rule in Line 50, also deriving free(,) in case is not at any halt or park node with at time , indicate all times  at which may make a move, and the integrity constraint in Line 51 restricts moves to such time points.