Standards Development

Scope

This document describes a framework for Functional Safety to assist the development of safety-related systems incorporating existing software products not developed in accordance with international safety standards, like ISO 26262. This framework provides possible methods and measures that can be adopted to claim that the software product is sufficiently safe once embedded within a system-on-chip and indications for creating a complete Technical Safety Concept. These indications address technical aspects to implement functional safety in order to demonstrate the architectural capability of a generic software product in the context of the overall safety-related system; others address the software development process to demonstrate the robustness against systematic failures.

This document provides a detailed and exhaustive qualification concept applicable for generic complex pre-existing SW product with the aim of achieving equivalence safety assurance with the principles underlying ISO 26262 (basically derived from Part 4, Part 6 and 8), where applicable. The methods and measures listed in ISO 26262 have been assessed with respect to the underlying rationale to achieve the standard’s goal. 

Purpose

Today, a direct application of the ISO 26262 series of standards on existing software products not developed in accordance with international safety standards is often considered not feasible. Especially for software, ISO 26262-6 requires strict lifecycle process requirements and architectural constraints to be considered for ensuring the avoidance of systematic failures that cannot be adopted retroactively in case of complex software elements. Then, the standard includes alternative methods, software SEooC (Part 10), qualification of software components (Part8-12) and proven in use arguments (Part8-14). According to ISO 26262-10 Table 4 the first method is suitable for new developed design, but not for existing software if not originally developed as SEooC; the second one is applicable only if the size and complexity of a software component is small; the last method can be used for existing components, but the conditions surrounding the validity of the “proven in use” argument can be challenging due to the typically limited field feedback. Furthermore, ISO 26262 does not include any guidelines on the application of safety standard requirements for that software products not explicitly conceived for Functional Safety purpose as done for example in ISO 26262-11 for hardware components to support semiconductor companies.