]> Electronics and Telecommunications Research Institute

218 Gajeong-ro, Yuseong-gu Daejeon 34129 South Korea +82 42 860 1213 hjlee294@etri.re.kr

Electronics and Telecommunications Research Institute

218 Gajeong-ro, Yuseong-gu Daejeon 34129 South Korea +82 42 860 0926 jhong@etri.re.kr

ART ASDF Internet-Draft This memo specifies SDF modeling for digital twins, i.e., digital twin systems, and their things. An SDF is a format that is used to create and maintain data and interaction, and to represent the various kinds of data that is exchanged for these interactions. The SDF format can be used to model the characteristics, behavior and interactions of things, i.e. physical objects, in digital twins that contain things as components.

Introduction A digital twin is defined as a digital representation of an object of interest and may require different capabilities, for example, synchronization and real-time support, according to the specific domain of application. Digital twins help organizations improve important functional objectives, including real-time control, off-line analytics, and predictive maintenance, by modeling and simulating objects in the real world. Therefore, it is important for a digital twin to represent as much real-world information about the object as possible when digitally representing the object. Digital twin technologies are applied in various domains, including manufacturing, energy, healthcare, agriculture, and transportation. A common format is therefore needed to represent objects in these domains as digital twins. SDF can be used for modeling objects as digital twins. This document specifies the modeling and guidance on how to use SDF to represent objects as digital twins.

Terminology This specification uses the terminology specified in , in particular "Class Name Keyword", "Object", and "Affordance". The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

SDF structure for digital twin This section describes SDF structure to represent a thing or an object as a digital twin. The architecture of a digital twin based on the SDF model is illustrated in , following the guidelines of . The physical layer comprises affordance and non-affordance objects. From the real-world objects, only those deemed relevant are selected for representation as digital twins. The digital twin layer is structured into three sublayers: the device communication sublayer, the digital twin sublayer, and the application sublayer. The device communication sublayer is responsible for monitoring and collecting data from both affordance and non-affordance objects. This sublayer provides the necessary data to synchronize the physical objects with their digital twin counterparts. The digital twin sublayer ensures synchronization between the affordance and non-affordance objects and their respective digital twins using the data provided by the Device Communication Sublayer. The Application sublayer presents the synchronized values of the digital twins to users to facilitate informed decision making.

Basic Architecture of digital twin

Motivation and design rationale The document is based on the underlying structure defined in , which standardizes the semantic definition format (SDF) for representing IoT affordances. This specification provides a strong basis for representing individual devices and their features (sdfProperty, sdfAction, sdfEvent, etc.), but additional mechanisms are needed to address the unique requirements of digital twin modeling. Digital twin systems defined in often have to describe virtual representations of various physical objects, including metadata, identity, contextual relationships, historical data, as well as device interfaces.

Introduction to sdfContext The sdfContext keyword defined in can be used to represent non-affordance or contextual information that describes a device or component without implying direct interaction:

• Identifier (e.g., UUID, URN)
• Location (e.g. site, zone, GPS tag)
• Owner (e.g., representative, manufacturer)

These fields can appear in both sdfObject and sdfThing contexts, follow the same structural pattern as sdfData, and are designed for scalability.

Digital twin modeling using SDF elements To support hierarchical representations (e.g., a boat composed of heater, GPS, and battery subsystems), this document encourages use of sdfThing to aggregate related sdfObject components, along with metadata. The example mapping of digital twin attributes to SDF elements is shown in . Digital twin modeling using elements of SDF model

Attribute	Recommended Mapping	Description
Identifier	sdfContext	Globally unique digital twin ID (e.g., URN)
Characteristic	sdfProperty or sdfData	General description or domain properties
Schedule	sdfEvent or sdfData	Time-based actions, availability, or maintenance
Status	sdfAction or sdfProperty	Actual or calculated operating conditions
Location	sdfContext	Physical or logical location information
Report	sdfData	Measurement summaries, analytics, or logs
owner	sdfContext	Organization or entity responsible for the digital twin
Relationship	sdfRelation	Inter-object/inter-twin relationships

