系统安全军用标准MIL6sTDE中文全文

前言

1.此标准被批准应用于国防部所有的军事部门和国防机构。

2.此系统安全标准是系统工程的关键要素，它为识别、分析和减轻危险提供了

一个标准和通用方法。

3.国防部承诺保护个人免受意外的死亡、伤害、职业病以及在执行国防要求的

任务时，保护防御系统、基础设施和财产免受意外的毁坏或破坏。在任务要

求里，国防部也会确保把环境保护到最大可能的程，整个这些努力就是使用系

统安全方法来识别危险并处理与危险相关的风险.国防部的关键目标是扩大

系统安全方法论的使用，来把风险管理融入到整个系统工程当中，而不是把

危险看做是操作因素。它不仅可以被系统安全专家使用.还可以应用于其他功

能学科，比如火灾保护工程师、职业健康专家和环境工程师来识别危险并通

过系统工程减轻风险。此文件的目的不是在其他功能学科使用系统安全解决

个人的危险管理问题，但是，所有使用此通用方法的功能学科都应该把工作

协调为整个系统工程的一部分，因为一个学科减轻危险的措施可能会在其他

学科产生危险。

4.此系统安全标准确定了国防部识别危险并评价和减轻相关风险的方法，这些

危险和风险是在防御系统的开发、测试、生产、使用以及报废阶段遇到的。

这个方法描述了要与国防部指令一致。国防部指令定义了风险的可接受水平。

5.本次修订包含了满足政府和工业要求的改变，恢复了任务说明书。这些任务

可能在合同文件中规定。当本标准在要求或合同中需要的时候，如果没有特

殊要求，只有第三章和第四章是强制的。3.2和整个第四章的定义描绘了任何

国防部系统可接受的系统安全最低的强制性定义和要求。本次修订把标准的

执行与当前的国防部政策相结合，支持国防部的战略性计划和目标，调整了

信息的组织安排，阐明了系统安全过程的基本要素，阐明了术语并定义了任

务说明书来改善危险管理。本标准强化了其它功能学科与系统工程的结合，

最终通过大纲改进危险管理实务的一致性。特殊的改变包括：

a.重新介绍了任务说明书：

（1）100-系列任务-管理

（2）200-系列任务.分析

（3）300-系列任务-评价

（4）400-系列任务-确认

b.强调了可应用的技术要求的识别

c.包括附加的任务：

（1）危险物质管理计划

（2）功能危险分析

（3）系统之间危险分析

（4）环境危险分析

d.应用严重性描述损失价值的增加

e.增加了“消除”可能性水平

f.增加了软件系统工程技术和实务

g.更新了附录

6.对此文件的评论、建议或问题应该递交到美国空军装备司令部总部

iii

附录B

⑵与由软件引起并控制的系统危险相关的风险是可以接受的，基于证据（危险,

起因以及降低风险的措施已经根据国防部顾客的要求得以识别，执行以及核实）。

证据支持了这样一种结论，危险控制提供了必需的降低危险的水平并且合成的风

险能够被适当的风险接受权威所接受。就这一点而言，软件与硬件和操作者没有

什么不同。如果软件设计没有满足安全要求，那么就会导致与没有充分核实软件

危险起因和控制相关联的风险。一般说来，风险评价是以定量和定性的判断和证

据为基础的。表格B-I显示这些原则是如何应用的，来提供一种与软件因素相关

联的评价方法。

表格B-I软件危险因素的风险评价标准

风险水平风险标准描述

在正常或不正常的操作或测试期间出现软件执行或软件设计不

足：

•能直接导致灾难性的或危急的事故，或者

高度的•使系统处于一-种状态，这种状态下，没有独立的连锁装置能

够排除潜在的灾难性及危急事故的发生

•能直接导致临界的或轻微的事故，或者

严重的•使系统处于一种状态，只有一个独立的连锁装置或人为活动

来排除潜在的灾难性或危急危险的发生

•影响临界的或轻微事故，将系统失效降低到单犯的一点，或

中等的者，

•使系统处于一种状态，有两个相互独立的连锁装置或人为活

动来排除潜在的灾难性或危急性事故的发生

・影响灾难性或危急性的事故，但是杓二个相互独立的连锁装

置或人为活动保留，或者

•会有影响临界的或轻微事故的因果相关的因素，但是有两个

低的相互独立的连锁装置或人为活动保留

•没有被分类为高度的、严重的、或中等的安全风险等级的软

件的安全关键功能退化

•要求，如果执行了，就会对安全产生负面影响，然而代码是

安全执行的

e.定义并执行与危险相关的风险评价过程对计划的成功是关键的，尤其是当系

统和更加复杂的系统之间相结合。这些系统之间常常包含在不同的开发条件和安

全计划下开发的系统，并且可能需要与其他服务（陆、海、空军）或国防部机构

系统和接。这些其他的系统之间的利益相关者可能有他们自己的安全过程，用来

决定与他们的系统相结合的系统的可接受性。

军用标准882E

1、范围

1.1范围：这个系统安全标准的实行确定了国防部系统工程的方法来消除危

险，如果可能的话，或者使那些不能消除的危险的风险最小化。国防部指令里

5000.02定义了风险可接受的优先性。这个标准覆盖了系统、产品、设备、基础

设施（包括硬件和软件的）贯穿于整个设计、研发、实验、产品、使用和清理阶

段的所有危险。当这个标准在一个说明或是合同里被要求但是又没有特定的任务

被定义时，只有三、四部分是强制的。3.2里的定义和第四部分的全部描绘了最

小化强制性定义和要求对于任何国防部系统的一个可接受的系统安全努力。

2、适用的文件

2.1通用。在这部分文件列出的是标准的第三、四、五部分里规定的。这一

