- The paper presents a standards-based method that automatically converts distributed AAS capability models into complete typed STRIPS PDDL domains and problems without requiring engineers to write PDDL.
- The method uses VDI 3682, IEC 61360-1, and IDTA 02011/02016 semantics, resolving references across multiple AASX files through a shared object store and generating models in about 0.3 seconds.
- The Festo MPS 500 case study generated 11 types, 11 predicates, 9 actions, and 45 objects, while revealing that one bypass path reduced optimal plan length by 46% through improved carrier traffic management.
Motivation and Problem Statement
Designing a production system requires early verification that a proposed layout supports all required production sequences. Automated planning over PDDL models can answer such questions, but authoring PDDL domains and problems demands expertise that production engineers typically lack. This paper by Nabizada et al. proposes an "AAS-native" solution: deriving complete PDDL specifications directly from Asset Administration Shell (AAS) capability models, so that engineers model capabilities only, never PDDL syntax (2606.02167). The work addresses two research questions: (RQ1) how AAS capability models can be systematically transformed into PDDL planning problems, and (RQ2) how the transformation handles distributed Multi-AAS architectures in which planning information is spread across multiple files.
Relation to Prior Work
Existing PDDL-generation approaches operate on OWL ontologies (Balakirsky; SWS2PDDL), IEC 62264/ISA-95 process models, SysML system models, or natural language via LLMs. The closest prior work, Bernhard et al., introduced a dedicated PDDL-description submodel inside the AAS but left automated transformation to future work. The distinguishing claim of this paper is that no PDDL-specific AAS structures are needed at all: all planning elements can be derived from four established standards — VDI 3682 (formalized process descriptions), IEC 61360-1 (semantic property qualification), IDTA 02011 (hierarchical structures/type hierarchies), and IDTA 02016 (control component instances). This means existing capability models can be reused without modification, and engineers are shielded entirely from planning concepts. The approach builds on earlier evidence by Vieira da Silva et al. that capability models formalized as OWL ontologies carry sufficient semantics for PDDL generation; the present contribution operationalizes this within the AAS metamodel.
Mapping and Extraction Algorithm
Each component of the production system is modeled in its own AASX file containing four submodels: TypeHierarchy, DataElementTypes, Capabilities, and Instances. The element-level mapping is systematic:
| PDDL element |
AAS source |
Standard |
| Type names / hierarchy |
Entity idShort / Parent references |
IDTA 02011 |
| Predicates |
DataElementType idShort and parameters |
IEC 61360-1 |
| Actions |
ProcessOperator (capability) name and parameters |
VDI 3682 |
| Preconditions / effects |
hasInput / hasOutput states |
VDI 3682 + IEC 61360-1 |
| Objects |
Instances |
IDTA 02016 |
| Init / goal facts |
initialStates / goals |
IEC 61360-1 |
The semantic core is the joint use of two IEC 61360-1 qualifiers. ExpressionGoal assigns the role of a state description: Requirement yields a precondition (or a goal fact at instance level), Assurance yields an effect, ActualValue yields an initial-state fact. InterpretationLogic assigns polarity: Equal produces a positive literal, NotEqual a negated one. This combination uniformly covers positive preconditions, negative preconditions, add effects, and delete effects without special cases.
The extraction algorithm operates in five phases — types, predicates, actions, objects, init/goal — after loading all AASX files into a shared in-memory object store. Every cross-submodel and cross-AAS reference (typeDefinitionRef, dataElementTypeRef, parameterBindingRef, instanceTypeRef) is resolved by looking up globally unique AAS identifiers in this registry, so no element names or type mappings are hardcoded; the algorithm generalizes without modification to any system following the schema. Implementation uses the BaSyx Python SDK for parsing and the Unified Planning Framework (UPF) for model construction, with PDDL export or direct solving through any UPF-integrated planner. The toolchain and example models are publicly released.
Case Study: Festo MPS500 and Design Space Exploration
The approach is validated on AAS models of the Festo MPS 500, a laboratory system with 30 unidirectional conveyor segments in a circular layout, seven stations, four carriers, and two product types. Nine component AAS files yield 11 PDDL types, 11 predicates, 9 actions, and 45 objects — roughly 520 lines of generated PDDL per run. Generation takes about 0.3 s (median of five runs), and Fast Downward solves the output to certified optimality (SOLVED_OPTIMALLY) with no hand-editing, which is a strong claim for the correctness and completeness of the automatic transformation.
The design space exploration varies which of two inner bypass conveyor paths are present, across four layout variants, holding the production scenario fixed:
| Variant |
Inner paths |
Optimal plan length |
Savings |
| A |
upper + lower |
35 steps |
46% |
| D |
lower only |
35 steps |
46% |
| C |
upper only |
59 steps |
9% |
| B |
none |
65 steps |
— |
Two findings stand out. First, variants A and D produce identical optimal plan lengths, indicating the upper path is unused in this scenario; the lower path alone accounts for the full 46% reduction. Second, and more substantively, the planner reveals that inner paths reduce plan length primarily by easing traffic management for idle carriers rather than by shortening the product's route — a non-obvious interaction between topology and multi-carrier logistics that the authors argue is difficult to anticipate manually. Planner search time varies considerably, from 6.8 s (variant D) to 219 s (variant B), while generation remains a sub-second overhead independent of the variant. All variants are produced purely by editing the connected facts of the ConveyorBelt AAS.
Limitations and Open Questions
The paper is explicit about its boundaries. The generated PDDL is restricted to typed STRIPS-style constructs with negative preconditions; although VDI 3682 and IEC 61360 support durations and numeric data, mapping them to PDDL 2.1 durative actions and numeric fluents is deferred. Component AAS models are authored manually in this work — the pipeline automates PDDL generation but not the upstream capability modeling, though the authors note MTP-based and LLM-based derivation could be combined with their method. The case study is a laboratory system evaluated entirely on models, with no physical execution; validation on industrial-scale systems remains open, as does a comprehensive exploration varying initial states and goals rather than only topology. Finally, integration with MBSE approaches for a continuous model chain from conceptual design through AAS to PDDL is proposed but not demonstrated.
Conclusion
The paper demonstrates that AAS capability models structured according to VDI 3682, IEC 61360-1, and IDTA 02011/02016 contain sufficient information to automatically generate complete, planner-ready PDDL domains and problems, resolving distributed information across Multi-AAS architectures via a shared reference-resolving object store. The Festo MPS 500 case study shows the resulting workflow supports systematic design space exploration — here uncovering that a single bypass conveyor path yields a 46% reduction in optimal plan length through carrier traffic management — without any engineer exposure to PDDL. The main open questions are extension to temporal and numeric planning constructs, reduction of upstream modeling effort, and validation at industrial scale.