Defence Standard 0056

Defence Standard - 0056

Solutions Resources

.	Training Courses
.	Technical Documents
.	News Forums

rcm2 Updates

.	rcm2 New Rail Project
.	Energy Conservation
.	Consultancy

Ministry of Defence

Defence Standard
00-56(PART 1)/Issue 2

13 December 1996

SAFETY MANAGEMENT REQUIREMENTS FOR
DEFENCE SYSTEMS

PREFACE

This Part 1 of Def Stan 00-56 supersedes INTERIM Def Stan 00-56/Issue 1 dated 5 April 1991

i This Part of the Defence Standard describes the requirements for safety management, including hazard analysis and safety assessment. It can be applied during the initiation, feasibility, project definition, full development and production phases of MOD projects embodying safety related components, and for in-service operation, maintenance and modification. This Standard shall be used by Defence Contractors as required by contract.

ii This Standard is one of a family of standards dealing with safety that is being developed or adopted by the MOD, taking into account international standardization activities and supporting research and development.

iii This Standard has been agreed by the authorities concerned with its use and is intended to be used whenever relevant in all future designs, contracts, orders, etc. and whenever practicable by amendment to those already in existence. If any difficulty arises which prevents application of the Defence Standard, the Directorate of Standardization shall be informed so that a remedy may be sought.

iv Any enquiries regarding this Standard in relation to an invitation to tender or a contract in which it is incorporated are to be addressed to the responsible technical or supervising authority named in the invitation to tender or contract.

v This Standard has been devised for the use of the Crown and its contractors in the execution of contracts for the Crown. The Crown hereby excludes all liability (other than liability for death or personal injury) whatsoever and whosoever arising (including, but without limitation, negligence on the part of the Crown its servants or agents) for any loss or damage however caused where this Standard is used for any other purpose

0 Introduction

0.1 Safety is a vital characteristic of defence materiel as it has a dominant impact upon operational effectiveness. It is, therefore, important that satisfactory levels of safety are achieved. To ensure that these levels of safety are achieved, realistic requirements shall be set and an agreed management strategy followed. This strategy shall reflect a continuous and evolutionary approach to the achievement of safety, with the management of the safety tasks being an integral part of project activity, from the initiation phase through to the disposal phase.

0.2 This Standard provides uniform requirements for implementing a system safety programme in order to identify hazards and to impose design techniques and management controls to identify, evaluate and reduce their associated risks to a tolerable level.

0.3 This Standard is specifically directed towards the Contractor’s responsibilities for safety.

0.4 This Standard assumes a working knowledge of the techniques for hazard analysis and safety assessment. Users requiring background information should refer to the publications in clause 2 of Part 2 of this Standard.

0.5 This Part of the Standard should be used in conjunction with Part 2, “Guidance”, which provides information and guidance on implementation of the requirements, with a view to achieving commonality in their interpretation.

1 Scope and Applicability

1.1 This Standard defines the safety programme requirements for defence systems. This Standard requires that careful consideration shall be given to all aspects of systems affecting safety.

1.2 The purpose of this Part of the Standard is to define the safety programme management procedures, the analysis techniques and the safety verification activities which are applicable during the project lifecycle. This is in order to minimize the possibility of a system entering service with unacceptable safety characteristics.

1.3 This Standard shall apply to all phases in the project lifecycle from initiation through to development and production, and on to disposal.

1.4 The activities required for the achievement of safety depend upon the nature and history of the materiel being designed, developed or manufactured, and the use to which the material will be put when it enters service. Therefore the safety planning required by this Standard shall be adapted to suit the particular system and operational domain being considered.

1.5 Appropriate rules, methods and techniques for design and development of the system are the subject of other documents, and are therefore not addressed by this Standard.

1.6 In those cases where all the hazards identified in preliminary hazard analysis are addressed by established, sector specific design standards or other rules applicable to the system, further analysis may be replaced by demonstrable rigorous application of these standards or rules, with the agreement of the Independent Safety Auditor and the MOD Project Manager (MOD PM).

1.7 Risk. The use of the word “risk” in this Standard is in the context of threats to safety. The term should not be confused with project management risk (i.e. risk to costs and timescale). However, it should be noted that proper and timely application of this Standard will reduce the project risk for systems requiring safety certification prior to use.

2 Related Documents

2.1 The following documents and publications are referenced in this Standard.

Def Stan 00-40 Reliability and Maintainability (Parts 1 and 2)
Def Stan 05-91 Quality System Requirements for Design/Development, Production, Installation and Servicing
Def Stan 05-57 Configuration Management Policy and Procedures for Defence Material
Def Stan 00-58 HAZOP Studies on Systems Containing Programmable Electronics

2.2 Reference in this Standard to any related documents means in any invitation to tender or contract the edition and all amendments current at the date of such tender or contract unless a specific edition is indicated.

2.3 In the event of a conflict between the text of this Standard and the references cited herein, the text of this Standard shall take precedence.

2.4 Part 2 of this Standard lists documents that, although not directly referenced in this Part of the Standard, contain detailed information that is related to the scope of this Standard.

2.5 Copies of related documents can be obtained as indicated in the following table.

Documents

3 Definitions

3.1 For the purpose of this Standard the definitions in annex A apply.

4 General Principles

4.1 This clause of the Standard introduces the principles of safety management and provides a summary of the main activities and their relationships. These activities are shown in figure 1.

4.2 Introduction

4.2.1 This Standard requires that safety be considered as an integral part of all defence equipment procurement.

Figure 1 - Principal activities

4.2.2 The practices and procedures set out in this Standard are intended to ensure through a rigorous process of safety assurance that the potential for an equipment to enter service with unacceptable safety characteristics is minimized. The primary purpose of the safety assurance process is to maximize the visibility of equipment safety characteristics at all stages of the project lifecycle. This is achieved through selected analytical assessments and verification activities, carefully integrated with the overall project programme in accordance with a Safety Programme Plan. The results and record of the on-going analytical and verification activities provide confidence that the desired safety characteristics have been designed into the system. The combined results of these activities provide evidence to support a logical argument, usually referred to as a Safety Case, for the deployment of the system into service.

4.3 Safety Management

4.3.1 In order to ensure that satisfactory levels of safety are achieved, a strategy shall be employed that reflects a continuous and evolutionary approach, with the management of the safety tasks being an integral part of the project activity. The management strategy to be employed shall be reflected in a Safety Programme Plan which shall describe the management and technical tasks to be undertaken.

