16. 摘要 本研究的目的是确定评估标准,使开发人员和认证机构能够从系统和软件安全的角度评估特定的安全关键型实时软件开发工具。报告阐明了当前航空系统认证指南中软件开发工具的概况。研究工作朝两个方向进行:(1)收集工具资格认证工作的数据,以检查现有指南未来可能出现的修改;(2)通过确定工具类别、功能、关注点、因素和评估方法来创建软件开发工具评估分类法。问题陈述有四个部分:(1)行业观点,(2)资格认证,(3)质量评估,(4)工具评估分类法。从行业收集的数据影响了评估过程和开发工具实践的建议。报告描述了用于评估工具的选定方法。报告介绍了研究过程中确定的不同类别的工具。此分类仅限于 DO-178B 指导的研究范围。最后,报告定义了工具评估分类法的结构和组织。
16. 摘要 本研究的目的是确定评估标准,使开发人员和认证机构能够从系统和软件安全的角度评估特定的安全关键型实时软件开发工具。报告阐明了当前航空系统认证指南中软件开发工具的概况。研究工作朝两个方向进行:(1)收集工具资格认证工作的数据,以检查现有指南未来可能出现的修改;(2)通过确定工具类别、功能、关注点、因素和评估方法来创建软件开发工具评估分类法。问题陈述有四个部分:(1)行业观点,(2)资格认证,(3)质量评估,(4)工具评估分类法。从行业收集的数据影响了评估过程和开发工具实践的建议。报告描述了用于评估工具的选定方法。报告介绍了研究过程中确定的不同类别的工具。此分类仅限于 DO-178B 指导的研究范围。最后,报告定义了工具评估分类法的结构和组织。
检查了数百个源故障描述,其中包括 15 个来自核电站的故障描述和 30 个来自通用数字控制领域的故障描述。表 2-1 列出了故障描述,并将它们与第 1 卷中的指南进行了交叉引用。表 3-2 提供了反向映射(即指南到故障描述)。来自通用数字控制领域的故障描述是轶事。它们不是正式的故障报告,仅用于说明目的。来自核领域的故障描述摘录自 LER,往往更完整。所有故障描述均未经过独立验证。
软件需求规范是系统开发中错误的重要来源(NUREG-0800,USNRC,1997c,第 A-7 页)。涉及软件的所有事故中,很大一部分(如果不是大多数)都可以归因于需求缺陷,例如对系统运行方式的不完整或错误假设。缺失、不准确或不完整的需求不仅会导致软件开发中的缺陷,还会阻止在验证和确认期间检测到这些缺陷。例如,功能测试基于需求;因此不会检测到缺失或不准确的需求。结构测试基于开发的代码;未说明的需求不太可能实现,因此不会被检测到。集成测试有时会检测到遗漏或不准确的信息,但更常见的是,只有通过实际操作中的故障,这些缺陷才会显现出来。