ISO 26262 FunctionalSafetyConcept（肆-02）

上一篇我们梳理了一些安全机制，并尝试逐一解释，本期衔接上一篇内容，继续解释剩余的安全机制。一起来学习吧！

本篇和上一篇的连接比较紧密

01

安全机制解释

Substitute Values（可替代值）

figure1： the rear wing angel of attack

当变量中的错误值被检测到时，我们可以使用替代值机制。然后将变量的值替换成为另外一个值，该值可以使将要执行的操作呈现有效的结果，比如默认值或者最后接受的值，但是结果的质量可能会差一些。替代值仅掩盖错误，因为它不能提供导致错误值的故障的恢复。由于要替代的变量高度依赖于环境（此处是context），因此该机制是特定于应用程序的。

figure2： angle of attack configuration

注意，值115错误地保存在存储器中；检测到此错误是因为后翼子板的高度与其倾斜角度（线性关系）之间的关系，从而产生高下压力将轮胎夹在地面上以增强转弯。在检测到斜率误差时，“替代值”机制应使用先前正确的参数。也就是说，它会对系统功能进行降级，如图中绿色值（92，20）。

在我们应用了故障处理机制之后，我们再来看下原来的曲线关系：

figure3： angle of attack configuration ＋substitute by values mechanism

Voting（表决）

当我们使用表决时，会执行多个冗余软件的副本，然后对不同执行的每个执行结果进行表决。表决算法的例子是简单多数（simple majority）和三取二（2 out of 3），他们通常在一个特殊的表决组件（voter component）中实现。表决也支持恢复，因为即使存在错误，也可以提取出正确的值。

figure4： voter examples

Agreement（协议／同意）

组件可以通过交换本地版本的值来决定／商定要使用的值。与表决不同的是，组成部分一起做出决定，而不是由一个单独的组成部分来做出决定。也就是说，交换本地计算的结果，提高系统的可靠性。假设Y功能块是ASIL，X功能块是QM，那么Y可以和X功能块交换本地的内部数据（housekeeping data），这样X功能块就可以在输出错误的数据之前处理元数据（meta data）。

figure5： agreement examples

Checksum／Codes（校验和／代码）

校验和／代码机制通过添加额外的信息来检测数据在传输过程中的篡改。也就是说，校验和是保护两个功能块接口的安全机制。有时还可以恢复错误的数据值并将其恢复到原始状态。小提示：比如ECC算法可以修正1bit的错误，检测2bit的错误，超过2bit的错误不一定可以检测出来。

figure6： checksum examples

Execution Sequence Monitoring（执行时序／序列监控）

执行序列监控检测执行是否可能导致错误的执行路径。可以检测由数据错误、定时错误或不对称错误引起的程序流错误（Program Flow Errors）。监控器本身无法确定是哪一个导致了错误。正确的执行顺序由开发人员配置。配置包含一组检查点／监控点的定义，对于每个这样的点，都有一组允许的后续点。每个检查点都将被报告给看门狗管理器（Watchdog manager），然后它来检查执行的时间和逻辑顺序。

Aliveness Monitroing（活力／活性监控）

此机制检测不活动的单元，这也就意味着他们不会按照周期来执行。这可以通过心跳检测来完成，心跳是一种应该定期发送的信号。活力监控技术有两种：

心跳（Heartbeats）

方形信号将周期性地从客户端发送到主机，如果配置超时后，并且主机侧没有接收到信号，则主机会将客户端标记为关闭。－－＞检测（detection）

两个函数之间的活计数器（Alive counter between two function blocks）

数据选通脉冲编码（Data strobe encoding）

选通信号与数据信号是相反的。它将用于验证两个功能块之间发送数据的正确性。也就是说，通过异或（XOR）（数据，选通）它来产生时钟信号。

Status and Mode Management（状态和模式管理）

状态和模式管理使用元信息来调查系统，以便把有缺陷的组件进行隔离。为了支持这种机制，应用程序级组件必须能够访问元信息。

信号状态（Signal status）：信号质量，信号时间戳和更新信息；

例如：speed＿val ＝ 120而speed＿quality ＝ LOW＿Confidence，因此由于信号质量的置信度较低，我们将放弃speed＿val；

设备状态（Device status）：应用软件想知道传感器、执行器的状态（如果传感器不正常运行，应用软件会降级服务）；

车辆模式（Vehicle mode）：正常运行，停车，跛行，应用程序将相应行动；

例如：speed＿val ＝ 120而Vehicle＿mode ＝待机，因此我们将放弃speed＿val，因为车辆模式与此速度值不一致；

ECU模式（ECU mode）：一个ECU可能处于不同的状态，如休眠、运行、关机。

Reconfiguration（重新配置）

当检测到错误时，此机制可以用于配置系统不使用错误的组件。也可以将系统设置为降级模式，并且只提供有限的一组服务。重新配置通常使用静态策略来进行控制，如关闭和打开点火钥匙。

Reset（重启）

重启可以在不同的级别进行，例如应用程序重置和ECU重置。复位只能处理瞬时故障，因为在重启后永久性的故障仍然是存在的。比如：

软件组件复位；

应用程序复位；

ECU 复位；

如果上述操作失效，请转到恢复机制来更改配置。

Error Filtering（错误过滤器）

错误过滤用于防止在恢复操作器件将系统设置为比以前更不安全的状态。瞬时误差和永久误差的鉴别：弹跳机制（Bouncing mechanism）；计数器（Counter）。也就是说，为了防止系统将故障／滞后作为系统的稳定有效输入输入到系统中。因此，保护系统免受假阳性或者假阴性的影响。

使用故障过滤机制，瞬时故障的过滤如下图所示：

Memory Protection（内存保护）

内存保护用于保护内存不受在不同内存区域之间传播的错误的影响。为了相互保护应用程序，定义了分区来创建错误限制区域。我们将使用MPU（内存分区）来保护ASIL内存不被QM访问。

Timing Protection（超时保护）

超时保护的目的是保护系统不受需要太多时间才能完成的活动的影响，从而妨碍其他任务的执行。它可用于检测应用程序是否已超过其时间段。它是一种全局超时管理器，用于监控所有任务，以检查哪些任务妨碍了系统。也就是说，如果任务处于就绪状态，或者根据我们的设计选择，可以将其设置为休眠。