Semantic Definition Format (SDF) Modeling for Digital Twin

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.¶

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")¶

• 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]¶

{
  "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"
            }
          }
        }
      }
    }
  }
}

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.¶

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.¶

{
 "sdfProperty": {
   "temperature": {
     "type": "number",
     "unit": "Cel",
     "sdfProtocolMap": {
       "ble": {
         "serviceID": "00001809-0000-1000-8000-00805f9b34fb",
         "characteristicID": "00002a1c-0000-1000-8000-00805f9b34fb"
       }
     }
   }
 }
}

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.¶

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 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.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 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.¶

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",
      "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" }
          }
        }
      }
    }
  }
}

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.¶

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.¶

{
  "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"
            }
          }
        }
      }
    }
  }
}

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.¶

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.¶

{
  "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": {
                "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,
              "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"
            }
          },
          "sdfRelation": {
            "measuresHVAC": {
              "target": "#/sdfThing/building001/sdfObject/hvacSystem",
              "relType": "exrel:measuresPowerOf"
            }
          }
        }

      }
    }
  }
}

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.¶

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

+-----------------------------------------------------------+
| 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 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" }
          },
          "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"
            }
          }
        }
      }
    }
  }
}

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;¶

• 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.¶

• 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.¶

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, <https://datatracker.ietf.org/doc/html/I-D.draft-ietf-asdf-nipc-13>.

[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, <https://datatracker.ietf.org/doc/html/I-D.draft-ietf-asdf-sdf-nonaffordance-05>.

[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, <https://datatracker.ietf.org/doc/html/I-D.draft-ietf-asdf-sdf-protocol-mapping-11>.

[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, <https://datatracker.ietf.org/doc/html/I-D.draft-laari-asdf-relations-04>.

[ISO23247-1]

"Automation systems and integration Digital twin framework for manufacturing - Part 1: Overview and general principles, ISO 23247-1.", October 2021, <https://www.iso.org/standard/75066.html>.

[ISO23247-3]

"Automation systems and integration Digital twin framework for manufacturing - Part 3: Digital representation of manufacturing elements, ISO 23247-3.", October 2021, <https://www.iso.org/standard/78744.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[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, <https://www.rfc-editor.org/rfc/rfc9880>.

[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

[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, <https://saref.etsi.org/saref4bldg>.