pith. sign in

arxiv: 2606.03691 · v1 · pith:OAU6PITAnew · submitted 2026-06-02 · 💻 cs.SE · cs.DB

An AutomationML Domain Library for the Formalized Process Description

Hamied Nabizada , Rainer Drath , Felix Gehlhoff , Alexander Fay This is my paper

Pith reviewed 2026-06-28 08:48 UTC · model grok-4.3

classification 💻 cs.SE cs.DB
keywords AutomationMLFormalized Process DescriptionFPDCAEX 3.0domain libraryprocess modelingmodel exchangeVDI/VDE 3682
0
0 comments X

The pith

A five-part AutomationML library encodes the full Formalized Process Description using CAEX 3.0 class libraries for machine-readable exchange.

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

This paper develops an AutomationML domain library to supply the Formalized Process Description with a standardized, tool-independent data format based on the CAEX 3.0 metamodel. The library consists of five parts that together capture semantic roles, connection types, attribute models, diagram interchange details, and instantiation templates. It solves the absence of a machine-readable representation for FPD graphical models used across engineering domains. A bidirectional mapping tool shows that models can move between a web FPD editor and AML files while preserving structure and graphics. The library is offered for community input as a candidate for Part 3 of the VDI/VDE 3682 standard.

Core claim

The AutomationML domain library formalizes the complete set of FPD language elements, their attributes, connection semantics, and graphical representation information as class libraries based on the CAEX 3.0 metamodel. It comprises a RoleClassLib defining semantic roles, an InterfaceClassLib for connection types, two AttributeTypeLibs for the information model and diagram interchange, and a SystemUnitClassLib providing instantiation templates. Design decisions on inheritance, diagram structure, hierarchical decomposition, and graphical information are presented along with considered alternatives.

What carries the argument

Five interrelated CAEX class libraries that map every FPD element, connection rule, attribute, and graphical feature into the metamodel without external extensions.

If this is right

  • Enables bidirectional conversion between web-based FPD modelers and AML files while retaining all model information.
  • Supplies reusable templates for instantiating FPD elements inside larger system models.
  • Supports standardized exchange of process descriptions across different engineering tools and domains.
  • Provides a concrete basis for community review and potential adoption as Part 3 of VDI/VDE 3682.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same mapping technique could be applied to other graphical process notations to achieve similar interoperability with AML.
  • Automated validation tools could use the library to detect inconsistencies between FPD diagrams and other CAEX-based engineering data.
  • Industry adoption might allow direct import of FPD models into simulation or control systems that already read AML files.

Load-bearing premise

The complete semantics, connection rules, and graphical attributes of FPD can be losslessly represented inside the CAEX 3.0 metamodel without requiring extensions or custom interpretations outside the five class libraries.

What would settle it

Convert a complete FPD diagram containing every language element and graphical feature to AML via the library, then convert it back, and check whether every semantic, connection, attribute, and graphical detail is restored without loss or alteration.

Figures

Figures reproduced from arXiv: 2606.03691 by Alexander Fay, Felix Gehlhoff, Hamied Nabizada, Rainer Drath.

