AUTOSAR的E2E通信安全

导语：近期项目中遇到一些E2E的诊断故障，涉及到整车需求和AutoSAR配置，对这个概念重新做了下梳理，与大家交流。由于E2E机制比较成熟，本文章内容更多出自于AutoSAR标准、ISO 26262 和相关文献，这里只捡重点和个例对这个概念做下解读。

1. 什么是E2E？

2. 为什么要做E2E？

3. 怎么做E2E？

4. 常用的保护形式有哪些?

5. E2E状态机与配置参数

1. 什么是E2E？

首先明确一点，E2E并非只是在汽车领域应用，任何通信领域都会涉及，只不过是AutoSAR对这一协议/机制做了规范。

E2E，全称End to End，中文即端到端的通信保护，是一种针对安全相关数据，为防止通信链路中可能存在的故障（HW/SW）， 在 通信节点 之间 执行的 一种数据保护协议/机制。其适用于多种网络结构：CAN、 CANFD、FlexRay、Ethernet等。

具体，如下图所示,假设有两个ECU： ECU1和ECU2，两节点之间通过CAN总线通信，ECU1要将某一安全信号传输至ECU2，如果采用E2E profile1保护协议（AutoSAR E2E Library），ECU1在对必要信息数据做传递之外，还要补充CRC和Counter信息给至ECU2，ECU2在接收到这帧数据后，会计算CRC，然后与接收到的进行比较，ECU2会根据校验结果执行下一步动作（这就涉及到故障的处理，之前有做过简要概述，可参见文章《 电动汽车动力系统的"望闻问切" | 故障诊断 》）。

不知道是否注意到，所谓的E2E其实是对两个关键对行为的保护：发送端（sender）和接收端（receiver）。标准中定义如下：

E2E所涉及的所有保护机制都围绕这两个行为展开的。

2. 为什么要做E2E？

通过上述简介，可以get到，E2E保护概念的核心是针对安全相关的数据交换，需要在运行时进行保护，以消除通信链路中可能的失效带来的影响，这就是为什么要做E2E的本质原因。另外，E2E也是汽车动力系统实现ASIL D的必要手段。

那么，数据交换过程中可能的失效模式 有哪些呢？关于这个问题ISO26262 中有总结，如下:

