edgeEngine Main-Child Edition
The edgeEngine Main-Child edition is specially developed for Heterogeneous Compute Platforms (HCP) such as TI-TDA4VM, TI-DRA829V, or TI-DRA821U. Along with other unique capabilities, the edgeEngine Main-Child edition provides a unique ability to dynamically execute microservices on R5F microcontrollers (MCUs). We describe edgeEngine capabilities corresponding to different layers of TI-TDA4VM hardware and software platform as the following:
The Cortex-A72 microprocessor, which is a main and high-end processor, supports multiple operating systems and full-fledged multi-threaded applications that support unrestricted access to network, memory, and storage facilities. The Cortex-R5F MCUs, which are smaller Co-processor(s) do not have this capability. However, Arm Cortex-R5F subsystems, enable low-level, timing critical processing tasks that leave the Arm Cortex-A72’s unencumbered for applications.
Cortex-A72 MPUs have access to the hardware (HW) file system to execute data read/write (R/W), but Cortex-R5F MCUs don’t have access to this file system.
When we use TDA4VM HCP with mimik’s “edgeEngine Main-Child edition”, the “edgeEngine-Main” is installed on the “TI-Linux” operating system, and multiple instances of “edgeEngine-Child” can be installed on top of each TI-RTOS.
Using the edgeEngine Main-Child architecture, you can create a homogeneous runtime environment that lets you deploy microservices dynamically on both A72 and R5F compute platforms. The flexibility to install edgeEngine on the TDA4VM platform allows the developer to install and enable edgeEngine on any R5F MCUs.
Each MCU can only run one instance of “edgeEngine-Child.” For example, the TDA4VM platform with 6 R5F MCUs can run up to six instances of “edgeEngine-Child” on each R5F microcontroller; however, mimik provides the option to keep several MCUs without any edgeEngine-Child and run any legacy code on those MCUs.
Edge microservices can run on both MPUs and MCUs and are accessible by a process (either through a monolithic app or another edge microservice running on the board) or externally through an API.
All edge microservices implement a set of APIs that can communicate with other edge microservices that run either on the “Main node” or other “Child nodes” through the API gateway.
As with other edgeEngine-enabled devices, all edge-microservices are packaged in the form of a “bytecode program” that runs on top of a WebAssembly (WASM) runtime with a small footprint, high performance, and highly configurable features for applications across embedded, IoT, edge to Trusted Execution Environment (TEE), smart contract, cloud-native, and so on.
Considering that edgeEngine is a serverless environment for WASM runtime, when there is an API call, the corresponding microservice responds; otherwise, it remains in idle mode, which results in power savings for the platform.
All edge microservices Implement a set of APIs, and they can communicate with other edge microservices that run either on the “Main node” or other “Child nodes” through the API gateway.
This way of deployment allows developers to create an isolated runtime environment on top of each R5F core. Each instance of the “edgeEngine-Child” runtime can only run one microservice on top in the form of “WASM Runtime.”
Each bytecode running on top of a WASM runtime can be updated remotely through the “edgeEngine-Main” instance. edgeEngine provides APIs for deploying a WASM runtime as well as starting, stopping, or even deleting it once deployed.
Because that edgeEngine is a serverless environment for WASM runtime, when there is an API call, the corresponding microservice responds; otherwise, it remains in idle mode, which results in power savings for the platform.
All edge microservices Implement a set of APIs that can communicate with other edge microservices that run either on the “Main node” or other “Child nodes” by way of API gateway.
All processes that run on “Child nodes” behave as concurrent processes (or respond to multiple API calls at the same time) since the API gateway running on the “Main node” can handle the communication through the serialization of the API calls.
There are many use cases in the automotive industry, robotics, drones, agritech, health, AI/ML, etc. that can benefit from these unique capabilities.
Please let us know if you have a cloud native application development or transformation project in progress and need some help. Our expert engineers can provide you with architecture and development support.