Pith. sign in

REVIEW 3 major objections 4 minor 40 references

Integrating AI Planning Semantics into SysML System Models for Automated PDDL File Generation

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Pith's one-line read A SysML profile embeds PDDL planning semantics into system models and automatically generates solver-ready PDDL files.

desk verdict A concrete SysML profile for PDDL generation with a working case study, but the paper under-documents how predicate/function declarations are produced and over-claims OCL coverage. read the letter →

arxiv 2506.06714 v1 pith:OYIZSO3I submitted 2025-06-07 cs.AI

classification cs.AI
keywords Model-BasedSystemsEngineeringSysMLPDDLAIplanningprofileOCLconstraintsfilegenerationautomated
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that a SysML profile can embed PDDL planning semantics directly into system models, so that an engineer can annotate existing model elements with stereotypes and automatically obtain PDDL domain files (and, with product data, problem files) that a planner can solve. The profile maps domains, types, predicates, functions, and actions to stereotypes on standard SysML elements, and OCL constraints catch syntactic errors at modeling time. The paper demonstrates the pipeline on an aircraft-manufacturing case study where a robot with interchangeable end effectors is planned to minimize cycle time. If the approach holds, it gives systems engineers a model-based route from architecture to symbolic planning without hand-writing error-prone PDDL.

What carries the argument

The central object is a SysML profile: a set of stereotypes, tagged values, derived properties, and OCL constraints that extends SysML to PDDL. It is derived manually from the BNF grammar of PDDL 3.1, because direct grammar-to-metamodel translation is unreliable. The profile carries the argument by making PDDL constructs first-class annotations on standard SysML elements, so the transformation algorithm can query stereotype attributes and output the corresponding PDDL text.

What would settle it

Take a set of annotated SysML models with known intended planning semantics, generate PDDL domains, and parse them with a standards-compliant PDDL parser while comparing each generated action's preconditions and effects against a reference domain written by a PDDL expert; any mismatch in predicates, parameters, or numeric effects would refute the claim that the profile preserves PDDL semantics for the covered subset.

Watch

Extended reading notes

Core claim

The central claim is that PDDL 3.1 planning constructs can be represented as reusable SysML stereotypes without distorting either language: <<PDDL_Domain>> on a model or package, <<PDDL_Type>> on a class, <<PDDL_Predicate>> and <<PDDL_Function>> on object or control flows, and <<PDDL_Action>> on a call behavior action. Preconditions and effects are encoded through derived properties on incoming and outgoing flows, and OCL invariants such as unique type names enforce syntactic consistency. Together with a previously reported transformation algorithm, an annotated model yields syntactically valid PDDL domain descriptions; the case study shows a generated MoveToNextRivet action with parameters, preconditions, and a numeric cost effect being solved by a PDDL solver.

Load-bearing premise

The approach depends on the assumption that labeling SysML elements with these stereotypes faithfully captures what the corresponding PDDL constructs mean, so the automatically generated domain is truly the planning problem the engineer intended for the simple PDDL constructs covered.

Editorial extensions

If this is right

  • An engineer can compare system configurations (for example, two robot arms) by extending the model with the new component and reusing the same planning annotations, without rewriting the domain.
  • Syntactic errors such as duplicate type names are detected in the modeling tool before any PDDL text is produced, shifting error detection earlier in the workflow.
  • The profile is domain-independent, so the same stereotypes can generate planning domains for other manufacturing or service scenarios modeled in SysML.
  • Generated domain files stay consistent with the system architecture, since both derive from the same annotated model.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The demonstrated subset covers simple actions with predicates and numeric cost effects; whether the flow-based mapping extends to quantified preconditions, conditional effects, and durative actions is left open.
  • Because preconditions and effects live on flows rather than on a dedicated predicate element, the same logical fact could be annotated differently in different diagrams, so cross-view consistency checking would likely be needed for large collaborative models.
  • The manual assignment of product data to planning constructs is where the pipeline still depends on human judgement; a direct mapping from product-structure data to predicate instances would make the workflow end-to-end automatic.
  • The paper's own limitation statement implies that annotation effort may dominate practical adoption; a user study comparing modeling time and error rates with and without the profile would test that concern.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper proposes a SysML profile that annotates system models with PDDL planning constructs (domains, types, predicates, functions, actions) via stereotypes, together with OCL constraints intended to ensure syntactic consistency. The profile is said to be derived from the PDDL 3.1 BNF. A case study in aircraft manufacturing applies the profile to a robot collar-screwing system, enriches a SysML model with planning annotations, and uses an algorithm from the authors' prior work to generate PDDL domain and problem files, which are then solved by the Delfi planner. The central claim is that the profile provides a reusable, tool-supported bridge between MBSE system models and AI planning, enabling automated generation of planning descriptions.