● 信息的重复发送 (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外设的通信，基于数据总线的通信等等。产生失效的原因包括系统性失效与随机失效，在软件端面，如生成代码过程中的错误，手动编码引入的错误，网络协议栈的错误等等；硬件端面，如处理器的故障，网络硬件的故障，电磁辐射等等。

3. 怎么做E2E?

AutoSAR中有对E2E Library 的定义，其中提供了多种用于E2E保护的函数供选择，每种profile都有自己特定的机制、参数和数据格式，用户可以根据需求选择。无论何种profile，基本可分为以下两步骤：

Step1： 发送端通过增加控制字段拓展数据结构，控制字段一般包含：checksum、counter等，扩展处的字段由RTE进行发送，如下图所示：

Step2： 接收端对上述整个字段内的数据进行验证，如果pass，则移除其中控制字段，并将应用数据交给SWCs处理；如果no pass，则执行安全保护机制。

那么，在具体对profile做配置时，常用的保护保护形式有哪些呢?

Adaptive autosar E2E保护是一种针对安全相关数据，为防止通信链路中可能存在的故障，在通信节点之间执行的一种数据保护协议/机制¹²。其适用于多种网络结构：CAN、 CANFD、FlexRay、Ethernet等¹。

Profile 4 、Profile 5、 Profile 6、 Profile 7、Profile 11是不同的E2E保护配置，每种profile都有自己特定的机制、参数和数据格式，用户可以根据需求选择¹²。

它们主要的区别如下：

Profile 4：支持最大4KB长度的消息，使用16位CRC校验和，8位计数器，16位数据ID和长度字段²。

Profile 5：支持最大256字节长度的消息，使用8位CRC校验和，4位计数器，16位数据ID³。

Profile 6：支持最大4KB长度的消息，使用32位CRC校验和，8位计数器，16位数据ID和长度字段³。

Profile 7：支持最大256字节长度的消息，使用8位CRC校验和，4位计数器，16位数据ID和8位数据长度³。

- Profile 11：支持最大4KB长度的消息，使用64位CRC校验和，8位计数器，16位数据ID和长度字段³。

由于Profile 4 和Profile 7 支持可变数据长度，因此必须指定最小和最大数据长度属性。

相比之下，Profile 5 支持固定数据长度要求，因此只应填充“数据长度”属性。

(1) 电动汽车动力总成解读 | E2E通信保护 - 知乎 - 知乎专栏. https://zhuanlan.zhihu.com/p/340894620.

(2) 功能安全专题之端到端(E2E) 的通信保护 - CSDN博客. https://blog.csdn.net/coroutines/article/details/106799892.

(3) 【AUTOSAR-E2E】-2.2-配置E2E：基于E2EPW配置一个TX发送的Signal Group（使用E2E Profile 2）. https://blog.csdn.net/qfmzhu/article/details/122401741.

E2E保护对性能有一定的影响，主要体现在以下方面：

• - E2E保护需要额外的数据字段，如CRC校验和、计数器、数据ID等，这会增加数据包的长度和传输时间¹²。
• - E2E保护需要在发送端和接收端进行计算和校验，这会增加处理器的负载和功耗¹²。
• - E2E保护需要在应用层和通信层之间增加一个保护层，这会增加软件的复杂度和开发成本¹²。
• 因此，在选择和配置E2E保护时，需要根据不同的应用场景和安全需求，权衡性能和安全性的平衡。

(1) Specification of SW-C End-to-End Communication Protection Library - AUTOSAR. https://www.autosar.org/fileadmin/standards/R4-0/CP/AUTOSAR_SWS_E2ELibrary.pdf.
(2) Energy : Energy : Hitachi Review. https://www.hitachi.com/rev/archive/2021/r2021_03/04/index.html.
(3) HSM firmware: Functional safety starts in the hardware security ... - ETAS. https://www.etas.com/en/company/news-hsm-firmware-functional-safety-starts-in-the-hardware-security-module.php.

4. 常用的保护形式有哪些呢？

这里对profile中提到的一些保护机制做下解释。

CRC

循环冗余校验，是一种根据网络数据包或文件等数据简短固定位数校核码的快速算法，主要用来检测或校验数据传输或保存后，可能出现的错误，利用除法及余数的原理。

此外，ISO26262-5 中明确说明CRC的覆盖率主要取决于报文长度、CRC字段大小和多项式形式，详情可参见ISO26262文档。

特别说明，我们习惯说“CRC checksum校验”，其实这里涉及两种校验方法。

Checksum

顾名思义，和的校验，在数据处理和数据通信领域中，用于校验目的的一组数据项的和，这些数据项目可以是数字或在计算校验总和过程中看作数字的其他字符串，其类型有多种：XOR checksum, 1's complement Checksum, 2's complement Checksum等。

Counter

在报文中占4bit，范围0~14 (profile1)，用于计数，发送端每发送一帧报文，计数+1，ECU1将计数值发给ECU2，ECU2对收到的counter进行比较，确认是否及时接收，当达到14，重新开始计数。

Timeout

通过counter来评估报文是否丢失、延迟等。

Data ID

一般为2个byte，是ECU1和ECU2之间提前定好的特殊字段，AutoSAR profile1中对E2E_P01DataIDMode定义几种模式：BOTH、ALT、LOW、NIBBLE，Data ID用于报文checksum，但是特别注意的是这一段DID并不作为报文传输数据的一部分放在总线上，仅仅作为报文密钥，这就好比特务接头，开始聊正文之前，总要私下先确认好暗号，以证明“我接收的指令确实是期待的发送方所发送的”。

特别说明下增加Data ID字段的报文如何计算checksum：

例如，Autosar E2E profile 1 规定采用CRC-8-SAE J1850 ，对应多项式为0x1D (x8 + x4 + x3 + x2 + 1)，通常情况下报文数据场中Byte0 用于存放报文CheckSum 数据，byte 1~byte7 存放报文其它数据，报文数据场存放数据下图所示。

具体步骤如下。

Step1：计算Data ID字段内CRC值 （注：实际初始值为初始值取反）。

Step2：计算Byte1~Byte7字段内CRC值（注：实际初始值为上一步校验值取反）。

Step3： 将上一步校验值取反，得到最终值。

以下是AutoSAR中针对profile1保护机制的原始定义，供参考：

5. E2E状态机与配置参数

E2E数据的接收是周期性的，接收方在每个周期内，调用对应的profile的检测接口，针对接收到的数据进行检测，验证这个周期内接收到的数据是正确的，并提供额外信息说明检测到的失效形式。下图给出了状态及迁移的说明，从中可以看到数据是否有用是根据窗口期内error数和ok数来做判断。

那么，E2E保护需要的配置参数有哪些呢？

以AUTOSAR E2E Protocol Specification1.3.0 为例，目前E2E中系统支持配置的设置信息如下图所示：

以上就是对E2E概念和保护逻辑做的简要介绍，它是汽车动力总成实现ASIL D的必经之路，更多内容大家感兴趣可以直接查看标准《AutoSAR E2E Protocol Specification》。

【Reference】

《AutoSAR E2E Protocol Specification》

《ISO 26262 - "Road vehicles - Functional safety"》

AUTOSAR标准的安全通信为支持功能安全，AUTOSAR标准结合ISO 26262功能安全标准，在基础软件层从安全执行、安全通信以及安全内建测试三个方面做出了规范，并规范了使用方法，
本文主要介绍其安全通信部分。

1.安全通信组成部分
为了支持安全通信，AUTOSAR提供了三种机制，

1.     数据顺序控制
2.     PDU复制和K/N的投票
3.     端到端的保护

数据顺序控制在COM中实现
PDU复制和N分之K（简称K/N）的投票机制涉及到COM和PduR模块
端到端的保护机制借助于端到端保护库（E2E库）来实现

1.1 COM模块
COM模块为应用程序提供基于信号的数据服务接口，并根据信号自身预定义的发送类型来发送报文。

COM模块还提供了附加的服务接口可用于检测是否成功发送报文、成功接收报文以及报文是否超时等。对于多个通信通道的ECU，本模块还提供了一个用于不同通信总线之间的信号路由即信号网关的功能。
同时，为了支持安全通信，本模块提供了两种机制，数据顺序控制和K/N的投票机制来增强通信的安全。

1.2 PduR模块
PduR模块主要提供两类服务：
承上启下衔接上层和下层：

发送时派发从高层模块的PDU到低层模块，并支持上层到下层的1对多映射即多播机制；

接收时派发从底层模块如If或者TP接收的PDU给高层模块（COM，PduR）。

通信网络中的网关功能：

网关功能有两种：

从一个接口层到另外一个相同或者不同总线类型的接口层；

从一个TP到另外一个相同或者不同总线类型的TP层。

其中，路由协议基于一个静态的路由表和PDU ID的概念。

1.3 E2E保护库

E2E是一个端到端的通信保护库，只依赖于循环校验（简称CRC）库。为确保软件的开放分层，应当考虑如下的通信故障检测：

1) 点对点通信的丢帧。
2) 无意义的重复发送相同的消息。
3) 发送过程中的消息丢失。
4) 接收到伪装正确源地址的消息。
5) 接收到的消息序号和发送的消息序号不一致。
6) 消息在传输过程中损坏。
7) 未在指定的时间内接收到消息。
8) 防止数据总线被错误节点过度请求服务。
9) 一个故障节点的损坏导致整个总线的故障。