Relationship modeling The sdfRelation, defined in , is a structure for specifying logical or physical relationships between objects within an SDF model. If conventional sdfThing, sdfObject, and sdfProperty focus on defining the properties of individual digital twins, sdfRelation is a means of expressing interactions and structural links between them. The sdfRelation keyword provides a mechanism for expressing logical, physical, functional, or semantic relationships between SDF definitions beyond simple containment or hierarchy. These relationships can include:

• Physical relations (e.g., "inside", "next to")
• Functional relations (e.g., "controls", "is controlled by")
• Semantic relations (e.g., "similar to", "same as")

The sdfRelation definition can include the following fields as defined in :

• relType: Specifies the type of relationship and may refer to a term defined in an external ontology (e.g., SAREF).
• target: Points to the SDF object or an external ontology term that is the target of the relationship.
• description: Provides a detailed textual explanation of the relationship.
• label: A short human-readable label for the relationship.
• property: Additional properties describing the relationship context.
• $comment: Optional properties including implementers notes.

An example of sdfRelation is shown in . The sdfProtocolMap in this example is described in and

An example of sdfRelation

Protocol considerations for digital twin realization

Motivation Digital twins require continuous and reliable communication with physical objects. To support synchronization, monitoring, control, and event notification, appropriate network protocols should be selected and semantically bound to modeled elements in SDF structures. This clause outlines the main protocol types, roles in digital twin operations, and guidelines for representing these bindings using .

Supported protocol types Digital twin applications can use different protocols and ecosystem technologies depending on device capabilities, data volume, latency requirements, deployment environment, and application domain. The current SDF Protocol Mapping document defines mappings for BLE and Zigbee. therefore lists examples of protocols and ecosystem technologies that can participate in a digital twin implementation; inclusion in the table does not imply that an SDF protocol mapping has been standardized for every entry. Example protocols and ecosystem technologies for digital twin realization

Protocol / technology	Role in digital twin	Characteristics
MQTT	Sensor data publishing, event reporting	Lightweight, publish-subscribe, suitable for IoT
CoAP	Access to constrained devices	Compact REST-like communication and observe/notify support
BLE	Local data exchange and control for wearables or embedded devices	Low energy, short range communication using services and characteristics
Zigbee	Sensor data access, event reporting, and device control	Uses endpoints, clusters, attributes, and commands
Matter	Interoperable device monitoring and control, particularly for smart-home and smart-building devices	IP-based application layer using device types, endpoints, clusters, attributes, commands and events
BACnet	Building automation and HVAC monitoring/control	Widely used for building automation systems and exposes building-device objects and properties
KNX	Building control such as lighting, shading, and room automation	Widely deployed home and building control technology
HTTP/REST	Enterprise integration and cloud API	Widely supported application interfaces with comparatively higher overhead
WebSocket	Bi-directional low-latency updates	Useful for state synchronization and real-time commands
NIPC	Standardized control of non-IP devices	Applicable to industrial, legacy and isolated device environments

Protocol binding in SDF To model the way digital twins communicate with their physical objects, sdfProtocolMap can be defined within the sdfProperty, sdfAction or sdfEvent levels. Each protocol entry can specify a communication topic, path, security mechanism, QoS settings, and timing parameters as shown in .

An example of protocol binding

QoS considerations Quality of service (QoS) settings define the reliability and frequency of data transfer between digital twins and physical objects. These settings are particularly important for telemetry (e.g., sdfProperty updates) and command response flows (e.g., sdfAction operations). For example, MQTT defines three QoS levels that can be selected according to the reliability requirements of digital twin data exchange, as shown in . Example MQTT QoS levels and recommended usage

QoS level	Meaning	Recommended Usage
0	At most once (best effort)	Periodic sensor data
1	At least once	State updates, events
2	Exactly once	Control command, AI action

