ISO26262 Part6 之 免于干扰FFI

1. 标准要求

在Annex D中，有解释避免软件要素之间的相互干扰，主要包括三块：

• Timing and execution 时序和执行
  • —死锁;
    —活锁;
    —执行时间的不正确分配;或
    —软件要素间的不正确同步。
• Memory 存储
  • —内容损坏;
    —数据不一致(例如,由于数据获取期间发生更新);
    —堆栈上溢或下溢;或
    —对已分配给其他软件要素的内存进行读或写访问。
• Exchange of information 信息交换

2. 详细要求

2.1 免受空间干扰

免受空间干扰意味着一个软件分区不应该更改另一个软件分区的代码或数据，换句话说，软件设备之间的内存和存储应该是分开的，否则，代码和数据可能会损坏

加入读取，写入和执行权限

想想软件分区之间的关系是一种信任，高级设备不信任任何低级设备，所以ASIL D可以从QM设备中读取，然而ASIL D设备应该尽可能减少QM设备的读数，ASIL D设备也可以写入QM设备，但QM设备却只能读取ASIL D设备，关键设备不应写入较高的ASIL设备。

同样，如果QM设备能够执行由ASIL D设备提供的功能，但是ASIL D设备不会信任QM功能，并且不执行QM功能。

同样，如果QM设备能够执行由ASIL D设备提供的功能，但是ASIL D设备不会信任QM功能，并且不执行QM功能。

举一个具体的例子，如果QM设备中的软件漏洞错误地为ASIL C分区创建指针地址会发生什么？QM设备可能会写入一个ASIL C设备，这可能会导致违反安全目标，所以我们应该阻止或检测它。

2.1.1 免受空间干扰的安全机制

• MPU
  MPU是一种预防方法，因为它阻止元素访问它们不应该访问的内存。可以对MPU进行编程，以便在软件元素之间设置正确的读、写和执行权限。

• 双重存储
  类似与2的补码是一种检测方法。使用2的补码，您可以检测到数据已经更改并且不再有效。但是你不能再使用这些数据了。

其他防止记忆干扰的机制包括:

• 冗余检查，如CRC，以确保数据不会意外更改。
• 具有内存错误检测和校正功能的微控制器
• 允许软件单元拥有自己的虚拟内存空间的操作系统

提到的一种机制是存储2的补码的安全相关数据。2的补码是二进制中表示负整数的一种方法。

CRC(循环冗余检查)是一种检查数据在传输过程中是否发生了更改的方法。它们的工作方式是向数据添加一个附加值，然后确保该值在传输过程中没有发生变化。

请注意，对于解决死锁，禁用会停止进程抢占的OS中断是低效的，并且可能会影响总体响应时间和系统延迟。另一种选择是由实时操作系统(RTOS)提供的Priority ceiling protocol。

In real-time computing, the priority ceiling protocol is a synchronization protocol for shared resources to avoid unbounded priority inversion and mutual deadlock due to wrong nesting of critical sections. In this protocol each resource is assigned a priority ceiling, which is a priority equal to the highest priority of any task which may lock the resource. The protocol works by temporarily raising the priorities of tasks in certain situations, thus it requires a scheduler that supports dynamic priority scheduling.[1]

2.2 免受时间干扰-Part1

Part 1 针对死锁 和 活锁
时间干扰是指随着时间的推移一个设备阻止另一个设备的执行。

例如，如果两个软件设备共享数据，更高优先级的线程可以连续访问数据，低优先级的线程则会一直等待，这被称为阻止执行。

当两个执行线程需要彼此资源时，会发生死锁。线程1拥有资源A需要资源B，线程2拥有资源B需要资源A。

类似的干扰被称为Livelocks，两个线程想要相同的资源，在这种情况下，两个线程都有礼貌地让其他线程先行，但它们会搁置一边，然后同时获取资源。

时间干扰的另一个例子是软件系统之间的不正确同步。例如，考虑一辆自主车辆，有用于车辆检测的雷达系统和相机系统，每个系统都有自己的问题，但是如果有问题的时钟不能正确同步，那么传感器融合就无法完成。因为随着时间的推移将无法压缩信号。


