We observed that safety arguments are prone to stay too abstract, e.g. solutions refer to large packages, argument strategies to complex reasoning steps, contexts and assumptions lack traceability. These issues can reduce the confidence we require of such arguments. In this paper, we investigate the construction of confident arguments from (i) hazard analysis (HA) results and (ii) the design of safety measures, i.e., both used for confidence evaluation. We present an argument pattern integrating three HA techniques, i.e., FTA, FMEA, and STPA, as well as the reactions on the results of these analyses, i.e., safety requirements and design increments. We provide an example of how our pattern can help in argument construction and discuss steps towards using our pattern in formal analysis and computer-assisted construction of safety cases.
@cite_7 present patterns arguing for safe control software by using adaptation mechanisms for improving or maintaining safe states. Our three modules (M, CR, and HC) are similar to their core patterns but use fewer argumentation steps. They focus on FMEA, arguing over adaptation as a design measure ( @math ) which goes beyond in our countermeasure module ( @math ). We integrate FTA, FMEA, and STPA and capture how safety requirements were motivated. We aim at a compact pattern and use HA results more directly. Their argument depicts that an identified risk structure ( failure modes as hazards and their causal factors) is acceptable and, by adaptations as countermeasures, how this structure got acceptable. We do not presume adaptation as a countermeasure. Moreover, we allow the goal structure to be built during FTA, FMEA, or STPA whereas they concentrate on an a-posteriori construction.
@cite_7
141099830
Abstract : This report results from a contract tasking University of York. The project will undertake one activity: Produce a unified (generic) approach to developing safety cases for adaptive avionics and software and identifying a "way ahead" to develop and validate the approach, based on the outline produced in the preceding NASA project. As with the previous report, the authors' focus in addressing safety cases for "advanced" control systems is to concentrate on the class of adaptive systems. A system can be considered adaptive if its behavior cannot be predicted solely from knowledge of its initial software design and state. The behavior of an adaptive system is the product of its initial state and the adaptations (state changes) that have taken place according to the stimuli it has encountered. Adaptive systems can be introduced to improve safety (e.g., to continue to control an aircraft safely in the event of losing a control surface), or to improve other system characteristics (e.g., to improve the fuel consumption of an aero-engine). The motivation for introducing an adaptive capability has a significant impact on the nature of the required safety argument. Where improved safety is the goal of the adaptation, the safety argument must justify that the adaptive system is capable of reducing some of the risks associated with hazards already present with the equipment under control. At the same, it is necessary to ensure that the introduction of the adaptive capability does not introduce new, or increase existing, risks. Where adaptation is being introduced for reasons other than safety, safety can be viewed as a constraint. The principal concern is that the adaptive capability doesn't introduce new, or increase existing, risks.