ZAYA μContainers are containers for resource-constraint small&MM-Less Microcontrollers and user, security and deployment friendly environments for IoT Device developments.
ZAYA μContainers offer rich features like Rich Operating System Containers such as Linux Containers.
1. Hardware Virtualisation
ZAYA offers hardware virtualisation for the user-space executables, so ZAYA Containers do not need to know the platform or hardware details; implementations in ZAYA μContainer are platform agnostic.
ZAYA Containers initialise neither Microcontroller core, any HW Peripherals nor Kernel. When a ZAYA μContainer starts, the system is already initialised and up&running, so ZAYA μContainer is ready to go for the custom implementation; it makes the container a portable implementation even between different architecture (e.g. Arm, RISC-V)
Hardware Virtualisation offers a flexible environment, and even another RTOS can be run in a ZAYA μContainer; RTOSes need a thin porting (Hardware Abstraction) layer to manage its internal resources so the developer can implement a tiny porting layer to run another RTOS in a ZAYA μContainer.
2. Run-Time Isolation Limitation of Traditional RTOSes: Due to lack of isolation hardware’s such as Memory Management Unit(MMU) on the microcontrollers, there is no isolation between, Kernel and User Applications(s) and code can access all address range of the device. Herein, when an application is malfunctioned (e.g. Code Injection), can get control of the whole IoT Device, including secrets (e.g. crypto keys) of other modules; it is the most critical security leak at the moment for the IoT Edge devices.
ZAYA Containers make use of ZAYA Secure Kernel’s Process Isolation mechanisms to run in an isolated space; any user-space executable cannot access the ZAYA μContainer address space.
ZAYA μContainer Isolation is a security and safety mechanism; - Security; A malicious user application or container cannot violate any other ZAYA μContainer’s sensitive information. In case of an attempt, ZAYA Secure Kernel terminates the violent execution. - Safety; A malfunctioned user application or container cannot break any other ZAYA μContainer; in case of an attempt, Kernel terminates the malfunctioned execution and Kernel continues to run the ZAYA μContainer.
If the ZAYA μContainer itself somehow malfunctioned, it cannot interfere or violate any other user executable or Kernel Space too. In case of an attempt, the ZAYA Secure Kerne terminates the ZAYA μContainer.
3. Totally Independent Executables
Limitation of Traditional RTOSes: Once a traditional RTOS is built, it creates a single binary/image including all implementation; Device Drivers, Kernel, User Application(s), Middleware(s) and Secret Keys. It avoids modular design for a system. It is also not useful during the certification, which is not easy to manage an all-in-one image. The other problem is that it makes each module (Kernel, App, Middleware) dependent on each other like using the single toolchain/development environment.
ZAYA Containers are independent executables in ZAYA.
The developer can design and develop ZAYA containers using different development environments/IDEs and toolchains(Arm MDK, GCC, etc.). As an example, one μContainer can be developed in Arm's Keil IDE using MDK ARMCC compiler while another μContainer can be developed in Eclipse IDE using GCC compilers.
In the code Link Time, there is no need to link the μContainer with Kernel nor other containers.
4. Deployment Friendly
Limitation of Traditional RTOSes: Once a traditional RTOS is built, it creates a single binary/image including all implementation; Device Drivers, Kernel, User Application(s), Middleware(s) and Secret Keys which means a massive size of firmware upgrade packages while IoT Devices are resource constraint devices. It also causes massive network traffic when we consider thousands of millions of devices in the field.
As pointed in the previous section, ZAYA Containers are independent executables which also make ZAYA Containers deployment friendly.
When a μContainer needs to be upgraded in the field, only the modified μContainer image is sent to the field; there is no need to send the whole Kernel, Peripheral drivers and other user applications etc. It means efficient OTA (Over-the-air programming) and dramatically reduced network traffic if we consider thousands or millions of devices in the field.
IoT Edges are resource-constraint small devices, and they may have Kilobytes of memories to store upgrade packages which may not be enough to save the whole image package, and it is a limitation of the classical RTOSes. Herein, small stand-alone upgrade packages of containers solve (at least improve) the problem for the resource constraint IoT Edges.
5. No OS Level Configuration Limitation of Traditional RTOSes: Traditional RTOSes need configuration files to manage on Application-Level Requirements, and once an application need is changed, the configuration needs to be changed, and the kernel needs to be rebuilt again.
ZAYA Secure Kernel is a Configureless OS and does not have any configuration for application-specific needs such as Timer Counter or MessageBox capacity. ZAYA μContainer is free to define its application-level requirements in the μContainer itself, and as the μContainer are design-time and run-time independent executables, the kernel is not affected by these changes.
It makes the ZAYA μContainer implementation simple (no OS configuration complexity) and certification friendly while the Kernel Signature never changed.
6. Run-Time Clonable ZAYA containers are cloneable executables at runtime.
The device may need to run the functionality stored in a μContainer in different instances, and it can clone a ZAYA μContainer, and it can run the clones with the same or different configurations.
Please see the following links for more details;
If you are interested in more details and demonstrations, please contact info@za-ya.co.
Comments