SPRAD97 may   2023 AM62A3 , AM62A3-Q1 , AM62A7 , AM62A7-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1 What is a DMS and Why Does it Have to be Safe?
  5. 2Hardware Platform for Vision Computing
  6. 3Targeting Safety-Critical Applications
  7. 4Safety OS as a Foundation for Safe Software
  8. 5Freedom from Interference
  9. 6Enabling Safe Symmetric Multi-Processing (SMP)
  10. 7Safety BSP – Bridging the Gap Between Hardware and Software
  11. 8Summary
  12. 9Reference

Safety OS as a Foundation for Safe Software

In general, an RTOS (real time operating system), like the Green Hills Software INTEGRITY RTOS, is in charge of scheduling tasks, providing synchronization and communication mechanisms, as well as objects to configure periodic events (timers) and other resource allocations. As such, the RTOS is the foundation for the whole application of the embedded system. Furthermore, the RTOS needs to follow the respective safety standards when used in a safety-critical application. What does that mean?

Functional safety is built on two pillars: fault avoidance and fault control. Fault avoidance deals with systematic failures, caused by faults originating before system installation. These are addressed in the standards by specifying a development process, off target. The corresponding certificate is the assurance that the safety element is suitable for use and free of systematic errors.

Figure 4-1 was specifically built for usage in a safety-critical applications, therefore it was developed according to the safety standards to address fault avoidance – it is certified according to ISO26262 ASIL D [1], IEC61508 SIL 3 [2] and EN50128 SW SIL 4 [3]. With these safety standards, it is possible to certify/assess a single component, such as an RTOS, treating it as a Safety Element out of Context.

Beyond this, fault control must deal with potential run-time errors for example, radiation-induced soft-errors. These errors are caused by faults originating after system installation and need to be addressed not only by the hardware but also by the software on the target. The standards describe diagnostics and techniques that shall be applied, including the corresponding diagnostic coverage: Low (60%), Medium (90%) or High (>=99%). The higher the required Safety Integrity Level (SIL, ASIL for ISO26262) the more rigid development process (fault avoidance) and diagnostic coverage (fault control) shall be applied. For ASIL C and D a high diagnostic coverage is required.

A certified software safety layer implementing high diagnostic coverage techniques such as time supervision, deadline monitoring, sequence pointing, safe storage, invariable RAM protection, MMU-page table checking, and safe inter process communication adds a lot of value to the safety designer of the device. Green Hills Software provides these capabilities in combination with the INTEGRITY Separation Kernel.

GUID-20230413-SS0I-N2LX-MGKL-CK7RSLKQXCZG-low.jpg Figure 4-1 INTEGRITY RTOS from Green Hills Software