Functional Safety: ISO 26262

Design Services team, 26 August 2020

The words ‘Functional Safety’ can often be met with a response of confusion, despair and concern regarding cost overruns and programme delays. Certainly, to build quality into a system design solution does not come for free, however, when done right, Functional Safety can be successfully delivered with minimal overheads and the associated work required can be mapped and amended onto your existing product lifecycle management processes, underpinned by the V-lifecycle model.

Safety can be defined as: ‘Freedom from unacceptable risk of physical injury or of damage to the health of people, either directly, or indirectly as a result of damage to property or to the environment.’ – IEC.

Systems comprised of electrical, electronic and software elements, have been used for many years to perform safety functions in all industry sectors.  Increasingly, system safety is dependent on programmable software-intensive solutions, this trend is clearly apparent in the automotive sector. Functional Safety therefore relies on ‘active systems’ and is the part of the overall safety that depends on a system (specifically the control system) operating correctly in response to its inputs. The control system is therefore responsible for the detection of potentially dangerous conditions resulting in a protective or corrective action to prevent hazardous events arising, or providing mitigation to reduce the consequence of the hazardous event.

Functional Safety is fundamental to enabling the use of complex electronics and software for safety-related functions, it provides the assurance that safety-related systems will offer the required risk reduction measures (the integrity level) in order to achieve overall safety, with a robust argument and supporting evidence commensurate with the safety claim.  Automotive Safety Integrity Level (ASIL) requirements are outlined in the industry standard ISO 26262, which is complemented by ISO 21448 and 21434 to help assure safety and security of the intended functionality is maintained.

A common fallacy is that Functional Safety and Security can be bolted-on to a system later on in the design.  While safety and security features may be retrospectively added to a mature design solution to reduce risk, this is usually at an increased cost and such systems are typically not as inherently safe or reliable, or as cost effective, as they could have otherwise been had Functional Safety and Security been considered from the outset.  Consequently, achieving inherent hazard and risk reduction, and quality assurance from the outset typically delivers a more cost-effective development lifecycle overall.  Neither safety nor Functional Safety can be determined without considering the system as a whole and the environment with which it interacts. Employing Systems Engineering techniques therefore fully complements the goals of Functional Safety, which can, and should, be further refined via model-based design.

The effects of ignoring Functional Safety can, sadly, be devastating, and so it is imperative from an ethical standpoint as well as a commercial one, that Functional Safety requirements are embedded within the design process from the outset, and that the supporting verification evidence required is obtained.

The aim of Functional safety is to bring risk down to a tolerable level and to reduce its negative impact.  At Romax we ensure safety risks are reduced to a level which is considered ‘as low as reasonably practicable’ (ALARP).  Our design process embraces industry good and best practice from several sectors, underpinned by Model Based Systems Engineering (MBSE) including: formal methods, defensive architecture development, appropriate language paradigms and toolset qualification, safe language subsets, automated code generation, error trapping and error handling, static and dynamic analysis, unit and integration testing, statistical testing, diversity and independence, commensurate with the level of risk reduction required.  Of course, this would not be possible without a sound safety culture.

What this means is that you need not fear the requirement for ‘ASIL D’ or equivalent functionality: from requirements engineering embedding validation and verification, robust system architecting, detailed electronic hardware and embedded software design and development, consultancy support, training and independent audits, Romax can help serve your needs in the field of automotive Functional Safety commensurate with ISO 26262.  We also offer the similar support to industrial, rail and aerospace sectors, regarding IEC 61508 & 61511, CENELEC EN 51026, 50128 & 50129, and DO178 & DO254.