Maintaining Safety Arguments via Automatic Allocation of Safety Requirements

Maintaining Safety Arguments via Automatic Allocation of Safety Requirements

3rd IFAC Workshop on Advanced Maintenance Engineering, Service and Technology October 2016.on Biarritz, France Service and Technology 3rd IFAC19-21, W...

428KB Sizes 0 Downloads 64 Views

3rd IFAC Workshop on Advanced Maintenance Engineering, Service and Technology October 2016.on Biarritz, France Service and Technology 3rd IFAC19-21, Workshop Advanced Maintenance Available Engineering, online at www.sciencedirect.com 3rd IFAC19-21, Workshop Advanced Maintenance Engineering, Service and Technology October 2016.on Biarritz, France October 19-21, 2016. Biarritz, France

ScienceDirect

IFAC-PapersOnLine 49-28 (2016) 025–030

Maintaining Safety Arguments via Automatic Maintaining Safety Arguments via Automatic Allocation of Safety Requirements Maintaining Safety Arguments via Automatic Allocation of Safety Requirements Allocation of Safety Requirements

Ioannis Sorokos, Yiannis Papadopoulos, Leonardo Bottaci Ioannis Sorokos, Yiannis Papadopoulos, Leonardo Bottaci Department Computer Science, University of Hull, Ioannis Sorokos,ofYiannis Papadopoulos, Leonardo Bottaci Department of Computer Science,UK University of Hull, Hull, HU67RX, Department of Computer Science,UK University of Hull, HU67RX, (e-mail: [email protected],Hull, [email protected], [email protected]) Hull, HU67RX, UK (e-mail: [email protected], [email protected], [email protected]) (e-mail: [email protected], [email protected], [email protected]) Abstract: The ‘safety case’ documents the safety argument developers of safety-critical systems employ Abstract: case’ documents safety argument developers of regulation safety-critical employ to convinceThe of ‘safety their systems’ safety, in the compliance with safety standard and systems advice. Despite Abstract: The case’ documents argument developers of regulation safety-critical systems employ to of ‘safety their safety,that in the compliance with safety standard advice. Despite theconvince considerable bodysystems’ of knowledge hassafety evolved, constructing and maintaining aand safety case remains to convince of their systems’ safety, in compliance with safety standard regulation and advice. Despite considerable body ofEspecially knowledgefor thatcontemporary has evolved, systems, constructing maintaining a safety case remains athesignificant challenge. due and to their scale and complexity, safety considerable ofEspecially knowledge has of evolved, constructing and maintaining a safety case remains athe significant challenge. contemporary systems, due to paper, their scale and complexity, safety cases can grow tobody require hundreds for ofthat pages documentation. In this we propose a method which aaims significant challenge. Especially contemporary systems, due to as their and complexity, safety cases canaddress grow tothese require hundreds of pages of safety documentation. Insuch this paper, we propose a method which to concerns. In for numerous standards, thescale aerospace ARP4754-A, the cases canaddress tothese require hundreds pages(DALs) of safety documentation. Insuch this as paper, we propose a method which aims to concerns. In of numerous aerospace ARP4754-A, the concept ofgrow Development Assurance Levels isstandards, used to control thethe safety assessment process and aims to address these concerns. In numerous safety such as aerospace ARP4754-A, the concept ofthe Development Assurance Levels (DALs) isstandards, used to control thethe safety assessment process influence safety case. Our method is based on automatically constructing a safety argument fromand an concept of Development Assurance Levels (DALs) is used to control the safety assessment process and influence safety case. Our method is based on automatically constructing a safety argument an annotated the system architecture model. To perform this construction, we employ previous work from towards influence the safety case.DALs Our method isabased automatically constructing a safety argument from an annotated system architecture model. perform thiscombining construction, we an employ previous workargument towards automatically allocating to suchTo modelonand it with appropriate safety annotated system architecture model. To perform this construction, we employ previous work towards automatically allocating DALs to such athe model and combining it with an appropriate tool, safety argument pattern. The method is enabled through state-of-the-art model-based dependability HiP-HOPS. automatically allocating DALs to such athe model and it with the an appropriate safety argument pattern. The method is enabled through state-of-the-art dependability HiP-HOPS. The advantage of this approach is that when the combining designmodel-based changes, impact of tool, changes can be pattern. The method is enabled through the state-of-the-art model-based dependability tool, HiP-HOPS. The advantage of this approach is that when the design changes, the impact of changes can be automatically reflected in the structure of a re-synthesised safety argument for the system. The advantagereflected of thisinapproach is that when the design changes, theforimpact of changes can be automatically the structure of a re-synthesised safety argument the system. Keywords: safety case maintenance; automation; safety requirements; DAL decomposition. © 2016, IFAC (International of Control) Hosting byARP4754-A; Elsevier Ltd. All rights reserved. automatically reflected in theFederation structure of Automatic a re-synthesised safety argument for the system. Keywords: safety case maintenance; automation; safety requirements; ARP4754-A; DAL decomposition. Keywords: safety case maintenance; automation; safety requirements; ARP4754-A; DAL decomposition. 1. INTRODUCTION 1. INTRODUCTION 1. INTRODUCTION Contemporary assurance of safety-critical systems often Contemporary assurance of safety-critical often involves the production and maintenance systems of the safety Contemporary assurance of safety-critical systems often involves production and present maintenance of convincing the safety case. Thethe safety case should ‘a clear, involves the production and maintenance of the safety case. The safety caseargument should present ‘a subject clear, convincing and comprehensive’ that the system is case. The safety case should present ‘a clear, convincing and comprehensive’ argument that the subject system is acceptably safe (Kelly, 2004). Graphical notations such as and comprehensive’ argument that the subject system is acceptably safe (Kelly, 2004).(GSN) Graphical notations as the Goal Structuring Notation (Kelly, 1998) such and the acceptably safe (Kelly, 2004).(GSN) Graphical notations such as the Goal Structuring Notation (CAE) (Bishop, (Kelly, 1998) the Claims-Arguments-Evidence et al.,and 2004) the Goal Structuring Notation (GSN) (Kelly, 1998) and the Claims-Arguments-Evidence (CAE) (Bishop, et al., 2004) notation have provided many tools for improving the Claims-Arguments-Evidence (CAE) (Bishop, et al., 2004) notation have ofprovided many tools for these improving the representation such arguments. Despite advances, notation have provided many tools for improving the representation of such arguments. Despite these advances, the process of constructing and maintaining safety cases representation of such arguments. Despite these advances, the process of constructing and maintaining safety remains largely a manual one. This is particularly thecases case the process of constructing and maintaining safety cases remains largely a manual one. This is particularly the in the early to interim stages of development, wherecase the remains largely a manual one. This is particularly the case in the early to interim stagesnumerous of development, where the system’s design experiences iterations. During in the early to interim stages of development, where the system’s designstages, experiences iterations.need During these critical safetynumerous case developers to system’s design experiences numerous iterations. During these stages, safetyof case developers need to managecritical significant amounts information and construct these critical stages, safety case developers need to manage significant amountsofof information and construct arguments, the complexity which are comparable to the manage significant amounts of information and construct arguments, complexityofof the which are comparable to the scale and the complexity underlying system. In arguments, the complexity of which are comparable to the scale and complexity of the underlying system. In (Denney, et al., 2013, p. 1) a preliminary safety case for scale andet complexity underlying system. In (Denney, 2013, surfaces p. of 1) athe preliminary safety for surveillance al., of airport (EOSAN, 2011) iscase quoted (Denney, et al., 2013, p. 1) a preliminary safety case for surveillance airport surfaces (EOSAN, 2011) is quoted to be ‘aboutof200 pages’ and ‘expected to grow as the surveillance of200 airport surfaces (EOSAN, 2011) is quoted to be ‘about pages’ and ‘expected to grow as that the operational safety case is created’. It is safe to assume to be ‘about 200 pages’ and ‘expected to grow as the operational safetyfuture case istechnologies created’. It is will safe toonly assume that emerging and further operational safety case is created’. It is safe to assume that emerging future introducing technologiesmore willcomplexity only further exacerbate and this issue, and emerging and future technologies will only further exacerbate issue, introducing complexity anda interactions this whose operation needs tomore be accounted for in exacerbate this issue, introducing more complexity and interactions whose relevant safety case.operation needs to be accounted for in a interactions whose operation needs to be accounted for in a relevant safety case. relevant safety case.

