SysML v2
.sysml
Native constructs
- Usage
part - Definition
part def - Relations
flow · perform · allocation · succession
Two communities.
One shared structure.
David Hoffmann
Otto von Guericke University Magdeburg
.sysml
Native constructs
partpart defflow · perform · allocation · succession.aml
CAEX constructs
InternalElementRoleClassExternalInterface + InternalLinkOMG · SysML v2
SysML v2 RFP issued
API & Services RFP
Beta specifications
Three specifications adopted
Certification launched
Different membership models; the organisational trend still runs in opposite directions.
Order-of-magnitude estimate from published membership counts and fee schedules.
Key message: INCOSE — the organisation behind SysML v2 — was able to scale where the AutomationML association was not.
Elements carry IDs in a repository. Keeping one object recognisable across different tools and round trips is not yet settled practice.
A kernel and a notation: the grammar. The domain vocabulary a receiving tool can act on is left to each project.
No worked-out account of how a plant gets engineered: who models what, in which order, handing over to whom.
A healthy open-source reference implementation — not yet a tool chain a production engineer opens on a Monday morning.
IDs that survive export and re-import between engineering tools — round-trip engineering, not file conversion.
Role class, interface class and system unit class libraries, the DMI library among them — agreed, reusable domain meaning.
Twenty years of plant-engineering handovers between tools — ECAD to PLC in AR APC is one of them.
Editors, SDKs and validators that production engineers already work with.
Star & Griesemer · 1989 · Social Studies of Science
“Plastic enough to adapt to local needs … yet robust enough to maintain a common identity across sites.”
Something recognisable survives the crossing.
Each side reads it its own way.
A repeatable route across. Not a meeting.
AutomationML's own success story. One agreed structure; electrical design and control engineering each read it their own way.
Not one merged model.A smaller agreement.
Arndt's keynote put liaison on this conference's agenda. Here is the version of that question I would keep.
A liaison tells us who to call.
A boundary object tells us what to work on together.
We ask how they should use AutomationML. The better question is what they already have that we should be reading.Keep the models. Name the shared object. Build the crossing.
Three reasons it is the right size for a boundary.
In the modelling core of AutomationML since year three. Not an import.
Native constructs on both sides. Nobody has to invent a concept.
Neither community adopts the other’s metamodel.
The format needed explaining.Product–Process–Resource did not.
One PPR graph. AutomationML keeps its three-view concept; SysML v2 reads the same meaning through native definitions.
item def <def_body_side_panel>
'Body-Side Panel';action def <def_spot_weld_joint_set>
'Spot-Weld Joint Set';part def <def_welding_robot>
'Servo-Gun Welding Robot';Not a third language. The same PPR identity, attributes and units survive in each standard’s own constructs.
The files do not look alike. They preserve the same identities, PPR kinds, values, units and relation meaning.
ppr-model.aml
<SystemUnitClass Name="Body-Side Panel" ID="def_panel">
<SupportedRoleClass RefRoleClassPath="…/Product"/>
<Attribute Name="thickness" Unit="mm" AttributeDataType="xs:double">
<Value>0.8</Value></Attribute></SystemUnitClass>
<SystemUnitClass ID="def_weld" …><SupportedRoleClass …/Process/>
<SystemUnitClass ID="def_robot" …><SupportedRoleClass …/Resource/>
<Attribute Name="payload" Unit="kg" AttributeDataType="xs:double">
<Value>165</Value></Attribute></SystemUnitClass>
<InstanceHierarchy Name="PPR Model">
<InternalElement ID="panel" RefBaseSystemUnitPath="…/Body-Side Panel">
<ExternalInterface Name="out" RefBaseClassPath="…/PPRConnector"/>
<InternalElement ID="weld" RefBaseSystemUnitPath="…/Spot-Weld Joint Set">
<ExternalInterface Name="panelInput" RefBaseClassPath="…/PPRConnector">
<Attribute Name="requestedQuantity"><Value>1</Value> …
<ExternalInterface Name="performedBy" …/PPRConnector/>
<InternalElement ID="robot" RefBaseSystemUnitPath="…/Welding Robot">
<ExternalInterface Name="performs" …/PPRConnector/>
<InternalLink ID="panel_to_weld"
RefPartnerSideA="panel:out" RefPartnerSideB="weld:panelInput"/>
<InternalLink ID="robot_performs_weld"
RefPartnerSideA="robot:performs" RefPartnerSideB="weld:performedBy"/>
</InstanceHierarchy>ppr-model.sysml
item def <def_panel> 'Body-Side Panel' {
attribute 'thickness' : Real = 0.8 [mm];
}
action def <def_weld> 'Spot-Weld Joint Set';
part def <def_robot> 'Welding Robot' {
attribute 'payload' : Real = 165 [kg];
}
part productOccurrences {
item <panel> 'Panel at Infeed' : def_panel;
}
action processOccurrences {
action <weld> 'Spot-Weld Joint Set' : def_weld {
in item panelInput : def_panel {
attribute requestedQuantity : Real = 1; } }
flow <panel_to_weld> from productOccurrences.panel to weld.panelInput;
}
part resourceOccurrences {
part <robot> 'Robot RB-10' : def_robot {
perform action <robot_performs_weld> references processOccurrences.weld; }
}This is already implemented as an MVP in the PPR editor.
Two relationships, at opposite ends of the same problem.
Engaging that community was not part of the mandate when I started.
In a narrower standards environment, that made sense.
2026: start that conversation deliberately.
Asset? · Device? · Capability? · Engineering configuration? · Information model? · PPR context?
Joint work since 2013/14. The open question is a different one.
End of talk Thank you. Questions & discussion