背后的数学原理在应用中得到验证

IEC 61508 和 ISO 26262 都提供“经过验证的使用”作为声明合规性的替代途径。在 IEC 61508 中，经使用验证的术语称为路由 2S.更常见的路线 1S表示该项目的开发符合标准的所有适用要求。路线 2S当该项目的开发不符合IEC 61508时，可以使用，但有很多操作经验可以表明其安全性。已经运行了很长时间并且从未出现任何问题的东西足以在安全系统中使用，这似乎是合理的。这至少是路线2背后的前提S.该路由可用于硬件和软件，但在这种情况下，我将更多地关注硬件合规性。

以下是IEC 61508和ISO 26262中最重要的表格。虽然IEC 61508暗示了表格背后的数学原理，但此博客可能会使您不必自己弄清楚。我个人总是喜欢了解我应用的任何东西。否则很容易误用。对于ISO 26262，几乎没有给出的理由，这个博客对于任何想要更好地了解该标准的人来说都是有价值的。这篇博客将总结我试图证明使用中证明背后的数字和方程式的经验。博客不会讨论应用路线 2 的优点S对于软件与硬件，它只看数字和数学。

图 1 - IEC 61508-7：2010 附录 D 中的相关表格。

下面给出了ISO 26262的等效项。

图 2 - ISO 26262-8：2018 中的表格

让我们从IEC 61508数字的最后一列开始，该列用于具有95%置信水平的连续或高要求安全功能。这与之前博客中关于在不同置信水平下进行可靠性预测的匹配非常相似，请参阅此处。

对于较大的 k 值，故障率可以估计为 λ = k/T，其中 k 是故障次数，T 是总操作时间。较大的值可能是 10 次或更多次失败。因此，如果您运行 100 亿小时（10000 台设备运行 1 年）并出现 10 次故障，则故障率的良好估计为 10/1e8 = 100e-9 或 100 FIT。但是，如果您遇到 0 次失败，那么您会将故障率估计为零，这是一个不太可能的值。然后需要对数据进行统计解释。

有些人喜欢使用 Θ=1/λ 而不是 λ，其中 Θ=MTTF（平均故障时间）。因此，对于 λ=100e-9，我们有 MTTF = 10 万小时。请记住，我们不希望该项目运行 10 万小时，而是表示大量单元的预期运行时间，直到其中一个单元发生故障，前提是任何项目的声明寿命都不超过 20 年。如果超过零件的速率寿命，故障率将开始急剧增加。

现在，有人比我花在数学上的时间多得多，表达式 2Tλ 是用 χ 表示的卡方分布分布的2.

我们的汽车同事说得最好，他们说

图 3 - ISO 26262-8：2018 第 14 条中所需的服务小时公式

在这个公式中

f 是观察到的故障数，在本例中我们假设为 0

CL 是所需的置信水平，我们假设为 95%

t平均时间是我们希望展示的平均失败时间

则总操作时间为t服务需要证明MTTF处于该置信度。

注意 – 如果我们使用 95% 的置信水平，那么 MTTF 的真实值大于计算的 MTTF 的置信度为 95%。

因此，让我们进行计算。理解后，您可以使用Excel为您进行数学运算，而忘记所有细节。

下表表示卡方分布。第一列显示自由度 （2f+2），第一行显示所需的置信水平。

因此，对于 f=0（零故障），我们有 DF=2，对于 95% 的置信度，我们有 p = 0.05 （1-95/100），我们从表中读取 5.991。

SIL 2 的 PFH 范围给出了每小时允许的危险故障率为 1e-6 至 1e-7。推杆 t平均时间= 1/1e-7（记住故障率为 1/t平均时间并使用波段下端的 λ 值）然后我们得到所需的小时数为 （1/1e-7）*5.991/2 = 30 万小时，这与上图 1 中的表格一致。

图 1 中的倒数第二列就很容易了。我们将 p=5.991 （0-01/1） 的值读出为 99.100，而不是 9.21，以获得所需的 46 万小时的维修间隔。

图 4 - 显示卡方分布的表格