当发生任何时间或执行人相关的故障时，需要采取安全机制，这可能是功能退化，并最终过渡到安全状态以避免安全目标违规。

2.2.1 解决死锁

有多种算法可以避免死锁，包括一种称为禁用中断的措施。当中断被启用时，一个进程可以中断另一个进程。在我们的例子中，线程1需要资源B，并试图获取A，但是线程2不断中断线程1来获取A。禁用中断将允许线程1获取A。

2.2.2 免受时间干扰-Part2

此部分针对 时间不正确的分配 和 不正确的执行顺序；

这些类型的时间干扰的发生条件为软件系统提前执行，推后执行或执行时间太长。功能安全标准建议三种不同的机制用于处理执行时间和执行顺序的故障，它们能实时监督，监测截止期限和控制流量。

所有这三种机制都与查验点一起协作。软件系统会在执行开始和结束时报告其状态.

现场监督会限制给定时间段内软件系统的执行次数，当达到查验点时，系统会分析系统执行的次数。

截止日期监控考察软件系统执行需要多长时间，如果某个系统耗时过长，则会发生错误。

最后，控制流监控确保软件进度按正确的顺序进行，例如，执行顺序可能无序或软件系统在顺序中间执行而非在开始时执行。

独立的软件块将包括在系统架构内用于分析查验点，如果发生违反安全目标的故障那么系统应该转换到安全状态。

2.3 免受通信干扰

我们要讨论的最后一个干扰源是通信干扰,在车辆系统中软件设备需要交换电子控制单元之间的信息.即使发送者和接收者的ASIL相同,也有必要防止干扰.软件系统之间的通信渠道往往会有较低的ASIL或QM评级，受保护的通信通道将检测数据传输错误；

确保免受通讯干扰的最常见机制之一，被称为 E2E 或者端对端协议，E2E 协议可以帮助防止由于硬件，软件和电磁干扰导致的通信下降。该协议检查数据在传输过程中是否损坏，这样当数据损坏可能违反安全目标时，车辆可以被引导至安全状态。

2.3.1. 通讯干扰的常见原因

造成通信故障的原因有很多。这些原因将在软件安全分析或有时在技术安全分析中进行分析:

• Repetition of information（重复的信息）
  Loss of information （信息丢失）
  Delay of information （延迟的信息）
  Insertion of information （插入的信息）
  Masquerade or incorrect addressing of information （伪装或不正确的信息寻址）
  Incorrect sequence of information （信息序列不正确）
  Corruption of information （污染的信息）

2.3.2 保障通讯不受干扰的其他机制

有一些方法可以避免通信干扰。这些机制可以用来定义有助于避免通信错误的软件安全需求。确保不受干涉的机制包括:

• Loopback of information （信息回环）
  Acknowledgement of information （信息确认）
  Appropriate configuration of I/O pins （I/O引脚的适当配置）
  Bus arbitration by priority （优先级总线仲裁)
  E2E protocol （E2E协议）

例如，一项技术安全要求是“确保‘LDW_Torque_Request’信号数据传输的有效性和完整性”。该技术安全要求可以细化为软件安全要求，即数据应受End2End机制的保护。

8.5.4. E2E保护协议示例规范
下图显示了E2E协议的示例。

该机制涉及在传输数据时添加两个额外的数据字节，称为CRC(循环冗余检查)和SQC(序列计数器)。

要计算CRC，需要对要传输的数据运行一个数学公式。然后在传输之前将CRC结果附加到数据上。当接收到数据时，再次对数据集运行数学公式。数据所附的CRC值与接收端计算的CRC值相同;否则，数据数据可能在传输中已损坏。
SQC只是一个与数据一起发送的计数器。这样接收者可以确保消息没有丢失。

参考引用

以上文章引用自
https://github.com/Dongkesi-2019/Functional-Safety-Notes/blob/master/Ch8-Safety-Mechanism.md