4. 工具分类方法：工具分类的步骤、工具对安全需求的影响分析、工具错误的检测能力评估

好，咱们接着聊工具鉴定。前面几章我们把工具鉴定的基本概念和流程捋了一遍，这一章我重点讲讲工具分类的具体方法。说实话，很多工程师一上来就急着做鉴定，结果发现工具太多、场景太杂，根本无从下手。问题出在哪？就是没做好分类。

我个人习惯，拿到一个工具列表，先花半天时间做分类。分类做对了，后面的事情就顺了。怎么做？咱们一步步来。

4.1 工具分类的步骤

工具分类，说白了就是回答三个问题：

• 这个工具用在哪个阶段？ 需求、设计、实现、测试、还是运维？
• 它影响什么？ 直接影响安全需求，还是间接影响？
• 它出错了会怎样？ 错误能被发现吗？还是悄无声息地溜进最终产品？

基于这三个问题，我一般分四步走：

步骤一：识别工具的使用场景

先别急着看工具本身，先看它用在哪个开发阶段。举个例子，Simulink 用在模型设计阶段，Polyspace 用在代码静态分析阶段，VectorCAST 用在单元测试阶段。每个阶段对安全的影响不一样，分类的侧重点也不同。

步骤二：判断工具对安全需求的影响

这一步是关键。ISO 26262 里把工具对安全需求的影响分为两类：

• 直接影响： 工具的输出直接成为安全相关产品的一部分。比如代码生成器生成的代码，直接烧录到ECU里。
• 间接影响： 工具的输出不直接成为产品，但会影响安全需求的验证。比如测试工具，它不生成代码，但它的测试结果决定了你是否认为代码是安全的。

嗯，这里要注意，有些工具既有直接影响又有间接影响。比如模型检查工具，它既可能生成代码（直接影响），也可能只做验证（间接影响）。这时候就要看具体的使用方式了。

步骤三：评估工具错误的检测能力

工具本身也会出错。比如编译器可能把正确的代码编译成错误的机器码，测试工具可能漏报一个严重的bug。所以我们要评估：工具出错了，我们能发现吗？

ISO 26262 把检测能力分为三个等级：

步骤四：确定工具置信度等级（TCL）

根据前面三步的结果，我们可以把工具分为三类：

• TCL1： 工具对安全需求影响小，或者工具错误很容易被发现。这类工具基本不需要鉴定。
• TCL2： 工具对安全需求有影响，且工具错误不容易被发现。这类工具需要做一定的鉴定。
• TCL3： 工具对安全需求有直接影响，且工具错误很难被发现。这类工具必须做严格的鉴定。

你想想看，TCL3 的工具，比如代码生成器、编译器，它们直接决定了最终产品的行为，而且一旦出错，你可能根本不知道。所以这类工具是鉴定的重点。

4.2 工具对安全需求的影响分析

这一节我展开讲讲“影响分析”。很多新手容易犯一个错误：只看工具本身，不看工具的使用方式。举个例子，MATLAB 本身只是一个计算工具，但如果你用它来生成代码，那它就变成了一个直接影响安全需求的工具。所以，影响分析一定要结合具体的使用场景。

我个人习惯，做影响分析时问自己三个问题：

1. 这个工具的输出，会不会成为安全产品的一部分？ 如果是，那就是直接影响。
2. 这个工具的输出，会不会影响安全需求的验证？ 如果是，那就是间接影响。
3. 如果这个工具出错了，最坏的结果是什么？ 这个问题的答案决定了你后续鉴定的力度。

4.3 工具错误的检测能力评估

这一节是重点中的重点。工具错误的检测能力，说白了就是：工具出错了，我们能不能及时发现？

我把它分为三个层次：

层次一：工具自身能检测到错误

有些工具自带错误检测机制。比如编译器，你写错了语法，它直接报错。这种错误很容易被发现，所以检测能力高。再比如形式化验证工具，它如果发现了一个反例，会明确告诉你哪里错了。这种也是高检测能力。

层次二：通过其他手段能检测到错误

有些工具的错误，工具本身发现不了，但可以通过其他手段发现。比如单元测试工具，它可能漏报一个bug，但如果你做了代码评审，或者做了集成测试，这个bug可能就被发现了。这种属于中等检测能力。

层次三：错误几乎无法被检测

这是最危险的情况。比如代码生成器，它生成了一个逻辑错误的代码，但功能测试恰好没覆盖到那个场景。或者配置工具，它生成了一个错误的配置文件，但系统在正常运行时没触发那个错误分支。这种错误可能直到产品交付、甚至客户使用时才被发现。检测能力极低。

4.4 一个完整的分类示例

说了这么多，咱们看一个实际的例子。假设你有一个项目，用到了以下工具：

你看，同样是工具，TCL等级完全不同。Embedded Coder 是 TCL3，必须做严格的鉴定。Polyspace 是 TCL1，基本不需要鉴定。这就是分类的意义——把有限的精力花在最关键的地方。

好，这一章就到这里。下一章我们讲具体的鉴定方法，包括如何制定鉴定计划、如何执行鉴定、如何记录鉴定结果。咱们下章见。