4.3.2 The Safety Programme Plan shall define the safety requirements and targets which are necessary to determine whether a system is acceptably safe. These requirements and targets shall be specified for each accident severity category, each accident or each hazard as appropriate.

4.3.3 In order to implement the safety programme a number of key personnel shall be assigned to a project. The Contractor shall appoint a Project Safety Engineer who shall have responsibility for implementing the tasks identified in the Safety Programme Plan. The Project Safety Engineer shall chair the Project Safety Committee which shall be responsible for endorsing the tolerability of each risk. The Contractor shall appoint an Independent Safety Auditor in accordance with clause 5.3.4 who shall be concerned with the adherence of the Safety Programme Plan to this Standard.

4.4 System Safety Analysis

4.4.1 General. System safety analysis shall be performed to determine whether the level of risk associated with a system has been reduced to a tolerable level. This process involves the identification of hazards and their associated accident sequences, the calculation of safety targets for each hazard and the subsequent assessment of the system to determine whether the safety targets have been met.

4.4.2 Mandatory Activities. The activities to be undertaken depend on the classification of worst risk from the system as defined in clause 7. Mandatory tasks are summarized in table 1. For initial development and changes, analysis beyond Preliminary Hazard Analysis is only required when the system falls in Risk Classes A, B or C. A Hazard Log shall be established in all cases. It shall be maintained for systems of Risk Classes A, B and C. For Risk Class D, it shall be retained and reviewed at the project design reviews to ensure that safety features are tracked and that the Risk Class D classification is still valid. Risk class definitions are given in table 4.

Table 1 - Mandatory Activities

4.4.3 Hazard Identification and Refinement. Hazard identification shall be initiated at the earliest possible stage in the project life cycle. Hazard identification shall be an evolutionary process starting with Preliminary Hazard Listing during the earliest project stages. This shall be followed by Preliminary Hazard Analysis and System Hazard Analysis which shall be conducted on an iterative basis as the programme proceeds, in order to refine and extend the identification and causes of hazards.

4.4.4 Risk Estimation. Probability targets for each accident and the aggregate of system accidents shall be calculated by analysing the risk associated with each accident and determining the tolerable level. The probabilities of the events in the accident sequences shall then be considered to determine the random and systematic elements he hazard probability targets.

4.4.5 Safety Compliance Assessment. The system shall be assessed as to its compliance with the system safety requirements using design analysis and auditing techniques. Corrective action shall be taken in cases where the requirements are not achieved, and the system shall then be re-assessed.

4.5 Safety Verification. Safety verification shall be undertaken to provide confidence that the claimed theoretical safety characteristics of the system have been achieved in practice. A Data Reporting, Analysis, and Corrective Action System (DRACAS) shall be established and maintained in accordance with Def Stan 00-40. The DRACAS shall be used for reviewing all incidents arising during the safety programme. A test programme shall be implemented to establish that the safety features operate as intended.

4.6 Hazard Log. A Hazard Log shall be established to act as a directory for the safety justification, or Safety Case, and shall provide a summary of all safety activities throughout the project lifecycle. The Hazard Log shall be employed as the principal means of establishing progress on resolving the risks associated with the identified hazards. The Hazard Log shall contain details pertinent to each hazard and accident, and shall be updated as new hazards are discovered, or if there are any changes to the existing hazard or accident data.

4.7 Safety Case. The Hazard Log is unlikely to be acceptable as a Safety Case. A Safety Case shall be constructed using information from the Hazard Log. The Safety Case shall provide a well organised and reasoned justification clearly showing that the proposed system is acceptably safe. The Safety Case must describe the system and its boundaries fully. It must also identify the hazards and the risks and indicate the safeguards. A Safety Case is required for all systems that are:
(a) New.

(b) Modifications of existing systems.

5 Management and Associated Documentation

5.1 General. The following general management and control activities shall be conducted in order to achieve the specified contractual safety requirements. Where a project is not concerned with an autonomous system, safety requirements for the overall system shall be taken into consideration.

5.2 Safety Programme Plan

5.2.1 The Contractor shall prepare and maintain a Safety Programme Plan throughout the contract which shall define a safety programme that is planned, integrated and developed in conjunction with other design, development, production and quality control functions.

5.2.2 The Safety Programme Plan shall include the following:
(a) A definition of the purpose and scope of the plan, including the project safety requirements and targets that are expected to be achieved by adherence to it. A definition of the scope of the addressed accidents.
(b) A description of the management structure and interfaces for all safety related activities and the appropriate delegation of responsibility in order to ensure adherence to the requirements of this Standard. This description shall include reference to the Project Manager, Project Safety Engineer, Project Safety Committee and Independent Safety Auditor.
(c) The management and technical tasks to be undertaken including defining the safety analysis tables as defined in clause 7. The contractual deliverables and the necessary resources, procedures, schedules and controls required during the safety programme shall be described,
(d) Rules to define when event driven activities, such as System Change Hazard Analysis, are to be conducted.
(e) The establishment or continuation of the Hazard Log.
(f) A reference to the DRACAS procedure and the test programme employed.
(g) The identification of the measures to be imposed on sub-contractors to ensure that they are aware of the safety requirements and their responsibilities.

5.2.3 The Safety Programme Plan shall be adapted to suit the type of system or equipment and if necessary the phase of the procurement.

5.2.4 The Safety Programme Plan shall be agreed with the MOD PM. Any subsequent changes to the Safety Programme Plan shall be agreed with the MOD PM prior to their implementation.

5.3 Key appointments

5.3.1 Project Manager. The Contractor shall appoint a Project Manager who shall be responsible for all safety activities. The Project Manager shall be vested with adequate seniority and authority to represent the Contractor.

5.3.2 Project Safety Engineer. The Project Manager shall appoint a Project Safety Engineer who shall be responsible for implementing the tasks identified in the Safety Programme Plan. The responsibilities of the Project Safety Engineer shall include, but not be limited to the following:
(a) Chairing the Project Safety Committee.

(b) Defining the accident severity categories, probability categories, equivalent numerical probabilities, accident risk classification scheme and design rules and techniques.

(c) Calculating and apportioning the hazard probability targets and ensuring that they are entered into the design documentation.

(d) Ensuring that all analyses are carried out in accordance with the Safety Programme Plan.

(e) Maintaining the Hazard Log.

(f) Signing and issuing the Statement of Risk Classification.

