当前位置:首页 >> >>

《风险评价技术及方法》 10.


Chapter

10

Safety Requirements/ Criteria Analysis
10.1 INTRODUCTION

The safety requirement/criteria analysis (SRCA) is an analysis for evaluating system

safety requirements (SSRs). As the name implies, SRCA evaluates SSRs and the criteria behind them. SRCA has a twofold purpose: (1) to ensure that every identi?ed hazard has at least one corresponding safety requirement and (2) to verify that all safety requirements are implemented and are validated successfully. The SRCA is essentially a traceability analysis to ensure that there are no holes or gaps in the safety requirements and that all identi?ed hazards have adequate and proven design mitigation coverage. The SRCA applies to hardware, software, ?rmware, and test requirements. The SRCA also applies to the traceability of design criteria and guidelines to SSRs, such as those speci?ed in the DoD Joint Software System Safety Handbook (DoDJSSSH) [1] and Electronic Industries Association SEB6-A for software [2], and MIL-STD-1316 for fuze systems [3]. Guideline traceability ensures that the appropriate safety guidelines and criteria are incorporated into the SSRs.

10.2

BACKGROUND

This analysis technique falls under the requirements design hazard analysis type (RD-HAT). The basic analysis types are described in Chapter 3. Alternate names

Hazard Analysis Techniques for System Safety, by Clifton A. Ericson, II Copyright # 2005 John Wiley & Sons, Inc.

169

170

SAFETY REQUIREMENTS/CRITERIA ANALYSIS

for this technique are requirements hazard analysis (RHA) and requirements traceability analysis. The purpose of the SRCA is to ensure that all identi?ed hazards have corresponding design safety requirements to eliminate or mitigate the hazard and that the safety requirements are veri?ed and validated as being successful in the system design and operation. The intent is to ensure that the system design requirements have no “safety” gaps (i.e., no hazard has been left unmitigated) and to verify that all safety requirements are adequately implemented or created as necessary. The SRCA is applicable to analysis of all types of systems, facilities, and software where hazards and safety requirements are involved during development. SRCA is particularly useful when used in a software safety program. The SRCA technique, when applied to a given system by experienced safety personnel, is very thorough in providing an accurate traceability of safety design requirement veri?cation and safety test requirement validation. A basic understanding of system safety and the design requirement process is essential. Experience with the particular type of system is helpful. The technique is uncomplicated and easily learned. Standard easily followed SRCA worksheets and instructions are provided in this chapter. The SRCA is very useful for ensuring that design safety requirements exist for all hazards and that the safety requirements are in the design and test speci?cations. SRCA provides assurance that safety requirements exist for all identi?ed hazards and ensures that all safety requirements are incorporated into the design and test speci?cations. The application of the SRCA to software development has proven to be very effective for successfully evaluating software to ensure compliance with safety requirements.

10.3

HISTORY

The SRCA technique was established very early in the history of the system safety discipline. It was formally instituted and promulgated by the developers of MIL-STD-882.

10.4

THEORY

As previously stated, the purpose of the SRCA is to ensure that safety requirements exist for all identi?ed hazards, that all safety requirements are incorporated into the design and test speci?cations and that all safety requirements are successfully tested. Figure 10.1 shows an overview of the basic SRCA process and summarizes the important relationships involved in the SRCA process. This process consists of comparing the SSRs to design requirements and identi?ed hazards. In this way any missing safety requirements will be identi?ed. In addition, SSRs are traced into the test requirements to ensure that all SSRs are tested.

10.5

METHODOLOGY

171

SRCA Process Input
? ? ? ? ? Hazards SSRs Design requirements Test requirements Guidelines
1. Correlate every hazard to an SSR. 2. Correlate every SSR to a design and test requirement. 3. Correlate guideline requirements to SSRs. 4. Document process.

Output
? Correlation matrix - Design Req’ts - Test Req’ts - Safety Req’ts ? Guideline Req’ts Matrix

Figure 10.1 SRCA overview.

10.5

METHODOLOGY

