[BB Bug]: Digital Twin in wrong Functional Cluster

[karkob91]

Contact Details

karol.kobiela@verum.com

Layer

AppLayer

Functional Cluster

FC Virtualization

BB name

Digital Twin

Problem Description

Wrong Functional Cluster, discuss better one

[bastilam]

Regarding the terminology: https://ieeexplore.ieee.org/document/9103025

Quotes from the paper:

• digital model: A digital model is described as a digital version of a pre-existing or planned physical object, to correctly define a digital model there is to be no automatic data exchange between the physical model and digital model.
• digital shadow: A digital shadow is a digital representation of an object that has a one-way flow between the physical and digital object. A change in the state of the physical object leads to a change in the digital object and not vice versus.
• digital twin: If the data flows between an existing physical object and a digital object, and they are fully integrated in both directions, this constituted the reference “Digital Twin”. A change made to the physical object automatically leads to a change in the digital object and vice versa.

[bastilam]

Some ideas:

• digital models may be placed under BB-MU | Building Block Mockup Unit (In-Vehicle / On-Board Component) or BB-CSC | Building Block Cloud Stack Component (Cloud / Off-Board) depending on the system they model. They can be understood as a (functional) digital mockup unit. "A digital mockup is the digital description of a product" (source) and a functional digital mockup extends a digital mockup with a model of the product's behavior (source). Since mock up units / digital models could also be understood as Engineering & Support Tools, there is some ambiguity in their categorization.
• digital shadows may be placed under BB-SC | Building Block Stack Component (In-Vehicle / On-Board) if they run in the vehicle or under BB-CSC | Building Block Cloud Stack Component (Cloud / Off-Board) if they run in the cloud / off-board. Alternatively, the distinction could be made based on the nature of the component they are shadowing, rather than their operational environment.
• digital twins may also be placed under BB-SC | Building Block Stack Component (In-Vehicle / On-Board) if they run in the vehicle or under BB-CSC | Building Block Cloud Stack Component (Cloud / Off-Board) if they run in the cloud / off-board. Similar to digital shadows, the distinction could be made based on the nature of the component they are a twin of, rather than their operational environment.

[LS0205]

Thanks for your concerns, we will include this topic in the next discussion and keep you updated.

[madri2]

Here is another source for Digital Twins: from the Digital Twin Consortium

Quotes from their definition:

Digital Twin Consortium Definition

Below, please find the Consortium’s digital twin definition:

A digital twin is a virtual representation of real-world entities and processes, synchronized at a specified frequency and fidelity.

• Digital twin systems transform business by accelerating holistic understanding, optimal decision-making, and effective action.

• Digital twins use real-time and historical data to represent the past and present and simulate predicted futures.

• Digital twins are motivated by outcomes, tailored to use cases, powered by integration, built on data, guided by domain knowledge, and implemented in IT/OT systems.

The foundational elements of the definition are captured in the first sentence: the virtual representation, the real-world entities and processes it represents, and the mechanism by which the virtual and real-world entities are synchronized.

Source: https://www.digitaltwinconsortium.org/2020/12/digital-twin-consortium-defines-digital-twin/ Digital Twin Consortium is part of the Object Management Group®.

[prillerp]

The current description of this BB is currently here

1. we suggest to add the definition of the Digital Twin Consortium as mentioned by Mario to the BB description, as it represents the consolidated view of many in the industry. -> Lukas
2. we need to add this definition to the glossary (which by itself should be hosted on GitHub). The glossary is currently in deliverable D2.x --> Mario
3. we ask the author of this BB (Conti - @Phil0046 ) to refine its requirements. Then we can decide if it's a
   • digital twin
   • digital model
   • digital shadow

[Phil0046]

There is mistake in definition as a BB-SC element of the Middleware. This Building Block as Digital Twin (correct definition) shall be place in the Cloud (BB-CSC). @madri2 Il propose to delete this BB-SC or to move it in BB-CSC. Are you OK ?

[karkob91]

