12.22 Link Binding in Digital Twins and Edge/Fog Computing

12.22.1 Description

In a smart manufacturing use case in emerging Industry 4.0 and/or Industrial Internet, physical domain and cyber domain are connected via Internet technologies toward industrial Cyber-Physical Systems. Various sensors and actuators will be installed and/or attached to physical parts, machines, and devices in the physical domain so that their status and information will be effectively collected to the cyber domain or the Internet. On the other hand, reverse control commands may be issued from the cyber domain to a single physical part, machines, and/or devices. Smart manufacturing in general aims to render the manufacturing process more efficient, autonomous, and smart by leveraging Internet of Things (IoT) and the convergence of Information Technology (IT) and Operation Technology (OT) in product lifecycle, which could include four phases (i.e. conceive, design, realize, and service). For example, in the 'realize' phase, the product will be manufactured in a factory, sold to the customer, and delivered to the customer in sequential steps. The efficiency of those phases can be greatly improved based on IoT; for instance, IoT allows to collect more complete and timely information about a sold product and customer feedback during "service" phase, which in turn can feed to "realize" phase in a real-time fashion to eventually improve manufacturing efficiency.

To exploit the full range of benefits from smart manufacturing, the concept "digital twins" has been proposed. Basically, digital twins refer to digital or virtual companions of physical products; digital twins use collected data from sensors installed on physical products to represent their near real-time status, working condition, and/or other information. Through digital twins, a physical product can be monitored, managed, and maintained remotely and even more efficiently without sending any technician to check the product physically. Digital twins actually necessitate link binding and resulted automatic content synchronization from physical products to their digital twins or vice versa, for example:

• Scenario 1: In order to create digital twins in the cyber domain, the status of the physical product in each phase of its lifecycle needs to be monitored and connected. Then, a link binding between physical products (i.e. source resource) in the physical domain and their digital twins (i.e. destination source) in the cyber domain can be established to enable automatic content synchronization from sensors of a physical product to its digital twins.
• Scenario 2: some maintenance commands need to be automatically transferred from digital twins to the corresponding physical products; in this case, a link binding will be created between digital twins (i.e. source resource) and physical products (i.e. destination resource).

12.22.2 Source

REQ-2018-0030-Link_Binding_Management_in_Digital_Twins_and_Edge_Fog_Computing

12.22.3 Actors

• Source Resource Host (SRH): A logical entity which hosts source resources (e.g., an oneM2M CSE). A fog/edge node (e.g., a vehicle in physical domain) could be a SRH (or a DRH).
• Destination Resource Host (DRH): A logical entity which hosts destination resources (e.g., an oneM2M CSE). A cloud node (e.g., a server in cyber domain) could be a DRH (or a SRH).
• Link Binding Coordinator (LBC): A logical entity or a management application which manages link bindings between source resources and destination resources (e.g. to discover source resources and destination resources, to formulate appropriate link bindings, to create a link binding and set attributes of a binding entry, to update a link binding by changing the attributes of a binding entry, and to cancel a link binding, etc.). An oneM2M AE or CSE could be a LBC.
• Resource Creator (RC): A logical entity which creates source resources at a SRH or destination resources at a DRH. An oneM2M AE or CSE could be a RC.

12.22.4 Pre-conditions

• There are various products in physical domain and/or at the network edge, which act as a SRH for sending data to digital twins (or a DRH for receiving commands from digital twins).
• The physical product has an embedded service platform. There is an physical product application as a RC in physical product (or physical domain) to create resources about the physical product in the embedded service platform. The physical product application usually resides at the network edge.
• Each physical product has its digital twin in cyber domain and/or in the cloud, which act as a DRH for collecting data from physical products (or a SRH for sending commands to physical products).
• The digital twin of a physical prodct maintain resources for the physical product.
• There is a management application as LBC to manage link bindings between physical products and their corresponding digital twins in cyber domain. The management application can be residing in the cloud.

12.22.5 Triggers

• New physical products are introduced and their digital twins are created. The management application as LBC establish link bindings between new physical products and their digital twins.

12.22.6 Normal Flow

Figure 12.22.6-1 illustrates the normal flow for link binding management for the scenario where physical products play as SRH to report data to their digital twins as DRH. Note that the similar flow can be applied to the case when digital twins play as SRH to send commands to physical products as DRH.

