MODUK DEF STAN 00-56: PART 2 PDF

SCOPE AND APPLICABILITY

This Standard specifies requirements that apply to the Contractor. However, the responsibility for safety is shared by all parties. The requirements placed on the Duty Holder are set down in the relevant Joint Service Publications (JSPs). This Standard has been written to align the requirements placed on the Contractor with the requirements placed on the Duty Holder. The Contractor should discuss the requirements of the relevant JSPs with the Duty Holder when applying this Standard as domain-specific issues may affect the interpretation and scope of application of this Standard. They may also be the source of specific contractual safety requirements. Relevant JSPs may be specified in the contract, but, in any case, specific requirements arising from the JSPs should be clarified and agreed.

The principle of proportionality is fundamental to this Standard. The level of effort expended on safety management and the detail of the analysis should be commensurate with the potential risk posed by the system (i.e. the risk identified before any mitigation has taken place) and its complexity. For example, simple systems may have few safety requirements because of their limited functionality; consequently, compliance with this Standard may be easier to achieve, resulting in a simpler Safety Case. In general, the more complex the system and/or the more onerous the operational requirement, the greater the risk, hence more effort will be required to achieve a safe system and to demonstrate that it is safe. The ultimate test of sufficiency of effort and adequacy of evidence will be the acceptance of the Safety Case; discussion with the Duty Holder and any regulatory authorities should be ongoing through the life of the project to enable effective planning and resource allocation to increase the likelihood that the Safety Case produced at the end of the process is acceptable.

The scale and depth of the safety case and Safety Case Report should be proportionate to uncertainty, not just to safety risk (see the Figure 1 below). Situations where both the problem and solution domain are familiar do not need a great depth of analysis; an example is a ship stability certificate. Many uses of systems fall into the familiar solution, unfamiliar problem quadrant, and the argument is likely to be focused on problem domain analysis. Network Enabled Capability may fall into this quadrant. Use of commercial equipment from another domain is also covered here. Systems which use unfamiliar solutions to familiar problems, e.g. automating tasks which previously were manual, need a justification of why the (novel) solution is acceptable in the context of use. The unfamiliar/unfamiliar quadrant requires much more detailed safety analysis and argument, together with a greater depth of evidence.