E2E支持的通信故障源包括：
1）软件故障
例如COM通信协议栈和RTE的软件模块，因为系统性质本身可能包含隐藏的错误。系统故障可能发生在规范、设计、制造、操作、维护的任何阶段的系统生命周期。他们出现的情况总是相同的(如触发源的条件)。软件故障可能会导致中断通信，接收溢出，发送空消息等。为防止软件故障的产生，应当采取适当的程序监控或E2E技术措施进行检查和处理是必要的。

2）硬件随机故障
硬件随机故障通常源自硬件电气过载，退化，老化或受外部条件(例如环境压力)影响。一个硬件随机故障不能完全避免，但其概率可以通过适当的技术措施(例如诊断)评估。

3）外部环境因素
这些因素包括电磁干扰(EMI)，静电放电(ESD)，空气湿度，腐蚀，温度，机械应力(如震动)等等。

2.安全通信关键技术

本章分别介绍SmartSAR Core在AUTOSAR的安全通信实现中，采用的三个关键技术，分别是数据顺序控制机制、PDU复制和K/N的投标机制、端对端的保护机制。

2.1 数据顺序控制机制

AUTOSAR COM模块基于PDU计数器提供了数据顺序控制机制，乱序的PDU，比如重复的或者在丢失的PDU之后接收到的PDU就能被检测出来并丢弃。这种机制需要发送端和接收端配合使用。

