DIAMOND meets AutomationML | AutomationML Conference 2026

AutomationML Conference 2026 · Research transfer

DIAMOND meets
AutomationML

From PPR prototype to community tooling

DIAMOND built useful AutomationML software. The project ended. Now we are turning its reusable core into community-owned tooling.

David Hoffmann · Oussama Jarrar

Otto von Guericke University Magdeburg · Volkswagen AG

20 years of AutomationML · Conference 2026 · Hochschule Pforzheim, 22–23 September

01 · The opener

Wanted: the DIAMOND PPR editor

We built it. We demonstrated it. Almost nobody else used it. That is the problem.

The project succeeded on paper. By our transfer goal, the editor never arrived in this community.

WANTED alive, ideally maintained

THE DIAMOND PPR EDITOR a.k.a. “the tool from the paper”

Last seen: in a project deliverable, and in a demo
Condition: works; undocumented; unpackaged
Whereabouts: one research group's machines
Closed: DIAMOND ended, one year ago

The record

Built. Working on real AutomationML models.
Demonstrated. At reviews and conferences.
Published. Concepts documented in papers and deliverables.
Installed elsewhere. Almost never. The project ended a year ago.

PPR in one glance

Let me start with a confession. DIAMOND built a PPR editor. It worked, we demonstrated it, and we published the ideas behind it. As far as I can tell, almost nobody outside our group installed it or used it on their own data. DIAMOND closed a year ago, so the transfer work in this talk began after the project ended. That is a common fate for research software, and DIAMOND still did well by publication measures. Our goal also included bringing results into AutomationML. By that measure, the editor never arrived. The missing part was not code. It was everything that lets a stranger install, understand and trust the code. The small diagram is PPR: a product, a process, a resource and their relations — the AutomationML “three-way view.” The wording follows Schleipen and Drath, “Three-view-concept for modeling process or manufacturing plants with AutomationML,” IEEE ETFA 2009: https://ieeexplore.ieee.org/document/5347260. I will return to this poster when the editor reappears on a foundation the community can maintain.

02 · DIAMOND

What problem did we set out to solve?

DIAMOND linked five engineering disciplines through shared concepts in AutomationML.

Five disciplines, five truths

Five tools describe one plant. Each is correct, but the models do not connect.

A shared backbone

AutomationML carries the common concepts. PPR gives every discipline the same view.

Information that can travel

Shared information can be checked, processed and reused across disciplines and projects.

The project, in five lines

Funded by: BMWK / BMWE, from NextGenerationEU
Budget: €26.5 m project volume · 47.3% BMWK funding
Programme: KoPa 35c · a €1.5 bn federal package
Runtime: Nov 2022 – Oct 2025 · three years
Consortium: 25 partners · OEMs to universities

For anyone outside DIAMOND, this picture is the project in one minute. The scale is worth stating once, because it is the premise of the whole talk: DIAMOND ran for three years, from November 2022 to October 2025, with twenty-five consortium partners from OEMs through tool vendors to universities. Its project volume was €26.5 million, with a 47.3% BMWK funding share — the figure is listed in the official DIAMOND project facts linked from the project website's funding section: https://www.bundeswirtschaftsministerium.de/Redaktion/DE/Publikationen/Industrie/zukunftsinvestitionen-fahrzeughersteller-und-zulieferindustrie.pdf?__blob=publicationFile&v=4. The programme itself was the KoPa 35c automotive transformation programme, a one-and-a-half-billion-euro federal package. This was not a small project, and that is exactly why the ending I described on the previous slide should bother us. Mechanical, electrical, automation, process planning and simulation all describe the same plant. Their models are individually valid and mutually disconnected, so every project rebuilds the integration through exports, conventions and phone calls. DIAMOND introduced a small set of shared concepts instead of one model that tries to absorb every discipline. AutomationML carries those concepts, and PPR gives them a common view across domain boundaries. That enables consistency checks, automated processing and reuse. Software is what turns the readable information into those outcomes.

03 · DIAMOND

The “tip of the diamond” problem

The papers are public. The reusable capability beneath them still needs a community home.

Public, but not installable

The documents explain the capability. They do not deliver software the community can use.

Four assets still need a home

Semantic & modelling conceptscommon concepts · PPR over CAEX · roles
Software componentsPython AML handling · AML-JSON processing
Tooling prototypesthe PPR editor · transformations · inspection
Industrial experiencewhere the standard held, and where it bent

Transfer needs three things

A result becomes community software when it has:

An installable, named package
A maintainer with clear ownership
Community versioning and governance

