TECHNICAL POST
Pre-prod digital twin
Looking at the lifecycle development of a solution that involves embedded software components (a car, a manufacturing line, etc..), a developer implementing a new feature does not have the actual environment available as a cloud developer has 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 are natural solutions 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 the two conditions:
Any legacy software that runs in an actual environment needs to be containerized.
The actual environment has to be close to what is being simulated in the cloud.
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 microservice (aka Function-as-a-Service), and 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 and allows developer and system analysts to understand the behaviour of the actual system and how these behaviours match the behaviour 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 for 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 spilt the pre-prod digital twin in 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 behaviour.
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.
