Personas Beneficiarias de los Programas para la Inserción Laboral

This section presents a template hybrid argument, linking the bottom-up contract supported argument fragments with a top-down argument, decomposed based on the system architecture. Whilst this approach may not have a direct presentation of how specific hazards or functions are supported, if the hazard data it is based on is correct then it should remain compelling. This approach is the simplest to implement if OSSAP and SCONE are used, and potentially the simplest to maintain following a change to the system. Whilst maintenance is not directly addressed in this thesis, safety contracts have the potential to be used to ease the amount of recertification needed after a change. Therefore it is logical to create a safety case which may also ease the amount of recertification required. Maintenance is discussed in the final chapter as an area for further research. The top-level template is shown in Figure 39, using the notation developed by Kelly for safety case patterns [28]. The template has been constructed based on a division between internal component behaviour which could affect system safety and behaviour via component interactions (both direct and indirect). The various elements are now described. Goal G1 states that {System X} is acceptably safe. {System X} must be instantiated to name the system using the OS named as {OS Y}. This goal has two pieces of contextual information, C1 describing what acceptably safe means for that system (e.g. hazards sufficiently addressed, reliability targets) and C2 detailing the system architecture and constituent components.

The strategy for the argument is described in S1. Contextual information for this strategy is a description of the components and their interactions (C4). The quality of the information in C4 will determine the validity of the final argument, since further decomposition is based on this. Context C3 is a list of defined system hazards, used to support lower level goals and evidence. At the bottom level are G5 and G7. These are generic goals which argue that both internal component behaviour and component interactions are acceptably safe, where the components may be of any type. G4 is a more specific version of G5, which uses placeholders {application M} and {OS Y} to describe generic interactions between a defined application and OS. G6 is a more specific version of G7 for an application, again using the placeholder {application M}. This decomposition is based on the failure divisions described in the working definitions of section 3.1. There is no instantiation of G7 for the internal behaviour of the OS since none of its behaviour should directly affect system safety without impacting on another component (e.g. an application). The discussion in section 3.3 on locations of failures justifies this in more detail. An instantiation of G7 should be made for the processor however, for its possible affects on system safety (e.g. overheating) as discussed in section 3.3.2.

G4

{OS Y} conribution to system safety for {Application M} is acceptably safe View 1 G8 {OS Y} services demonstrated to be adequate to support {Application M} G9

{Potentially hazardous failures 0- N} due to {OS Y} have been sufficiently mitigated for {Application M}

G10

Inactive/dead code in {OS Y} does not prevent acceptably safe operation for any application or does not exist

G11

{Application M} and {OS Y} interactions evidence doesn't conflict with other applications/ OS evidence

G12

{Derived argument strategy} demonstrating {Failures 0-N} mitigated is supported

G13

{Contract} which ensures {Failures 0-N} mitigated is met

G14

All relevant {OS Y} failures for {Application M} have been indentified and set of contracts and arguments is complete

0-n 0-n

Figure 40 Safety argument linking top-down and bottom-up argument templates

Figure 40 presents a decomposition of goal G411. Here the definition of “acceptably safe” has been decomposed into two parts – G8 addressing whether the feature requirements are met, and G9 addressing whether the derived safety requirements are met. G8 will be supported by the functions mapping (as described in 6.2). G9 will be partially supported by instantiations of the contracts and derived arguments templates.

G14 states that the relevant failure behaviour must have been identified (i.e. to ensure the set of instantiated contracts are valid) and that the set of contracts and arguments is complete.

11

Note that only G4 is decomposed further in this thesis. Areas of further work including other component interactions are discussed in more detail in Chapter 9.

G11 states that the contracts must not conflict with one another. This is an extremely important goal in a system with more than one application supported by the OS. Consider the following situation. A template contract C which protects against failure mode F may have two potential methods to support the DR, M1 and M2. Suppose two applications find F to be a relevant failure. Then suppose one application developer picks M1, and designs their software accordingly and another picks M2 and designs their software accordingly. It is then possible for instances of C with both M1 and M2 to exist in the same safety case. If M1 and M2 are conflict with one another then system safety cannot be assured. It is unlikely this situation would arise where the OS supports only one application, as theoretically the evidence gathering process should uncover the inconsistency. Nevertheless it is strongly recommended that evidence supporting this goal be provided. Detecting conflicts when multiple applications are used forms one area for further research.

G10 states that any unused functionality in the OS should be identified and shown to be safe. Again, this is listed under component interactions, because it is the OSs effect on other components which is important. This also forms an area for further research.

G12 links the template shown in Figure 37 (derived argument strategies) to the top down goal. This should be instantiated for each relevant derived argument. G13 links to the contract template shown in Figure 36. Again this should be instantiated for each relevant contract. Thus the evidence provided by SCONE and OSSAP can be presented as part of a system safety case, arguing that an acceptable level of safety has been achieved.