The record is public. The capability still needs a community home.

04 · What was actually built

The PPR editor was only the visible layer

The editor was the demo. Its reusable value sits in the six layers below.

A demo cannot be installed

We showed the editor in papers, posters and demos. Nobody outside the project received a usable tool.

The demo was easy to see
The reusable stack had no package or name

The reusable part is underneath

Package these six layers as an SDK, and the editor becomes one application built on top.

Useful to any AutomationML application
Already exercised on real models

06 · The pull

Volkswagen was ready to choose AML-JSON. Four questions remained.

The format was never the sticking point. What a developer could actually pick up was. Of four questions, we could answer one.

Volkswagen · internal evaluation AML-JSON favoured as the target exchange format

The honest answer, that week

Yes

The association owns the specification. I could send one clear link.

Thin

Examples were scattered across papers and project repositories.

DIAMOND contained the pieces, but no named, installable release.

Prototype

The PPR editor ran at our institute. Nobody else could install it.

In the same months · I switched sides

Was David Hoffmann · Research Assistant helped build the prototype DIAMOND · OVGU Magdeburg

Am David Hoffmann · Technical Coordinator now responsible for the tooling AutomationML e.V.

The gap became my job.

07 · The widened question

What does “supporting AML-JSON” actually mean?

A specification is only the first of four layers a developer needs.

AML-JSON needs more than a JSON document.

A documented representation

The model is documented and conformant. AutomationML already does this well.

Necessary, but not sufficient alone

Objects and operations

Developers need to load, navigate, edit, validate and write models without building another parser.

The .NET implementation proves the pattern

A dependable release

Versions, changelogs, tests, CI and planned deprecation turn a library into a production dependency.

The specification cannot provide this

A maintainer who answers

Issues need owners. User needs need a route into the roadmap. Maintenance needs continuity.

Defined for the standard, still open for software

08 · The response

An AutomationML SDK for Python

The Python SDK starts from AML-JSON and proves compatibility through a round-trip in the AutomationML Editor.

from automationml import (attribute, caex_file, dump_json, dump_xml,
                          instance_hierarchy, internal_element, load_xml)

doc = caex_file("cell.aml")
robot = internal_element("Robot RB-10", id="ie-robot-01",
    attributes=[attribute("payload", 210, unit="kg", data_type="xs:double")],
    role_paths=["AutomationMLDMIRoleClassLib/Resource"])

doc.instance_hierarchies.append(
    instance_hierarchy("Cell 01", internal_elements=[robot]))
# snake_case in Python, canonical CAEX names in the file

dump_json(doc, "cell.amljson")  # no conversion: this IS the model

{ "SuperiorStandardVersion": ["AutomationML 2.1"],
  "InstanceHierarchy": [{ "Name": "Cell 01",
    "InternalElement": [{ "ID": "ie-robot-01", "Name": "Robot RB-10",
      "Attribute": [{ "Name": "payload", "Value": "210", "Unit": "kg",
                      "AttributeDataType": "xs:double" }],
      "RoleRequirements": [{ "RefBaseRoleClassPath": "…/Resource" }] }] }],
  "SchemaVersion": "3.0", "FileName": "cell.aml" }
# SourceDocumentInformation elided

dump_xml(doc, "cell.aml")  # CAEX 3.0 for the XML toolchain

<CAEXFile xmlns="http://www.dke.de/CAEX" SchemaVersion="3.0">
  <InstanceHierarchy Name="Cell 01">
    <InternalElement ID="ie-robot-01" Name="Robot RB-10">
      <Attribute Name="payload" Unit="kg" AttributeDataType="xs:double">
        <Value>210</Value>
      <RoleRequirements RefBaseRoleClassPath="…/Resource"/>
# one logical model, two representations. ChangeMode elided.

Checked by hand on every release

cell.aml opens in the AutomationML Editor
No errors, no warnings, no repaired references
Conformance against the CAEX 3.0 XSD runs in CI

# saved again from the Editor, by the Editor's own writer
back = load_xml("cell_from_editor.aml")

# load_xml upgrades CAEX 2.15 input on the way in, so an
# older Editor file still comes back as a 3.0 model

doc = build_cell()
dump_xml(doc, tmp_path / "cell.aml")
back = load_xml(EDITOR_OUT / "cell.aml")

assert back.to_aml_dict() == doc.to_aml_dict()

# tests/test_xml_roundtrip.py, on every push:
def test_generated_xml_is_valid_caex_3_against_xsd(): ...
def test_xml_json_xml_keeps_semantic_references_valid(): ...