章不包括本标准中其他章节引用的文件或是推荐的额外信息或是例子。然而每个

努力都已经被做确保这一列表的完成。文件使用者应注意到他们一定会遇到在本

标准第三、四、、五章里引用的文件的规定要求。无论他们是否列出。

2.2政府文件

2.2.1说明书、标准和手册。下面的说明书、标准和手册在某种规定的范围

内形成了文件的一部分。除非不被规定的，这些文件的问题都在合同里被引用。

国际标准化协议

A0P52NATOAOP52.关于软件安全设计的指导和相关计算系统必需品的评估。

（这个文件的副本在这个https://assist./quicksearch/网站上可以

获得或从标准化文件排序桌面获得。费城罗宾斯大街700号4D建筑里，PA

19111-5094）

国防部手册

没有指定者软件系统安全工程接口手册（这个文件的副本在这个

http:〃www.system-safety,org/links/网站上电以获得）

2.2.2其他的政府文件、图纸和出版物。下面这些其他政府文件、图纸和出扳物

形成了文件规定程度上的一部分。除了没有规定的。这些文件的问题就是在合同

里引用的。

国防部指令

DoDI5000.02-防御获得系统的操作

9DoDl6055.07-事故通告、调查、报道和记录保持

（这个文件的副本在这个http://www.system-safety,org/1inks/网站上可

以获得）

2.3优先命令在一个突发事件中在这个文件的文本和引用于此的参考文献

中间，文件的文本是优先的。除了DoDI5000.02例外。在这个文件中没有什么

能接替可应用的法律和法规，除了一个规定的免除包含在内。

3.定义

3.1首字母缩拼词

AF0SH空气促使职业安全和健康

ANSI美国国家标准协会

A0P联合军火出版物

AMSC获得管理系统控制

ASSIST获得流线型和标准化信息系统

ASTM美国社会检验和材料

AT自主的

CAS化学文摘服务

CDR关键设计评审

CPR联邦法规代码

C0TS商业成品

DAEHCP军火防御部门和爆炸危险分类程序

DID数据项描述

DoD国防部

DoDI国防部指令

D0DIC国防部标识码

DOT运输部

DT研发测试

E3电磁环境影响

ECP工程改变提议

EHA环境危险分析

EMD工程和制造业发展

E0行政指令

E0D爆炸性军械处理

ESD静电放电

ES0H环境安全和职业健康

FHA功能危险分析

FMECA失效模式和效果临界性分析

FTA故障树分析

GFE政府配备的装备

GFI政府供应的信息

GOTS政府常备的

HAZMAT危险品材料

HERO电磁辐射对军火的危险

HHA健康危害分析

HMAR危险管理评估报告

HMMP危险物品管理计划

HMP危险管理计划

HSI人类系统集成

HTS危险追踪系统

IEEE电气科学和电子学工程师学会

IM不敏感的军需品

IMS综合的设计任务书

IPT综合的产品团队

ISO国际标准化组织

IV&V独立验证和检验

JCIDS功能集合和开发系统的接口

LOR精确水平

MANPRINT人力资源和人事集合

MIL-1IDBK军用手册

MIL-STD军用标准

MSDS材料安全数据表

NATO北大西洋公约组织

NAVMC海军和海军陆战队

NDI发展条款

NEPA国家环境政策法

NSI不安全影响

NSN国家物料编号

O&SHA操作和支持危险分析

OSH职业安全和健康

OSHA职业安全与健康管理

0T操作测试

PESHE纲领性环境、安全和职业健康评价

PDR初步设计评审

PHA初始危险分析

PHL初始危险目录

PM程序管理器

PPE个人防护用品

RAC风险评估模式

RF无线电频率

RFP提案申请

RFR射频辐射

RFT冗余容错

SAR安全评估报告

SAT半自治

SCC软件控制类别

SCF安全性至关重要的功能

SCI安全性至关重要的项目

SDP软件开发计划

SE系统工程

SEMP系统工程管理计划

SHA系统风险分析

SMCC特殊材料内容的代码

SoS体系

SOW工作说明书

SRHA危害分析系统需求

SRF安全相关函数

SRI安全相关物品

SRR系统需求评审

SSF安全问题”功能

SSCM软件安全临界矩阵

SSHA子系统危害分析

SSPP系统安全工程计划

SSSF安全问题〃软件功能

STP软件测试计划

SwCI软件临界指数

T&E测试和评估

TEMP临时测试和评估总体规划

TES测试工程师测试和评仙策略

WDSSR放弃或偏差系统安全报告

WG工作组

3.2定义在使用这个标准时，应强制使用。

3.2.1可接受的风险。风险，适当的受理机关(定义在多迪5000.02)愿意接受没有额

外的缓解。

3.2.2采办计划。一个直接的，资助的努力，提供了一个新的,改进的，或继续物资，武

器,或信息系统或服务能力以应对一个批准的需要。

第3.23病原。一个或多个机制，触发了风险，可能导致事故。

3.2.4条商用现货(COTS)。商业项目，不需要独特的政府修改或维护生命周期的产

品来满足需求的采购代理。

325承包商。一个实体在私人行业进入合同与政府提供的商品或服务。在这个

标准，这个词也适用于政府运营的活动，开发或收购国防项目上执行工作。

3.2.6环境影响。一个对环境不利变化引起的全部或部分的系统或其使用。

327ESOHo一个首字母缩略词，指的是结合学科，包括流程和方法解决的法律、法

规、行政命令(E0),国防部政策、环境合规，和相关的危险的环境影响、系统安全(如。、

平台、系统、体系、武器、爆炸物、软件、军械、作战系统)，职业安全与健康、

危险物品管理，和污染防治。

328事件风险。相关的风险和危害，因为它适用于指定的硬件/软件配置在一个事