Figure 2
Figure 2. Figure 2: VDI_FPD_InterfaceClassLib. All interface classes inherit from FPD_Port, which itself inherits from the AML base interface Port. C. AttributeTypeLibs Two AttributeTypeLibs formalize the data structures. The VDI_FPD_AttributeTypeLib ( [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 1
Figure 1. Figure 1: VDI_FPD_RoleClassLib. The Class annotation indicates the parent class from which each role inherits. B. InterfaceClassLib – Connection Semantics The VDI_FPD_InterfaceClassLib ( [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 5
Figure 5. Figure 5: VDI_FPD_SystemUnitClassLib. Each entry shows the CAEX class inheritance (Class) and role mappings (Role). limit, states, process operators, and technical resources—are modeled as direct children at the same hierarchy level. The system limit does not serve as a CAEX container for the other elements, regardless of their graphical placement inside or outside it. An alternative would be to nest elements inside… view at source ↗
Figure 4
Figure 4. Figure 4: VDI_FPD_DI_AttributeTypeLib with graphical representation attributes based on the OMG DD metamodel. D. SystemUnitClassLib and Instantiation The VDI_FPD_SystemUnitClassLib ( [PITH_FULL_IMAGE:figures/full_fig_p003_4.png] view at source ↗
Figure 6
Figure 6. Figure 6: The process “Heating with Inspection” modeled in FPB.js (https://www.fpbjs.net, center) and exchanged via the domain library to the AML Editor, showing instance hierarchy (left) and element attributes (right). role assignments, and attribute values are correctly represented and navigable without requiring FPD-specific editor plugins or rendering logic. A limitation of the current validation is that round-t… view at source ↗
read the original abstract

The Formalized Process Description (FPD) according to VDI/VDE 3682 provides a standardized graphical notation for describing processes across engineering domains but lacks a standardized, tool-independent data format for machine-readable model exchange. This paper presents an AutomationML (AML) domain library that formalizes the complete set of FPD language elements, their attributes, connection semantics, and graphical representation information as class libraries based on the Computer Aided Engineering Exchange (CAEX) 3.0 metamodel. The library comprises five interrelated parts: a RoleClassLib defining the semantic roles, an InterfaceClassLib for connection types, two AttributeTypeLibs for the information model and diagram interchange, and a SystemUnitClassLib providing instantiation templates. Key design decisions regarding inheritance, diagram structure, hierarchical decomposition, and the representation of graphical information are discussed along with the alternatives that were considered. A bidirectional mapping tool demonstrates the library's applicability by converting between a web-based FPD modeler and AML. The library is proposed as a candidate for Part 3 of VDI/VDE 3682. It is available together with an example and a feedback function for community input ahead of standardization at https://aml.fpbjs.net.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper presents an AutomationML (AML) domain library based on the CAEX 3.0 metamodel that formalizes the complete set of Formalized Process Description (FPD) elements per VDI/VDE 3682, including semantic roles, connection types, information model, diagram interchange attributes, and instantiation templates. The library consists of five interrelated parts (RoleClassLib, InterfaceClassLib, two AttributeTypeLibs, and SystemUnitClassLib). Key design decisions on inheritance, diagram structure, hierarchical decomposition, and graphical representation are discussed. A bidirectional mapping tool is provided to demonstrate conversion between a web-based FPD modeler and AML, and the library is proposed as a candidate for Part 3 of VDI/VDE 3682 with open availability for community feedback.

Significance. If the lossless representation claim holds, the work would fill a practical gap by enabling tool-independent, machine-readable exchange of FPD models in engineering domains, directly supporting standardization efforts. The constructive approach with an open mapping tool and community feedback mechanism strengthens applicability.

major comments (2)
  1. [Abstract] Abstract and library description: the central claim that the five class libraries encode the 'complete set' of FPD language elements, connection semantics, and graphical attributes without metamodel extensions or external interpretations lacks any supporting completeness enumeration, formal mapping table, or validation against all VDI/VDE 3682 constructs. This is load-bearing for the standardization proposal.
  2. [Mapping tool description] The bidirectional mapping tool is presented as a demonstration, but no metrics on semantic preservation, round-trip fidelity, or coverage of edge cases (e.g., hierarchical decompositions or interface cardinalities) are reported, leaving the lossless-capture assumption untested.
minor comments (2)
  1. The manuscript would benefit from an explicit table listing each VDI/VDE 3682 element and its corresponding AML construct to make the mapping auditable.
  2. Consider adding a short section on limitations or known approximations in the representation of graphical attributes.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments, which identify key areas where the manuscript's central claims can be more rigorously supported. We address each major comment point by point below, indicating planned revisions.

read point-by-point responses

  1. Referee: [Abstract] Abstract and library description: the central claim that the five class libraries encode the 'complete set' of FPD language elements, connection semantics, and graphical attributes without metamodel extensions or external interpretations lacks any supporting completeness enumeration, formal mapping table, or validation against all VDI/VDE 3682 constructs. This is load-bearing for the standardization proposal.

    Authors: We agree that an explicit completeness validation is necessary to support the standardization proposal. The library was constructed through exhaustive mapping of every VDI/VDE 3682 element (roles, interfaces, attributes, and graphical properties) onto the CAEX 3.0 metamodel without extensions, but this mapping was not presented as a tabulated enumeration. In the revised manuscript we will add a dedicated subsection containing a formal mapping table that lists all FPD constructs alongside their AML representations, together with a brief validation statement confirming full coverage. revision: yes

  2. Referee: [Mapping tool description] The bidirectional mapping tool is presented as a demonstration, but no metrics on semantic preservation, round-trip fidelity, or coverage of edge cases (e.g., hierarchical decompositions or interface cardinalities) are reported, leaving the lossless-capture assumption untested.

    Authors: The mapping tool is offered primarily as a functional demonstration of the library's applicability rather than a full empirical study. We acknowledge that quantitative evidence would strengthen the lossless claim. The revised manuscript will include a new subsection reporting round-trip conversion results on representative models, explicitly addressing hierarchical decompositions and interface cardinalities with qualitative observations on semantic preservation. Comprehensive numerical metrics across every conceivable edge case are beyond the scope of the current demonstration and would benefit from subsequent community testing once the library is publicly available. revision: partial

Circularity Check

0 steps flagged

No circularity: constructive mapping of existing notation into metamodel

full rationale

The paper describes the creation of five interrelated AML class libraries (RoleClassLib, InterfaceClassLib, two AttributeTypeLibs, SystemUnitClassLib) to encode FPD per VDI/VDE 3682 inside unmodified CAEX 3.0. This is a one-way constructive specification and bidirectional converter implementation. No equations, fitted parameters, predictions, or derivations appear. Design decisions on inheritance and diagram structure are presented as engineering choices with alternatives considered, not as outputs forced by prior self-citations or self-definitions. The claim of lossless representation is supported by the explicit library contents and the mapping tool, which are independent artifacts rather than reductions to inputs. No load-bearing step reduces to a self-citation chain or renames a known result as a new derivation.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The construction rests on the assumption that CAEX 3.0 can host FPD without semantic loss and that the chosen inheritance and diagram structures are adequate; no free parameters or new entities are introduced.

axioms (1)
  • domain assumption The CAEX 3.0 metamodel is sufficient to represent all FPD language elements, attributes, connections, and graphical information.
    Invoked when the library is defined as class libraries based on the CAEX 3.0 metamodel.

pith-pipeline@v0.9.1-grok · 5747 in / 1266 out tokens · 20644 ms · 2026-06-28T08:48:07.885467+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

16 extracted references

  1. [1]

    VDI/VDE 3682 Part 1 – Formalized Process Descriptions – Concept and graphic representation,

    VDI/VDE, “VDI/VDE 3682 Part 1 – Formalized Process Descriptions – Concept and graphic representation,” 2015, Verein Deutscher Inge- nieure

    2015

  2. [2]

    VDI/VDE 3682 Part 2 – Formalized Process Descriptions – Information model,

    ——, “VDI/VDE 3682 Part 2 – Formalized Process Descriptions – Information model,” 2015, Verein Deutscher Ingenieure

    2015

  3. [3]

    A Formal Capability and Skill Model for Use in Plug and Produce Scenarios,

    A. Köcher, L. M. Vieira da Silva, C. Hildebrandt, and A. Fay, “A Formal Capability and Skill Model for Use in Plug and Produce Scenarios,” in25th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), 2020, pp. 1663–1670

    2020

  4. [4]

    Information Model of a Digital Process Twin for Machining Processes,

    B. Caesar, A. Hänel, E. Wenkler, C. Corinth, S. Ihlenfeldt, and A. Fay, “Information Model of a Digital Process Twin for Machining Processes,” in25th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), 2020, pp. 1765–1772

    2020

  5. [5]

    Transfor- mation eines Fähigkeitsmodells in einen PDDL-Planungsansatz,

    L. M. Vieira da Silva, R. Heesch, A. Köcher, and A. Fay, “Transfor- mation eines Fähigkeitsmodells in einen PDDL-Planungsansatz,”at – Automatisierungstechnik, vol. 71, no. 2, pp. 105–115, 2023

    2023

  6. [6]

    Offenes, web- basiertes Werkzeug zur Informationsmodellierung mit Formalisierter Prozessbeschreibung,

    H. Nabizada, A. Köcher, C. Hildebrandt, and A. Fay, “Offenes, web- basiertes Werkzeug zur Informationsmodellierung mit Formalisierter Prozessbeschreibung,” inProc. Automation 2020. VDI-Verlag, 2020, pp. 443–454

    2020

  7. [7]

    IEC 62714 – Engineering data exchange format for use in industrial automation systems engineering – AutomationML,

    IEC, “IEC 62714 – Engineering data exchange format for use in industrial automation systems engineering – AutomationML,” 2018, International Electrotechnical Commission

    2018

  8. [8]

    IEC 62424 – Representation of process control engineering – Requests in P&I diagrams and data exchange between P&ID tools and PCE-CAE tools,

    ——, “IEC 62424 – Representation of process control engineering – Requests in P&I diagrams and data exchange between P&ID tools and PCE-CAE tools,” 2016, International Electrotechnical Commission

    2016

  9. [9]

    Drath,AutomationML – A Practical Guide

    R. Drath,AutomationML – A Practical Guide. Berlin, Boston: De Gruyter Oldenbourg, 2021

    2021

  10. [10]

    Methodik zur Modellierung grafischer Beschreibungssprachen mit AutomationML am Beispiel der Formalisierten Prozessbeschreibung,

    R. Drath, H. Nabizada, and A. Fay, “Methodik zur Modellierung grafischer Beschreibungssprachen mit AutomationML am Beispiel der Formalisierten Prozessbeschreibung,” inEntwurf komplexer Automa- tisierungssysteme (EKA 2026), 2026

    2026

  11. [11]

    Description of manufacturing processes using AutomationML,

    A. Lüder, L. Hundt, and A. Keibel, “Description of manufacturing processes using AutomationML,” in15th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), 2010, pp. 1–8

    2010

  12. [12]

    Durchgängige Werkzeugunterstützung von der Anforderungserhebung bis zur Anla- genstrukturbeschreibung mittels formalisierter Prozessbeschreibung und AutomationML,

    T. Jäger, L. Christiansen, M. Strube, and A. Fay, “Durchgängige Werkzeugunterstützung von der Anforderungserhebung bis zur Anla- genstrukturbeschreibung mittels formalisierter Prozessbeschreibung und AutomationML,” inEntwurf komplexer Automatisierungssysteme (EKA 2012), 2012

    2012

  13. [13]

    V orschlag für eine XML-Repräsentation der Formalisierten Prozessbeschreibung nach VDI/VDE 3682,

    H. Nabizada, T. Jeleniewski, A. Köcher, and A. Fay, “V orschlag für eine XML-Repräsentation der Formalisierten Prozessbeschreibung nach VDI/VDE 3682,” inEntwurf komplexer Automatisierungssysteme (EKA 2022), 2022

    2022

  14. [14]

    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,” inProc. IEEE International Systems Conference (SysCon), 2024, pp. 1–8

    2024

  15. [15]

    Ontology Building for Cyber-Physical Systems: A domain expert-centric approach,

    C. Hildebrandt, S. Törsleff, B. Caesar, and A. Fay, “Ontology Building for Cyber-Physical Systems: A domain expert-centric approach,” in14th IEEE International Conference on Automation Science and Engineering (CASE), 2018, pp. 1079–1086

    2018

  16. [16]

    Diagram Definition (DD), Version 1.1,

    Object Management Group, “Diagram Definition (DD), Version 1.1,” 2015, OMG Document Number: formal/2015-06-01

    2015