Adhering to functional safety standards is costly and time consuming. For an application to be compliant with the most demanding SIL (IEC 61508), ASIL (ISO 26262), Class (IEC 62304), or DAL (DO-178) in industrial, automotive, medical or avionics applications respectively, the overhead can be considerable.
These functional safety standards have classifications to describe the criticality levels of the software they are applied against. Higher levels of safety criticality require more rigor in the system’s creation. Regardless of the industry sector, they can have a tremendous impact on the code development process from planning, developing, testing, and verification through to release and beyond (Figure 1).
For example, in ISO 26262-3:2011 :
“Four ASILs are defined: ASIL A, ASIL B, ASIL C and ASIL D, where ASIL A is the lowest safety integrity level and ASIL D the highest one….
In addition to these four ASILs, the class QM (quality management) denotes no requirement to comply with ISO 26262.”
...
Achieving adequate separation between software items is vital to the integrity of this approach, and there are many ways to achieve that. Ways to separate software items include:
This requirement for domain separation is common across the safety critical sectors, as can be demonstrated by now considering the example of aeronautical systems.
The traditional approach to maintaining the separation of many systems in aircraft was to simply keep them physically separate. The separation of an airliner entertainment system from the flight control system provides a clear illustration of separation matters in this environment.
Federated avionics architectures make use of distributed avionics functions that are packaged as self-contained units (LRUs and LRMs). IMA architectures move away from this hardware centric approach by employing a high-integrity, partitioned environment that hosts multiple avionics functions of different criticalities on a shared computing platform...
DOWNLOAD THE COMPLETE PAPER TO CONTINUE READING