该数学适用于任意数量的观察到的故障，并且您需要更长的观察期才能获得相同的置信度，即故障率足够低。但是，有些人认为任何系统性故障都是不可接受的，并说您应该修复故障的原因并重新开始。这些人会说使用的失败次数应该为零，因此 df = 2。我认为这种态度存在许多问题，包括难以确定该领域的失败是否是系统性的，但我今天不会进入这场辩论，因为我只是想解释这些数字来自哪里。然而，我确实注意到，虽然IEC 61508使用这种数学来证明足够的系统完整性，但我们的汽车同事只是用它来证明足够低的故障率，包括随机和系统故障模式（例如参见ISO 26262-5 5.8.3和ISO 26262-8：2018 14.2）。

上图26262所示的ISO 2数字与IEC 61508的数字不同。这是因为ISO 26262只需要70%的置信水平。因此，再次读取 df=2 和 p=1-70/100=0.3 的表格，我们得到所需的服务时间 = 1/1e-7*2.41/2 = 12 万小时。

汽车仅具有高或连续模式操作。IEC 61508的需求也很低，定义为需求率为<1 /年。为了从表5的第1列中获取值，我们现在假设需求率正好是1 /年（这是最坏的情况，即最高需求率）。假设每年 10000 小时，您只需将高需求/连续模式的 95% 和 99% 置信值除以 10000。因此，30 万小时变成了 30000 个需求。

您可能会争辩说，对给定的 SIL 使用 PFH 范围的下限是保守的，例如，当范围从 1e-7/h 到 2e-1/h 时，对 SIL 7 使用 1e-6/h。您可能会争辩说，如果您进行了定量的SIL测定并确定您需要PFH为5.3e-7 / h（在SIL 2范围内），则应使用该值代替1e-7 / h。但是，机械安全和ISO 26262通常使用风险图，并且假设危险故障率只有一个上限。相反，您也可以争辩说，标准编写者使用了给定 SIL 范围底部的值，因为所评估的元素或组件只是安全功能的一部分，因此将 10% 的预算分配给特定项目。

在功能安全标准中使用经过验证的类似概念包括

先前使用 IEC 61511

IEC 61508的现场经验

路线 2H符合 IEC 61508 标准

DO-254相关服务经验

仅依靠经过验证的使用的一些问题包括：

软件故障实际上并不取决于时间，而是取决于代码中的错误数量、代码中错误存在的位置、代码的使用方式、输入参数的顺序和可变性等因素。

日历时间与操作时间

系统级冗余可以隐藏故障

未报告低后果故障

1000 个项目运行 1000 小时真的与一个项目运行 <> 万个小时真的一样吗

并非所有现场故障都会被报告，因为与永久性硬件故障不同，它们可以迅速消失并且难以重现，我们习惯于容忍软件故障

运送的物品可以作为备件存放在仓库中

难以区分随机硬件故障和系统故障

系统故障可能只针对一组特定的输入出现。如果确实出现这些情况，故障将始终发生

系统故障是否有可接受的故障率！

在爱尔兰，至少所有投资产品广告都声明“过去的回报不是未来回报的证据”或类似的东西。但这正是您正在使用历史数据来预测未来回报的经过验证的事情。

使用卡方计算置信区间假定故障率恒定，并且故障时间呈指数分布

IEC 61508-2：2010 7.4.10 在进行验证使用时提出了额外的要求（路线 2S） 索赔。这包括例如7.4.10.3，它要求对新旧操作环境之间的任何差异进行影响分析。它没有提供任何关于可能产生影响的线索，但作为一个主要是硬件的人，我建议可能包括工作温度范围、更快的时钟速度、具有更快斜坡速率的不同电源、输入变量的不同分布......

但请记住，安全标准包含声称符合标准所需的最低要求。这听起来有点消极，但事实并非如此。这只是一个事实。因此，经过验证的使用候选者的安全案例可能包括其他内容，例如：

用于开发软件的开发过程的详细信息，即使它不是符合IEC 61508的开发过程（如果它是符合IEC 61508的开发过程，您将声明路线1S而不是路线 2S).

来自现场经验参数的信息显示设计到 10 个不同的应用程序中（这意味着由 10 个不同的团队验证并暴露于更大的输入组合）。

请记住，您的目标是让您的独立评估员更容易说“是”。您可以提供的感觉良好的信息越多（也许其他缓解措施听起来更专业），您的评估员在通常是工程判断时就会感到越高兴。

当然，您声明路线 2 的项目S通常被纳入正在根据IEC 61508开发的系统中，因此将与系统的其余部分一起进行验证和确认。这意味着至少它不应该有任何明显的错误，这些错误应该在集成过程中发现。

审核编辑：郭婷