件。典型的活动包括发展测试/操作测试(DT/OT)、示威、部署、post菲尔丁测试。

329防守。将系统为操作使用单位在田里或舰队。

3210固件。结合一个硬件设备和计算机指令或计算机数据驻留为只读软件硬件

设备。这个软件不能轻易修改在程序的控制下。

“11工作设备(GFF)。财产的占有或由政府直接获得,随后交付或其他可用的承包

商使用。

3.2.12工作信息(GFI),信息在拥有或由政府直接获得，随后交付或其他可用的承

包商使用。政府提供的信息可能包括物品如教训类似的系统或其他数据,通常不

会被可用的非政府机构。

3.2.13政府从架子上(GOTS)。硬件或软件开发、生产,或属于一个政府机构，不需

要独特的修改在生命周期的产品来满足需求的采购代理。

3.2.14风险。一个真正的或潜在的条件,可能导致意外事件或一连串的事件(即事

故)导致死亡、受伤、职业疾病，损害或损失的设备或财产，或对环境的破坏。

3.2.15有害物质(有害)。任何项目或物质，由于它的化学、物理、毒理学、或生

物性质，可能导致伤害人，设备，或环境。

3.2.16人力系统集成(溪)。集成的和全面的分析、设计、评估的需求、概念和

参考资料系统人力、人员、培训、安全、职业健康、适居性、人员生存能力，和

人类工程学。

3.2.17最初的风险。第一个评估潜在的风险识别出风险。初步建立了一个固定

的基线风险的危害。

3.2.18精确级别（特/一个规范的深度和广度的软件分析和验证活动必要提供

足够的自信程度，安全性至关重要的或安全软件功能将根据需要执行。

3.2.19生命周期。系统的所有阶段的生活，包括设计、研究、开发、测试和评估、

生产、部署（库存）、操作和支持，和处理。

3.2.20事故。一个事件或一系列事件导致意外死亡、受伤、职业疾病，损害或损

失的设备或财产，或对环境的破坏。对于本标准中，术语〃灾祸〃包括从计划事件对

环境的不良影响。

3.2.21缓解措施.行动需要消除危害或当一个危险不能消除，减少相关的风险,

减少事故的严重性或降低导致事故的可能性会发生。

3.2.22模式。一个指定的系统状态或状态（如。、维护、测试、运行、储存、运

输和非军事化）。

3.2.23货币损失。估算成本的总和为设备维修或更换，设备维修或更换，环境清洁、

人身伤害或疾病、环境负债,应包括任何已知的罚款或罚金造成的事故预测。

3.2.24非发展项目（NDI）。项目（硬件、软件、通讯/网络,等等），用于系统开发程

序，但并不发达，作为该计划的一部分。NDls包括但不限于,COTS,GOTS,GFE,再利用

物品,或以前开发的项目提供程序“目前的〃。

3.2.25概率。一个表达式的事故发生的可能性的

3.2.26个项目经理.（PM）。指定的政府个人负责和权威来完成项目目标开发、生

产,和系统/产品/设备的维护以满足用户的操作需求。项目经理负责可靠的戌本,

进度，性能并汇报给里程碑决策机构。

3227重用项目一个提前开发好的项目被用于另一个程序或应用于令一个单独

的应用程序

3.2.28风险事故严重性和事故发生可能性的组合.

3.2.29风险水平对风险高,严重、中或低的描述.

3.2.30安全不能引起死亡、伤害、职业病、设备或财产的破坏、损失，环境破坏

的状态。

3.3.31安全关键性一个术语应用于一个状态、事件、操作、进程或项目。事故的

严重性是灾难性和危机性的。（例如，安全关键性函数，安全关键性路径和安全

关键性部件）

3.2.32安全关键性函数一个函数，其失败或不正确的操作将直接导致事故的灾难

性或危机性事故严重程度

3233安全关键性项目一个硬件或软件项目被决定于通过分析来确定潜在的导

致危害发生的灾难性关键性事故的潜力，或者，或者应用于减轻导致危害的灾难性

或关键性事故的潜力.本标准中术语〃安全关键项目〃的定义是独立于术语〃关键

安全项目〃在公共法108-136和109-364的定义的。

3.2.34安全相关一个术语应用于一个状态、事件、操作、进程或项目。事故的严

重性是临界的或可以忽略的。

3235安全意义个术语应用于一个状态、事件、操作、进程或项目被鉴定为安全

关键或安全相关。

3.2.36严重性一个事故潜在结果的大小，包括：死亡，伤害，职业病，设备或

财产的破坏或损失，环境破坏，或者财政损失。

3.2.37软件使计算机能够执行计算或控制功能的相关计算机指令和计算机数据

的结合。软件包括计算机程序、规程、规则以及任何相关的文档有关的计算机系

统的操作。软件包括新的发展，复杂可编程逻辑器件（固件）,NDI,COTS,GOTS、重用、

GFE,和政府开发的软件用于系统中。

3.2.38软件控制类别在一个系统特性的背景下对软件功能自治的程度，指挥和控

制权力和冗余容错的赋值。

3.2.39软件重用在一个软件应用的发展程序中使用一种先前开发的软件模块或

软件包

3240软件系统安全将系统安全的原理应用于软件。

3.2.41系统需要在规定的环境中得到指定的结果的硬件、软件、材料、设备、

人员、数据的和指定功能的服务的组织。

3.2.42体系一组或一系列相互依赖的系统相关联于提供一个给定的能力

3243系统安全在系统整个生命周期的所有阶段，应用工程和管理原则、标准，

和技术利用有限的操作效能和适用性、时间和成本来达到可接受的风险

3.2.44系统安全工程一个工程学科，运用专业知识和技能于应用科学和工程学科,

标准和技术，以识别危险然后消除危险或当危险无法消除时减少相关风险。

