eMCOS® features
Modern Multikernel Design
eMCOS is the world's first commercially available, ultra-scalable real-time operating system (RTOS) based on the modern multikernel architecture (aka distributed microkernel). This new operating system architecture offers - in contrast to all other traditional RTOS architectures - a scalability that supports not only larger core numbers but also heterogeneous hardware configurations. This includes various architectures such as on-chip flash microcontrollers, SoCs, DSPs and FPGAs. Not only is the platform already ported to various hardware architectures, but its highly portable source code and design also make it easy to transfer to new platforms.
A traditional single microkernel operating system architecture designed for the single-core era cannot handle different processor architectures in an integrated manner and so cannot deliver optimized performance. To realize highly efficient HPC with heterogeneous multi/manycore computing, an operating system with a modern multikernel architecture is required, where the operating system itself has high parallelism and each processor has its own independent microkernel optimized for heterogeneous computing.
In addition, eMCOS' unique and patented scheduling algorithm provides the real-time capabilities essential for embedded systems while delivering the high performance expected from multi/manycore processors.
Despite these innovations, application developers can use familiar development styles with eMCOS as it offers the same programming model and interfaces as other widely used RTOSes for single and multi-core processors.
Fully isolated and tightly coupled applications with varying reliability
Since the applications on each core are processed independently, complete isolation between their applications is achieved.
Applications communicate with other applications on other cores through lightweight and very rapid messages.
Modern multikernel (distributed microkernel)
In multikernels, an independent microkernel runs in each core (system of systems), providing basic services such as message transmission between cores, core-local scheduling, thread management. The microkernel is extremely compact and consists only of lightweight, rapid functions.
Higher-level operating system services such as file and network services as well as other middleware and device drivers are distributed across several cores as thread servers independent of the microkernel and operate according to the client-server model of a Service Oriented Architecture (SOA).
Applications are divided into processes, which are then divided into threads. Those threads can then be executed on different cores in parallel. To ensure that all cores are used efficiently, these thread groups are scheduled and executed based on the thread priority and the operating status of the individual cores.
High performance, true parallel processing
The threads are all interconnected by microkernel message transmission. However, from the application point of view, the OS services and middleware APIs can still be used like normal C/C++ language functions. Due to the integration of the message-passing functionality, the user APIs do not need to further consider this underlying mechanism.
The independent microkernels operate on each core, reducing resource contention, and achieving high throughput. This is made possible by keeping the thread databases (TDBs) for each core separate, so that switching threads on one core dies not interfere with from other cores.
With a traditional (single) microkernel RTOS, every communication between different kernels stops all kernels, since this architecture bases its determinism only on a single thread database. This means user applications have to deal with global kernel locks, that generate complex application behavior.
In a modern multikernel, each core has a kernel with its own thread database. This results in only short local synchronization locks for the communicating kernels during inter-kernel communications. This means on the one hand the RTOS bottleneck is reduced with the application communication and on the other hand the functional safety is increased by the improved Freedom From Interference (FFI).
Here is an example of how the task switch time of a traditional microkernel RTOS increases with the number of cores, while that of a modern multikernel RTOS is completely independent of the number of cores.
For running highly parallelized applications such as coding and image processing, thread pool and fast messaging libraries are also provided to enable communication and synchronization for parallel thread execution with minimal effort.
Back to top
Patented Semi-Priority-Based Scheduler
Semi-priority-based scheduling
The unique and patented scheduling algorithm of eMCOS: "Semi-priority-based Scheduling" (Japanese Patent No. 5734941, 5945617), ensures real-time determinism, which is key in embedded systems, while delivering maximum performance through load balancing.
In semi-priority-based scheduling, two types of schedulers operate in parallel. The individual threads can be configured as hard-real-time (core affinity function) or soft-real-time threads (enables load-balancing).
Improved throughput while maintaining real-time performance
The first scheduler runs independently on each core and uses a classical priority-based algorithm to select the thread to execute. Since each kernel runs independently, scheduling and context switching are similar to a single-core system (no synchronization between cores).
The second scheduler distributes the load by first measuring the CPU utilization of each thread at regular intervals. It takes into account the low priority thread groups (soft real-time threads), the relative throughput of the processor cores and, of course, the priority of the respective threads. In order to maximise the overall performance of the multi/manycore processor, it can then shift threads with low priority to less busy cores.
Time protection for safer system integration
High priority threads (hard real-time threads, core affinity function) remain untouched by the second scheduler to ensure the determinism of the system. Here, there is no migration of processor cores and so no execution interruptions. This allows developers to accurately calculate the processing time of these threads to complete processing within the required real-time limits.
This semi-priority scheduling significantly outperforms other scheduling methods, especially for thread configurations with large fluctuations between thread workloads.
Improved system integration with time partitioning
In today's applications, not only spatial software separation (memory, I/O access) is needed, but also temporal separation (time separation). eMCOS POSIX applications can be scheduled with its smart time partitioning feature based on “priority partition scheduling”.
With priority partition scheduling, software integrators have a mighty tool to manage a big number of priorities and keeping a high level of freedom from interference (FFI) for applications with mixed criticality.
Most software modules were developed and tested in isolation and thus in a state where they did not have to share CPU with other software. The customer benefit with time partitioning is to get a further dimension to manage thread priorities in the stressful integration phase to avoid complex changes in application behavior as more and more software is integrated on the same CPU.
By managing applications with the scheduling cluster window, software integrators have a convenient tool to continuously update their application and avoid sporadic complex effects.
A time partition consists of processes with its threads.
These partitions are assigned to "scheduling clusters" formed by a group of CPU cores.
Within a scheduling cluster “window” a time partitions will be sequentially configured. In each time partition, the applications (processes/threads) of the respective active partition have the highest priority. If the active partition is idle, however, other partitions can use this idle time for themselves according to their priority.
The scheduling cluster window is constantly repeated.
Compared to other time partitioning approaches, priority partition scheduling provides a very convenient mechanism to control application-level priorities by separating thread priorities from "application time slots" while still taking care to efficiently utilize all CPU idle time.
Back to top
Hardware and Software Ultra Scalability
Hardware-scalability from single-core to heterogeneous multi/manycore
The modern eMCOS multikernel architecture (distributed microkernel) scales from single-core microcontrollers up to heterogeneous multi/manycore processors and multi-chip systems.
eMCOS is compatible with both homogeneous multi/manycore processors without cache coherence function and heterogeneous multi/manycore processors of different architectures.
In addition, it also simplifies developments based on multi-chip system architectures.
Software-scalability by existing APIs and programming models
The eMCOS application programming model is independent of the underlying CPU instruction set. eMCOS APIs can be used with regular languages such as C or C++. Other language interpreters such as Rust are also available if required.
eMCOS is available with different profiles such as Multi-process POSIX and AUTOSAR (SC1 and SC3). It also offer a Hypervisor option for mixed-criticality applications. Support for POSIX and AUTOSAR APIs means Linux and AUTOSAR software assets can also be easily reused.
POSIX-compliant profile: eMCOS POSIX
eMCOS POSIX is an eMCOS profile that conforms to POSIX 1003.13 PSE 53 and enables multiprocess programming.
The POSIX API specifications are supported without reducing the scalability and real-time performance of eMCOS.
By using the highly portable POSIX application interface, functions found in a variety of already available libraries of e.g. general purpose operating systems such as Linux and Android can be easily implemented in the system.
This provides eMCOS POSIX features such as thread, signal, and inter-process communication at process and system level. It is compliant with POSIX 1003.13 PRE53 and supports PSE 51, a profile for a single POSIX process with multiple thread controls, and PSE 53 for multi-POSIX processes. Various libraries using the POSIX standard, e.g. ROS and AUTOSAR Adaptive, can therefore be easily integrated.
eMCOS therefore offers the user a traditional POSIX user interface based on a highly innovative architecture.
Learn more
Type 1.5 Hypervisor : eMCOS Hypervisor
eMCOS Hypervisor is implemented as an extension option to the POSIX-compatible eMCOS POSIX.
This means real-time and safety-critical applications for eMCOS POSIX can be deployed on the same hardware platform alongside Linux and Android guest operating systems.
Learn more
Development scalability
With eSOL's flexible and easy-to-use IDE, development teams can access easy tools for debugging and performance optimization. Its Eclipse & Visual Studio Code editors are popular among embedded developers, with the build process based on CMake to simplify porting, especially in available Linux applications. eSOL’s pre-built, safety-qualified toolchain supports emulation-, simulator-, and model-based development.
In addition, runtime software and development tools such as the Basic Board Support Package (Reference BSP), various middleware and device drivers are provided for eMCOS as part of the eMCOS SDK to support efficient development of high-performance applications.
Beyond our COTS products, we also provide rofessional Services and one-stop services for product support, training, customization and porting.
Learn more
Back to top
Safety
ISO 26262 ASIL D certification
eSOL provides a Safety Manual and Safety Report as safety related documents. The Safety Manual describes the safety concepts for eMCOS , measures for achieving these concepts, and validation methods, as well as methods for using eMCOS that take effects on system safety into account. The Safety Report describes the results of validation performed by using the validation methods described in the Safety Manual. Compared to the use of a non-certified operating system, usage of these safety-related documents reduces the work required for creating test use cases, testing, creating evidence based on tests, and explaining safety related to the operating system. This reduces the cost of compliance with standards for your product.
 |