(g) Approving any proposed design changes for their effect on the safety characteristics prior to their implementation.

(h) Reviewing the test programme to ensure that it adequately establishes the safety features.

(i) Reviewing the incidents arising from the DRACAS to provide information on whether the claimed intended safety characteristics have been achieved.

5.3.3 Project Safety Committee

5.3.3.1 A Project Safety Committee including the following, shall be established by the
Contractor:
(a) The Project Safety Engineer, who shall act as Chairman.

(b) Representatives of the Project Manager, design department and sub-contractors whose tasks may have an impact on the Safety Programme as defined by 5.7.

5.3.3.2 The Project Safety Committee shall be responsible for endorsing the output of the safety reviews as defined in 5.4. If during the course of a Project Safety Committee meeting any of the outcomes of the safety review are not endorsed or if any new hazards are identified, the appropriate corrective action shall be defined and agreed and the Project Safety Engineer shall be actioned to implement it. The minutes of the Project Safety Committee shall be referenced where appropriate in the Hazard Log and any relevant reports.

5.3.4 Independent Safety Auditor

5.3.4.1 The Independent Safety Auditor shall be concerned with the adherence of the Safety Programme Plan to this Standard. An Independent Safety Auditor shall be formally tasked forthwith in all cases where Preliminary Hazard Analysis has identified the existence of risks in classes A or B and risk class B has been deemed to be tolerable, or in other cases as required by the MOD PM. The Independent Safety Auditor shall be one (or more) named individual(s) agreeable to both the Contractor and the MOD PM.

5.3.4.2 Terms of reference for the Independent Safety Auditor shall be formally documented. These terms of reference shall specify all the activities to be carried out by the Independent Safety Auditor and shall be agreed by the Contractor and the MOD PM. The Independent Safety Auditor shall document these activities in an Audit Plan which shall include the following:
(a) A definition of the purpose and scope of the plan.

(b) The management structure and control associated with the function of the Independent Safety Auditor.

(d) Details of how the safety audit programme is to be integrated with the project safety programme.

A sample safety audit programme is shown in Annex C, Part 2 of this Standard.

5.3.4.3 The Independent Safety Auditor shall be sufficiently qualified to carry out the duties assigned, and be sufficiently commercially and managerially independent from the design function so that the safety of the system can be independently assessed and judged. The Independent Safety Auditor shall be free from any possible conflicts of interest.

5.3.4.4 Where, exceptionally, it is necessary for the Independent Safety Auditor to belong to a company that is part of the same trading group as the Contractor, the proposed arrangement shall be justified and shall be agreed with the MOD PM.

5.3.4.5 The Contractor shall give the Independent Safety Auditor full, unfettered and timely access to results of the hazard analyses and other related documentation used or produced by the application of this Standard.

5.3.4.6 The Independent Safety Auditor shall report directly and concurrently to the MOD PM and the Contractor, and be a member of the Project Safety Committee.

5.3.4.7 Continuity of the Independent Safety Auditor personnel throughout the contract is desirable. Any change shall be justified to the MOD PM.

5.3.4.8 The responsibilities of the Independent Safety Auditor shall include, but not be limited to the following:
(a) Auditing of the project for compliance with this Standard and any other project specific standards, guidelines or codes of practice specified in the Safety Programme Plan.
(b) Checking that the safety requirements are adequately specified and that they appropriately influence the design and the development of the user handbook and maintenance procedures.
(c) Auditing the interpretation and any subsequent refinement of accident severity categories, the probability categories, the numerical equivalents for each probability category, the accident risk classification scheme and the design rules and techniques assigned to each Safety Integrity Level.
(d) Auditing the accident severity category assigned to each accident and the derivation of hazard probability targets, both the random and systematic elements. This shall include the probability apportioned to human operations.
(e) Carrying out independent sample analyses of the system.
(f) Auditing the safety verification test programme.
(g) Auditing the documentation produced by the Contractor (and any sub-contractors) during the safety programme.
(h) Auditing the configuration management system used during the safety programme.
(i) Endorsing the Statement of Risk Classification,
(j) Documenting the activities listed in (a) to (i) above.

5.3.4.9 The Independent Safety Audit shall be documented in an Independent Safety Audit Report which shall be updated in accordance with the Audit Plan. The Independent Safety Audit Report shall contain the following information:

(a) An assessment of the adequacy of the Safety Programme Plan.

(b) A summary of the results.

(d) A brief description of the system.

(e) The results of the technical review and audit.

(f) The results of any independent analysis.

(g) Assessment of compliance with this Standard and the Safety Programme Plan.

(h) Progress against the Audit Plan.

(i) Any recommendations for the remainder of the safety programme.

(j) Conclusions and recommendations.

(k) References to all documents examined, including their versions.

(l) Record of the audit activity.

(m) Reference to the Audit Plan.

5.3.5 Quality of staff. The seniority, authority, qualifications and experience of staff to be employed on the safety programme shall be adequate and appropriate for the tasks assigned to them. Key staff curricula vitae shall be submitted to the MOD PM prior to their employment on the project.

5.4 Safety Review

5.4.1 Formal reviews of the safety programme and the associated analyses and assessments shall be carried out by the Contractor as part of the project design reviews. The timing of the formal reviews shall be stated in the Safety Programme Plan. These reviews shall include the following aspects:
(a) Approval of the accident severity categories, probability categories, equivalent numerical probabilities and accident risk classification scheme.

(b) Approval of the appropriate design rules and techniques for each Safety Integrity Level.

(d) Approval of the hazard probability targets.

(e) Approval of the apportionment of the random and systematic elements of the hazard probability targets.

(f) Approval of the results of the analyses carried out.

(g) Approval of the entries in the Hazard Log and supporting documentation.

(h) Approval of the completeness of the Hazard Log.

(i) Approval of the tolerability of the risk associated with each hazard taking into account the combined effect of all other hazards.

(j) Endorsement of the relevant version of the Hazard Log by the Chairman.

5.4.2 If during the course of a review any of the items of 5.4 are not approved or if any new hazards are identified, the appropriate corrective action shall be defined and agreed and the Project Safety Engineer shall be actioned to implement it. The minutes of the Safety Review meetings shall be referenced where appropriate in the Hazard Log and any relevant reports.

5.4.3 The review meetings shall approve the Statement of Risk Classification and action the Project Safety Engineer to issue it.

5.5 Quality Assurance

5.5.1 The quality system requirements laid down in Def Stan 05-91, or MOD (PE) agreed alternatives, shall be applied to all work involving safety management.

