实施各种软件值得付出努力吗？

功能安全需要应对随机故障和系统故障。软件只有系统故障，因为软件没有随机故障，因为如果出现相同的情况，软件故障通常每次都以相同的方式导致系统故障。达到更高安全水平的一种方法是实施双通道系统，每个通道中都有不同的软件。具有相同软件的冗余通道会将软件作为单点故障。如果两个通道具有不同的软件，那么争论是它们不太可能同时以相同的方式失败，从而允许更高的SIL索赔。听起来不错，但有问题吗？让我们在博客中更深入地或尽可能深入地了解。

首先，让我们看一下IEC 61508中提供了哪些指导，然后看看文献中提供了哪些指导以及一些基于多样性的设计模式。

在IEC 61508-3：2010中，以下子条款涵盖了这一点

图 1 - IEC 61508-3 的相关摘录

看看IEC 61508-2：2010子条款7.4.3说SC（系统能力）最多只能提高一个级别。因此，例如，如果两个软件的SIL声明为SIL 1，那么组合最多为SIL 2。我想最多只允许增加一个的限制是存在的，因为将这两个项目结合起来的人不知道各个开发的细节，也许可能存在一些隐藏的常见原因故障，例如使用的工具。如果从头开始开发这两个软件，你可能会做得更好。

IEC 61508-3 附录 A 中的表格提供了一些指导，表 A.2 提供了不同架构的四种替代版本，表 A.10 要求对软件进行 CCF（常见原因故障）分析，此措施建议在 SIL 2 中，强烈建议用于更高的 SIL。

图 2 - IEC 61508-3：2010 摘录

但是开发各种软件有多难。Philip Koopman在他的优秀著作“更好的嵌入式系统软件”第26.3.3节中对这个话题有一个很好的评论。在本节中，他指出，实现真正多样化的软件确实很困难，但很容易获得一定程度的多样性。他指出，量化所实现的多样性也很难，这并不奇怪，因为硬件CCF分析在标准中有更多的指导，仍然更多的是工程判断而不是科学。Philip Koopman进一步警告说，“许多人（包括我们）认为，如果你的时间和资源有限，你最好制作一个真正好的软件版本，而不是试图制作两个独立的版本，而这两个版本本身就没有那么好。两个版本中可能会有太多相同的错误。

我看了看是否有任何研究来支持这一观点。我看到的关于这个主题最有趣的笔记是下面显示的，他们给 27 名学生提供了一个规范，并要求他们编写软件来实现它，然后检查有多少不同的软件以同样的方式失败。它确实支持了编写各种软件确实很难的观点。

图3 - 关于不同软件价值的有趣实验论文

然后是HSE数据，它们显示了编码阶段（设计和实现）中很少的错误，这表明除非规范具有多样性，否则您不会获得很多好处。

图4 - 系统因HSE而失败的原因

为波音777开发电传飞行软件的团队似乎已经采用了三种不同的软件，开发了三种不同的规格，使用三个不同的开发团队，他们不应该相互交谈，运行在三台不同的（不同的）计算机上控制飞机。然后，当其中一个产出与其他产出不一致时，使用选民来选择行动方案。

航天飞机使用了一种类似的架构，使用五台计算机，四台相同，一台不同。各种微型计算机上的软件也多种多样。

基于多样性的功能安全软件的一种设计模式是N版本编程，它使用根据同一组需求开发的不同代码的多个版本，并对其输出进行投票。

图 5 - N 版本编程模式的绘制（安全关键型嵌入式系统的设计模式）)

如果我们将上述内容视为可靠性框图，那么投票者是CCF来源的明显弱点，除非投票者是超可靠的，否则从高值N中获得的好处将是有限的。

让我们将多样化的软件方法与一些替代方案进行比较。双核锁步微控制器不实现软件分集，而是一种硬件安全机制，因为两个内核将运行相同的软件。相比之下，软件锁步/软件 RMT 与逐周期锁步不同，可以实现软件多样性，但比时钟逐周期锁步方法检测差异的时间更长。软件锁步可以在不同的处理器上运行，甚至可以在单个处理器的冗余线程上运行，并在选定的观察点比较它们的输出。

即使您实施了各种软件，用于生产软件的工具呢？这些也可能是常见原因故障的根源，但如果在CCF中考虑到这一点并选择了不同的工具，或者选择的工具以满足整体安全功能的SIL要求，或者您使用适合组合元件SIL的工具，您可能很高兴。

审核编辑：郭婷