本文来自AUTOSAR技术资料。
前言
功能安全（Functional Safety）是一项系统特性，由于基于功能安全的设计会影响到系统设计，所以从系统开发初始阶段就要进行考虑。由于软件的复杂度会影响 到功能安全的设计，所以在AUTOSAR规范中，包含了部分与功能安全相关的需求，这些新技术和概念能够帮助降低功能安全相关组件的复杂度。不过需要强调的是，AUTOSAR虽然通过提供安全措施和机制来支持基于功能安全产品开发，但这些独立的安全措施（Safety Measure）并不能形成整体的安全解决方案。
在功能安全标准（ISO 26262 2018, Part 6）中，提到了要避免软件相关元素之间干扰（Freedom from Interference between software elements）。软件之间的相互干扰主要集中在软件的执行时间（Timing），软件间的死锁（Dead locks，Live locks），内存使用（Memory），信息交换（Information Exchange）。
本文主要介绍一下AUTOSAR规范中对于端到端(下称E2E)通信的保护措施。
1 失效模式
在一个分布式的系统中，如果系统的功能安全依赖于数据的完整性，那么发送方(Sender)和接收方(Receiver)之间的数据交换就可以对系统的功能安全造成影响。根据ISO 26262 Part 6的附录D，数据交换过程中，可能存在的失效模式有如下几种：
- 信息的重复发送 (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)，信息的内容被篡改
- 向多个接收方发送非对称信息 (Asymmetric information sent from a sender to multiple receivers)，接收方者收到的数据不一致
- 仅部分接收方收到发送者的信息 (Information from a sender received by only a subset of receivers
- 阻塞通信通道 (Blocking access to communication channel)
这些失效可能发生的数据交换的场景包括，与I/O外设的通信，基于数据总线的通信等等。产生失效的原因包括系统性失效与随机失效，在软件方面，如生成代码过程中的错误，手动编码引入的错误，网络协议栈的错误等等；硬件方面，如处理器的故障，网络硬件的故障，电磁辐射等等。
E2E保护的概念是假设安全相关的数据交换，需要在运行时进行保护，以消除通信链路中可能的失效带来的影响。
2 E2E通信安全机制介绍
从软件组件(SWC)的角度来看，通过RTE进行的通信就像是俩个不同的端点(End)之间的简单通信。但是这个级别的抽象是基于复杂的机制包括多个软件层次，通信协议栈，驱动和底层硬件。
E2E通信的要点在于标准化安全机制的保护能力与灵活性。接下来我们讨论下E2E保护如何应用到ECU内部与ECU之间的通信的。
首先，发送者一方扩展用于封装应用数据的数据结构，增加控制字段，即E2E Header。这些控制字段通常包括校验和(Checksum)，计数器(Counter)和其它的一些配置选项。扩展出来的字段也交由RTE进行发送，如下图所示：
然后，在接收方验证包括这些控制字段在内的应用数据。如果验证成功，则这些控制数据则被移除，并将应用数据交由软件组件处理。错误处理也由接收方执行。
2.1 E2E的可选配置(Profiles)
AUTOSAR指定了一系列的标准化及可配置的E2E配置，每个配置实现了一系列的安全机制，并且指定的对应的E2E控制字段的格式。
任一E2E配置使用的都是如下的保护机制的一部分：
- CRC校验和，基于AUTOSAR CRC Library
- 连续计数器(Sequence Counter)，每个数据包，连续计数器都会增加，其值会在接收方进行检查是否正确的增加
- 心跳计数器(Alive Counter)，每个数据包，心跳计数器都会发生改变，接收方会验证数值是否发生变化，但变化的范围不做检查
- 针对每个通信端口特定的通信ID，全局唯一，即使系统包括多个ECU的情况下
- 超时检测，检查接收方的通信超时(Communication Timeout)和发送方的确认超时(Acknowledgement Timeout)
AUTOSAR中指定了3种E2E的配置，Profile1, 2和4，不同的AUTOSAR供应商还会提供其它的Profile。如Profile 1的E2E配置如下：
| Mechanism | Description | Fault Model |
|---|---|---|
| Counter | A 4Bit Counter is incremented with every Send-Request. This Value is explicitly sent. | Repetition, deletion, insertion, incorrect sequence |
| Timeout | Using a non-blocking read, the receiver can determine if the value of the counter has been increased. | Deletion, delay |
| Data ID | Each sender-receiver port has a unique 16-Bit ID, which is used in the CRC calculation. | Insertion, addressing faults |
AUTOSAR E2E Profile 1和2由于CRC字段长度的限制(8 bit)，所以Profile 4通过增加CRC字段长度，支持到最大4KB长度的消息，如下图所示：
由于引入的长度字段，Profile 4支持的E2E消息保护的长度与Profile 1, 2不同，是可变的。
2.2 E2E的状态机系统
E2E数据的接收是周期性进行，接收方在每个周期内，调用对应Profile的检测接口针对接收到的数据进行检测。检测结果验证这个周期内接收到的数据的正确性，并可以提供额外的信息用于说明检测到的失效。
AUTOSAR目前的E2E中的状态机系统支持配置的设置信息，如丢失的数据包个数，重复的包个数，可修复、不可修复的通信错误及通信的初始化动作。下图给出了状态及迁移的说明：
2.3 集成E2E库文件
AUTOSAR中的E2E保护以库的形式使用，因此存在多种使用的方式。AUTOSAR标准中，以附录的形式提供了一种E2E Protection Wrapper （E2EPW)的封装。目前，AUTOSAR中的E2E保护，只支持通过RTE基于Sender/Receiver的形式使用，其它种类的接口类型仍在定义中(如，基于Client/Server的接口)。因此，E2EPW接口封装了RTE的Read/Write接口，用于向软件组件提供方便的数据发送与接收接口。E2EPW是单独的软件组件，需要向供应商购买。在E2EPW的方案中，功能安全相关的软件组件额外增加了一个软件层次，用于封装E2E库中的接口及RTE接口，如下图所示：
需要注意的是E2EPW接口并非通用接口，每一个使用E2EPW接口的软件组件，都需要通过工具配置针对本组件一种通信类型的E2EPW接口。同时，为了避免非功能安全软件组件的影响，在同非功能安全组件通信时，最好也使用E2EPW封装的接口。
2.4 E2E Transformer
针对使用仅符合QM要求的通信协议栈进行的安全通信，AUTOSAR标准提供了E2E Transformer (E2eXf)的组件用于支持配合实现安全通信。E2eXf负责触发E2E Library，隐藏掉E2E Library的复杂性（如，E2E相关检查和状态机维护）。E2eXf需要和ComXf和SomeIpXf配合使用，在通信协议栈中的位置如下所示：
3 检测和响应
E2E Library在AUTOSAR中，作为标准的支持库来实现。发送方需要在发送数据之前，通过E2E Library来对数据增加保护；接收方收到数据后，通过E2E Library对收到的数据进行运行时检测。使用E2E Library时，检测到的通信失效通知给接收方。
4 限制条件
- 仅使用E2E Library并不能达成系统的功能安全要求，只有证明了基于E2E的安全机制达成的必要的覆盖率才可以（如，硬件的失效率，Bit错误率，网络的结点数量，消息的重复率等等）
- 基于RTE的软件组件之间的通信比仅仅点对点的通信要复杂，如RTE中的数据转换(Data Conversion)错误，过滤(Filtering)，通知信息的丢失(Missing Notification)等等，需要追加额外的机制才能达成安全要求
- 在ECU内的所有组件上使用E2E保护，可能导致运行时的性能问题。同时，对于Profile 1和2来说，Data ID个数的限制可能导致数据的仿冒
- E2E通信不支持时间戳(Time Stamp)机制，因此数据的到达时间可能不精确