Significance. If fully substantiated, the approach would be a useful contribution to MBSE-based AI planning, addressing the acknowledged difficulty of manually writing and maintaining PDDL files. The paper has several notable strengths: the profile is anchored to an external standard (PDDL 3.1 BNF), the generated PDDL is validated by an external solver (Delfi), and the stereotypes are mapped to standard SysML metaclasses so that the approach is not tied to a single case study. The case study is concrete and demonstrates at least one end-to-end instance of the claimed workflow. However, the manuscript leaves open essential details about how the profile represents complete PDDL domain structure, in particular the declaration sections for predicates and functions, and it does not include the complete profile or constraint set. These omissions directly affect reproducibility and the strength of the 'syntactic consistency' claim, so the contribution is promising but not yet fully supported as presented.

major comments (3)
  1. [Section IV, Table I; Section V, Listing 5] The profile mapping in Table I assigns <<PDDL_Predicate>> only to ObjectFlow and ControlFlow, and <<PDDL_Function>> only to ObjectFlow and ControlFlow. These metaclasses capture occurrences of predicates and numeric expressions inside action preconditions and effects (e.g., Figure 3), not the mandatory PDDL domain declarations of the form (:predicates (CollarScrewed ?r - Rivet)) and (:functions (RivetDistanceInformation ?from - Rivet ?to - Rivet) - number). Neither Table I nor the OCL constraints in Listings 3 and 4 provide a stereotype or metaclass extension for these declaration sections, and the transformation description in Section V does not explain how the algorithm obtains the declarations. If the declarations are reconstructed from the string-valued tagged values Predicatename and Predicatepart shown in Figure 3, that is an important convention that should be stated explicitly, along with its limitations for type and arity checking. If they come from additional profile elements, those elements are missing from Table I. As written, a model built exactly to the paper's specification would be expected to yield a PDDL domain without the required :predicates and :functions blocks, and the reported solver success cannot be assessed because Listing 5 shows only one action, not the full generated domain. This gap is load-bearing for the central claim of automated PDDL generation.
  2. [Section IV, Listings 3-4; Abstract] The abstract states that 'formal OCL constraints ensure syntactic consistency,' but the paper presents only two OCL constraints (domain-name validation and unique type names) and does not specify the remaining constraint set. The text mentions 'further OCL constraints' for action completeness and predicate consistency, but these are not listed, and no complete profile specification is included in the manuscript. The GitHub link is not a substitute for a versioned, reviewed artifact, and the paper gives no commit identifier or access date. To make the syntactic-consistency claim verifiable, the authors should provide the full constraint list (or an appendix with the complete profile) and state precisely which syntactic properties of the generated PDDL are enforced by the profile versus by the transformation templates.
  3. [Section V, paragraph beginning 'To enable automated generation'] The transformation algorithm is cited as prior work [31], but the present manuscript does not summarize its core steps beyond saying that VTL templates extract and format model content. Since the paper's central claim depends on the correctness of this transformation, the reader needs at least a high-level description of how the annotated model elements are queried and assembled into a syntactically complete PDDL domain. In particular, it is not clear from the current text whether the algorithm performs a structural traversal of the SysML model or relies on textual parsing of tagged values. Adding a short description of the transformation pipeline, or pseudocode, would materially improve reproducibility.
minor comments (4)
  1. [Section IV, final paragraph; Section V] The text says that 'Both files are generated automatically using template logic,' but Section V states that the assignment of product data to the planning constructs was carried out manually. Please clarify the exact boundary between automatic generation and manual association, since this affects the strength of the 'automated generation' claim.
  2. [Figure 3] Figure 3 is a low-resolution tool screenshot with small text and visible watermarks, which makes the stereotype annotations and tagged values difficult to read. A vector-based redrawing or a higher-resolution figure with enlarged annotations would improve the paper.
  3. [Section V, last paragraph before Conclusion] The manuscript does not discuss whether the plan produced by Delfi was validated beyond solver acceptance, for example by simulation or expert review. Solver acceptance demonstrates that the PDDL is syntactically and semantically accepted by the planner, but not that the plan is physically executable in the modeled system. A sentence on this distinction would be helpful.
  4. [References [28] and [31]] Because the paper relies heavily on prior work [28] and [31] for the workflow and the transformation algorithm, a brief summary of each is necessary for self-containedness. Currently, readers of this paper alone cannot fully evaluate the reproducibility of the case study.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the profile is grounded in the external PDDL 3.1 grammar, and the case study is validated by an external solver; cited prior-work algorithms are independent tooling, not fitted inputs.

