<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.26 (Ruby 2.6.3) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>

<?rfc docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-lee-asdf-digital-twin-07" category="std" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="SDF modeling for digital twin">Semantic Definition Format (SDF) modeling for Digital Twin</title>
    <seriesInfo name="Internet-Draft" value="draft-lee-asdf-digital-twin-07"/>

    <author fullname="Hyunjeong Lee" role="editor" initials="H." surname="Lee">
        <organization abbrev="ETRI">Electronics and Telecommunications Research Institute</organization>
        <address>
            <postal>
                <street>218 Gajeong-ro, Yuseong-gu</street>
                <city>Daejeon</city>
                <region></region>
                <code>34129</code>
                <country>South Korea</country>
            </postal>
            <phone>+82 42 860 1213</phone>
            <email>hjlee294@etri.re.kr</email>
        </address>
    </author>
    <author fullname="Jungha Hong" initials="J." surname="Hong">
      <organization abbrev="ETRI">Electronics and Telecommunications Research Institute</organization>
      <address>
          <postal>
              <street>218 Gajeong-ro, Yuseong-gu</street>
              <city>Daejeon</city>
              <region></region>
              <code>34129</code>
              <country>South Korea</country>
          </postal>
          <phone>+82 42 860 0926</phone>
          <email>jhong@etri.re.kr</email>
      </address>
    </author>
    <author fullname="Joo-Sang Youn" initials="J-S" surname="Youn">
		<organization abbrev="Dong-eui Univ">DONG-EUI University</organization>
      	<address>
        	<postal>
	          	<street>176 Eomgwangno Busan_jin_gu</street>
    	      	<city>Busan</city>
        	  	<region></region>
	       		<code>47340</code>
    	      	<country>South Korea</country>
        	</postal>
        	<phone>+82 51 890 1993</phone>
        	<email>joosang.youn@gmail.com</email>
      	</address>
    </author>
    <author fullname="Yong-Geun Hong" initials="Y-G" surname="Hong">
        <organization>Daejeon University</organization>
        <address>
            <postal>
                <street>62 Daehak-ro, Dong-gu</street>
                <street></street>
                <city>Daejeon</city>
                <region></region>
                <code>34520</code>
                <country>South Korea</country>
            </postal>
            <phone>+82 42 280 4841</phone>
            <email>yonggeun.hong@gmail.com</email>
        </address>
  </author>

  <area>ART</area>
  <workgroup>ASDF</workgroup>
  <keyword>Internet-Draft</keyword>
  <abstract>
    <t>This memo specifies SDF modeling for a digital twin,
      i.e. a digital twin system, and its 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 a digital twin that contain Things as components.
      </t>
  </abstract>
</front>

