Academic project · University of Aberdeen · September 2026
AI Planning for Computer Order Fulfilment
Modelling assembly and refurbishment workflows under compatibility and shared-stock constraints, then comparing hierarchical and classical planners with independently checked plans.
- Benchmark instances
- 54
- Recorded planner runs
- 216
- Verified solution runs
- 206
The problem
A workshop must fulfil a batch of computer orders using compatible loose parts and computers it already owns. Orders can allow new assembly, refurbishment, or either route. A flexible order can consume a component that another order needs, so a valid plan must account for the whole batch as well as the required inspection, testing, configuration, and dispatch procedures.
My contribution
- Modelled the workshop using HDDL task hierarchies and a matched PDDL baseline, with eleven primitive operations and explicit compatibility and stock constraints.
- Built a generator and experiment pipeline for paired instances, including feasible witnesses, stock-shortage controls, and coupled allocation conflicts.
- Evaluated four planner configurations and checked returned plans using typed action replay and native hierarchical verification.
Approach
Represent the workflow
Six methods and four compound tasks describe how orders are fulfilled. A bounded dispatcher lets the planner choose any pending order while one workstation serialises the physical operations.
Construct matched problems
A 45-case grid varies order count, loose-memory stock, and generator seed. Nine control cases test baseline behaviour, joint allocation conflicts, and stock availability.
Compare four configurations
PANDA uses RC-FF and RC-add; Fast Downward uses FF and additive heuristics. Each preprocessing and search process has a separate 30-second wall watchdog.
Verify returned plans
Action preconditions, effects, and goals are replayed, then the primitive sequence is checked against the HDDL hierarchy. All 24 permutations of a four-order witness were also verified.
Results & findings
The native macOS benchmark contains 206 verified solution runs, eight unsolvable outcomes, and two timeouts. PANDA RC-add and both Fast Downward configurations solved every feasible instance in this benchmark.
| Configuration | Feasible cases solved | Unsolvable outcomes | Timeouts |
|---|---|---|---|
| PANDA RC-FF | 50 / 52 | 2 | 2 |
| PANDA RC-add | 52 / 52 | 2 | 0 |
| Fast Downward FF | 52 / 52 | 2 | 0 |
| Fast Downward add | 52 / 52 | 2 | 0 |
Each configuration was run on the same 54 instances: 52 feasible cases and two unsolvable controls. Measured on macOS.
- RC-FF timed out on two eight-order cases while solving all ten-order cases. Instance structure and heuristic guidance mattered alongside problem size.
- Extra memory stock did not consistently reduce search effort: it also introduced more possible allocations.
- PANDA RC-add reached the shortest primitive plan length on all 45 grid cases. Greedy search still provides no general optimality guarantee.
Experiments & analysis
Select a figure to view it at full size.
How the dispatcher preserves job-order choice
This method selects a pending order, fulfils it, and recurses to the next batch level. The level bounds decomposition depth; it does not impose a fixed customer sequence.
HDDL · Source excerpt
(:method select-and-fulfil-next-order
:parameters (?level ?next - batch-level ?o - order)
:task (process-orders ?level)
:precondition (and
(next-level ?level ?next)
(pending ?o)
)
:ordered-subtasks (and
(job (fulfil-order ?o))
(remaining (process-orders ?next))
)
)Limitations & what I learned
- The benchmark uses synthetic, fully known inventory and deterministic outcomes. It does not establish performance on real workshop workloads.
- Each case/configuration has one native timing measurement. Different encodings, grounding stages, heuristics, and search representations prevent attributing runtime differences to HDDL or PDDL alone.
- The implementation plans for a static batch. New arrivals require an updated problem and replanning; a continuously running arrival controller is outside this implementation.
Where I would take this next
- Repeat timing measurements and test additional allocation patterns and inventory distributions.
- Explore how an arrival-and-replanning controller could update the static planning model between completed orders.