1. Step 1: The physical product application as a RC creates source resources at the SRH. In the meantime, the RC provides binding support in this process along two aspects: 1) The RC can indicate certain binding hints for the resource to be created. The binding hints could be the binding role of the resource (i.e. source resource, or destination resource), the type of the resource to be bound to, binding attributes the resource can support, etc. Such binding hints could be provided to the RC via a user interface or previsioned to the RC. 2) The RC can also create link binding in this step. In other words, the RC creates new resources and new link bindings simultaneously. For example, when creating a source resource at the SRH, the RC can provide the destination resource and binding attributes to the SRH and accordingly create a link binding from the resource to be created to the destination resource at the SRH (i.e. for Push mode).
2. Step 2: The management application as a LBC discovers appropriate resources (i.e. source resources and destination resources) from the DRH and the SRH. The LBC will provide new filters related to link binding such as link binding role (i.e. source resource or destination resource), binding attributes which the resource to be discovered can support, etc. Based on those new filters, more appropriate resources for link binding will be identified and returned from the DRH/SRH to the LBC. Before discovering any resource, the LBC basically does not know if a resource host maintains source resources, destination resources, or both. It just simply issues a resource discovery request to a resource host; the resource discovery request will indicate whether it intends to search source resources or destination resources.
3. Step 3: The LBC triggers to create a link binding at the DRH for Poll/Observe mode or at the SRH for Push mode. In either case, the LBC instructs both the DRH and the SRH to be aware of each other's context information and binding attributes of the created link binding. Alternatively, the SRH can initiate to send a request to the DRH to create the link binding for Poll/Observe mode and similarly the DRH can initiate to send a request to the SRH to create the link binding for Push mode.
4. Step 4: Based on the created link binding in Step 3, binding-aware content synchronization will be repeatedly conducted from the SRH to the DRH. In Poll/Observe mode, the DRH will send RETIREVE/GET messages to the SRH (and accordingly a response message to GET will be sent from the SRH to the DRH), while UPDATE/PUT messages will be sent from the SRH to the DRH for Push mode (and accordingly a response message to PUT will be sent from the DRH to the SRH). In either case, link binding indicator such as binding attributes can be contained in GET or PUT messages so that the SRH or the DRH knows that the corresponding context exchange is not an ordinary one-time content exchange, but repeatable content synchronization due to a link binding. As such, both the SRH and the DRH are aware of binding attributes during content synchronization and in turn can be better prepared (e.g. adjust its sleep schedule) for content synchronization in the future. Being aware of binding attributes, the SRH (or the DRH) can also authenticate whether each received GET message (or PUT message) satisfies the conditions as specified in binding attributes.
5. Step 5: An established link binding can be updated by the LBC, the DRH, or the SRH. Link binding update can be triggered under various conditions. For example, the LBC may update the link binding with a more frequent content synchronization. The source resource or the destination resource involved in the link binding can also be changed to a new resource.
6. Step 6: An established link binding can be suspended by the LBC, the DRH, or the SRH. Link binding suspension can be triggered under various conditions. For example, the DRH under Push mode may request to halt a link binding at the SRH when it is too overloaded to receive any future PUT messages from the SRH; similarly, the SRH under Pull mode may request to pause a link binding at the DRH when it aims to reduce energy consumption by stopping receiving future GET messages from the DRH.
7. Step 7: A halted link binding can be restored or resumed after certain time by the LBC, the DRH, or the SRH. Link binding restoration can be triggered under various conditions. For example, the DRH under Push mode may request to resume the halted link binding at the SRH when it becomes underloaded and able to receive PUT messages from the SRH; similarly, the SRH under Pull mode may request to resume the halted link binding at the DRH.
8. Step 8: An existing link binding may be removed by the LBC, the DRH, or the SRH for various scenarios. For example, the LBC may just simply cancel the link binding and disable the content synchronization; in this case, both the source resource and the destination resource are still kept. In another example, when the source resource becomes unavailable, the link binding is actually invalid and needs to be removed accordingly.

Figure 12.22.6-1 Normal Flow - Link Binding Management

12.22.7 Alternative Flow

None

12.22.8 Post-conditions

• After appropriate link bindings are established between a physical product and its digital twin, they automatically exchange data and command accordindg to the established link bindings.

12.22.9 High Level Illustration

Figure 12.22.9-1 High Level Illustration - Link Binding in Digital Twins

12.22.10 Potential requirements

1. The oneM2M System shall enable methods to identify resource link-binding roles, such as source resource and destination resource.
2. The oneM2M System shall enable the link binding between a source resource and a destination resource.
3. The oneM2M System shall enable to create link bindings between a source resource and a destination resource.
4. The oneM2M System shall enable to update link bindings between a source resource and a destination resource.
5. The oneM2M System shall enable to cancel link bindings between a source resource and a destination resource.