Establishing Evidence for Safety Cases in Automotive Systems – A Case Study

Abstract

Abstract. The upcoming safety standard ISO/WD 26262 that has been derived from the more general IEC 61508 and adapted for the automotive industry, introduces the concept of a safety case, a scheme that has already been successfully applied in other sectors of industry such as nuclear, defense, aerospace, and railway. A safety case communicates a clear, comprehensive and defensible argument that a system is acceptably safe in its operating context. Although, the standard prescribes that there should be a safety argument, it does not establish detailed guidelines on how such an argument should be organized and implemented, or which artifacts should be provided. In this paper, we introduce a methodology and a tool chain for establishing a safety argument, plus the evidence to prove the argument, as a concrete reference realization of the ISO/WD 26262 for automotive systems. We use the goal structuring notation to decompose and refine safety claims of an emergency braking system (EBS) for trucks into subclaims until they can be proven by evidence. The evidence comes from tracing the safety requirements of the system into their respective development artifacts in which they are realized.

Continuous assessment of software traceability

“…Existing publications of analytical traceability approaches are confined to the presentation of empirical observations, without providing precise and applicable assessment criteria [Kornecki and Zalewski 2005;Ridderhof et al 2007;Panesar-Walawege et al 2010;Casey and Mc Caffery 2011;Mäder et al 2013]. Determining the fitness for purpose of a project's traceability implementation is essential for establishing trust.…”

“…However, both approaches have a very strict limitation. They can only be applied to design artifacts, which are represented as UML [Ridderhof et al 2007] or SysML models [Panesar-Walawege et al 2010]. Thus, a holistic traceability assessment of all project artifacts is not supported by these approaches.…”

“…To ensure reproducible assessment results, assessment criteria need to be defined in a way that does not leave any room for interpretation. As discussed in Section 2.6, existing analytical approaches are lacking clear assessment criteria [Kornecki and Zalewski 2005;Ridderhof et al 2007;Panesar-Walawege et al 2010;Casey and Mc Caffery 2011;Mäder et al 2013]. Therefore, the following challenge needs to be addressed as well:…”

“…This implies that the assessment criteria need to cover all types of traceability problems. Existing analytical approaches are restricted to a very limited number of traceability problems [Ridderhof et al 2007;Panesar-Walawege et al 2010;Mäder et al 2013]. Accordingly, the following challenge can be derived:…”

“…Existing approaches for traceability assessment are either manual [Kornecki and Zalewski 2005;Casey and Mc Caffery 2011;Mäder et al 2013;Regan et al 2014] or restricted to formalized design artifacts [Ridderhof et al 2007;Panesar-Walawege et al 2010]. To ensure continuous traceability assessments of all project artifacts, the traceability assessment needs to be automated and support all project artifacts.…”