系统安全军用标准MIL-STD-882E中文全文

./前言此标准被批准应用于国防部所有的军事部门和国防机构。此系统安全标准是系统工程的关键要素,它为识别、分析和减轻危险提供了一个标准和通用方法。国防部承诺保护个人免受意外的死亡、伤害、职业病以及在执行国防要求的任务时,保护防御系统、基础设施和财产免受意外的毁坏或破坏。在任务要求里,国防部也会确保把环境保护到最大可能的程,整个这些努力就是使用系统安全方法来识别危险并处理与危险相关的风险。国防部的关键目标是扩大系统安全方法论的使用,来把风险管理融入到整个系统工程当中,而不是把危险看做是操作因素。它不仅可以被系统安全专家使用.还可以应用于其他功能学科,比如火灾保护工程师、职业健康专家和环境工程师来识别危险并通过系统工程减轻风险。此文件的目的不是在其他功能学科使用系统安全解决个人的危险管理问题,但是,所有使用此通用方法的功能学科都应该把工作协调为整个系统工程的一部分,因为一个学科减轻危险的措施可能会在其他学科产生危险。此系统安全标准确定了国防部识别危险并评价和减轻相关风险的方法,这些危险和风险是在防御系统的开发、测试、生产、使用以及报废阶段遇到的。这个方法描述了要与国防部指令一致。国防部指令定义了风险的可接受水平。本次修订包含了满足政府和工业要求的改变,恢复了任务说明书。这些任务可能在合同文件中规定。当本标准在要求或合同中需要的时候,如果没有特殊要求,只有第三章和第四章是强制的。3.2和整个第四章的定义描绘了任何国防部系统可接受的系统安全最低的强制性定义和要求。本次修订把标准的执行与当前的国防部政策相结合,支持国防部的战略性计划和目标,调整了信息的组织安排,阐明了系统安全过程的基本要素,阐明了术语并定义了任务说明书来改善危险管理。本标准强化了其它功能学科与系统工程的结合,最终通过大纲改进危险管理实务的一致性。特殊的改变包括：a.重新介绍了任务说明书：〔1100-系列任务-管理〔2200-系列任务-分析ii〔3300-系列任务-评价〔4400-系列任务-确认b.强调了可应用的技术要求的识别c.包括附加的任务：危险物质管理计划功能危险分析系统之间危险分析环境危险分析d.应用严重性描述损失价值的增加e.增加了"消除"可能性水平f.增加了软件系统工程技术和实务g.更新了附录对此文件的评论、建议或问题应该递交到美国空军装备司令部总部iii附录B<2>与由软件引起并控制的系统危险相关的风险是可以接受的,基于证据〔危险,起因以及降低风险的措施已经根据国防部顾客的要求得以识别,执行以及核实。证据支持了这样一种结论,危险控制提供了必需的降低危险的水平并且合成的风险能够被适当的风险接受权威所接受。就这一点而言,软件与硬件和操作者没有什么不同。如果软件设计没有满足安全要求,那么就会导致与没有充分核实软件危险起因和控制相关联的风险。一般说来,风险评价是以定量和定性的判断和证据为基础的。表格B-I显示这些原则是如何应用的,来提供一种与软件因素相关联的评价方法。表格B-I软件危险因素的风险评价标准风险水平风险标准描述在正常或不正常的操作或测试期间出现软件执行或软件设计不足：高度的能直接导致灾难性的或危急的事故,或者使系统处于一种状态,这种状态下,没有独立的连锁装置能够排除潜在的灾难性及危急事故的发生严重的能直接导致临界的或轻微的事故,或者使系统处于一种状态,只有一个独立的连锁装置或人为活动来排除潜在的灾难性或危急危险的发生中等的影响临界的或轻微事故,将系统失效降低到单独的一点,或者,使系统处于一种状态,有两个相互独立的连锁装置或人为活动来排除潜在的灾难性或危急性事故的发生低的影响灾难性或危急性的事故,但是有三个相互独立的连锁装置或人为活动保留,或者会有影响临界的或轻微事故的因果相关的因素,但是有两个相互独立的连锁装置或人为活动保留没有被分类为高度的、严重的、或中等的安全风险等级的软件的安全关键功能退化要求,如果执行了,就会对安全产生负面影响,然而代码是安全执行的e.定义并执行与危险相关的风险评价过程对计划的成功是关键的,尤其是当系统和更加复杂的系统之间相结合。这些系统之间常常包含在不同的开发条件和安全计划下开发的系统,并且可能需要与其他服务〔陆、海、空军或国防部机构系统相接。这些其他的系统之间的利益相关者可能有他们自己的安全过程,用来决定与他们的系统相结合的系统的可接受性。军用标准882E1、范围1.1范围：这个系统安全标准的实行确定了国防部系统工程的方法来消除危险,如果可能的话,或者使那些不能消除的危险的风险最小化。国防部指令里5000.02定义了风险可接受的优先性。这个标准覆盖了系统、产品、设备、基础设施〔包括硬件和软件的贯穿于整个设计、研发、实验、产品、使用和清理阶段的所有危险。当这个标准在一个说明或是合同里被要求但是又没有特定的任务被定义时,只有三、四部分是强制的。3.2里的定义和第四部分的全部描绘了最小化强制性定义和要求对于任何国防部系统的一个可接受的系统安全努力。2、适用的文件2.1通用。在这部分文件列出的是标准的第三、四、五部分里规定的。这一章不包括本标准中其他章节引用的文件或是推荐的额外信息或是例子。然而每个努力都已经被做确保这一列表的完成。文件使用者应注意到他们一定会遇到在本标准第三、四、、五章里引用的文件的规定要求。无论他们是否列出。2.2政府文件2.2.1说明书、标准和手册。下面的说明书、标准和手册在某种规定的范围内形成了文件的一部分。除非不被规定的,这些文件的问题都在合同里被引用。国际标准化协议AOP52NATOAOP52.关于软件安全设计的指导和相关计算系统必需品的评估。〔这个文件的副本在这个网站上可以获得或从标准化文件排序桌面获得。费城罗宾斯大街700号4D建筑里。PA19111-5094国防部手册没有指定者软件系统安全工程接口手册〔这个文件的副本在这个/links/网站上可以获得2.2.2其他的政府文件、图纸和出版物。下面这些其他政府文件、图纸和出版物形成了文件规定程度上的一部分。除了没有规定的。这些文件的问题就是在合同里引用的。国防部指令DoDI5000.02-防御获得系统的操作9DoDI6055.07-事故通告、调查、报道和记录保持<这个文件的副本在这个/links/网站上可以获得>2.3优先命令在一个突发事件中在这个文件的文本和引用于此的参考文献中间,文件的文本是优先的。除了DoDI5000.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采办计划。一个直接的,资助的努力,提供了一个新的,改进的,或继续物资,武器,或信息系统或服务能力以应对一个批准的需要。第3.2.3病原。一个或多个机制,触发了风险,可能导致事故。3.2.4条商用现货<COTS>。商业项目,不需要独特的政府修改或维护生命周期的产品来满足需求的采购代理。325承包商。一个实体在私人行业进入合同与政府提供的商品或服务。在这个标准,这个词也适用于政府运营的活动,开发或收购国防项目上执行工作。3.2.6环境影响。一个对环境不利变化引起的全部或部分的系统或其使用。327ESOH。一个首字母缩略词,指的是结合学科,包括流程和方法解决的法律、法规、行政命令<EO>,国防部政策、环境合规,和相关的危险的环境影响、系统安全<如。、平台、系统、体系、武器、爆炸物、软件、军械、作战系统>,职业安全与健康、危险物品管理,和污染防治。328事件风险。相关的风险和危害,因为它适用于指定的硬件/软件配置在一个事件。典型的活动包括发展测试/操作测试<DT/OT>、示威、部署、post菲尔丁测试。329防守。将系统为操作使用单位在田里或舰队。3210固件。结合一个硬件设备和计算机指令或计算机数据驻留为只读软件硬件设备。这个软件不能轻易修改在程序的控制下。3211工作设备<GFE>。财产的占有或由政府直接获得,随后交付或其他可用的承包商使用。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>。项目<硬件、软件、通讯/网络,等等>,用于系统开发程序,但并不发达,作为该计划的一部分。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软件使计算机能够执行计算或控制功能的相关计算机指令和计算机数据的结合。软件包括计算机程序、规程、规则以及任何相关的文档有关的计算机系统的操作。软件包括新的发展,复杂可编程逻辑器件<固件>,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.2．49用户代表对于保护事件,一个命令或代理,已被正式指定在联合功能集成和开发系统<JCIDS>过程中代表单个或多个用户的能力和采集过程。对于无保护事件,用户代表付命令或代理责任对暴露在风险中的人员,设备和环境。对于所有的事件,用户代表将有同等的水平相当于风险接受权威。4.常规/一般要求4.1常规。当本标准被要求在招标或合同,但不包括具体的任务,只有第3节和第4节的规定适用。3.2和所有第4节中的定义是国防部系统任何一个可以接受的系统安全工作最低强制性规定和要求。4.2系统安全要求第四节通过任何系统的整个生命周期定义了系统安全要求。如果运用得当,这些要求应使在系统开发和维持工程活动的危害和相关风险的识别和管理。本记录的目的不是使系统的安全人员负责风险管理在其他的功能学科。然而,所有的功能学科使用这个通用的方法应该协调每个部分的努力优化的整体的系统工程过程,因为一个学科的最优缓解措施可能对其他学科产生危险。4.3系统安全过程。系统安全过程包含8个元素。图1描述了过程的典型逻辑序列。然而,可能需要在各个步骤之间的迭代。记录系统安全方法项目管理人和订约人应该记录下系统安全方法,为了给作为系统工程进程中完整的一部分的风险管理,系统安全方法的最低要求包括：a.描述风险管理的影响和如何使得风险管理和系统工程进程,集成产品和过程开发进程,总的项目管理构造成为一体。b.描述和记录可适用于系统的规定和派生的需求。例子包括顿感弹药的需求,电磁换效应的需求,污染防治任务,设计需求,技术因素,职业病和社区噪音标准。一旦需求被定义,确定系统说明书的内容和可用的流程要求给转包商,承包商和供应商。c.定义如何使得与美国军标I5000.02一致的危险和相关风险被使用者的代表正式的接受和同意。d.文件编制一个闭环危险追踪系统危险。危险追踪系统将会包括,作为最低限度的以下数据元素：确认危险,相关事故,风险评估〔最初的,目标,事件,定义风险缓解措施,选定缓解办法,危险状态,验证风险的降低,和风险的可接受度。政府和承包商有权使用危险追踪系统来适当的控制数据管理。政府应该接收和保留"政府的目标权利",所有的数据记录在危险追踪系统和其他条款〔即,研究,分析,测试数据,注释,类似的数据定义和记录危险。危险通过系统性的分析过程被定义,这个过程包括系统硬件和软件,系统界面〔包括人机界面,具体的使用或应用,操作环境。考虑和使用事故数据；相关的环境和职业；使用者的物理特性；使用者的知识,技术和能力；来自以往相似系统事故的经验和教训。危险识别过程应该考虑整个系统的生命周期和对于人的潜在影响,基础设施,防御系统,公众,和环境。危险识别应该被记录在危险追踪系统。4.3.3评估和记录风险事故严重程度的分类和所有系统模型的不同危险的潜在事故可能性等级被评估,用来定义表=1\*ROMANI,=2\*ROMANII。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定义和编辑风险缓解措施。潜在的风险缓解应该被定义,并且预期风险降低的选择应该被评估和记录在危险追踪系统。如果可能的话目标应该是消除危险。当一个风险不能被消除时,通过应用系统安全设计的优先次序,相关风险应该被降低到成本和性能的最低可接受水平。系统安全设计的优先次序给出了选择性抑制的方法和通过列表来降低影响。A通过设计选择排除危险。理论上,通过设计的选择或者是移除危险的材料的选择,可以排除的危险。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精确任务的级别SwCI1程序应当执行需求、体系结构、设计和代码的分析；并进行深入的安全特定测试。SwCI2程序应当执行需求、体系结构和设计的分析；并进行深入的安全特定测试。SwCI3程序应当执行需求和体系结构的分析；并进行深入的安全特定测试。SwCI4程序应当进行安全特定测试。SwCI5一旦由安全工程评估为不安全的话,就不需要安全特定分析或者检查。注释：对于附加的关于如何进行所需的软件分析引导,请查询联合软件系统安全工程手册和AOP52。风险评估软件的贡献。所有系统风险评估软件的贡献,包括表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任务和风险评估/可接受性SwCI1高如果SwCI1LOR任务没有被指定或者没有完成,系统风险的贡献将被记录为高,并且为抉择提供PM。PM应该记录是否扩大资源的决定,这些资源需要实现SwCI1LOR任务或者为高风险的可接受准备一个常规的风险评估。SwCI2严重如果SwCI2LOR任务没有被指定或者没有完成,系统风险的贡献将被记录为严重,并且为抉择提供PM。PM应该记录是否扩大资源的决定,这些资源需要实现SwCI2LOR任务或者为严重风险的可接受准备一个常规的风险评估。SwCI3中等如果SwCI3LOR任务没有被指定或者没有完成,系统风险的贡献将被记录为中等,并且为抉择提供PM。PM应该记录是否扩大资源的决定,这些资源需要实现SwCI2LOR任务或者为中等风险的可接受准备一个常规的风险评估。SwCI4低如果SwCI4LOR任务没有被指定或者没有完成,系统风险的贡献将被记录为低,并且为抉择提供PM。PM应该记录是否扩大资源的决定,这些资源需要实现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数据库应该在一下网址查看来保证只有当前和许可的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范围 和目标.系统安全程序计划应该在最小量上描述一下：<1>就系统和它的生命周期而言的工作范围,<2>整个方法可以完成在第四节和其他合约地要求的任务,<3>整合的这些工作为系统工程和其他项目办公室管理的流程可以来支持项目的总体目标,和<4>执行SSPP所需要的资源需求<资金、人才、和工具>。本节将解释所有合同风险管理需求通过提供一个矩阵,这些合同需求相关的位置在系统安全程序计划处理中的应用。系统安全程序计划接口.系统安全程序计划应该：a.SSPP涵盖的识别功能规范。b.在以下二者间描述SSPP的接口:<1>系统工程<2>其他相关学科<如：物流、可维护性、质量保证、可靠性、人体工程学,可移植性工程和医疗支持<健康危害评估>>。组织.SSPP应当在最低标准描述以下:a.SE过程中的组织或功能的系统安全。使用图表显示组织和功能关系和行通信。b。员工<人力加载和时间表>的系统安全的工作,每一个涉及到的功能性学科和组织单元的合同期限。SSPP将确定参与执行系统安全要求合同的每一个人和组织单位的责任和权力。此外,SSPP将确定关键人员,并提供关键系统安全人员的资格和证书的概要。SSPP将介绍在关键系统安全人员变动之前承包商应何时和怎样通知政府。c.程序的承包商将使用整合系统级和系统的系统〔SOS级得出的危险管理结果在合同所涵盖的范围内。这些将包括：〔1定义每个相关的承包商和分包商〔供应商和供应商也适用在总系统集合安全要求中的角色。〔2确定各个相关的承包商和分包商之间的安全协调工作〔供应商和供应商也适用,例如：整合风险分析。〔3与相关的承包商和分包商〔供应商和供应商也适用的代表建立综合的产品团队〔IPTS或工作组〔WGs。〔4描述任何特定SOS整合的角色和责任。〔5硬件和软件的整合由政府提供的。〔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．这种描述方法,以确保减轻危险源的辨识和缓解相关的分包商/供应商要求的作用。102.2.6危险分析。至少,SSPP应：a．描述危险源辨识,风险评价,风险减损,风险沟通和风险可接受支持的过程。〔1危险源辨识,SSPP描述了系统的识别过程,在其整个生命周期内评估系统。这种评估应该包括一个最小系统的硬件和软件,系统接口〔包括人机界面,预使用或者应用程序和运行环境,及清理。〔2风险评价,SSPP应列出的严重程度分类,可能性水平和应遵循的风险评价规范〔RAC。表一和表二中给出RACS的定义,表三介绍RACS的使用,除非根据照国防部〔DOD的部分政策正式批准特定的替代定义和/或一个特定基体。〔3风险减损,SSPP应说明如何决定将不会超出整体SE审核。SSPP强调的目标应该是尽可能的消除危险。当一个危险不能被消除时,在SSPP应讲述决定过程中如何在有限的资金、进度和性能下,通过应用第4节标准讲述的系统安全设计优先级将相关风险降低到最低的可接受水平。SE审核决定的减损经营将是涉及技术学科贸易之间讨论的结果。〔4对于可接受的风险的,SSPP描述的计划以设法解决政府的风险可接受,包括决定通信的风险接受是必要的,并且提供的风险评价文件的规程。此外,该计划应包括政府将如何把风险可接受的决策结果传达给承包商的程序。根据国防部指令〔DODI5000.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及其相关要求确定和分配软件的临界指数〔SwCI支持数据。最小程度的系统安全工程计划应满足：a.详细说明收集和处理相关危险,风险和经验教训数据的方法。这应包括危险识别和风险评估相关的协助,既有历史数据相似或遗留系统和当前系统数据,例如,危险追踪系统。b．识别所有文件或其他媒体,并将灾害管理数据的标题、合同编号、交付日期合并,并建议本合同项下拟交付给政府的运载工具〔硬拷贝,电子或实时访问,包括不属于无限权利政府的文件或其他媒体。至少,交付的资料应包括危险跟踪系统在合同执行和结束的数据。核查和确认。至少,系统安全工程计划应证明系统安全风险管理工作会做到：a．通过试验、分析、检验等手段在降低风险过程中审核、验证和文档有效的缓解措施。b．审核,验证与硬件、软件和进程相关的文件符合已确定的危险性管理的要求。c．识别认证,独立审查委员会的评估,以及特殊的测试要求。〔例如,钝感弹药的测试和安全或紧急情况的处理程序d．确保政府在审核和验证信息过程中的程序。102.2.9审计过程。系统安全工程计划应该描述雇用的承包商的技术和进程,以确保本标准第4章中所描述的,系统的安全性过程中即将完成的要求。培训。系统安全工程计划应描述与系统安全进程有关的个人的意识培训。事故报告。承包商应该描述在系统安全工程计划中包括政府的通知在内的事故〔包括偶然事故和事故预警、调查和报告流程。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节和其他合约规定的任务完成的总体思路,<3>为系统工程和其他项目办公室的管理流程整合这些努力,并且<4>所需资源〔资金,人才和工具执行危险管理计划。本节应统计所有合同灾害管理的要求,并提供一个矩阵,说明每一个需求的所解决这些合同要求是在的危险管理计划的什么地方。危险管理计划的接口。危险管理计划应该满足：a.一个确定的危险管理计划所涵盖的功能学科。b.描述危险管理计划的接口问题在下面几点之间的关系：〔1系统工程〔2本标准第4章中所描述的功能使用的系统安全性方法的学科〔例如：系统安全、安全范围、消防工程、环境工程、爆破安全、化学和生物安全、定向能、激光和无线电频率安全、软件系统安全工业卫生、职业健康、人力系统集成〔HSI〔3其他涉及的学科<例如,物流、维修性、质量控制、可靠性、软件开发、系统集成、测试等等>。103.2.3组织。危险管理计划至少应描述：危险管理计划的成就在系统工程过程中的的组织和运行。使用表格来展示组织性的和运行性的联系及其联络线路。使这个订约持续的每一个相关功能性纪律和组织单元的危险管理计划成就的职工安置〔人力资源的接收和安排。危险管理计划会识别每一个与危险管理计划要求的执行相关的人和组织单元的责任和权力。危险管理组织也会识别关键人员并且提供一个他们认知资格和证书的概要。危险管理计划会描述如何以及什么时候承包商应该优先通知政府关键人物的变换。这个承包商将要使用的程序会使得系统水平完整和体系水平危险管理成就达到被这个合约所概括的程度。这些会包括：明确每一个承包商和分包商〔以及合适的供应商和买主的角色来使得这个整个系统的危险管理计划完整。明确每一个相关的承包商和分包商〔以及供应商合适的和买主之间的危险管理计划的接口,例如,完整危险分析。和来自的承包商和分包商〔以及合适的供应商和买主的代表建立完整的生产团队和研发团队。描述任何细节性的体系的整合角色和责任。完善政府提供的硬件和软件。评估对行动组织和分包商的要求。等同化分包商的危险管理计划工程成就。推荐减轻方法；评估可行性,费用,和方法的效用；还有分配相关承包商和分包商的实施责任。汇报危险管理地位和度量。描寻址述相关承包商和分包商之间的危险管理观点的过程。d．这个通过承包商管理决定的过程会被弄成包括及时通知政府高度严重危险；决策灾祸,事故,或者故障事件中的必要行为；和对于危险管理要求的免除以及程序偏差的要求。103.2.4重要事件。危险管理计划本应在最小的情况下：a．提供一个危险管理活动的计划包括要求的投入和产出,和开始以及结束时间来支撑系统工程的过程。b.通过推荐他们包括在整体主要计划中的部分将危险管理活动联系到整个的系统水平活动当中〔例如设计分析,测试,和证明,技术综述,程序综述,和主要程序重要事件。c.识别子系统计划,成分和适用于风险管理活动但是在其他工程研究和发展成就中细分的软件活动。d.包括一个在相关的承包商和分包商之间的技术会议的计划,来讨论,综述,和使整个安全工作完整。103.2.5一般危险管理计划要求和标准。危险管理计划本应：a.列出标准和系统规格包括承包商在在合同中将要执行的危险管理要求。包括标题,日期,和哪里适用,段落号。b.描述危险管理在系统设计和发展阶段的整体工程要求和设计标准。c.识别危险管理要求,来包括过程,用于测试,操作,支撑和处理。d.描述保证危险鉴别下降和减弱功能以及和分包商和供应者相联系的要求的方法。103.2.6危险分析。危险管理计划本应在最小的情况下：a.描述危险识别,风险评价,风险减小,风险之间联系,和支持风险接受。〔1对于危险识别,危险管理计划会描述评价系统全寿命周期的系统识别过程。这个评价至少应该包括系统硬件和软件,系统接口〔来包括人的接口,有意的使用或者应用和使用环境,和处理。〔2对于风险评价,危险管理计划会列出其严重类别,可能性水平,和应该被遵守的风险管理规范。在表格Ⅰ和表格Ⅱ中的定义和在表格Ⅲ中的风险评价规范会被用到,除非是专用选择性的定义和/或专用矩阵被正式认可和国防部内容政策相一致。〔3风险降低,危险管理计划会描述决定在整个系统工程中是怎样中作出的。危险管理计划会强调目标应该一直是尽可能的降低危险。当一个危险不能被降低时,危险管理计划应该描述在这个标准第4部分描述的花费,计划,和应用系统安全优先次序的表现这些约束条件下决定如何将相关联的风险降低到最低可接受水平的过程。系统工程过程关于应该继续哪个减轻应该是权衡相关技术约束的讨论的结果。〔4对于风险接受,危险管理计划应该描述定度政府可接受风险以包括联系政府程序的计划政府可接受风险决定和提供风险评价文件的程序的计划。除此之外,这个计划应该包括政府提供的政府如何联系承包商关于建议可接受风险的决定的程序。为了和国防部5000.2保持一致,政府可能不得不接受再全寿命周期的很多点事件风险。b.描述将安全风险管理应用到商用货架商品,政府现货,非发展性项目,政府供应设备和政府供应信息的使用当中的方法途径。c.描述跟踪报告识别的危险和相关风险的闭环程序,包括哪些包括了商用货架商品,政府现货,非发展性项目,政府供应设备和政府供应信息的程序。包括一个详细的危险跟踪系统的描述。d.描述一个过程对于外界危险决定一个定性的或者定量的风险评价是否合适。e.识别即将被被操作的危险分析〔比如初步危险分析,子系统危险分析,应用分析技术〔比如事故树分析,故障类型和影响危险度分析和在危险跟踪系统中的结果证明文件。f.识别每一个分析的范围,综合相关承包商和分包商危险分析和整个系统危险分析,以及每个分析技术在系统内会用到的深度〔比如系统水平,分系统水平,组件水平。g.当执行体系危险分析时,这个计划应该描述如何分析整个系统设计,运行,每个相关的承包商和分包商的产品间的接口,结束项目的执行。相关承包商和分包商〔供应商和卖主提供的提供的数据或分析会被用来知道这项工作。h.描述为了识别、控制在系统全寿命周期过程中使用的设备所带来的风险而做出的努力。i.描述一个系统的软件系统安全方法来：〔1识别并描述系统危险的软件贡献。〔2识别安全重要性〔安全关键性和安全相关性的软件功能和软件需求.〔3识别与安全重要性软件部件和安全问题项目有关的安全需求。〔4为每一个安全重要性软件和其相关的需求识别并确定软件的临界指数。103.2.7支持数据。在一个最低的限度下,危险管理方案应该：a.描述收集和处理有关的危险、事故和经验数据的方法。这应该同时包括从类似的或遗留系统使用的来帮助危险识别和相关的风险评估中得到的历史数据,和当前的系统数据,例如,危险追踪系统。b.通过标题、协议号、投递日期和再这个协议下计划投递到政府所提出的投递方式〔硬拷贝、电子或实时访问来识别与危险管理数据有关的所有的文件或其他媒介,包括政府的除了无限制的权利以外的文件或其他媒介。在一个最低的限度下,投递数据应该包括在协议执行中和结束时所提供的危险追踪系统的数据。103.2.8验证和确认。在一个最低的限度下,危险管理方案应该证明危险管理活动将如何：a.验证、确认并证明在通过测试、分析、检验等来减少风险的过程中使用的缓解措施的有效性。b.验证、确认并证明硬件、软件和程序遵从已经识别出的危险管理需求。c.识别证明需求、独立的修订委员会评估和特殊测试〔例如,不敏感的军火测试,火炮的电磁辐射危险,静电放电,和安全化/突发事件处理程序。d.确保这些程序恰当地向政府传递验证和确认的信息。103.2.9审计程序。危险管理方案应该描述承包商为确保系统安全程序的需求所运用该的技术和方法,正如本标准中第4章所描述的,已经被实现。103.2.10教育。危险管理方案应该描述在危险管理方案程序中与危险管理有关的全体员工的思想教育。103.2.11事件报告。承包商应该描述在危险管理方案中事件〔特别是事故和故障警报、调查和报告程序,包括政府的报告。103.3指定的细节。如果适用的话,提案要求和工作说明应该包括下面的内容：a.任务103的强制性。〔Rb.这个任务中提出的功能规则的确定。〔Rc.这个任务中涉及到的任何一个求救需求的确定,包括政府提供的接口连接硬件和软件。〔Rd.这个计划的建议、复审和批准的需求和方法论。〔Re.承包商交流正式的政府的风险可接受程度的程序。f.关键功能员工的资质要求。g.其他特定的风险管理需求,例如,特定风险的定义和这个程序中使用的矩阵。104.1任务104支持政府执行的或者为了政府而采取的检查、认证、委员会和审计。104.2任务描述。承包商应该：104.2.1支持但不限于政府检查、审计和委员会,例如,程序和技术检查,军需品安全委员会,激光安全委员会,核安全委员会,任务预备检查,飞行预备检查,测试预备检查,发射预备检查,飞行安全检查委员会和国家环境政策法文件的公众听证会。104.2.2为事故调查提供技术支持。104.3指定的细节。如果适用的话,提案要求和工作说明应该包括下面的内容：a.任务104的强制性。〔Rb.这个任务中提出的功能规则的确定。〔Rc.支持的检查、审计和委员会的频率、持续时间和可能的位置,以及任何一个指令。〔Rd.其他特定的风险管理需求,例如,特定风险的定义和这个程序中使用的矩阵。任务105集成产品开发团队/工作组支持105.1目的：任务105指定政府项目综合产品小组〔IPTS或工作组〔WGs提供支持。105.2任务描述：承包商应作为一员参与指定综合产品小组或工作组。这样的参与应包括,但不限于,以下活动:a：总结危害分析和与减少风险相关的状态b：发现与风险缓解措施相关的问题。c：努力使缓解措施的有效性和相应风险的减少保持一致。d：呈现事件〔特别是系统的事故和故障被发现的评估结果,包括建议和采取的行动,以防止再次发生。e:由指定的综合产品小组或工作组应对行动项目的分配。f：审查和验证降低风险的要求,标准和适用于系统的约束条件。g：规划和协调对所需的审查和认证程序的支持。h：要求选定的分包商,副承包商、供应商或厂商参与指定综合产品小组或工作组。105.3指定细节：要求建议书〔RFP和工作说明书〔SOW应包括以下内容<如适用>：a：任务105的实施〔Rb：通过这个任务解决了功能学科的识别〔Rc：指定的综合项目组和工作组,由承包商来支持〔Rd：把承包人会员资格要求和角色分配列入指定的议程和会议记录的编制和分发中。〔Re：综合产品小组或工作组会议的频率或总数和可能的位置〔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：由政府指定的危险品〔HAZMAT的数据成分106.2.1政府应用适当的控制数据管理来接触到危险跟踪系统106.2.2任务108<危险品管理计划>、任务204<子系统危害分析>、任务205<系统风险分析>、任务206<操作和支持危害分析>、任务207<健康危害分析>,和任务210<环境危害分析>对于风险跟踪系统可能包括额外的需求106.3指定细节：要求建议书〔RFP和工作说明书〔SOW应包括以下内容<如适用>：a：任务106的实施〔Rb：通过这个任务解决了功能学科的识别〔Rc：政府有访问所有的灾害管理数据的危险跟踪系统和数据的权利〔Rd：正式的政府传达了可接受的风险的程序给承包商〔Re：任何特殊的数据元素,格式,或数据的报告要求〔Rf:目前规划系统的生命周期去让危险品的使用或产生的投影〔如适用〔Rg:危险品管理异常,豁免,或临界值<如适用>〔Rh:额外的有害物质的数据元素和报告的要求〔Ri:其他特定风险管理需求,例如,特定风险的定义和矩阵上使用这个程序〔R任务章节200-分析任务201初步危险列表201.1目的。任务201是编制出一个在发展初期的潜在危险列表。201.2任务描述。承包者应该：201.2.1在军备解决方案分析开始时立刻检测系统,编制一个初步危险列表,可以识别概念中固有的潜在的危险。201.2.2检测过去相似的文件和遗留系统,包含但是却不限制与：A.灾难和事故报告B.危险跟踪系统C.经验学习D.安全分析和评估E.健康危害信息F.试验文件G.对于系统测试、训练、防护/基础以及维护〔有组织的,持久的,可能地点的环境问题。H.与国际环境政策法、总统令12114、环境影响国外的主要联邦行动相关联的文件I.废除武装和清理计划201.2.3承包者应当用文件证明在危险跟踪系统中被识别的危险。内容与格式要按照承包者和机构的约定。除非另外的规定201.3.d,内容最少应当包括：危险简明的描述每个识别的危险因果关系因素201.3资料详细说明。提案申请和工作说明书应该包含下面的内容,作为适用的：A.任务201的强制性B.解决这个任务的功能性学科的鉴定C.对获得政府文件的指导D.初步危险列表的内容与格式要求E.作业观念F.在这个大纲中使用到的其他特定的风险管理要求,等,特殊的风险定义和模型G.风险定义的参考文献和来源任务202预先危险分析202.1目的。任务202是通过执行或证明一个预先危险分析来识别危险,评估最初的风险和识别潜在的减轻措施。202.2任务描述。负责人应执行或证明一个预先危险分析,去决定已识别危险的最初风险评估。与被推荐的设计和功能相联系的危险,应该评价其严重程度和发生几率,基于最合理的数据。包括来自同一系统、遗产系统或其他经验学习得来的事故数据〔同样的可访问性。根据规定条款、替代选择和减轻措施来消除危险或减轻。相关的风险应该被包括。202.2.1负责人应该用危险跟踪系统来证明预先危险分析的结果。202.2.2预先危险分析应识别危险通过考虑通过潜在的导致系统或子系统事故由以下：a．系统组件b．能量来源c．军械d．危险原材料e．接口与控制f．当在一个网络