If you are working in the software of a safety critical product, you are most probably using an ASIL 'certified' Operating system in it.
The market is flooded with various ASIL-certified Operation Systems (OSs) from various Tier 2s. On top of it, several Tier 1s and OEMs themselves are developing their own OS in ASIL compliance. This blog summarizes the ASIL-certified OSs that are available in the market, what features they provide and what do they promise for its users.
Disclaimer: We have analyzed only the public literature available for the various OSs and written this article based on what we learnt from them. We do not have working experience in most of these OSs. Hence, we could have missed describing some of the features that are available in these OSs simply because it was not stated in their public literature.
We have structured the content of this article as follows:
- What are the broad expectations of an Operating System from a Functional Safety perspective?
- What are the aspects in which we have analyzed the ASIL OSs?
- Broad categories of ASIL OSs
- Different OSs in the market
In order to keep this article focused on safety, we have not got into analyzing Non-safety aspects of the OS (such as debug or profiling tools) or other related aspects that are outside the scope of OS (such as supporting middleware, compliers etc). However, these may as well be key differentiators (most importantly the license cost!!) for deciding on an OS.
What are the broad expectations of an Operating System from a Functional Safety perspective?
- High availability and reliability (i.e., Guaranteed and correct execution of not only safety components, but also non-safety components)
- Maximum Performance (minimal latencies for interrupts, events, tasks etc)
- Guaranteed Isolation of Safety related processes (including its memory and data)
- Guaranteed freedom from Interference for execution of Safety related tasks/threads and preferably, localized recovery of failed components/processes without affecting the rest of the System
- Safe and reliable inter-process/inter-task/inter-thread communication
- Preferably also used in Safety crucial products in domains other than Automotive such as Avionics, Railways, Industrial equipment, Medical devices etc
- Integration of Security into the architecture of the OS
Security and Safety are two different topics with their own purposes. However, as we move towards ADAS, V2X, Domain controllers etc, not only are hazards increased multi-folds but also threats due to the increased connectivity (Internet based attacks, Wireless attacks, Sensor attacks etc). Security threats may lead to a compromise or incorrect functioning of Safety features/mechanisms. Hence, we have added this aspect to our OS considerations.
What are the aspects in which ASIL OSs have been analyzed?
We analyzed the public literature available for the various OSs to understand the following aspects:
- Highest ASIL level achieved by the OS
- Is the OS compliant to AUTOSAR standards?
- Is the OS compliant to POSIX standards?
- Other Safety standards achieved by the OS (i.e., other than ISO26262)
- Does the OS support Multi-core and Many-core architectures?
- Does the OS use the MMU?
- Does the OS use the MPU?
- OS Architecture (Nature of Kernel, scheduling policies etc)
- How the OS achieves Freedom from Interference for Memory (i.e., tasks/process memory)
- How the OS detects or prevents Stack corruption/overflow/underflow
- How the OS achieves safe inter-task/inter-process communication
- How the OS achieves Freedom from Interference for Timing and Execution
- How the OS ensures high reliability, availability and performance
- Microcontrollers supported by the OS
- How the OS considers security in its architecture
Broad categories of ASIL OSs
We have broadly categorized the ASIL based OSs into 3 groups:
- Classic AUTOSAR based OSs
- POSIX compliant High Performance/High Reliability/High Availability OSs
- Other OSs with a small footprint
Different OSs in the market
These are the OSs that we have analyzed:
- Vector’s Microsar OS
- ETAS’s RTA-OS
- Elektrobit’s EB Tresos Safety OS
- Blackberry’s QOS (QNX for Safety)
- Greenhills Integrity RTOS
- Windriver’s VxWorks
- eSOL's eMCOS POSIX
- WHIS’s SAFERTOS
- SCIOPTA Safety RTOS and
- eT-Kernel Compact
Classic AUTOSAR based OSs
Falling under this category are - Vector’s Microsar OS, ETAS’s RTA-OS and Elektrobit’s EB Tresos Safety OS.
All of these OSs support both single core and multi-core processors and are certified as ASIL-D. EB Tresos Safety OS is also certified as IEC61508 SIL3.
Microsar OS and RTA-OS have many a things in common.
- Both are Preemptive, Monolithic OSs with a statically configured priority-based real time scheduler.
- Both support all Autosar scalability classes (SC1 to SC4) thus offering both Memory protection and Timing protection as solutions for achieving freedom from interference (FFI) for memory, timing and execution.
- Both these OSs offer an ASIL-compliant RTE solution for Safe communication between Applications (As per Autosar standards, OS does not need to support internal communication within the ECU, and this is the job of the RTE).
- Both are small, quick, resource-economizing operating systems.
Vector additionally offers the AUTOSAR Watchdog Manager solution (outside the scope of OS) to achieve FFI in timing. RTA-OS differentiates from Microsar OS by also implementing a patented single stack solution that reduces application stack space requirements by between 50% and 80%.
EB Tresos Safety OS stands out from the first two by being an AUTOSAR-compatible microkernel OS. So it combines the best of many worlds - Microkernel, Multi-core and Autosar. Though Elektrobit also offers Memory protection as part of its OS and EB Tresos Safety RTE for safe RTE services, it again differentiates by making a conscious decision to not implement Timing protection services. Instead, it provides the EB tresos Safety TimE Protection module (outside the scope of OS) for achieving FFI for timing and execution.
All of these OSs have been in the market for several years now, support a wide range of processor architectures and microcontrollers and are used by various Tier 1s and a preferred choice for several OEMs.
From a security perspective, these OSs do not provide any specific features, rather these suppliers provide several modules outside the scope of OS that implement hardware & software based crypto solutions and established cryptographic algorithms.
One another OS in the market that falls in this category is eSOL’s eMCOS AUTOSAR profile OS that is ASIL D certified. We have not analyzed this here since there is not sufficient information available about it.
POSIX Compliant High Performance/High Reliability/High Availability OSs
Falling under this category are – Blackberry’s QOS (QNX for Safety), Greenhills Integrity RTOS, Windriver’s VxWorks and eSOL's eMCOS POSIX. All these OSs are certified as ASIL-D. QOS and Integrity have many additional certifications as well for domains other than Automotive. Please refer to the table below for details on additional certifications. All these OSs are Multi-core, Micro-kernel based and POSIX compliant.
Architecture
INTEGRITY is built based on a partitioning architecture. It implements the concept of multiple protected virtual address spaces, each address space containing multiple application tasks. QOS also works on a similar concept; its architecture isolates every application, driver, protocol stack and file system in its own address spaces outside the kernel. VxWorks as well implements separation between kernel and memory-protected user-space environments.
All these 3 OSs implement a preemptive real-time scheduler that supports multiple priority levels and enables complete control over CPU percentage allocation. It is no doubt that availability, reliability, safety and security are top most considerations in all these OSs. To ensure reliable execution, these OSs guarantee system resources to individual processes together with a host of other features to improve reliability and performance, such as Highest locker semaphore capability (in INTEGRITY) and Priority Inheritance (in QOS).
eMCOS on the other hand implements a distributed micro-kernel architecture. It is targeted towards multi core processors and runs an Independent microkernel on each core. It also implements its own unique patented scheduling technology called “semi-priority base scheduling”. MCOS is primarily designed for Autonomous driving systems and supports heterogeneous hardware configurations, including on-chip flash microcontrollers, GPUs, and FPGAs.
Freedom from Interference - Memory
Integrity, QOS and VxWorks establish spatial separation for all processes through MMU. Processes have their own virtual address space, which cannot be overwritten by any other component or the kernel. While QOS has features to limit system resources to prevent rogue process from robbing critical processes of resources, INTEGRITY has its own unique memory quota system that keeps one address space from exhausting the memory of any other, thus preventing memory exhaustion, damage and unauthorized access.
Using the MMU, QNX implements guard pages at the end of each thread’s stack to protect against stack overflow. INTEGRITY’s kernel has its own memory stack in order not to access user process’ stack thus preventing the risk of stack overflow.
eMCOS also ensures spatial separation through MMU for processes within the same core.
Freedom from Interference – Timing and Execution
Integrity, VxWorks and QOS implement a preemptive real-time scheduler. Process functionality is separated at thread level and hence there is an isolation from a scheduling perspective between components with different priorities.
QOS offers a feature called Adaptive partitioning scheduler (APS), in which processes divided into different time partitions. This feature guarantees minimum budgets to defined groups of threads without wasting unused processing time. Hence, unexpected system loads don’t affect safe operation, including third party code. Integrity offers an equivalent feature called Multi-level optimized enhanced partition scheduler (EPS) guarantees a specific percentage of CPU time to a given address space regardless of other system or process events. Integrity states EPS enforces the CPU time window boundaries to prevent bugs from adversely affecting tasks in other partitions. From a high level explanation both APS and EPS sound similar, though QOS has an “adaptive” aspect which means that the time partitions and processes running in the time partition can be adapted dynamically during run time. VxWorks also provides Adaptive scheduling but the details of this mechanism is not detailed in their literature.
What about eMCOS? Since eMCOS runs an independent kernel on each core, no kernel instance on any given core can block a kernel instance on another core. Applications are scheduled in partition basis. While a partition is being executed, it will not be affected by another partitions. The time which each application can run in a partition is confined to an allocated set time (budget). As the behavior within the partitions are preserved, inconsistencies due to timing discrepancies caused by integrating separately developed applications into a single system are less likely to occur, thus making system integration much easier.
Freedom from Interference - Communication
QOS uses Inter Process Communication (IPC) based on Synchronous message passing as preferred choice for safety related communication. Though QNX supports made other IPC mechanisms such as signals, message queues, pipes, sockets etc, though they are more preferred for non-safety use cases. eMCOS also uses inter-core message passing as its main communication mechanism.
INTEGRITY provides a secure, bi-directional communication channel, called Connection that enables tasks in the same or different address spaces to communicate. Unlike traditional message queues and other heavyweight protocols such as sockets, the kernel moves data directly between sender and receiver, without any intermediate copying or protocol overhead. Connection objects can be safely and securely assigned to the address spaces that need them.
VxWorks uses message queues as its primary IPC mechanism.
Security
All these micro-kernel OSs have built in several security capabilities, ranging from support for security standards to OS level measures. While VxWorks offers features such as Secure boot, ELF loader, Kernel hardening, Security events, Built-in access controls etc amongst many others, QNX offers features such as Discretionary Access Control (DAC), Address space layout randomization (ASLR), Path trust, Process manager abilities etc. GHS is a pioneer in terms of security in OS, developing the Integrity-178B OS certified to NSA: EAL 6+ High Robustness Common Criteria SKPP, which is one of the highest security certifications. Integrity OS for Automotive also brings in the security features in the OS. Not much information is available about eMCOS on this topic.
Other OSs with a small footprint
Amidst the OSs we analyzed, falling under this bucket are WHIS’s SAFERTOS, SCIOPTA Safety RTOS and eT-Kernel Compact, all of which are ASIL-D certified.
SAFERTOS is a widely-used OSEK based highly deterministic micro kernel that has a minimum ROM footprint in the region of 10 K Bytes. The Task Isolation and Separation feature of SAFERTOS enables developers to co-locate safety critical code with non-safety critical code. SAFERTOS implements a Queue for safe transfer of data between tasks and tasks and interrupts, though it is not exactly clear how safety of the queue is ensured. Freedom from Interference for timing is achieved not within the OS itself but by an external module named SAFECheckpoints that is outside the SAFERTOS and checks that tasks and interrupts run within time and periodic tasks are executed within a tolerant limit.
SCIOPTA Safety RTOS is a pre-emptive multi-tasking high performance OS. The SCIOPTA kernel can observe data transfer between processes by testing checksums over message data areas. The architecture allowing direct message passing between processes with centralized errors handled by hooks. Messages and processes can be grouped into modules protected by MMU which can be static or fully dynamic. Messages are stored and maintained by a manager in memory pools to avoid memory fragmentation and enhance performance.
eT-Kernel Compact is an RTOS with a small footprint and remarkable real-time capability. It is backward compatible to TRON based Architecture. It provides a protection ring function. Different protection level rings at different levels of privilege can be defined for partitioning software of different criticality levels.
Conclusion
The growth of ADAS, Automated driving, DMS and Domain controllers clear demand the need to use OSs that are highly reliable, secure, safe and provide maximum real time response. Micro-kernel based OSs clearly outshine Monolithic OSs in terms of reliability, security and safety. Functioning on an adaptive Autosar platform may also become a mandatory requirement for such OSs. We will increasingly need OSs such as QNX, Integrity and VxWorks to handle such use cases.
Classic Autosar is the state-of-the-art for the native ECUs such as body controller ECUs, Airbags, brake and Instrument Cluster ECUs that would contain to remain in the majority of the non-autonomous and semi-autonomous cars and coexist with the new generation ECUs. The Classic Autosar based OSs are here to stay too.
Linux Foundation’s ELISA project is trying to bring LINUX to Safety critical systems by creating shared set of tools and processes. In its current status, LINUX being developed as a Safety critical OS is a far cry, if not an unheard cry. But will this change in future?
We'd love to hear what you think about this topic. Do these ASIL-D operating systems already have all that is needed for our growing new ECUs? What will we see coming in the future? Please do share your thoughts.