Figure 10.2 shows an overview of the SRCA thought process for the SRCA technique. The idea behind this thought process is that a matrix worksheet is used to correlate safety requirements, with design requirements, test requirements, and identi?ed hazards. If a hazard does not have a corresponding safety requirement, then there is an obvious gap in the safety requirements. If a safety requirement is not included in the design requirements, then there is a gap in the design requirements. If a safety requirement is missing from the test requirements, then that requirement cannot be veri?ed and validated. If an SSR cannot be shown to have passed testing, then the associated hazard cannot be closed.

Test Requirements Software Requirements Design Requirements

Safety Guidelines SSRs Hazards

SRCA Analysis

SRCA Report

SSR Matrix

Guideline Matrix
Figure 10.2 SRCA methodology.

? ? ? ? ?

Hazards SSRs Test Requirements Test Results Guidelines

172

SAFETY REQUIREMENTS/CRITERIA ANALYSIS

TABLE 10.1 SRCA Process Step 1 2 3 4 5 6 7 Task Acquire requirements. Acquire safety data. Acquire safety guidelines. Establish an SSR traceability matrix. Establish guideline traceability matrix. Identify requirement gaps. Recommend corrective action. Track hazards. Document SRCA. Description Acquire all of the design (hardware and software) and test requirements for the system. Acquire all of the hazards and SSRs for the system. Acquire all safety guidelines that are applicable to the system. Correlate SSRs with hazards, design requirements, and test requirements. Correlate safety guidelines and criteria with SSRs. Identify hazards that have no corresponding safety requirement. Determine if the design controls present are adequate and, if not, recommend controls that should be added to reduce the mishap risk. Transfer identi?ed hazards into the hazard tracking system (HTS). Document the entire SRCA process on the worksheets. Update for new information as necessary.

8 9

The SRCA is a detailed correlation analysis, utilizing structure and rigor to provide traceability for all SSRs. The SRCA begins by acquiring the system hazards, SSRs, design requirements, and test requirements. A traceability matrix is then constructed that correlates the hazards, SSRs, design requirements, and test requirements together. The completed traceability matrix ensures that every hazard has a corresponding safety requirement and that every safety requirement has a corresponding design and test requirement. The SRCA consists of two separate correlation traceability analyses: (1) an SSRs correlation and (2) a guideline compliance correlation. The guideline correlation only applies to systems where guidelines exist and are applied to the system design. For example, the safety guideline requirements from the DoDJSSSH are generally applied to the design of software, and the guideline requirements from MIL-STD1316 are applied to fuze system designs. Table 10.1 lists and describes the basic steps of the SRCA process.

10.6

WORKSHEETS

The SRCA is a detailed hazard analysis utilizing structure and rigor. It is desirable to perform the SRCA using specialized worksheets. Although the format of the analysis worksheet is not critical, typically, matrix or columnar-type worksheets are used to help maintain focus and structure in the analysis. Software packages are available to aid the analyst in preparing these worksheets.

10.6

WORKSHEETS

173

The purposes of the SRCA are to establish traceability of SSRs and to assist in the closure of mitigated hazards. As a minimum, the following basic information is required from the SRCA: 1. Traceability matrix of all identi?ed hazards to corresponding SSRs 2. Traceability matrix of all safety design requirements to test requirements and test results 3. Identi?cation of new safety design requirements and tests necessary to cover gaps discovered by items 1 and 2 above 4. Traceability matrix of all safety guidelines and criteria to SSRs 5. Data from items 1, 2, 3, and 4 above supporting closure of hazards The speci?c worksheet to be used may be determined by the managing authority, the safety working group, the safety team, or the safety analyst performing the analysis. Figures 10.3 contains an example SRCA requirements correlation worksheet for the traceability of SSRs. The information required under each column of the requirements correlation matrix worksheet is described below: 1. System This column identi?es the system under analysis. 2. Subsystem This column identi?es the subsystem under analysis. 3. System Safety Requirement (SSR) Number This column identi?es the SSR number. 4. SSR This column states the actual verbiage of the SSR. 5. Safety Critical (SC) Place a Yes in this column to indicate that the SSR is an SC requirement.

1 System: Subsystem:

2

SSR Traceability Matrix HAR No. TLM No. Design Req. No.

SRCA Test Req. No. Test M C R

SSR No. System Safety Requirement (SSR) SC

3

4

5

6

7

8

9

10