Security and access considerations Protocol bindings used by a digital twin need to preserve the security properties of the underlying protocol and deployment. Implementations should use the authentication, authorization, confidentiality, integrity, and replay-protection mechanisms appropriate to the selected protocol. Access to SDF Properties, Actions, Events, and contextual information should be restricted according to the security policy of the digital twin system.

Implementation guidelines The protocol is essential to realizing the digital twin in operation, and it is recommended that the following considerations are taken into account:

• Use protocol mapping appropriate for device classes and network environments
• Provide both push-based (e.g., MQTT) and poll-based (e.g., HTTP) bindings, if applicable
• Reuse standardized subject structures, UUIDs, or endpoint URIs to ensure interoperability
• Avoid duplicate or conflicting bindings, and define protocol preferences via metadata if necessary.

Digital twin system in various domains

Overview Various examples are included to show how SDF-based digital twin models can be applied to real-world scenarios. These examples show how to represent physical objects using SDF elements. In addition, sdfContext and sdfRelation are used to describe additional information such as the context of components, and the relationship between components (sdfRelation). The examples cover several domains, including marine systems, healthcare systems, smart buildings, and smart networks. This consistent modeling approach can support interoperability across applications.

Marine system describes an example of how a maritime vessel, referred to as Boat007, can be described as a digital twin using the SDF model. In this example, individual physical parts such as heaters and batteries are treated as separate sdfObjects, while the entire vessel is represented as a single sdfThing that groups these components together. In a vessel modeled with SDF, each component is described using elements such as attributes, actions, and events. These elements are used to represent how the component behaves and what state it is in at a given time. The connections between components are also included in the model. For example, a battery may be linked to a controller, which helps show how different parts are related and interact with each other. This kind of representation makes it easier to follow the condition of devices over time. It also allows operational data to be used more effectively for monitoring, while keeping the model compatible with other systems built in a similar way. This structure enables developers and systems integrators to:

• Seamlessly capture and communicate the features and state of the device
• Consolidate operational data for real-time monitoring and analysis
• Standardized semantics enable interoperability with other domains.

Components and SDF elements of a marine system

Attribute	SDF element	Properties
Boat007	sdfThing	label, vesselId, homePort; includes heater1, thermostat1, batterySensor1, and powerController1
Heater1	sdfObject	status, temperature, turnOn, turnOff
Thermostat1	sdfObject	setPoint, mode (sdfProperty)
Battery sensor1	sdfObject	chargeLevel, voltage, batteryToController
Power controller	sdfObject	connect, disconnect
Temp-to-Thermostat	sdfRelation	heater1 → thermostat1, relType: regulatedBy
Battery-to-powerController	sdfRelation	batterySensor1 → powerController1, relType: connectedTo
Context information	sdfContext	vesselId, homePort, manufacturer, model

In the context of Boat007, shown in , such a digital twin can support various applications, including predictive maintenance, energy optimization, and fleet-level coordination, demonstrating the practicality and scalability of SDF-based Digital twin modeling for mobility and transportation systems.

An example of marine system

Healthcare system This case represents a digital twin for a patient health monitor system (patientMonitor001) assigned to a patient. The system reports real-time health properties while referencing contextual patient information with the components and elements shown in . Components and SDF elements of a healthcare system

Attribute	SDF element	Properties
Patient monitor	sdfThing	patientMonitor001 as a digital twin
ECG module	sdfObject	heartRate, rhythmType
Infusion pump	sdfObject	flowRate, volumeRemaining
Alert system	sdfObject	highHeartRateAlert
Context information	sdfContext	wardLocation, patientID, manufacturer, model, serialNumber
Relationship	sdfRelation	ECG to alertSystem (relType: monitoredBy)

A digital twin example of a patient monitoring system with ECG and infusion pump components is illustrated in . In this healthcare scenario, a biosensor measuring the heart rate is functionally connected to an alert system that emits a high-heart-rate warning, enabling real-time patient monitoring in medical environments.

An example of healthcare

