一文读懂AUTOSAR_E2E模块

mizhongquan

0 前言





本文对AUTOSAR E2E模块做简要说明。在E2E的实现中，有E2E Profile1, E2E Profile2, E2E Profile4, E2E Profile5, E2E Profile8, E2E Profile11, E2E Profile22, E2E Profile44等多种配置方式，本文仅详细分析 E2E Profile1，其他的配置方式基本原理与E2E Profile1大体一致，读者可自行查阅AUTOSAR标准了解详情。

本文的出发点是帮助读者快速理解AUTOSAR E2E模块的基本概念，协助读者在实际工程中快速部署和应用E2E模块。AUTOSAR E2E模块内容繁多，涉及知识面广，由于笔者水平有限，难以将AUTOSAR E2E模块相关规范的精华内容一一详述，建议读者自行阅读相关规范内容。

本文预期读者：AUTOSAR E2E模块开发人员,测试人员。

                  

1 E2E基本概念







1.1 功能安全对信息交换的需求及E2E模块概述



AUTOSAR中的E2E模块全称为End-to-End Communication Protection，直译是端到端通信保护。为何会有这样一个模块出现，它的作用又是什么？

由于各种客观因素限制，在ECU的产品生命周期（设计、制造、操作和维护等阶段）总有无法避免的故障因素存在。例如随机的硬件失效、EMC干扰等。我们把ECU之间的通信、ECU内部不同模块之间的通信看做一个“功能”，则这种通信功能当然也会由于外界的干扰因素而产生失效。如果通信数据未加任何保护，则通信数据内容完全是不受控的。例如对于接受方来说，没有任何方法获知数据有无被“意外篡改”。

在系统运行时，SWC之间进行数据交换时，引起信息交换相关的故障来源包括：

1）（系统级）软件故障：类似通信堆栈模块和RTE可能包含有系统性的故障。

2）（随机）硬件故障：随机硬件故障通常是硬件部件的电气过载、退化、老化或暴露于外部影响的结果。随机硬件故障不能完全避免，但可以评估其概率，并可以实施适当的技术措施（如诊断）。
3）外部干扰引起的瞬态故障：包括EMI、ESD、湿度、腐蚀、温度或机械应力（如振动）等影响。


通信故障来源示意图

         

在功能安全规范中，对软件失效范围的定义包括：1）时序和执行；2）内存；3）信息交换。E2E针对的就是其中的“信息交换”。需要注意的是，E2E只能检测出通信数据的失效，对失效状态的处理，由应用SW-C进行。

关于信息交换，需要考虑如下所列各故障类型：

1）Repetitionof information（信息重复）：信息被接收到不止一次。

2）Loss of information（信息丢失）：信息或部分信息从传输的信息流中删除。

3）Delay of information（信息延迟）：接收到的信息晚于预期。

4）Insertionof information（信息插入）：将附加信息插入到所传输的信息流中。

5）Masquerading（信息伪装）：非真实信息被接收者接受为真实信息。

6）Incorrect addressing（信息的不正确寻址）：信息从错误的发送方发送或被错误的接收方接收。
7）Incorrect sequence of information（信息次序不正确）：修改传输信息流中的信息顺序。
8）Corruption of information（信息损坏）：信息被改变内容。

9）Asymmetric information sent from a sender to multiple receivers（从发送方传送到多个接收方的信息不对称）：多个接收方从同一发送方接收到不同的信息。

10）Information from a sender received by only a subset of the receivers（发送方发送的信息只能被部分接收方接收）：部分接收方没有接收到信息。

11）Blocking access to a communication channel（通信信道阻塞）：对通信通道的访问被阻塞。

         

为了检测出信息交换中的各种失效状态，AUTOSAR提出了E2E机制，通过对通信数据增加DataID、CRC、Counter等控制字段，使得软件可以在运行时检测和处理通信链路故障。

E2E保护可以实现：

1）通过附加的控制数据来保护要通过RTE发送的安全相关的数据元素（data element）。

2）通过控制数据来验证从RTE接收到的安全相关的数据元素。

3）当接收到的安全相关的数据元素发生错误时，可以发出通知并由相关的SWC处理。

         

为了理解E2E的基本原理，以E2E Profile1为例介绍E2E机制。

首先需要了解E2E提供的机制：

Mechanism	Description
Counter	4bit长，需要显示发送（即在发送的数据内容中需要体现），取值范围0-14。
Timeout monitoring	通过评估Counter来判断超时（Timeout）。E2E监督者（Supervision）通过E2E_P01CheckStatusType中的标志位向调用方（caller）通知超时。
Data ID	16位长的唯一编码，用于CRC计算。 当dataIdMode为0,1,2时，Data ID不会显式传输，但会通过CRC隐式传输。 当dataIdMode为3时： lDataID的高字节的高4位不使用（值为0x0），DataID为12位长 lDataID的高字节的低4位被显式传输，且计算CRC时也需要代入计算内容 lDataID的低字节不会被显式传输，但会通过CRC隐式传输（与dataIdMode为0,1,2时一样）
CRC	使用CRC-8-SAE J1850 - 0x1D (x8 + x4 + x3 + x2 + 1)，start值和XOR值均为0x00。

         

该机制可以检测到以下故障：

E2E机制	可检测的通讯故障
Counter	Repetition：信息重复 Loss：信息丢失 insertion：信息插入 incorrect sequence：信息次序不正确 blocking：通信信道阻塞
Transmission on a regular basis and timeout monitoring using E2E-Supervision	Loss：信息丢失 delay：信息延迟 blocking：通信信道阻塞
Data ID + CRC	Masquerade and incorrect addressing：信息伪装/信息的不正确寻址 insertion：信息插入
CRC	Corruption：信息损坏 Asymmetric information：从发送方传送到多个接收方的信息不对称

         

对于发送方来说，需要填写counter，计算CRC等信息。对于接收方来说，需要对接收到的数据进行CRC校验，判断counter连续性等。

可以看出，E2E的机制，是针对功能安全中信息交换的失效模式来设计的。例如：使用counter，可以识别出：Repetition（信息重复）故障。比如接收方连续接收到两个相同的counter，那明显是数据发送重复，也就是“信息重复”故障。再例如使用Data ID + CRC，因为Data ID一般不显式传输，其信息包含在CRC中。那么如果接收方接收到的CRC校验有误（虽然数据内容相同，但CRC不同，那可能是Data ID不一致导致的），则可以判断为可能是Data ID错误的失效。也即可以识别出“信息伪装/信息的不正确寻址”这两种失效模式。