Figure 10.3 SRCA requirements correlation matrix worksheet.

174

SAFETY REQUIREMENTS/CRITERIA ANALYSIS

6. Hazard Action Record (HAR) Number This column identi?es the HAR or HARs associated with the SSR. The SSR may be providing mitigation for one or more hazards. 7. Top-Level Mishap (TLM) Number This column identi?es the TLM associated with the SSR. 8. Design Requirement Number This column identi?es the speci?c design requirement that implements the SSR. 9. Test Requirement Number This column identi?es the speci?c test requirement or requirements that test the SSR. 10. Test This column provides information regarding testing of the SSR. Three different types of information are provided: a. M This column identi?es the test method used: test (T), analysis (A), inspection (I), and not (N) done. b. C This column identi?es the test coverage: explicitly (E) tested by a speci?c test or implicitly (I) tested through another test. c. R This column identi?es the test results: pass (P) or fail (F). Figure 10.4 contains the recommended SRCA correlation worksheet for the traceability of SSR compliance with safety guideline and criteria. The information required under each column of the guideline correlation matrix worksheet is described below: 1. System This column identi?es the system under analysis. 2. Subsystem This column identi?es the subsystem under analysis. 3. Guideline Number This column identi?es the requirement number from the guideline or criteria document.

System: 1 Subsystem: Guideline Number

2

Guideline Compliance Matrix Guideline Requirement SSR Number

SRCA Comments
Implement F P N

3

4

5

6

7

Figure 10.4 Guideline correlation matrix worksheet.

10.8 ADVANTAGES AND DISADVANTAGES

175

4. Guideline Requirement This column contains the actual text of the guideline requirement. 5. SSR Number This column identi?es the speci?c SSR that implements the design guideline requirement. 6. Comments This column provides for any necessary discussion associated with the guideline requirement. For example, if the guideline is only partially implemented or not implemented at all, suf?cient rationale and justi?cation must be provided. 7. Implement This column provides information regarding implementation of the design guideline. Check the particular column that is applicable: a. Full (F) implementation by the SSR b. Partial (P) implementation by the SSR c. Not (N) implemented (not applicable or not possible)

10.7

EXAMPLE

This example involves a fuze subsystem for a missile weapon system, which includes both hardware and software. In these examples, not all of the SSRs or design requirements are included, only a small example portion of the overall requirements to demonstrate the technique. Note from this example that more than one safety requirement may exist for a particular hazard. Also, note that the hazard action record (HAR) number is provided for each hazard. The identi?ed design requirement is derived from the program design speci?cation document, and the test requirement is derived from the program test requirements document. Table 10.2 provides an SRCA requirements traceability matrix for this example system. Note that only a single page is shown for this example. A typical SRCA would consist of many pages. Table 10.3 provides a compliance matrix for the DoDJSSSH software guidelines [1]. A software SRCA correlation compliance would include the review of each of these guidelines, determine if it were applicable to the system design, provide rationale for those not applicable, and provide the corresponding safety requirement reference in the speci?cation for those found to be applicable. Table 10.4 provides a MIL-STD-1316 (Series) compliance matrix for this example system. Table 10.5 provides a MIL-HDBK-454 (Series) compliance matrix for this example system. 10.8 ADVANTAGES AND DISADVANTAGES

The following are advantages of the SRCA technique: 1. SRCA is easily and quickly performed. 2. SRCA correlates SSRs to hazards and design requirements and speci?cations.

176
SSR Traceability Matrix Safety Requirements/Criteria Analysis Test T/A/I/N T E/I E P/F P HAR Number TLM Number Design Req’t Number Test Req’t Number TS 4.7.21 SS 7.7.21 1 21 81, 95 1 SS 7.7.22 TS 4.7.22 T E P Page:

TABLE 10.2 SRCA Requirements Traceability Matrix Example

System: Lark Missile

Subsystem: Fire Control System

SSR Number

System Safety Requirement (SSR)

SC

SSR 31

Y

SSR 32

No single point failure can result in missile launch. Three separate and independent means are required for missile arming.

Y

SSR 33 SSR 34

TABLE 10.3 DoDJSSSH Compliance Matrix Example Safety Requirements/Criteria Analysis Compliance Comments F X P N

System:

Subsystem:

DoDJSSSH Software Compliance Matrix

DoDJSSSH Number SSR 71

DoDJSSSH Requirement

SSR Number

E.4.3

E.5.2

Primary computer failure. The system shall be designed such that a failure of the primary control computer will be detected and the system returned to a safe state. CPU selection. CPUs, microprocessors, and computers that can be fully represented mathematically are preferred to those that cannot.

Not possible for program to obtain a CPU meeting this requirement. Intel Pentium II has been selected and approved. This requirement is too stringent for program. SSR 72 X

X

E.6.4

E.9.4 SSR 73

X

E.11.2

SSR 74 SSR 75

X X

E.11.18

E.11.19

Operational checks. Operational checks of testable safety critical system elements shall be made immediately prior to performance of a related safety critical operation. Safety critical displays. Safety critical operator displays, legends, and other interface functions shall be clear, concise, and unambiguous and, where possible, be duplicated using separate display devices. Modular code. Software design and code shall be modular. Modules shall have one entry and one exit point. Variable declaration. Variables or constants used by a safety critical function will be declared/initialized at the lowest possible level. Unused executable code. Operational program loads shall not contain unused executable code. SSR 76

X Page:

177

TABLE 10.4 MIL-STD-1316E Compliance Matrix Example Safety Requirements/Criteria Analysis Compliance Comments F P X N

178
SSR Number SSR 47 SSR 48 SSR 49 Veri?ed by FTA X X Page:

System:

Subsystem:

MIL-STD-1316E Compliance Matrix

1316E Number

MIL-STD-1316E Requirement

4.2.2

4.2.3

4.3

4.3a

4.3b

4.3c

Arming delay. A safety feature of the fuze shall provide arming delay, which assures that a safe separation distance can be achieved for all de?ned operational conditions. Manual arming. An assembled fuze shall not be capable of being armed manually. Safety system failure rate. The fuze safety system failure rate shall be calculated for all logistical and tactical phases from manufacture to safe separation. The safety system failure rate shall be veri?ed to the extent practical by test and analysis during fuze evaluation and shall not exceed the rates given for the following phases: Prior to intentional initiation of the arming sequence: 1 ? 1026 to prevent arming or functioning. Prior to the exit (for tubed launch munitions): 1 ? 1024 to prevent arming 1 ? 1026 to prevent functioning Between initiation of arming sequence and safe separation: 1 ? 1023 to prevent arming ALARPa with established risk to prevent functioning

a

ALARP, as low as reasonably practical.

TABLE 10.5 MIL-HDBK-454 Compliance Matrix Example Safety Requirements/Criteria Analysis Compliance Comments F X P N

System:

Subsystem: SSR Number SSR 101

MIL-HDBK-454 Compliance Matrix

454 Number

MIL-STD-454 Requirement

4.1

4.2 SSR 102 SSR 103

X X

4.3a

4.3b SSR 104

The equipment shall provide fail-safe features for safety of personnel during installation, operation, maintenance, and repair or interchanging of a complete assembly or component parts. Electric equipment shall be bonded in accordance with MIL-B-5087, Class R/L/H. At an ambient temperature of 258C, the operating temperature of control panels and operating controls shall not exceed 498C (1208F). At an ambient temperature of 258C (778F), exposed parts subject to contact by personnel (other than control panels and operating controls) shall not exceed 608C (1408F). X Page:

Source: MIL-HDBK-454M, general guidelines for Electrical Equipment, guideline 1—Safety Design Criteria for Personnel Hazards.

179

180

SAFETY REQUIREMENTS/CRITERIA ANALYSIS

3. SRCA veri?es and validates SSRs through correlation of test results. 4. Software packages are available to aid the analyst in preparing SRCA worksheets. There are no major disadvantages of the SRCA technique.

10.9

COMMON MISTAKES TO AVOID

When ?rst learning how to perform an SRCA, it is commonplace to commit some typical errors. The following is a list of common errors made during the conduct of an SRCA: 1. Failing to put all safety guidelines and requirements into SSRs 2. Failing to perform a traceability compliance analysis on all safety guidelines and requirements SSRs

10.10

SUMMARY

