软件工具：像T1、T2、T3一样简单

没有工具和软件就无法建造房屋。IEC 61508谈到了两种类型的软件工具。作为应用程序的一部分运行的在线工具，以及在开发或制造阶段使用的离线工具。在线软件工具与安全系统中的任何其他软件具有相同的要求，但是用于开发或测试产品中软件的离线软件工具呢？离线软件工具包括编译器、编辑器、静态分析工具和需求管理工具等。本博客讨论了与 IEC 61508、ISO 26262 和 D0-178C/D0-330 等标准中的离线软件工具相关的要求。

我注意到，与工具相关的功能安全要求远比网络安全等其他高完整性领域要繁重得多。大多数网络安全标准几乎没有与工具相关的要求，这让我感到惊讶，因为它们没有与集成电路开发相关的要求，而集成电路是大多数系统的基础。

下图显示了与汽车 ISO 26262 要求兼容的过程。首先，列出了您计划使用的所有工具。然后，如果您的开发过程中有其他东西会检测到工具输出中的错误，则无需对工具进行进一步分析，如下面的流程图所示。虽然这不是严格的IEC 61508标准，但我喜欢这种方法，因为对于大多数工具来说，它提供了一个快速简便的退出点，官方流程最终到达，但经过更多步骤。

图1 - 基于ISO 26262要求的简化流程图

回到IEC 61508流程，有3类定义的工具

T1 – 对可执行代码没有影响的工具。IEC 61508-4：2010中给出的示例包括文本编辑器和需求管理工具。也许与文本中给出的示例更一致的描述是不用于生成代码或验证代码的工具，但即便如此，也很难说文本编辑器只是一个 T1 工具。

T2 – 仅影响可执行代码验证的工具，并且不能将错误注入代码，但可能导致错误丢失，例如静态时序分析工具

T3 – 可以在代码中放置错误的工具，例如编译器

第一个要求是应管理工具的使用。这通常意味着在制定软件安全计划时，您应该列出您计划使用的所有工具、它们的用途以及您计划使用的工具版本。 还需要说明该工具的理由。

接下来，根据上述定义将工具排名为 T1、T2 和 T3。如果一个工具被列为 T2 或 T3，那么您需要考虑该工具如何出错，以及开发过程中还有哪些内容会捕获该错误（开发过程中固有的缓解措施）。如果没有任何东西可以捕获此类错误，则必须确定一些适当的方法来减轻错误。

分类为 T2、T3 的工具还必须具有合适的文档。此外，对于归类为 T3 的工具，需要额外的证据证明它符合该文档。证据可以基于使用中的证明或基于测试用例的工具验证。

对于具有许多功能的复杂工具，每个功能都可以单独分析，就好像它是几个独立的工具一样。

在IEC 61508圈子里，关于软件离线工具要求是否适用于硬件开发工具存在一些争论。用于开发集成电路的工具包含在IEC 61508-2：2010附录F的要求中，主要涉及在类似复杂性的项目中使用2年的证明使用。在汽车领域，更清楚的是，无论正在开发的硬件还是软件，工具要求都适用。我相信这也是基于IEC 61508的开发的正确方法。

后来在IEC 61508-3中，表A.1提倡使用工具进行需求管理，表A.3提倡使用经过认证的工具和经过认证的翻译人员。

展望未来，有计划改进IEC 61508-3中的离线工具要求，请关注此空间。

审核编辑：郭婷