5.5.2 An overall Project Quality Plan shall be established. The Project Quality Plan shall define the necessary quality assurance activities associated with the implementation of the Safety Programme Plan.

5.5.3 All tools used during the safety programme shall be documented in the Project Quality Plan and they shall be held under an appropriate configuration management system.

5.6 Configuration Management

5.6.1 The overall Project Configuration Management Plan shall define the necessary configuration management activities associated with the implementation of the Safety Programme Plan.

5.6.2 All items produced as a result of the safety programme, including relevant documentation and all dependent data, shall be held under the configuration management system identified in the Project Configuration Management Plan. The configuration management system shall meet the requirements of Def Stan 05-57, or an alternative equivalent standard is agreed in writing prior to any work commencing.

5.6.3 The configuration management system shall ensure that the Project Safety Engineer receives all information regarding design changes so that they can be assessed and approved prior to their implementation.

5.7 Monitoring and Control of Sub-contractors

5.7.1 The Contractor shall ensure that items obtained from sub-contractors and suppliers enable the system to meet the overall safety requirements as specified by this Standard.

5.7.2 The Contractor shall ensure that sub-contractors and suppliers certify that their functions and components are compliant with the requirements of the Safety Programme Plan.

5.7.3 The Contractor shall ensure that all functions and components obtained from sub-contractors and suppliers are subjected to the analyses described in this Standard. Any hazards identified during this process shall be entered into the Hazard Log.

5.7.4 The Contractor shall ensure that sub-contractors are made aware of the safety requirements apportioned to their functions, that they are reflected in sub-contractor specifications, and that they are consistent with the overall system requirements.

5.7.5 The Contractor shall ensure that the activities of sub-contractors are consistent with the overall Safety Programme Plan. Sub-contractors shall document their activities in a Safety Programme Plan which shall be referenced in the overall Safety Programme Plan and shall be approved by the Contractor.

5.8 Hazard Log

5.8.1 A Hazard Log shall be established to act as a record and directory for the safety justification, or Safety Case, of the system. It shall be maintained as the principal means of establishing progress on resolving risks associated with identified hazards. A procedure shall be defined for the management and control of the Hazard Log. The Hazard Log shall be retained for the entire system lifecycle.

5.8.2 The Hazard Log shall include a description and scope of use of the system to which it relates, together with the safety requirements.

5.8.3 The Hazard Log shall be updated as new hazards are discovered or if data relating to identified accidents or hazards changes. It shall be regularly reviewed by the Contractor. It shall also be updated to reflect information obtained from the DRACAS.

5.8.4 The Hazard Log shall reference all analyses and reports produced during the safety programme, and shall include the following:

(a) The accident severity categories, probability categories, equivalent numerical probabilities and accident risk classification scheme for the system.

(b) The design rules and techniques to be used for each Safety Integrity Level.

5.8.5 The Hazard Log entries shall be endorsed at Project Safety Committee meetings and approved by the Safety Review.

5.8.6 The Hazard Log shall record application of this Standard, and provide documentation of hazards and their control.

5.8.7 The Hazard Log shall contain the following data for each identified accident:

(a) A unique reference.

(b) A brief description.

(d) A cross-reference to the full description and analysis of the accident sequence in the safety programme reports.

(e) A list of the hazards and associated accident sequences that can cause the accident.

5.8.8 The Hazard Log shall contain the following data for each hazard:

(a) A unique reference.

(b) A brief description of the hazard including the functions or components and their states that represent the hazard, together with a reference to the appropriate design documentation.

(c) The related accident severity category and the random and systematic elements of the hazard probability targets appropriate to Risk Classes B and C.

(d) The predicted probability of the random element.

(e) A statement as to whether the hazard requires further action to reduce the risk to a tolerable level.

(f) A discussion of the possible means by which the risk could be reduced to a tolerable level, and notes on the re-evaluation of the accident sequence following such action.

(g) A brief description of any action to reduce risk, with a reference to the design documentation that has changed as a result of the action, or a justification for taking no action.

(h) A cross-reference to the full description and analysis of the hazard in the hazard analysis reports.

(i) For Risk Class A systems, a statement of component criticality.

5.8.9 The Statement of Risk Classification shall be included in the Hazard Log and shall be updated to reflect any change in the System Risk Class. It shall contain the following information:

(a) The name of the system.

(b) A unique statement number.

(d) The System Risk Class.

(e) The references to supporting documentation.

(f) The signatures of the Project Safety Engineer and Independent Safety Auditor.

5.9 Design Documentation

The Contractor shall ensure that the system design documentation contains the following information for each function:
(a) The failure probability target.
(b) The Safety Integrity Level and the corresponding design rules and techniques.
(c) A cross-reference to the hazards associated with the function and the relevant risk reduction measures.

6 Safety Requirements

6.1 The safety requirements shall comprise the safety targets for the system specified for each accident severity category, each accident or each hazard as appropriate.

6.2 The safety requirements shall be entered in the Safety Programme Plan and the Hazard Log. These requirements shall also form part of the Safety Case.

7 System Safety Analysis

7.1 Introduction. The Contractor shall identify hazards and their associated accident sequences, calculate safety targets for each hazard and analyse the system to determine whether the safety targets have been met. The system safety analysis shall be adapted to suit the project and the activities shall be stated in the Safety Programme Plan. In order to avoid obscuring important hazards with insignificant detail, rules shall be developed at this stage to prioritise and select accident sequences for consideration.

7.2 Hazard Identification

7.2.1 General Hazard Identification shall be carried out by means of a stepwise approach involving Preliminary Hazard Listing, Preliminary Hazard Analysis and System Hazard Analysis. System Change Hazard Analysis shall be performed as required by 7.2.5.

7.2.2 Preliminary Hazard Listing

7.2.2.1 Preliminary Hazard Listing shall be performed to identify the main generic hazards and accident scenarios that may be associated with the system. This process shall highlight any areas on which to focus special design attention. The Preliminary Hazard Listing shall be carried out by means of a checklist based approach or other similar method which has been agreed by the MOD PM. The Preliminary Hazard Listing shall also consider previous development and actual in-service incident and accident data relating to similar or other applicable systems. All of the identified hazards shall be recorded in a Preliminary Hazard Listing Report and the Hazard Log. The Preliminary Hazard Listing Report shall be referenced in the Hazard Log.