This chapter discussed the SRCA technique. The following are basic principles that help summarize the discussion in this chapter: 1. The primary purpose of the SRCA is to assess the SSRs and: . Identify hazards without associated SSRs (gaps in the design SSRs).
.

Identify requirements that are not in the system design requirements. Identify requirements that are not tested and validated for effectiveness.

.

.

2.

3. 4. 5.

6.

Identify safety guidelines and requirements that are not implemented in the SSRs. The SRCA relates the identi?ed hazards to the design SSRs to ensure that all identi?ed hazards have a least one safety requirement, whose implementation will mitigate the hazard. The SRCA relates the design SSRs to the test requirements to ensure all safety requirements are veri?ed and validated by test. The SRCA is also used to incorporate safety guidelines and requirements that are speci?cally safety related but not tied to a speci?c hazard. The SRCA process ensures that the design safety requirements are properly developed and translated into the system hardware and software requirement documents. The use of the recommended SRCA worksheets simpli?es the process and provides documentation of the analysis.

REFERENCES

181

REFERENCES
1. DoD, DoD Joint Software System Safety Handbook (DoDJSSSH), Appendix E—Generic Requirements and Guidelines, 1999. 2. Electronic Industries Association, EIA SEB6-A, System Safety Engineering in Software Development, Appendix A—Software System Safety Checklist, Electronic Industries Association, 1990. 3. MIL-STD-1316 (Series), Safety Criteria for Fuze Design—DoD Design Criteria Standard. 4. MIL-HDBK-454M (Series), General Guidelines for Electronic Equipment, Guideline 1— Safety Design Criteria for Personnel Hazards.


相关文章:
风险评价的方法
暴露指数确定的方法是:单一危险事件的概率(通常是每 10,000 暴 露小时所发生...定量风险评价是一种广泛使用的管理决策支持技术,定量风险评价包含五个要素: (1)...
风险评价准则和风险评价方法
>10 降低生产负荷 造成环境污染 2 造成人员轻微伤 <10 影响不大,几乎不停车 ...要求各级风险 评价人员严格按照《风险评价及风险控制程序》 ,认真履行各自的职责,...
风险评估方法和标准
风险评估方法和标准_金融/投资_经管营销_专业资料。...(如人力资源部、 生产部、总经办、技术发展部、计...内控项目建设委员会 二〇〇七年八月二十四日 7 ...
风险评价方法
物业管理 几乎不停工 <10 没有停工 及周边范 围 无伤亡 形象没有 受损失 应...《风险评价技术及方法》... 12页 免费 风险评价方法 8页 1下载券 工程项目风...
常用的两种风险评价方法
常用的两种风险评价方法 1.半定量风险矩阵半定量风险矩阵危害严重性 1 伤害可以...10 3可能 3 6 9 12 15 4很可能 4 8 12 16 20 5事故的发生几乎 不可...
风险评价方法 LEC评价法
三、根据 D 值不同确定危险源风险等级,建立《危险源清单风险评价方法 ...事故发生的可能性(L) 分数值 10 6 3 1 0.5 0.2 0.1 事故发生的可能...
风险评价方法
10~17 是有控制的接受的风险,需要订购方评审后方可接受;18~20 是不经 评审...《风险评价技术及方法》... 12页 免费 区域风险评价方法研究 6页 免费 工程项...
各种风险评价方法的优缺点及适用范围
2014小学教师资格考试《... 2014年幼儿园教师资格考... 2014教师资格中学教育知...风险评价方法 2页 1下载券 环境风险评价技术方法 6页 免费 几种常用定量风险...
风险评估方法
附录 风险坐标图+蒙特卡罗方法 风险管理常用技术方法简介 一、风险坐标图 风险...定性方法 一般情况下 文字描述二 不会发生 今后 10 年内 文字描述三 发生的...
企业风险评价方法
企业风险评价方法 1、评价方法的选择 公司针对当前风险评价方法众多的实际,评价...10 11 人员可靠性分析 定量风险评价方 法 作业条件危险性 评价法 HRA QRA 12...
更多相关标签:
风险评价方法 | lec风险评价方法 | 定量风险评价方法 | 环境风险评价技术导则 | 安全风险评价方法 | 危险源风险评价方法 | 风险评价的方法有哪些 | 风险评价的方法 |