也就是说，E2E的机制设计，是针对功能安全中信息交互的需求来设计的，是为了满足能够检测出信息交换的11种失效模式来针对性设计的！

         

E2E机制提供了一种检测信息交换故障的方法，当接收方接收数据后检测到失效发生时，可以由SW-C进行功能安全相关处理。

为了方便读者快速理解E2E中CRC, counter等机制，下一节以一个简单的例子说明E2E中的CRC计算方式、counter监测等重要内容。



1.2 E2E Profile1计算/校验示例说明



本节以一个示例快速说明E2E Profile1中的部分概念。

注意，E2E规范中定义了E2E Profile 1, E2E Profile 2, E2E Profile 4, E2E Profile 5, E2E Profile 6, E2E Profile 7, E2E Profile 11, E2E Profile 22及其对应的变体。下文以E2E Profile1为例简要说明E2E机制。



1.2.1 发送方的E2E计算



以发送方发送CAN报文时计算CRC为例。

首先要理解“信号组”的概念。OEM给的dbc文件中，可能会包含功能安全相关的信号，功能安全相关的多个信号会被编为一组，每组都会有DataID。注意这些“信号组”会被排布在CAN报文中，一个CAN报文中可以有多个信号组。

每个信号组，会有其独立的DataID, CRC, Counter。需要注意的是，根据DataID Mode的配置，DataID可能并不在CAN报文的数据内容中体现。
下面以E2E Profile1A的一种可能的配置为例，CAN报文的数据布局可能为：


该示例中报文MyMsg包含两个信号组，其DataID分别为0x0006, 0x0007.

CRC在信号组的第1个字节，Counter在信号组的第2个字节的低四位。每个信号组长度为8个字节。

有了以上信息后，就可以计算E2E中的CRC值了。按Data ID模式的不同，有不同的计算方法，关于Data ID模式的详细信息，见1.2.3节。

下面以E2E Profile1A为例（Data ID Mode为E2E_P01_DATAID_BOTH）：

Data ID的两个字节数据在计算CRC时都需要包含在内，低字节在前，高字节在后。紧接着Data ID的数据为信号组中除了CRC的其他数据。



在计算出CRC后，将CRC值填入信号组数据中的CRC的位置。

这样即完成了一次E2E的计算。
每次调用接口进行E2E处理时，需要对counter加1处理（事实上这儿的代码实现可能略有不同，但为方便理解，可以暂时这么认为），counter最大值为14。



1.2.2 接收方的E2E校验



接收方在接收到数据后，即可进行CRC计算。通过比较CRC的计算结果与发送方发送的CRC是否一致，可以判断出Corruption（信息损坏）、Asymmetric information（从发送方传送到多个接收方的信息不对称）、Masquerade and incorrect addressing（信息伪装/信息的不正确寻址）、insertion（信息插入）的失效。

通过判断counter是否连续，可以判断出Repetition（信息重复）、Loss（信息丢失）、insertion（信息插入）、incorrect sequence（信息次序不正确）、blocking（通信信道阻塞）的失效。

判断出失效发生后，SW-C即可进行相应的功能安全处理。



1.3 E2E Profile 1简介





本节介绍E2E Profile1的基本概念。



1.3.1 E2E Pforile1机制







1.3.1.1 数据布局




在遵循以下两个原则的基础上，数据布局由用户自由定义：

l长度小于8的信号，应该被分配各一个I-PDU的一个字节，即该信号不能跨越两个字节

l长度大于等于8的信号，占据一个消息的字节开始或者结束的位置。

怎么理解其中的第二条？个人理解是，以CAN报文为例，如果一个信号的长度大于等于8，则它的起始或结束位，应该在某个字节的第8位，或者第0位。
类似于这样的布局是合理的：


但这样的布局就违反了第二条原则：



E2E Profile1的变体中，定义了关于协议数据字段的特定数据布局。



1.3.1.2 Counter



对于发送方（sender），设置Counter的初值为0，在发送数据时，每次递增1，最大值为14，即应跳过15这个值。

对于接收方，通过对比当前接收到的counter和之前接收到的counter，可以检测到以下情况：1）自启动E2E检查功能后，没有收到新的数据；2）自receiver启动后，没有收到新数据；3）数据重复；4）counter增加1（即无数据丢失）；5）counter增加大于1，但仍在允许范围内（部分数据丢失）；6）counter增加超过允许范围（即丢失数据过多）。
怎么理解其中的case5、case6两项？在E2E的配置参数中有这样一个参数：maxDeltaCounterInit，这个参数值定义了最大容忍的丢帧数。例如，如果maxDeltaCounterInit配置为1，则最大能容忍丢1帧报文。如果上一次接收到的counter是4，那么如果当前接收到的counter是5（没有丢帧）或6（丢了1帧，在容忍范围内），则仍然认为是OK的，也就是case5的情况。如果当前counter是7或更大的值，则表示丢了2帧或更多，超过容忍范围，就是case 6的情况。
Case3对应失效的alive counter检查。Case6对应失效的sequence counter检查。



1.3.1.3 Data ID



以CAN报文为例，功能安全相关的一组信号，应该被编入到一组数据中，并且给出相应的Data ID值。

以实际的CAN报文举例：



该CAN报文中的信号被编为两组，DataID分别为0x0006和0x0007.

DataID是唯一的。

         

在计算CRC时，需要将DataID作为计算数据。有下面4种情况：

1）Data ID Mode为E2E_P01_DATAID_BOTH时：DataID都要计算CRC，低字节在前，高字节在后。
2）Data ID Mode为E2E_P01_DATAID_ALT时：当counter是偶数时，计算CRC时包含低字节；当counter为奇数时，计算CRC时包含高字节。
3）Data ID Mode为E2E_P01_DATAID_LOW时：高字节未使用，计算CRC时包含低字节。注意此时DataID长度为8 bits。

4）Data ID Mode为E2E_P01_DATAID_NIBBLE时：

lDataID高字节的高4位未使用，DataID长度为12 bits。

lDataID高字节的低4位被显示传输（在报文中需要包含该数据），且在计算CRC时需要计算DataID高字节的低4位。

lDataID低字节不被显示传输，在计算CRC时需要包含。

当Data ID Mode为E2E_P01_DATAID_BOTH或E2E_P01_DATAID_ALT时，DataID是16位长。