7.2.2.2 The Preliminary Hazard Listing shall be documented in the Preliminary Hazard Listing Report which shall contain the following information:
(a) A brief description of the system and its domain.
(b) Details of any data from similar systems, including hazards, accidents and initiating events.
(c) A description of the method used to carry out the Preliminary Hazard Listing.
(d) A list of hazards identified which are applicable to the system, including a description and unique reference.
(e) A reference to all source documents used, including versions, dates and status.
(f) Conclusions and recommendations.

7.2.3 Preliminary Hazard Analysis

7.2.3.1 Preliminary Hazard Analysis shall be performed to identify areas of the system which will have an effect on safety by evaluating the major hazards associated with the system. These shall be controlled by engineering or eliminated by re-design. Preliminary Hazard Analysis shall be carried out by means of a HAZOP study (in accordance with Interim Def Stan 00-58 on HAZOP Studies for Equipment Containing Programmable Electronic Systems) or other similar method which has been agreed by the MOD PM. Preliminary Hazard Analysis shall be documented as part of a Preliminary Hazard Analysis Report. Any hazards not previously identified by the Preliminary Hazard Listing shall be entered in the Hazard Log and the entries for any existing hazards and accident sequences updated. The Preliminary Hazard Analysis Report shall be referenced in the Hazard Log. The safety considerations identified in the Preliminary Hazard Analysis Report shall be incorporated into the design documentation and used in the evaluation of design alternatives. The Preliminary Hazard Analysis shall be followed by an initial Risk Estimation and any subsequent changes to the Preliminary Hazard Analysis shall be followed by a review of the initial Risk Estimation.

7.2.3.2 Preliminary Hazard Analysis and initial Risk Estimation shall be documented in a Preliminary Hazard Analysis Report which shall contain the following information:

(a) A brief description of the system and its domain.

(b) A brief description of any sub-systems identified at this phase and the boundaries between them.

(d) A list of identified hazards applicable to the system, including a description and unique reference.

(e) A list of identified accidents applicable to the system including a description, a unique reference and a description of the associated hazards and accident sequences.

(f) The accident risk classification scheme adopted.

(g) Preliminary probability targets for each accident.

(h) Preliminary predicted probabilities for each accident sequence.

(i) Preliminary probability targets for each hazard.

(j) A description of the system functions and safety features.

(k) Details of any checklists or other techniques used.

(l) A description of human error which could create or contribute to accidents.

(m) A cross-reference of the results of Preliminary Hazard Analysis and initial Risk
Estimation to the Hazard Log.

(n) A reference to all source documents used, including versions, dates and status.

(o) A reference to the minutes of any Project Safety Committee meeting or Safety Review held.

(p) Conclusions and recommendations.

7.2.4 System Hazard Analysis

7.2.4.1 System Hazard Analysis shall be performed to refine and extend the identification and causes of hazards and accident sequences from the previous analyses, by consideration of the abstract functions of the system and subsequently the components which implement them. System Hazard Analysis shall comprise the following activities unless otherwise stated in the Safety Programme Plan:

(a) Functional Analysis.

(b) Zonal Analysis.

(d) Operating and Support Hazard Analysis.

(e) Occupational Health Hazard Analysis.

7.2.4.2 System Hazard Analysis shall be documented as part of a System Hazard Analysis Report that shall be referenced in the Hazard Log. The Hazard Log shall be updated to reflect the output from the System Hazard Analysis. The System Hazard Analysis shall be followed by Risk Estimation and any subsequent changes to the System Hazard Analysis shall be followed by a review of the Risk Estimation.

7.2.4.3 System Hazard Analysis and Risk Estimation shall be documented in a System
Hazard Analysis Report which shall contain the following information:

(a) A brief description of the system and its domain.

(b) A brief description of the sub-systems and the boundaries between them.

(d) A list of identified hazards applicable to the system, including a description and unique reference.

(e) A list of identified accidents applicable to the system, including a description, a unique reference and a description of the associated hazards and accident sequences.

(f) The accident risk classification scheme adopted.

(g) Probability targets for each identified accident.

(h) Predicted probabilities for each accident sequence.

(i) Probability targets for each hazard.

(j) A description of the system functions and safety features.

(k) The results of System Hazard Analysis and Risk Estimation, including:

The results of the Functional Analysis.
The results of the Zonal Analysis.
The results of the Component Failure Analysis.
The results of the Operating and Support Hazard Analysis.
The results of the Occupational Health Hazard Analysis.

(l) Details of the analysis of each accident sequence and the sources of any failure rate data used.

(m) A cross-reference of the results of System Hazard Analysis and Risk Estimation to the Hazard Log and Preliminary Hazard Analysis Report.

(n) A reference to all source documents used, including versions, dates and status.

(o) A reference to the minutes of any Project Safety Committee meeting or Safety Review held.

(p) Conclusions and recommendations.

7.2.5 System Change Hazard Analysis

7.2.5.1 System Change Hazard Analysis shall be performed if:

(a) There are any changes to the domain in which the system is installed.

(b) There are any modifications or changes made to the functions or components of the system after design certification.

(d) The system is used for a different application from that for which it was originally designed.

7.2.5.2 The System Change Hazard Analysis shall involve a review of the Preliminary Hazard Analysis and, if extant, System Hazard Analysis Reports. Any changes to the existing hazards, or the identification of new hazards, shall result in a review of the safety targets and the Safety Compliance Assessment. The results shall be documented in updated versions of the system safety programme reports and the Hazard Log. The system specification and design documentation shall be amended to include revised cross-references to the system safety programme reports and the Hazard Log.

7.2.5.3 Rules for when System Change Hazard Analysis is to be performed shall be documented in the Safety Programme Plan.

7.3 Safety Criteria Definition

7.3.1 Introduction. Safety Criteria Definition shall be conducted prior to Risk Estimation and shall involve:

(a) The formulation of the Safety Analysis Tables.
(b) The determination of the design rules and techniques appropriate to the system safety requirements.

7.3.2 Formulation of the Safety Analysis Tables. The following activities shall be carried out by the Project Safety Engineer, endorsed by the Project Safety Committee and approved by the Safety Review. The rationale used in the formulation of the Safety Analysis Tables shall be recorded in the Safety Criteria Report.

(a) Each accident severity shall be categorized during Risk Estimation in accordance with the definitions of Table 2 but in the event that these definitions are not appropriate for the system being considered they may be modified to include other aspects such as system loss or environmental effects. Any modifications shall be agreed by the Independent Safety Auditor and the accident severity categories used for the system shall be recorded in the Hazard Log.

