-
前言
1.
此标准被批准应用于国防部所有的军事部门和国防机构。
2.
此系统安全标准是系统工程的关
键要素，它为识别、分析和减轻危险提供了
一个标准和通用方法。
3.
国防部承诺保护个人免受意
外的死亡、伤害、职业病以及在执行国防要求的
任务时，保护防御系统、基础设施和财产
免受意外的毁坏或破坏。在任务要
求里，
国防部也会确保把环境
保护到最大可能的程
,
整个这些努力就是使用系
统安全方法来识别危险并处理与危险相关的风险。国防部的关键目标是扩大
系统
安全方法论的使用，来把风险管理融入到整个系统工程当中，而不是把
危险看做是操作因
素。
它不仅可以被系统安全专家使用
.
还可以应用于其他功
能学科，比如火灾保护工程师、职业健康专家和环境工程师来识别危
险并通
过系统工程减轻风险。此文件的目的不是在其他功能学科使用系统安全解决
个人的危险管理问题，但是，所有使用此通用方法的功能学科都应该把工作
协调为整个系统工程的一部分，因为一个学科减轻危险的措施可能会在其他
学科产生
危险。
4.
此系统安全标准确定了国防部识
别危险并评价和减轻相关风险的方法，这些
危险和风险是在防御系统的开发、测试、生产
、使用以及报废阶段遇到的。
这个方法描述了要与国防部指令一致。
国防部指令定义了风险的可接受水平。
5.
本次
修订包含了满足政府和工业要求的改变，恢复了任务说明书。这些任务
可能在合同文件中
规定。当本标准在要求或合同中需要的时候，如果没有特
殊要求，
只有第三章和第四章是强制的。
3.2
和整个第四章的定义描
绘了任何
国防部系统可接受的系统安全最低的强制性定义和要求。本次修订把标准的
执行与当前的国防部政策相结合，支持国防部的战略性计划和目标，调整了
< br>信息的组织安排，阐明了系统安全过程的基本要素，阐明了术语并定义了任
务说明
书来改善危险管理。本标准强化了其它功能学科与系统工程的结合，
最终通过大纲改进危
险管理实务的一致性。特殊的改变包括：
a.
重新介绍了任务说明书：
（
1
）
100-
系列任务
-
管理
（
2
）
200-
系列任务
-
分析
ii
（
3
）
300-
系列任务
-
评价
（
4
）
400-
系列任务
-
确认
b.
强调了可应用的技术要求的识别
c.
包括附加的任务：
（
1
）
危险物质管理计划
（
2
）
功能危险分析
（
3
）
系统之间危险分析
（
4
）
环境危险分析
d.
应用严重性描述损失价值的增加
e.
增加了“消除”可能性水平
f.
增加了软件系统工程技术和实务
g.
更新了附录
6.
对此文件的评论、建议或问题应
该递交到美国空军装备司令部总部
iii
附录
B
(2)
与由软件引起并控制的系统危险相关的风险是可以接受
的，
基于证据
（危险，
起因以及降低风
险的措施已经根据国防部顾客的要求得以识别，
执行以及核实）
。
证据支持了这样一种结论，
危险控制提供了必需的降低危险的
水平并且合成的风
险能够被适当的风险接受权威所接受。
就这一
点而言，
软件与硬件和操作者没有
什么不同。
< br>如果软件设计没有满足安全要求，
那么就会导致与没有充分核实软件
危险起因和控制相关联的风险。
一般说来，
风险评价
是以定量和定性的判断和证
据为基础的。表格
B-I
显示这些原则是如何应用的，来提供一种与软件因素相关
联的评价方法。<
/p>
表格
B-I
软件危险因素的风险评价标准
风险水平
风险标准描述
在正常或不正常的操作或测试期间出现软件执行或软件设计不
足：
< br>
●
能直接导致灾难性的或危急的事故，或者
高度的
●
使系统处于一种状态，这种状态下，没有独立的连锁装置能<
/p>
够排除潜
在的灾难性及危急事故的发生
●
能直接导致临界的或轻微的事故，或者
严重的
●
使系统
处于一种状态，
只有一个独立的连锁装置或人为活动
来排除潜在
的灾难性或危急危险的发生
●
影响临界的或轻微事故，将系统失效降低到单独的一点，或
中等的
者，
●
使系统
处于一种状态，
有两个相互独立的连锁装置或人为活
动来排除潜
在的灾难性或危急性事故的发生
●
影响灾
难性或危急性的事故，
但是有三个相互独立的连锁装
置或人为活动保留，或者
●
会有影
响临界的或轻微事故的因果相关的因素，
但是有两个
低的
相互独立的连锁装置或人为活动保留
●
没有被
分类为高度的、严重的、或中等的安全风险等级的软
件的安全关键功能退化
●
< br>要求，如果执行了，就会对安全产生负面影响，然而代码是
安全执行的
e.
定义并执行与危险相关的风险评价过程对
计划的成功是关键的，尤其是当系
统和更加复杂的系统之间相结合。
这些系统之间常常包含在不同的开发条件和安
全计划下开发的系统，并且可能需要与
其他服务（陆、海、空军）或国防部机构
系统相接。
这些其他的
系统之间的利益相关者可能有他们自己的安全过程，
用来
决定与
他们的系统相结合的系统的可接受性。
军用标准
882E
1
、范围
1
.1
范围：
这个系统安全标准的实行确定了国防部系统工程的方
法来消除危
险，如果可能的话，或者使那些不能消除的危险的风险最小化。国防部指令里
5000.02
定义了风险可接受的优先性。这个标准覆盖了系
统、产品、设备、基础
设施（包括硬件和软件的）贯穿于整个设计、研发、实验、产品、
使用和清理阶
段的所有危险。
当这个标准在一个说明或是合同里
被要求但是又没有特定的任务
被定义时，
只有三、
四部分是强制的。
3.2
里的定义和第四部分的全部
描绘了
最
小化强制性定义和要求对于
任何国防部系统的一个可接受的系统安全努力。
2
、适用的文件
2.1
通用。在这部分文件列出的是标准的第三、四、五部分里规定的。这一
章不包括本标准中其他章节引用的文件或是推荐的额外信息或是例子。
然而每个
努力都已经被做确保这一列表的完成。
文件使用者应注
意到他们一定会遇到在本
标准第三、四、
、五章里引用的文件的
规定要求。无论他们是否列出。
2.2
政府文件
2.2.1
说明书、标准和手册。下面的说明书、标准和手册在某种规定的范围
内形成了文件的一部分。除非不被规定的，这些文件的问题都在合同里被引用。
国际标准化协议
AOP52 NATOAOP52.
关于软件安全设计的指
导和相关计算系统必需品的评
估。
（这个文件的副本在这个
/quicksearch/
网站上可
以获
得或从标准化文件排序桌面获得。费城罗宾斯大街
700
号
4D
建筑里。
PA
19111-5094
）
国防部手册
没有指定者
软件系统安全
工程接口手册（这个文件的副本在这个
/links/
网站上可
以获得）
2.2.2
其他的政府文件、图纸和出版物。下面这些其他政府文件
、图纸和出版物
形成了文件规定程度上的一部分。
除了没有规定
的。
这些文件的问题就是在合同
里引用的。
国防部指令
DoDI
5000.02-
防御获得系统的操作
9DoDI 6055.07-
事故通告、调查、报道和记录保持
(
这个文件的副本在这个
/links/
网站上可
以获得
)
2.3
优先命令
在一个突发事件中在这个文件的文本和引用于此的参考文献
中间，文件的文本是优先
的。除了
DoDI 5000.02
例外。在这个文件中没有什
么
能接替可应用的法律和法规，除了一个规定的免除包含在内。
3.
定义
3.1
首字母缩拼词
AFOSH
空气促使职业安全和健康
ANSI
美国国家标准协会
AOP
联合军火出版物
AMSC
获得管理系统控制
ASSIST
获得流线型和标准化信息系统
ASTM
美国社会检验和材料
AT
自主的
CAS
化学文摘服务
CDR
关键设计评审
CFR
联邦法规代码
COTS
商业成品
DAEHCP
军火防御部门和爆炸危险分类程序
DID
数据项描述
DoD
国防部
DoDI
国防部指令
DODIC
国防部标识码
DOT
运输部
DT
研发测试
E3
电磁环境影响
ECP
工程改变提议
EHA
环境危险分析
EMD
工程和制造业发展
EO
行政指令
EOD
爆炸性军械处理
ESD
静电放电
ESOH
环境安全和职业健康
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-
HDBK
军用手册
MIL-
STD
军用标准
MSDS
材料安全数据表
NATO
北大西洋公约组织
NAVMC
海军和海军陆战队
NDI
发展条款
NEPA
国家环境政策法
NSI
不安全影响
NSN
国家物料编号
O&SHA
操作和支持危险分析
OSH
职业安全和健康
OSHA
职业安全与健康管理
OT
操作测试
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
采办计划。一个直接的
,
资助的努力
,
提供了一个新的
< br>,
改进的
,
或继续物资
,
武
器
,
或信息系统或服务能力以应对一个批准的需要。
第
3.2.3
病原。一个或多个机制
,<
/p>
触发了风险
,
可能导致事故。
3.2.4
条商用现
货
(COTS)
。商业项目
,
不需要独特的政府修改或维护生命周期的产
品来满足需求的采购代理。<
/p>
3
2
5<
/p>
承包商。一个实体在私人行业进入合同与政府提供的商品或服务。在这个
< br>标准
,
这个词也适用于政府运营的活动
< br>,
开发或收购国防项目上执行工作。
< br>3.2.6
环境影响。一个对环境不利变化引起的全部或部分的系统或其使用。<
/p>
3 2 7 ESOH
。
一个首字母缩略词
,
指的是结合学科
,
包括流程和方法解决的法律、
法
规、行政命令
(EO),
国防部政策、环境合规
,
和相关的危险的环境影响、系统安全
(
如。
、平台、系统、体系、武器、爆炸物、软件、军械、作战系统
),
职业安全与
健康、危险物品管理
,
和污染防治。
3
2 8
事件风险。
相关的风险和危害
,
因为它适用于指定的硬件
/
软件配置在
一个事
件。
典型的活动包括发展测试
/
操作测试
(DT / OT)
、
示威、
部署、
post
菲尔丁测试。
3 2
9
防守。将系统为操作使用单位在田里或舰队。
3 2 10
固件。
结合一个硬件设备
和计算机指令或计算机数据驻留为只读软件硬件
设备。这个软件不能轻易修改在程序的控
制下。
3211
工作设备
(GFE)
。财产的占有或由政府直接获得
,
随后交付或其他可用的承包
商使用。
3
．
2.12
工作
信息
(GFI)
。信息在拥有或由政府直接获得
,
随后交付或其他可用的承
包商使用。政府提供的信息
可能包括物品如教训类似的系统或其他数据
,
通常不
会被可用的非政府机构。
3
．
2.13
政府从架子上
(GOT
S)
。硬件或软件开发、生产
,
或属于
一个政府机构
,
不需
要独特的修改在生
命周期的产品来满足需求的采购代理。
3
．
2.14
风险。
一个真正的或潜
在的条件
,
可能导致意外事件或一连串的事件
< br>(
即事
故
)
导致死亡、受伤、职业疾病
,
损害或损失的设备或财产
,
或对环境的破坏。
3
．
2.15
有害物质
(
有害
)
。任何项目或物质
,
由于它的化学、物理、毒理学、或生
物性质
,<
/p>
可能导致伤害人
,
设备
< br>,
或环境。
3
．
2.16
人力系统集成
(<
/p>
溪
)
。集成的和全面的分析、设计、评估
的需求、概念和
参考资料系统人力、人员、培训、安全、职业健康、适居性、人员生存能
力
,
和
人类工程学。
< br>
3
．
2.17
最初的风险。第一个评估潜在的风险识别出风险。初步建立了一个固定
的基线风
险的危害。
3
．
2.18
精确级别
(
特
)
。一个规范的深度和广度的软件分析和验证活动必要提供
足够的自信程度
,
安全性至关重要的或安全软件功能将
根据需要执行。
3
．
2.19
生命周期。
系统的所有阶段的生活
,
包括设计、
研究、
开发
、
测试和评估、
生产、部署
(
库存
)
、操作和支持
,
和处理。
3
．
2.20
事故。一个事件或一系列事件导致意外死亡、受伤、
职业疾病
,
损害或损
失的设备或财产<
/p>
,
或对环境的破坏。对于本标准中
,
术语
“
灾祸
”
包括从计划事件对
环境的不良影响。
3
．
2.21
缓解
措施。行动需要消除危害或当一个危险不能消除
,
减少相关的风
险
,
减少事故的严重性或降低导致事故的可能性会发生。
3
．
2.22
模式。一个指定的系统状态或状态
(
如。<
/p>
、维护、测试、运行、储存、运
输和非军事化
)
。
3
．
2.23
货币损失。
估算成本的总和
为设备维修或更换
,
设备维修或更换
,
环境清洁、
人身伤害或疾病、环境负债
,
应包括任何已知的罚款或罚金造成的事故预测。
3
．
2.24
非发展项目
(NDI)
。项目
(
< br>硬件、软件、通讯
/
网络
,
等等
),
用于系统开发程
< br>序
,
但并不发达
,
作为该计划的一部分。
NDIs
包括但不限于
,COTS,GOTS,GFE,
再利用
物品
,
或以前开发的项目提供程序
“
目前的
”
。
3
．
2.25
概率。
一个表达式的事故发生的可能性的
3
．
2.26
个项目经理
(PM)
。指定的政府个人负责和权威来完成项目目标开发、生
产
,
和系统
/
产品
/
设备的维护以满足用户的操作需求。项目经理负责可靠的成本
,
进度
,
性能并汇报给里
程碑决策机构。
3.2.27
重用项目
一个提前开发好的项目被用于另一个程序或应用于令一个单独
的应用程序
3.2.28
风险
事故严重性和事故发生可能性的组合
.
3.2.29
风险水平
对风险高
,
严重、中或低的描述
.
3.2.30
安全
不能引起死亡、伤害、职业病、设备或财产的破坏、损失，环境破坏
的状
态。
3.3.31
安全关键性
一个术语应用于一个状态、事件、操作、进程或项目。事故的
严重性是灾难
性和危机性的。
（例如，安全关键性函数，安全关键性路径和安全
关键性部件）
3.2.32
安全关键性函数
一个函数
,
其失败或不正确的操作将直接导致
事故的灾难
性或危机性事故严重程度
3.2.33
安全关键性项目
一个硬件或软件项目被决定于通过分析来确定潜在的导
致危害发生的灾难性关键性事故的潜力
,
或者
,
或者应用于减轻导致危害的灾难性
或
关键性事故的潜力。本标准中术语
“
安全关键项目
“
的定义是独立于术语
“
关
键
安全项目
”
在公共法
108 - 136
和
109 -
364
的定义的。
3.2.34
安全相关
一个术语应用于一个状态、事件、操作、进程或项目。事故的严
重性是临界的
或可以忽略的。
3.2.35
安全意义
个术语应用于一个状态、
事件、
操作、
进程或项目被鉴定为安全
关键或安全相关。
3.2.36
严重性
一个事故潜在结果的大小，包括：死亡，伤害，职业病，设备或
财产的破坏或
损失，环境破坏，或者财政损失。
3.2.37
软件
使计算机能够执行计算或控制功
能的相关计算机指令和计算机数据
的结合。
软件包括计算机程序
、
规程、
规则以及任何相关的文档有关的计算机系
统的操作。
软件包括新的发展
,
复杂可编程逻辑器件
(
固件
),N
DI,COTS,GOTS
、
重用、
G
FE,
和政府开发的软件用于系统中。
3.2.38
软件控制类别
在一个系统特性的背景下对软件功能自治的程度
,
指挥和控
制权力和冗余容错的赋值。
3.2.39
软件重用
在一个软件应用的发展程序中使用一种先前开发的软件模块或
软件包
3.2.40
软件系统安全
将系统安全的原理应用于软件。
3.2.41
系统
需要在规定的环境中得到指定的结果的硬件、软件、材料、设备、
人员、数据的
和指定功能的服务的组织
。
3.2.42
体系
一组或一系列相互依赖的系统相关联于提供一个给定的能力
3.2.43
系统安全
在系统整个生命周期的所有阶段，应用工程和管理原则、标准
,
和技术利用有限的操作效能和适用性、时间和成本来达到可接受的风险
3.2.44
系统安全工程
一个工程学科
,
运用专业知识和技能于应用科学
和工程学
科，标准和技术，以识别危险然后消除危险或当危险无法消除时减少相关风险。
3.2.45
系统安全管理
识别危险
;
评估和减轻相关风险
;
跟踪、
控制、<
/p>
接受和记录在
系统、子系统、设备和设施的设计、开发、测试、获
取、使用和处理中遇到的风
险的所有计划和行动
3.2.46
系统
/
子系统
说明
对于给定的系统中系统等级的
功能和性能需求，连接，
适应需求，
安全性和保密性需求，
计算机资源的需求，
设计约束
（包括软件架
构，
数据标准和编程语言）
，软件支持，优先级的需求，研制试
验的需求。
3.2.47
系统工程
一个项目团队的总体过程，
适用于从上述能力的有效运作和合适
的系统过渡。系统工程涉及到的应用
SE
适应每个阶
段的生命周期（）在整个收
购过程的目的是要平衡的解决方案的整合机制，
处理能力需求，
设计考虑因素和
制约因素。
SE
还涉及技术，预算和进度的限制。
SE
进程早期应用材料解决方
案的分析
和持续整个生命周期。
3.2.48
目标风险
预计风险水平的
PM
计划以实现符合设计的优先顺序
实施缓解
措施的在
4.3.4
中的描述
3.2
．
4
9
用户代表
对于保护事件，一个命令或代理
,
已被正式指定在联合功能集
成和开发系统
(JCIDS)
过程中代
表单个或多个用户的能力和采集过程。
对于无保护
事件，
用户代表付命令或代理责任对暴露在风险中的人员，
设备和环境。
对于所
有的事件，用户代表将有同等的水平相当于风险接受权威。<
/p>
4.
常规
/
一般要求
4.1
常规。当本标准被要求在招标或合同，但不包括具体的任务，只有第
3
节和
第
4
节的规定适用。
3.2
和所
有第
4
节中的定义是国防部系统任何一个可以接受的
系统安全工作最低强制性规定和要求。
4.2
系统安全要求
第四节通过任何系统的整个生命周期定义了系统安全要求。
如
< br>果运用得当，
这些要求应使在系统开发和维持工程活动的危害和相关风险的识别<
/p>
和管理。本记录的目的不是使系统的安全人员负责风险管理在其他的功能学科。
然而，
所有的功能学科使用这个通用的方法应该协调每个部分的努力优化的
整体
的系统工程过程，因为一个学科的最优缓解措施可能对其他学科产生危险。
4.3
系统安全过程。系统安全过程包含
8
个元素。图
1
描
述了过程的典型逻辑序列。
然而，可能需要在各个步骤之间的迭代。
4.3.1
记录系统安全方法
项目管理人和订约人应该记录下系统安全方法，为了
给作为系统工程进程中完整的一部分的风险管理，系统安全方法的最低要求包
括：
a.
描述风险管理的影响和
如何使得风险管理和系统工程进程，集成产品和过程开
发进程，总的项目管理构造成为一
体
。
b.
描述和记录可适用于系统的规定和派生的需求。例子包括顿感弹药的需求，
电磁换效应的需求，污染防治任务，设计需求，技术因素，职业病和社区噪音标
准。
一旦需求被定义，
确定系统说明书的内容和可用的流程要
求给转包商，
承包
商和供应商。
c.
定义如何使得与美国军标
I5000.
02
一致的危险和相关风险被使用者的代表正式
的接受和同意。
d.
文件编制一个闭环危险追踪系统
危险。危险追踪系统将会包括，作为最低限度
的以下数据元素：确认危险，相关事故，风
险评估（最初的，目标，事件）
，定
义风险缓解措施，选定缓解
办法，危险状态，验证风险的降低，和风险的可接受
度。
政府和
承包商有权使用危险追踪系统来适当的控制数据管理。
政府应该接收
和保留“政府的目标权利”
，所有的数据记录在危险追踪系统和其他条款（即，
研究，分析，测试数据，注释，类似的数据）
4.3.2
定义和记录危险。
危险通过系统性的分析过程被定义，这个过程包括系统
硬件和软件，系
统界面（包括人机界面）
，具体的使用或应用，操作环境。考虑
和使用事故数据；相关的环境和职业；使用者的物理特性；使用者的知识，技术
和能力；
来自以往相似系统事故的经验和教训。
危险识别过程应该考虑整
个系统
的生命周期和对于人的潜在影响，基础设施，防御系统，公众，和环境。危险识<
/p>
别应该被记录在危险追踪系统。
4.3.3
评估和记录风险
事故严重程度的分类和所有系统模型的不同危险的潜在
事故可能性等级被评估，用来定义表
I
，
II
。
a
．
表一中
给出了确定给定的危险在给定的时间点来确定正确的严重性分类的方
法，定义了死亡或者
伤害，环境影响，或者财产损失的潜在可能性。一个给定的
危险可能会产生一个或者所有
的影响。
表一
.
严重性分类
严重性分类
事故结果准则
种类
严重性分类
灾难性的
1
严重的
2
轻微的
3
可忽略的
4
一种或者多种结果如下：死亡，终身残疾，不
可逆的重大环境影响，
< br>≥
1000
万美金的财产损
失。
一种或者多种结果如下：永久性部分残疾，伤
害或者导致住院人数超过
3
人的职业病，可你
的重大环境影响，≥
100
万，≤
1000
万美金的
财产损失。
一种或者多种结果如下：导致一天或者更多天
的工作日损失
的伤害或职业病，可恢复的轻微
环境影响，
≥
< br>10
万，
≤
100
万美金的财产损失。
一种或者多种结果如下：导致
轻微伤害或职业
病，
但不会导致损失工作日，
< br>最小的环境影响，
≤
10
万美金
的财产损失。
b.
表二中给出了确定给定危险在给定时间点适当的可能性等级，
评估了事故发生<
/p>
的可能性。
可能性等级
F
被用来记录不存在风险的地方的例子。
没有大量的学说，
培训，警报，警告，警示，或者个人防护设施可以达到事故可能性等级
F
。
表二
可能性等级
可能性等级
具体内容
在寿命周期内可能发生
在寿命周期内发生多次
在寿命周期内可能发生
在寿命周期内不易发生，但有可
能性
极不易发生，几乎认为不可能发
生
<
/p>
不能发生，这个等级是用来当潜
在的危险被定义和被排除时。
种类
频繁的
很可能的
偶然的
可
能
性
极
小
的
不太可能的
没有可能性
等级
A
B
C
D
E
F
系统
连续发生
将会发生若干次
将会发生几次
不易发生，但有理
由可预期发生
不易发生，但有可
能发生
不能发生，这个等
级
是
用
来
当
潜
在
的
危
险
被
定
义
和
被排除时。
(1)
运用适
当的和代表性的定量数据定义危险的频率和发生率，一般最好定量分
析，
不可能等级是一般被认为是低于一百万，
附录
A
给出了一个定量可能性等级
的例子。
(2)
缺少定量频率或数据率时，依赖于表二的定性分析是有必要的并
且适合的。
c.
风险评价被表达为一
个风险评估代码，这种代码是严重性分类和可能性等级的
结合，例如，
< br>RAC
中的
A
是大型和频繁发生
等级的事故，表三把不同的风险评估
代码的风险等级划分为，高等，严重，中等，和低等
。
表三
风险评价矩阵
风险评价矩阵
严重的
轻微的
（
2
）
（
3
）
高
高
严重的
中等的
中等的
严重的
严重的
中等的
中等的
中等的
严重性
可能性
频繁的
（
A
）
很可能
（
B
）
偶然的
（
C
）
可能性极小的
（
D
）
不太可能的
（
E
）
没有可能性
（
F
）
灾难性的
（
1
）
高
高
高
严重的
中等的
没有可能性
可以忽略的
（
4
）
中等的
中等的
低
低
低
d.
表一，表二的定义和表三的
RAC
（风险评估代码）应该被用来，除非与美国军
用标准的部分政策一直
的不同定义和矩阵被正式的认可，
代理人应该从表一到表
三中提
取。
e.
项目应该按照
4.3.1
的要求把所有可能性规定转换成数值使用在风险评估中。
评估风险应该被记录在
HTS
（危险追踪系统）
。
4.3.4
定义和编辑风险缓解措施。潜在的风险缓解应该被定义，并且预期风险降
低的选择应
该被评估和记录在危险追踪系统。如果可能的话目标应该是消除危
险。
< br>当一个风险不能被消除时，
通过应用系统安全设计的优先次序，
< br>相关风险应
该被降低到成本和性能的最低可接受水平。
系
统安全设计的优先次序给出了选择
性抑制的方法和通过列表来降低影响。
4.3.4
A
通过设计选择排除危险
。理论上，通过设计的选择或者是移除危险的材料的选
择，可以排除的危险。
B
通过修改设计减小风险。
如果采取改变供选择的设计或者材料去排除危险是不
可行的，那么考虑改变设计减小
因危险引起潜在事故的严重性和
/
或者可能性。
C
包含工程特征或装置。如果通过设计选择减缓风险
是不可行的，那么使用工程
特征或装置，减少因危险引起潜在事故的严重性和可能性。<
/p>
D
提供报警装置。如果工程特征和装
置是不可行的或者不能使因危险引起潜在
事故的严重性和可能性足够低。
那么使用包括探测和警报系统使人警觉到危险情
况的存在或者是危险事件的发生
。
E
包含指导标示、程序、训练和保
护人的设备。这里供选择的设计、改变设计、
工程特性和装置是不可行的和警报装置不能
充分的减少因危险引起潜在事故的
严重性和可能性。那么使用包含指导标示、程序、训练
和保护人的设备。指导标
示包括海报、
标示、
< br>符号和其他可见的图形。
程序和训练应该包括适当的警告和
警示。
程序可以描绘保护人的设备的使用。
对于被赋值为灾难
性危险或者是危险
事故严重性分级、指导标示的使用、程序、训练、和保护人的设备用作
唯一的减
少风险的方法应该被避免。
4.3.5
减小风险。减轻措施被选择和执行去获得可接受水平。考虑和评估花费、
可行性、
候选减轻方法的效果作为系统工程的一部分和使生产机组加
工完整。
技
术检查时提出当前存在的危险、
他们相关危险性和严重性的评估及危险减轻工作
的状况。
4.3.6
核实、确认及用文件证明风险的减小。通过合适的分
析、测试、演示、或
者检查，
核实和确认所有已选减缓风险措施
效果及执行情况。
在危险跟踪系统中
生成核实和确认文件。
4.3.7
可接受风险和文件。在暴露人
、设备、或者是环境给以知相关系统危险前，
在
DODI500
0.02.
中，
通过合适的权威机构定义的风险应该被接受。<
/p>
通过系统全寿
命周期，支持正常可接受风险决定的系统配置和相关
文件应该被提供给政府保
留。除非根据国防部元件政策合适的可供选择的定义和
/
或者合适的矩阵将被认
可，
< br>定义在表一和表二中，
风险评估编码在表三中，
标准在表
四中的软件习惯于
在可接受的时定义风险。
通过系统的全寿命周
期，
典型的使用者应该是这个过程
的一个部分和应该提供正常发
生的所有严重的和高危险的可接受决定。在试验、
来自事故报告的数据、
使用者的反馈、
相似系统的经验、
或者是其他资源之后
可
能显现新的危险、
或者演示，
演示来
自已知危险的风险是比起目前已经识别的风
险更高或者更低。在这些情况里，依据
DoDI5000.02,
修正后的风险应该被接受。
注：
一个简单的系统经过全寿命周期，
将需要大量的事故风险评估和接受。
在危
险跟踪系统
里，每一个风险接受决定应该被制成文件。
4.3.8
管理全寿命周期的风险。在系统被测试后，通过系统全寿命周期，系统项
目主管使用系统安全过程去识别风险和维护危险跟踪系统。
这个系统周期考虑到
了任何的改变。包括但不限制在接口、使用者、硬件和软件、事故数据、任务或
剖面和系统安全数据。
程序应该放在合适的位置，
以确
保风险管理者可以意识到
这些改变。
例如，
通过部分配置的控制过程。
项目主管和使用者协会应该保持有
效的交流合作、
识别、
管理新的危险及修正危险。
如果新的危险被发现或比起目
前的评估，已知的危险决定了更高的风险水平
。依据
DoDI5000.02,
新的或修正的
风险需要被接受。
此外，
通过提供危险分析，
国防部要求项目经理支持相关系统
A
级和
B
级（在国防部说明书
6055.07
被定义）的事故调查，这样的事故调查有
助于事故及对材料风险减缓措
施的规范，特别是对那些使人为差错减小的规范。
4.4
软件促成的系统风险。对于软件的风险评估和软件控制或者是软件加强系统
< br>不能单独的依赖风险的严重性和可能性。
至多
决定一个简
单软件失效的可能性是
困难的，
也不能基于历史数据。
软件一般有特殊的应用而和作为与硬件相关的可
靠性参数不能被评估用相
同的方法。
因此，
在软件所促成的系统风险的评估中其
他方法应该被使用。
这些方法应该考虑潜在风险的严重度及软件使用超过
硬件的
控制的程度。
4.4.1
软件评估。通过表六表四应该被使用，除非合适的供选择的矩阵依据国防部软件政策
被承认。用在表四中（或者被承认的合适供选择的表）的软件控制分类定义软件控制程度。
表五提供了软件安全危险性矩阵基于表一严重度的分类（或者是被承认的合适的严重性分
类）
和表四软件控制分类。
软件分类严重性矩
阵建立了软件严重性指标，
这个指标被用于定
义必要的
LOR
任务。
表四提供了
SwCI
及
LOR
任务与如何不满足
LOR
需求而影响到软件促成
的风险之
间的关系。
A
如果遗留的元件功能被
包括在子系统的环境中，
所有的软件控制分类应该被从新评估。
遗
留功能应该被评估包括功能和物理接口两方面，
这两个方面对
潜在的影响或是参与到子系统
顶级水平的事故和危险相关因素进行评估。
b.
系统安全和软件系统
安全危险分析过程识别和减少了准确的软件编著者
的危险和事故。
预定义的
LOR
任务成功的执行增加了当减少软件编著者的数
量到
适合时，
系统中存在的危险软件会按照软件经营要求的可信
度。
这两个过程是减
少软件初始化时危险条件和事故传播道路可
能性的必要条件。
附录
B
提供了开发<
/p>
可接受的
LOR
任务的指导。
表
IV.
软件控制目录
软件控制目录
水平
1
名称
自主的
描述
·软件功能练习自主控制的权威
在潜在的安全问题硬件系统、
子系统或组件不可能预先确定的安全检测和通过控制实体来
干
预阻止事故的发生或危害。
（这个
定义包括复杂的有多个子系统或互相平行的过程的、多
界面的、在时间临界上的安全临界
的系统
/
软件功能。
）
?
·软件功能进行控制潜
在的安全度硬件系统、子系统或组件
,
允许预定的安全检测和干
预由独立安全机制来减轻或控制事故
或灾害。
（这个定义包括了控制比较复杂的系统
/
软件功能
,
没有并行过
程
,
或几个界面
,
但其他的安全系统
/
机制可以部分减少。
系统和
软件故障检测和通告通知需要所需的安全行动的控制实体。
）
< br>
·
显示信息安全问题的软件项目
,
要求立即操作实体执行一个预
先确定的行动为来减小或控制
事故或者危险。软件例外
,
失败
,
错误
,
或延迟将允许
,
或未能防止事故发生。
（这个定
义假设安全临界的显示信息可能是时间特别紧张的
,
但可用时间
不得超过充分控制实体响应和风险控制所需的时
间。
）
·通过重要度安全硬件系统、子系统或组件来发布命令的软件
功能
,
需要控制实体来完成该命令功能。
该系统检测和反应功能
包括冗余和为每个已定义的危险状况准备的独立
的容错机制。
（这个定义假设有足够能力进行故障检测
,
报警
,
容错
,
和系统
恢复以防止如果软件失效、失灵或退
化时发生危险。有备用的
安全重要度信息和减损功能的可以在任何时间紧张的时间响
应。
）
·软件生
成信息的安全性至关重要的自然用来做重要决定。该
系统包括几个冗余的、独立的容错机
制对于每个危险条件、检
测和显示。
·
软件生成一个与安全相关种类的信息来让运营商做决定
,
但不
需要操作者做出行动来避免事故。
2
半自主的
3
冗余容错的
4
5
有影响的
·软件的功能要求不处理命令或控制安全问题硬件系统、子系
不影响安全的
统或组件的度和不提供安全重要度问题。软件并不提供需要控
制实体相互作用的安全重要度或时间敏感数据或信息。软件不
转移或解决与通
信的安全问题或对时间敏感的数据的交流。
4.4.2
软件安全临界矩阵（
SSCM
）
。
SSCM
对于列（表<
/p>
5
）使用表
1
的
严重性
类别，对于行使用的是表
4
的软
件控制类别。矩阵的行和列相互参照的块在表
5
中分配为
SwCI
。
尽管它在外观上相似于风险评估矩
阵
（表
3
）
，
SSCM
不是风险的
评估。与每个
SwCI
相关的
LOR
任务是最小的任务集合，这个任务是为系统风险
等级而需求的评估软件贡献。
表
5.
软件安全临界矩阵
SwCI
SwCI 1
SwCI 2
SwCI 3
SwCI 4
SwCI 5
注释：
对于附加的关于如何进行所需的软件分析引导，
请查询联合软件系统安全工程手册和
AOP52
。<
/p>
精确任务的级别
程序应当执行需求、
体系结构、
设计和代码的分析；
并进行
深入的安全特定测试。
程序应当执行需求、体系结构和设计的
分析；并进行深入的安全特定测试。
程序应当执行需求和体系
结构的分析；并进行深入的安全特定测试。
程序应当进行安全特定测试。
一旦由
安全工程评估为不安全的话，就不需要安全特定分析或者检查。
4.4.3
风险评估软件的贡献。
所有系统风险评估软件的贡
献，
包括表
5
中应用
< br>的任何结果，在高温超导中（
HTS
）都应当记录。
a.
为了评估系统风险水平软件的贡献，
表
5
中的
LOR
（精确的水平）任务应
当被执行。
LOR
任务的结果在软件重要的软件安全方面提供了一定程度的可信程
度，并且记录了可能
需要减少的相关因素和危险。在风险管理过程中应该包括
LOR
任务的结果。
附录
B
提供了一个如何把
一个风险等级分配到由完成
LOR
分析
得到的系统风险软件贡献。
b.
如果
LOR
任务没有被执行的话，
通过表<
/p>
6
得到与未被指定或者为完成的
LOR<
/p>
任务相关的系统风险贡献应当被记录。
表
6
描述了
SwCI
，
< br>风险等级，
LOR
任务的
完成和
风险评估之间的关系。
c.
所有系
统风险评估软件的贡献，包括表
5
中应用的任何结果，在高温超
导中（
HTS
）都应当记录。按照
DoDI5000.02
执行风险的接受。
表
6
Sw
CI
，风险等级，
LOR
任务的完成和
风险评估之间的关系
SwCI
SwCI 1
风险等级
高
软件<
/p>
LOR
任务和风险评估
/
可接受性
如果
SwCI1
LOR
任务没有被指定或者没有完成，系统风险的贡献
将被记录
为
高
，并且为抉择提供
PM
。
PM
应该记录是否扩大资源
的决定，这些资源需要实现
SwCI1 LOR
任务或者为
高
风险的可接
受准备一个常规的风险评
估。
如果
SwCI2 LOR
任务没有被指定或者没有完成，系统风险的贡献
将被记录为
严重
，并且为抉择提供
PM
。
PM
应该记录是否扩大资
源的决定
，这些资源需要实现
SwCI2 LOR
任务或者为
严重
风险的
可接受准备一个常规的风险评估。
如果
SwCI3 LOR
任务没有被指定或者没有完成，系统风险的贡献
将被记录为
中等
，并且为抉择提供
PM
。
PM
应该记录是否扩大资
源的决定，这些资
源需要实现
SwCI2 LOR
任务或者为
中等
风险的
可接受准备一个常规的风险评估。
如果
SwCI4 LOR
任务没有被指定或者没有完成，系统风险的贡献
将被记录为
低<
/p>
，并且为抉择提供
PM
。
PM
应该记录是否扩大资源
的决定，这些资源需要实现
SwCI4 LOR
任务或者为
低
风险的可接
受准备一个常规的风险评估。
没有要求特别的安全分析或者测试
SwCI 2
严重
SwCI 3
中等
SwCI 4
低
SwCI 5
不安全
5.1
额外的信息。单个任务
,
附录
A,<
/p>
和附录
B
对于可选的特别的程序要求而<
/p>
包含了可选的信息。
5.2
任务。在这个标准中的任务可以有选择地应用到适合量身定制的系统安
全。
100
-
系列任务适用于管理。
200
-
系列任务适用于分析。
300
-
系列任务适
用于评估。
400
-
系列任务适用于验证。每个所需任务应当明确要求在一个合同
,
因为任务描述不包括任何其他任务的要求。
5.3
任务结构。每个任务分为三个部分的目的、任务描述
和指定细节。
a.
目表为执行的任务提供了解释理由。
b.
如果这个任务在合同中提到的话，这个任务描述了一个承
包商工作应当
履行。当准备提案时
,
承
包人可以推荐将额外的任务或删除指定任务的理由对于
支持每个添加
/
删除。
c.
细节必须在每个任务描述列出特定信息、添加、修改、删除或选项来要
求的任务
时应该考虑的要求一个任务。然后将此信息连同任务数包括在合同文
件。每个任务列表提
供不一定是完整的
,
可以补充。任何在需求中被选择的任务
都应该按照任务数量被实施为了
RFP
和<
/p>
ROW
。
带有标注
“
(R)
”
的指定细节是必需的。<
/p>
政府给正确的执行提供了这个任务的细节。
6.
注释
这节可能包括了一个通用或者可能有用的解释很自然的信息，
但
是不是强制
的。
6.1
预期用途。这个系统安全标准被打算作为一个关键的
SE
的部分使用，
SE
提供了一个标准的
,
泛型方法的识别、分类和危险减轻。它也不仅由安全专业人
员使用，
而且也被其他功能学科使用，
消防工程师、
职业卫生专业人员和环境工
程师。
6.2
获得要求。需求文档应当指定如下：
a.
标准的标题，数量，日期。
6.3
相关数据项说明（
DIDs
）
。
DIDs<
/p>
可能被应用到系统安全努力，包括：
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-
< br>管理
任务
101
基于系统安全方法论的风险识别和风险减轻
101.1
目的
.
< br>任务
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
< br>除非特定的定义或者是特定的矩阵与国防部的部件政策完全一致，否
则，表格一和
表格二中的定义，及表格三中的风险评价矩阵将被应用到。
1
01.2.8
作为一个最小量，报告如下准则：
a.
危险和相关风险
b.
功能，账目，和与危险相关的材料
c.
对于操作可接受的要求，维持，支持，和排列
d.
可接受的抑制方法
101.2.9
对于综合性的驱动事件，审查，支持，保证，分
析，释放和文件数据提
供正确定义和输出
101.3
列明的细节
.
计划的要
求和工作的提议应包括以下可应用到的准则
:
a.
任务
101
的税收
b.
应用于此任务的功能性准则识别
c.
事件进程的要求
d.
此任务的要求和方法论的报告
<
/p>
e.
对于实施危险识别和风险抑制工作的关键人员的资格要求
f.
其他的列明的危险识别和风险降低的
方法的要求，
例如，
列明的风险识别方法
和矩阵（如果它们与第四节提到的不同）将应用到这个项目
任务
102
系统安全程序计划
102.1
目的
.
任务
102<
/p>
是开发一个系统安全程序计划来证明对于识别，分类，和
安全风险
的减少的系统安全方法论是系统安全工程的一部分。
系统安全程序计划
< br>应是系统工程管理计划的不可分割的一部分。
系统安全程序计划详细描述了实施<
/p>
一个系统的方法进行危险分析，风险评价，和风险管理时所要求的任务和工作。
目标始终致力于消除可能出现的危险。
当一个危险不能够被消除时，
相关风险在
经费限制，日程，和系统安全优先设计应用的演算范围内降
到最低。
102.2
任务描述。承
包商应该开发一个系统安全程序计划来提供一个基本方法，
以便于承包商和项目经理理解
安全危险怎样结合到系统工程过程中。
系统安全程
序计划包括如
下准则：
102.2.1
范围
和目标
.
系统安全程序计划应该在最小量上描述一下：
(1)
就系统
和它的生命周期而言的工
作范围
,(2)
整个方法可以完成在第四节和其他合约地
要求的任务
,(3)
整合的这些工作为系统工
程和其他项目办公室管理的流程可以
来支持项目的总体目标
,<
/p>
和
(4)
执行
S
SPP
所需要的资源需求
(
资金、人才
、和工
具
)
。
本节将解释所有合同风险管理需求通过提供一个矩阵
,
这些合同
需求相关的
位置在系统安全程序计划处理中的应用。
102.2.2
系统安全程序计划接口
.
系统安全程序计划应该：
a.
SSPP
涵盖的识别功能规范。
b.
在以下二者间描述
SSPP
的接口
:
(1)
系统工程
(2)
其他相关学科
(
如：物流、
可维护性、质量保证、可靠性、人体工程学
,
可移
植性工程和医疗支持
(
健康危害评估
))
。
102.2.3
组织
.
SSPP
应当在最低标准描述以下
:
a.
SE
过程中的组织或功能的系统
安全。
使用图表显示组织和功能关系和行通信。
b
。
员工
(
人力加载和时间表
)
的系统安全的工作
,
每一个涉及到的功能性学科和组
织单元的合同期限。
SSPP
将确定参与执行系统安全要
求合同的每一个人和组织单位的责任和权力。
此外，
SSPP<
/p>
将确定关键人员，并提供关键系统安全人员的资格和证书的概要。
SSPP
将介绍在关键系统安全人员变动之前承包商应何时和怎样通知政府。
c.
程序的承包商将使用整合系统级和系统的系
统（
SOS
）级得出的危险管理结果
在
合同所涵盖的范围内。这些将包括：
（
1
）定义每个相关的承包商和分包商（供应商和供应商也适用）在总系统集合
安全要求中的角色。
（
2
）确定各个相关的承包商和分包商之间的安全协调工作（供应商和供应商也
适用），例如：整合风险分析。
（
3
）与相关的承包商和分包商（供应商和供应商也适用）的代表建立综合的
产
品团队（
IPTS
）或工作组（
WGs
）。
（<
/p>
4
）描述任何特定
SOS
整合的角色和责任。
（
5<
/p>
）硬件和软件的整合由政府提供的。
（
6
）为行动的组织和分包商分配要求。
（
7
）协调分包商系统安全工程的工作
。
（
8
）帮
助实施安全审查。
（
9
）
建议减损措施
;
评估可行
性、
成本和减损措施的效益和与其相关的承包商和
分包商的责任
分配落实情况。
（
10
）报告项目的安全状态和指标。
（
11
）为相关公司的承包商和分包商之间提供解决安全问题的章程。
d.
承包商在进行管理决策过程中需要将项目中
的危害与灾难和关键的严重性级
别，以及高危风险和严重风险及时通知政府；在事故，事
件，或发生故障的情况
下确定必要的措施；并且要求放弃安全要求和项目的偏差。
102.2.4
重大事件。
SSPP
，应当至少包括：
a.
提供系统安全活动的时间表，包括必要的输入和输出，并且提供支持
SE
过程
的开始和完成日期。
b
．建议将与系统安全活动相关的整合系统级活动（例如，设计分析，
测试和演
示），技术评审，方案审查，主要的项目事件列入汇总到综合表（
IMS
）。
c
．除了一些指定的其他工程研究和开发工作以外，需确定子系统、组件和软件
活动的日程表适用于系统安全活动
d
．包括相关承包商和分包商之间的技术会议讨论，审查和整合安全工作的时间
表。
102.2.5
一般安全要求和标准。
SSPP
应：
a.
列出含有安全要求的标准和系统规范，承包商应履行这些合同。包括标题，
日期
，段落编号和适用的部分。
b.
在
系统的设计和开发过程中，应对安全风险管理人员描述一般的工程要求和
设计标准。
c.
确定安全风险管理的要求，包括规章
，试验，运行及维护和报废。
d
．<
/p>
这种描述方法，
以确保减轻危险源的辨识和缓解相关的分包商
/
供应商要求的
作用。
102.2.6
危险分析。至少，
SSPP
应：
a
< br>．描述危险源辨识，风险评价，风险减损，风险沟通和风险可接受支持的过程。
（
1
）
危险源
辨识，
SSPP
描述了系统的识别过程，
在其整个生命周期内评估系统。
这种评估应该包括一个最小系统的硬件和软件，系统接
口（包括人机界面），预
使用或者应用程序和运行环境，及清理。
（
2
）风险评价，
SSPP
应列出的严重程度分类，可能性水平和应遵循的风险评价
规范（
RAC
）。表一和表二中给出
RACS
的定义，表三介绍
RACS
< br>的使用，除非根
据照国防部（
DOD
）的部分政策正式批准特定的替代定义和
/
或一个特定基体
。
（
3<
/p>
）风险减损，
SSPP
应说明如何决定将
不会超出整体
SE
审核。
SSPP
强调的目
标应该是尽可能的消除危险。当一个危险不能被消除时，在
SSPP
应讲述决定过
程中如何在有限
的资金、
进度和性能下，
通过应用第
4
节标准讲述的系统安全设
计优先级将相关风险降低到最低的可接
受水平。
SE
审核决定的减损经营将是涉
及技术学科贸易之间讨论的结果。
（
4
）对于可接受的风险的，
SSPP
描述的计划以设法解决政府的风险可接受，包
括决定通信的风险接受是必要的，
并且提供的风险评价文件的规程。
此外，
该计<
/p>
划应包括政府将如何把风险可接受的决策结果传达给承包商的程序。
根据国防部
指令（
DODI
）
5000.02
，在生命周期的多个时期政府可能不得不接受一个重大
的
风险。
b.
讲述将安全风险管理应用在商用现货（
COTS
），政府专用
现货（
GOTS
），非开
发项目（
NDI
），政府供应设备（
GFE
），政府供应资料（
GFI
）的方法。
c
．描述使用闭环程序中的跟踪和报告来确定
危险和相关风险，包括那些涉及
COTS
，
GOTS
，
NDI
，
GFE
，
GFI
。包括危
险跟踪系统（
HTS
）的详细说明。
d
．描述是否决定对于一个给定的危险进行恰当的定性或定量的
风险评价的过程
e
．危险识别分析（
例如，预先性危险分析
[PHA]
，子系统危险分析
[SSHA]
），
要使用的分析技术（例如，故
障树分析
[FTA]
，失效模式和严重性影响分析
[FMECA]
）和文档中的
HTS
结果。
f.
确定每个分析的
范围，
随着每一种分析技术深入到系统内使用和对整个系统的
危
险分析，整合相关承包商和分包商的危险分析
g.
当实施
SOS
的危险分析时，
计划应说明如何分析整合系统的设计，
操作，
和各
个相关承包商或分包商的产品和执行项目之间的联系。
相关承包商和分包
商
（供
应商和供应商也适用）所提供的数据或分析应该用于引导
工作的进行。
h
．描述的结果用来识
别和控制系统生命周期中与使用材料相关的危险。
i.
描述一个系统软件的系统安全性的方法：
(1)
识别和描述软件对系统危害的贡献。
（
2
）确定安全显着性（安全关
键性和安全相关性）的软件功能和软件要求。
（
3
）确定与软件组件安全重要性和安全相关项目的相关安全要求。
（
4
）每一个安全有效
的软件的功能（
SSSF
）及其相关要求确定和分配软件的临<
/p>
界指数（
SwCI
）
102.2.7
支持数据。最
小程度的系统安全工程计划应满足：
a.
< br>详细说明收集和处理相关危险，风险和经验教训数据的方法。这应包括危险
识别和
风险评估相关的协助，
既有历史数据相似或遗留系统和当前系统数据，
< br>例
如，危险追踪系统。
b
．识别所有文件或其他媒体，并将灾害管理数据的标题、合同编号、交付日期
合并，
并建议本合同项下拟交付给政府的运载工具
（硬
拷贝，
电子或实时访问）
，
包括不属于
无限权利政府的文件或其他媒体。
至少，
交付的资料应包括危险
跟踪
系统在合同执行和结束的数据。
102.2.8
核查和确认。至少，系统安全工程计划应证明系统安全风险管理工作会<
/p>
做到：
a
．通
过试验、分析、检验等手段在降低风险过程中审核、验证和文档有效的缓
解措施。
b
．
审核，
验证与硬件、
软件和进程相关的文件符合已
确定的危险性管理的要求。
c
．识别
认证，独立审查委员会的评估，以及特殊的测试要求。（例如，钝感弹
药的测试和安全或
紧急情况的处理程序）
d
．确保政府
在审核和验证信息过程中的程序。
102.2.9
审计过程。系统安全工程计划应该描述雇用的承包商的技术和进程，以
确保
本标准第
4
章中所描述的，系统的安全性过程中即将完成的要求
。
102.2.10
培训。系统安全工程计划应描述与系统安全进程有关的个人的意识培
训。
102.2.11
事故报告。
承包商应该描述在系统安全工程计划中包括政府的通知在内
的事故（包括偶然
事故和事故）预警、调查和报告流程。
102.3
指定细节。
请求建议书
（
RFP
）
和工作说明书
（
SOW
）
应包括以下内容
（
如
适用）
a.
征收任务
102
。
(R)
b.
要解决这个任务的功能学科（
S
）的鉴定。
(R)
c.
鉴定这项任务所涵盖的任何系统的系统要求，包括由政府提供的接口硬件和
软件。
(R)
d.
提交，审查和批准本计划的要求和方法。
(R)
e.
政府正式接受风险传达给承包商的程序。
f.
关键职能人员的资格要求。
g.
其他特定的安全风险管理的要求，例如，特定风险的定义
和在矩阵上使用这
个程序。
任务
103
危险管理计划
103.1
目标。任务
103
是为了开发一个能记载标准的危
险管理计划（
HMP
），这
个计划一般
是为了全部系统安全工程方法中一部分危险的识别、
分类和减少而进
行的系统安全方法论。这个危险管理计划应该是系统工程管理计划（
SEMP
）的
一个重要组成部分。
危险管理计划应描述
一个系统化的方法的任务和活动，
包括
危险分析、风险评价和风
险管理。如果可能，我们的目标应该是消除危险。当一
个风险没有被限制，与其相关的风
险应依据系统的安全性设计的优先次序中时
间、效能和成本的限制降低到可接受的最低水
平。
103.2
任务描述。承包商应
该制定一个基于承包商和项目经理（
PM
）之间的危险
管理计划，
这个计划是基于危险管理工作是如何被纳入到系统工程中的。
这个危
险管理计划应包括如下内容：
103.2.1
范围和目标。危险管理计划至少应描述：
(1)
依据系统和其生命周期范围
所做的努力
，
(2)
一般要求在第
4
节和其他合约规定的任务完成的总体思路，
<
/p>
(3)
为系统工程和其他项目办公室的管理流程整合这些努力，<
/p>
并且
(4)
所需资源
（资
金，人才和工具）执行危险管理计划。本节应统计
所有合同灾害管理的要求，并
提供一个矩阵，
说明每一个需求的
所解决这些合同要求是在的危险管理计划的什
么地方。
103.2.2
危险管理计划的接口。危险管理计划应该满足：
a.
一个确定的危险管理计划所涵盖的功能
学科。
b.
描述危险管理计划的接口
问题在下面几点之间的关系：
（
1<
/p>
）系统工程
（
2
）本标准第
4
章中所描述的功能使用
的系统安全性方法的学科（例如：系统
安全、安全范围、消防工程、环境工程、爆破安全
、化学和生物安全、定向能、
激光和无线电频率安全、软件系统安全工业卫生、职业健康
、人力系统集成
（
HSI
））
（
3
）其他涉及的学
科
(
例如，物流、维修性、质量控制、可靠性、软件开发、系<
/p>
统集成、测试等等
)
。
< br>
103.2.3
组织。危险
管理计划至少应描述：
a.
危险管理计划的成就在系统工程
过程中的的组织和运行。使用表格来展示组
织性的和运行性的联系及其联络线路。
b.
使这个订约
持续的每一个相关功能性纪律和组织单元的危险管理计划成就的
职工安置
（人力资源的接收和安排）
。
危险管理计划会识别每一
个与危险管理
计划要求的执行相关的人和组织单元的责任和权力。危险管理组织也会识别
关键人员并且提供一个他们认知资格和证书的概要。危险管理计划会描述如
何以及什么时候承包商应该优先通知政府关键人物的变换。
c.
这个承包商将要使用的程序会使
得系统水平完整和体系水平危险管理成就达
到被这个合约所概括的程度。这些会包括：<
/p>
（
1
）
明确每一个承包商和分包商（以及合适的供应商和买主）的角色来使
得这个整个系统的危险管理计划完整。
（
2
）
明确每一个相关的承包商和分包商（以及供应商合适的和买主）之间
的危险管理计划的接口，例如，完整危险分析。
（
3
）
和来自的承包商和分包商（以及合适的供应商和买主）的代表建立完
整的生产团队和研发团队。
（
4
）
描述任何细节性的体系的整合角色和责任。
（
5
）
完善政府提供的硬件和软件。
（
6
）
评估对行动组织和分包商的要求。
（
7
）
等同化分包商的危险管理计划工程成就。
（
8
）
推荐减轻方法；评估可行性，费用，和方法的效用；还有分配相关承
包商和分包商的实施责任。
（
9
）
汇报危险管理地位和度量。
（
10
）
描寻址述相关承包商和分包商之间的危险管理观点的过程。
<
/p>
d
．这个通过承包商管理决定的过程会被弄成包括及时通知政府高
度严重危
险；决策灾祸，事故，或者故障事件中的必要行为；和对于危险管理要求的
免除以及程序偏差的要求。
103.2.4
< br>重要事件。危险管理计划本应在最小的情况下：
a
．提供一个危险管理活动的计划包括要求的投入和产出，和开始以及结束
时间来支撑系统工程的过程。
b.
通过推荐他们包括在整体主要计划中的部分将危险管理活动联系到整个的
系统水平活动
当中（例如设计分析，测试，和证明）
，技术综述，程序综述，
和主要程序重要事件。
c.
识别子系
统计划，成分和适用于风险管理活动但是在其他工程研究和发展
成就中细分的软件活动。
d.
包括一个在相关的承包商和分包
商之间的技术会议的计划，
来讨论，
综述，
和使整个安全工作完整。
103.2.5
一般危险管理计划要求和标准。危险管理计划本应：
a.
列出标准和系统规格包括承包商在在合同中将要执行的危险管理要求。包
括标题，日期，和哪里适用，段落号。
b.
描述危险管理在系统设计和发展阶段的整体工程要求和设计标准。
c.
识别危险管理要求，来包括过程，用于测试，操作，支撑和
处理。
d.
描述保证危险鉴别下降和
减弱功能以及和分包商和供应者相联系的要求的
方法。
103.2.6
危险分析。危险管理计划本应在最小的情况下：
a.
描述危险识别，风险评价
,
风险减小，风险之间联系，和支持风险接受。
<
/p>
（
1
）对于危险识别，危险管理计划会描
述评价系统全寿命周期的系统识别
过程。
这个评价至少应该包括
系统硬件和软件，
系统接口
（来包括人的接口）
，
有意的使用或者应用和使用环境，和处理。
（
2
）对于风险评价，危险管理计划会列出其
严重类别，可能性水平，和应
该被遵守的风险管理规范。
在表格
Ⅰ和表格Ⅱ中的定义和在表格Ⅲ中的风险
评价规范会被用到，除非是专用选择性的定义和
/
或专用矩阵被正式认可和
国防部内容
政策相一致。
（
3
）风险
降低，危险管理计划会描述决定在整个系统工程中是怎样中作出
的。危险管理计划会强调
目标应该一直是尽可能的降低危险。当一个危险不
能被降低时，
危险管理计划应该描述在这个标准第
4
部分描述的花费，
计划，
和应用系统安全优先次序的表现这些约束条件下决定如何将相关
联的风险
降低到最低可接受水平的过程。
系统工程过程关于应该
继续哪个减轻应该是
权衡相关技术约束的讨论的结果。
（
4
）对于风险接受，危险管理计划应该描述
定度政府可接受风险以包括联
系政府程序的计划政府可接受风险决定和提供风险评价文件
的程序的计划。
除此之外，
这个计划应该包括政府提供的政府如
何联系承包商关于建议可接
受风险的决定的程序。
为了和国防部
5000.2
保持一致，
政府可能不得
不接受
再全寿命周期的很多点事件风险。
b.
描述将安全风险管理应用到商用货架商品，政府现货，非发展性项目，政
府供应设备和政府供应信息的使用当中的方法途径。
c.
描述跟踪报告识别的危险和相关风险的闭环程序，包括哪些包括了商用货<
/p>
架商品，政府现货，非发展性项目，政府供应设备和政府供应信息的程序。
包括一个详细的危险跟踪系统的描述。
d.
描述一个过程对于外界危险决定一个定性的或者定量的风险评价是否合
适
。
e.
识别即将被被操作的危险分析
（比如初步危险分析）
，
子系统危险分
析，
应
用分析技术（比如事故树分析，故障类型和影响危险度分
析）和在危险跟踪
系统中的结果证明文件。
< br>f.
识别每一个分析的范围，综合相关承包商和分包商危险分析和整个系统危
险分析，以及每个分析技术在系统内会用到的深度（比如系统水平，分系统
< br>水平，组件水平）
。
g.
当执行体系危险分析时，
这个计划应该描述如何分析整个系统设计，
运行，
每个相关的承包商和分包商的产品间的接口，结束项目的
执行。相关承包商
和分包商
（供应商和卖主）
< br>提供的提供的数据或分析会被用来知道这项工作。
h.
描述
为了识别、
控制在系统全寿命周期过程中使用的设备所带来的风险而
做出的努力。
i.
描述一个系统
的软件系统安全方法来：
（
1
）识别并描述系统危险的软件贡献。
（
2
）
识别安全重要性
（安全关键性和安全相关性）
的软件功能和软件需求
.
（
3
）识别与安全重要性软件部件和安全问
题项目有关的安全需求。
（
4
）
为每一个安全重要性软件和其相关的需求识别并确定软件的临界指数
。
103.2.7
支持数据。在一个
最低的限度下，危险管理方案应该：
a.
描述收集和处理有关的危险、
事故和经验数据的方法。
这应
该同时包括从
类似的或遗留系统使用的来帮助危险识别和相关的风险评估中得到的历史数
据
,
和当前的系统数据，例如，危险追踪系统。
b.
通过标题、
协议号、<
/p>
投递日期和再这个协议下计划投递到政府所提出的投
递方式
（硬拷贝、
电子或实时访问）
来识别与危险管
理数据有关的所有的文件或
其他媒介，
包括政府的除了无限制的
权利以外的文件或其他媒介。
在一个最低的
限度下，投递数据应
该包括在协议执行中和结束时所提供的危险追踪系统的数
据。
103.2.8
验证和确认。在一个最低的限度下，危险管理方
案应该证明危险管
理活动将如何：
a
.
验证、
确认并证明在通过测试、
分析
、
检验等来减少风险的过程中使用的
缓解措施的有效性。
b.
验证、确认并证明硬件、软件和程序遵
从已经识别出的危险管理需求。
c.
识别证明需求、
独立的修订委员会评估和特殊测试
（例如，
不敏感的军火
测试，火炮的电磁辐射危险，静电放电，和安全化
/
突发事件处理程序）。
d.
确保这些程序恰当地向政府传递验证和确认的信息。
103.2.9
审计程序。
危险管理方案应该描述承包商为确保系统安全程序的需
求所运用该的技术
和方法，正如本标准中第
4
章所描述的，已经被实现。
103.2.10
教育。危险管理方案应该描
述在危险管理方案程序中与危险管理
有关的全体员工的思想教育。
103.2.11
事件报告。承包商应该描述在危险管理方
案中事件（特别是事故
和故障）警报、调查和报告程序，包括政府的报告。
103.3
指定的细节。如果适用的话，提案要求
和工作说明应该包括下面的内
容：
a
.
任务
103
的强制性。（
R
）
b.
这个任务中提出的功能规则的确定。（
R
）
c.
这个任务中涉及到的任何一个求救需求的
确定，
包括政府提供的接口连接
硬件和软件。（
R
）
d.
< br>这个计划的建议、复审和批准的需求和方法论。（
R
）<
/p>
e.
承包商交流正式的政府的风险可接
受程度的程序。
f.
关键功能员工的资质要求。
g.
其他特定的风险管理需求
,
例如
,
特定风险的定义和这个程序中使用的矩
阵。
104.1
任务
104
支持政府执行的或者为了政府而采取的检查、认证
、委员会
和审计。
104.2
任务描述。承包商应该：
104.2.1
支持但不限于政府检查、审计和委员会，例如，
程序和技术检查，
军需品安全委员会，激光安全委员会，核安全委员会，任务预备检查，
飞行预备
检查，
测试预备检查，
发射预
备检查，
飞行安全检查委员会和国家环境政策法文
件的公众听证
会。
104.2.2
为事故调查提供
技术支持。
104.3
指定的细节。
如果适用的话，提案要求和工作说明应该包括下面的内
容：
<
/p>
a.
任务
104
的强制性。（
R
）
b.
这个任务中提出的功能规则的确
定。（
R
）
c.
支持的检查、
审计和委员会的频率、
持续时间和可能的位置，
以及任何一
个指令。（
R
）
d.
其他特定的风险管理需求
,
例如
,
特定风险的定义和这个程序中使用的矩
阵。
任务
105
集成产品开发团队
/
工作组支持
105.1
目的：任务
105
指定政府项目综合产品小组（
IPTS
）或工
作组（
WGs
）提
供支持。
105.2
任务描述：
承包商应作为一员参与指定综合产品小组或工作组。
这样的参
与应包括
,
但不限于
,
以下活动
:
a
：总结危害分析和与减少风险相关的状态
b
：发现与风险缓解措施相关的问题。
c
：努力使缓解措施的有效性和相应风险的减少保持一致。
d
：呈现事件（特别是系统的事故和故障
被发现）的评估结果，包括建议和采取
的行动，以防止再次发生。
e:
由指定的综合产品小组或工作组应对行动项目的分配。
f
：审查和验证降低风险的要求，标准和适用于系统的约束条件。
g
：规划和协调对所需的审查和认证程序
的支持。
h
：
要求选定的分包商
,
副承包商、
供应
商或厂商参与指定综合产品小组或工作组。
105.3 <
/p>
指定细节：要求建议书（
RFP
）和工作
说明书（
SOW
）应包括以下内容
(<
/p>
如
适用
)
：
a
：任务
105
的实施（
R
）
b
：通过这个任务解决了功能学科的识别（
R
）
c
：指定的综合项目组和工作组，由承包商来支持（
R
）
d
：把承包人会员资格要求和角色分配列入指
定的议程和会议记录的编制和分发
中。（
R
）
e
：综合产品小组或工作组会
议的频率或总数和可能的位置（
R
）
任务
106
危险跟踪系统
106.1
：目的：任务
106
是建立和维护一个闭环的危险
跟踪系统（
HTS
）。
106.2
：任务描述：承包商应建立和维护危险跟踪系统，至少应包括以下
这些任
务：
a
：危险
b
：系统
c
：子系统（如适用）。
d
：适用范围（特定版本的硬件设计或软件版本）
e
：要求参考资料
f
：系统模型
g
：致病因素（如硬件，软件，人力，运行环境）
h
：影响
i
：事故
j
：初步风险评估模型
k
：目标风险评估模型
l
：事件风险评估模型
m
：缓解措施（识别和选择可追溯至特定版本的硬件设计或软件版本）
n
：危险状态
o
：核查和验证方法
p
：行动人员和组织要素
q
：
可接受风险的记录—可接受风险的权限
(
和用户赞同权限
,
即合适的
)
依据权力
和组织
,
可接受日期和签署可接受风险文档的位置
r
：风险管理日志
(
在系统的生命周期中进入和更改风险记录的任何部分
)
s<
/p>
：由政府指定的危险品（
HAZMAT
）
的数据成分
106.2.1
政府应用适当的控制数据管理来接触到危险跟踪系统
106.2.2
任务
108(
危险品管理计划
)
、任务
204(
子系统危害分析
)
、任务
205(
系
统风险分析
)
、任务
206(
操作和支持
危害分析
)
、任务
207(
健康危害分析
),
和任
务
210(
环境危害分析
)
对于风险跟踪系统可能包括额外的需求
106.3
指定细节：要求建议书（
RFP
）和工作说明书（
SOW
）应包
括以下内容
(
如
适用
< br>)
：
a
：任务
106
的实施（
R
）
b
：通过这个任务解
决了功能学科的识别（
R
）
c
：政府有访问所有的灾害管理数据的危险跟踪系统和数据的权利（
R
）
d
：正式的政府传达了可接受的风险的程序给承包商（
R
< br>）
e
：任何特殊的数据元素<
/p>
,
格式
,
或数据
的报告要求（
R
）
f:
目前规划系统的生命周期去让危险品的使用或产生的投影
（如适用）（
R
）
g:
危险品管理异常
,
豁免
,
或临界值
(
如适用
)
（
R
）
h:
额外的有害物质的数据元素和报告的要求（
R
）
i:
其他特定风险管理需求
,
例如
,
特定风险的定义和矩阵上使用这个程序（
R
）
任务章节
200-
< br>分析
任务
201
初步危险列表
201.1
目的。任务
201
是编制出一个在发展初期的潜
在危险列表。
201.2
任务描述。承包者应该：
201.2.1
在军备解决方案分析开始时立刻检测系统，<
/p>
编制一个初步危险列表，
可以识别概念中固有的潜在的危险。
201.2.2
检测过去相似的文件和遗留系统，包含但是却不限制与：
A.
灾难和事故报告
B.
危险跟踪系统
C.
经验学习
D.
安全分析和评估
E.
健康危害信息
F.
试验文件
G.
对于系统测试、训练、防护
/
基
础以及维护（有组织的，持久的）
，可能地
点的环境问题。
H.
与国际环境政策法、总统令
12114
、环境影响国外的主要联邦行动相关联
的文件
I.
废除武装和清理计划
201.2.3
承包者应当用文件证明在危险跟踪系统中被识
别的危险。内容与格
式要按照承包者和机构的约定。除非另外的规定
201.3.d
，内容最少应当包括：
A.
危险简明的描述
B.
每个识别的危险因果关系因素
201.3
资料详细说明。
提案申请
和工作说明书应该包含下面的内容，
作为适用的：
A.
任务
201
的强制性
B.
解决这个任务的功能性学科的鉴定
C.
对获得政府文件的指导
D.
初步危险列表的内容与格式要求
E.
作业观念
F.
在这个大纲中使用到的其他特定的风险管理要求，等，特殊的风险定义和
模型
G.
风险定义的参考文献和来源
任务
202
预先危险分析
202.1
目的。任务
202
是通过执行或证明一个预先危
险分析来识别危险，评估最
初的风险和识别潜在的减轻措施。
202.2
任务描述。负责人应执行或证明一个预先危险分析，
去决定已识别危险的
最初风险评估。
与被推荐的设计和功能相联
系的危险，
应该评价其严重程度和发
生几率，
< br>基于最合理的数据。
包括来自同一系统、
遗产系统或其他
经验学习得来
的事故数据（同样的可访问性）
。根据规定条款、
替代选择和减轻措施来消除危
险或减轻。相关的风险应该被包括。
202.2.1
负责人应该用危险跟踪系统来证明预先危险
分析的结果。
202.2.2
预先危
险分析应识别危险通过考虑通过潜在的导致系统或子系统事故由
以下：
< br>
a
．系统组件
b
．能量来源
c
．军械
d
．危险原材料
e
．接口与控制
f
．当在一个网络或
sos
中，与
其他系统的接口的考虑
g
．材料兼容性
h
．不注意的激活
< br>i
．商务现货供应，政府现货供应，非研产品，政府提供的设备
< br>
j
．软件。包括由其他负责人或资源发展的软件，设计
标准应控制安全有效的软
件指令和响应能被识别。
（例如，疏忽
的指令，失败的指令，不合时的指令或响
应，还有不恰当的量级）而恰当的动作应被采用
，包含在软件说明书中（且与硬
件相关）
。
K
．操作环境和约束
1
、操作，测试，维护，测试中构建，诊断，紧急事件，爆炸火灾安
全实施和突
发事件处理的步骤。
m
．模型
n
．健康危害
o
．环境影响
p
．根据操作者功能，任务和需求对人为因素和人的错误进行分析
q.
生命维持和安全的需求与操作系统相关联，包括睡眠
，外出，营救，援救和抢
救。
r
．事件的唯一风险
s
．建立基础设施，真正的财产安装设备，和支撑设备。
t
．
sos
，系统，子系统，组件或软件故障。
202.2.3
对于每一个被识别的风险，预先危险分析应包括最初的风险评估，定义
在表Ⅰ和表Ⅱ中，
在表Ⅲ中的
RAC
风
险评价矩阵也应被使用，
除非对可选择定义
或正常选择模型做一
个调整使其与国防部的政策相一致。
202.2.4
对于每一个可识别的危险，预先危险分析应识别潜在的减轻措施，使用
在
4.3.4
中规定的，系统安全优先次序设计方法。
202.3
设计的详述，提案申请和工作说明书
应包括如下，如适用：
a
．任务
202
的强化
b
．通过功能训练的识别来处理这个任务
c
．特别的数据元素，格式或数据报告需要（考虑任务
106
危险追踪系统）
d
< br>．危险，危险区域的识别，或其他去检查或排除的特殊条款
e
．能使负责人完成定义的任务的，来自于
COTS
，
GOTS
，
NDI
s,
和
GFE
的技术报
告
f
．操作的概念
g
．其他特殊风险管理需要，例如，在这个计划中使用的特殊风险定义和模型
任务
203
系统需求危险性分析
203.1
用途。任务
203
是用来执行和用文件证明一个系统需求危害分析
（
SRHA<
/p>
）
的文件。
以确定设计需求去消除危险或
者降低系统的相关风险，
并将这
些需求合并为适当的系统文件，
去评估系统是否符合这些需求。
SRHA
可以用于
所有生命周期阶段和模式。
< br>203.2
任务描述。承包商应执行和记录
SRHA
用于：
203
.2.1
通过适用的政策，法规，标准等，以及分析已经辨识清的危险来确
定系统的设计要求，以消除危险或降低相关风险。
a.
承包商应确定适用的要求，
通过审阅军事和行业标准和规范来；
类似的原
有系统的历史文档；国防部（
DoD
）要求（包括风险消减技
术要求）
；系统性能规
格；其他的系统设计要求和文件；适用的
联邦、军队、国家和地方的规范；以及
适用的行政命令（
EOS
）和国际协议。
< br>b.
承包商应推荐适当的系统设计要求，以消除危险或减少依照本标准第
4
节所确定的相关风险。
c.
承包商应为每个设计要求规定检
验和确认的方法，
以消除危险或降低相关
的风险。
203.2.2
依情况
将经过批准的设计需求纳入工程设计文件、硬件、软件和系
统测试计划中。随着设计的发
展，确保适用的设计要求指向系统和子系统规范、
初步的硬件配置项目开发规范、
软件需求规范、
接口需求规范和同等的文件。
依
情况，使用工程变更建议书将适用的设计需求合并入这些文件中。
203.2.3
评估系统的硬
件和相关软件的发展是否符合确定的需求。承包商应：
a.
确立需求在所有合约中都要求技术评审，包括设计评审（
如初步设计评
审（
PDR
）和关键设计
评审（
CDR
）
）和软件规格评审。承
包商应确立危险、减缓
措施、检验和确认的方法和建议。
b.
为符合要求的硬件和软件的检验和确认检查测试计划和结果。<
/p>
这包括对风
险减缓措施的有效性的验证和确认。
< br>
c.
确保危险减缓信息纳入
运营商，维护，用户，培训，物流，诊断和非军事
化和处置手册和计划中。
203.3
细节规定。
提案申请（
RFP
）和工作说明书（
S
OW
）应包括以下内容（如适
用）
：<
/p>
a.
强制
实行
203
任务
（
R
）
b.
通过此任务，确立功能学科设计
需求的辨识。
（
R
）
< br>
c.
承包商努力维持的水
平所需的设计、技术和其他项目评审。
（
R
）
d.
修改
203.2.2
和
203.2
.3
以适当地反映与承包商负责设计的合同关系。
（
R
）
e.
经营理念。
f.
其他具体风险管理的要求，例如，特定风险的定义和这个
程序使用的矩
阵。
-
-
-
-
-
-
-
-
-
上一篇：MIL-STD-882E简介
下一篇：MIL-A-8625F 阳极氧化 中文版