ASDF H. Lee, Ed. Internet-Draft J. Hong Intended status: Informational ETRI Expires: 17 April 2027 14 October 2026 Semantic Definition Format (SDF) Modeling for Digital Twin draft-ietf-asdf-digital-twin-06 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Lee & Hong Expires 17 April 2027 [Page 1] Internet-Draft SDF modeling for digital twin October 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SDF structure for digital twin . . . . . . . . . . . . . . . 3 4. Motivation and design rationale . . . . . . . . . . . . . . . 5 4.1. Introduction to sdfContext . . . . . . . . . . . . . . . 5 4.2. Digital twin modeling using SDF elements . . . . . . . . 5 4.3. Relationship modeling . . . . . . . . . . . . . . . . . . 6 5. Protocol considerations for digital twin realization . . . . 9 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Supported protocol types . . . . . . . . . . . . . . . . 9 5.3. Protocol binding in SDF . . . . . . . . . . . . . . . . . 10 5.4. QoS considerations . . . . . . . . . . . . . . . . . . . 11 5.5. Security and access considerations . . . . . . . . . . . 11 5.6. Implementation guidelines . . . . . . . . . . . . . . . . 12 6. Digital twin system in various domains . . . . . . . . . . . 12 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Marine system . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Healthcare system . . . . . . . . . . . . . . . . . . . . 16 6.4. Smart building system . . . . . . . . . . . . . . . . . . 18 6.5. Smart network system . . . . . . . . . . . . . . . . . . 23 7. Requirements for implementing digital twins . . . . . . . . . 27 8. Procedure for digital twin implementation . . . . . . . . . . 28 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 32 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Lee & Hong Expires 17 April 2027 [Page 2] Internet-Draft SDF modeling for digital twin October 2026 1. 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[Y.4600]. 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 [RFC9880] 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. 2. Terminology This specification uses the terminology specified in [RFC9880], 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. 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 Figure 1, following the guidelines of [ISO23247-3]. 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. Lee & Hong Expires 17 April 2027 [Page 3] Internet-Draft SDF modeling for digital twin October 2026 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. +---------------------------------------------+ - - - - - - - - - - - | Application sublayer | | +----------+ +------+ +--------+ +--------+ | | | Human | | HMI | | Apps | | Peers | | | +----------+ +------+ +--------+ +--------+ | +---------------------------------------------+ | Digital twin sublayer | | +----------+ +-------------+ +------------+ | | | Operation| | Application | | Resource | | | | and | | and | | access and | | | |management| | service | |interchange | | | +----------+ +-------------+ +------------+ | | +-----------------------------------------+ | Digital twin layer | | Digital representation | | | | +-------------+ +----------------+ | | | | | Affordance | | Non-affordance | | | | | | objects | | objects | | | | | +-------------+ +----------------+ | | | +-----------------------------------------+ | +---------------------------------------------+ | Device communication sublayer | | +-------------+ +----------------+ | | | Data | | Object | | | | collection | | control | | | +-------------+ +----------------+ | +---------------------------------------------+ - - - - - - - - - - - | +-------------+ +----------------+ | | | Affordance | | sdfContext | | | | objects | | objects | | Physical layer | +-------------+ +----------------+ | +---------------------------------------------+ - - - - - - - - - - - Figure 1: Basic Architecture of digital twin Lee & Hong Expires 17 April 2027 [Page 4] Internet-Draft SDF modeling for digital twin October 2026 4. Motivation and design rationale The document is based on the underlying structure defined in [RFC9880], 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 [ISO23247-3] often have to describe virtual representations of various physical objects, including metadata, identity, contextual relationships, historical data, as well as device interfaces. 4.1. Introduction to sdfContext The sdfContext keyword defined in [I-D.draft-ietf-asdf-sdf-nonaffordance] 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. 4.2. 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 Table 1. Lee & Hong Expires 17 April 2027 [Page 5] Internet-Draft SDF modeling for digital twin October 2026 +================+==============+==================================+ | Attribute | Recommended | Description | | | Mapping | | +================+==============+==================================+ | Identifier | sdfContext | Globally unique digital twin ID | | | | (e.g., URN) | +----------------+--------------+----------------------------------+ | Characteristic | sdfProperty | General description or domain | | | or sdfData | properties | +----------------+--------------+----------------------------------+ | Schedule | sdfEvent or | Time-based actions, | | | sdfData | availability, or maintenance | +----------------+--------------+----------------------------------+ | Status | sdfAction or | Actual or calculated operating | | | sdfProperty | 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 | +----------------+--------------+----------------------------------+ Table 1: Digital twin modeling using elements of SDF model 4.3. Relationship modeling The sdfRelation, defined in [I-D.draft-laari-asdf-relations], 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") Lee & Hong Expires 17 April 2027 [Page 6] Internet-Draft SDF modeling for digital twin October 2026 * Semantic relations (e.g., "similar to", "same as") The sdfRelation definition can include the following fields as defined in [I-D.draft-laari-asdf-relations]: * relType: Specifies the type of relationship and may refer to a term defined in an external ontology (e.g., SAREF[saref4bldg]). * 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 Figure 2. The sdfProtocolMap in this example is described in [I-D.draft-ietf-asdf-nipc] and [I-D.draft-ietf-asdf-sdf-protocol-mapping] Lee & Hong Expires 17 April 2027 [Page 7] Internet-Draft SDF modeling for digital twin October 2026 { "namespace": { "saref": "https://saref.etsi.org/core/" }, "sdfThing": { "Room001": { "description": "Contains lightbulb and thermostat", "sdfObject": { "lightbulb": { "description": "A smart lightbulb", "sdfProperty": { "adjacent-node": { "type": "object", "sdfType": "link", "sdfProtocolMap": { "ble": { "serviceID": "361c9c4f-22d7-4a1e-824b-8b61045a566a", "characteristicID": "b7adf665-37c7-44be-8e1c-651a10573613" } } } }, "sdfRelation": { "sameRoomAsThermostat": { "relType": "saref:isLocatedIn", "target": "#/sdfThing/Room001/sdfObject/thermostat", "description": "This lightbulb is located in the same room as the thermostat.", "label": "Located together" } } }, "thermostat": { "description": "A thermostat is in the same room as the lightbulb", "sdfProperty": { "adjacent-node": { "type": "object", "sdfType": "link" } } } } } } } Figure 2: An example of sdfRelation Lee & Hong Expires 17 April 2027 [Page 8] Internet-Draft SDF modeling for digital twin October 2026 5. Protocol considerations for digital twin realization 5.1. 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 [I-D.draft-ietf-asdf-sdf-protocol-mapping]. 5.2. 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. Table 2 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. +============+=============================+========================+ | Protocol / | Role in digital twin | Characteristics | | technology | | | +============+=============================+========================+ | MQTT | Sensor data | Lightweight, publish- | | | publishing, event | subscribe, suitable | | | reporting | for IoT | +------------+-----------------------------+------------------------+ | CoAP | Access to constrained | Compact REST-like | | | devices | communication and | | | | observe/notify support | +------------+-----------------------------+------------------------+ | BLE | Local data exchange | Low energy, short | | | and control for | range communication | | | wearables or embedded | using services and | | | devices | characteristics | +------------+-----------------------------+------------------------+ | Zigbee | Sensor data access, | Uses endpoints, | | | event reporting, and | clusters, attributes, | | | device control | and commands | +------------+-----------------------------+------------------------+ | Matter | Interoperable device | IP-based application | | | monitoring and | layer using device | | | control, particularly | types, endpoints, | | | for smart-home and | clusters, attributes, | Lee & Hong Expires 17 April 2027 [Page 9] Internet-Draft SDF modeling for digital twin October 2026 | | smart-building devices | commands and events | +------------+-----------------------------+------------------------+ | BACnet | Building automation | Widely used for | | | and HVAC monitoring/ | building automation | | | control | systems and exposes | | | | building-device | | | | objects and properties | +------------+-----------------------------+------------------------+ | KNX | Building control such | Widely deployed home | | | as lighting, shading, | and building control | | | and room automation | technology | +------------+-----------------------------+------------------------+ | HTTP/REST | Enterprise integration | Widely supported | | | and cloud API | application interfaces | | | | with comparatively | | | | higher overhead | +------------+-----------------------------+------------------------+ | WebSocket | Bi-directional low- | Useful for state | | | latency updates | synchronization and | | | | real-time commands | +------------+-----------------------------+------------------------+ | NIPC | Standardized control | Applicable to | | | of non-IP devices | industrial, legacy and | | | | isolated device | | | | environments | +------------+-----------------------------+------------------------+ Table 2: Example protocols and ecosystem technologies for digital twin realization 5.3. 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 Figure 3. Lee & Hong Expires 17 April 2027 [Page 10] Internet-Draft SDF modeling for digital twin October 2026 { "sdfProperty": { "temperature": { "type": "number", "unit": "Cel", "sdfProtocolMap": { "ble": { "serviceID": "00001809-0000-1000-8000-00805f9b34fb", "characteristicID": "00002a1c-0000-1000-8000-00805f9b34fb" } } } } } Figure 3: An example of protocol binding 5.4. 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 Table 3. +===========+============================+=======================+ | 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 | +-----------+----------------------------+-----------------------+ Table 3: Example MQTT QoS levels and recommended usage 5.5. 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 Lee & Hong Expires 17 April 2027 [Page 11] Internet-Draft SDF modeling for digital twin October 2026 according to the security policy of the digital twin system. 5.6. 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. 6. Digital twin system in various domains 6.1. 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. 6.2. Marine system Table 4 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 Lee & Hong Expires 17 April 2027 [Page 12] Internet-Draft SDF modeling for digital twin October 2026 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. Lee & Hong Expires 17 April 2027 [Page 13] Internet-Draft SDF modeling for digital twin October 2026 +============================+=============+=======================+ | 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 | +----------------------------+-------------+-----------------------+ Table 4: Components and SDF elements of a marine system In the context of Boat007, shown in Figure 4, 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. { "namespace": { "exrel": "https://example.com/sdf-relations#" }, "sdfThing": { "boat007": { "label": "Boat #007", "description": "Digital twin of a vessel with heater and battery subsystems", Lee & Hong Expires 17 April 2027 [Page 14] Internet-Draft SDF modeling for digital twin October 2026 "sdfContext": { "vesselId": { "type": "string", "const": "boat007" }, "homePort": { "type": "string", "const": "port007" } }, "sdfObject": { "heater1": { "sdfProperty": { "status": { "type": "boolean" }, "temperature": { "type": "number", "unit": "Cel" } }, "sdfAction": { "turnOn": { "description": "Activate the heater" }, "turnOff": { "description": "Deactivate the heater" } }, "sdfContext": { "manufacturer": { "type": "string", "const": "HeaterTech Inc." }, "model": { "type": "string", "const": "HEATER-2025-V1" } }, "sdfRelation": { "temperatureControl": { "target": "#/sdfThing/boat007/sdfObject/thermostat1", "relType": "exrel:regulatedBy" } } }, "thermostat1": { "sdfProperty": { "setPoint": { "type": "number", "unit": "Cel" }, "mode": { "type": "string" } } }, "batterySensor1": { "sdfProperty": { "chargeLevel": { "type": "number", "unit": "percent" }, "voltage": { "type": "number", "unit": "V" } }, "sdfRelation": { "batteryToController": { "target": "#/sdfThing/boat007/sdfObject/powerController1", "relType": "exrel:connectedTo" } } }, "powerController1": { "sdfAction": { "connect": { "description": "Connect battery power" }, "disconnect": { "description": "Disconnect battery power" } } Lee & Hong Expires 17 April 2027 [Page 15] Internet-Draft SDF modeling for digital twin October 2026 } } } } } Figure 4: An example of marine system 6.3. 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 Table 5. +=================+=============+===================================+ | Attribute | SDF element | Properties | +=================+=============+===================================+ | Patient | sdfThing | patientMonitor001 as a digital | | monitor | | twin | +-----------------+-------------+-----------------------------------+ | ECG module | sdfObject | heartRate, rhythmType | +-----------------+-------------+-----------------------------------+ | Infusion | sdfObject | flowRate, volumeRemaining | | pump | | | +-----------------+-------------+-----------------------------------+ | Alert system | sdfObject | highHeartRateAlert | +-----------------+-------------+-----------------------------------+ | Context | sdfContext | wardLocation, patientID, | | information | | manufacturer, model, serialNumber | +-----------------+-------------+-----------------------------------+ | Relationship | sdfRelation | ECG to alertSystem (relType: | | | | monitoredBy) | +-----------------+-------------+-----------------------------------+ Table 5: Components and SDF elements of a healthcare system A digital twin example of a patient monitoring system with ECG and infusion pump components is illustrated in Figure 5. 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. Lee & Hong Expires 17 April 2027 [Page 16] Internet-Draft SDF modeling for digital twin October 2026 { "namespace": { "exrel": "https://example.com/sdf-relations#" }, "sdfThing": { "patientMonitor001": { "sdfContext": { "wardLocation": { "type": "string", "const": "ICU-5A" }, "patientID": { "type": "string", "const": "PT123456" }, "manufacturer": { "type": "string", "const": "MediTech" }, "model": { "type": "string", "const": "IM-500" }, "serialNumber": { "type": "string", "const": "MT-IM500-00789" } }, "sdfObject": { "ecg": { "sdfProperty": { "heartRate": { "type": "number", "unit": "1/min" }, "rhythmType": { "type": "string" } }, "sdfRelation": { "monitoredByAlertSystem": { "target": "#/sdfThing/patientMonitor001/sdfObject/alertSystem", "relType": "exrel:monitoredBy" } } }, "infusionPump": { "sdfProperty": { "flowRate": { "type": "number", "unit": "mL/h" }, "volumeRemaining": { "type": "number", "unit": "mL" } } }, "alertSystem": { "sdfEvent": { "highHeartRateAlert": { "description": "Raised when the monitoring application detects a high heart rate" } } } } } } } Figure 5: An example of healthcare Lee & Hong Expires 17 April 2027 [Page 17] Internet-Draft SDF modeling for digital twin October 2026 6.4. 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 [Matter], BACnet-based HVAC [BACnet], KNX-based shading [KNX], 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 Table 6. 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. Lee & Hong Expires 17 April 2027 [Page 18] Internet-Draft SDF modeling for digital twin October 2026 +===============+=============+================================+ | Building | SDF element | Example information | | component | | | +===============+=============+================================+ | Building | sdfThing | building001 containing room | | digital twin | | and subsystem objects | +---------------+-------------+--------------------------------+ | Lighting | sdfObject | powerState, brightness, | | system | | setBrightness; implemented | | | | with Matter | +---------------+-------------+--------------------------------+ | HVAC system | sdfObject | temperatureSetPoint, | | | | operatingMode, setTemperature; | | | | implemented with BACnet | +---------------+-------------+--------------------------------+ | Shading | sdfObject | blindPosition, | | system | | setBlindPosition; implemented | | | | with KNX | +---------------+-------------+--------------------------------+ | Environmental | sdfObject | temperature, CO2 | | sensor | | concentration; implemented | | | | with CoAP | +---------------+-------------+--------------------------------+ | Energy meter | sdfObject | powerConsumption; implemented | | | | with MQTT | +---------------+-------------+--------------------------------+ | Building | sdfContext | buildingUse, roomNumber, | | context | | floor, zone | +---------------+-------------+--------------------------------+ | Relationships | sdfRelation | locatedIn, controlsClimateOf, | | | | measuresPowerOf | +---------------+-------------+--------------------------------+ Table 6: Components and SDF elements of a smart building system Figure 6 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. Lee & Hong Expires 17 April 2027 [Page 19] Internet-Draft SDF modeling for digital twin October 2026 { "namespace": { "exrel": "https://example.com/sdf-relations#" }, "sdfThing": { "building001": { "description": "Digital twin of a heterogeneous smart building", "sdfContext": { "buildingUse": { "type": "string", "const": "office" } }, "sdfObject": { "room101": { "sdfContext": { "roomNumber": { "type": "string", "const": "101" }, "floor": { "type": "integer", "const": 1 }, "zone": { "type": "string", "const": "eastWing" } } }, "lightingSystem": { "description": "Lighting system implemented with Matter", "sdfProperty": { "powerState": { "type": "boolean" }, "brightness": { "type": "integer", "unit": "percent" } }, "sdfAction": { "setBrightness": { "sdfInputData": { Lee & Hong Expires 17 April 2027 [Page 20] Internet-Draft SDF modeling for digital twin October 2026 "type": "integer", "unit": "percent" } } }, "sdfRelation": { "installedInRoom": { "target": "#/sdfThing/building001/sdfObject/room101", "relType": "exrel:locatedIn" } } }, "hvacSystem": { "description": "HVAC system implemented with BACnet", "sdfProperty": { "temperatureSetPoint": { "type": "number", "unit": "Cel" }, "operatingMode": { "type": "string" } }, "sdfAction": { "setTemperature": { "sdfInputData": { "type": "number", "unit": "Cel" } } }, "sdfRelation": { "controlsRoom": { "target": "#/sdfThing/building001/sdfObject/room101", "relType": "exrel:controlsClimateOf" } } }, "shadingSystem": { "description": "Shading system implemented with KNX", "sdfProperty": { "blindPosition": { "type": "integer", "unit": "percent", "minimum": 0, "maximum": 100, Lee & Hong Expires 17 April 2027 [Page 21] Internet-Draft SDF modeling for digital twin October 2026 "description": "Current blind position" } }, "sdfAction": { "setBlindPosition": { "description": "Sets the blind position", "sdfInputData": { "type": "integer", "unit": "percent", "minimum": 0, "maximum": 100 } } }, "sdfRelation": { "installedInRoom": { "target": "#/sdfThing/building001/sdfObject/room101", "relType": "exrel:locatedIn" } } }, "environmentSensor": { "description": "Environmental sensor implemented with CoAP", "sdfProperty": { "temperature": { "type": "number", "unit": "Cel" }, "co2Concentration": { "type": "number", "unit": "ppm" } }, "sdfRelation": { "sensorLocation": { "target": "#/sdfThing/building001/sdfObject/room101", "relType": "exrel:locatedIn" } } }, "energyMeter": { "description": "Energy meter implemented with MQTT", "sdfProperty": { "powerConsumption": { "type": "number", "unit": "W" Lee & Hong Expires 17 April 2027 [Page 22] Internet-Draft SDF modeling for digital twin October 2026 } }, "sdfRelation": { "measuresHVAC": { "target": "#/sdfThing/building001/sdfObject/hvacSystem", "relType": "exrel:measuresPowerOf" } } } } } } } Figure 6: An example of a heterogeneous smart building system 6.5. 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 Table 7. Lee & Hong Expires 17 April 2027 [Page 23] Internet-Draft SDF modeling for digital twin October 2026 +=================+=============+==================================+ | Attribute | SDF element | Example information | +=================+=============+==================================+ | Smart network | sdfThing | smartNetwork001 containing the | | system | | network-device and traffic twins | +-----------------+-------------+----------------------------------+ | Network-device | sdfObject | device identifier, operational | | twin | | state, utilization, latency | +-----------------+-------------+----------------------------------+ | Traffic twin | sdfObject | current traffic, traffic | | | | history, traffic pattern | +-----------------+-------------+----------------------------------+ | Current traffic | sdfProperty | currentTraffic, packetRate | | information | | | +-----------------+-------------+----------------------------------+ | Twin | sdfRelation | association of the traffic twin | | association | | with the network-device twin | +-----------------+-------------+----------------------------------+ | Prediction | sdfProperty | anomalyScore, | | result | / sdfEvent | abnormalSituationPredicted | +-----------------+-------------+----------------------------------+ | Countermeasure | sdfAction | applyCountermeasure for a | | interface | | predicted abnormal situation | +-----------------+-------------+----------------------------------+ Table 7: Components and SDF elements of a smart network system Figure 7 shows the conceptual processing sequence. The procedure is intentionally described at an architectural level; this document does not standardize a prediction algorithm. Lee & Hong Expires 17 April 2027 [Page 24] Internet-Draft SDF modeling for digital twin October 2026 +-----------------------------------------------------------+ | Obtain traffic information for a network device | +-----------------------------------------------------------+ | v +-----------------------------------------------------------+ | Generate a network-device twin and a traffic twin | +-----------------------------------------------------------+ | v +-----------------------------------------------------------+ | Synchronize current traffic information with traffic twin| +-----------------------------------------------------------+ | v +-----------------------------------------------------------+ | Train a model using state represented by synchronized | | digital twins | +-----------------------------------------------------------+ | v +-----------------------------------------------------------+ | Obtain current traffic and predict an abnormal situation | +-----------------------------------------------------------+ | v +-----------------------------------------------------------+ | If abnormal, determine and expose a countermeasure | +-----------------------------------------------------------+ Figure 7: Digital twin-based prediction and response procedure for a smart network system Figure 8 provides an SDF representation of the entities and interfaces used by the example. { "namespace": { "exrel": "https://example.com/sdf-relations#" }, "sdfThing": { "smartNetwork001": { "description": "Digital twin system for abnormal-situation prediction and response", "sdfObject": { "networkDeviceTwin": { "sdfContext": { "deviceId": { "type": "string", "const": "network-device-001" } }, Lee & Hong Expires 17 April 2027 [Page 25] Internet-Draft SDF modeling for digital twin October 2026 "sdfProperty": { "operationalState": { "type": "string" }, "utilization": { "type": "number", "unit": "percent" }, "latency": { "type": "number", "unit": "ms" } } }, "trafficTwin": { "sdfProperty": { "currentTraffic": { "type": "number", "unit": "Mbit/s" }, "packetRate": { "type": "number", "unit": "1/s" }, "anomalyScore": { "type": "number", "minimum": 0, "maximum": 1 } }, "sdfData": { "trafficHistory": { "type": "array" }, "trafficPattern": { "type": "string" } }, "sdfEvent": { "abnormalSituationPredicted": { "description": "Indicates that the analytics function predicts an abnormal situation" } }, "sdfAction": { "applyCountermeasure": { "description": "Applies a countermeasure selected by an application", "sdfInputData": { "type": "object", "properties": { "countermeasureId": { "type": "string" } } } } }, "sdfRelation": { "associatedNetworkDevice": { "target": "#/sdfThing/smartNetwork001/sdfObject/networkDeviceTwin", "relType": "exrel:associatedWith" } } } } } } } Figure 8: An example of a smart network system Lee & Hong Expires 17 April 2027 [Page 26] Internet-Draft SDF modeling for digital twin October 2026 7. 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 [ISO23247-1]. * *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. Lee & Hong Expires 17 April 2027 [Page 27] Internet-Draft SDF modeling for digital twin October 2026 * *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. 8. Procedure for digital twin implementation 8.1. 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; Lee & Hong Expires 17 April 2027 [Page 28] Internet-Draft SDF modeling for digital twin October 2026 * 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. 8.2. 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. Lee & Hong Expires 17 April 2027 [Page 29] Internet-Draft SDF modeling for digital twin October 2026 * *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. Lee & Hong Expires 17 April 2027 [Page 30] Internet-Draft SDF modeling for digital twin October 2026 * *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. 9. 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. 10. IANA Considerations This document has no IANA actions. 11. References 11.1. Normative References [I-D.draft-ietf-asdf-nipc] Brinckman, B., Mohan, R., and B. Sanford, "An Application Layer Interface for Non-IP device control (NIPC)", Work in Progress, Internet-Draft, I-D.draft-ietf-asdf-nipc-13, 20 September 2025, . [I-D.draft-ietf-asdf-sdf-nonaffordance] Hong, J. and H. Lee, "Semantic Definition Format (SDF) Extension for Non-Affordance Information", Work in Progress, Internet-Draft, I-D.draft-ietf-asdf-sdf- nonaffordance-05, 16 September 2026, . Lee & Hong Expires 17 April 2027 [Page 31] Internet-Draft SDF modeling for digital twin October 2026 [I-D.draft-ietf-asdf-sdf-protocol-mapping] Mohan, R., Brinckman, B., and L. Corneo, "SDF Protocol Mapping", Work in Progress, Internet-Draft, I-D.draft- ietf-asdf-sdf-protocol-mapping-11, 27 August 2026, . [I-D.draft-laari-asdf-relations] Laari, P., "Extended relation information for Semantic Definition Format (SDF)", Work in Progress, Internet- Draft, I-D.draft-laari-asdf-relations-04, 28 January 2025, . [ISO23247-1] "Automation systems and integration Digital twin framework for manufacturing - Part 1: Overview and general principles, ISO 23247-1.", October 2021, . [ISO23247-3] "Automation systems and integration Digital twin framework for manufacturing - Part 3: Digital representation of manufacturing elements, ISO 23247-3.", October 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9880] Koster, M., Bormann, C., and A. Keränen, "Semantic Definition Format (SDF) for Data and Interactions of Things", BCP 14, RFC 9880, DOI 10.17487/RFC9880, January 2026, . [Y.4600] Union, I. T., ""Recommendation ITU-T Y.4600 (2022), Requirements and capabilities of a digital twin system for smart cities.", August 2022. 11.2. Informative References Lee & Hong Expires 17 April 2027 [Page 32] Internet-Draft SDF modeling for digital twin October 2026 [BACnet] ASHRAE, "ANSI/ASHRAE Standard 135-2024: BACnet - A Data Communication Protocol for Building Automation and Control Networks", 2024. [KNX] ISO/IEC, "ISO/IEC 14543-3: Information technology - Home electronic system (HES) architecture - Part 3". [Matter] Alliance, C. S., "Matter Core Specification, Version 1.4", November 2024. [saref4bldg] Poveda-Villaln, M. and R. Garcia-Castro, "SAREF extension for building", 5 June 2020, . Acknowledgements This specification is based on work by the One Data Model group. Contributors Joo-Sang Youn DONG-EUI University 176 Eomgwangno Busan_jin_gu Busan 47340 South Korea Phone: +82 51 890 1993 Email: joosang.youn@gmail.com Yong-Geun Hong Daejeon University 62 Daehak-ro, Dong-gu Daejeon 34520 South Korea Phone: +82 42 280 4841 Email: yonggeun.hong@gmail.com Authors' Addresses Lee & Hong Expires 17 April 2027 [Page 33] Internet-Draft SDF modeling for digital twin October 2026 Hyunjeong Lee (editor) Electronics and Telecommunications Research Institute 218 Gajeong-ro, Yuseong-gu Daejeon 34129 South Korea Phone: +82 42 860 1213 Email: hjlee294@etri.re.kr Jungha Hong Electronics and Telecommunications Research Institute 218 Gajeong-ro, Yuseong-gu Daejeon 34129 South Korea Phone: +82 42 860 0926 Email: jhong@etri.re.kr Lee & Hong Expires 17 April 2027 [Page 34]