Abstract
A digital twin is a virtual representation of a physical object, process, or system. It is a computerized model that simulates the behavior of a real-world object or system in real-time, providing a detailed and accurate reflection of its physical counterpart.
A digital twin is created by collecting data from various sources, such as sensors, cameras, and other IoT devices, and processing that data using machine learning algorithms and other analytical tools. The resulting model can monitor, analyze, and optimize the physical system’s performance and predict future behavior and outcomes.
Digital twins are commonly used in manufacturing, aerospace, and energy industries. They can be used to simulate the operation of complex machinery, equipment, and systems and identify potential issues or inefficiencies before they occur in the real world. They are also used in building design and construction to optimize performance, maintenance, and energy efficiency.
A digital twin is composed of two main steps:
-
development phase, pre-production (aka pre-prod)
-
deployment and update phase in production (aka post-prod)
Pre-prod digital twin
Looking at the lifecycle development of a solution that involves embedded software components (a car, a manufacturing line, etc..) utilizing QNX, many variants of Linux, Android, and even IOS when a user phone is involved, a developer implementing a new feature does not have the actual environment available as a cloud developer has a Development Environment, aka DEV, to do the implementation and QA for testing the compliance of the implementation. To remediate this problem, a simulation of the environment has to be created. This is where the need for a pre-prod digital twin is emerging.
Adopting modern development solutions and creating an environment in the cloud is a natural solution for such simulation. And because in a cloud environment, the resource is virtualized and generally pooled using Kubernetes orchestrator, a natural consequence is to containerize every simulation component. The developer implementing a new feature must dynamically deploy images and containers using Kubernetes.
This will work well assuming two following conditions:
-
Any legacy software that runs in an actual environment needs to be containerized.
-
The simulation in the cloud environment must closely mimic the actual environment.
These two conditions are difficult to realize since, in the actual environment for embedded systems, the usage of real-time operating systems is frequent, and containerizing legacy components has limitations when dealing with user interfaces and multi-processes within the same container. This means that once QA is passed in the cloud, transferring the new feature to the actual environment generally leads to new problems, making the whole cloud testing obsolete.
Another approach to creating a pre-prod digital twin is replicating the actual environment in the cloud. For that, it is often necessary to run an RTOS like QNX. However, as most of the container technologies (e.g., docker) depend on Operation System’s functions (e.g., c-group), it is not possible to run these containers on QNX. This is why there is a need for a technology that provides a run-time independent from the operating system. And this is what mimik edgeEngine provides.
Running QNX in the cloud and mimik edgeEngine on top of QNX in the cloud allows a developer to implement microservices or function-as-a-service. It is possible to have a seamless transition from the pre-prod digital twin to the actual environment.
Post-prod digital twin
Once the feature is deployed in real systems, it is essential to have a feedback loop to refine the simulation. It allows developers and system analysts to understand the behavior of the actual system and how these behaviors match the behavior of the simulated environment. And this is where a post-prod digital twin needs to be created.
One solution is to use the pre-prod digital twin instance to implement the post-prod digital twin. However, this implies the need to transfer a large amount of data to replicate in the cloud the context of the actual environment. This can be a source of many problems:
-
Cost: the more data to be transferred, the more cost will be generated, either the cost of transport or the cost of processing, in particular, if it is to deal with low-level signals.
-
Power consumption: it generally consumes more power to transmit data to a network than to process data locally and transmit results.
-
Privacy: in some cases, the data to be transmitted is about the user and, therefore, transmitted data to the cloud may be breaching privacy regulation
One solution is to split the pre-prod digital twin into two parts, one part running in that existing system and the other as a consolidation in the cloud since one aspect of running in the cloud is to deal with multiple actual systems (e.g., cars) and therefore avoid bias when extracting a generic behavior.
Technology is needed to allow microservices to run in any environment (regular OS. real-time OS, main CPU, controllers) to do the pre-analysis and send smart signals to an aggregated simulation running in the cloud. And this is what mimik edgeEngine and its different editions (standard, main/child, controller/worker) provide.