- Introduction
- Architecture
- DTDL
- In-Vehicle Digital Twin Service
- Sample Digital Twin Interactions
- Appendix: Digital Twin Interface
Project Eclipse Ibeji delivers an In-Vehicle software component that provides a digital representation of vehicle hardware resources. The representation is usable by other software in the vehicle to monitor and control vehicle hardware resources in a standardized manner.
Please note that the initial Ibeji implementation is a proof-of-concept. We would like to see it evolve into an enterprise class solution.
Ibeji has three main architectural concepts:
- Digital Twin Consumer
- Digital Twin Provider
- In-Vehicle Digital Twin Service
The first Ibeji architectural concept that we will introduce is the Digital Twin Consumer. A Digital Twin Consumer is a software entity that utilizes Ibeji to interface with the digital representation of the In-Vehicle hardware components.
Another Ibeji architectural concept is the Digital Twin Provider. A Digital Twin Provider is the access point to some/all of the vehicle's hardware resources. A Digital Twin Provider registers itself with the In-Vehicle Digital Twin Service. Once registered, the In-Vehicle Digital Twin Service can make the resources available to Digital Twin Consumers. Each resource includes metadata so that Digital Twin Consumers know how to interact with it. The In-Vehicle Digital Twin Service supports multiple simultaneous Digital Twin Providers and accommodates overlapping resources offered by multiple Digital Twin Providers. These overlaps offer multiple options for interacting with a resource and can improve the resource's availability (by supporting multiple access paths).
The final architectural concept is the In-Vehicle Digital Twin Service. It has an interface that enables Digital Twin Consumers to discover the vehicle's resources and provides the details necessary to interact with those resources. The In-Vehicle Digital Twin Service has an interface that allows Digital Twin Providers to dynamically register their resources.
Below is the architectural diagram for Ibeji.
Fundamental to the Ibeji solution is its use of Digital Twin Definition Language DTDL to identify and specify each of the vehicle's resources. We are using Version 3 of DTDL.
This initial contribution does not try to arrange the resources into a hierarchy or into a graph. It is expected that some future version will facilitate this.
DTDL can identify and specify each of the resources. Below is an example of a HVAC resource.
{
"@context": ["dtmi:dtdl:context;3"],
"@type": "Interface",
"@id": "dtmi:sdv:HVAC;1",
"description": "Heat, Ventilation and Air Conditioning",
"contents": [
{
"@type": "Property",
"@id": "dtmi:sdv:HVAC:AmbientAirTemperature;1",
"name": "AmbientAirTemperature",
"description": "The immediate surroundings air temperature (in Fahrenheit).",
"schema": "integer"
},
{
"@type": "Property",
"@id": "dtmi:sdv:HVAC:IsAirConditioningActive;1",
"name": "IsAirConditioningActive",
"description": "Is air conditioning active?",
"schema": "boolean"
}
]
}
The sequence diagram for the Register activity is shown below.
The sequence diagram for the Find-By-Id activity is shown below.
The sequence diagram for a Digital Twin Consumer using the Get operation is shown below.
The sequence diagram for a Digital Twin Consumer using the Set operation is shown below.
The sequence diagram for a Digital Twin Consumer using the Subscribe operation is shown below.
The sequence diagram for a Digital Twin Consumer using the Invoke operation is shown below.
The sequence diagram for a Digital Twin Consumer using the Stream operation is shown below.
Find an entity's access information.
- entity_id - The entity's id.
- entity_access_info - The entity's access information.
Register one or more entities access information.
- entity_access_info_list - A list of entity access information.
- No response.