This section lists the sets of evidence identified in 6.3.2 to support the system safety case. The evidence has been categorised as either direct evidence (i.e. that which demonstrates specific safety requirements have been met) and backing evidence (i.e. that which demonstrates that the direct evidence adequately supports the safety argument). The latter will be extremely important for a fragmented design approach supported by OSSAP and SCONE.
6.4.1. Demonstrating OS feature requirements are met
Direct evidence supporting the claim that feature requirements have been met can be provided in the form of the mapping of API calls and services to high-level functions. Backing evidence to this claim will be an assessment of the completeness of the high-level functions, and the completeness of the API calls and services list. As has been discussed (see section 4.4) there is often some latitude in the way the mapping is applied so the competency of the safety engineers applying the process
may need to be demonstrated. Alternatively, independent review of the evidence may be an acceptable means to demonstrate its validity.
6.4.2. Demonstrating OS hazard based requirements are met
Part of the direct evidence demonstrating that hazard based requirements have been met comes in the form of the safety contracts. The contracts contain direct evidence that a derived requirement is met, via evidence that the listed constraints have been met. Matching of OS failures to hazards at the system level is used to demonstrate relevance. Thus there is traceability from specific hazardous failures to low level evidence. The contract goals also required backing evidence that the conditions are adequate for a particular application or situation.
The following sets of backing evidence were identified in the safety argument to support the usage of the set of safety contracts:
• Evidence that all OS related application failures have been identified (G14).
• Evidence that the set of contracts is complete. If all the relevant application failures have been identified then as long as a contract exists for each failure then they can be deemed to be complete (G14).
• Evidence that the constraints within the contracts are complete (G14).
• Evidence that the multiple instances and instantiations of contracts are not in conflict with one another (G11).
• Evidence that inactive or dead code does not conflict with the OS/application functionality (G10)
In addition, instantiations of the derived argument strategies also directly demonstrate that hazard based requirements have been met. However the evidence supporting these will be developed on a case-by-case basis so no criteria for backing evidence can be provided.
6.4.3. Demonstrating system level requirements are met
The top level part of the safety argument has been decomposed based on the system architecture.
This approach will only be successful if the following evidence has been provided:
• A complete architectural model (C2) – this model will need to identify all system components. In addition a list of all interactions between applications, OS and hardware
will need to be provided, as well as details of internal behaviour (C4). There are two points of note.
1. The argument decomposition for other components may not need to follow this route, however if it does all interactions and internals behaviours of other components will need to be identified.
2. Whilst this thesis has examined some of the contributions of processing hardware to the operation of both the OS and applications, it only provides specific guidance on the interactions between the OS and applications (see section 3.1.5). The examination of processing hardware (in particular it’s interactions with application software) forms one of the proposed further avenues of research.
• A complete list of system level hazards and their severity (C3), along with a definition of
“acceptably safe” (C1) - the relevance/importance of application failures can only be determined if this information is available. Much literature is available on this subject (see 2.2.1.1) and the findings are not repeated here.
The application model forms backing evidence that the safety argument decomposition approach is sound. The hazard list could similarly be viewed as backing evidence, in that its existence ensures the validity of the application failure assessment. However, given the importance of hazard assessment in demonstrating system safety this thesis views it as direct evidence supporting the safety case.
6.5. Conclusions
The chapter demonstrated how safety requirements were met by SCONE and OSSAP evidence and presented a safety argument template which can be instantiated by developers using these methods.
The chapter described both direct evidence (from SCONE and OSSAP), and backing evidence required to support the argument. The latter was required to demonstrate that the direct evidence was sound.
The argument templates were decomposed based on a division between the two types of failure described in working definitions 1 and 2, namely OS failures and internal application failures. This is not a purely architectural decomposition (where an individual components contribution to system safety is assessed) since the OS and application interactions lead to OS failures. In addition some features of the OS are dependent on the underlying hardware, as are some features of the application (see the alternative “sideways” diagram shown in Figure 12). For a first iteration of a
safety case this overlap will not cause a problem, as the analysis processes examine these interactions independently. Following a change to the system it is important to ensure these overlaps do not lead to an unintended side effects or invalidate the contract evidence. For example, if an OS constraint is dependent on the processor and the processor is changed then this may have a knock on effect on the application. Therefore it is important to list all OS and application hardware dependencies in the contracts and describe the interactions fully in the contextual data. Further research into supporting maintenance using contracts is discussed in the final chapter.