Open karkob91 opened 1 month ago
Regarding the terminology: https://ieeexplore.ieee.org/document/9103025
Quotes from the paper:
Some ideas:
Thanks for your concerns, we will include this topic in the next discussion and keep you updated.
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®.
The current description of this BB is currently here
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 ?
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
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.
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)
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.
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) ?
Contact Details
karol.kobiela@verum.com
Layer
AppLayer
Functional Cluster
FC Virtualization
BB name
Digital Twin
Problem Description
Wrong Functional Cluster, discuss better one