★ FEATURED ARTICLE 简介DO-330 是由 RTCA SC-205 制定并发布的软件工具鉴定标准作为 DO-178C 的配套文件面向机载软件工程师、适航审定人员与工具鉴定负责人主要用于解决型号研制和适航取证过程中软件工具是否满足可信性要求、应证明到何种程度以及如何编写证据等关键问题。整个资源仅含 1 个 PDF 文件压缩包大小约 768KB为英文原版标准全文从目次、前言到引言中的目的、范围、使用方法均有收录并系统阐述工具鉴定等级的确定、鉴定生命周期过程及相关数据要求便于对照原文逐条推敲。已有 765 人学习下载可应用于 DO-178C 项目评审、内部培训、质量保证文件编制以及适航沟通等场景帮助团队在开展软件工具鉴定时直接引用权威依据减少方向性偏差和返工风险。该标准对理解适航要求与工具可信度评估具有很高参考价值。1. 编译器会引入错误吗会——DO-330 就是管这件事的标准编译器会引入错误吗会但适航审查真正想问的是你凭什么相信这个工具的输出。某型号飞控软件项目里A 同学拿着 DO-178C 的目标清单把代码和测试都过了一轮审查方一句自动代码生成器做没做工具鉴定整个验证策略被打回重排。DO-330Software Tool Qualification Considerations2012 年 3 月版就是为这个信任缺口而生的配套标准它规定软件工具怎样按使用方式确定工具鉴定等级TQL怎样规划、开发、验证、做配置管理并留下哪些证据才能支撑 DO-178C 的适航结论。机载软件开发者、工具供应商、适航工程师以及临时接手工具鉴定任务的测试团队都绕不开这本东西。它解决的不是工具好不好用而是这个工具的输出可不可以当作适航证据用。2. 工具鉴定等级与工具准则DO-330 怎样判定一个工具该信几分2.1 工具为什么是黑匣子错误引入与错误漏检两条风险线DO-330 对工具的定义比日常理解更窄所谓软件工具是在 DO-178C 软件生命周期的某个过程中自动化执行一项或多项活动的软件比如编译器、自动代码生成器、静态分析器、覆盖率工具、测试用例生成器。标准最关心的问题只有一个这个工具的输出会不会影响最终适航结论的可信度。工具出错的方式分成两类这两类对应两条完全不同的风险线。第一类是工具把错误引入产物代码生成器生成了不符合需求的逻辑编译器把正确的源程序编译成错误的目标码这类错误会直接进入机载软件。第二类是工具让验证失效静态分析器漏报了一个除零分支覆盖率工具统计漏了几条路径这类错误让审查方误以为验证已经充分。DO-330 里所有等级划分、过程要求、验证深度本质上都在回答这两个问题这个工具有没有机会引入错误它失效后有没有独立手段兜底。所以工具鉴定的第一课是分清黑匣子的类型。有的黑匣子输出直接装进飞机有的黑匣子只是帮人检查飞机两者的信任要求天差地别。DO-330 把这两条线落成了一张等级表TQL 1 到 TQL 5等级越高要求越严。2.2 TQL 1-5 怎么定过程目标逐级裁剪工具鉴定等级Tool Qualification Level是 DO-330 的核心概念。它不像考试分数不是分越高越好而是按使用后果倒推出来的最低信任要求。TQL 1 要求最严TQL 5 相对宽松。这里的严和松体现在过程目标上高等级的工具有更多开发过程目标、验证过程目标和配置管理目标要满足低等级的可以裁剪掉一大部分开发活动重点保留配置标识和最终验证。我一般会先用下面这张简化表建立直觉再去对照标准原文的详细目标表工具鉴定等级典型定位过程目标侧重工程直觉TQL 1工具输出直接决定机载行为且无独立缓解开发验证CMQA全目标把它当成机载软件本身来审TQL 2工具输出直接决定机载行为有部分缓解措施开发验证目标部分可裁剪高保证但允许用外部手段分担TQL 3工具对生命周期产物有实质影响验证目标为主开发目标可裁剪中等保证重点是证明输出正确TQL 4工具用于验证失效不至于完全不可信验证目标保留开发目标大量裁剪低保证但不允许完全裸奔TQL 5工具只辅助验证失效有独立手段兜底保留基本标识、问题报告、评审最高等级的裁剪判定 TQL 时工程上最常用的路径是先给工具按使用准则分类见 2.3再评估如果这个工具坏了软件生命周期里还有没有独立的手段能发现。这两步做完基本能锁定一个初步等级。注意同一款工具在不同项目里等级可能完全不同覆盖率工具在 A 项目只做统计报表拿 TQL 5在 B 项目被当作验证过程的唯一检查手段就可能升到 TQL 3 甚至更高。等级绑定的是使用方式不是工具品牌。2.3 按准则给工具分类准则 1/2/3 的判定步骤DO-330 里习惯把工具按使用准则分成三类这个分类是 TQL 判定的前提。我把它理解成一条三步判定链列出工具写清楚它用在哪个生命周期过程、输入是什么、输出是什么、输出流向哪里。判断工具的产物是否会成为最终机载软件的一部分编译器、代码生成器、汇编器的输出进目标码属于准则 1。如果工具只参与验证再判断没有它验证是否仍然可信或可完成静态分析器、覆盖率工具这类说话算数、缺了就不行的验证工具归入准则 2只帮助生成测试用例或辅助生成预期结果的工具归入准则 3。需要特别小心的是准则 2 和准则 3 的分界线。准则 2 的工具失效后验证结论会直接受影响准则 3 的工具失效后通常还能靠人工复核或其他手段兜底。同一个生成测试用例的工具如果它的预期结果被直接拿去跟实际输出比对、且没有独立人工判读它就滑进了准则 2 而不是准则 3。这一步定错了后面整个 TQP 都得返工。提示准则分类和 TQL 判定都有标准原文的判定表格。实际做项目时先按判定链给每个工具出一个类别等级初判结果再拿给适航工程师过目别自己闷头定版本。3. 把工具当成一台小飞机来开发规划、开发、验证三阶段落法3.1 工具规划过程TQP 先把边界、等级、环境定死DO-330 要求工具鉴定从规划过程起步核心产出是工具鉴定计划TQP)。很多团队把这个计划当成应付审查的模板这是最大的误区。TQP 是后续一切证据的索引工具等级、使用环境、生命周期模型、裁剪声明、数据清单全部在 TQP 里定义清楚。我一般会在 TQP 里强制写满四块工具识别信息工具名、版本、供应商、安装环境操作系统、编译器版本、库文件版本。使用场景声明工具在哪些生命周期过程中使用、输出产物流向、相关软件等级。鉴定等级声明按第 2 章的判定链给出工具准则、TQL并写一句这个等级依据的裁剪理由。数据交付清单要和 DO-330 第十章的数据目录对齐列出计划产出的每一项鉴定数据及责任人。这里有一个常见问题工具版本只写了大版本号没写补丁号。之后环境变了审查方拿 TQP 对环境时对不上整个鉴定有效性就悬了。我在做规划时会把工具环境细化到可执行文件哈希值 安装时间 补丁记录宁可过度锁定也不要事后打补丁。3.2 开发过程怎么对齐 DO-178C 思路DO-330 对工具本身的开发过程借鉴了 DO-178C 的开发活动结构需求、设计、编码、集成。区别在于裁剪深度。TQL 高的工具这几个过程都要完整走一遍包括工具需求规格、工具架构设计、编码标准、代码评审TQL 低的工具可以裁剪掉大部分开发中期产物把力气集中在工具需求定义和最终验证上。具体操作上我会抓三样工具需求Tool Requirements不能只写功能需求要写在什么条件下输入什么、输出必须满足什么特征。工具需求是后面验证用例设计的源头需求写得碎测试用例就好写。工具设计与源码TQL 2 以上建议保留设计描述和源码评审记录。别听供应商说我们的工具是商品货架软件不给源码。DO-330 并没有一刀切豁免货架工具审查时该要还是得要么。工具集成产物工具安装后的可执行文件、库文件、配置文件要纳入受控。集成过程出问题往往不是工具本身错了而是环境变量、依赖库版本对不上。把工具当成一台小飞机来开发的意思是工具的每一层活动都要能追溯到上一层的输入。工具需求对应工具设计工具设计对应源码源码对应验证用例——这条链子哪怕在裁剪状态下也不能断断了就是证据链的断层。3.3 验证过程三条腿评审、分析、测试工具的验证过程和机载软件验证同构但要按工具的逻辑来定制。我一般按三条腿去铺第一条腿是评审。需求评审看需求写的是不是工具真正该做的事设计评审看架构能不能容纳异常输入代码评审看有没有明显的未定义行为。评审记录要留参会人、结论、问题关闭记录别只留一份签到表。第二条腿是分析。包括覆盖分析验证用例覆盖了多少工具需求、覆盖了多少代码结构、安全性分析工具失效会不会导致机载软件进入危险状态、鲁棒性分析工具对非法输入、超范围输入、中断恢复有没有保护。分析结果在 TAS 里要有明确结论不能写成未见异常四个字。第三条腿是测试。测试用例至少覆盖三组正常输入组、边界输入组、非法输入组。正常组证明功能实现边界组专门打数组越界、字符串超长、数值上下限非法组打空输入、错格式输入、异常中断。工具的鲁棒性测试是审查方最爱翻的一页这一页如果只有 happy path基本会被质疑验证不充分。提示工具验证用例的预期输出要独立于工具自身生成。比如验证代码生成器预期结果应来自人工推演或独立参考实现而不是生成器跑一遍得出的结果反过来当预期。这一条违反了验证就变成工具自己证明自己证据无效。4. 工具鉴定常见问题五个踩坑记录按现象-原因-解决复盘4.1 等级判定与证据链上的三个坑坑一把验证工具定为低等级审查时被打回。现象某项目用静态分析器作为缺陷发现的唯一手段按 TQL 5 做了鉴定审查方质疑不足以支撑验证结论。原因团队只看工具没进机载代码属于准则 3忽略了准则 2 的定义工具自动化验证过程且其输出是验证结论的主要依据。工具失效后验证结论不可信等级就得往上走。解决重新按判定链过一遍这个工具属于准则 2TQL 提到 3补充了工具需求评审记录和鲁棒性测试用例重新走变更。从那以后我定等级前都会先问一句如果这个工具今天坏了验证结论还站得住吗坑二拿软件项目的过程记录冒充工具开发记录。现象工具鉴定证据文件夹里贴的是机载软件项目的需求评审记录和 QA 记录。原因工具供应商把工具当普通软件做了开发没单独建工具鉴定台账项目方为了凑数直接复制了同类文档。解决把工具鉴定的所有记录独立成卷每条记录带工具名、版本号、鉴定标识。DO-330 要的证据必须能看出是这个工具在这个版本下的活动结果混在一起的文件在审查时一文不值。坑三TQP 里写了裁剪却没写裁剪理由。现象TQP 声明本工具不执行正式编码过程审查方追问为什么可以裁掉设计过程。原因裁剪声明只有结论没有依据DO-330 的裁剪逻辑是按 TQL 等级目标来裁剪不是按项目工期来裁剪。解决TQP 里每一句裁剪都写对应标准目标编号 不执行的客观理由比如该 TQL 等级不要求工具设计描述故本节留空。4.2 环境变更与测试覆盖上的两个坑坑四工具打补丁或升级后没有重新评估鉴定有效性。现象编译器从 4.2 升到 4.2.1回归测试跑了一遍全对团队直接继续用审查时被指出鉴定环境已不在受控基线内。原因配置管理只锁了源码没锁工具环境变更控制流程没有覆盖工具本身升级这个入口。解决把工具可执行文件、依赖库、运行参数全部纳入配置基线任何变更走变更申请→影响分析→补充验证→更新 TAS四步。影响分析要回答升级是否影响工具输出格式、是否影响已有验证结论、是否需要重新跑验证子集。坑五工具验证用例只覆盖正常路径鲁棒性一测就翻车。现象覆盖率工具的验证用例全部通过审查方自己在目标环境中输入了一个超长路径字符工具直接崩溃。原因验证用例按使用手册的示例生成没有做等价类和边界值设计。解决补了边界值用例输入长度上限、路径含空格、中文路径、文件权限受限和非法输入用例空目录、损坏的配置文件。工具不是被测软件它的用户输入千奇百怪鲁棒性测试必须当成正式验证内容而不是加分项。5. 工具鉴定数据怎么组织TQP、TDR、TAS 和它的索引-证据骨架5.1 规划期文档做厚别当模板填空DO-330 第十章把工具鉴定数据分成了规划期数据、执行期数据和运行验证数据。规划期数据是一组计划与标准我习惯把它们看成承诺文档——写的是我打算怎么干。审查方后续审查时会拿计划对照执行凡是承诺了没做的都会被直接记为不符合项。规划期文档通常包括这些按项目裁剪但建议至少做全前六个文档内容要点我一般怎么用工具鉴定计划TQP等级、环境、生命周期模型、裁剪声明、数据清单项目工具鉴定的总纲所有其余文档都从它展开工具开发计划开发活动、方法、组织职责TQL 偏高时写满低等级可压缩为一段工具验证计划验证策略、用例范围、通过准则明确正常/边界/非法三类用例数量工具配置管理计划基线划分、变更控制、发布流程把工具环境锁定规则写清楚工具质量保证计划QA 活动、审计点、偏差处理说明 QA 怎么独立于开发工具需求标准/设计标准/编码标准编写规范直接引用公司现有标准再加工具专用条目别另起炉灶工具生命周期环境配置索引开发与运行环境的完整快照含操作系统、依赖库、补丁、路径、环境变量这里有个血泪教训TQP 里声明工具运行环境为 64 位操作系统结果执行期用的库文件是 32 位版本审查方核对环境配置索引时发现不一致。从那以后我要求 TQP、环境配置索引、安装报告三者里的环境信息必须逐字一致哪怕是一个路径分隔符都不允许出现两个版本。5.2 执行期数据留住证据要点在版本和时间执行期数据是工具鉴定真正的正文工具需求、工具设计描述、工具源码、工具可执行目标码、工具验证用例、工具验证结果、追溯数据、工具问题报告、配置管理记录、QA 记录。这些东西单独看都不复杂复杂的是它们之间的追溯关系。追溯数据我一般做成一张表每条工具需求 → 对应的设计元素 → 对应源码模块 → 对应验证用例 → 对应验证结果 → 对应问题报告。用 Excel 或需求管理工具维护都行关键是表格里的每个条目都要有版本号和变更时间。工具需求改了如果没有同步更新设计和验证用例追溯表就会出现悬空节点审查方一眼能看出这条链断了。工具验证结果这条数据最容易出问题的地方是预期输出没有独立来源。我前面提过验证代码生成器时预期输出必须来自独立推演不是工具自己生成的。文件命名也建议带上工具版本比如codegen_4.2.1_verify_result_v1.xlsx这样每次升级后结果文件不会互相覆盖翻旧账时能快速定位。5.3 TAS 的写法一半是结论一半是证据索引工具鉴定总结Tool Accomplishment SummaryTAS是审查方最先翻的文件也是工具供应商递交时的门面。它的角色很特殊既要给出这个工具达到了 TQL x 的置信度的结论又要把分散在十几个文件夹的证据全部串起来。写 TAS 时我把它当成证据索引报告而不是成果汇报。TAS 的标准骨架建议按六块走工具信息名称、版本、供应商、开发环境与运行环境快照。鉴定结论工具准则、TQL、等级判定依据文章。目标对照表逐条列出这个 TQL 等级要求的过程目标每条对应满足方式 证据文件引用 证据版本。偏差说明哪些目标没完全满足理由是什么有没有替代手段。问题报告汇总工具开发和使用期间遗留未关闭的问题每个都要有影响分析。引用数据清单所有支撑文档名、版本、存放路径的完整清单。第 3 块是核心。审查方拿到 TAS 后不会从头到尾读而是随便挑一条目标沿着目标 → TAS 声明 → 引用的证据文件 → 实测结果这条路走一遍。如果路径上任何一环断裂或含糊整份 TAS 的可信度都会被打折扣。所以我写 TAS 时有个习惯每写完一条目标声明立刻打开引用的那份证据文件核对里面的内容确实验证了这行字而不是我记得好像验证过。注意TAS 里的偏差说明千万别写成此项不适用就完事。每一句不适用后面必须跟为什么否则会被审查方理解为逃避目标接下来就是一轮轮补解释周期直接拉长。6. 一个落地习惯工具进场先做鉴定影响分析再谈选型把 DO-330 用熟之后我的工作习惯变成了这样任何新工具进入项目环境前先跑一轮工具鉴定影响分析而不是等工具用起来了再补鉴定。这个分析不是给工具做鉴定是做预判先在选型阶段筛掉一批鉴定成本过高的方案。具体分四步。第一步建工具台账把项目里每个生命周期过程用到的工具列全包括临时脚本、内部小工具、甚至 Excel 宏——审查方眼里没有这不算正式工具的说法凡是参与产生或验证产物的都要先列出来再谈裁剪。第二步对每个工具走一遍 2.3 的判定链输出是否进机载代码、验证是否依赖它、失效后有没有独立兜底初步标出准则和 TQL。第三步把初判 TQL 2 以上的工具标为高风险项在选型评审时单独讨论这个工具值不值得引入有没有替代方案供应商能不能提供开发证据。第四步把判定结果连同依据写进 TQP作为鉴定活动的起点。这套习惯救过我两次。一次是项目原计划用一个开源脚本做格式转换影响分析发现它属于准则 1 且供应商证据为零果断换成了有鉴定记录的商业工具省掉了自研验证脚本的几个星期。另一次是某个覆盖率工具初判 TQL 5影响分析时发现项目把它的输出当作唯一覆盖率结论等级被拉到 TQL 3补了大量用例——如果等审查时才发现整个验证阶段都要重跑。从那以后我在每个项目启动会上都强制过一遍这张表哪怕是非适航项目也跑一版省掉的不只是返工还有跟审查方来回扯皮的周期。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