JSON-first, compatible with the XML toolchain
The model maps directly to AML-JSON

github.com/AutomationML/automationml-python · MIT · alpha

Here is the technical response. AutomationML already has a mature .NET implementation centred on CAEX XML. The Python SDK starts from AML-JSON because Python users already work with that shape. Compatibility is proven through the six-step round-trip. Build the model in Python, write AML-JSON, write the same model as CAEX XML, open it in the AutomationML Editor, save it with the Editor's writer, then load it back into the SDK and compare both models. The dictionaries are equal. That test shows the JSON-first SDK still participates fully in the XML toolchain. Everything on this slide is real API output from the MIT-licensed repository linked at the bottom: AutomationML slash automationml-python. It is alpha, so the public API may still move before the first stable release. The Editor step remains a manual check; the XSD conformance underneath it already runs in CI.

09 · The demonstrator

The PPR editor returns on top of the SDK

Instead of inventing another format, we use a purpose-built PPR editor. Its SDK foundation is reusable by other AutomationML applications.

Research prototype · github.com/DHoffmannOVGU/PPR-Editor

Work in domain terms

Selecting the process shows what it takes in, what it hands on, and which resource performs it — with quantities. CAEX stays out of the interface.

The SDK owns the files

AutomationML, SysML v2 or a process specification — all four exports are the SDK validating and serialising one model. Any application can reuse the same foundation.

10 · The outcome

Volkswagen is going ahead with AML-JSON

Working software answered the four questions. Volkswagen chose AML-JSON for a toolchain its engineers already know, and the decision is being documented.

The four questions, closed

“Where is the specification?” Published by the association
“Where are the examples?” In preparation with the paper
“Do you have a Python SDK?” Prototype today, public under MIT next
“Is there an application?” PPR editor running on the SDK

The specification opened the door. Working software closed the decision.

Evaluation table comparing XML, AutomationML, JSON and AutomationML-JSON across technical, process and organisation criteria; AutomationML-JSON has the highest total score of 0.782

The decision

AML-JSON, adopted

Volkswagen and Oussama Jarrar's doctoral research are moving ahead with AutomationML-JSON. Direct work resolved the open questions.

CIRP CMS · abstract submitted

Why Volkswagen chose AML-JSON

With Oussama Jarrar · abstract submitted, awaiting acceptance

The core reasonA modern toolchain: Python, JSON and pip. Incoming engineers already know it; the XML/C# stack requires extra onboarding.

JSON fits the systems and pipelines already in the plant
Open community results can be reused, not rebuilt

An industrial member is back in the AutomationML conversation. Maintained software made that possible.

11 · A word of caution

One editor crossed. How do the next results cross?

We need a repeatable transfer route for project software, papers, Application Recommendations and Best Practice Recommendations.

A Promise at kick-off Transfer is written into the proposal
The project hands over documentation. The capability stays in the consortium.

Tried. We received the tip.
B Today · recover after the project Pick up results one by one
A community mini-job extracts and packages each result after the team moves on.

Works. Loses a year and momentum.
C Transfer while building Convert results as they appear
A full-time community role converts results while the authors are available.

Untested. Faster and far more expensive.

The question for this community

Which route becomes our default, and who owns it?

This applies beyond project software

Research project results
Papers
Application Recommendations
Best Practice Recommendations
Whatever comes next

The editor is one result from DIAMOND, so the larger question is how we transfer everything else. I see three routes. Route A promises transfer in the proposal. In practice, the project hands over documents while the capability stays with the consortium. Route B recovers results after the project. That is the current setup, and I should be precise about its size: the association work behind this talk is a mini-job. It works, but a year passes, people move on and context fades. Route C puts someone in the project while it runs, converting results into independent association assets while the authors are still there. I want to be honest that this is not the cheap option and I am not proposing it as the only way: it needs a full-time technical position, which costs several times what route B costs today. We have not tried it, and it preserves momentum. The same decision applies to software, papers, Application Recommendations and Best Practice Recommendations. Which route becomes our default, and who owns it?

12 · And for now

Happy modeling!

The SDK and editor are going open source under MIT. The browser demo is live today.

Where to find it

The AutomationML Python SDK model · validation · JSON and XML · API · MIT github.com/AutomationML/automationml-python
The PPR editor browser editor · MIT github.com/DHoffmannOVGU/PPR-Editor

Find it here: github.com/DHoffmannOVGU/PPR-Editor

Thank you. Questions, issues and pull requests all mean someone is using it.