full rationale

The paper contains no circular derivation. The SysML profile is presented as a modeling artifact, not as a prediction that must be tested against fitted data. The mapping in Table I is explicitly grounded in the external PDDL 3.1 specification [29], and the paper states that the BNF was used as a reference while the profile was developed manually to fit SysML modeling practice. The generated PDDL files are checked by an outside planner, Delfi [36], which produced a valid optimized plan in the case study; this gives independent evidence that the transformation chain works. The transformation algorithm and overall workflow are taken from the authors' prior work [28,31], which is self-citation, but it is not load-bearing in a circular sense: the algorithm is a separate, previously published component whose output is externally validated by the solver rather than being defined to equal the profile's inputs. No parameters are fitted to the output, and no claim is justified solely by appealing to a cited uniqueness or impossibility theorem. The reviewer-identified gap that predicates and functions are mapped to flow metaclasses and that their names and parameter parts are stored as string-valued tagged values is a modeling-fidelity and completeness concern, potentially affecting the syntactic completeness of generated domain files, but it is not circularity: the transformation still adds the PDDL template syntax and the generated output is checked by an external solver. The stated limitation that manual annotation remains time-consuming is an engineering cost, not a circular dependency. Therefore the derivation chain is self-contained against external standards and tools, and the circularity score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 5 invented entities

The profile introduces new modeling constructs (stereotypes) but no physical entities. These stereotypes are the paper's core contribution and are validated only through the single case study presented. The axioms listed are the unproved background assumptions the central claim rests on.

assumptions (4)
  • domain assumption PDDL 3.1 BNF defines the correct target syntax for planning domains.
    The paper bases the profile on the BNF from [29]; the correctness of the generated PDDL depends on this standard being the right one.
  • domain assumption SysML profile mechanism can faithfully represent PDDL constructs.
    The paper assumes that stereotypes over UML metaclasses are sufficient to capture PDDL semantics; direct transformation from BNF is noted as non-trivial, so the profile was developed manually.
  • domain assumption The transformation algorithm from [31] correctly extracts annotations into PDDL.
    The paper relies on the algorithm in [31] without reproducing it; this is an unverified dependency.
  • domain assumption The case study model and tools are representative and behave as described.
    A single case study without quantitative evaluation or generalization analysis supports the claimed generality.
invented entities (5)
  • PDDL_Domain stereotype
    purpose: Marks a Model or Package as the container for a PDDL planning domain.
    Introduced by the paper; no external evidence beyond the case study.
  • PDDL_Type stereotype
    purpose: Marks a Class as a PDDL object type with possible inheritance.
    Introduced by the paper; no external evidence beyond the case study.
  • PDDL_Predicate stereotype
    purpose: Marks an ObjectFlow or ControlFlow as a logical predicate in PDDL.
    Introduced by the paper; no external evidence beyond the case study.
  • PDDL_Function stereotype
    purpose: Marks an ObjectFlow or ControlFlow as a numeric function in PDDL.
    Introduced by the paper; no external evidence beyond the case study.
  • PDDL_Action stereotype
    purpose: Marks a CallBehaviorAction as a PDDL action with preconditions and effects.
    Introduced by the paper; no external evidence beyond the case study.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Integrating AI Planning Semantics into SysML System Models for Automated PDDL File Generation." pith.science (2026). https://pith.science/paper/OYIZSO3I

@misc{pith2026250606714,
  author       = {Pith},
  title        = {Pith review of: Integrating AI Planning Semantics into SysML System Models for Automated PDDL File Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OYIZSO3I}},
  note         = {Machine review of arXiv:2506.06714}
}
read the original abstract