3.2.45系统安全管理识别危险;评估和减轻相关风险;跟踪、控制、接受和记录在

系统、子系统、设备和设施的设计、开发、测试、获取、使用和处理中遇到的风

险的所有计划和行动

3.2.46系统/子系统说明对于给定的系统中系统等级的功能和性能需求，连接，

适应需求，安全性和保密性需求，计算机资源的需求，设计约束(包括软件架构，

数据标准和编程语言)，软件支持，优先级的需求，研制试验的需求。

3.2.47系统工程一个项目团队的总体过程，适用于从上述能力的有效运作和合适

的系统过渡。系统工程涉及到的应用SE适应每个阶段的生命周期()在整个收

购过程的目的是要平衡的解决方案的整合机制，处理能力需求，设计考虑因素和

制约因素。SE还涉及技术，预算和进度的限制。SE进程早期应用材料解决方

案的分析和持续整个生命周期。

3.2.48目标风险预计风险水平的PM计划以实现符合设计的优先顺序实施缓解

措施的在4.3.4中的描述

3.2.49用户代表对于保护事件，一个命令或代理,已被正式指定在联合功能集

成和开发系统(JCIDS)过程中代表单个或多个用户的能力和采集过程。对于无保护

事件，用户代表付命令或代理责任对暴露在风险中的人员，设备和环境。对于所

有的事件，用户代表将有同等的水平相当于风险接受权威。

4.常规/一般要求

4.1常规。当本标准被要求在招标或合同，但不包括具体的任务，只有第3节和

第4节的规定适用。3.2和所有第4节中的定义是国防部系统任何一个可以接受的

系统安全工作最低强制性规定和要求。

4.2系统安全要求第四节通过任何系统的整个生命周期定义了系统安全要求。如

果运用得当，这些要求应使在系统开发和维持工程活动的危害和相关风险的识别

和管理。木记录的目的不是使系统的安全人员负责风险管理在其他的功能学科。

然而，所有的功能学科使用这个通用的方法应该协调每个部分的努力优化的整体

的系统工程过程，因为一个学科的最优缓解措施可能对其他学科产生危险。

43系统安全过程-系统安全过程包含3个元素。图1描述了过程的典型逻辑序列.

然而，可能需要在各个步骤之间的迭代。

元素1：元素5：

记录系统安全的方法减少风险

元素2:元素6：

识别和记录危险核实、险证和记录风险降低

元素3：元素7：

评估和记录风险接受风险和记录

元素4：元素8:

确定和记录的风险缓解措施管理生命周期风险

图1系统安全过程的八个要素

4.3.1记录系统安全方法项目管理人和订约人应该记录下系统安全方法，为了

给作为系统工程进程中完整的一部分的风险管理，系统安全方法的最低要求包括:

a.描述风险管理的影响和如何使得风险管理和系统工程进程，集成产品和过程开

发进程，总的项目管理构造成为一体。

b.描述和记录可适用于系统的规定和派生的需求。例子包括顿感弹药的需求，

电磁换效应的需求，污染防治任务，设计需求，技术因素，职业病和社区噪音标

准。一旦需求被定义，确定系统说明书的内容和可用的流程要求给转包商，承包

商和供应商。

c.定义如何使得与美国军标15000.02一致的危险和相关风险被使用者的代表正式

的接受和同意。

d.文件编制一个闭环危险追踪系统危险。危险追踪系统将会包括，作为最低限度

的以下数据元素：确认危险，相关事故，风险评估（最初的，目标，事件），定

义风险缓解措施，选定缓解办法，危险状态，验证风险的降低，和风险的可接受

度。政府和承包商有权使用危险追踪系统来适当的控制数据管理.政府应该接收

和保留“政府的目标权利”，所有的数据记录在危险追踪系统和其他条款（即，

研究，分析，测试数据，注释，类似的数据）

4.3.2定义和记录危险。危险通过系统性的分析过程被定义，这个过程包括系统

硬件和软件，系统界面（包括人机界面），具体的使用或应用，操作环境。考虑

和使用事故数据；相关的环境和职业；使用者的物理特性；使用者的知识，技术

和能力；来自以往相似系统事故的经验和教训。危险识别过程应该考虑整个系统

的生命周期和对于人的潜在影响，基础设施，防御系统，公众，和环境。危险识

别应该被记录在危险追踪系统。

4.3.3评估和记录风险事故严重程度的分类和所有系统模型的不同危险的潜在

事故可能性等级被评估，用来定义表I，IL

a.表一中给出了确定给定的危险在给定的时间点来确定正确的严重性分类的方

法，定义了死亡或者伤害，环境影响，或者财产损失的潜在可能性。一个给定的

危险可能会产生一个或者所有的影响。

表一.严重性分类

严重性分类

种类严重性分类事故结果准则

灾难性的1一种或者多种结果如下：死亡，终身残疾，不

可逆的重大环境影响，R1000万美金的财产损

失。

严重的2一种或者多种结果如下：永久性部分残疾，伤

害或者导致住院人数超过3人的职业病，可你

的重大环境影响，2100万，W1000万美金的

财产损失。

轻微的3一种或者多种结果如下：导致一天或者更多天

的工作日损失的伤害或职业病，可恢复的轻微

环境影响，210万，W100万美金的财产损失。

可忽略的4一种或者多种结果如下；导致轻微伤害或职业

病，但不会导致损失工作日，最小的环境影响，

W10万美金的财产损失。

b.表二中给出了确定给定危险在给定时间点适当的可能性等级，评估了事故发生

的可能性。可能性等级F被用来记录不存在风险的地方的例子。没有大量的学说,

培训，警报，警告，警示，或者个人防护设施可以达到事故可能性等级F。

表二可能性等级

可能性等级

种类等级具体内容系统

频繁的A在寿命周期内可能发生连续发生