Table 2 Accident severity categories

(b) Distinct safety targets may be agreed for different groups of people who may be harmed by an accident involving the system. For instance, one safety target may be defined for trained personnel who are directly involved with the system; another, more stringent, safety target may be defined for people, such as MOD employees, who are indirectly involved with the system during the course of their duties; and a third, more stringent still, safety target may be defined for people who are independent third parties, such as the general public.

(c) Some systems have a defensive role whereby inaction under hostile circumstances may constitute a hazard. Safety targets for such systems shall address the requirements to reduce, to a tolerable level, the risk resulting from inaction under hostile circumstances. Where there is a conflict between the practical realization of safety targets for action and inaction within the system’s operational role, a reasonable balance of risk reduction shall be established and agreed between the Design Authority, the Independent Safety Auditor and the MOD PM.

(d) The probabilities shall be categorized during Risk Estimation in accordance with the definitions of Table 3 but in the event that these definitions are not appropriate for the system being considered they may be modified to reflect the level of application. Any modifications shall be agreed by the Independent Safety Auditor and the probability categories used for the system shall be recorded in the Hazard Log.

Table 3 Probability Ranges

(e) An equivalent numerical probability shall be assigned to each probability category of Table 3, by taking into account the operational profile of the system. These values shall be agreed by the Independent Safety Auditor and recorded in the Hazard Log.

(f) Using Table 2 and Table 3, together with the risk class definitions of table 4, an Accident Risk Classification Table for the system shall be produced in the format of the example shown in table 5. This table shall show the risk class of each accident severity/probability combination which shall be agreed by the Independent Safety Auditor and recorded in the Hazard Log. For the purposes of the accident risk classification scheme, accidents are considered single events. Any subsequent changes made to the Accident Risk Classification Table shall also be agreed by the Independent Safety Auditor and the Hazard Log shall be updated.

(g) Risk Class A is unacceptable. Class A Risks shall be removed by the use of safety features and the system shall be subject to further analysis in accordance with this Standard.

(h) If following from the mandated activities of table 1 a risk has been classified as Class D, clauses 7.3.3, 7.3.4 and 7.4 of this Standard will no longer apply.

Table 4 Risk Class Definitions

Table 5 Example Risk Classification Scheme

7.3.3 Determination of Design Rules and Techniques. Design rules and techniques appropriate to each Safety Integrity Level, S1 to S4, shall be determined prior to implementation of the functions of the system. These design rules and techniques shall be endorsed by the Project Safety Committee, approved by the Safety Review and recorded in the Hazard Log. The rationale used in the determination of the design rules and techniques shall be recorded in the Safety Criteria Report.

7.3.4 Safety Criteria Report. The rationale used during Safety Criteria Definition and Risk Estimation shall be documented in a Safety Criteria Report which shall contain the following information:

(a) A brief description of the system and the scope of its use.

(b) The rationale used in the derivation of the definitions of the accident severity categories, probability categories, equivalent numerical probabilities and accident risk classification scheme.

(d) The rationale used in the calculation and apportionment of the hazard probability targets.

(e) A cross-reference of the results of Safety Criteria Definition and Risk Estimation to the Hazard Log and safety programme reports.

(f) A reference to the minutes of any Project Safety Committee meeting or Safety Review held.

(g) Identification of safety critical components.

7.4 Risk Estimation

7.4.1 Introduction. Once the safety criteria have been defined as described in 7.3 and agreed by the MOD PM, Risk Estimation shall be conducted to determine the Hazard Probability Targets. Following each hazard identification phase, or its revision, the Hazard Probability Targets shall be reviewed.

7.4.2 Safety Integrity. Safety integrity has two components: random failure integrity and systematic failure integrity. Both these components shall be taken into account when apportioning safety integrity; however, the estimation of systematic failure integrity is much harder than the estimation of random failure integrity. The Standard therefore uses the concept of safety integrity level as an indicator of the required level of protection against systematic failure; each abstract function shall be allocated a safety integrity level at the early design phases, and this shall be inherited by the components that implement the function. Appropriate design techniques shall be associated with each safety integrity level; claim limits shall be set for each safety integrity level that give a measure of the effectiveness of the techniques.

7.4.3 Claim limits

7.4.3.1 In recognition of the fact that systematic failures usually dominate the achieved failure rate of any function or component, particularly where redundant hardware is employed, claim limits shall be determined for each Safety Integrity Level that give the minimum failure rate that can be claimed for a function or component of that level, irrespective of its random failure probability calculated by means of the combination of probabilities. These claim limits shall be based on actual operational experience of the same or similar functions or components where this exists; otherwise, they shall be as set out in Table 6.

Table 6 Claim Limits

7.4.3.2 A function or component shall be taken as having a failure rate equal to the claim limit only if reasonable measures have been taken to minimize all credible systematic failures.

7.4.3.3 The claim limits shall be agreed between the Project Safety Committee, the Independent Safety Auditor and the MOD PM.

7.4.4 Accident Sequences. The accident sequence and resulting accidents shall be identified for each hazard using techniques such as Fault Tree Analysis, Event Tree Analysis and Cause-Consequence Analysis. Each accident and its associated accident sequence shall be recorded in the Hazard Log.

7.4.5 Categorization of Accidents. Each identified accident shall be categorized according to its severity using table 2. The severity category of each accident shall be agreed by the Independent Safety Auditor and recorded in the Hazard Log.

7.4.6 Accident Probability Targets

(a) Accident probability targets for Risk Classes B and C. Using Table 5, the Accident
Risk Classification Table, the highest tolerable probability of each accident and the aggregate of all accidents shall be determined for Risk Classes B and C. These probabilities represent the accident probability targets for Risk Classes B and C.

(b) Random and systematic elements. The accident probability targets shall comprise random and systematic elements. In order to ensure that the level of risk associated with a system is tolerable, the system shall be assessed separately for the random and systematic elements.

(c) Random element of the accident probability targets. By taking the accident probability targets for Risk Classes B and C, from (a), and using the equivalent numerical probabilities determined in 7.3.2 (e), equivalent quantitative accident probability targets for Risk Classes B and C shall be determined.

(d) Systematic element of the accident probability targets. The systematic element shall be assigned the qualitative accident probability targets derived in (a) for Risk Classes B and C.

7.4.7 Hazard Probability Targets