The contribution of this paper is a method which The contribution of this and paper is a method which automates the construction maintenance of a part of The contribution of this and paper is a method which automates the construction maintenance of a part the safety case. The method focuses on the production ofofa automates the construction and maintenance of a part of the safetypreliminary case. The method on the of a (partial) safety focuses argument forproduction civil aircraft, the safety case. The method focuses on the production of a (partial) safety standard argumentis for civil aircraft, where thepreliminary applicable safety ARP4754-A. The (partial) preliminary safety argument for civil aircraft, where theemploys applicable safety standard ARP4754-A. The standard a process known asis the ‘Development where the applicable safety standard is the ARP4754-A. The ‘Development standard a process known as Assuranceemploys Process’, whereby Development Assurance standard employs a process known as the ‘Development Assurance Process’, whereby hierarchically Development across Assurance Levels (DALs) are assigned the Assurance Process’, whereby Development Assurance Levels (DALs) are assigned hierarchically across the system architecture in a top-down approach. These levels Levels architecture (DALs) areinassigned hierarchically acrosslevels the system awith top-down approach. prescribe the rigor which safety These assessment system architecture in a top-down approach. These levels prescribe with which safety assessment procedures the are torigor be applied accordingly throughout the prescribe the rigor with which safety assessment procedures are to be applied accordingly throughout the relevant sections of the system. Previous research has procedures are to be applied accordingly throughout the relevant sections system. Previousallocate research has demonstrated that itofis the feasible to optimally DALs, relevant sections of the system. Previousallocate research has demonstrated thatestimation it is feasible optimally a component DALs, based on a cost of to implementing demonstrated that it is feasible to optimally allocate DALs, based on a cost a component for a given DALestimation (Sorokos,ofetimplementing al., 2015). The approach based on a cost estimation of implementing a component for a given et al.,Performed 2015). The approach makes use ofDAL the (Sorokos, Hierarchically Hazard and for a given DAL (Sorokos, et al., 2015). The approach makes of the Hierarchically Hazard tool and Origins use Propagation Studies Performed (HiP-HOPS) makes use of the Hierarchically Performed Hazard and Origins Propagation Studies (HiP-HOPS) tool (Papadopoulos, et al., 2011). Origins Propagation Studies (HiP-HOPS) tool (Papadopoulos, et al., 2011). (Papadopoulos, et al., 2011). The method presented here expands on this notion to The method presented here expands this notion to produce a safety case fragment from thisonallocation which The method presented here expands onallocation this notion to produce a safety case fragment from this which can form the basis of a preliminary safety case. Previous produce a safety case fragment from this allocation which can the basis of a preliminary safety case. Previous workform towards automating construction of safety cases in can form the basis of a preliminary safety case. Previous in work automating construction safety cases on (Basir,towards et al., 2008) and (Denney, et al., of 2013) focused work towards automating construction of safety cases in (Basir, et al., 2008)cases and for (Denney, et al., 2013) focused on generating safety automatically generated code (Basir, et al., 2008)cases and (Denney, et al., 2013) focused on generating safety automatically generated code based on formal softwarefor safety certification. An approach generating safety cases for automatically generated code based on formal software safety Anal., approach comparable to ours can be seencertification. in (Sljivo, et 2015). based on formal software safety Anal., approach comparable ours can be seencertification. inthere (Sljivo, 2015). Although at tofirst glance similar, are etconsiderable comparableat tofirst oursglance can besimilar, seen inthere (Sljivo, al., 2015). Although are etconsiderable Although at first glance similar, there are considerable

2405-8963 © 2016, IFAC (International Federation of Automatic Control) Hosting by Elsevier Ltd. All rights reserved. Copyright © 2016 IFAC 25 Peer review under responsibility of International Federation of Automatic Control. 25 Copyright © 2016 IFAC 10.1016/j.ifacol.2016.11.005 Copyright © 2016 IFAC 25

2016 IFAC AMEST 26 October 19-21, 2016. Biarritz, France

Ioannis Sorokos et al. / IFAC-PapersOnLine 49-28 (2016) 025–030

in (Alexander, et al., 1977) and (Gamma, et al., 1994). Argument patterns attempt to capture good practice in safety case design by “abstracting the argument strategy from the details of a particular argument” (Hawkins & Kelly, 2013, p. 3).

differences. Their approach constructs safety arguments from ‘safety contracts’, specifications of necessary safety properties for particular commercial-off-the-shelf software components. The safety contracts are generated from model of the subject software specified in Fault Propagation and Transformation Calculus (FPTC). Our approach is applicable from the early stages of design, requiring less rigorous annotation of system architecture models instead of formal methods for software components. It can be combined freely with other approaches for automatic or traditional manual production of safety cases. We should note that the concept of DALs is shared throughout numerous standards, commonly referred to as Safety Integrity Levels (SILs). Thus, the method presented here can be generalized across such standards as the domain-neutral IEC 61508 and the automotive-domain ISO 26262 which use SILs as well.

2.2. Civil Aircraft Safety Assessment. The framework for producing the evidence necessary for safety assurance is typically provided through the guidelines of one or more safety standards relevant to the subject system. Depending on the industry, the system may need to be certified by independent authorities and/or official regulatory bodies. The safety standard ARP4754-A and its supporting documents provide guidelines for developing systems compliant with regulations for civil aircraft development. As mentioned in the introduction, the safety assessment process the ARP4754-A advocates, is centralized around the concept of Development Assurance Levels (DALs) (SAE, 2010, pp. 22-23), commonly known in other standards as Safety Integrity Levels (SILs). These levels are assigned to subsystems and components of the system’s architecture and encapsulate the rigor with which safety assessment activities are conducted. Both the regulations and the standard itself advocate conducting safety assessment in a top-down process, mirroring the evolution of the system’s development.

The following section introduces the development of safety cases and the ARP4754-A standard. The method of automatic allocation of DALs will also be briefly presented, as it provides the backbone of the safety case construction. In Section 3, the method for producing the safety argument is presented. In Section 4, the method is applied to a simplified model. The model is then modified and the method re-applied to illustrate the benefits of automation. The final section includes a discussion of the method’s implications together with relevant and further work.

The ARP4754-A places the safety assurance processes in the context of the ‘v-model’ of system development (SAE, 2010, p. 24). Under this v-model, the early stages of system development involve the identification and analysis of the system’s functionality, i.e. the system’s functions. A Functional Hazard Analysis (FHA) is recommended to elicit the hazards associated with the failure modes of each function (SAE, 2010, p. 31). Each hazard is classified into one of five categories of severity, ranging from No Effect, Minor through to Catastrophic. Depending on the hazard in question, mitigation measures, system requirements or design choices might also be considered.

2. BACKGROUND 2.1. Introduction to Safety Argument Notation Safety argument notations such as the Goal Structuring Notation (GSN) and the Claims Arguments Evidence (CAE) notation (also known as the Adelard Safety Case Development/ASCAD notation) were introduced to provide a structured approach to constructing and representing safety arguments. In both notations, graphical shapes depict elements considered fundamental to structuring any given safety case. The philosophy behind the identification of these elements is largely attributed to the work of philosopher Stephen Toulmin on the analysis of practical argumentation (Toulmin, et al., 1984). These elements are the safety case’s claims/goals, arguments/strategies and evidence/solutions in CAE/GSN respectively. Claims describe attributes, objectives or constraints that the underlying system is argued to achieve. Evidence is factual information which supports the truthfulness of the claims made. Arguments connect claims to evidence by explicating the rationale which links them. As both of these notational systems have developed, additional concepts have been introduced. Of particular interest are GSN’s argument patterns and parameterized arguments. Safety argument patterns are inspired by the concept of architectural and software design patterns found

At this point, development proceeds to identifying the system architecture responsible for implementing each function. Once this relationship has been established, a qualitative failure analysis, such as Fault Tree Analysis (FTA) (Vesely, et al., 1981), is conducted to determine if and how failures in the underlying systems can trigger a hazardous functional failure. Through FTA, the minimum combinations of system failures which are necessary and sufficient to cause a function to fail can be determined. These are commonly known as ‘minimum cut sets’ and in the ARP4754-A are referred to as Functional Failure Sets (FFSs) (SAE, 2010, p. 11). This is a recursive process; when sub-systems supporting each system are introduced, FTA or an equivalent analysis will be conducted to determine their failure contribution to the system’s and a 26

2016 IFAC AMEST October 19-21, 2016. Biarritz, France

Ioannis Sorokos et al. / IFAC-PapersOnLine 49-28 (2016) 025–030

overhead. Thus, assessment activities remain synchronous to the main development effort and provide meaningful feedback to it from the earliest stages of development. The approach presented here further supports MBSA, by extending the notion to include the construction of safety arguments from a system’s architectural and failure model and its safety analyses. We will now briefly describe the process of automatically assigning DALs in more detail, as it provides the basis for the safety argument we construct.

DAL will be assigned to them as well. At every level of application, validation of the DALs and other requirements assigned is performed to ensure that they indeed address the higher-level requirements. The process terminates upon reaching components that cannot be further refined. The safety assessment process resumes when the implementation of the components has been completed. This is achieved by verifying in a bottomup sequence that each level of architecture correctly implements the requirements set during the design stage. The process of allocating DALs to lower architectural levels of the system is also referred to as ‘decomposition’. The reason behind this is that safety standards typically allow the option of reducing the DALs of the subsystems when the system features fault tolerant design e.g. through redundancy. Once the FFSs for a given function or system are known, the ARP4754-A allows two options for allocating DALs to the members they contain (SAE, 2010, p. 44): 



27

2.3. Automatic Allocation of DALs We will begin by presenting an example of DAL decomposition on a small abstract system. The system’s architectural model can be seen in (Fig. 1).

First, one of the members of a FFS is assigned the same DAL as the system and the rest of the members of that FFS allowed a DAL of up to two levels lower than the system’s DAL. Second, two of the members of a FFS, are assigned one DAL lower and the rest of the members of that FFS up to two DALs lower than the system’s. In cases where there is only one sub-system, the first option is applied.

Fig. 1. Example Abstract System requiring DAL allocation. The system features a single output and is composed by three individual elements, A, B and C, which could be either components or systems themselves. The logical gates indicate how failure of the elements can cause the system’s function to fail. In this case, the system can fail if either A and B fail or C fails. Let us assume that the system has been assigned DAL A from earlier stages of development. Following ARP4754-A’s advice, to allocate DALs onto the system’s elements, we have the following options, seen in Table 1.

While there are only two options for a single combination of members that can cause system failure, the total number of combinations increases very rapidly as the alternatives across a system increase. An important consideration in allocating DALs is that implementing higher level DALs can incur an increase in development time and thus, there is incentive to minimize such costs. Previous research has investigated this issue for both the automotive SILs as well as the DALs, in (Azevedo, et al., 2014) and (Sorokos, et al., 2015) respectively. HiP-HOPS (Papadopoulos, et al., 2011) allows FTA to be performed automatically. This is achieved by annotating the system model with local failure behaviour information. From this information, the tool then synthesizes local fault trees locally, which it then combines into a unified fault tree for the model. Finally, the tool analyzes this fault tree, qualitatively, to determine the FFS, as well as quantitatively, to determine the overall probability of failure of the given system.

Table 1. DAL Decomposition Options Allocation/Element Option 1 Option 2 Option 3

A DAL A DAL C DAL B

B DAL C DAL A DAL B

C DAL A DAL A DAL A

Note that element C is always assigned a DAL of A (i.e. the system’s DAL) as it can cause the system’s failure on its own, as it is the only member in its FFS. The other two elements need to fail in combination to trigger systemic failure, so the possibilities for allocation are derived from the two options, as described in section 2.3. The total range of options for allocation is formed by combining the possibilities from each FFS. To determine which option is the most cost-effective, some evaluation of the cost of implementing each element of the architecture with a given DAL must be provided. This evaluation can differ depending on the element in question, however one reasonable constraint is that the element’s cost must

Finally, we should note that HiP-HOPS and the automatic allocation of DALs (to be described next) are both methodologies which support the paradigm of ModelBased Safety Analysis (MBSA) (Joshi, et al., 2006). Under MBSA, the system’s model is extended to include both the nominal as well as its failure behavior. Safety assessment processes can then be applied with minimal information 27

2016 IFAC AMEST 28 October 19-21, 2016. Biarritz, France

Ioannis Sorokos et al. / IFAC-PapersOnLine 49-28 (2016) 025–030

allocation options). By avoiding these recently applied moves the search can be guided towards different areas, with potentially globally optimal solutions. To moderate the effect of the Tabu Tenure, an Aspiration Criterion is employed, allowing a Tabu move providing it leads to a candidate solution that beats the Tenure’s current best candidate in terms of overall DAL cost.