<middle>
    <!--section 1-->
    <section title="Introduction">
      <t>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. <xref target="Y.4600"/>.
        Digital twin 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.
	     </t>

      <t>Nowadays, digital twin technologies are applied in various domains including manufacturing, energy, medical, farm, transportation, etc.
		  And a common format is needed to represent the objects in the domains as digital twins.
		  SDF <xref target="I-D.ietf-asdf-sdf"/> can be used for modeling objects as digital twins.
      </t>
      <t>This document specifies the modeling and guidance on how to use SDF to represent objects as digital twins.
		  </t>
    </section>
     <!--section 1-->

     <!--section 2-->
    <section anchor="terminology">
      <name>Terminology</name>
      <t>This specification uses the terminology specified in <xref target="I-D.ietf-asdf-sdf"/> in particular "Class Name Keyword", "Object", and "Affordance".</t>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
      "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
      "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <!--section 2-->

    <!--section 3-->
    <section title="SDF structure for digital twin">
      <t>This section describes SDF structure with the new Class Name Keyword, sdfNonAffordance, 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 <xref target="basic-arch-fig" format="default"/>,
        , following the guidelines of <xref target="ISO23247-3"/>.</t>

      <t>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,
                facilitating informed decision-making.
      </t>

        			<figure anchor="basic-arch-fig">
        				<name>Basic Architecture of digital twin</name>
        				<artwork align="center" name="" type="" alt=""><![CDATA[
        +---------------------------------------------+ - - - - - - - - - - -
        |            Application Sublayer             |
        | +----------+ +------+ +--------+ +--------+ |
        | |  Human   | | HMI  | |  Apps  | |  Peers | |
        | +----------+ +------+ +--------+ +--------+ |
        +---------------------------------------------+
        |           Digital Twin Sublayer             |
        | +----------+ +-------------+ +------------+ |
        | | Operation| | Application | | Resource   | |
        | |    and   | |     and     | | access and | |
        | |management| |   service   | |interchange | |
        | +----------+ +-------------+ +------------+ |
        | +-----------------------------------------+ |  Digital twin Layer
        | |     Digital representation of objects   | |
        | |   +-------------+   +----------------+  | |
        | |   |  Affordance |   | Non-Affordance |  | |
        | |   |   objects   |   |    objects     |  | |
        | |   +-------------+   +----------------+  | |
        | +-----------------------------------------+ |
        +---------------------------------------------+
        |        Device Communication Sublayer        |
        |     +-------------+   +----------------+    |
        |     |    Data     |   |     Object     |    |
        |     | collection  |   |     control    |    |
        |     +-------------+   +----------------+    |
        +---------------------------------------------+ - - - - - - - - - - -
        |     +-------------+   +----------------+    |
        |     |  Affordance |   | Non-Affordance |    |
        |     |   objects   |   |    objects     |    |     Physical Layer
        |     +-------------+   +----------------+    |
        +---------------------------------------------+ - - - - - - - - - - -
        				]]></artwork>
        			</figure>

    </section> <!--section 3-->

    <!--section 4-->
    <section title="New Elements for Digital Twin">
      <t>The SDF language uses six Class Name Keywords, and sdfNonAffordance is added as a new Class Name Keyword for digital twin.</t>
      <t>The information attributes for digital twin are defined in <xref target="ISO23247-3"/>.
      Some of them, for example characteristics and status, can be described using existing Class Name Keywords.
      And the others, for example location, can be described using sdfNonAffordance.
      </t>

      <t>The mapping information attributes of digital twin to qualities of sdfThing are shown in <xref target="digitaltwin2sdfthingqual"/>.
      It is required to define a new quality in sdfThing in order to express the properties of digital twins such as location.
      </t>

      <table anchor="digitaltwin2sdfthingqual">
        <name>Mapping Information Attributes of Digital Twin to Qualities of sdfThing</name>
        <thead>
          <tr>
            <th align="left">Information</th>
            <th align="left">Quality</th>
            <th align="left">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">Idetifier</td>
            <td align="left"> </td>
            <td align="left">A value used to uniquely identify a sdfThing / sdfObject</td>
          </tr>
          <tr>
            <td align="left">Characteristic</td>
            <td align="left">sdfProperty</td>
            <td align="left">A typical or noticeable feature of a sdfThing / sdfObject</td>
          </tr>
          <tr>
            <td align="left">Schedule</td>
            <td align="left">sdfEvent</td>
            <td align="left">Time information bound to a sdfThing / sdfObject</td>
          </tr>
          <tr>
            <td align="left">Status</td>
            <td align="left">sdfAction</td>
            <td align="left">A condition of a sdfThing / sdfObject</td>
          </tr>
          <tr>
            <td align="left">Location</td>
            <td align="left"> </td>
            <td align="left">Geographical or relative location information of a sdfThing / sdfObject</td>
          </tr>
          <tr>
            <td align="left">Report</td>
            <td align="left">sdfData</td>
            <td align="left">Description of activities done by or onto a sdfThing / sdfObject</td>
          </tr>
          <tr>
            <td align="left">Relationship</td>
            <td align="left"><xref target="I-D.ietf-laari-asdf-relations"/></td>
            <td align="left">Connection information between two or more sdfThings / sdfObjects</td>
          </tr>
        </tbody>
      </table>

        <figure anchor="example1">
          <name>An example of SDF mapping for digital twin</name>
          <sourcecode>
            {
              "info": {
                "title": "An example of the heater #1 in the boat #007",
                "version": "2025-01-27",
                "copyright": "Copyright 2025. All rights reserved.",
              },
              "namespace": {
                "heater1": "https://example.com/heater1"
              },
              "defaultNamespace": "heater1",
              "sdfThing": {
                "boat": {
                  "description" : "A boat including heater1",
                  "sdfProperty": {
                      "status": {
                          "description": "The status of the boat #007 ; false for stop and true for move."
                          "sdfRef": "#/sdfProproperty/status"
                      }
                    },
                    "sdfObject": {
                      "heater1": {
                          identifier: {
                            "UUID": { "a2e06d16-df2c-4618-aacd-490985a3f763" }
                          }
                          location:{
                              "wgs84": {
                                "latitude": "35.2988233791372",
                                "longitude": "129.25478376484913",
                                "altitude": "0.0"
                              },
                              "postal": {
                                "city": "Ulsan",
                                "post-code": "44110",
                                "country": "South Korea"
                              },
                              "w3w": {
                                "what3words":"toggle.mopped.garages"
                              }
                          }
                          "sdfData" : {
                            report: {
                                "On February 24, 2025, the boat #007's heater #1 was on from 9 a.m. to 6 p.m."
                              }
                            }
                        }
                    }
                  }
                }
              }
          </sourcecode>
        </figure>
    </section>  <!--section 4-->


    <!--section 5-->
  <section anchor="requirements-digital twin">
    <name>Requirements for digital twin</name>
    <section anchor="overview">
      <name>Overview</name>
      <t>A digital twin is a partial representation of sdfThing or sdfObject that contains attributes such as sdfProperty, sdfAction and sdfEvent<xref target="ISO23247-1"/>.
      By representing sdfThing as a digital twin, crucial events that require appropriate action can be quickly detected and controlled.
       The requirements defined in <xref target="ISO23247-1"/> are applied to represent sdfThings and sdfObjects as digital twins.</t>
    </section>

    <section anchor="data acquisition">
      <name>Data acquisition</name>
      <t>Data related to sdfThing and sdfObject, such as sdfProperty, sdfEvent, and sdfAction, should be collected from IP and non-IP devices.</t>
    </section>
    <section anchor="data analysis">
      <name>Data analysis</name>
      <t>The collected data needs to be analyzed to understand the state of sdfThing and sdfObject.</t>
    </section>
    <section anchor="identification">
      <name>Identification</name>
      <t>The sdfThings and sdfObjects should contain data that uniquely identifies them as digital twins.</t>
    </section>
    <section anchor="accuracy">
      <name>Accuracy</name>
      <t>The sdfThings and sdfObjects should be represented as digital twins with appropriate levels of detail and accuracy,
        depending on the application.</t>
    </section>
    <section anchor="synchronization">
      <name>Synchronization</name>
      <t>The sdfThings and sdfObjects should be synchronized with their digital twins in real-time as appropriate for the application.
        Newly added or removed sdfThings and sdfObjects should be recognized and reflected in the digital twin.</t>
    </section>

  </section> <!--section 5-->

    <!--section 6 -->
    <section anchor="procedure-for-digital twin">
          <name>Procedures for digital twin</name>
          <t>
            A procedure for representing sdfThing, as a digital twin in a domain is as follows:</t>
          <t>
        <list style="symbols">
          <t>defining a purpose for expressing the observable object, as known as a physical asset or an object of interest, as a digital twin in the domain</t>
          <t>organizing data based on the roles of the observable object in the domain</t>
          <t>configuring the observable object into the digital twin based on the data for the purposes</t>
          <t>interworking with a digital twin of each of other domains in which the observable object performs a different role</t>
          <t>synchronizing the observable object and the digital twin</t>
        </list>
          </t>
  </section>
  <!--section 6 -->

   <!--section 7-->
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Only authorized users should have the authority to manage sdfThings and sdfObjects. </t>
    </section> <!--section 7-->

    <!--section 8-->
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section> <!--section 8-->
  </middle>

  <back>
  <!--section 9-->
  <references title='Normative References'>
        <reference anchor='Y.4600'>
            <front>
                <title>"Recommendation ITU-T Y.4600 (2022), Requirements and capabilities of a digital twin system for smart cities.</title>
                <author fullname="International Telecommunication Union"/>
                <date month="August" year="2022"/>
            </front>
        </reference>

        <!--&id.draft-ietf-asdf-sdf;-->
        <reference anchor='I-D.ietf-asdf-sdf'>
          <front>
            <title>Semantic Definition Format (SDF) for Data and Interactions of Things</title>
            <author fullname="Michael Koster" initials="M." surname="Koster">
              <organization>KTC Control AB</organization>
            </author>
            <author fullname="Carsten Bormann" initials="C." surname="Bormann">
              <organization>Universität Bremen TZI</organization>
            </author>
            <author fullname="Ari Keränen" initials="A." surname="Keränen">
              <organization>Ericsson</organization>
            </author>
            <date day="17" month="March" year="2025"/>
            <abstract>
              <t>The Semantic Definition Format (SDF) is concerned with Things, namely
                 physical objects that are available for interaction over a network.
                 SDF is a format for domain experts to use in the creation and
                 maintenance of data and interaction models that describe Things.  An
                 SDF specification describes definitions of SDF Objects/SDF Things and
                 their associated interactions (Events, Actions, 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.

              </t>
            </abstract>
          </front>
          <seriesInfo name='Internet-Draft' value='draft-ietf-asdf-sdf-23'/>
        </reference>

      <!--  &id.draft-laari-asdf-relations;-->
      <reference anchor='I-D.ietf-laari-asdf-relations'>
        <front>
          <title>Extended relation information for Semantic Definition Format (SDF)</title>
          <author fullname='	Petri' initials='P.' surname='Laari'>
            <organization>Ericsson</organization>
          </author>

          <date day='28' month='January' year='2025'/>
          <abstract>
            <t>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.
            </t>
          </abstract>
        </front>
        <seriesInfo name='Internet-Draft' value='I-D.ietf-laari-asdf-relations-04'/>
      </reference>


      <reference anchor='ISO23247-1' target='https://www.iso.org/standard/75066.html'>
        <front>
            <title>Automation systems and integration Digital twin framework for manufacturing - Part 1: Overview and general principles, ISO 23247-1.</title>
              <author fullname='ISO' initials='' surname=''>
                </author>
              <date month='October' year='2021'/>
        </front>
      </reference>

      <reference anchor='ISO23247-3' target='https://www.iso.org/standard/78744.html'>
        <front>
            <title>Automation systems and integration Digital twin framework for manufacturing - Part 3: Digital representation of manufacturing elements, ISO 23247-3.</title>
              <author fullname='ISO' initials='' surname=''>
                </author>
              <date month='October' year='2021'/>
        </front>
      </reference>


        <reference anchor='RFC2119'>
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname='S. Bradner' initials='S.' surname='Bradner'/>
            <date month='March' year='1997'/>
            <abstract>
              <t>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.
              </t>
            </abstract>
          </front>
          <seriesInfo name='BCP' value='14'/>
          <seriesInfo name='RFC' value='2119'/>
          <seriesInfo name='DOI' value='10.17487/RFC2119'/>
        </reference>
        <reference anchor='RFC8174'>
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname='B. Leiba' initials='B.' surname='Leiba'/>
            <date month='May' year='2017'/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name='BCP' value='14'/>
          <seriesInfo name='RFC' value='8174'/>
          <seriesInfo name='DOI' value='10.17487/RFC8174'/>
         </reference>

  </references>
  <references title='Informative References'>
        <reference anchor='saref4bldg' target='https://saref.etsi.org/saref4bldg'>
            <front>
                <title>SAREF extension for building</title>
                <author initials='M.' surname='Poveda-Villaln' fullname='Mara Poveda-Villaln'/>
                <author initials='R.' surname='Garcia-Castro' fullname='Ral Garcia-Castro'/>
                <date year='2020' month='June' day="05"/>
            </front>
        </reference>
   </references>
  </back>
</rfc>
