As modern production systems become increasingly complex, traditional document-based systems engineering methods struggle to meet contemporary challenges, such as maintaining consistent knowledge bases across disciplines and ensuring early validation and verification processes. Model-Based Systems Engineering (MBSE) using Systems Modeling Language (SysML) provides a structured, model-centric approach for managing this complexity, yet the manual generation of AI planning descriptions in the Planning Domain Definition Language (PDDL) remains labor-intensive and error-prone. This paper presents an automated approach to generating PDDL domain ifles from SysML-based system models enriched with a specific SysML profile for PDDL, as part of a broader workflow aimed at enhancing planning processes in complex systems engineering. The proposed algorithm systematically extracts types, predicates, and actions from the enriched models, converting them into comprehensive PDDL descriptions suitable for automated planning systems. An Implementation using the Velocity Template Language (VTL) integrated into MBSE tools like Magic Systems of Systems Architect (MSoSA) demonstrates the approach's eficacy, as shown in an application case in aircraft fuselage assembly. This automation enhances the accuracy and eficiency of planning processes, facilitating rapid exploration and optimization of system configurations. The generated PDDL files were validated by integrating them into a PDDL solver, confirming the utility of the approach in real-world scenarios.
Language
The increasing complexity of modern production systems has rendered traditional document-based systems engineering methods inadequate for addressing today’s chall2e]n.gTehsis[ includes the need for a unified knowledge base as system complexity increases, allowing data exchange across diferent engineering phases and discipline3s] [and ensuring that validation and verification processes can already be carried out during the early engineering ph4]a.sTeos [efectively manage this complexity, Model-Based Systems EngineeringMB(SE) has emerged as a powerful methodology, providing a structured and model-centric approach to system developMmBenSEt.facilitates a detailed, consistent, and comprehensive description of production systems, significantly improving collaboration across the various disciplines involved in the development proc5e,s6s].[
Among the languages available fMoBrSE, the Systems Modeling LanguagSey(sML) is particularly well-suitedS. ysML provides a broad range of modeling elements that can represent the structure, behavior, and requirements of a syste7m].[By leveraging workflows such as those described i8n],[SysML LGOBE
https://www.hsu-hh.de/aut/team/nabiza(dHa. Nabizada);https://www.hsu-hh.de/aut/team/jeleniews(Tk.i Jeleniewski);
CEUR
ceur-ws.org (:requirements :strips :typing) (:predicates (at ?p - part ?l - location) (available ?t - tool) (in-assembly ?p - part) (assembled ?p - part)) (:types
tool part location) can support a structured approach to system modeling that not only ensures consistency and early error detection but also enables exploration and comparison of various system configur9a].tHioonwse[ver, evaluating these alternatives requires both static and dynamic analysis of the system configurations [10].
One of the critical challenges in dynamic analysis is the allocation of individual process steps to the
appropriate technical resources capable of executing them, enabling a detailed view of setup and cycle
times [
Artificial IntelligenceAI() planning could be a valuable approach for tackling dynamic analysis challenges in the engineering of modern production systems, as it can automatically generate the necessary sequences of steps and assign the appropriate resources to each step to achieve specific goals [12]. The Planning Domain Definition LanguagePD(DL) has emerged as the de facto standard for formalizing planning descriptionsAfIoprlanning solvers13[]. However, despite its widespread use, manually modelinPgDDL descriptions remains a complex and time-consuming task that requires substantial domain knowledge and expert1i4s]e. [Modeling these planning descriptions involves defining a domain file, which specifies the available actions, objects, and predicates for planning. The following listinLgi(sting 1) is a simple example of aPDDL domain file that defines actions, objects, and predicates for an assembly task:
Listing 1:Example of a simplified PDDL domain file for an assembly task
This PDDL domain file provides a simple example of howactions, objects, andpredicates are structured in an assembly task. Trehqeuirements section specifies that basiPcDDL planning functions (:action move :parameters (?p - part ?from - location ?to - location) :precondition (and (at ?p ?from)) :effect (and (not (at ?p ?from)) (at ?p ?to))) (:action start-assembly :parameters (?p - part ?t - tool) :precondition (and (available ?t) (not (in-assembly ?p)) (not (assembled ?p))) :effect (and (in-assembly ?p) (not (available ?t)))) (:action finish-assembly :parameters (?p - part ?t - tool) :precondition (and (in-assembly ?p)) :effect (and (assembled ?p) (not (in-assembly ?p)) (available ?t))) and typed objects are used. In tthyepes section, three object categories are definteodo:l, part, and location. These types form the foundation for modeling the planning process.
The predicates describe the states of the system, such as a part’s posiatti)o, nth(e availability of a toola(vailable), whether a part is being assembleidn-(assembly), and when it is fully assembled (assembled).
The actions defines the operations within the domain. Tmhoeve action represents moving a part from one location to another, with the precondition that the part must be at its current location, an the efect is updating the part’s position. Tshteart-assembly action initiates the assembly process, ensuring that the tool is available and the part is neither assembled nor in assembly. Once initiated, the part is marked aisn-assembly, and the tool is made unavailable. fTihneish-assembly action completes the assembly process, transitioning the partinfr-oamssembly to fullyassembled and making the tool available again for other tasks.
This example illustrates how domain files formalize the necessary elements for automated planning, which will be critical for generaPtDinDgL descriptions fromSysML models, as discussed later in the paper.
Much of the information needed to construct at least the domain file is already embedded within SysML-based system models. These models are used to represent the structure, behavior, and constraints of production systems. However, extracting and organizing this information manually is a timeconsuming process.
This paper introduces an approach for automating the generatPiDoDnLodfomain files by extracting information fromSysML-based system models. It is part of the broader workflow introduce1d5]i,n [ which focuses on enhancing the modeling and planning processes in complex systems engineering. The system models are enriched witPhDDL aspects using thSeysML profile for PDDL1, ensuring that the generatedPDDL files are both syntactically correct and semantically meaningful. By enabling the rapid and reliable generationPoDfDL domain files, this method facilitates more efective decision-making in the engineering phase, supporting the exploration of multiple system configurations and improving overall system design.
The remainder of this paper is structured as follows. Se2ctpiroonvides an overview of related work. Section3 presents the proposed algorithm for the automPaDtDedL description generation as a pseudocode. Sectio4n demonstrates a possible implementation using the Velocity Template Language (VTL). Section5 applies the algorithm to an application case in aircraft assembly. Finally, Section6 concludes the paper and outlines future research.
In this section, various approaches to generaPtDinDgL descriptions are reviewed. These methods range from manual modeling techniques to automated solutions.
A SysML taxonomy for describing assembly tasks is proposed by Huckaby et16a]l,.w[hich provides a basis for derivinPgDDL actions to represent system capabilities. However, this method involves manually creatinPgDDL descriptions, restricting its use to the predefined taxonomy. On the other hand, an ontology-based method to automatically genPDerDaLtedescriptions is introduced by Vieira da Silva et al1.7[], which aligns required and ofered capabilities. Although this approach automates the generation process, it relies on a specific capability model and does not incorporate existing models.
To simplify planning in Hierarchical Domain Definition LanguaHgDe D(L), a PDDL dialect,
Rimani et al.1[
In a diferent domain, Wally et al1.9[] present a method that translates ISA-95 manufacturing system models intoPDDL descriptions for production planning. However, the method is tailored to ISA-95-compliant systems, which limits its applicability across other modeling standards and systems that are not based on ISA-95.
Focusing on robotics, Konidaris et 2a0l]. d[escribe a method to create abstract symbolic representations that support high-level planning by learning from direct sensorimotor interactions rather than using existing models. Stoev et a2l1.][aim to automate the creation of domain-specific symbolic models from text by extracting knowledge from instructional materials, such as cooking recipes, to generatePDDL descriptions automatically. Both approac2h0,e2s1[], however, do not utilize existing models as a basis, which limits their ability to integrate with established frameworks and leverage pre-existing knowledge.
Although the approach of Konidaris et al. is data-driven rather than model-based, it merits special consideration because it use a probabilistic PDDL representation, which could be beneficial in contexts where uncertainty plays a significant role. However, in our approach, the need for structured, parametric PDDL representations generated directly PfrDoDmL models is crucial for integration MinBtSoE workflows. The set-theoretic, non-parametric format of Konidaris et al. limits flexibility and reusability withinMBSE, where parametrization is essential for describing complex system configurations. While the probabilistic aspect of PDDL could ofer value under high uncertainty, our application context prioritizes deterministic planning, where consistency with the structured system model is critical.
Nabizada et al.22[] introduce aSysML profile specifically designed to enhance the modeling and planning of complex production systems by integrating planning logic tPhDroDuLg.hThe profile enables anPDDL-specific extension of existingSysML-based system models, resulting in consistent and synchronized updates of planning and system information. As a result, any changes made to the system model automatically lead to corresponding modificatioPnDsDinL components. The applicability of the profile was validated in a real-world use case within the aerospace industry. However, utilizing this profile requires a structured methodology that outlines necessary steps to systematically extend system models with the profile.
In a related contribution, Nabizada e1t5a]lp.r[ovide the necessary structured methodology which is illustrated in Figu1r. eIt is a model-based workflow for generatiPnDgDL descriptions that integrates both system and product models and uses tSyhseML Profile for PDDL. The proposed workflow comprises four phases, each detailing the steps required to extend existing system and product models and automate the generation of PDDL files.
In Phase IV, the focus is on automatically generating a domain description and a problem description. This phase is essential as it requires an algorithm capable of genePrDaDtiLndgescriptions efectively. The present paper focuses specifically on this phase, introducing and detailing the algorithm developed for generating the PDDL domain descriptions.
I sea System Model h P I I sea PDDL Profile h P
Analyze System
Model Create PDDL Domain (excl.
Actions) I I I se Product Model a h P
Identify
Product Information
Define Scope of Observation
Define Actions of Domain Extract Relevant Information
Identify relevant Elements
Extended System Model
Transfer to MBSE Environment
Phase IV Algorithm Generate
PDDL Descriptions Annotate according to PDDL Domain
PDDL Domain & Problem
Extended Product Model
PDDL Plan
Solve Problem Description
The proposed algorithm automates the generationPDoDfaL domain file from a SysML-based system
model that is enriched with a specSificysML profile for PDDL, as described in2[
The algorithm systematically extracts types, predicates, and actions from theSyensMriLchmeoddel and converts them into a comprehensPivDeDL domain file. Each step of the algorithm is designed to ensure that the resultPinDgDL file is both syntactically correct and semantically meaningful, ready for use in automated planning systems.
The pseudocode for the algorithm, presenteAdlignorithm ,1illustrates the direct correspondence between theSysML model elements and thePirDDL representations. The variables in the pseudocode align with the elements defined by the PDDL profile, providing a clear mapping and flow of data from theSysML model to thePDDL domain file. This structured approach enhances the development and optimization of production systems by ensuring a precise and eficient conversion process. This approach supports the engineering of production systems by enabling the generation of process sequences for various system configurations, which can then be evaluated afterwards.
Following this overview, the specific steps outlined in the pseudocAoldgeor(ithm )1will now be explained in detail.
Algorithm 1 Generation of the PDDL domain file Input: SysML-based system modelsm Output: PDDL domain file df function CreatePDDLDomain(sm) df ← InitializePDDLDomain(sm.PDDL_Domain) T ← ExtractTypes(sm.PDDL_Type) for each type in T do
ProcessTypeToPDDL(df, type) end for P ← ExtractPredicates(sm.PDDL_Predicate) for each predicate in P do
ProcessPredicateToPDDL(df, predicate) end for A ← ExtractActions(sm.PDDL_Action) for each action in A do
ProcessActionToPDDL(df, action) end for return df end function 1. Initialization of the PDDL Domain File The algorithm begins by initializing PtDheDL domain ifle, denoted asdf. This step involves setting up the base structure of the domain file based on the predefined domain specifications within thSeysML model (sm.PDDL_Domain). By using the «PDDL_Domain» stereotype from thSeysML profile, the model is annotated with all necessary planning-specific attributes, ensuring compatibility wPDitDhL syntax and semantics. This initialization phase prepares the domain file to correctly incorporate additional elements, such as types, predicates, and actions, which are defined in subsequent steps. 2. Extraction and Processing of Types Following the initialization, the algorithm extracts and processes the types defined in the SysML model, which are crucial for structuring the PDDL domain. • Extraction of Types: The algorithm identifies all elements in tSyhseML model that have been annotated with the «PDDL_Type» stereotype. These elements represent the object classes needed for thePDDL domain, such as machines, products, resources, tools, and more. The extracted types are gathered into a Tse.tThis extraction process takes advantage oSfytsMheL profile’s ability to clearly define type hierarchies and relationships, providing a structured and reusable framework for the PDDL domain. • Processing of Each Type: For each type in the seTt, the algorithm converts the SysML-based type information into tPhDeDL format. This includes translating any hierarchical relationships (e.g., supertype and subtype structures) defined within StyhseML model into corresponding PDDL representations. The resulting types are then incorporated PinDtDoLtdhoemain file ( df ), ensuring that all object categories are properly defined and structured according to the requirements of the planning task. 3. Extraction and Processing of Predicates The algorithm then focuses on predicates, which are essential for defining the logical structure of the planning domain.
• Extraction of Predicates: Predicates in thPeDDL domain are defined using elements in the SysML model that have been annotated with the «PDDL_Predicate» stereotype. These predicates describe the conditions or states of the system that must be true or false during the planning process. The algorithm extracts these elements and compiles them intPo.Tahseeutse of derived properties in thSeysML profile allows for a dynamic representation of predicate relationships and dependencies, ensuring that all logical conditions are accurately captured. • Processing of Each Predicate: Each predicate in sePtis transformed into its corresponding PDDL format. This involves defining the predicate’s parameters and logical statements as required by PDDL. The predicates are then added to the domaindfilfe),(providing a foundation for specifying preconditions and efects of actions in the planning domain. 4. Extraction and Processing of Actions Next, the algorithm processes the actions defined in the SysML model, which represent the operations that can be performed within the planning domain. • Extraction of Actions: The algorithm extracts all elements inSytshMeL model annotated with the «PDDL_Action» stereotype. These elements define the various actions available in the domain, including their parameters, preconditions, and efects. These actions are collected into a setA. The SysML profile’s customization elements, such as derived properties and possible owners, are leveraged to ensure that the extracted actions are contextually appropriate and syntactically valid. • Processing of Each Action: Each action in seAt is converted intPoDDL syntax, specifying its preconditions and efects in terms of the predicates defined earlier. This step ensures that the actions are fully compatible withPDthDeL requirements and that they reflect the intended operations and workflows defined in theSysML model. The processed actions are then added to the domain file (df ), finalizing the dynamic aspects of the planning domain. 5. Finalization and Output of the PDDL Domain File Once all types, predicates, and actions have been added to thPeDDL domain file ( df ), the algorithm completes the generation of a wellstructurePdDDL domain file. This file accurately represents the components and relationships defined in the enrichedSysML model. With the domain file fully constructed, it is now ready for deployment in automated planning systems to generate and analyze production sequences for specific system configurations. The use of theSysML profile for PDDL simplifies the conversion of system models into planning-ready formats, enhancing the eficiency and efectiveness of production system engineering.
The VTL was selected to implement the algorithm for automPDatDeLddescription generation primarily due to its integration wMitBhSE tools like Magic Systems of Systems ArchiteMcSto(SA). The Velocity Engine, which utilizeVs TL, is embedded in these tools, enabling eficient and seamless automation within existing modeling environments. WhViTleL is well-suited for this task, the approach is flexible and could be implemented using other templating languages or scripting methods, depending on the specific requirements and tools available.
VTL is a templating language that facilitates dynamic text generation, making it particularly useful for convertinSgysML-based system models intPoDDL domain files. Its straightforward syntax and powerful constructs, such as loops, conditionals, and macros, are ideal for generating structured documents like PDDL files.
Listing2 shows a core component of thVeTL script, focusing on the automated generation of actions in thPeDDL domain file. 2 The script iterates over the actions defined inStyshMeL model and dynamically generates thPeDirDL representations, including parameters, preconditions, and efects. Each element is checked for completeness and validity to ensure that the gePnDeDrLa tfiledis both syntactically correct and semantically meaningful.
Listing 2:Snippet of the VTL Template for defining PDDL actions 2The complete template is available on GitHhutbt:ps://github.com/hsu-aut/VTL-PDDL_Doma.in Action Iteration and Name Assignment: The script begins by iterating over each action element within the$pddlDomainElement. For each action, the script assigns the action’s name to the variable $actionName.
Parameter Generation: Parameters for each action are generated by iterating opvaerratmheteers attribute of the action element. The script checks whether each parameter and its type are defined. If any are missing, an error message is generated. This process ensures that every action has a complete and valid parameter list, which is essential for the correct functioning of the planning domain. Precondition Generation: The script constructs the preconditions for each action by iterating over theprecondition attribute. It dynamically builds the logical expressions requPiDreDdLb,yhandling both normal and negated predicates. If multiple preconditions are defined, they are grouped using the operatorand. This part of the script is crucial for defining the conditions under which each action can be executed, ensuring that all necessary logical constraints are accurately represented. Efect Generation: Similarly, the script handles the efects of each action. It iterates oevfefrectthe attribute and constructs the correspoPnDdDinLgexpressions. The script also accounts for negated efects where necessary. Correctly handling action efects is vital for defining the outcome of executing each action in the planning domain, ensuring that the resulting state changes are accurately modeled. Error Handling: Throughout the code, various checks are included to ensure the integrity of the generatedPDDL file. If any action is missing critical information, such as a name, parameters, preconditions, or efects, the script generates an error message. This robust error-checking mechanism helps prevent incomplete or invaPliDdDL files from being produced, thereby enhancing the reliability and correctness of the automated planning process.
To evaluate the proposed algorithm, an aircraft manufacturing use case was selected. Initially, holes are drilled from the outside of the fuselage, after which fasteners are installed. Inside the fuselage, collars are then screwed onto these fasteners. This process, which is repetitive and ergonomically challenging, is typically performed by a robotic system.
The robotic system utilized for the tasks inside the fuselage comprises a UR10 manipulator equipped with various end-efectors, each capable of screwing diferent types of collars onto the rivets. Identifying an optimal plan for this task poses a significant challenge. The robotic system must follow the shortest possible path while minimizing the number of end-efector reconfigurations needed during the assembly process.
For the development of this robotic system, a detailed system model was creatSeydsuMsLinign the software MSoSA. A comprehensive description of the use case and the system model is present9e]d. in [ This system model was subsequently extended using PtDheDL profile. The PDDL profile facilitates the annotation SoyfsML elements that contain relevant information necessary for constructing the corresponding PDDL file.
Figure 2shows an excerpt from the activity diagram of the enriched system model, showcasing the integration between the system’s modeled behavior anPdDtDhLe profile. It includes three «PDDL_Action» elements, each accompanied by its respective preconditions and efects. The «PDDL_Action» elements ”ScrewCollarTypeA” and ”ScrewCollarTypeB” describe the process steps for screwing diferent types of collars. After completing these steps, the system proceeds to the next rivet through the «PDDL_Action» ”MoveToNextRivet”. This sequence is repeated cyclically throughout the assembly process.
«PDDL_Action» ScrewCollarType A : Screw Collar
Type A «PDDL_Action» ScrewCollarType B : Screw Collar
Type B {Predicatename = "EnergySupply"} {Functionname = "RivetDistanceInformation",
Functionpart = ?From - Rivet, ?To - Rivet} «PDDL_Action» MoveToNextRivet : Move System {Predicatename = "MoveToNextRivet",
Predicatepart = ?To - Rivet} {Predicatename = "CollarScrewed",
Predicatepart = ?From - Rivet}
To execute the action ”MoveToNextRivet,” which moves the end-efector from one rivet to the next, the following preconditions must be satisfied: 1. The system must be powered, which is ensured by the predicate ”EnergySupply” included in the action. 2. The collar at the current end-efector position must already be screwed. This is managed by the actions ”ScrewCollarTypeA” and ”ScrewCollarTypeB,” which set the predicate ”CollarScrewed” to ”True” once their respective actions are completed. 3. The coordinates of the rivets and the distances between them are definedFuinncttihoen ”RivetDistanceInformation” and are used in the ”MoveToNextRivet” actPiDonD.LAsolver can utilize these distances and rivet types to determine the optimal sequence for processing rivets.
Once the action is executed, its efect is that the end-efector is positioned at a new working location. The corresponding predicate ”MovedToNextRivet” is set to ”True” with the new rivet position.
The automated generation of tPhDeDL domain files using theVTL template allows for eficient and accurate conversion of the system model into planning descriLpitsitoinsg. 3presents thePDDL action ”MoveToNextRivet,” which has been automatically generated usVinTgLttheemplate foPrDDL domain file generation. This example illustrates how the algorithm captures the necessary parameters, preconditions, and efects directly from the enriched SysML model.
The generatedPDDL domain files, produced through the automated process usingVtThLe template, were subsequently provided toPDaDL solver for creating the sequence of process steps. By maintaining a strict linkage between PthDeDL descriptions and thSeysML system model, this approach allows for a
Listing 3:PDDL action definition for ”MoveToNextRivet” with preconditions and efects (MovedToNextRivet ?To ) (not (CollarScrewed ?From )) (increase (total-cost) (RivetDistanceInformation ?From ?To)) seamless exploration of diferent system configurations and their behaviors. This integration facilitates more eficient planning and decision-making, enabling engineers to quickly assess the impact of various configurations and optimize the production process accordingly. The close alignment between the model and the planning descriptions ensures consistency and accuracy, making it easier to adapt and refine strategies based on specific requirements and constraints.
This paper presented an automated approach for generPaDtiDnLg domain files directly fromSysMLbased system models, leveraging tShyesML profile for PDDL. The automation is achieved through a newly developed algorithm, which systematically extracPtDsDtLhaennotated elements from the enriched system models, thereby reducing the manual efort typically required for creating such files. The integration of this automation MinBtSoE tools likMeSoSA, utilizing thVeTL, demonstrates the feasibility of embedding the approach into existing engineering workflows.
The application of this method to an aircraft assembly use case highlights the potential of automating process planning in complex production environments. By maintaining a strict linkage between the system model and the generatPeDdDL domain, engineers can easily explore and evaluate diferent system configurations. This capability improves the overall eficiency of the system design and decisionmaking processes, enabling faster and more accurate planning.
However, one notable drawback is the initial complexity of setting up the system model. While the proposed approach reduces manual work in the long term, it requires a significant amount of efort to initially extend tShyesML models with thePDDL profile. Engineers must ensure that the system model is correctly annotated and that all relevant elements are configured properly for automation. This setup process can be time-consuming and presents a steep learning curve for teams unfamiliSayrsMwLith or PDDL, potentially delaying the benefits of automation in the early stages of implementation.
To address this drawback, the standardization of system models could play a crucial role in reducing the complexity of the annotation process. By adhering to well-defined modeling standards and conventions, it becomes easier to identify the relevant elemSeynstMs Linmodels and applyPDDL annotations systematically. Standardized system models would ensure consistency across diferent projects, enabling automated tools to more easily detect, annotate, and extract relevant information. In turn, this would reduce the manual efort required during the initial setup and streamline the overall process.
Additionally, the challenge of annotation complexity could be further addressed by developing an intelligent assistance tool to support engineers during the modeling process. Such a tool would provide suggestions for annotations based on the user’s modeling intent, leveraging the context of the current model elements and their relations. By incorporating advanced techniques, potentially including large language models (LLMs), the tool could predict suiPtDabDlLe annotations dynamically, streamlining the setup process even further. This interactive assistance would not only minimize manual annotation eforts and reduce errors but also enhance accessibility for teams with varying levels of familiarity with SysML and PDDL.
Future work will focus on extending the current approach by automating the genePrDaDtiLon of problem files from product models. This step is essential for fully automating the planning process, as the problem file defines the initial state and goals of the planning task. Additionally, the method will be applied to even more complex production systems, involving multiple process steps and a wider variety of technical components, to further evaluate its scalability and robustness in diferent industrial contexts.
Furthermore, the developed algorithm is designed to be broadly applicable and can be implemented in other environments, such as the Unified Planning Framework (3U.PBFy) leveraging the UPF, the approach could ofer direct access to variPoDusDL solvers, streamlining the process of selecting and using the most appropriate solver for each use case. This flexibility will enhance the adaptability of the algorithm across diferent tools and platforms, making it more accessible for diverse planning challenges in industry.
This research paper [project iMOD and LaiLa] is funded by dtec.bw – Digitalization and Technology Research Center of the Bundeswehr. dtec.bw is funded by the European Union – NextGenerationEU.