1）发送端

在发送端，对于配置了计数器的PDU，在COM初始化时或者PDU组以TRUE的方式启动时设置计数器为0。以后，在每次发送PDU之前，都会递增这个计数器。如果调用PduR的向下发送服务返回失败，则执行减一操作，也就是对于一个PDU每成功发送一次，则对这个它的顺序控制计数器执行加一操作。

2）接收端

在接收端，对于配置了计数器的PDU，在COM初始化时或者PDU组以TRUE的方式启动时设置计数器为0。以后，无论顺序计数器的值怎样，都应接受到来PDU。一旦接受一个包含顺序计数器的PDU，COM模块应设置下一个期待的值为接收到的计数器的下一个值。

如果一个顺序计数器是4位的，它有从0到15这16个可能值。如果一个接收到一个PDU，并且接收到的计数器是15，则下一个期待的值应为0。不论接收到的值是否和实际期待的值相等，新的期待的值都应被更新。

接收到一个包含顺序计数器的PDU时，COM应先设置下一个期待的值，然后丢弃这个PDU，当且仅当这个PDU符合以下条件：
收到的PDU的顺序计数器小于期待的PDU计数器，或者接收到的PDU顺序计数器大于期待的PDU计数器和一个配置的容错阈值的和。

如果发生顺序计数器不匹配，COM可以调用这个PDU的一个回调函数来通知用户。

PDU顺序计数器是4位，配置的容错阈值为1，则匹配情况如下表 1所示。

表 1 顺序计数器为4位，容错阈值为1的样例表

2.2 PDU复制和K/N的投票机制

安全相关的PDU可能需要在下层被复制来防止数据的损坏或丢失。在AUTOSAR中，PDU的复制在PduR中以多播的形式来实现。复制的PDU的比较和投票机制在COM中实现。由于复制的PDU没有校验或者签证以供比较使用，就需要在接收方存储并比较整个PDU。

1）发送端
在发送端，只需要在PduR中为对应的PDU配置多播路径即可。但是，必须要确保复制的PDU配置有顺序计数器，为了在接收端基于顺序计数器来进行投票。
对于K/N的投票机制，应确保复制N份PDU发送出去。

2）接收端

在接收端，负责对接收到的复制的PDU进行投票，并只向RTE传递成功发送的一直的PDU的消息。复制的PDU要配置有顺序计数器。然而，建议配置容错阈值为0，避免情况太复杂。
对于K/N的投票机制，至少接收到相同的K份数据才保证数据是可靠的，才能提交这个PDU的消息给RTE。

2.3 端到端的保护机制

端到端的保护需要发送端和接收端的配合使用才能检查出错误。
发送端的流程如图 1所示。

首先，PDU的发送方初始化配置结构体和状态结构体；

然后用最新的信号的值更新PDU，取得PDU的数据；根据这些参数调用E2E_PXXProtect，执行E2E的逻辑，加入CRC校验信息，加入数据计数器信息，最后把数据一起发送到总线上。其中CRC校验信息可用来检查一位到两位错等硬件错误，数据计数器信息可以辅助检查到顺序出错等问题。


图 1 E2E的发送方
接收端的流程如图 2所示。

首先，PDU的接收方初始化配置结构体和状态结构体；

然后接收PDU，取得PDU的数据；根据这些参数调用E2E_PXXCheck，执行E2E的逻辑，检查CRC校验信息，检查数据计数器信息，如果都没有错误才把收到的PDU中的数据提交给应用。

其中CRC校验信息可用来检查一位到两位错等硬件错误，数据计数器信息可以辅助检查到顺序出错等问题。



图2 E2E的接收方