鉴源实验室 | AUTOSAR E2E：车载通信的安全保障

作者 | 沈平 上海控安可信软件创新研究院汽车网络安全组

来源 | 鉴源实验室

社群 | 添加微信号“TICPShanghai”加入“上海控安51fusa安全社区”

随着汽车行业逐步走向电气化、智能化，车载系统的软件和硬件复杂度不断上升。如何确保这些复杂系统中的数据通讯安全和可靠，已成为业界关注的焦点。E2E（End-to-End）通讯常常指的是一个信息从发送端到接收端的完整传输过程，保障通讯中数据的完整性与安全性。AUTOSAR (AUTomotive Open System ARchitecture) 是一个全球汽车工业的标准化项目，旨在为嵌入式汽车软件创造一个共同的标准。在AUTOSAR架构中，软件被分为三个主要层次：应用软件 (ASW, Application Software)，基础软件 (BSW, Basic Software)，以及运行时环境 (RTE, Runtime Environment)。E2E通常是在ASW层实现的，它确保应用级的数据通信在发送和接收时的完整性。图1所示为在AUTOSAR架构中E2E保护示例图。在图1中E2E能够减轻BSW层软硬件以及ECU之间网络通讯的故障。

图1 通过E2E保护减轻故障的示例图

功能安全是关于硬件和软件系统在出现故障时仍然保持安全状态的能力。在车载系统中，例如ISO 26262标准定义了如何评估和确保汽车电子/电气系统的功能安全。当进行功能安全评估时，可以考虑E2E保护作为降低数据通信相关风险的一个措施。

E2E之所以能够保证一定程度的功能安全是因为E2E保护的目标是确保数据在传输过程中的完整性，避免由于噪声、干扰或软件错误导致的数据损坏或失真。它包括两大核心要素：

1. 通过计算和验证校验和或CRC（循环冗余校验），确保数据在传输过程中没有被篡改或损坏。如果一个关键系统（例如制动系统或转向系统）收到了损坏或篡改的数据，它可能会做出不正确的决策，从而导致功能失效甚至危险情况。E2E保护通过确保数据完整性来减少这种风险。

2. 通过顺序计数器（Counter）来确保消息按预期的顺序到达，能够检测丢失的消息或重复的消息。如果接收端的计数器值与预期不符，这可能是由于消息丢失或者重复。对于某些功能安全关键的应用，如自动驾驶或紧急刹车，如果系统收到的数据是间断的，可能会导致不适当或延迟的响应。

接下里将结合AUTOSAR官方文档中的E2E Profile 1例子，具体阐述E2E是如何工作的。

E2E Profile 1由以下四个组件构成：

• CRC：循环冗余检查。Profile 1通常使用一个8位的CRC，采用CRC-8-SAE J1850-0x1D多项式计算。

• Counter：计数器在每次消息发送时增加。对于Profile 1，这通常是一个4位的值，这意味着它的范围是从0到14。当达到最大值后，计数器会回绕到0。

• Data ID：用来唯一标识数据元素或消息的标识符。对于Profile 1，这通常是16位的值，用来参与计算CRC，但不会进行实际的数据传输。

• Timeout monitoring：超时监控是由E2E管理模块对counter的值计算得到。

需要注意的是E2E保护中的CRC不同于CAN或者FlexRay通讯协议的CRC校验。其中CAN或者FlexRay通讯协议的CRC是由通信控制器中的硬件支持提供，并不是由E2E管理模块生成的。E2E保护中的CRC是CAN或者FlexRay通讯协议中传输的数据段内容。另外Counter的值是0到14，值15是用来表示错误的。

在AUTOSAR 官方文档中E2E Profile 1对于CRC以及Counter是可以自定义其起始位置的，在本文中将CRC起始位置定义为bit 0且长度为8，Counter起始位置定义为bit 8，且长度为4。如图2所示。

图2 E2E保护报文矩阵示意图

CRC的计算过程中，一般会对整个报文传输的数据进行校验。其中未使用的bit位用0xFF代替。根据图2报文矩阵定义，CRC的计算如图3计算示意图所示，在图3中CRC计算的结果填充在了报文的第一个Byte，Counter值填充在了报文第二个Byte的低位。

图3 CRC计算示意图

E2E保护的工作原理，作为发送端需要对每一条消息增加顺序计数器的值，使用Data ID、Counter以及传输数据计算CRC，将Counter和CRC添加到消息中并发送。作为接收方使用接收到的Data和Counter计算CRC，检查计算出的CRC是否与接收到的CRC匹配，检查Counter值以确定消息的连续性。如果在接收端CRC不匹配，这意味着数据可能已经被损坏。根据系统的需求，可以选择触发一个错误报告或者采取其他的错误处理措施。如果Counter值不是预期的（例如，如果它比上一条消息的值小），这可能意味着消息是过时的或者已经被重复。同样，可以根据具体情境进行处理，如丢弃数据或者触发一个警告。对于Counter校验机制如图4所示。

图4 counter校验机制

在图4中，会根据配置的参数对counter进行校验，配置项包括允许最大的丢帧的数量，允许重复的计数器的数量等。通过对计数器的校验，会导致8种E2E状态：

• E2E_P01STATUS_OK：Counter计数器正确并且CRC校验正确。

• E2E_P01STATUS_NONEWDATA：一个报文周期内未接收到该E2E报文。

• E2E_P01STATUS_WRONGCRC：CRC校验失败。

• E2E_P01STATUS_SYNC：在收到期望之外的Counter后，收到了一个正确的CRC与合理的Counter。

• E2E_P01STATUS_INITIAL：初始化阶段。

• E2E_P01STATUS_REPEATED：收到的Counter是重复的。

• E2E_P01STATUS_OKSOMELOST：接收到的E2E报文连续两帧之间的Counter差值大于1但小于MaxDeltaCounterInit。

• E2E_P01STATUS_WRONGSEQUENCE：接收到的E2E报文连续两帧之间的Counter差值大于MaxDeltaCounterInit。

以上，本文对E2E保护机制的核心概念以及实现原理进行了简单的阐述。如果想对E2E保护机制在AUTOSAR中如何进行配置，需要进一步阅读AUTOSAR官方文档。

参考文献：

AUTOSAR.(2022).E2E Protocol Specification. AUTOSAR Standard Working Specification.

AUTOSAR.(2022).pecification of SW-C End-to End Communication Protection Library. AUTOSAR Standard Working Specification.