(a) Random element of the hazard probability targets. By considering the probability of occurrence of each accident sequence, the random element of the probability target for each hazard for Risk Classes B and C shall be determined. These hazard probability targets shall be quantitative, endorsed by the Project Safety Committee, approved by the Safety Review, agreed by the MOD PM and entered in the Hazard Log. The rationale used in the derivation of the hazard probability targets shall be recorded in the Safety Criteria Report.

(b) Systematic element of the hazard probability targets. By considering the probability of occurrence of each accident sequence, the systematic element of the probability target for each hazard for Risk Classes B and C shall be determined. These hazard probability targets shall be qualitative, endorsed by the Project Safety Committee, approved by the Safety Review, agreed by the MOD PM and entered in the Hazard Log. The rationale used in the derivation of the hazard probability targets shall be recorded in the Safety Criteria Report.

7.4.8 Apportionment of Hazard Probability Targets

(a) Random Element of the hazard probability targets. The random element of the probability targets for each hazard shall be apportioned between the lower level functions to provide probability targets for the different functional areas of the system. The apportionment of the random element of the hazard probability targets and the level to which they shall be apportioned, shall be endorsed by the Project Safety Committee, approved by the Safety Review and recorded in the Hazard Log. The rationale used in the apportionment of the hazard probability targets shall be recorded in the Safety Criteria Report.

(b) Systematic element of the hazard probability targets. The systematic failure integrity of the system functions shall be addressed by allocating each function to a Safety Integrity Level in the range S1-S4, where Safety Integrity Level S4 has the highest level of systematic failure integrity. The appropriate design rules and techniques as determined by 7.3.3, shall then be used during implementation of the functions. In the case of a single function or two or more non-independent functions (see 7.4.8.1), the Safety Integrity Level assigned to that function or functions shall be determined by the categorisation of the worst credible accident of the system in Table 7a. In the case of two or more independent functions, one of these functions shall be assigned a Safety Integrity Level on the basis of the severity of the worst credible accident of the system and the apportioned failure probability of the first function in accordance with Table 7b.

Table 7 Safety Integrity Level Requirements

As design and development progresses, function Safety Integrity Levels shall be apportioned to the components that implement the high level functions. The Safety Integrity Level of each high level function shall be inherited by the components that implement it according to the scheme in table 8. The scheme allows components of a lower Safety Integrity Level to implement a function of a higher Safety Integrity Level provided that:

(1) All of the lower level functions are independent.

(2) Any combinator links the lower level functions in such a way that it produces a valid output if the input conditions are satisfied.

The apportionment of Safety Integrity Levels and the level to which they shall be apportioned, shall be endorsed by the Project Safety Committee, approved by the Safety Review and recorded in the Hazard Log. The rationale used in the apportionment of the hazard probability targets shall be recorded in the Safety Criteria Report.

Table 8 Apportionment of Safety Integrity Levels

7.4.8.1 The ‘*’-marking indicates the strict requirements for independence that shall be maintained between the components through specification, design, development and maintenance. A component shall be deemed independent only if it is conceptually different from and relies on different design properties from all the other components. Components with common specifications or subcomponent types shall not be deemed to be independent.

7.4.8.2 Notwithstanding the above, where two or more components reside in the same segregation unit, they shall take the Safety Integrity Level of the most critical component in that segregation unit. This is to prevent designs where a failure of a component of a lower safety integrity can directly affect one of a higher safety integrity.

7.5 Safety Compliance Assessment

7.5.1 Safety Compliance Assessment shall be conducted following Risk Estimation to determine whether the hazard probability targets can be met.

7.5.2 It shall be determined whether the Risk Class C hazard probability targets for the random and systematic elements can be met. This shall be done using techniques such as Fault Tree Analysis for the random element, and by auditing to ensure that the appropriate design rules and techniques are being implemented for the systematic element.

7.5.3 If Risk Class C hazard probability targets are not met then appropriate risk reduction methods shall be employed to reduce the risk to a tolerable level. These shall be in the following order of preference:

(a) Re-specification or re-design.

(b) Incorporation of safety features.

(d) Operating and training procedures.

(e) Warning signs and notices.

Due regard shall be taken of human fallibility wherever a safety feature is implemented by a human being. Human factors, instructions and training shall be considered when apportioning safety integrity.

7.5.4 If it is not possible to reduce the level of risk to Risk Class C then Risk Class B can only be deemed tolerable by the Project Safety Committee if risk reduction is impracticable.

7.5.5 If risk reduction methods are employed then the effect on the system shall be determined by re-assessment of the system. Details of any risk reduction methods employed shall be recorded in the Hazard Log.

7.5.6 Safety Compliance Assessment shall be documented in a Safety Compliance Assessment Report. The Safety Compliance Assessment Report shall contain the following information:

(a) A brief description of the system and its domain.

(b) A brief description of the sub-systems and the boundaries between them.

(d) A description of the method used to carry out Safety Compliance Assessment.

(e) A list of identified hazards applicable to the system, including a description and unique reference.

(f) The results of Safety Compliance Assessment, including:

The results of the Fault Tree Analysis.
The results of any audits carried out.
The results of any tests performed.
The results of any other analyses performed.

(g) Details of the analysis of each hazard and the sources of any failure rate data used.

(h) A description of any risk reduction methods employed for each hazard.

(i) A list of the predicted probabilities for each hazard, together with their justification and a statement on the tolerability of the level of risk.

(j) A cross-reference of the results of Safety Compliance Assessment to the Hazard Log and Safety Programme reports.

(k) A reference to all source documents used, including versions, dates and status.

(l) A reference to the minutes of any Project Safety Committee meeting or Safety Review held.

(m) Conclusions and recommendations.

7.5.7 Any changes to the system or its domain shall be assessed for safety compliance and the Safety Compliance Assessment Report shall be revised or amended to document the changes and the revised safety compliance status.

8 Data Management

8.1 The Contractor shall establish a Data Reporting Analysis and Corrective Action System (DRACAS) which shall be a documented closed loop system for reporting, collecting, recording, analysing, investigating and taking timely corrective action on all incidents that may have an impact on safety. The DRACAS shall apply to design, manufacture, tests and processes, including the activities of sub-contractors. It shall be established during the project definition phase of the project lifecycle and maintained thereafter, up to and including the in-service phase. The Contractor’s Safety Programme Plan shall reference the documentation that describes the DRACAS.

8.2 The DRACAS shall provide traceability of incidents from their discovery until their resolution, or until their associated risk has been reduced to a tolerable level.