当Data ID Mode为E2E_P01_DATAID_LOW时，DataID的高字节应被设置为0x00.

当Data ID Mode为E2E_P01_DATAID_NIBBLE时，DataID的高字节的高4位设置为0x0. DataID长度为12位。

         

注意，这儿容易混淆的是E2E_P01_DATAID_NIBBLE模式。下面举个例子说明：

假设信号组的DataID是0x3456，Data ID Mode为E2E_P01_DATAID_NIBBLE，CAN报文数据内容布局是:


则用于计算CRC的数据内容是：


也即是：





1.3.1.4 CRC计算



E2E Profile1使用函数Crc_CalculateCRC8 ()来计算CRC

下面是两个计算示例。

         

E2E Profile 1A，计算CRC时，包含DataID，以及所有的报文数据（除了CRC字节）内容。



E2E Profile 1C，计算CRC时，包含DataID，以及所有的报文数据（除了CRC字节）内容。注意这种情况下Data ID Mode为E2E_P01_DATAID_NIBBLE。



         

计算CRC的数据是这样排布的：首先是DataID，然后是除了CRC外的所有安全相关的数据元/信号组。



1.3.1.5 超时检测



接收方可以通过前述的机制检测超时（timeout）。
1.3.1.6 E2E Profile 1变体

E2E Profile1中有三个变体，也就是在E2E Profile1的基础上，规定好了一些配置项。

E2E Profile 1A

1）CRC在信号组的第0个字节；

2）Alive Counter在第1个字节的低4位；

3）E2E_P01DataIDMode = E2E_P01_DATAID_BOTH；

4）SignalIPdu.unusedBitPattern = 0xFF。即未使用的bit位均置1.

E2E Profile 1B
1）CRC在信号组的第0个字节；
2）Alive Counter在第1个字节的低4位；

3）E2E_P01DataIDMode = E2E_P01_DATAID_ALT；

4）SignalIPdu.unusedBitPattern = 0xFF。即未使用的bit位均置1.

E2E Profile 1C

1）CRC在信号组的第0个字节；

2）Alive Counter在第1个字节的低4位；

3）DataID的nibble在第1个字节的高4位；

4）E2E_P01DataIDMode = E2E_P01_DATAID_NIBBLE；

5）SignalIPdu.unusedBitPattern = 0xFF。即未使用的bit位均置1.

         

注意，在实际的工程应用中，要注意下未使用的bit位实际是被置1还是置0。不过一般来说，并不影响CRC的计算。



1.3.2 E2E_P01 Protect



信息发送方需要调用E2E_P01Protect()来进行计算CRC、处理counter等E2E保护动作。

函数E2E_P01Protect()应当实现：

1）在数据中写入counter；

2）如果DataID Mode配置为了E2E_P01_DATAID_NIBBLE，在数据中写入DataID nibble；

3）计算CRC；

4）在数据中写入CRC；
5）counter递增1（以供下一次调用E2E_P01Protect()时使用）。




1.3.3 E2E_P01 Forward



函数E2E_P01Forward()根据ForwardStatus的值来计算E2E的header数据：

         

当ForwardStatus为E2E_P_OK时：

1）向数据写入counter；
2）如果配置了E2E_P01_DATAID_NIBBLE模式，向数据写入DataID nibble；
3）根据DataID和数据计算CRC；

4）向数据中写入CRC；

5）counter递增1（以供下一次调用E2E_P01Forward()时使用）。

         

当ForwardStatus为E2E_P_REPEATED时：

1）counter递减；

2）向数据写入counter；

3）如果配置了E2E_P01_DATAID_NIBBLE模式，向数据写入DataID nibble；

4）根据DataID和数据计算CRC；

5）向数据中写入CRC；

6）counter递增1（以供下一次调用E2E_P01Forward()时使用）。

         

当ForwardStatus为E2E_P_WRONGSEQUENCE时：

1）计算：Counter = Counter + MaxDeltaCounterInit

2）向数据写入counter；

3）如果配置了E2E_P01_DATAID_NIBBLE模式，向数据写入DataID nibble；

4）根据DataID和数据计算CRC；

5）向数据中写入CRC；

6）counter递增1（以供下一次调用E2E_P01Forward()时使用）。

         

当ForwardStatus为E2E_P_ERROR时：

1）计算：DataID = DataID+1；

2）向数据写入counter；
3）如果配置了E2E_P01_DATAID_NIBBLE模式，向数据写入DataID nibble；
4）根据DataID和数据计算CRC；

5）向数据中写入CRC；

6）counter递增1（以供下一次调用E2E_P01Forward()时使用）。


注意，ISOLAR生成代码中未找到E2E_P01Forward()接口。



1.3.4 E2E_P01 Check



信息接收方接收到数据后，调用E2E_P01 Check()对数据进行校验，此处的“校验”不仅包括CRC校验，还包括counter的检查等。根据校验结果，确定E2E检查状态。

函数E2E_P01Check()应当：

1）检查CRC；

2）检查Data ID nibble（如果配置了E2E_P01_DATAID_NIBBLE）；

3）检查counter；

4）确定检查状态。

         

Profile1检查状态结果：

Name	Status	Description
E2E_P01STATUS_OK	OK	自上次接收到数据以来，没有任何数据丢失，且CRC校验正确。
E2E_P01STATUS_NONEWDATA	Error	检查函数已被调用，但自上次调用以来没有新的数据。因此，没有执行对数据的E2E检查。
E2E_P01STATUS_WRONGCRC	Error	已经收到数据，但有两种情况导致该状态：1.CRC校验错误；2.DataID的高字节的低4位数据错误。（如果配置了 E2E_P01_DATAID_NIBBLE）
E2E_P01STATUS_SYNC	Not Valid	在检测到计数器的意外行为后，已收到了新的数据。对于最近接收到的数据，数据具有正确的CRC和计数器，但计数器的连续性检查尚未最终确定。
E2E_P01STATUS_INITIAL	Initial	新数据已根据通信介质接收，CRC是正确的，但这是自接收机初始化或重新初始化后的第一个数据，因此计数器还不能被验证。
E2E_P01STATUS_REPEATED	Error	收到新数据，CRC正确，但counter与上一次收到的相同。
E2E_P01STATUS_OKSOMELOST	OK	丢失了一部分数据，但仍在忍受范围内。
E2E_P01STATUS_WRONGSEQUENCE	Error	丢失了过多的数据，超过了忍受范围。

         
E2E_P01Check()完整流程图如下，为了方便分析，后文会对该流程图的拆分流程图做分析：