increase as the DAL increases. For the example system we use the cost function in Table 2 (costs chosen for illustrative purposes only). Table 2. DAL Costs for Example System DAL

A

B

C

D

E

Cost

50

40

20

10

0

3. MODEL-BASED SAFETY ARGUMENT CONSTRUCTION

Given this cost distribution, we can easily determine that the options which both satisfy the standard’s constraints and minimize the cost are Option 1 and Option 2 (their total cost is 120, whereas Option 3’s is 130). However, this is a trivially simple system, where the possible options are easily enumerable. For more complex systems, even of slightly larger size than the example, the problem can quickly become intractable. This means that is it unfeasible to exhaustively search the design space of these options, as the amount of time required would be prohibitive for any practical development activity.

To construct the preliminary safety argument we elicit the underlying argument within the Preliminary Aircraft Safety Assessment (PASA) process of ARP4754-A (SAE, 2010, pp. 13, 34). The PASA investigates how hazards of the aircraft’s functions could be caused by system failures. The method we suggest extends that of the DAL allocation presented in Section 2.3. In summary, the safety engineer annotates a model of the system’s architecture with local failure behaviour information. HiP-HOPS then automatically analyzes the model for failures via FTA and generates FFS. Finally, DALs are automatically and costoptimally assigned across the architecture. At this point, we can apply the PASA rationale, as explained earlier, to generate a safety argument structure. In (Fig. 2), a simplified safety argument structure generated from the example system in (Fig. 1) (with Option 1 from Table 1) is shown.

