Abstract.12 ISO26262 is a recently approved standard for functional safety in road vehicles. It provides guidelines on minimization of unreasonable safety risks during development of embedded systems in road vehicles. However, the development process specified in ISO26262 involves a number of steps that will require changing traditional and well established development processes. In a transition phase, however, due to lack of tool support, the steps may be performed manually, increasing the risk for delays and increased cost. This paper describes a case study in which we have successfully worked with traceability and testability of functional safety requirements, as well as safety requirements assigned to a testing tool that automates integration and verification steps, leading to standard-compliant tool qualification. Our tool qualification method employs fault injection as a validation method to increase confidence in the tool. Our case study will help to avoid many of the new pitfalls that can arise when attempting to realize standard-compliant development.
IntroductionIndustry and academia struggle to improve safety of road vehicles. considering the severity and probability for each hazard, as well as a driver's ability to compensate (controllability). For high ASIL items, the standard requires stringent measures for risk minimization. In contrast to IEC61508, besides many other aspects, ISO26262 imposes qualification requirements on software tools used in the development process, which also includes verification and validation tools. While tools exist, they may not have been qualified or developed considering safety requirements. Consequently, to be ISO26262-compliant, existing tools must be qualified, and in each future version, re-qualified. Similar to IEC 61508, ISO26262 allows decomposition of high ASIL safety requirements, using two same-or-lower ASIL requirements and redundancy, monitoring or other safety-enhancing concept. Since development to a lower ASIL typically requires less effort, decomposition is an attractive possibility. However, the decomposition must be implemented by independent components and affects the system architecture. To demonstrate fulfillment of the original requirements, there shall be traceability to and from the decomposed requirements. As seen from above, ISO26262-compliant development include specification of safety requirement (including determination of ASIL), decomposition of safety requirements, requirement traceability and testability, qualification of software tools, verification and validation. This paper provides an example of how these steps can be performed. The aim is to help minimize pitfalls in transition to ISO26262.The next section reviews prior work. Section 3 presents requirements elicitation and traceability. Section 4 discusses testability, leading up to Section 5 which is about testing tool qualification. Section 6 presents a verification and validation strategy. These concepts are illustrated in a case study in Section 7. present a reference development...