8.3 The Project Safety Engineer shall be responsible for reviewing all incidents that occur during the safety programme in order to provide confidence in the accuracy of the theoretical safety analyses. If an incident results in the identification of a new hazard or an amendment to the categorization of an accident, then the Hazard Log shall be amended accordingly.

9 Test Programme

9.1 The Contractor shall establish a test programme which defines tests, inspections and demonstrations in order to verify that the system safety features operate as intended.
The activities shall be aimed at determining if the risk associated with identified hazards has been reduced to a tolerable level. Detailed test procedures shall be prepared for the tests included in the test programme.

9.2 The Contractor’s Safety Programme Plan shall reference the documentation that describes the test programme. The test programme shall also include activities to be conducted by sub-contractors.

9.3 The Project Safety Engineer shall be responsible for assessing that the test programme adequately verifies the safety features.

9.4 All incidents resulting from the test programme shall be subjected to the DRACAS.

10 Work Programme

10.1 The project lifecycle phases below shall be considered by the Contractor when determining the phases applicable to the project

(a) Initiation.

(b) Project definition.

(d) Design certification.

(e) Production.

(f) In-service.

(g) Disposal.

10.2 The Safety Programme Plan shall be out during each phase being considered and adapted to reflect the activities to be carried this shall be agreed by the MOD PM.

ANNEX A - Definitions

A.1 For the purpose of this Standard the following definitions apply:

A.1. 1 Accident. An unintended event or sequence of events that causes death, injury, environmental or material damage. (See also accident sequence.)

A.1.2 Accident sequence. The progression of events that result in an accident. This is illustrated in the following diagram:

A.1.3 Combinator. A physical structure or function used to combine a number of inputs to produce a single output. The output can also be affected by failures induced by the combinator itself.

A.1.4 Common mode failure. Failure of apparently independent components or communication links due to an initiating event that affects them all.

A.1.5 Component. A discrete structure, such as an assembly, within the total system considered at a particular level of analysis.

A.1.6 Configuration. All those components that make up the hierarchy of components for the control, protection and monitoring of the system.

A.1.7 Configuration control. The techniques and processes used to ensure that only the correct versions of components are used in the design, development, production and in-service operation of the system.

A.1.8 Credible. Believed to have a probability of occurrence that can be expressed in meaningful numerical terms.

A.1.9 Domain. The part of the external world, including users and personnel, that affects and is affected by the system and may be harmed by an accident caused by it.

A.1.10 Error. A system state, resulting from a fault (A.1.14) or human mistake, that is liable to lead to a failure (A.1.13).

A.1.11 Event. A significant happening that may originate in the system or its domain. (See also A.1.2.)

A.1.12 Fail safe state. A state of the system that cannot result in an accident, although some other important goals of the system, such as availability, may be compromised.

A.1.13 Failure. The inability of a system or component to fulfil its operational requirements. Failures may be systematic or due to physical change.

A.1.14 Fault. An imperfection or deficiency in the system which may, under some operational conditions, contribute to an error (A.1.10).

A.1.15 Function. An aspect of the intended behaviour of the system.

A.1.16 Hazard. A physical situation, often following from some initiating event, that can lead to an accident. (See also A.1.2.)

A.1.17 Incident. An event that may result in a specification change.

A.1.18 Independent Functions. Functions with immunity from common cause failure.

A.1.19 Incredible. Believed to have a probability of occurrence too low for expression in meaningful numerical terms.

A.1.20 MOD PM. MOD (PE) Project Manager

A.1.21 Module. A separately identified part of a system that performs a specific function.

A.1.22 Nondevelopmental Item (NDI). An item or supply that is either in the process of becoming or already is commercially available or is in use by a UK government agency or department or foreign government with which the UK has a mutual defence cooperation agreement.

A.1.23 Procedure. A series of activities carried out to accomplish an analysis or assessment.

A.1.24 Random failure. Failures that result from a variety of degradation mechanisms in the hardware. Unlike failures arising from systematic failures, system failure rates arising from random hardware failures can be quantified with reasonable accuracy.

A.1.25 Random failure integrity. That aspect of the safety integrity relating to random hardware failures.

A.1.26 Requirement. A detailed statement describing the function and performance of a proposed new system and the domain in which it is to operate.

A.1.27 Risk. The combination of the frequency, or probability, and the consequence of an accident.

A.1.28 Risk assessment. Assessment of the system or component to establish that the achieved risk level is lower than or equal to the tolerable risk level.

A.1.29 Safety. The expectation that a system does not, under defined conditions, lead to a state in which human life is endangered. (The scope of “safety” may be expanded by adding to this definition in the Programme Safety Plan.)

A1.30 Safety features. The properties of the system (including its reliability and availability) that are required to remove unacceptable risks and constrain the other risks from the system to a tolerable level.

A.1.31 Safety integrity. The likelihood of a safety critical system achieving its required safety features under all the stated conditions within a stated measure of use.

A.1.32 Safety integrity level. An indicator of the required level of safety integrity.

A.1.33 Safety target. A numerical expression of the policy on the tolerability of risks from a system, giving for each identified accident its highest tolerable probability for each group of people who may be harmed by it.

A.1.34 Segregation unit. A physical unit of the system designed such that the immediate effects of the failure of a component that resides in it are restricted to the unit.

A.1.35 Smallest replaceable item. The lowest level component at which maintenance will be performed or discrete configuration control enforced.

A.1.36 Staff Target. A concept statement expressing in broad terms the functions and desired performance of a proposed new system or proposed modifications to an existing system.

A.1.37 System. A bounded physical entity that achieves in its domain a defined objective through interaction of its parts.

A.1.38 System Risk Class. The highest risk class of the identified accidents associated with a system.

A.1.39 Systematic Event. An event that can be due to faults in the specification, design, construction, operation or maintenance of the system or its components. A systematic event will always cause an event to occur under a particular combination of inputs, or under some particular environmental conditions. A system event that is not caused by a random event is by definition a systematic event. All software failures are systematic events.

A.1.40 Systematic failure integrity. That aspect of the safety integrity relating to systematic failures.

A.1.41 Technique. A method of performing an aspect of an analysis.

A.1.42 Tolerable risk level. The maximum level of risk of a particular technical process or condition that is regarded as tolerable in the circumstances in question.

A.1.43 Tracking scheme. A scheme for documenting the inheritance of integrity requirements by the system components during the design.