There is mistake in definition as a BB-SC element of the Middleware. This Building Block as Digital Twin (correct definition) shall be place in the Cloud (BB-CSC). @madri2 Il propose to delete this BB-SC or to move it in BB-CSC. Are you OK ?

I can't agree with categorizing the Digital Twin (or model) as a cloud element. For the purpose of Shift2SDV, the digital twin or model (depending on whom you ask) should have the ability to generate target code, which would be directly placed in the Middleware. For example, we can create a formal model of business logic that can be easily simulated in various environments (including the cloud), but in the end, we generate code that represents the exact implementation/behavior of the model or digital twin. The same applies to Matlab/Simulink when generating target code using the Embedded Coder Toolbox

[Phil0046]

From Continental perspective it is a mistake for a MW service embedded in the vehicle for related vehicle control. The initial proposal what in the mindset of digital twins in cloud. By the way, if you generate vehicle control code from your model (Matlab/Simulink embedded coder the service used to generate the code is a tool block and not a middleware vehicle embedded service, as you may decide offline that you model is ready as it has been validated (usually in the cloud, but code can be a code shadown embedded in the vehicle, where also off line you will make the decision to replace another control code as the new active one). The service used to make this code active by applying patch in embedded vehcile software will be performed throught OTA reproraming service, in order to master and security sign what is the real software embedded in the vehicle. If the code is an apps to be uploaded in the "protected non safety part of the vehicle", may be a different use case, mastering of the software active is still required and OTA reprog services shall also be used (to garantee overall control of software uploaded). But may be you have a different view (or use case) and to my eyes the naming "digital twins" missleading and shall be improved.

[prillerp]

Status from WP2 meeting on 29-AUG-2024: Philippe (Conti) and Karol (Verum) both will provide definition for DigitalTwin. If this leads to two sperate BB's, we will create them and attach definitions; otherwise it will be merged into the existing one (currently in MW layer)

[karkob91]

From Continental perspective it is a mistake for a MW service embedded in the vehicle for related vehicle control. The initial proposal what in the mindset of digital twins in cloud. By the way, if you generate vehicle control code from your model (Matlab/Simulink embedded coder the service used to generate the code is a tool block and not a middleware vehicle embedded service, as you may decide offline that you model is ready as it has been validated (usually in the cloud, but code can be a code shadown embedded in the vehicle, where also off line you will make the decision to replace another control code as the new active one). The service used to make this code active by applying patch in embedded vehcile software will be performed throught OTA reproraming service, in order to master and security sign what is the real software embedded in the vehicle. If the code is an apps to be uploaded in the "protected non safety part of the vehicle", may be a different use case, mastering of the software active is still required and OTA reprog services shall also be used (to garantee overall control of software uploaded). But may be you have a different view (or use case) and to my eyes the naming "digital twins" missleading and shall be improved.

From my perspective, the Digital Twin within the "G1: Digital Twin for vECU" building block in Shift2SDV is a part of the software development environment. In this context, the Digital Twin can act as a platform-agnostic model that implements requirements and specifications. It can then be used for verification and validation activities, testing, running complex simulations (HIL, SIL, CPU emulation, middleware integration), and all shift-left activities. Ultimately, this Digital Twin serves as the source of the target code, which can be deployed via OTA update services.

In the context of Shift2SDV, our plan is to offer a cloud-based environment for Digital Twin-driven development. While it aligns with cloud-based development practices, I’m uncertain if it fits neatly into any specific cloud category BB.

[Phil0046]

Hi Karol I do agree with your definition for a Cloud based environment with set of services to build and execute a Digital-Twin model. My proposal for as Digital Twin (proxy) BB was very narrow, others services would be required that would be detailed in Shift2SDV. So my proposal would be to rename the actual BB from BB-SC-TC as "Digital Twin proxy in Cloud" and to move it to BB-CMU category.

But it shall be aligned with Shift2DV forecoming project. Does this new proposal fit Shift2DV BB definition plan ? Shall this "proxy" BB be embedded to broader BB from BB-CMU that you already defined in Shift2SDV (and that embeds proxy features) ?

[LS0205]

was taken care of in #28