Source-linked AI summary
Toward Model-Driven Digital Twin Configuration: Separating Structure Semantics and Runtime with SysML SAREF and Ditto
Andrey Sadovykh, Matthew Rusakov, Kirill Korikov
TL;DR
The paper addresses opaque, manually written digital-twin configuration that lacks shared names, units, and device relationships. It proposes conceptual rules splitting structure, semantics, and runtime across SysML, SAREF4ENER, and Eclipse Ditto/WoT TD, then illustrates them on a greenhouse node. The resulting configuration carries explicit types, units, and sensor-actuator relations, while remaining limited to design-time rules rather than an executable generator.
Problem
Hand-written twin configuration uses arbitrary field names, implicit units, and no machine-readable device relationships, limiting reliable interpretation by other systems.
Method
The paper derives Ditto/WoT TD configuration from a SysML model annotated with SAREF4ENER using conceptual transformation rules.
Results
The greenhouse-derived configuration makes device categories, measurement semantics, units, and sensor-actuator relations explicit compared with hand-written JSON.
Takeaways & Limitations
Separating structure, energy semantics, and runtime representation yields traceable, semantically grounded configuration artifacts within the paper’s design-time scope.
Takeaways & Limitations
The approach introduces modelling overhead, leaves some Thing-versus-feature partitioning as a design decision, and does not yet provide executable templates.
Abstract
from arXiv · showhide
Energy communities, neighbourhoods that jointly produce, store, and consume electricity, increasingly rely on \emph{digital twins}: live software copies of physical devices such as a solar panel, a battery, or a heater, kept in sync for monitoring and control. Setting up such a twin is today mostly manual: an engineer hand-writes a configuration whose field names are arbitrary, whose units are implicit, and which carries no machine-readable description of how devices relate, so other systems cannot reliably interpret it. This position paper argues that the task should be split across three complementary tools, each doing what it does best: a modelling language for the system's structure (SysML), a standard energy vocabulary for its meaning (SAREF4ENER), and a digital-twin platform for the running representation (Eclipse Ditto, via the W3C Web-of-Things Thing Description). We give conceptual rules (not yet an executable generator) for deriving a Ditto configuration from a SysML model annotated with that vocabulary, illustrate them on a greenhouse energy-community node modelled in Modelio, and argue that the split improves traceability and configuration consistency, and establishes the semantic hooks needed for interoperability, over hand-written alternatives. We scope the contribution to design-time configuration and discuss its limits.
1 Introduction
The paper identifies hand-written digital-twin configuration as semantically opaque and proposes dividing configuration across SysML, SAREF4ENER, and Ditto/WoT TD. It presents conceptual design-to-runtime transformation rules and a greenhouse example.
- Hand-written Ditto configuration uses arbitrary names and implicit units, lacking machine-readable device relationships for reliable interpretation by other systems.
- SysML captures device structure, SAREF4ENER supplies shared energy vocabulary, and Ditto/WoT TD provides the deployable runtime representation.
- The design-to-configuration focus addresses an underrepresented energy domain and the absence of surveyed Eclipse Ditto transformation outputs.
- The paper defines conceptual transformation rules from SysML annotated with SAREF4ENER to initial Ditto configuration rather than an executable generator.
- A greenhouse energy-community node serves as the running example for carrying a control relation from the model into the twin configuration.
2 Background
The background positions SysML as the structural backbone, SAREF/SAREF4ENER as the semantic vocabulary, and Ditto/WoT TD as the runtime layer. Existing alternatives cover only subsets of these needs.
- SysML provides blocks, ports, value properties, parametrics, and requirement traceability for structural digital-twin engineering.
- Ditto represents devices as Things with attributes and features, while WoT Thing Descriptions add JSON-LD @type and @context semantic hooks.
- SAREF defines interoperable device and measurement vocabularies, while SAREF4ENER adds energy-device categories and flexibility profiles.
- The SAREF/SAREF4ENER hierarchy supplies measurement types for SysML value properties, device supertypes, and machine-readable observes/actsUpon relations.
- Compared alternatives each leave gaps: WoT-TD lacks design structure, Vorto lacks an energy vocabulary, and NGSI-LD lacks engineering structure.
3 Approach: SysML+SAREF to Ditto
The approach imports SAREF4ENER into Modelio and uses conceptual mappings to derive Ditto/WoT TD configuration while preserving shared semantic identity and traceability.
- SAREF4ENER is imported as a read-only Modelio reference package so device blocks and value properties can specialize or use standard types directly.
- The conceptual rules map SysML and SAREF model elements to Ditto and WoT TD concepts, with formal model-to-text templates left for future work.
- SAREF URIs become Ditto @type values, while every Ditto property traces back to a named SysML attribute and @context enables JSON-LD processing.
- The current process generates configuration text but does not yet provide automated OWL or SHACL validation or model-to-twin round-trip verification.
4 Greenhouse Example
The greenhouse example derives a Ditto configuration from a SysML model containing four device blocks, standard measurement types, and control relations. The resulting configuration makes device semantics, units, and sensor-actuator intent explicit.
- The greenhouse node contains TemperatureSensor, HVACSystem, SolarPanel, and GridConnection blocks derived from one SysML model instead of hand-edited Ditto JSON.
- The GreenhouseSystem composes four devices, whose value properties use SAREF measurement types and whose device blocks specialize SAREF/SAREF4ENER supertypes.
- The container block becomes the Ditto Thing and each device block becomes a feature, with model relations preserved in the mapping.
- Generated Ditto Configuration: The SolarPanel feature carries a PowerGenerator category, Power and Energy meanings, explicit units, and SysML-matching names instead of opaque numbers.
- Generated Ditto Configuration: The HVAC mapping places measured state in properties and its actsUpon target in desiredProperties, making the TemperatureSensor-to-HVACSystem loop explicit.
5 Discussion
The discussion assigns structure, standardised energy semantics, and runtime representation to SysML, SAREF4ENER, and Ditto/WoT TD respectively. It argues this split improves reuse and traceability while retaining design choices and coverage limits.
- Rationale: The split addresses model heterogeneity, synchronization, evolution, architectural fragmentation, missing platform semantics, and limited energy-domain representation.The paper presents these as challenges requiring coordination across notations rather than one monolithic model.
- Semantic division: SysML supplies structural modelling, while SAREF4ENER supplies standardised energy terms independently of whether SysML v1 or v2 is used.The rules treat the SAREF reference package as the semantic source rather than embedding energy vocabulary in the modelling language.
- Scalability and reuse: One imported SAREF reference package and a block-multiplicity rule support reuse across device types and instantiation across multiple community nodes.The same model can extend from one greenhouse to a community without hand-editing JSON for each device.
- Limitations: The approach adds modelling overhead, assumes SysML and ontology familiarity, leaves larger-system Thing-versus-feature partitioning as a design decision, and does not cover every energy-community concept.These constraints qualify the architectural clarity offered by the split.
6 Related Work
Related work covers structural SysML engineering, runtime digital-twin platforms, and energy ontologies, but reports limited integration across these concerns. The closest precedent adds SysML traceability to Ditto without energy semantics or SAREF integration.
- Existing strands: SysML-based digital-twin engineering supports structural design and lifecycle traceability but usually targets manufacturing or platforms other than Ditto.The related work positions SysML as effective structurally while identifying a platform and domain focus gap.
- Existing strands: Eclipse Ditto is practical at runtime, but its native model is lightweight and lacks built-in energy-domain semantics.The paper contrasts runtime practicality with the absence of domain meaning in the platform’s native representation.
- Existing strands: SAREF and SAREF4ENER provide standard smart-energy vocabulary, yet ontology-centred work rarely connects those concepts to engineering models and runtime platforms.This leaves the integration targeted by the paper underrepresented in prior work.
- Closest precedent: The closest precedent stores SysML element names in Ditto metadata for traceability, but does not integrate energy semantics or SAREF.The paper reports no prior work describing this combination for energy-community digital twins.
7 Conclusion
The paper concludes that separating structure, semantics, and runtime representation produces traceable, semantically grounded configurations. It identifies executable generation, broader validation, flexibility extensions, and runtime reflection as next steps.
- Conclusion: Separating SysML, SAREF4ENER, and Ditto/WoT TD yields configuration artifacts that are traceable and semantically grounded.The separation keeps each notation within its design scope.
- Conclusion: The transformation makes device types, units, and sensor-actuator relations explicit instead of leaving them implicit in hand-written JSON.These are concrete configuration consequences of the proposed rules.
- Future work: Next steps include executable model-to-text templates, validation across more SAREF4ENER device types, interoperability experiments, flexibility profiles, and runtime reflection back to SysML.These extensions go beyond the current design-time conceptual rules.