We can define the problem of cost-optimally allocating DALs as a Constrained Optimization Problem (COP). To solve a COP, there are two broad categories of techniques typically applied; linear programming (Dantzig, 1998) and metaheuristic techniques (Blum & Roli, 2003). In the former category lie techniques which analyse and exploit the structure of the space of feasible solutions (solutions that do not violate the constraints) to deterministically find an optimal solution. Metaheuristics are a class of optimization techniques which employ a heuristic search strategy. Metaheuristics offer both improved scalability, as well as accommodating complex constraints and cost functions. Often, these strategies are inspired by natural processes. A drawback of metaheuristics is that they do not guarantee an optimal solution, especially when they include stochastic processes. However, applying them typically yields near-optimal results (Azevedo, et al., 2014, p. 4), which in our view is an acceptable compromise for improving a system’s design. We chose to employ a particular metaheuristic method, Tabu Search, based on its performance when solving the individual problems of allocating ASILs or DALs, seen in (Azevedo, et al., 2014) and (Sorokos, et al., 2015) respectively. Tabu Search operates by initiating the search at a random, feasible solution of the problem instance. In the case of our problem, each solution is an allocation of DALs across the system’s elements. For a set number of iterations, the search successively examines neighbouring solutions looking for solutions that are lower in cost. In the problem’s case, this means selecting options of DAL allocations which are lower in cost. To reduce the risk of continually cycling through solutions that are locally, but not globally, optimal the technique uses a memory structure, the Tabu Tenure. The Tenure records best solution found so far and the recently applied moves (DAL

Fig. 2. Example Abstract System Safety Argument The notation chosen to express the argument is a simplified version of the GSN. Claims are shown as rectangles, arguments as parallelograms and context as 28

2016 IFAC AMEST October 19-21, 2016. Biarritz, France

Ioannis Sorokos et al. / IFAC-PapersOnLine 49-28 (2016) 025–030

29

this, evidence in favor of satisfying DAL A for the subsystem itself is provided, as well as an additional argument. This argument claims that all the elements of the subsystem contributing to the hazard have also been mitigated via DAL allocation as well. Appropriate (yet undeveloped) claims for components C and D then follow.

ovals. The arrows point in the direction of the elements which are supported. The argument claims that the system is safe if all of its hazards have been addressed i.e. (their risk has been) ‘mitigated’. To do so, each of the components contributing to the system function and the hazard must have been assigned a DAL. The claim arguing that each component acceptably mitigates the hazard (as required by the DAL) is left ‘undeveloped’, marked with a triangle underneath. Further claims and evidence supporting how each component satisfies its DAL would follow. Assume that after viewing the safety argument structure, the design of the system is altered so that C is paired with another component D and that together they form a sub-system as seen in (Fig. 3).

It is important to note that both the original and the modified argument structures can be produced automatically from the model of the system as this evolves during the design. This facilitates the maintenance of the design assets involved in the assessment and certification of safety critical systems. The generated argument structures are only partial and need to be supplemented by evidence. This evidence must show that allocated component requirements as well as any assumptions of component independence, fault propagation, fault mitigation and fault tolerance have been met in practice. Standards define the type of evidence required to claim that certain DAL levels have been achieved. Some of this evidence can be provided by safety analyses such as fault trees or FMEAs which can also be generated using the methods outlined in this paper. However, the focus of this paper has been on the synthesis and maintenance of the structure of safety arguments as opposed to the evidence needed to substantiate them. With regards to the applicability of our method in industrial practice, we should note the following points. First, as shown in (Azevedo, et al., 2014), this approach to SIL allocation scales well (at least for ASILs). We are currently conducting larger-scale studies in applying our process to better evaluate it for DALs as well. Preliminary results indicate the performance is comparable to that of ASIL allocation. An abstract flight control system, based on the one found in the Airbus A320, is one such example of ongoing work. Provided the method is confirmed to scale well, the step of producing the argument fragments is fairly straightforward. The method should therefore be applicable to systems found in safety-critical industries. Finally, we aim to incorporate the method we have presented here as a feature in an upcoming version of the HiP-HOPS tool.

Fig. 3. DAL Decomposition Abstract System Modified The new safety argument structure can be seen in Fig. 4.

4. CONCLUSION We have produced a generic preliminary safety argument structure which addresses the decomposition of safety requirements from functions down to components of an aircraft under the guidelines of the ARP4754-A. The focal point of our argument is that it is possible to capture the recursive decomposition of safety requirements advocated by the standard algorithmically. By doing so, a basis for forming larger and more detailed arguments can be established. These safety arguments can be maintained much more efficiently in the face of inevitable design changes, as demonstrated in section 3. Furthermore, given the widespread use of SILs in other domains, this approach

Fig. 4. Modified Abstract System Safety Argument Fig. 4 shows the part of the argument structure that has changed from (Fig. 2), namely the new claims involving the introduced subsystem. The argument now claims that in addition to components A and B, the subsystem’s DAL also contributes to the mitigation of the hazard. To support 29

2016 IFAC AMEST 30 October 19-21, 2016. Biarritz, France

Ioannis Sorokos et al. / IFAC-PapersOnLine 49-28 (2016) 025–030

EOSAN, 2011. Preliminary safety case for ADS-B airport surface surveillance application. PSC ADS-B-APT.

is generalizable to those domains as well. As far as we know, there currently exists no alternative approach to generating safety arguments based on automatically allocated SILs. Alternative approaches that address process-based arguments rely in their majority on verification information or processes. There are numerous possibilities for extending this methodology. In (Weaver, 2003) a safety argument pattern catalogue for the ARP4754-A is presented. This catalogue has been extended in (Ye, 2005) and (Hawkins & Kelly, 2013). Thus, it is possible to translate and adapt our process to develop a more complete and argument structure, closer to standard compliance. In (Rushby, 2015, p. 8), the author argues in favor of revising safety standards to be structured as “assurance case templates”. Further arguments are made for developing community-developed patterns, which would explicate the implicit arguments found in standards to guide safety case production. One such attempt is the Explicate ‘78 project (Holloway, 2015), which focuses on the DO-178C standard. We feel these views to be consistent to our approach and will investigate extending the method to cover the component development guidelines in DO-178C for software and other supporting documents to ARP4754-A. The safety argument fragments auto-generated in (Basir, et al., 2008) and (Denney, et al., 2013) via formal analysis of software, could complement our approach for parts of the system which employ formal methods, especially during the verification stage.

Gamma, E., Helm, R., Johnson, R. & Vlissides, J., 1994. Design Patterns: Elements of Reusable Object-Oriented Software. 1st ed. USA: Addison-Wesley. Hawkins, R. & Kelly, T., 2013. A software safety argument pattern catalogue, York: University of York. Holloway, M., 2015. Explicate '78: Discovering the implicit assurance case in. Bristol, UK, CreateSpace Independent Publishing Platform. Joshi, A., Heimdahl, M., Miller, S. & Whalen, M., 2006. Model-based safety analysis. Nasa Langley Research Center. Kelly, T., 1998. Arguing Safety – A Systematic Approach to Safety Case Management. York: University of York. Kelly, T., 2004. A Systematic Approach to Safety Case Management, Detroit: SAE International. Papadopoulos, Y., Walker, M., Parker, D., Rude, E., Rainer, H., Uhlig, A. & Lien, R., 2011. Engineering failure analysis and design optimisation with HiP-HOPS. Engineering Failure Analysis, 18(2), pp. 590-608. Rushby, J., 2015. The Interpretation and Evalutation of Assurance Cases, Menlo Park, CA, USA: SRI International.

REFERENCES

SAE, 2010. ARP4754-A: Guidelines for Development of Civil Aircraft and Systems. 2nd ed. SAE International.

Alexander, C., Ishikawa, S. & Silverstein, M. (1977). A Pattern Language: Towns, Building, Construction. 1st ed. Oxford University Press.

Sljivo, I., Gallina, B., Carlson, J., Hannson, H. & Puri, S., 2015. A Method to Generate Reusable Safety Case Fragments from Compositional Safety Analysis. In: Software Reuse for Dynamic Systems in the Cloud and Beyond. Springer International Publishing, pp. 253-268.

Azevedo, L., Parker, D., Walker, M. & Esteves, A., 2014. Assisted Assignment of Automotive Safety Requirements. Software, 31(1), pp. 62-68. Basir, N., Denney, E. & Bernd, F., 2008. Constructing a safety case for automatically generated code from formal program verification information. In: Computer Safety, Reliability, and Security. Springer Berlin Heidelberg, pp. 249-262.

Sorokos, I., Papadopoulos, Y., Azevedo, L., Parker, D., Walker, M., 2015. Automating Allocation of Development Assurance Levels : an extension to HiP-HOPS. IFACPapersOnline, 48(7), pp. 9-14. Toulmin, S., Rieke, R. & Janik, A., 1984. An introduction to reasoning. 2nd ed. New York: McMillan Publishing.

Bishop, P., Bloomfield, R. & Guerra, S., 2004. The future of goal-based assurance cases. Florence, IEEE, pp. 390395.

Vesely, W., Goldberg, F. & Roberts, N., 1981. Fault Tree Handbook. 1st ed. Washington DC, USA: Nuclear Regulatory Commision.

Blum, C. & Roli, A., 2003. Metaheuristics in combinatorial optimization: overview and conceptual comparison. ACM Computing Surveys, September, 35(3), pp. 268-308.

Weaver, R., 2003. The safety of software: Constructing and assuring arguments. 1st ed. York: University of York.

Dantzig, G., 1998. Linear programming and extensions. Princeton, NJ, USA. Princeton university press.

Ye, F., 2005. Justifying the use of COTS Components within safety critical applications. York: University of York.

Denney, E., Pai, G. & Whiteside, I., 2013. Hierarchical safety cases. 1st ed. 478-483: Springer Berlin Heidelberg. 30