Smart building system This case illustrates the use of SDF as a common semantic layer for a smart-building digital twin whose devices and subsystems are implemented using different protocols and ecosystem technologies. A single building can contain, for example, Matter-based lighting , BACnet-based HVAC , KNX-based shading , CoAP environmental sensors, MQTT energy meters, and HTTP/REST-based building-management services. SDF does not replace these technologies. Instead, it provides a protocol-independent representation of what each component is, which Properties, Actions, and Events it exposes, which contextual information describes it, and how the components are related. This separation allows applications to interpret a heterogeneous building consistently even when the underlying implementations use different protocol-specific data models. The components used in this example are summarized in . Protocol and ecosystem names are illustrative implementation information; except where a mapping is explicitly defined by the SDF Protocol Mapping specification, this example does not define a new SDF protocol mapping. Components and SDF elements of a smart building system

Building component	SDF element	Example information
Building digital twin	sdfThing	building001 containing room and subsystem objects
Lighting system	sdfObject	powerState, brightness, setBrightness; implemented with Matter
HVAC system	sdfObject	temperatureSetPoint, operatingMode, setTemperature; implemented with BACnet
Shading system	sdfObject	blindPosition, setBlindPosition; implemented with KNX
Environmental sensor	sdfObject	temperature, CO2 concentration; implemented with CoAP
Energy meter	sdfObject	powerConsumption; implemented with MQTT
Building context	sdfContext	buildingUse, roomNumber, floor, zone
Relationships	sdfRelation	locatedIn, controlsClimateOf, measuresPowerOf

shows an SDF representation of the heterogeneous building. The protocol-independent SDF model enables an application to determine, for example, that a sensor is located in Room101, an HVAC system controls the climate of that room, and an energy meter measures the HVAC power consumption, without requiring those systems to share the same native protocol. The principal value of SDF in this scenario is semantic interoperability across heterogeneous device ecosystems. Device-specific communication and control remain the responsibility of the underlying protocols and protocol mappings.

An example of a heterogeneous smart building system

Smart network system This case illustrates a digital-twin-based smart network system that supports abnormal-situation prediction and response for a network device. The example distinguishes a digital twin corresponding to the network device from a digital twin corresponding to traffic information associated with that device. During model preparation, the system obtains traffic information for the network device, generates digital twins corresponding respectively to the network device and the traffic information, and synchronizes current traffic information with the traffic-information twin. An analytics function can then train a prediction model using information represented by the synchronized twins. During operation, the system obtains current traffic information and uses the trained prediction model together with the digital-twin state to predict an abnormal situation of the network device. If an abnormal situation is predicted, an application can determine a countermeasure appropriate to the predicted situation. Model training, inference, and countermeasure-selection algorithms are application functions; SDF is used to describe the digital-twin entities, their state, their relationships, and the interfaces through which prediction results or response actions are exposed. The SDF elements used in this example are summarized in . Components and SDF elements of a smart network system

Attribute	SDF element	Example information
Smart network system	sdfThing	smartNetwork001 containing the network-device and traffic twins
Network-device twin	sdfObject	device identifier, operational state, utilization, latency
Traffic twin	sdfObject	current traffic, traffic history, traffic pattern
Current traffic information	sdfProperty	currentTraffic, packetRate
Twin association	sdfRelation	association of the traffic twin with the network-device twin
Prediction result	sdfProperty / sdfEvent	anomalyScore, abnormalSituationPredicted
Countermeasure interface	sdfAction	applyCountermeasure for a predicted abnormal situation

shows the conceptual processing sequence. The procedure is intentionally described at an architectural level; this document does not standardize a prediction algorithm.

Digital twin-based prediction and response procedure for a smart network system

provides an SDF representation of the entities and interfaces used by the example.

An example of a smart network system

Requirements for implementing digital twins A digital twin may be represented using an sdfThing or sdfObject containing elements such as sdfProperty, sdfAction, sdfEvent, sdfContext, and sdfRelation. When an observable object participates in multiple application domains, different digital twins of the same observable object may be configured according to the purpose and role of the object in each domain. The following implementation considerations are applied to SDF-based digital-twin representations, taking into account the general digital-twin principles described in .