很可能的B在寿命周期内发生多次将会发生若干次

偶然的C在寿命周期内可能发生将会发生几次

可能性极小D在寿命周期内不易发生，但有可不易发生，但有理

的能性由可预期发生

不太可能的E极不易发生，几乎认为不可能发不易发生，但有可

生能发生

没有可能性F不能发生，这个等级是用来当潜不能发生，这个等

在的危险被定义和被排除时。级是用来当潜在

的危险被定义和

被排除时。

⑴运用适当的和代表性的定量数据定义危险的频率和发生率，一般最好定量分

析，不可能等级是一般被认为是低于一百万，附录A给出了一个定量可能性等级

的例子。

⑵缺少定量频率或数据率时，依赖于表二的定性分析是有必要的并且适合的。

C.风险评价被表达为一个风险评估代码，这种代码是严重性分类和可能性等级的

结合，例如，RAC中的A是大型和频繁发生等级的事故，表三把不同的风险评估

代码的风险等级划分为，高等，严重，中等，和低等。

表三风险评价矩阵

风险评价矩阵

、^性灾难性的严重的轻微的可以忽略的

(1)(2)(3)(4)

可能性

频繁的高高严重的中等的

(A)

很可能高同严重的中等的

(B)

偶然的高严重的中等的低

(C)

可能性极小的严重的中等的中等的低

(D)

不太可能的中等的中等的中等的低

(E)

没有可能性没有可能性

(F)

d.表一，表二的定义和表三的RAC(风险评估代码)应该被用来，除非与美国军

用标准的部分政策一直的不同定义和矩阵被正式的认可，代理人应该从表一到表

三中提取。

e.项目应该按照4.3.1的要求把所有可能性规定转换成数值使用在风险评估中。