E2E_P01Check流程图（完整版）

E2E_P01Check流程图为：



E2E_P01Check流程图
E2E_P01Check的形参有三个：
1）Config：配置参数。

2）State：当前状态。

3）Data：待检查的数据。

E2E_P01Check流程主要有几个分支：

1）分支一：① → ② → ③ → ⑩

2）分支二：① → ② → ④ → ⑨

3）分支三：① → ② → ④ → ⑤ → ⑪

4）分支四：① → ② → ④ → ⑤ → ⑥ → ⑦ → ⑫

5）分支五：① → ② → ④ → ⑤ → ⑥ → ⑧

下面分别介绍几个分支的流程：

分支一

①：State->MaxDeltaCounter++，最大值14。

②：判断是否有可检查的新数据。

③：没有可检查的新数据，进入E2E_P01_process_NoNewOrRepeatedDataCounter子流程。

·E2E_P01_process_NoNewOrRepeatedDataCounter子流程将：        
         State->NoNewOrRepeatedDataCounter++

⑩：State->Status赋值为E2E_P01STATUS_NONEWDATA。

         

分支二

①：State->MaxDeltaCounter++，最大值14。

②：判断是否有可检查的新数据。
④：判断接收到的counter是否小于15。
⑨：接收到的counter大于15，counter值不合理（最大为14），直接退出，返回值为E2E_E_INPUTERR_WRONG。

         

分支三

①：State->MaxDeltaCounter++，最大值14。

②：判断是否有可检查的新数据。

④：判断接收到的counter是否小于15。

⑤：接收到的counter小于15，进入E2E_P01_CRCAndDataIDNibble子流程。在该子流程中，会计算CRC值（如果配置了DataID Mode为E2E_P01_DATAID_NIBBLE，还会检查数据内容中的DataID的高字节的低四位值）并检查CRC值是否正确。

子流程E2E_P01_CRCAndDataIDNibble在此不详细分析，详见AUTOSAR规范文件《E2E Protocol Specification》R23-11章节6.5.3.1。

⑪：在⑤中校验出CRC结果有误，说明传输的数据不正确，设置State->Status= E2E_P01STATUS_WRONGCRC。

         

分支四

①：State->MaxDeltaCounter++，最大值14。

②：判断是否有可检查的新数据。

④：判断接收到的counter是否小于15。
⑤：接收到的counter小于15，进入E2E_P01_CRCAndDataIDNibble子流程。在该子流程中，会计算CRC值（如果配置了DataID Mode为E2E_P01_DATAID_NIBBLE，还会检查数据内容中的DataID的高字节的低四位值）并检查CRC值是否正确。        
⑥：判断是否是首次收到数据。
⑦：是首次收到数据，进行数据赋值：

·State->WaitForFirstData = FALSE

·State->MaxDeltaCounter = Config->MaxDeltaCounterInit

·State->LastValidCounter = ReceivedCounter

⑫：将State->Status赋值为E2E_P01STATUS_INTIAL。

         

分支五

①：State->MaxDeltaCounter++，最大值14。

②：判断是否有可检查的新数据。

④：判断接收到的counter是否小于15。

⑤：接收到的counter小于15，进入E2E_P01_CRCAndDataIDNibble子流程。在该子流程中，会计算CRC值（如果配置了DataID Mode为E2E_P01_DATAID_NIBBLE，还会检查数据内容中的DataID的高字节的低四位值）并检查CRC值是否正确。        
⑥：判断是否是首次收到数据。

⑧：不是首次收到数据，进入E2E_P01_process_counter子流程。

         
下面分析E2E_P01_process_counter子流程，流程图为：


E2E_P01_process_counter流程图

该流程有3个分支：

1）分支一：① → ② → ③ → ④

2）分支二：① → ② → ⑤ → ⑥ → ⑦

3）分支三：① → ② → ⑤ → ⑧

下面分析三个分支：

分支一

①：计算DeltaCounter。
②：判断DeltaCounter是否为0。
③：DeltaCounter为0，进入E2E_P01_process_NoNewOrRepeatedDataCounter子流程。        
   ·在该子流程中，进行：State->NoNewOrRepeatedDataCounter++（最大值为14）。



E2E_P01_process_NoNewOrRepeatedDataCounter流程图

④：设置State->Status值为 E2E_P01STATUS_REPEATED。

         

分支二

①：计算DeltaCounter

②：判断DeltaCounter是否为0

⑤：DeltaCounter不为0，继续判断DeltaCounter是否大于State->MaxDeltaCounter。
⑥：DeltaCounter大于State->MaxDeltaCounter，进入E2E_P01_handle_wrongSequence子流程。        
   ·在子流程E2E_P01_handle_wrongSequence中，进行如下处理：


E2E_P01_handle_wrongSequence流程图

注意，这儿的处理逻辑可能存在这样的问题：
按E2E规范的设计，设置SyncCounter为0，其本意应该是进入WrongSquence的状态后，保持在WrongSquence状态，且不更新State->LastValidCounter，直到数据发送方发送了正确的counter后，才恢复到OK的状态。
但存在一种应用场景：假设如果配置的MaxDeltaCounter值为1，SyncCounterInit为0.数据发送方发送的是周期性CAN报文。假设数据发送方某次发送的数据中的counter为2，下一次发送的数据中的counter为5，则数据接收方进入WrongSquence状态。且由于SyncCounterInit为0，所以数据接收方的State->LastValidCounter不更新，保持为2。

此时数据发送方继续周期性发送报文，其之后发送的报文counter分别为：6, 7, 8, 9, 10, 11, 12, 13, 14, 0, 1, 2, 3...

注意，当counter为6 ~ 1时，数据接收方的状态仍然保持在WrongSquence。当counter为2时，数据接收方状态切换到Repeated。当counter为3时，数据接收方状态切换到OK。

在这种场景下，实际上数据并没有正常恢复，但最终状态也仍然切换到了OK。且接收方的状态实际上保持了相当长时间的WrongSquence。按SyncCounter为0的设计初衷而言，也许是在数据接收方进入WrongSquence后，不进行数据同步，而是需要等待数据发送方重新发送counter为3的数据？但在上述的场景下，显然不太符合一般逻辑和工程常理。

在设计SyncCounterInit值时，应格外注意分析设置该值为0的各种场景！

         

⑦：设置State->Status值为E2E_P01STATUS_WRONGSEQUENCE。

         

分支三

①：计算DeltaCounter

