1. Industrial Avionics Working Group 19/04/07 Modular Certification Developing Safety Case Modules

2. Industrial Avionics Working Group 19/04/07 How to Develop an IMS Modular Safety Case Based on experience from an industrial case study –parallel certification study Scoped to replace an existing ‘traditional’ Software Safety Case Software Safety Requirements –‘flowed down’ from system level analyses –Refined using software analysis methods Research contract assumes context of DEF STAN 00-56 issue 3 Actual project uses DEF STAN 00-56 issue 2

3. Industrial Avionics Working Group 19/04/07 Safety Requirements Safety Argument Module

4. Industrial Avionics Working Group 19/04/07 Overview SR Module provides the top level goal for the whole software safety case –“Operation of OFP software on Mission Computer is sufficiently safe” Responsible for showing the safety requirements are met by allocating each safety requirement to Application Blocks to discharge SR Module is only argument that mentions safety, as all other modules only argue about guaranteeing behaviour Two main claims supported in SR Module are: –All Software Safety Requirements (SSRs) are addressed Product Argument –All SSRs have been correctly identified Process Argument

5. Industrial Avionics Working Group 19/04/07 SR Module Architecture Module is split into two: –Safety Requirements argues the SRs are addressed –SR Process argues that the SRs are correctly identified by arguing about the Process used to derive them SR Process is contained within the Safety Requirements Module –Process supports the main product argument but is not needed by other modules

6. Industrial Avionics Working Group 19/04/07 SR Module Interface SR Module provides the following public goal to other argument modules This goal would for example be referenced by a system safety argument to reason about the safety of the software component The following goal requires support from other Modules

7. Industrial Avionics Working Group 19/04/07 Software Safety Requirements Addressed The argument is hazard-driven –Argue over each SR relating to each hazard Each requirement gets mapped to guarantees provided by the arguments of one or more Blocks in the Application layer A SC contract has then be formed with each of the Blocks identifying the guaranteed behaviour of the Block which supports each safety requirement The Safety Requirements Module provides no evidence, all evidence is provided by the supporting Modules

8. Industrial Avionics Working Group 19/04/07 SR Process Argument that the SR derivation process is: –Adequate - considers all potentially hazardous behaviour –Followed - in order to identify the set of SRs The details of the analysis process will be specific to the system but should consider: –Identification of required behaviour –Analysis of deviations from intent,and its effect on hazards