• Purpose definition: The purpose for representing an observable object as a digital twin should be defined for each application domain. The purpose determines which characteristics, behaviors, contextual information, and interactions of the observable object need to be represented.
• Role-based data organization: Data associated with the observable object should be organized according to the role that the object performs in the domain. A role identifies the function or behavioral action performed by the observable object to achieve the defined purpose.
• Cross-domain digital twin information: When the same observable object is represented by digital twins in multiple domains, information about the digital twins that exist in other domains should be available where necessary for interworking. The digital twins in different domains may represent different characteristics of the same observable object according to their respective purposes and roles.
• Domain-specific digital twin configuration: An observable object may be configured as a digital twin using the data, purpose, and role defined for a particular domain. Consequently, digital twins representing the same observable object in different domains may expose different sdfProperties, sdfActions, sdfEvents, sdfContext information, or sdfRelations.
• Interworking among domain-specific digital twins: A digital twin system should support interworking, where required, with digital twin systems in other domains in which the same observable object performs a different role. sdfRelation and other SDF mechanisms may be used to describe relationships among such digital-twin representations.
• Synchronization with the observable object: The state of a digital twin should be synchronized with the state of the corresponding observable object at intervals appropriate to the application. Changes in relevant sdfProperties, sdfEvents, sdfActions, or contextual information should be reflected in the digital twin according to the synchronization requirements of the domain.
• Cross-domain state consistency: When multiple digital twins represent the same observable object in different domains, information that represents a common state of the observable object should be maintained consistently among those digital twins. Domain-specific characteristics may remain different, while shared state information should be synchronized so that the digital twins do not represent conflicting states of the same observable object.

Procedure for digital twin implementation

Overview It is essential to define a consistent implementation procedure to support interoperability, scalability, and lifecycle management across digital twin systems. This section describes a step-by-step approach aligned with the Semantic Definition Format (SDF) model and its architecture. When an observable object participates in multiple application domains, the same observable object may be represented by different digital twins according to the purpose and role of the object in each domain. The general procedure for representing and operating such digital twins is outlined as follows:

• defining a purpose for expressing the observable object as a digital twin in the domain;
• collecting and organizing data according to the roles of the observable object in the domain;
• receiving information about digital twins of the same observable object that exist in other domains in which the observable object performs different roles;
• configuring the observable object as a digital twin based on the collected data, defined purpose, and role of the observable object in the domain;
• enabling interworking with digital twin systems in other domains in which the same observable object performs different roles;
• synchronizing the observable object and its corresponding digital twin;
• maintaining consistent shared state information among digital twins representing the same observable object across multiple domains.

A domain-specific digital twin may represent characteristics that differ from those represented by digital twins in other domains in order to support the purpose and role defined for the observable object in that domain. A role represents a function performed through one or more behavioral actions to achieve the defined purpose.

Procedure The procedure for configuring and operating an observable object as a digital twin is described below.