This paper presents a SysML profile that enables the direct integration of planning semantics based on the Planning Domain Definition Language (PDDL) into system models. Reusable stereotypes are defined for key PDDL concepts such as types, predicates, functions and actions, while formal OCL constraints ensure syntactic consistency. The profile was derived from the Backus-Naur Form (BNF) definition of PDDL 3.1 to align with SysML modeling practices. A case study from aircraft manufacturing demonstrates the application of the profile: a robotic system with interchangeable end effectors is modeled and enriched to generate both domain and problem descriptions in PDDL format. These are used as input to a PDDL solver to derive optimized execution plans. The approach supports automated and model-based generation of planning descriptions and provides a reusable bridge between system modeling and AI planning in engineering design.

Figures

Figures reproduced from arXiv: 2506.06714 by the authors.

Figure 1
Figure 1. Workflow model for automated generation of PDDL descriptions (adapted from [28]) [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. The approach for creating the corresponding system [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Excerpt from the enriched system model of the [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

40 extracted references · 40 canonical work pages

  1. [31]

    Automated PDDL Domain File Generation for Enhancing Production System Development based on SysML Models,

    H. Nabizada, T. Jeleniewski, L. Beers, F. Gehlhoff, and A. Fay, “Automated PDDL Domain File Generation for Enhancing Production System Development based on SysML Models,” in Proceedings of the AI4CC-IPS-RCRA-SPIRIT 2024 , November 2024

  2. [1]

    Value and benefits of model– based systems engineering (MBSE): Evidence from the litera- ture,

    K. Henderson and A. Salado, “Value and benefits of model– based systems engineering (MBSE): Evidence from the litera- ture,” Systems Engineering, vol. 24, no. 1, pp. 51–66, 2021

  3. [2]

    Model-Based Systems Engineer- ing (MBSE) as computer-supported approach for cooperative systems development,

    M. M. Schmidt and R. Stark, “Model-Based Systems Engineer- ing (MBSE) as computer-supported approach for cooperative systems development,” in Proceedings of 18th European Con- ference on Computer-Supported Cooperative Work , 2020

  4. [3]

    Weilkiens, SYSMOD - The Systems Modeling Toolbox: Prag- matic MBSE with SysML, 3rd ed

    T. Weilkiens, SYSMOD - The Systems Modeling Toolbox: Prag- matic MBSE with SysML, 3rd ed. Fredesdorf: MBSE4U, 2020

  5. [4]

    K. Pohl, H. H ¨onninger, R. Achatz, and M. Broy, Eds., Model- Based Engineering of Embedded Systems: The SPES 2020 Methodology. Berlin, Heidelberg: Springer, 2012

  6. [5]

    Survey of Model-based Systems Engineering (MBSE) Methodologies,

    J. A. Estefan, “Survey of Model-based Systems Engineering (MBSE) Methodologies,” Incose MBSE Focus Group , vol. 25, no. 8, 2007

  7. [6]

    Experimentable digital twins for a modeling and simulation-based engineering approach,

    U. Dahmen and J. Rossmann, “Experimentable digital twins for a modeling and simulation-based engineering approach,” in 2018 IEEE International Systems Engineering Symposium (ISSE), 2018

  8. [7]

    An approach for system analysis with model-based systems engineering and graph data engineer- ing,

    S. Schummer and P. Hyba, “An approach for system analysis with model-based systems engineering and graph data engineer- ing,” Data-Centric Engineering, vol. 3, 2022

Show all 40 references
  1. [8]

    Inte- grating Multi-Disciplinary Optimization into the Product De- velopment Process using Model-Based Systems Engineering (MBSE),

    M. T ¨orm¨anen, A. H ¨agglund, T. Rocha, and E. Drenth, “Inte- grating Multi-Disciplinary Optimization into the Product De- velopment Process using Model-Based Systems Engineering (MBSE),” in NAFEMS World Congress, 2017

  2. [9]

    Ghallab, D

    M. Ghallab, D. Nau, and P. Traverso, Automated Planning and Acting. Cambridge: Cambridge University Press, 2016

  3. [10]

    Evaluating PDDL for programming production cells: a case study,

    C. Mayr-Dorn, A. Egyed, M. Winterer, C. Salomon, and H. F ¨urschuß, “Evaluating PDDL for programming production cells: a case study,” in IEEE/ACM 4th International Workshop on Robotics Software Engineering (RoSE) , 2022

  4. [11]

    On Using Action Inheritance and Modularity in PDDL Domain Modelling,

    A. Lindsay, “On Using Action Inheritance and Modularity in PDDL Domain Modelling,” Proceedings of the International Conference on Automated Planning and Scheduling , vol. 33, no. 1, 2023

  5. [12]

    Detecting AI Planning Modelling Mistakes – Potential Errors and Benchmark Domains,

    K. Sleath and P. Bercher, “Detecting AI Planning Modelling Mistakes – Potential Errors and Benchmark Domains,” in PRI- CAI 2023: Trends in Artificial Intelligence , ser. Lecture Notes in Computer Science, F. Liu, L. Shen, H. C. Lau, P. Lukowicz, F. Chen, H. Yan, and B. An, Eds...

  6. [13]

    MyPDDL: Tools for Efficiently Creating PDDL Domains and Problems,

    V . Strobel and A. Kirsch, “MyPDDL: Tools for Efficiently Creating PDDL Domains and Problems,” in Knowledge En- gineering Tools and Techniques for AI Planning , M. Vallati and D. Kitchin, Eds. Cham: Springer International Publishing, 2020

  7. [14]

    A Research Agenda for AI Planning in the Field of Flexible Production Systems,

    A. K ¨ocher, R. Heesch, N. Widulle, A. Nordhausen, J. Putzke, A. Windmann, and O. Niggemann, “A Research Agenda for AI Planning in the Field of Flexible Production Systems,” in 2022 IEEE 5th International Conference on Industrial Cyber- Physical Systems (ICPS) , 2022

  8. [15]

    Unified Modeling Language (UML), Version 2.5.1 ,

    Object Management Group, “ Unified Modeling Language (UML), Version 2.5.1 ,” 2017. [Online]. Available: https: //www.omg.org/spec/UML/

  9. [16]

    Anal- ysis beyond UML,

    C. Stutz, J. Siedersleben, D. Kretschmer, and W. Krug, “Anal- ysis beyond UML,” in Proceedings of the 10th IEEE Interna- tional Requirements Engineering Conference (RE 2002) , 2002

  10. [17]

    Weilkiens, Systems engineering with SysML/UML: Modeling, analysis, design

    T. Weilkiens, Systems engineering with SysML/UML: Modeling, analysis, design . Amsterdam and Boston: Morgan Kaufman- n/Elsevier, 2008

  11. [18]

    Systems Modeling Language (SysML), Version 1.6 ,

    Object Management Group, “ Systems Modeling Language (SysML), Version 1.6 ,” 2019. [Online]. Available: https: //www.omg.org/spec/SysML/1.6/

  12. [19]

    Systematic Literature Review of MBSE Tool-Chains,

    J. Ma, G. Wang, J. Lu, H. Vangheluwe, D. Kiritsis, and Y . Yan, “Systematic Literature Review of MBSE Tool-Chains,” Applied Sciences, vol. 12, no. 7, 2022

  13. [20]

    Friedenthal, A

    S. Friedenthal, A. Moore, and R. Steiner, A Practical Guide to SysML: The Systems Modeling Language , third edition ed. Waltham, USA: Morgan Kaufmann, 2014

  14. [21]

    Seidl, M

    M. Seidl, M. Scholz, C. Huemer, and G. Kappel, UML @ Class- room: An Introduction to Object-Oriented Modeling . Cham: Springer, 2015

  15. [22]

    Haslum, N

    P. Haslum, N. Lipovetzky, D. Magazzeni, and C. Muise, An Introduction to the Planning Domain Definition Language . Cham: Springer International Publishing, 2019

  16. [23]

    Planning with a task modeling framework in manufacturing robotics,

    J. Huckaby, S. Vassos, and H. I. Christensen, “Planning with a task modeling framework in manufacturing robotics,” in 2013 IEEE/RSJ International Conference on Intelligent Robots and Systems, 2013

  17. [24]

    Transformation eines F ¨ahigkeitsmodells in einen PDDL- Planungsansatz,

    L. M. Vieira da Silva, R. Heesch, A. K ¨ocher, and A. Fay, “Transformation eines F ¨ahigkeitsmodells in einen PDDL- Planungsansatz,” at-Automatisierungstechnik, vol. 71, no. 2, 2023

  18. [25]

    Application of MBSE to model Hierarchical AI Planning problems in HDDL,

    J. Rimani, C. Lesire, S. Lizy-Destrez, and N. Viola, “Application of MBSE to model Hierarchical AI Planning problems in HDDL,” in International Conference on Automated Planning and Scheduling (ICAPS) , 2021

  19. [26]

    System modeling in SysML and system analysis in Arena,

    O. Batarseh and L. F. McGinnis, “System modeling in SysML and system analysis in Arena,” in Proceedings of the Winter Simulation Conference (WSC) , 2012

  20. [27]

    Flexible production systems: Automated generation of operations plans based on ISA-95 and PDDL,

    B. Wally, J. Vysko ˇcil, P. Nov ´ak, C. Huemer, R. ˇSindel´ar, P. Kadera, A. Mazak, and M. Wimmer, “Flexible production systems: Automated generation of operations plans based on ISA-95 and PDDL,” IEEE Robotics and Automation Letters , vol. 4, no. 4, 2019

  21. [28]

    Model- Based Workflow for the Automated Generation of PDDL Descriptions,

    H. Nabizada, T. Jeleniewski, F. Gehlhoff, and A. Fay, “Model- Based Workflow for the Automated Generation of PDDL Descriptions,” in Proceedings of the 29th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), 2024

  22. [29]

    Complete BNF description of PDDL 3.1,

    D. L. Kovacs, “Complete BNF description of PDDL 3.1,” Language Specification, Department of Measurement and In- formation Systems, Budapest University of Technology and Economics, 2011

  23. [30]

    Generating Metamodels from Grammars by Chaining Translational and By-Example Tech- niques,

    A. Bergmayr and M. Wimmer, “Generating Metamodels from Grammars by Chaining Translational and By-Example Tech- niques,” in MDEBE@ MoDELS, 2013

  24. [32]

    A SysML Profile for the Standardized Description of Processes during System Development,

    L. Beers, H. Nabizada, M. Weigand, F. Gehlhoff, and A. Fay, “A SysML Profile for the Standardized Description of Processes during System Development,” in 2024 IEEE International Sys- tems Conference (SysCon) , 2024

  25. [33]

    Exploring knowledge engineering strategies in designing and modelling a road traffic accident management domain,

    M. Shah, L. Chrpa, D. Kitchin, T. McCluskey, and M. Vallati, “Exploring knowledge engineering strategies in designing and modelling a road traffic accident management domain,” in 2013 Proceedings of the 23rd International Joint Conference on Artificial Intelligence (IJCAI) , 2013

  26. [34]

    Challenges in Automated Commercial Aircraft Production,

    F. Gehlhoff, H. Nabizada, M. Weigand, L. Beers, O. Ismail, A. Wenzel, A. Fay, P. Nyhuis, W. Lagutin, and M. R ¨ohrig, “Challenges in Automated Commercial Aircraft Production,” in IFAC PapersOnLine, vol. 55, no. 2, 2022

  27. [35]

    MBSE Modeling Workflow for the Development of Automated Air- craft Production Systems,

    L. Beers, M. Weigand, H. Nabizada, and A. Fay, “MBSE Modeling Workflow for the Development of Automated Air- craft Production Systems,” in 28th International Conference on Emerging Technologies and Factory Automation (ETFA), 2023

  28. [36]

    Delfi: Online Planner Selection for Cost-Optimal Planning,

    M. Katz, S. Sohrabi, H. Samulowitz, and S. Sievers, “Delfi: Online Planner Selection for Cost-Optimal Planning,” in Ninth International Planning Competition , 2018

  29. [37]

    PLANU- TILS: Bringing Planning to the Masses,

    C. Muise, F. Pommerening, J. Seipp, and M. Katz, “PLANU- TILS: Bringing Planning to the Masses,” in 32nd International Conference on Automated Planning and Scheduling (ICAPS).KA System Demonstrations, 2022

  30. [38]

    Creating Virtual Knowledge Graphs from Software-Internal Data,

    M. Weigand and A. Fay, “Creating Virtual Knowledge Graphs from Software-Internal Data,” in 48th Annual Conference of the IEEE Industrial Electronics Society , 2022

  31. [39]

    Unified Planning: Modeling, manipu- lating and solving AI planning problems in Python,

    A. Micheli, A. Bit-Monnot, G. R ¨oger, E. Scala, A. Valentini, L. Framba, A. Rovetta, A. Trapasso, L. Bonassi, A. E. Gerevini, L. Iocchi, F. Ingrand, U. K ¨ockemann, F. Patrizi, A. Saetti, I. Serina, and S. Stock, “Unified Planning: Modeling, manipu- lating and solving AI plan...

  32. [40]

    Systems Modeling Language (SysML), Version 2.0 beta 2 ,

    Object Management Group, “ Systems Modeling Language (SysML), Version 2.0 beta 2 ,” 2024. [Online]. Available: https://www.omg.org/spec/SysML/2.0/Beta2/

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.