②：判断DeltaCounter是否为0
⑤：DeltaCounter不为0，继续判断DeltaCounter是否大于State->MaxDeltaCounter。
⑧：DeltaCounter小于State->MaxDeltaCounter，进入E2E_P01_handle_ok_and_okSomeLost子流程。        
   E2E_P01_handle_ok_and_okSomeLost子流程见下图，该子流程又有几个分支：

1）① → ② → ③

2）① → ④ → ⑤ → ③

3）① → ④ → ⑥ → ⑦
4）① → ④ → ⑥ → ⑧


E2E_P01_handle_ok_and_okSomeLost流程图

下面分别分析几个分支：

分支①→ ② → ③：
①：计算DeltaCounter
判断State->NoNewOrRepeatedDataCounte大于Config->MaxNoNewOrRepeatedData。

②：对State->SyncCounter赋值为Config->SyncCounterInit（开启同步计数）

清零State->NoNewOrRepeatedDataCounte（因为已经收到有效数据了）

③：设置State->Status值为 E2E_P01STATUS_SYNC。（进入同步状态）

         

分支① → ④ → ⑤ → ③：

①：计算DeltaCounter

判断State->NoNewOrRepeatedDataCounte小于Config->MaxNoNewOrRepeatedData。

④：判断State->SyncCounter大于0（说明同步过程还未结束）

⑤：State->SyncCounter--

③：设置State->Status值为 E2E_P01STATUS_SYNC。（保持在同步状态）

         

分支① → ④ → ⑥ → ⑦：

①：计算DeltaCounter

判断State->NoNewOrRepeatedDataCounte小于Config->MaxNoNewOrRepeatedData。

④：判断State->SyncCounter小于0（说明同步过程已结束）

⑥：判断DeltaCounter等于1

⑦：设置State->Status值为 E2E_P01STATUS_OK。

         

分支① → ④ → ⑥ → ⑧：
①：计算DeltaCounter
判断State->NoNewOrRepeatedDataCounte小于Config->MaxNoNewOrRepeatedData。

④：判断State->SyncCounter小于0（说明同步过程已结束）

⑥：判断DeltaCounter不等于1

⑧：设置State->Status值为 E2E_P01STATUS_OKSOMELOST。（数据丢失一部分但仍在忍受范围内）

         

怎么理解“同步过程”？在发生丢失数据过多，超过上限值时，E2E会进入E2E_P01STATUS_WRONGSEQUENCE的状态。此时如果再有新的数据达到，需要先进行数据同步，同步完成后才能再次判断数据的连续性。

例如配置的MaxDeltaCounterInit为2，SyncCounterInit为3。当接收到的数据counter值分别为0,1,2,6时，则在收到counter为6的数据时，会判断当前的DeltaCounter > MaxDeltaCounterInit，E2E进入E2E_P01STATUS_WRONGSEQUENCE状态。

此时又来了新的数据，counter值分别为7,8,9,10...则收到counter为7,8,9的数据时，E2E状态为同步状态E2E_P01STATUS_SYNC，当收到counter为10的数据时，E2E的状态恢复到正常状态E2E_P01STATUS_OK。
个人理解这类似于一种保护恢复机制。当发生过了数据sequence错误时，即使新来的数据的counter恢复了连续性，也不能立即认为数据连续性就OK了。必须当连续来的n个数据的counter都是正常的，才认为数据sequence已恢复正常。打个不恰当的比方，就像是某人曾经犯过事进去过，刚从监狱放出来，大家对他还抱有怀疑态度，你在监狱里改造好了吗，你已经变成一个好人了吗？当他连续几年表现良好，不仅好好工作，还经常扶老奶奶过马路，大家心里有谱了，嗯，他确实变成一个好人了。那么到底连续几年才能给他恢复正名呢？这个时长就是SyncCounterInit。



1.4 E2E状态机



前文1.3.4节中的E2E_P01Check()接口，是对单个周期内的数据进行检查并确认状态。E2E状态机则可根据接收窗口内Check()的多个结果确定状态，并反馈给上层应用。

E2E状态机适用于所有的E2E Prifole。E2E状态机可以通过参数disableEndToEndStateMachine来使能/不使能。（在ISOLAR中是E2ERbStateMachine）

注意状态机根据参数TransitToInvalidExtended的不同值表现略有区别。下面分析TransitToInvalidExtended==0的状态机（R19-11及之前版本），TransitToInvalidExtended==1的情况与之相似，不再详细分析。



1.4.1 E2E状态机概述



状态机概要图如下图所示。E2E状态机有4中状态：

1）E2E_SM_DEINIT：初始状态。

2）E2E_SM_NODATA：未收到数据。

3）E2E_SM_INIT：初始化状态。

4）E2E_SM_VALID：数据有效状态。
5）E2E_SM_INVALID：数据无效状态。




E2E state machine overview -[TransitToInvalid==0]

         

状态机详细跳转关系图如下图所示。

分析其中的跳转关系：

1）E2E_SM_DEINIT → E2E_SM_NODATA：        
       调用E2E_SMCheckInit()后，即从E2E_SM_DEINIT跳转到E2E_SM_NODATA。
2）E2E_SM_NODATA → E2E_SM_INIT：        
       收到有效数据后，从E2E_SM_NODATA跳转到E2E_SM_INIT。
3）E2E_SM_INIT → E2E_SM_VALID：        
       满足条件：State->ErrorCount小于等于Config->MaxErrorStateInit 且 State->OkCount大于等于Config->MinOkStateInit。

4）E2E_SM_INIT → E2E_SM_INVALID:         
       满足条件：!(State->ErrorCount小于等于Config->MaxErrorStateInit 且 State->OkCount大于等于Config->MinOkStateInit)后，         
       满足条件：State->ErrorCount大于Config->MaxErrorStateInit。

5）E2E_SM_VALID → E2E_SM_INVALID:         
       满足条件：!(State->ErrorCount小于等于Config->MaxErrorStateValid 且 State->OkCount大于等于Config->MinOkStateValid)。
6）E2E_SM_INVALID → E2E_SM_VALID:         
       满足条件：(State->ErrorCount小于等于Config->MaxErrorStateInvalid 且 State->OkCount大于等于Config->MinOkStateInvalid)


E2E state machine check -[TransitToInvalid==0]
简要理解上述状态机的逻辑跳转关系就是，有两个计数器：OkCounter，ErrorCounter。当OkCounter大于等于配置的限值且ErrorCoutner小于配置的限值时，进入VALID状态。当ErrorCounter大于等于配置的限值且OkCounter小于配置的限值时，进入INVALID状态。
         