• Identifying and scoping the observable object: The observable object to be represented as a digital twin is identified, and the scope of the digital representation is determined. A globally unique identifier, such as a URN or UUID, may be assigned to the observable object or its digital twin.
• Defining the purpose: The purpose for expressing the observable object as a digital twin is defined for the application domain. The purpose determines which characteristics, behaviors, contextual information, and interactions need to be represented.
• Organizing data based on roles: Data associated with the observable object is collected and organized according to the role that the object performs in the domain. The role represents a function performed through behavioral actions to achieve the defined purpose.
• Receiving cross-domain digital twin information: When the same observable object is represented by digital twins in other domains, information about those digital twins should be obtained as necessary. Such information may include their purposes, roles, represented characteristics, contextual information, and shared state information.
• Configuring a domain-specific digital twin: The observable object is represented using SDF structures such as sdfThing and sdfObject based on the collected data, defined purpose, and role. Affordances may be represented using sdfProperty, sdfAction, and sdfEvent, while contextual and descriptive information may be represented using sdfContext. Digital twins representing the same observable object in different domains may contain different characteristics because each digital twin is configured according to the purpose and role defined in its respective domain.
• Describing relationships: Relationships between the observable object, its components, and digital twins may be represented using sdfRelation. Relationships between digital twins of the same observable object in different domains may also be described where cross-domain interworking is required.
• Binding interfaces and communications: SDF affordances may be associated with communication interfaces and protocols such as MQTT, CoAP, BLE, Zigbee, or other applicable technologies through protocol-specific mappings where available. This enables interaction between the SDF representation and physical or logical resources.
• Interworking among domain-specific digital twins: A digital twin system may interwork with digital twin systems in other domains in which the same observable object performs different roles. Interworking can be used to exchange information needed to interpret shared state or coordinate domain-specific operations.
• Synchronizing the observable object and the digital twin: Information obtained from the observable object is used to update the state of the corresponding digital twin. The synchronization interval and update mechanism depend on the requirements of the application and the characteristics of the observable object.
• Maintaining cross-domain state consistency: When multiple domain-specific digital twins represent the same observable object, shared state information should be maintained consistently among those digital twins. Domain-specific characteristics may remain different, while information representing the common state of the observable object should be synchronized so that different digital twins do not represent conflicting states of the same observable object.
• Verification and compliance: The resulting SDF representation should be validated against applicable syntax and semantic rules. Compliance with SDF specifications, profiles, and relevant domain-specific requirements should also be verified where applicable.
• Deployment and lifecycle management: After verification, the digital twin may be deployed in a digital twin registry, edge system, or cloud environment. Version management, updates, audit information, and eventual deregistration should be managed throughout the lifecycle of the digital twin.

Security Considerations Only authorized users should have the authority to manage digital twins, sdfThings and sdfObjects. Also, secure communication and metadata integrity are essential when implementing digital twins. All context messages, including contextPatch and identityManifest, must be protected using appropriate authentication and authorization mechanisms.

IANA Considerations This document has no IANA actions.

References Normative References KTC Control AB Universität Bremen TZI Ericsson The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. An SDF specification describes definitions of SDF Objects/SDF Things and their associated interactions (Events, Actions, and Properties), as well as the Data types for the information exchanged in those interactions. Tools convert this format to database formats and other serializations as needed. ETRI ETRI This document describes an extension to the Semantic Definition Format (SDF) for representing non-affordance information of Things, such as physical, contextual, and descriptive metadata. This extension introduces a new class keyword, sdfContext, that enables comprehensive modeling of Things and improves semantic clarity. Ericsson The Semantic Definition Format (SDF) base specification defines set of basic information elements that can be used for describing a large share of the existing data models from different ecosystems. While these data models are typically very simple, such as basic sensors definitions, more complex models, and in particular bigger systems, benefit from ability to describe additional information on how different definitions relate to each other. This document specifies an extension to SDF for describing complex relationships in class level descriptions. This specification does not consider instance- specific information. Cisco Systems Cisco Systems Philips This memo describes an API that allows applications to perform operations against a gateway serving one or more devices described by an SDF model. The document describes RESTful application layer interface to perform operations on those devices, as well as a CBOR- based publish-subscribe interface for streaming data. Cisco Systems Cisco Systems Ericsson This document defines protocol mapping extensions for the Semantic Definition Format (SDF) to enable mapping of protocol-agnostic SDF affordances to protocol-specific operations. The protocol mapping mechanism allows SDF models to specify how properties, actions, and events should be accessed using a specific protocol. This document defines protocol mappings for Bluetooth Low Energy and Zigbee, and the mechanism can be extended to other protocols such as HTTP and CoAP. This document also describes a method to extend SCIM with an SDF model mapping. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References

Acknowledgements This specification is based on work by the One Data Model group.

Contributors DONG-EUI University

176 Eomgwangno Busan_jin_gu Busan 47340 South Korea +82 51 890 1993 joosang.youn@gmail.com

Daejeon University

62 Daehak-ro, Dong-gu Daejeon 34520 South Korea +82 42 280 4841 yonggeun.hong@gmail.com