系统安全军用标准MIL-STD-882E(中文全文).doc

前言1. 此标准被批准应用于国防部所有的军事部门和国防机构.2. 此系统安全标准是系统工程的关键要素，它为识别、分析和减轻危险提供了一个标准和通用方法。3. 国防部承诺保护个人免受意外的死亡、伤害、职业病以及在执行国防要求的任务时，保护防御系统、基础设施和财产免受意外的毁坏或破坏。在任务要求里，国防部也会确保把环境保护到最大可能的程，整个这些努力就是使用系统安全方法来识别危险并处理与危险相关的风险.国防部的关键目标是扩大系统安全方法论的使用，来把风险管理融入到整个系统工程当中，而不是把危险看做是操作因素。它不仅可以被系统安全专家使用.还可以应用于其他功能学科,比如火灾保护工程师、职业健康专家和环境工程师来识别危险并通过系统工程减轻风险。此文件的目的不是在其他功能学科使用系统安全解决个人的危险管理问题，但是，所有使用此通用方法的功能学科都应该把工作协调为整个系统工程的一部分,因为一个学科减轻危险的措施可能会在其他学科产生危险.4. 此系统安全标准确定了国防部识别危险并评价和减轻相关风险的方法，这些危险和风险是在防御系统的开发、测试、生产、使用以及报废阶段遇到的。这个方法描述了要与国防部指令一致。国防部指令定义了风险的可接受水平。5. 本次修订包含了满足政府和工业要求的改变，恢复了任务说明书。这些任务可能在合同文件中规定。当本标准在要求或合同中需要的时候,如果没有特殊要求，只有第三章和第四章是强制的。3。2和整个第四章的定义描绘了任何国防部系统可接受的系统安全和最低的强制性定义和要求。本次修订把标准的执行与当前的国防部政策相结合，支持国防部的战略性计划和目标，调整了信息的组织安排,阐明了系统安全过程的基本要素，阐明了术语并定义了任务说明书来改善危险管理。本标准强化了其它功能学科与系统工程的结合，最终通过大纲改进危险管理实务的一致性。特殊的改变包括：a。 重新介绍了任务说明书:（1） 100-系列任务-管理（2） 200系列任务分析 ii （3） 300系列任务-评价(4） 400-系列任务确认b。 强调了可应用的技术要求的识别c. 包括附加的任务：（1） 危险物质管理计划（2） 功能危险分析（3） 系统之间危险分析（4） 环境危险分析d. 应用严重性描述损失价值的增加e. 增加了“消除”可能性水平f. 增加了软件系统工程技术和实务g。 更新了附录6. 对此文件的评论、建议或问题应该递交到美国空军装备司令部总部 iii 附录B(2) 与由软件引起并控制的系统危险相关的风险是可以接受的，基于证据（危险，起因以及降低风险的措施已经根据国防部顾客的要求得以识别,执行以及核实）.证据支持了这样一种结论，危险控制提供了必需的降低危险的水平并且合成的风险能够被适当的风险接受权威所接受。就这一点而言，软件与硬件和操作者没有什么不同。如果软件设计没有满足安全要求，那么就会导致与没有充分核实软件危险起因和控制相关联的风险.一般说来，风险评价是以定量和定性的判断和证据为基础的。表格BI显示这些原则是如何应用的，来提供一种与软件因素相关联的评价方法。 表格BI 软件危险因素的风险评价标准风险水平风险标准描述在正常或不正常的操作或测试期间出现软件执行或软件设计不足:高度的 能直接导致灾难性的或危急的事故，或者 使系统处于一种状态,这种状态下，没有独立的连锁装置能够排除潜 在的灾难性及危急事故的发生 严重的 能直接导致临界的或轻微的事故，或者 使系统处于一种状态，只有一个独立的连锁装置或人为活动来排除潜在的灾难性或危急危险的发生 中等的 影响临界的或轻微事故，将系统失效降低到单独的一点,或者, 使系统处于一种状态，有两个相互独立的连锁装置或人为活动来排除潜在的灾难性或危急性事故的发生低的 影响灾难性或危急性的事故，但是有三个相互独立的连锁装置或人为活动保留，或者 会有影响临界的或轻微事故的因果相关的因素，但是有两个相互独立的连锁装置或人为活动保留 没有被分类为高度的、严重的、或中等的安全风险等级的软件的安全关键功能退化 要求，如果执行了，就会对安全产生负面影响，然而代码是安全执行的e. 定义并执行与危险相关的风险评价过程对计划的成功是关键的,尤其是当系统和更加复杂的系统之间相结合。这些系统之间常常包含在不同的开发条件和安全计划下开发的系统，并且可能需要与其他服务（陆、海、空军)或国防部机构系统相接。这些其他的系统之间的利益相关者可能有他们自己的安全过程，用来决定与他们的系统相结合的系统的可接受性。 军用标准882E1、范围1。1范围:这个系统安全标准的实行确定了国防部系统工程的方法来消除危险，如果可能的话，或者使那些不能消除的危险的风险最小化。国防部指令里5000.02定义了风险可接受的优先性。这个标准覆盖了系统、产品、设备、基础设施（包括硬件和软件的）贯穿于整个设计、研发、实验、产品、使用和清理阶段的所有危险。当这个标准在一个说明或是合同里被要求但是又没有特定的任务被定义时，只有三、四部分是强制的。3。2里的定义和第四部分的全部描绘了 最小化强制性定义和要求对于任何国防部系统的一个可接受的系统安全努力。2、适用的文件2.1通用。在这部分文件列出的是标准的第三、四、五部分里规定的。这一章不包括本标准中其他章节引用的文件或是推荐的额外信息或是例子。然而每个努力都已经被做确保这一列表的完成。文件使用者应注意到他们一定会遇到在本标准第三、四、五章里引用的文件的规定要求。无论他们是否列出。2.2政府文件2.2.1说明书、标准和手册。下面的说明书、标准和手册在某种规定的范围内形成了文件的一部分。除非不被规定的，这些文件的问题都在合同里被引用。国际标准化协议AOP52 NATOAOP52.关于软件安全设计的指导和相关计算系统必需品的评估。（这个文件的副本在这个https:/assist.dla。mil/quicksearch/网站上可以获得或从标准化文件排序桌面获得。费城罗宾斯大街700号4D建筑里。PA 191115094）国防部手册没有指定者 软件系统安全工程接口手册(这个文件的副本在这个http：/www.system-safety.org/links/网站上可以获得）2。2.2其他的政府文件、图纸和出版物.下面这些其他政府文件、图纸和出版物形成了文件规定程度上的一部分.除了没有规定的。这些文件的问题就是在合同里引用的。国防部指令DoDI 5000。02- 防御获得系统的操作9DoDI 6055。07- 事故通告、调查、报道和记录保持（这个文件的副本在这个http：/www。system-safety。org/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 国际标准化组织 IVV 独立验证和检验 JCIDS 功能集合和开发系统的接口 LOR 精确水平 MANPRINT 人力资源和人事集合 MIL-HDBK 军用手册 MIL-STD 军用标准 MSDS 材料安全数据表 NATO 北大西洋公约组织 NAVMC 海军和海军陆战队 NDI 发展条款 NEPA 国家环境政策法NSI 不安全影响 NSN 国家物料编号 OSHA 操作和支持危险分析 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 软件临界指数TE 测试和评估TEMP 临时测试和评估总体规划TES 测试工程师测试和评估策略WDSSR 放弃或偏差系统安全报告WG 工作组3。2定义 在使用这个标准时，应强制使用。3。2。1可接受的风险。风险，适当的受理机关(定义在多迪5000.02）愿意接受没有额外的缓解。3.2。2采办计划.一个直接的，资助的努力,提供了一个新的,改进的,或继续物资,武器,或信息系统或服务能力以应对一个批准的需要。第3.2。3病原。一个或多个机制，触发了风险，可能导致事故。3。2。4条商用现货(COTS)。商业项目，不需要独特的政府修改或维护生命周期的产品来满足需求的采购代理。3 2 5承包商。一个实体在私人行业进入合同与政府提供的商品或服务。在这个标准,这个词也适用于政府运营的活动,开发或收购国防项目上执行工作.3.2。6环境影响。一个对环境不利变化引起的全部或部分的系统或其使用。3 2 7 ESOH。一个首字母缩略词,指的是结合学科，包括流程和方法解决的法律、法规、行政命令（EO),国防部政策、环境合规,和相关的危险的环境影响、系统安全(如。、平台、系统、体系、武器、爆炸物、软件、军械、作战系统)，职业安全与健康、危险物品管理,和污染防治。3 2 8事件风险。相关的风险和危害，因为它适用于指定的硬件/软件配置在一个事件。典型的活动包括发展测试/操作测试(DT / OT）、示威、部署、post菲尔丁测试。3 2 9防守。将系统为操作使用单位在田里或舰队。3 2 10固件。结合一个硬件设备和计算机指令或计算机数据驻留为只读软件硬件设备。这个软件不能轻易修改在程序的控制下.3211工作设备(GFE)。财产的占有或由政府直接获得，随后交付或其他可用的承包商使用。32.12工作信息（GFI).信息在拥有或由政府直接获得,随后交付或其他可用的承包商使用。政府提供的信息可能包括物品如教训类似的系统或其他数据,通常不会被可用的非政府机构。32。13政府从架子上(GOTS)。硬件或软件开发、生产,或属于一个政府机构,不需要独特的修改在生命周期的产品来满足需求的采购代理。32.14风险.一个真正的或潜在的条件,可能导致意外事件或一连串的事件（即事故)导致死亡、受伤、职业疾病，损害或损失的设备或财产,或对环境的破坏。32。15有害物质(有害)。任何项目或物质，由于它的化学、物理、毒理学、或生物性质,可能导致伤害人，设备，或环境。32。16人力系统集成(溪）。集成的和全面的分析、设计、评估的需求、概念和参考资料系统人力、人员、培训、安全、职业健康、适居性、人员生存能力，和人类工程学.32.17最初的风险.第一个评估潜在的风险识别出风险。初步建立了一个固定的基线风险的危害.32。18精确级别(特)。一个规范的深度和广度的软件分析和验证活动必要提供足够的自信程度，安全性至关重要的或安全软件功能将根据需要执行。32.19生命周期。系统的所有阶段的生活,包括设计、研究、开发、测试和评估、生产、部署（库存)、操作和支持,和处理。32.20事故。一个事件或一系列事件导致意外死亡、受伤、职业疾病,损害或损失的设备或财产,或对环境的破坏.对于本标准中,术语“灾祸”包括从计划事件对环境的不良影响.32。21缓解措施。行动需要消除危害或当一个危险不能消除,减少相关的风险,减少事故的严重性或降低导致事故的可能性会发生。32。22模式。一个指定的系统状态或状态(如。、维护、测试、运行、储存、运输和非军事化）。32。23货币损失。估算成本的总和为设备维修或更换,设备维修或更换,环境清洁、人身伤害或疾病、环境负债,应包括任何已知的罚款或罚金造成的事故预测.32。24非发展项目（NDI)。项目（硬件、软件、通讯/网络，等等),用于系统开发程序,但并不发达，作为该计划的一部分.NDIs包括但不限于，COTS，GOTS,GFE,再利用物品，或以前开发的项目提供程序“目前的”。32。25概率。一个表达式的事故发生的可能性的32.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 软件 使计算机能够执行计算或控制功能的相关计算机指令和计算机数据的结合.软件包括计算机程序、规程、规则以及任何相关的文档有关的计算机系统的操作。软件包括新的发展，复杂可编程逻辑器件(固件)，NDI,COTS，GOTS、重用、GFE,和政府开发的软件用于系统中。 3。2.38软件控制类别 在一个系统特性的背景下对软件功能自治的程度，指挥和控制权力和冗余容错的赋值.3.2。39 软件重用 在一个软件应用的发展程序中使用一种先前开发的软件模块或软件包3.2.40软件系统安全 将系统安全的原理应用于软件.3。2。41 系统 需要在规定的环境中得到指定的结果的硬件、软件、材料、设备、人员、数据的和指定功能的服务的组织 .3.2.42体系 一组或一系列相互依赖的系统相关联于提供一个给定的能力3.2.43系统安全 在系统整个生命周期的所有阶段，应用工程和管理原则、标准,和技术利用有限的操作效能和适用性、时间和成本来达到可接受的风险3.2.44系统安全工程 一个工程学科,运用专业知识和技能于应用科学和工程学科，标准和技术，以识别危险然后消除危险或当危险无法消除时减少相关风险。3。2。45系统安全管理 识别危险；评估和减轻相关风险;跟踪、控制、接受和记录在系统、子系统、设备和设施的设计、开发、测试、获取、使用和处理中遇到的风险的所有计划和行动3。2.46系统/子系统说明 对于给定的系统中系统等级的功能和性能需求,连接，适应需求，安全性和保密性需求,计算机资源的需求，设计约束（包括软件架构，数据标准和编程语言)，软件支持，优先级的需求，研制试验的需求。3。2。47系统工程 一个项目团队的总体过程，适用于从上述能力的有效运作和合适的系统过渡.系统工程涉及到的应用SE适应每个阶段的生命周期(）在整个收购过程的目的是要平衡的解决方案的整合机制，处理能力需求，设计考虑因素和制约因素。 SE还涉及技术，预算和进度的限制。 SE进程早期应用材料解决方案的分析和持续整个生命周期.3。2。48目标风险 预计风险水平的PM计划以实现符合设计的优先顺序实施缓解措施的在4。3。4中的描述3.249用户代表 对于保护事件，一个命令或代理,已被正式指定在联合功能集成和开发系统（JCIDS）过程中代表单个或多个用户的能力和采集过程。对于无保护事件,用户代表付命令或代理责任对暴露在风险中的人员，设备和环境.对于所有的事件，用户代表将有同等的水平相当于风险接受权威。4. 常规/一般要求 4。1常规。当本标准被要求在招标或合同，但不包括具体的任务,只有第3节和第4节的规定适用。 3.2和所有第4节中的定义是国防部系统任何一个可以接受的系统安全工作最低强制性规定和要求。4。2系统安全要求 第四节通过任何系统的整个生命周期定义了系统安全要求.如果运用得当，这些要求应使在系统开发和维持工程活动的危害和相关风险的识别和管理。本记录的目的不是使系统的安全人员负责风险管理在其他的功能学科。然而,所有的功能学科使用这个通用的方法应该协调每个部分的努力优化的整体的系统工程过程，因为一个学科的最优缓解措施可能对其他学科产生危险。4.3系统安全过程.系统安全过程包含8个元素。图1描述了过程的典型逻辑序列。然而，可能需要在各个步骤之间的迭代.4。3.1记录系统安全方法 项目管理人和订约人应该记录下系统安全方法,为了给作为系统工程进程中完整的一部分的风险管理，系统安全方法的最低要求包括：a.描述风险管理的影响和如何使得风险管理和系统工程进程，集成产品和过程开发进程，总的项目管理构造成为一体 .b. 描述和记录可适用于系统的规定和派生的需求。例子包括顿感弹药的需求，电磁换效应的需求，污染防治任务，设计需求,技术因素，职业病和社区噪音标准。一旦需求被定义，确定系统说明书的内容和可用的流程要求给转包商,承包商和供应商。c.定义如何使得与美国军标I5000。02一致的危险和相关风险被使用者的代表正式的接受和同意。d.文件编制一个闭环危险追踪系统危险。危险追踪系统将会包括,作为最低限度的以下数据元素：确认危险，相关事故,风险评估（最初的，目标,事件），定义风险缓解措施，选定缓解办法，危险状态，验证风险的降低,和风险的可接受度。政府和承包商有权使用危险追踪系统来适当的控制数据管理.政府应该接收和保留“政府的目标权利”，所有的数据记录在危险追踪系统和其他条款(即，研究，分析,测试数据，注释,类似的数据）4.3.2定义和记录危险。 危险通过系统性的分析过程被定义，这个过程包括系统硬件和软件，系统界面(包括人机界面），具体的使用或应用，操作环境。考虑和使用事故数据；相关的环境和职业;使用者的物理特性；使用者的知识，技术和能力;来自以往相似系统事故的经验和教训。危险识别过程应该考虑整个系统的生命周期和对于人的潜在影响，基础设施，防御系统，公众,和环境。危险识别应该被记录在危险追踪系统.4。3。3 评估和记录风险 事故严重程度的分类和所有系统模型的不同危险的潜在事故可能性等级被评估，用来定义表I，II。a 表一中给出了确定给定的危险在给定的时间点来确定正确的严重性分类的方法,定义了死亡或者伤害,环境影响，或者财产损失的潜在可能性.一个给定的危险可能会产生一个或者所有的影响。表一。严重性分类严重性分类种类严重性分类事故结果准则灾难性的1一种或者多种结果如下：死亡，终身残疾,不可逆的重大环境影响，1000万美金的财产损失。严重的2一种或者多种结果如下：永久性部分残疾，伤害或者导致住院人数超过3人的职业病，可你的重大环境影响，100万,1000万美金的财产损失。轻微的3一种或者多种结果如下:导致一天或者更多天的工作日损失的伤害或职业病，可恢复的轻微环境影响，10万，100万美金的财产损失.可忽略的4一种或者多种结果如下:导致轻微伤害或职业病，但不会导致损失工作日，最小的环境影响,10万美金的财产损失。b。表二中给出了确定给定危险在给定时间点适当的可能性等级，评估了事故发生的可能性。可能性等级F被用来记录不存在风险的地方的例子。没有大量的学说,培训，警报，警告，警示，或者个人防护设施可以达到事故可能性等级F.表二 可能性等级可能性等级种类等级具体内容系统频繁的A在寿命周期内可能发生连续发生很可能的B在寿命周期内发生多次将会发生若干次偶然的C在寿命周期内可能发生将会发生几次可能性极小的D在寿命周期内不易发生,但有可能性不易发生，但有理由可预期发生不太可能的E极不易发生，几乎认为不可能发生不易发生，但有可能发生没有可能性F不能发生，这个等级是用来当潜在的危险被定义和被排除时。不能发生，这个等级是用来当潜在的危险被定义和被排除时.(1)运用适当的和代表性的定量数据定义危险的频率和发生率，一般最好定量分析，不可能等级是一般被认为是低于一百万，附录A给出了一个定量可能性等级的例子。（2)缺少定量频率或数据率时,依赖于表二的定性分析是有必要的并且适合的。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.4A通过设计选择排除危险。理论上,通过设计的选择或者是移除危险的材料的选择，可以排除的危险.B通过修改设计减小风险。如果采取改变供选择的设计或者材料去排除危险是不可行的,那么考虑改变设计减小因危险引起潜在事故的严重性和/或者可能性。C包含工程特征或装置。如果通过设计选择减缓风险是不可行的，那么使用工程特征或装置，减少因危险引起潜在事故的严重性和可能性.D 提供报警装置。如果工程特征和装置是不可行的或者不能使因危险引起潜在事故的严重性和可能性足够低。那么使用包括探测和警报系统使人警觉到危险情况的存在或者是危险事件的发生。E包含指导标示、程序、训练和保护人的设备。这里供选择的设计、改变设计、工程特性和装置是不可行的和警报装置不能充分的减少因危险引起潜在事故的严重性和可能性。那么使用包含指导标示、程序、训练和保护人的设备。指导标示包括海报、标示、符号和其他可见的图形.程序和训练应该包括适当的警告和警示。程序可以描绘保护人的设备的使用.对于被赋值为灾难性危险或者是危险事故严重性分级、指导标示的使用、程序、训练、和保护人的设备用作唯一的减少风险的方法应该被避免。4.3.5减小风险。减轻措施被选择和执行去获得可接受水平。考虑和评估花费、可行性、候选减轻方法的效果作为系统工程的一部分和使生产机组加工完整。技术检查时提出当前存在的危险、他们相关危险性和严重性的评估及危险减轻工作的状况。4.3.6核实、确认及用文件证明风险的减小。通过合适的分析、测试、演示、或者检查，核实和确认所有已选减缓风险措施效果及执行情况。在危险跟踪系统中生成核实和确认文件。4。3.7可接受风险和文件。在暴露人、设备、或者是环境给以知相关系统危险前，在DODI5000。02.中,通过合适的权威机构定义的风险应该被接受。通过系统全寿命周期，支持正常可接受风险决定的系统配置和相关文件应该被提供给政府保留.除非根据国防部元件政策合适的可供选择的定义和/或者合适的矩阵将被认可，定义在表一和表二中，风险评估编码在表三中，标准在表四中的软件习惯于在可接受的时定义风险。通过系统的全寿命周期，典型的使用者应该是这个过程的一个部分和应该提供正常发生的所有严重的和高危险的可接受决定。在试验、来自事故报告的数据、使用者的反馈、相似系统的经验、或者是其他资源之后可能显现新的危险、或者演示，演示来自已知危险的风险是比起目前已经识别的风险更高或者更低。在这些情况里,依据DoDI5000。02，修正后的风险应该被接受.注:一个简单的系统经过全寿命周期，将需要大量的事故风险评估和接受.在危险跟踪系统里，每一个风险接受决定应该被制成文件。4.3。8管理全寿命周期的风险。在系统被测试后，通过系统全寿命周期,系统项目主管使用系统安全过程去识别风险和维护危险跟踪系统.这个系统周期考虑到了任何的改变。包括但不限制在接口、使用者、硬件和软件、事故数据、任务或剖面和系统安全数据。程序应该放在合适的位置，以确保风险管理者可以意识到这些改变.例如，通过部分配置的控制过程。项目主管和使用者协会应该保持有效的交流合作、识别、管理新的危险及修正危险。如果新的危险被发现或比起目前的评估，已知的危险决定了更高的风险水平.依据DoDI5000.02,新的或修正的风险需要被接受。此外，通过提供危险分析，国防部要求项目经理支持相关系统A级和B级（在国防部说明书6055.07被定义）的事故调查,这样的事故调查有助于事故及对材料风险减缓措施的规范，特别是对那些使人为差错减小的规范.4.4软件促成的系统风险。对于软件的风险评估和软件控制或者是软件加强系统不能单独的依赖风险的严重性和可能性.至多决定一个简单软件失效的可能性是困难的，也不能基于历史数据。软件一般有特殊的应用而和作为与硬件相关的可靠性参数不能被评估用相同的方法。因此，在软件所促成的系统风险的评估中其他方法应该被使用。这些方法应该考虑潜在风险的严重度及软件使用超过硬件的控制的程度.4.4。1软件评估.通过表六表四应该被使用，除非合适的供选择的矩阵依据国防部软件政策被承认.用在表四中(或者被承认的合适供选择的表）的软件控制分类定义软件控制程度。表五提供了软件安全危险性矩阵基于表一严重度的分类（或者是被承认的合适的严重性分类）和表四软件控制分类.软件分类严重性矩阵建立了软件严重性指标,这个指标被用于定义必要的LOR任务。表四提供了SwCI及LOR任务与如何不满足LOR需求而影响到软件促成的风险之间的关系。A如果遗留的元件功能被包括在子系统的环境中，所有的软件控制分类应该被从新评估.遗留功能应该被评估包括功能和物理接口两方面，这两个方面对潜在的影响或是参与到子系统顶级水平的事故和危险相关因素进行评估。b。系统安全和软件系统安全危险分析过程识别和减少了准确的软件编著者的危险和事故.预定义的LOR任务成功的执行增加了当减少软件编著者的数量到适合时，系统中存在的危险软件会按照软件经营要求的可信度。这两个过程是减少软件初始化时危险条件和事故传播道路可能性的必要条件.附录B提供了开发可接受的LOR任务的指导。表IV.软件控制目录软件控制目录水平名称描述1自主的软件功能练习自主控制的权威在潜在的安全问题硬件系统、子系统或组件不可能预先确定的安全检测和通过控制实体来干预阻止事故的发生或危害。(这个定义包括复杂的有多个子系统或互相平行的过程的、多界面的、在时间临界上的安全临界的系统/软件功能。）2半自主的软件功能进行控制潜在的安全度硬件系统、子系统或组件,允许预定的安全检测和干预由独立安全机制来减轻或控制事故或灾害。（这个定义包括了控制比较复杂的系统/软件功能,没有并行过程,或几个界面，但其他的安全系统/机制可以部分减少。系统和软件故障检测和通告通知需要所需的安全行动的控制实体.)显示信息安全问题的软件项目,要求立即操作实体执行一个预先确定的行动为来减小或控制事故或者危险。软件例外，失败,错误，或延迟将允许，或未能防止事故发生。（这个定义假设安全临界的显示信息可能是时间特别紧张的，但可用时间不得超过充分控制实体响应和风险控制所需的时间。)3冗余容错的通过重要度安全硬件系统、子系统或组件来发布命令的软件功能，需要控制实体来完成该命令功能。该系统检测和反应功能包括冗余和为每个已定义的危险状况准备的独立的容错机制。(这个定义假设有足够能力进行故障检测,报警,容错,和系统恢复以防止如果软件失效、失灵或退化时发生危险。有备用的安全重要度信息和减损功能的可以在任何时间紧张的时间响应。）软件生成信息的安全性至关重要的自然用来做重要决定。该系统包括几个冗余的、独立的容错机制对于每个危险条件、检测和显示。4有影响的软件生成一个与安全相关种类的信息来让运营商做决定，但不需要操作者做出行动来避免事故.5不影响安全的软件的功能要求不处理命令或控制安全问题硬件系统、子系统或组件的度和不提供安全重要度问题。软件并不提供需要控制实体相互作用的安全重要度或时间敏感数据或信息.软件不转移或解决与通信的安全问题或对时间敏感的数据的交流。4。4.2软件安全临界矩阵（SSCM）。SSCM对于列(表5）使用表1的严重性类别，对于行使用的是表4的软件控制类别。矩阵的行和列相互参照的块在表5中分配为SwCI.尽管它在外观上相似于风险评估矩阵（表3），SSCM不是风险的评估。与每个SwCI相关的LOR任务是最小的任务集合,这个任务是为系统风险等级而需求的评估软件贡献.表5。 软件安全临界矩阵SwCI精确任务的级别SwCI 1程序应当执行需求、体系结构、设计和代码的分析;并进行深入的安全特定测试。SwCI 2程序应当执行需求、体系结构和设计的分析；并进行深入的安全特定测试。SwCI 3程序应当执行需求和体系结构的分析；并进行深入的安全特定测试.SwCI 4程序应当进行安全特定测试。SwCI 5一旦由安全工程评估为不安全的话,就不需要安全特定分析或者检查.注释：对于附加的关于如何进行所需的软件分析引导，请查询联合软件系统安全工程手册和AOP52。4.4.3风险评估软件的贡献。所有系统风险评估软件的贡献,包括表5中应用的任何结果,在高温超导中(HTS）都应当记录.a.为了评估系统风险水平软件的贡献，表5中的LOR（精确的水平）任务应当被执行。LOR任务的结果在软件重要的软件安全方面提供了一定程度的可信程度，并且记录了可能需要减少的相关因素和危险。在风险管理过程中应该包括LOR任务的结果。附录B提供了一个如何把一个风险等级分配到由完成LOR分析得到的系统风险软件贡献。b.如果LOR任务没有被执行的话,通过表6得到与未被指定或者为完成的LOR任务相关的系统风险贡献应当被记录。表6描述了SwCI，风险等级,LOR任务的完成和风险评估之间的关系。c. 所有系统风险评估软件的贡献，包括表5中应用的任何结果，在高温超导中(HTS）都应当记录。按照DoDI5000.02执行风险的接受。表6SwCI，风险等级，LOR任务的完成和风险评估之间的关系SwCI风险等级软件LOR任务和风险评估/可接受性SwCI 1高如果SwCI1 LOR任务没有被指定或者没有完成，系统风险的贡献将被记录为高，并且为抉择提供PM。PM应该记录是否扩大资源的决定，这些资源需要实现SwCI1 LOR任务或者为高风险的可接受准备一个常规的风险评估。SwCI 2严重如果SwCI2 LOR任务没有被指定或者没有完成，系统风险的贡献将被记录为严重，并且为抉择提供PM。PM应该记录是否扩大资源的决定，这些资源需要实现SwCI2 L