精品译文 | 如何通过设计实现FTT

译文 如何通过设计实现FTT

原文 : How to achieve FTT by design

译文审核：卢萍

➡本文（约2300字，6钟阅读）

对于每一个安全关键系统，FTT要求由OEM指定。我们经常注意到的是，SW团队并不知道这些时间是如何实现的。他们倾向于认为，如果测试证明满足FTT时间，这就足够了。然后他们开始看到，即使系统中与安全相关的硬件或者与安全相关的软件没有改变，测试中的FTT时间测量值突然开始明显变化。在某些情况下，这些测量值超过了所需的FTT，现在团队突然想知道这是如何发生的。“我们没有改变与安全相关的软件。看起来是系统的非安全部分导致了这个变化但我们无法控制它“他们说。

如果你从ISO26262第6部分V模型的角度来看，在V的左边是架构设计，V的右边是验证和测试。

证明FTT通过测试满足的论据在V的右侧。然而，我们真正需要关注的是 v 的左侧,这就是理解设计中各种因素是如何影响 FTT 的。因此，人们不仅可以通过控制这些因素来控制FTT，而且可以设计更好的测试用例来验证FTT。

首先，让我们以一个简单的FTT需求为例

如果检测到安全输出“X”出现故障，则应在2秒内达到安全状态。

在这种情况下，安全输出是系统生成的任何与安全相关的输出。例如，它可以是数字端口输出、CAN输出、声音脉冲、图像或系统生成的软件输出。让我们假设要激活安全输出，必须满足一些输入条件，例如具有特定值的数字或模拟输入，点火状态或CAN信号值。一旦满足了这些条件，系统中的软件和硬件组件/子系统将处理这些条件并触发安全路径中的数据流，直到安全输出被激活。

图一：安全输出激活

现在，让我们假设这个路径中的一些组件是QM，可能会失败，因此系统已经实现了对实际安全输出与预期输出的监控，并在不匹配的情况下触发安全状态。监控路径和安全状态路径中涉及一系列软硬件组件。现在这个系统可以这样表示。

图二：监控概念的系统视图

在时间线视图中，该系统的FTT将如下所示：

图三：将FTT分解成更小的部分

在这种情况下，FTTI大致有3个部分：

安全输出激活时间(策略)--这是从激活安全输入条件到激活安全输出的时间。注意,由于我们现在考虑的是故障情况,我们假设即使安全输出"试图"激活,它实际上没有激活。

故障检测时间间隔（Fault Detection time interval，FDTI）--这是输出触发后可用于检测故障的实际时间。为了避免错误地触发用于短暂瞬时故障的安全状态，应通过检查实际输出的几个连续样本来确认或者排除故障。

故障反应时间(FRTI)--这是故障被确认后到达安全状态的可用时间

OEM(FTTI)给出的所需容错时间间隔-这是允许的最大容错时间,超过这个时间将出现危险,因此必须达到安全状态。

Tact  +  FDTI  + FRTI   <  FTTI

理想情况下，Tact和FRTI必须比FDTI小得多，以便系统在确认故障之前有时间读取故障输出的足够数量的样本。

我们如何在我们的系统中实现上述的时序概念？为了理解这一点，让我们将图2中的System中的SW/HW组件映射到图3中的时间线上。这看起来会像这样：

图四：将FTT时间线及其较小部分映射到图2中的System组件视图

你可能会开始看到，上图中的每一个定时组件，如Tact，FDTI和FRTI都受到各种因素的影响，如：

1. 该链中SW组件的运行时间(例如TRuntime_SW_CMP 1、TRuntime_SW_CMP 2、TRuntime_SW_CMP 1)

2. HW所需的处理时间(例如，TADC处理，TGPIO处理)

3. 该链中每个SW分量和HW分量的潜伏期(T潜伏期_SW_CMP_1_to_SW_CMP_2，T潜伏期_SW_CMP_2_to_SW_CMP_3等)   

4. 软件组件运行的任务优先级

5. 这些任务的运行频率

6. 如果激活或监视是使用中断实现的，则中断的优先级、运行时间和频率

图五：FTT的影响因子

理想情况下，你可以而且应该更深入地将Tact、FDTI和FRTI分解为这6个因素的总和。

然而，其中一些因素可能相对于其他一些因素来说是微不足道的。例如，假设Tact为20ms，该链中的2个组件的运行时间为3ms，延迟为3ms，但HW执行激活所需的时间仅为1us。在这种情况下，HW激活时间对于实现总体时序要求来说是微不足道的。

那么，我们如何设计我们的系统，以能够一致地实现FTT？

￮ 第一步是决定必须检查多少个有缺陷的样本，以确认故障。也就是FDTI。有了这个，你就可以用你的方式来确定你可以允许的最大Tact和Tfr。在某些情况下，Tact也由OEM指定。

￮ 在安全路径中设计ASIL SW组件，使其以足够高的优先级和频率运行

￮ 应该对CPU性能进行深入分析，以了解CPU的时间用到了哪里。在此基础上，应在进程定义、任务间通信方法、任务/线程的优先级、CPU间通信的优先级（如果与该系统相关）等方面进行改进，以尽量减少在安全路径的潜伏期

￮ 在FTTI计算中必须考虑最坏的HW时间。在需要激活HW输出或由HW进行监测的情况下，可能需要提供时间延迟或必须遵守HW序列

￮ 始终将系统设计为低于OEM要求的FTTI值，以防出现任何意外行为。例如，如果FTTI为2000ms，则将系统设计为1700ms或1800ms。

FTT的验证

既然我们已经讨论了如何设计我们的FTT系统，即V的左侧，让我们回到V的右侧，FTT的验证。

我们不应该把FTT验证看作是一种“要求”验证，而是一种设计验证。我们应该通过测量最坏情况下的延迟和处理时间来验证FTT是否达到。

我们应该问的问题是“最坏的情况发生在什么情况下？”

回到图5，对于影响FTT的每一个因素，都应该问这个问题：“这个SW组件什么时候会有最坏的运行时间？”“这个HW什么时候会有最糟糕状况的处理时间？”“这个SW组件什么时候会有最坏的情况延迟？”并在测量FTT时模拟这种情况。

下面是一些例子：

￮ 触发高性能和/或硬实时需求场景，并让它们满负荷运行。

￮ 如果安全路径中的两个微控制器或两个硬件IC之间有通信，则在此路径中创建满负荷流量，以便尽可能延迟安全数据的传输。

￮ 模拟创建尽可能高的中断流量的场景

结论

我们以FTT要求的一个具体例子来解释基本原则。系统中的FTT要求可能有所不同。例如，您可能需要FTT来检测内存或CPU故障等微故障，其中您没有我们在上面的示例中提到的策略激活时间。然而，如何设计FTTI系统的基本原理是相同的。关键的信息是-不要让满足FTT要求的机会溜走！“我测试了FTT的时间，它在规定的范围内”不是一个充分的论据。FTT必须非常有意识地通过深入到安全路径中的每一个SW/HW组件，并考虑它们最坏的执行时间和延迟来设计。通过在设计阶段进行深入的检查，可以为FTTI提供最坏的测试场景，即可以创建最坏的延迟和最坏的运行时间，并在这些条件下度量FTT。

文章转载自公众号：Sasetech