评估风险应该被记录在HTS(危险追踪系统

4.3.4定义和编辑风险缓解措施。潜在的风险缓解应该被定义，并且预期风险降

低的选择应该被评估和记录在危险追踪系统。如果可能的话目标应该是消除危险。

当一个风险不能被消除时，通过应用系统安全设计的优先次序，相关风险应该被

降低到成本和性能的最低可接受水平。系统安全设计的优先次序给出了选择性抑

制的方法和通过列表来降低影响。

4.3.4

A通过设计选择排除危险。理论上，通过设计的选择或者是移除危险的材料1勺选

择，可以排除的危险。

B通过修改设计减小风险。如果采取改变供选择的设计或者材料去排除危险是不

可行的，那么考虑改变设计减小因危险引起潜在事故的严重性和/或者可能性。

C包含工程特征或装置。如果通过设计选择减缓风险是不可行的，那么使用工程

特征或装置，减少因危险引起潜在事故的严重性和可能性。

D提供报警装置。如昊工程特征和装置是不可行的或者不能使因危险引起潜在

事故的严重性和可能性足够低。那么使用包括探测和警报系统使人警觉到危险情

况的存在或者是危险事件的发生。

E包含指导标示、程序、训练和保护人的设备。这里供选择的设计、改变设计、

工程特性和装置是不可行的和警报装置不能充分的减少因危险引起潜在事故的

严重性和可能性。那么使用包含指导标示、程序、训练和保护人的设备。指导标

示包括海报、标示、符号和其他可见的图形。程序和训练应该包括适当的警告和

警示。程序可以描绘保护人的设备的使用。对于被赋值为灾难性危险或者是危险

事故严重性分级、指导标示的使用、程序、训练、和保护人的设备用作唯一的减

少风险的方法应该被避免。

4.3.5减小风险。减轻措施被选择和执行去获得可接受水平。考虑和评估花费、

可行性、候选减轻方法的效果作为系统工程的一部分和使生产机组加工完整。技

术检查时提出当前存在的危险、他们相关危险性和严重性的评估及危险减轻工作

的状况。

4.3.6核实、确认及用文件证明风险的减小。通过合适的分析、测试、演示、或

者检查，核实和确认所有已选减缓风险措施效果及执行情况。在危险跟踪系统中

生成核实和确认文件。

4.3.7可接受风险和文件。在暴露人、设备、或者是环境给以知相关系统危险前，

在DODI5000Q2.中，通过合适的权威机构定义的风险应该被接受。通过系统全寿

命周期，支持正常可接受风险决定的系统配置和相关文件应该被提供给政府保留。

除非根据国防部元件政策合适的可供选择的定义和/或者合适的矩阵将被认可，

定义在表一和表二中，风险评估编码在表三中，标准在表四中的软件习惯于在可

接受的时定义风险。通过系统的全寿命周期，典型的使用者应该是这个过程的一

个部分和应该提供正常发生的所有严重的和高危险的可接受决定。在试验、来自

事故报告的数据、使用者的反馈、相似系统的经验、或者是其他资源之后可能显

现新的危险、或者演示，演示来自已知危险的风险是比起目前已经识别的风险更

高或者更低。在这些情况里，依据DODI5000.02,修正后的风险应该被接受。

注：一个简单的系统经过全寿命周期，将需要大量的事故风险评估和接受。在危

险跟踪系统里，每一个风险接受决定应该被制成文件。

4.3.8管理全寿命周期的风险。在系统被测试后，通过系统全寿命周期，系统项

目主管使用系统安全过程去识别风险和维护危险跟踪系统。这个系统周期考虑到

了任何的改变。包括但不限制在接口、使用者、硬件和软件、事故数据、任务或

剖面和系统安全数据。程序应该放在合适的位置，以确保风险管理者可以意识到

这些改变。例如，通过部分配置的控制过程。项目主管和使用者协会应该保持有

效的交流合作、识别、管理新的危险及修正危险。如果新的危险被发现或比起目

前的评估，已知的危险决定了更高的风险水平。依据DODI5000.02,新的或修正的

风险需要被接受。此外，通过提供危险分析，国防部要求项目经理支持相关系统

A级和B级（在国防部说明书60s5.07被定义）的事故调杳，这样的事故调查有

助于事故及对材料风险减缓措施的规范，特别是对那些使人为差错减小的规范。

4.4软件促成的系统风险。对于软件的风险评估和软件控制或者是软件加强系统

不能单独的依赖风险的严重性和可能性。至多决定一个简单软件失效的可能性是

困难的，也不能基于历史数据。软件•般有特殊的应用而和作为与硬件相关的可

靠性参数不能被评估用相同的方法。因此，在软性所促成的系统风险的评估中其

他方法应该被使用o这些方法应该考虑潜在风险的严重度及软件使用超过硬件的

控制的程度。

4.4.1软件评估。通过表六表四应该被使用，除非合适的供选择的矩阵依据国防部软件政策

被承认。用在表四中（或者被承认的合适供选择的表）的软件控制分类定义软件控制程度。

表五提供了软件安全危险性矩阵基于表一严重度的分类（或者是被承认的合适的严重性分类）

和表四软件控制分类。软件分类严重性矩阵建立了软件严重性指标，这个指标被用于定义必

要的LOR任务。表四提供「SwCI及LOR任务与如何不满足LOR需求而影响到软件促成的风

险之间的关系。

A如果遗留的元件功能被包括在子系统的环境中,所有的软件控制分类应该被从新评估。遗

留功能应该被评估包括功能和物理接口两方面，这两个方面对潜在的影响或是参与到子系统

顶级水平的事故和危险相关因素进行评估。

b.系统安全和软件系统安全危险分析过程识别和减少了准确的软件编著者

的危险和事故。预定义的LOR任务成功的执行增加了当减少软件编著者的数量到

适合时，系统中存在的危险软件会按照软件经营要求的可信度。这两个过程是减

少软件初始化时危险条件和事故传播道路可能性的必要条件。附录B提供了开发

可接受的LOR任务的指导。

表IV.软件控制目录

软件控制目录

水平名称描述

•软件功能练习自主控制的权威在潜在的安全问题硬件系统、

子系统或组件不可能预先确定的安全检测和通过控制实体来干

1自主的预阻止事故的发生或危害。

（这个定义包括复杂的有多个子系统或互相平行的过程的、多

界面的、在时间临界上的安全临界的系统/软件功能。）

•软件功能进行控制潜在的安全度硬件系统、子系统或组件，

允许预定的安全检测和干预由独立安全机制来减轻或控制事故

或灾害。

（这个定义包括了控制比较复杂的系统/软件功能，没有并行过

程,或几个界面，但其他的安全系统/机制可以部分减少。系统和

2半自主的软件故障检测和通告通知需要所需的安全行动的控制实体。）

♦显示信息安全问题的软件项目，要求立即操作实体执行一个预

先确定的行动为来减小或控制事故或者危险。软件例外,失败，

错误,或延迟将允许,或未能防止事故发生。

（这个定义假设安全临界的显示信息可能是时间特别紧张的，

但可用时间不得超过充分控制实体响应和风险控制所需的时

间。）

•通过重要度安全硬件系统、子系统或组件来发布命令的软件

功能,需要控制实体来完成该命令功能。该系统检测和反应功能

包括冗余和为每个已定义的危险状况准备的独立的容错机制。

（这个定义假设有足够能力进行故障检测，报警，容错，和系统

3冗余容错的恢复以防止如果软件失效、失灵或退化时发生危险。有备用的

安全重要度信息和减损功能的可以在任何时间紧张的时间响

应。）

•软件生成信息的安全性至关重要的自然用来做重要决定。该

系统包括几个冗余的、独立的容错机制对于每个危险条件、检

测和显小。

4有影响的啾件生成一个与安全相关种类的信息来让运营商做决定，但不

需要操作者做出行动来避免事故。

­软件的功能要求不处理命令或控制安全问题硬件系统、了•系

5不影响安全的统或组件的度和不提供安全重要度问题。软件并不提供需要控

制实体相互作用的安全重要度或时间敏感数据或信息。软件不

转移或解决与通信的安全问题或对时间敏感的数据的交流。

4.4.2软件安全临界矩阵（SSCM）oSSCM对于列（表5）使用表1的严重性

类别，对于行使用的是表4的软件控制类别。矩阵的行和列相互参照的块在表5

中分配为SwCI。尽管它在外观上相似于风险评估矩阵（表3）,SSCM不是风险的

评估。与每个SwCI相关的LOR任务是最小的任务集合，这个任务是为系统风险

等级而需求的评估软件贡献。

表5.软件安全临界矩阵

SOFTWARESAFETYCRITICALITYMATRIX

SEVERITYCATEGORY

SOFTWARE

CatastrophicCriticalMarginalNegligible

CONTROL

CATEGORY(1)(2)⑶(4)

1SwCI1SwCI1SwCI3SwCI4

2SwCMSwCI2SwCI3SwCM

3SwCI2SwCI3SwCI4SwCI4

4SwCI3SwCMSwCMSwCM

5SwCI5SwCI5SwCI5SwCI5

SwCI精确任务的级别

SwCI1程序应当执行需求、体系结构、设计和代码的分析；并进行深入的安全特定测试。

SwCI2程序应当执行需求、体系结构和设计的分析；并进行深入的安全特定测试。

SwCI3程序应当执行需求和体系结构的分析；并进行深入的安全特定测试。

SwCI4程序应当进行安全特定测试。

SwCI5一旦由安全工程评估为不安全的话，就不需要安全特定分析或者检查。

注释：对于附加的关于如何进行所需的软件分析引导，请查询联合软件系统安全工程手册和

A0P52。

4.4.3风险评估软件的贡献。所有系统风险评估软件的贡献，包括表5中应用

的任何结果，在高温超导中(HTS)都应当记录。

a.为了评估系统风险水平软件的贡献，表5中的LOR(精确的水平)任务应

当被执行。LOR任务的结果在软件重要的软件安全方面提供了一定程度的可信程

度，并且记录了可能需要减少的相关因素和危险。在风险管理过程中应该包括

LOR任务的结果。附录B提供了一个如何把一个风险等级分配到由完成LOR分析

得到的系统风险软件贡献。

b.如果LOR任务没有被执行的话，通过表6得到与未被指定或者为完成的LOR

任务相关的系统风险贡献应当被记录。表6描述了SwCI,风险等级，LOR任务的

完成和风险评估之间的关系。

c.所有•系统风险评估软件的贡献，包括表5中应用的任何结果，在高温超

导中（HTS）都应当记录。按照DODI5000.02执行风险的接受。

表6

SwCI,风险等级，LOR任务的完成和风险评估之间的关系

SwCI风险等级软件LOR任务和风险评估/可接受性

如果SwCIlLOR任务没有被指定或者没有完成，系统风险的贡献

SwCI1高将被记录为高，并且为抉择提供PMoPM应该记录是否扩大资源

的决定，这些资源需要实现SwCI1LOR任务或者为高风险的可接

受准备一个常规的风险评估。

SwCI2严重如果SwCI2LOR任务没有被指定或者没有完成，系统风险的贡献

将被记录为严重，并且为抉揉提供PM。PM应该记录是否扩大资

源的决定，这些资源需要实现SwCI2LOR任务或者为严重风险的

可接受准备一个常规的风险评估。

SwCI3中等如果SwC13LOR任务没有被指定或者没有完成，系统风险的贡献

将被记录为中等，并且为抉抠提供PMoPM应该记录是否扩大资

源的决定，这些资源需要实现S*CI2LOR任务或者为中等风险的

可接受准备一个常规的风险评估。

SwCI4低如果SwCLlLOR任务没有被指定或者没有完成，系统风险的贡献

将被记录为低，并且为抉择提供PMOPM应该记录是否扩大资源

的决定，这些资源需要实现SwCI4LOR任务或者为低风险的可接

受准备一个常规的风险评估。

SwCI5不安全没有要求特别的安全分析或者测试

5.1额外的信息。单个任务，附录A,和附录B对于可选的特别的程序要求而

包含了可选的信息。

5.2任务。在这个标准中的任务可以有选择地应用到适合量身定制的系统安

全。100-系列任务适用于管理。200-系列任务适用于分析。300-系列任务适

用于评估。400-系列任务适用于验证。每个所需任务应当明确要求在一个合同,

因为任务描述不包括任何其他任务的要求。

5.3任务结构。每个任务分为三个部分的目的、任务描述和指定细节。

a.目表为执行的任务提供了解释理由。

b.如果这个任务在合同中提到的话，这个任务描述了一个承包商工作应当

履行。当准备提案时,承包人可以推荐将额外的任务或删除指定任务的理由对于

支持每个添加/删除。

c.细节必须在每个任务描述列出特定信息、添加、修改、删除或选项来要

求的任务时应该考虑的要求一个任务。然后将此信息连同任务数包括在合同文件。

每个任务列表提供不一定是完整的,可以补充。任何在需求中被选择的任务都应

该按照任务数量被实施为了RFP和ROW'。带有标注"（R）〃的指定细节是必需的。政

府给正确的执行提供了这个任务的细节。

6.注释

这节可能包括了一个通用或者可能有用的解释很自然的信息，但是不是强制

的。

6.1预期用途。这个系统安全标准被打算作为•个关键的SE的部分使用，SE

提供了一个标准的，泛型方法的识别、分类和危险减轻。它也不仅由安全专业人

员使用，而且也被其他功能学科使用，消防工程师、职业卫生专业人员和环境工

程师。

6.2获得要求。需求文档应当指定如下：

a.标准的标题，数量，日期。

6.3相关数据项说明（DIDs）。DIDs可能被应用到系统安全努力，包括:

DIDs编号DIDs标题

DI-ADMIN-81250会议记录

DI-MISC-80043弹药数据卡片

DI-MISC-80370安全工程分析报告

DI-ILSS-81495故障类型影响和临街分析报告

DI-SAFT-80101系统安全危险分析报告

DI-SAFT-80102安全及评价报告（SAR）

DI-SAFT-80103工程改变建议系统安全报告

DI-SAFT-80104免除或偏差系统安全报告（WDSSR）

DI-SAFT-80105系统安全程序进度报告

DI-SAFT-80106健康危险评价报告

DI-SAFT-80184辐射危险控制报告

DI-SAFT-80931爆炸性军械处理数据

DI-SAFT-81065安全研究报告

DI-SAFT-81066安全研究计划

DI-SAFT-81299爆炸危险分类数据

DI-SAFT-81300事故危险评价报告

DI-SAFT-81626系统安全过程计划

获得流线型和标准化信息系统（ASSIST）数据库应该在一下网址查看

/quicksearc来保证只有当前和许可的DIDs被列入DD表

1423中

6.4主要学科术语（关犍字）列表

环境

环境影响

ESOH（环境、安全和职业健康）

危险

危险品材料

HAZMAT（危险品）

健康危险

生命周期

事故

NEPA（国家环境政策法）

职业健康

PESHE（环境、安全和职业健康评估纲领）

PPE（个人防护装备）

可能性

风险

严重程度

软件安全

系统安全工程

系统工程

6.5之前发行版本的改变。在这个版本中边缘记号由于这个变化的程度不用来表

示至于之前的发行版本的改变。

任务部分100■管理

任务101

基于系统安全方法论的风险识别和风险减轻

101.1目的.任务101是基于系统安全方法论，将风险识别和风险减轻结合起来，

应用到国防部获性系统工程的过程。这个任务的目标应始终消除可能的危险。当

一个危险不能够被消除时，相关的风险应该在应用系统安全优先设计的基祀上,

在花费限制，目录和表现的范围内将其削减到最小可接受水平。

101.2任务描述.承包商应该：

101.2.1在系统工程的基础上，建立并且执行一个危险识别和削减的方法

来满足第四节中，总体要求，以及所有其他的由项目经理提出的的要求。

101.2.2执行危险识别和风险减少的方法，包括识别、足够的人力资源和

资金资源的分配。

101.2.3定义角色、责任和相互之间的关系，也就是项目组织和相关项目

之间的通讯线。定义不同风险识别和其他的风险削减功能性准则（包括配置控制

和数据管理，可靠性，可维修性，人类系统合成（HSI））以及项目其他重要性的

元素，包括项目管理，测试和升级，计算，财政，和承包。

101.2.4确保分包商，相关的承包商，商贩，和供应商的要求是可接受

的。这些要求包括由分包商，相关的承包商，商贩，和供应商提出的定义危险分

析，风险评价输出，和核定数据与资料（包括设计和方法论）。

101.2.5关于系统，子系统，和部件系统审查的风险等级评价报告，例如，

系统要求审查（SRR）,预先危险性设计（PDR）,批判设计审查（CDR）,灵敏

度测试审查，和产品灵敏度审查。

101.2.6应用一个封闭的风险监控系统，包括分包商，商贩，和危险数据

提供者。对于这个监控系统所要求的最小数据元素是危险，系统，子系统，可应

用性，要求证书，系统模式，因果相关因素，影响，灾难，基本风险，事件风险，

目标风险，减少风险的措施，和风险水平，审查和确定方法，其作用的人（人们），

可接受风险记录，和风险管理的度量。

101.2.7除非特定的定义或者是特定的矩阵与国防部的部件政策完全一致，否则,

表格一和表格二中的定义，及表格三中的风险评价矩阵将被应用到。

101.2.8作为一个最小量，报告如下准则：

a.危险和相关风险

b.功能，账目，和与危险相关的材料

c.对于操作可接受的要求，维持，支持，和排列

d.可接受的抑制方法

101.2.9对于综合性的驱动事件，审查，支持，保证，分析，释放和文件数据提

供正确定义和输出

101.3列明的细节.计划的要求和工作的提议应包括以下可应用到的准则：

a.任务101的税收

b.应用于此任务的功能性准则识别

c.事件进程的要求

d.此任务的要求和方法论的报告

e.对于实施危险识别和风险抑制工作的关键人员的资格要求

f.其他的列明的危险识别和风险降低的方法的要求，例如，列明的风险识别方法

和矩阵（如果它们与第四节提到的不同）将应用到这个项目

任务102

系统安全程序计划

102.1目的.任务102是开发一个系统安全程序计划来证明对于识别，分类，和

安全风险的减少的系统安全方法论是系统安全工程的一部分。系统安全程序计划

应是系统工程管理计划的不可分割的一部分。系统安全程序计划详细描述了实施

一个系统的方法进行危险分析，风险评价，和风险管理时所要求的任务和工作。

目标始终致力于消除正能出现的危险。当一个危险不能够被消除时，相关风险在

经费限制，日程，和系统安全优先设计应用的演算范围内降到最低。

102.2任务描述。承包商应该开发一个系统安全程序计划来提供一个基本方法，

以便于承包商和项目经理理解安全危险怎样结合到系统工程过程中。系统安全程

序计划包括如下准则：

102.2.1范围和目标.系统安全程序计划应该在最小量上描述一下：⑴就系统

和它的生命周期而言的工作范围，（2）整个方法可以完成在第四节和其他合约地

要求的任务，（3）整合的这些工作为系统工程和其他项目办公室管理的流程可以

来支持项目的总体目标,和⑷执行SSPP所需要的资源需求（资金、人才、和工具）。

本节将解释所有合同风险管理需求通过提供一个矩阵，这些合同需求相关的位置

在系统安全程序计划处理中的应用。

102.2.2系统安全程序计划接口.系统安全程序计划应该：

a.SSPP涵盖的识别功能规范。

b.在以下二者间描述SSPP的接口：

（1）系统工程

（2）其他相关学科（如：物流、可维护性、质量保证、可靠性、人体工程学，可移

植性工程和医疗支持（健康危害评估））。

102.2.3组织.SSPP应当在最低标准描述以下：

a.SE过程中的组织或功能的系统安全。使用图表显示组织和功能关系和行通信。

bo员工（人力加载和时间表）的系统安全的工作,每一个涉及到的功能性学科和组

织单元的合同期限。

SSPP将确定参与执行系统安全要求合同的每一个人和组织单位的责任和权力。

此外，SSPP将确定关键人员，并提供关键系统安全人员的资格和证书的概要。

SSPP将介绍在关键系统安仝人员变动之前承包商应何时和怎样通知政府。

c.程序的承包商将使用整合系统级和系统的系统（SOS）级得出的危险管理结果

在合同所涵盖的范围内。这些将包括：

（1）定义每个相关的承包商和分包商（供应商和供应商也适用）在总系统集合

安全要求中的角色。

（2）确定各个相关的承包商和分包商之间的安全协调工作（供应商和供应商也

适用），例如：整合风险分析。

（3）与相关的承包商和分包商（供应商和供应商也适用）的代表建立综合的产

品团队（IPTS）或工作组（WGs）。

（4）描述任何特定SOS整合的角色和责任。

（5）硬件和软件的整合由政府提供的。

（6）为行动的组织和分包商分配要求。

（7）协调分包