Digital Twin

Introduction:

Digital Twin in an automotive industry comprises of detailed and dynamically updated virtual replica of the vehicle with its software, mechanics, electrical and electronic network etc. This
twin view of the vehicle is made to monitor the behaviour and performance of the vehicle as well as to test different scenarios thereby predicting the issues and optimising the
performance of the vehicle.

Objective of Implementing Digital Twin in SUMO:

The main objective is to create a Digital twin backbone which will have the replica of E&E network architecture along with ECU modelling in a hierarchical manner that captures the
hardware & software inter-dependencies of all the ECUs present.

The DT will be a backbone which will host rest all SUMO platform components.

This Digital Twin backbone will mainly serve below mentioned purposes-

1. To perform Over the Air software updates for the vehicles.

2. To map aggregate performances of different vehicle domains/components, their usage and there by improve functionality.
3. To have overall database in place for all the vehicle data that could be further used for Remote Diagnostics and Software Updates .

Architecture of Digital Twin:

DT Platform Components:
 Sr.No. Platform Component Functional Description

1 TCM Data Is the data sent by the vehicle such as vehicle, telemetry data, software version information, Calibration Part No,
Calibration version, FOTA Update State, Basic SW number, Basic SW version, Parameterization /CCID no,
Assembly Number.

2 VSOH The above TCM data is sent via the VSOH message. The VSOH message is a MQTT message currently used for
FOTA and is triggered on Ignition ON.

3 Layer3 IOT Platform: It is the interface between the vehicle and server and contains the message queue. This layer also
contains the APIs to communicate with the device/vehicle.

4 Layer 4 External API Platform: It is the current frontend for web based applications and also has S3 buckets to store data.

5 DT Interface API The data received from VSOH and the data from other DB are received and formatted to a cypher friendly format.

6 Cypher API The API to convert the TCM and DB data to cyphers for executing the respective operations(create/merge/update)
on the graph DB.

7 EOL RDB This database contains the static vehicle parameters like VIN, VC, vehicle variant, ECU sw versions if any at that
point of time.

8 CRM DB Customer and Purchase details is available in this database and is use to track Vehicle Purchase and Owner status.

9 Battery Data This data is available in s3 bucket of layer 4 and contains battery parameters collected by the BMS( Battery
management system) from different vehicles.

10 Vehicle Graph (Graph DB) This graph contains the vehicle specific information and relationship between the components.

11 ECU Graph ( Graph DB) This is a high-level graph that contains all the ECUs applicable for a FOTA.

12 SW/Variant Graph ( Graph DB) This graph contains the vehicle configuration for all possible variants; the ECUs available for each variant and their
respective software and hardware configuration.

13 Conventional DB Relational or Non-Relational DB which will contain static data.

14 Cloud Storage To store intermediate data, log files, binaries, software files and dumps.

15 View Graph Data (UI/UX) Query the data from vehicle graph, ECU graph and SW graph and display the same in a user-friendly format.

16 ECU Modelling Interface (UI/UX) Interface to input the ECU related information for the Graph DB.

User Stories :

Story No. User Type User Stories Priority Use Sequen Interfac SRD Respon Depend Story Comme
Case ce e sible encies Consum nt
Defined Defined Squad er
 Diagram
Defined
DT_REQ_00 CoC As a COC Engineer, I want to view the profile High Frontend Platform
1 Engineer of ECUs I am responsible for Engineeri
ng users

DT_REQ_00 CoC As a COC Engineer, I want to create a new High Frontend Platform
2 Engineer ECU Profile and model hardware profile for Engineeri
that ECU ng users