《GJB900A-2012 装备安全性工作通用要求》解析
说明：文章内容仅供预览，部分内容可能不全。下载后的文档，内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的，是否完整无缺。
《GJB900A-2012 装备安全性工作通用要求》解析 《GJB900A-2012 装备安全性工作通用要求》简介： · 代替号：GJB 900-1990 · 分类号：b0107 · 页数：40 · 实施时间：2013.04.01 · 主办单位：总装电子信息基础部 · 批准单位：总装 · 主编单位：总装电子信息基础部标准化研究中心、航天标准化与产品保证研究院、中航工业301所、空军装备研究院装备总体所、中航工业603所、海军装备研究院舰船所、二炮装备研究院三所、海军装备研究院规范所、工业与信息化部电子四所 适用范围： 本标准规定了装备寿命周期内开展安全性工作的一般要求和工作项目。 本标准适用于各类装备的招标、投标和签订合同。 第 1 页 共 7 页 引用标准： GB 2893 安全色 GB 2894 安全标志 GB 18218 重大危险源辨识 GJB 368 装备维修性工作通用要求 GJB 438B－2009 军用软件文档开发通用要求 GJB 450 装备可靠性工作通用要求 GJB 451 可靠性维修性保障性术语 GJB 2547 装备测试性工作通用要求 GJB 3872 装备综合保障通用要求 GJB/Z 99 系统安全工程手册 GJB/Z 102 软件可靠性安全性设计准则 GJB/Z 142 军用软件安全性分析指南 GJB/Z 768 故障树分析指南 GJB/Z 1391 故障模式、影响及危害性分析指南 GJB 900A-2012在其一般要求中规定 a) 装备开展安全性工作的目标：在装备寿命周期内，综合权衡性能、进度和费用，将装备的风险控制到可接受水平。 b) 安全性工作的基本原则有4条： 1) 在充分分析和研究的基础上，论证确定装备的安全性要求，安全性要求应合理、科学、可实现并可验证； 2) 遵循预防为主、早期投入的指导方针，…通过及时、有效、经济的方式将安全性综合到产品设计中去； 3) 在装备研制阶段，安全性工作必须纳入装备的研制工作，并根据装备特点和安全性要求，对安全性工作进行统筹策划，确保协调开展； 4) 加强安全性工作的组织和管理，按照权责一致的原则，明确各单位和机构在安全性工作中的职责。 c) 安全性工作的基本过程是一个反复迭代的系统工程过程，包括确定装备安全性要求、策划与管理安全性工作、识别危险、分析危险和评价风险、消除危险或降低风险、 第 2 页 共 7 页 验证安全性要求、评价安全性水平和跟踪危险。在消除危险或降低风险活动中，采取安全性措施的优先次序一般为：最小风险设计，采用安全装置，采用告警装置，制定专用规程并进行培训。并且对于危险严重性等级为Ⅰ级和Ⅱ级的危险，决不能仅仅使用告警装置、注意事项或其它形式的提醒作为唯一的减少风险的方法。 d) 安全性信息要求。安全性信息包括装备寿命周期中有关的安全性数据、资料以及文件等。要求制定必要的信息管理要求和程序，并建立相应的信息系统；对寿命周期中所得到的安全性信息进行收集、传递、分析、处理、反馈和归档；承制方向订购方提交的各项安全性工作资料、报告等，应满足订购方要求；安全性信息要求应在装备相关的合同和研制任务书中明确，并制定相应计划确保在研制过程中遵照实施。 e) 安全性工作应与可靠性、维修性、综合保障、测试性等工作相协调，并尽可能结合进行，减少重复，在安全性工作计划中应明确与这些工作的接口关系。 为了以经济有效的方式使装备满足安全性要求，需选择并确定安全性工作项目。在GJB 900A-2012的附录A应用指南中给出了装备安全性工作项目应用矩阵表示例，为初步选择工作项目提供一般性的参考，见表1。 表1 装备安全性工作项目应用矩阵表示例 标准在工作项目207安全性关键项目的确定与控制中指出，符合下述准则之一的软件，建议确定为安全性关键项目： a) 导致后果严重的危险（如该标准规定的Ⅰ级危险和Ⅱ级危险）或是其发生条件之一； b) 控制属于安全性关键项目的功能； c) 处理属于安全性关键项目的命令或数据； d) 对系统是否达到特定危险状态，进行检侧、报告或者采取纠正措施； e) 与属于安全性关键项目的软件在同一处理器内运行的软件； f) 进行危险趋势分析或数据处理，且其结果直接用于安全性决策； g) 提供安全性关键项目（包括硬件或软件）的全部或部分验证或者确认。 GJB 900A-2012还指出安全性关键项目的确定和控制应是一个动态过程，应通过定期评审来评定安全性关键项目控制和试验的有效性，并对安全性关键项目清单及其控制计划和方法进行增减。 第 3 页 共 7 页 在工作项目303制定安全性设计准则中指出，通用的安全性设计准则可参考但不局限于以下内容： a) 应通过设计（包括原材料、元器件的选择和代用），消除已识别的危险或将其风险降低到可接受水平； b) 危险的物质、零部件和操作应与其它活动、区域、人员以及不相容的器材相隔离； c) 对于不能消除的危险，应考虑采取补偿措施减少其风险，这类措施包括：联锁、冗余系统防护、灭火和防护服、防护设备、防护规程； d) 当各种补偿措施都不能将危险的风险降低到可接受程度时，应在装配、使用、维护和修理说明书中给出告警和注意事项，并在危险零部件、器材、设备和设施上做出醒目标记（标记应符合GB 2894的有关规定，采用的安全色应符合GB 2893的规定）； e) 尽量减少恶劣环境条件（例如：温度、压力、噪声、毒性、加速度、振动、冲击和有害射线等）所导致的危险； f) 装备设计时应同步开展防误操作设计、人机工效设计，降低人为差错的风险； g) 装备的布局应使人员在操作、维护或调试过程中，能尽量避开危险； h) 应综合考虑各种不利因素（环境及使用因素等）的影响，并留有一定的设计余量； i) 对Ⅰ级和Ⅱ级危险应采取容错设计； j) 对于影响安全的关键功能的冗余应在物理上或功能上进行隔离，设置保护措施； k) 应进行故障隔离设计，防止因自身故障而导致与之有接口关系的产品发生Ⅰ级和Ⅱ级危险； l) 对装备安全性起关键作用的系统、分系统、设备或部件应进行故障-安全设计，使其发生故障后仍能保证装备的安全； m) 已有的标准、设计规范中的安全性要求，例如：GJB/Z 102A规定的软件安全性设计准则。 标准在工作项目304系统危险分析中指出，系统危险分析在装备设计己足够详细或方案阶段后期开展，并随设计的深入而不断修改和完善。系统危险分析还可以评价设计更改是否影响装备的安全性。还指出，在评价软件对装备安全性的影响时，承制 第 4 页 共 7 页 方应监控和应用软件开发过程各阶段的输出结果，并向订购方报告需采取措施的软件问题，以便及时处理。 GJB 900A-2012关于软件安全性工作特别规定了工作项目600系列。其中包括： a) 一般考虑 1) 在软件密集且安全性要求高的系统中，危险往往由于硬件、软件及人为差错所导致。应分析这些复杂的潜在事故路径，确定为消除危险或降低其风险，对硬件和软件设计、测试的要求和限制条件； 2) 软件安全性工作是安全性工作和软件开发工作的一个重要组成部分，应将其集成到整个系统相关的安全性工作中，更好解决软硬件接口问题，并通过《接口需求规格说明》（见GJB 438A规定）明确安全性需求。 b) 外购与重用软件的分析与测试（工作项目601） 1) 分析安全关键软件与外购或重用软件的交互方式； 2) 分析外购或重用软件可能引起安全关键软件失效的故障模式； 3) 分析外购或重用软件没有使用的功能和代码…对安全关键功能的影响； 4) 通过测试和分析的方法，对外购或重用软件的接口和能力进行测试； 5) 组织有关专家，依据分析和测试结果对选择的外购或重用软件进行评审，给出评审结论。 c) 软件安全性需求与分析（工作项目602） 1) 软件安全性需求分析，应当与系统危险分析结合进行。系统危险分析为软件安全性需求分析提供输入信息，而软件分析的结果，应反馈给系统危险分析人员，用于在系统层次进行更全面细致的分析； 2) 从装备安全性要求、系统或设备要求、接口要求、系统危险报告以及系统危险分析中获取软件“必须工作”的功能和“禁止工作”的功能，以及相关的时间性能需求； 3) 从环境要求、系统或设备要求、接口要求中获取软件与硬件、软件与软件、软件与操作者等之间的安全性相关的全部约束； 4) 依据标准、项目规范、软件可靠性安全性设计准则等，归纳软件安全性通用需求； 5) 参照相关标准，使用规范的方式描述软件安全性需求； 6) 依据系统需求、软件标准、通用软件安全性需求、危险报告等审查软件需求，补充遗漏的安全性需求； 第 5 页 共 7 页 7) 选择使用软件失效模式及影响分析、软件运行模式分析、数据流分析、控制流分析、基于功能路径的软件潜在分析等方法，对软件需求进行安全性分析，并在《软件需求规格说明》中以独立条款，明确记录分析结果； 8) 标识所有与软件相关的危险和要求软件实现的危险控制； 9) 通过危险跟踪闭环系统，向相关主管人员报告找到的全部问题和新发现的危险。 d) 软件设计安全性分析（工作项目603） 1) 利用可追溯性矩阵，保证在设计中编入了所有的安全性需求，标识了安全性关键部件、单元和数据； 2) 在软件设计评审时，应对软件设计的可测试性、改善软件可测试性的建议，以及安全性关键部件的独立性给予特别关注； 3) 在安全性关键任务中，应重点考虑中断、时序、事件队列、硬件失效、通讯等问题对安全关键功能的影响； 4) 在《软件设计说明》中以独立条款明确记录软件设计安全性分析结果，记录发现的问题，提交设计评审。 e) 软件代码安全性分析（工作项目604） 1) 可利用可追溯性矩阵，确认在代码中编入了所有安全关键软件需求和设计元素； 2) 验证实现安全性关键需求/设计的所有源代码文件，起始处有一个注释区，指出这些文件是安全性关键的； 3) 依照编码标准，可利用工具对代码进行标准符合性检查； 4) 对代码的逻辑、数据、接口、中断和潜在路径等进行分析，并标识出未使用的代码； 5) 将发现的问题和危险，提交危险跟踪闭环系统。 f) 软件安全性测试分析（工作项目605） 1) 验证彻底地测试了所有软件安全性需求； 2) 通过测试验证安全关键软件在载荷、应力、硬件失效和操作员错误等多种条件下，都能正常运行； 3) 通过测试验证其他非安全性关键的软件设计元素的失效不会危及安全性关健功能的执行； 4) 利用可追溯性矩阵，验证测试覆盖了所有软件安全性需求； 第 6 页 共 7 页 5) 利用测试覆盖工具，验证测试覆盖了所有软件安全性关键设计元素； 6) 不能通过测试验证的需求，可通过代码审查验证，并报相关管理部门批准； 7) 在《软件测试报告》中以独立章节明确安全性验证分析内容，统计验证的安全性关键需求、软件单元、相关的记录文档，以及与预期要求不一致的全部问题或质疑； 8)《软件测试报告》应提交评审； 9) 如果发现了新的危险，应协助系统人员进行危险分析，并确定必须采取的措施。 g) 运行阶段的软件安全性工作（工作项目606） 1) 组织有关专家对软件运行文档进行审查，保证在文档中清晰地标识了所有安全性相关的命令、数据、输入序列等系统安全运行所必需的全部信息，包括错误消息描述和纠正措施； 2) 制定运行阶段的软件安全性工作计划，策划软件维护(更改与升级)、培训等活动中软件安全性相关工作的要求、流程、完成形式、人员等，提出产生、实现、追溯和验证安全性关键需求的机制； 3) 任何安全性关健软件需求的更改，必须报相关管理部门批准； 4) 任何软件的维护(更改与升级)，必须进行软件更改影响分析，确定回归测试的范围与层次； 5) 在软件交付之前，完成回归测试、验证覆盖分析和相关评审。 第 7 页 共 7 页 本文来源：https://www.wddqw.com/doc/c7151339cf7931b765ce0508763231126edb77c5.html