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?
- 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
- Classic AUTOSAR based OSs
- POSIX compliant High Performance/High Reliability/High Availability OSs
- Other OSs with a small footprint
Different OSs in the market
- 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
- 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.