E2E状态机配置参数如下表。注意在ISOLAR中，WindowSizeValid, WindowSizeInit, WindowSizeInvalid三个参数被合并成一个参数E2EXfRb_WindowSize。

注意协议（《AUTOSAR_FO_PRS_E2EProtocol》R23-11）中这张表列出的参数少了一个MinOkStateInit。




E2E State Machine Configuration Type
E2E状态机中用到的变量类型如下表：



E2E State Machine State Type



1.4.2 E2E状态机counter处理逻辑



E2E状态检查的次序是，首先调用E2E check函数进行数据检查，而后根据check函数的检查结果，处理OkCounter、ErrorCounter等，最后再进行状态机的跳转。

以E2E Profile1为例说明，E2E check函数的检查结果有E2E_P01STATUS_OK, E2E_P01STATUS_OKSOMELOST, E2E_P01STATUS_SYNC等。而E2E_SMCheck()函数所需要的E2E状态类型包括：E2E_P_OK, E2E_P_ERROR, E2E_P_REPEATED等。二者之间需要进行映射，映射关系见下表（E2E Profile1，R4.2及以后版本）：





E2E Profile1 specific Check Status Mapping since R4.2

         
其中E2E状态描述如下表：


E2E State Machine Check Status Enumeration

ISOLAR中对counter处理逻辑大致理解为：

OkCounter上表示的是在一个WindowSize测量范围内，检测结果为E2E_P_OK的次数。同理ErrorCounter表示的是在一个WindowSize测量范围内，检测结果为E2E_P_ERROR的次数。实际的实现方法详见ISOLAR的代码实现（E2E_SMCheck()函数）。

举个实例，例如WindowsSize为9，连续9次的测试结果为：

序号	2	3	4	5	6	7	8	9	9
状态	E2E_P_OK	E2E_P_ERR	E2E_P_OK	E2E_P_OK	Other state	E2E_P_ERR	E2E_P_ERR	E2E_P_OK	Other state

则OkCounter为4，ErrorCounter为3。



1.4.3 FTTI与E2E参数设置



在功能安全设计中，有一个重要的设计指标FTTI，即Faulttoleranttimeinterval，故障容错时间间隔。通常FTTI=tFD + tFR，其中tFD是故障检测时间（E2E故障滤波时间），tFR是故障反应时间（在检测到故障后软件/硬件切换到安全状态的时间）。忽略tFR的话，则FTTI=tFD.
在设计E2E参数时需要考虑以下两点：
1）WindowSizeInit - 1 ≤ tFD/cycleTime。（这个是针对TransitToInvalid == 1的情况分析的，此处不详细分析）

2）WindowSizeValid - MinOkStateValid ≤ tFD/cycleTime。        
       考虑从状态机E2E_SM_VALID切换到E2E_SM_INVALID，例如需要WrongSquence数量达到WindowSizeValid - MinOkStateValid+1，（也即是满足条件：OkCounter < MinOkStateValid）。

则持续时间为：

(WindowSizeValid - MinOkStateValid)*CycleTime

要满足FTTI，则

也即是：

WindowSizeValid - MinOkStateValid ≤ tFD/cycleTime

这儿给出FTTI与E2E参数的关联关系的设计思路，具体要看代码实现的逻辑与FTTI需求进行具体分析。



1.5 E2E Library概述



AUTOSAR中提供了E2E Library，本节对E2E Library做简要介绍。



1.5.1 E2E Library调用方式



E2E Library提供了E2E保护机制，E2E Library的调用方需要负责正确使用该库，特别是为接口提供正确的参数。

         

E2E Library可以通过以下进行调用：
1）E2E Transformer（从R4.2.1版本开始引入）
2）E2E Protection Wrapper

3）COM E2E Callout

E2E的保护是针对数据元素（data element）的。E2E保护在序列化后的数据元素上执行，这意味着：

1）当使用E2E Transformer时，序列化由E2E Transformer之上的transformer（COM Based transformer或Some/IP transformer）执行。

2）当使用E2E Protection Wrapper时，Wrapper需要实现数据的序列化。

3）当使用COM callout时，序列化已经被通信栈（RTE, COM）做过了，所以callout可以直接使用I-PDU中已经序列化的信号组（signal group）。

怎么理解以上几点？可以通过CAN报文在COM中的I-PDU和signal/signal group的实现来理解。一般情况下，一帧CAN报文在COM中对应一个I-PDU，一帧CAN报文中可以有一个或多个signal group。一个signal group中可以有一个或多个signal。

E2E保护的是CAN报文的“原始数据”，也就是多个signal序列化（经过偏移量、分辨率的反算）后的CAN报文裸数据，而不是通过计算分辨率、偏移量后的具有物理值含义的数据。
在使用COM callout时，因为signal/signal group的数据已经被RTE和COM处理过，已经形成了CAN报文“原始数据”的格式，所以callout当然可以直接针对序列化后的数据直接进行E2E操作。




         
在使用Wrapper时，需要Wrapper自行实现signal/signal group的序列化，也就是将signal/signal group的数据“打包”成CAN报文原始数据格式，再进行E2E操作。


         
使用E2E Transformer时，由于E2E Transformer只完成E2E操作，所以还需要一个transformer来实现数据的序列化，可以是COM Based transformer或Some/IP transformer。

E2E Transformer Sender Side


E2E Transformer Receiver Side



1.5.2 E2E数据元素保护说明



数据元素要么被E2E完全保护，要么完全不被保护，不可能只保护数据元素中的一部分。

一个I-PDU中可以由多个数据元素。只保护其中的一部分数据元素是可以的。
这么理解以上两点？仍然以CAN报文及其在COM中对应的I-PDU来理解。一个CAN报文（一般情况下对应COM中的一个I-PDU）中可以有多个signal group，每个signal group中可以有多个signal。那么可以针对其中的部分signal group做E2E保护，但不能只对一个signal group中的部分signal做E2E保护。也就是说，做E2E保护的最小数据元素是一个完整的signal group。



1.5.3 E2E Library与功能安全



仅使用E2E Library并不足以根据ASIL D的要求实现安全的E2E通信。用户只负责证明所选择的配置未见为所考虑的网络提供了足够的错误检测能力。



1.5.4 调用E2E Library时序图





1.5.4.1 发送方




