聊聊软件工具置信度

共计 1993 个字符，预计需要花费 5 分钟才能阅读完成。

作者：刘钊江；微信号：zhjliu

本文为汽车电子设计系列，由国内工程师撰写一些心得体会，有空的时候刊登出来，希望阅读的汽车电子工程师参与讨论和提供不同意见的，希望对国内汽车电子工程师的成长有价值。

功能安全标准ISO 26262-8明确规定了对软件工具的置信度要求。为什么会提出这些要求？有哪些关键点？应该如何实施？本文将为你独家解读。

背景

功能安全的开发过程中会用到多种多样的软件工具。如果软件工具在使用过程中出现了功能异常，就有可能影响功能安全。这是需要对软件工具置信度进行论证的根本原因。

那么，哪些软件工具需要进行论证呢？ISO 26262-8的11.4.1节的描述是：“a software tool for the development of a system, or its hardware orsoftware elements”，应该说范围很明确。

关键点

软件工具置信度论证，主要包含计划（Plan）、分级（Classification）、鉴定（Qualification）和确认评审（Confirmation Review）4个环节。对于论证范围内的每一种软件工具，从流程上来说这4个环节都是不可省略的。

一、计划软件工具的使用，主要包括确定软件工具的版本号、配置以及它可能影响的所有安全需求中的最高ASIL等级。这个环节的目的就是对需要用到的软件工具进行精确定位。

二、分级，是为了确定软件工具的置信度水平（Tool Confidence Level，TCL）。置信度水平越高，就越有可能影响功能安全，这在下一个鉴定环节也有所体现。通过分析软件工具的功能（输入、输出），从工具影响（Tool Impact，TI）和工具错误探测（Tool error Detection，TD）两个方面进行评估：

• TI：软件工具功能异常影响安全需求的可能性（有、无）；
• TD：防止或探测软件工具功能异常的置信度（高、中、低）。

然后，依据下表来确定置信度水平：

值得注意的是，TD的高低跟软件工具的使用方式及研发流程有密切关系。例如，同样的静态分析工具，在不同的电脑上分别运行，再对比先后两次的分析报告，就可以提高错误探测置信度。当然，你需要付出更多的工作量。

常见的工具类型及其置信度水平如下表所示：

请注意，以上结论并不是绝对的，具体问题还需具体分析。Cadence公司的模拟/混合信号工具链实施的是TCL1认证，这是因为相对软件设计工具而言，硬件设计工具显然具有更高的错误探测置信度。

三、分级之后，对TCL2和TCL3的软件工具需要进行鉴定，而TCL1的软件工具可以跳过此环节。鉴定方法见下表：

对上述a、b、c、d四种鉴定方法而言：

• 使用中积累置信度：需要特别注意软件工具的版本、配置及bug记录；
• 工具开发流程评估：从搜集证据的角度来说，这种方法最容易实施；
• 软件工具确认：主要通过测试进行，需要考虑异常运行条件；
• 按照安全标准开发：自己开发的工具可考虑采用此方法。

不难发现，c、d方法的实施难度和a、b方法完全不在一个层面。但当你进行高ASIL等级的开发时，不可避免的会面对c、d的要求。怎么办？如果你担心技术难度太大又或者项目周期太紧，你可以借助软件工具供应商的力量。目前主流的功能安全软件设计工具、测试工具及编译器均有符合ISO 26262要求的版本面世，你可以放心大胆的使用。当然，这样的软件工具一般价格也不便宜。

四、确认评审依据ISO 26262-2的相关要求进行。需要特别注意的是，只对ASIL C和ASIL D的开发有强制进行确认评审的要求。

实施建议

论证软件工具置信度，无非就是横向和纵向两种方式。所谓横向实施，就是每个环节出一份报告，这份报告里包含了所有软件工具的信息；所谓纵向实施，就是每一种软件工具的论证都合在一份报告里，包括全部4个环节。

这两种方法各有利弊。横向实施把同一阶段的任务集中在一起，更有利于开展工作；纵向实施把同一工具的论据集中在一起，更有利于维护更新。

另外，要特别强调一下论据复用。在首次进行软件工具置信度论证时，正所谓万事开头难，工作量非常大。但有了基础之后，产品变更设计或者其它项目进行功能安全开发时，只要使用的软件工具没有发生变化，其论据就可以重复使用，这样能节省大量的时间精力。当然，确认评审还是要重新做。

（个人观点，仅供参考；如有异议，欢迎讨论。）