eMCOS has received the following third-party certification for functional safety standards.
|
Back to top
eMCOS Hypervisor
eMCOS Hypervisor enables the integration of safe real-time applications and feature-rich applications on general purpose operating systems on a single hardware platform. This allows mixed-criticality systems to be developed and certified according to applicable industry standards.
eMCOS Hypervisor is implemented as an extension option to eMCOS POSIX.
Mixed criticality
This means real-time and safety-critical applications for eMCOS POSIX can be deployed alongside Linux and Android guest operating systems on the same hardware platform. This opens up another dimension of scalability for eMCOS and gives users more options to integrate a wide variety of functions into one system, while still being able to use existing Linux or Android-based platforms with minimal changes. Linux and Android guest operating systems provide the necessary POSIX-compliant API and support a wide range of open communication protocols or graphics display solutions.
This combination provides greater flexibility for implementing advanced, open, and diverse systems with mixed criticality.
Hypervisor versus containers
During the joint software development of safety-related connected applications, misunderstandings often arise between cloud developers and embedded developers. One issue is the different practices for isolating applications running on hardware. While cloud development often uses containers, embedded systems with high functional security requirements use hypervisors.
A hypervisor provides much higher application isolation than a container. Subsequently, containers can be used on a guest OS of a hypervisor to take advantage of containers such as in a development according to the CI philosophy.
| Category | Hypervisor | Containers |
| General | Hypervisor is a strong technique for virtualization: each environment runs in a full virtual machine (VM) | Container is a weaker virtualization technique: groups of applications share the same operating system services |
| Granularity | Groups of apps + guest-OS | One OS with groups of apps |
| MMU usage | Level 2 hypervisor, Level 1 guest OS | Level 1 host-OS |
| Performance | More expensive context switches | Just host-OS |
| Integration process | Incremental integration | All applications must be verified together |
| Software update | Affects one guest-OS | Affects the entire platform |
| Security breach | Affects one guest-OS | Affects the entire platform |
| Safety concern | Can decompose into subsystems | Must consider all applications |
Type 1.5 Hypervisor
eMCOS Hypervisor offers a type 1.5 hypervisor functionality, which is different from a normal type 1 hypervisor in that it also provides direct real-time functions through its POSIX API.
So, at the same time Guest-OSes can be controlled by Virtual Machine Managers and native POSIX process applications can be processed in real time. Established software standards such as virtio are also used here for easy reuse of source code.
eMCOS hypervisor device management
eMCOS provides four different access types for shared devices.
Summary
eMCOS Hypervisor offers all the advantages of a hypervisor for rapid development of applications with mixed criticality and high performance.
Back to top