在每个发送周期，发送方应该调用E2E_PXXProtect()对数据进行保护处理，然后再触发Rte_Send_
下图是发送方发送数据元素的时序图。注意，由于调用E2E_PXXProtect()对数据元素进行保护计算时，需要的是I-PDU布局格式的数据，所以这儿可能会涉及到一些数据序列化的步骤。详见规范内容。

Sender of data elements
下图是发送signal group的E2E保护时序图。可以用COM + callout，或COM + CDD等实现。注意图中示例了一个I-PDU中包含一个signal group的情况。事实上一个I-PDU可以包含多个signal group。当包含多个signal group时，发送方需要针对每个signal group分别调用E2E_PXXProtect()对数据进行E2E保护。


Sender of I-PDUs1.5.4.2 接收方

与发送类似，接收方接收到数据后，需要对数据进行E2E检查。对数据元素和signal group的E2E检查时序图分别见下图。

Receiver ofdata elements

Receiver of I-PDUs

下图是接收方接收数据后进行E2E检查的示例，可从该示例中了解各配置参数的实际含义。



Configuration parameters of the E2E_PxxCheck() function and their effects



1.5.5 E2E Library使用说明



本节对E2E Library的使用做相关说明。



1.5.5.1 E2E Profile及其变体



在使用 E2E Profile1时，应尽可能使用规范中定义的 E2E Profile1变体。



1.5.5.2 E2E故障处理



E2E Library的用户（调用者），特别是接收方，应为E2E Library检测到的故障提供错误处理机制。



1.5.5.3 数据最大长度



对于给定的CRC算法，其对应的消息长度和汉明距离是相关的。为了确保所需的诊断覆盖率，需要选择适当的消息长度。

E2E保护的数据最大长度如下表：

E2E Profile	Max applicable length including control fields for inter-ECU communication
E2E Profile1	32
E2E Profile2	32
E2E Profile4	4kB
E2E Profile5	4kB
E2E Profile6	4kB
E2E Profile7	4MB

在E2E Profile1和E2E Profile2中，汉明距离为2到给定的数据长度。由于采用8位CRC校验，突发错误检测（burst error detection）高达8位。
注：这儿涉及到信息论基础。

         

采用FlexRay通信时，E2E Profile1和E2E Profile2保护的最大数据长度为32字节。

该规定仅定义最大数据长度，用户需要根据实际需求确定实际保护的数据长度。

         

采用CAN或LIN通信时，E2E Profile1保护的最大数据长度为8字节。

         

E2E Profile4, E2E Profile5, E2E Profile6保护的最大数据长度为4kB.

         

在使用E2E库时，用户应充分评估受保护数据的最大长度，以确保足够的错误检测率。实际项目中定义的最大数据长度可能比为E2E规范推荐最大数据长度更短。

         

如果受保护的数据长度超过网络总线数据帧的限制，则可以在E2E处理前后对数据进行拆包组包的处理。如果再拆包组包过程中发生数据处理错误，可以看做是“Corruption of information（信息损坏）”。

         
在设计系统时，用户应确保E2E Library没有检测出一个数据元素的错误时，不会导致违反系统的安全目标。也就是说，SW-C应该能够容忍收到一个错误的数据元素（但E2E Library没有检测到该错误，系统会把该“错误数据”当做“正确数据”使用）。但SW-C不需要容忍两个连续的错误数据元素，因为E2E Library连续漏检两个数据元素的错误是不太可能的（unlikely）。


1.5.5.4 E2E Library使用方法



E2E Library的使用按以下四步进行：

Step1

用户选择如何调用E2E Library（通过COM callouts, E2E Protection wrapper, E2E Transformer+COM Based transformer）。

Step2

用户确认需要保护哪些数据元素或信号组，以及使用哪个E2E Profile。原则上，所有与安全相关的需要被传输的数据，都需要被保护。

Step3

用户确定每个需要保护的数据元素或信号组的配置。包括：Data ID, CRC offset等

Step4

用户生成（或以其他方式开发）必要的中间代码（例如COM callouts, E2E Protection wrapper等），负责调用E2E库函数。中间代码用作通信模块（如COM、RTE）和E2E Library之间的适配器。



1.5.5.5 Data ID的配置约束


数据元素的DataID或DataIDList[]必须是唯一的。为了能够验证数据元素或信号组的身份，不允许的两个数据元素在一个通信ECU的系统中具有相同的数据ID（E2E配置文件1、4、5、6、7）或相同的DataIDList[]（E2E配置文件2）。1.5.5.5.1 E2E Profile1 double DataID配置

在E2E Profile1中，CRC为8位，DataID为16位。在DataID Mode为E2E_P01_DATAID_BOTH时，DataID被隐式传输（DataID值不会包含在数据内容中，而是包含在CRC计算结果中），针对DataID的CRC计算会有重复值。（很容易理解这一点，因为CRC的值范围是0-255，而DataID的值范围是0-65535，每个DataID对应一个CRC计算结果，显然DataID计算出的CRC会有大量的重复）

也就是说，两个不同数据元素DE1, DE2的16位DataID DI1, DI2可能会对应相同的CRC计算结果。那么一种可能的错误情况是，网关将DE1的数据错误地转发给DE2的接收方（receiver of DE2），而DE2的接收方收到DE1的数据后，无法识别出DataID错误这种失效（假设很不凑巧，counter也一样，数据长度也一样）。

为了解决这种问题，需要添加针对DataID的额外约束。对功能安全等级为ASIL B/C/D的数据元素，其DataID计算出的CRC应当唯一。对功能安全等级为ASIL A的信号，对指定的数据元素/信号长度的DataID，其DataID计算出的CRC应当唯一。

[UC_E2E_00072] 使用E2E Profile1且DataID Mode为E2E_P01_DATAID_BOTH时，数据元素DE1的功能安全等级为ASIL B/C/D，DataID为DI1。则不应存在任何一个数据元素DE2（功能安全等级为任意值，DataID为DI2），使得：

Crc_CalculateCRC8( start value: 0x00, data[2]: {lowbyte (DI1),highbyte(DI1)} )

=

Crc_CalculateCRC8( start value: 0x00, data[2]: {lowbyte (DI2),highbyte(DI2)} ).

（即针对DataID的CRC计算结果相同）

         
上述要求将具有ASIL B、C、D的数据元素的DataID限制在255个不同值，但可以在16bit长的数据范围内选择值。
         

[UC_E2E_00073] 使用E2E Profile1且DataID Mode为E2E_P01_DATAID_BOTH时，数据元素DE1的功能安全等级为ASIL A，DataID为DI1。则不应存在任何一个数据元素DE2（功能安全等级为ASIL A，DataID为DI2，且DE2的数据长度与DE1相同），使得：

Crc_CalculateCRC8( start value: 0x00, data[2]: {lowbyte (DI1),highbyte(DI1)} )

=

Crc_CalculateCRC8( start value: 0x00, data[2]: {lowbyte (DI2),highbyte(DI2)} ).

         

注意对ASIL A等级的数据元素来说，要求相对降低了，只针对相同长度的数据元素做约束即可。
1.5.5.5.2 E2E Profile1 alternating DataID配置

在E2E Profile1下，当Data ID Mode为E2E_P01_DATAID_ALT时，DataID的高字节、低字节被交替放入CRC计算数据中（取决于counter的奇偶）。因此，数据元素接收方需要连续接收两个数据来验证DataID。
1.5.5.5.3 E2E Profile1 Nibble DataID配置

在E2E Profile1下，当Data ID Mode为E2E_P01_DATAID_NIBBLE时，低字节不被显式传输，而是包含在CRC中。因为低字节长度为8位，与CRC相同，因此，如果两个DataID的低字节不同，则DataID对应的CRC值也不同。

         
[UC_E2E_00308] 使用E2E Profile1，Data ID Mode为E2E_P01_DATAID_NIBBLE应遵循以下约束：
1.DataID高字节的高4位为0。

2.DataID高字节的低4位在0x1..0xE范围内（以避免与其中具有0x0的其他E2E Profile 1配置发生冲突，并排除无效值0xF）。

3.DataID低字节与同一总线上的其他使用Double DataID配置的数据元素的DataID的低字节不同。

         

[UC_E2E_00317] 使用E2E Profile1A，E2E Profile1C应遵循以下约束：

1.1A数据应使用< 256的id（这意味着高字节应始终为 0）

2.1C数据应使用>=256（这意味着高字节总是!= 0）和<4096（0x1000-这意味着它们适合12位）的id。

3.1C的DataID的任何低字节都应与1A的DataID的任何低字节不同。

例如：1A低字节可以使用地址0到199，而1C低字节在200到255之间，高字节在1到15之间的地址。这1D的地址范围为：（256-200）*15个= 840个DataID.

         

按照上述约束定义的DataID分布，可以检测到寻址错误，特别是当1C的数据元素发到了1A的接收方时，可以被检测到。
假设一种不符合上述约束的情况，如果1C的数据元素发送了一个1A数据元素接收方，如果1C和1A数据元素的DataID的低字节相同，则1A数据接收方是无法检测出DataID错误的（因为在计算CRC时，1A数据接收方将DataID的低字节放在有效数据内容之前进行CRC计算，但该低字节与1C数据的DataID的低字节数据相同，计算出的CRC当然是有效的！）。1.5.5.6 构建自定义E2E协议

E2E Library提供了基本函数（例如用于处理CRC和counter），从中可以从中构建非标准协议。集成商/应用程序开发人员可以自定义E2E协议，可构建为SW-C或自定义BSW库。
1.5.5.7 I-PDU Layout

1.5.5.7.1 字节对齐要求

当使用E2E Profile时，长度小于8位的信号应该分配给I-PDU的一个字节，即它们不应该超过两个字节。

当使用E2E Profile时，长度为大于等于8位的信号的起始位应该在I-PDU的字节的开始或结束位。

当使用E2E Profile时，要保护的数据长度应为8 bits的倍数。
1.5.5.7.2 unused bit位

在定义I-PDU时，其中难免会有一些bit位未被使用。规定在计算CRC之前，未使用的位被设置为定义的默认值。

注意，实际项目中可能供应商不一定严格执行该规定，需与对手件确认。
1.5.5.7.3 Byte order

规范里推荐的不同总线的大小端为：


Networks and their byte order

         

AUTOSAR中有两种数据类型：1）“Normal”类型，可以执行大小端转化；2）“OPAQUE”类型，COM不做任何转换，将数据作为uint8数组一一映射到I-PDU上。
1.5.5.7.4 Bit order

各网络的Bit order：



Networks and their bit order

除了LIN，所有列出的网络都是MSB。
1.5.5.8 针对SW-C级保护的RTE配置约束

如果数据保护是在I-PDU级别，则不需要对RTE配置做约束。

其他的约束暂未理解其含义，待补充。
1.5.5.9 对使用COM特性的限制

规范原文如下，暂未理解其含义，待补充。
l"supported" means that both (E2E COM Callout and E2EPW) do support this feature.

l"use case dependent" means that the feature might be used/usable depending on the actual use case and configuration on sender and receiver side. However, suitability for an actual system and its influence on the safety requirements has to be analysed.

l"not supported" means that at least one variant (either E2E COM Callout or E2EPW) does not support this feature or a failure mode can be masked.





Classification of COM features



1.6 配置参数



下表是E2E模块中的配置参数。



下面介绍E2E Profile1中较为重要的一些参数：
1）dataID：即信号组的DataID值，为两字节长数据。

2）dataLength：即数据长度，注意这儿的数据长度包含CRC字节。

3）dataIdMode：即DataId模式，详见1.2.3节。

4）counterOffset：counter字节偏移，即counter在信号组中的起始位置。

5）crcOffset：crc字节偏移，即crc在信号组中的起始位置。

6）dataIdNibbleOffset：这个参数只有在dataIdMode为E2E_P01_DATAID_NIBBLE时才有意义。表示DataId高字节的低四位在信号组中的偏移（起始位置）。

7）maxDeltaCounterInit：允许最大的信息丢失数。

8）maxNoNewOrRepeatedData：允许最大的无新数据/数据重复数。

9）syncCounterInit：信息同步计数初始值。

         

E2E状态机参数：

1）windowSize（windowSizeValid, windowSizeInvalid, windowSizeInit）：在ISOLAR中，windowsSize被合并为一个参数，表示检测窗口长度。

2）maxErrorStateInit：在Init状态下error counter上限值。

3）maxErrorStateInvalid：在Invalid状态下error counter上限值。

4）maxErrorStateValid：在Valid状态下error counter上限值。

5）minOkStateInit：在Init状态下ok counter下限值。

6）minOkStateInvalid：在Invalid状态下ok counter下限值。

7）minOkStateValid：在Valid状态下ok counter下限值。

  

点击上方☝️关注车端