摘要：
本文讨论一个具体的工程问题，E2E报文对应的信号，由小周期转大周期导致的E2E校验失败问题。
工程中，网关节点很重要的一个功能就是路由。当然，E2E（End to End）报文也可路由，但是，路由的信号（Signal），如果周期不同，通信矩阵设计又未充分考虑，可能会带来一些预料之外的问题。本文讨论一个具体的工程问题，E2E报文对应的信号，由小周期转大周期导致的E2E校验失败问题。
1、问题描述
节点Node1和节点Node2之间通过网关节点（Gateway Node）通信，其中，某帧PDU受E2E保护。Node1通过CAN总线，以10ms周期发送E2E Tx PDU，发送给网关节点（Gateway Node），Gateway Node再通过Flexray总线，以320ms周期将此PDU信息路由给Node2，Node2接收E2E Rx PDU，并对此PDU做E2E校验。此E2E PDU的传输示意如下：
提示：Gateway Node仅仅是路由功能，不做E2E校验。路由时，如果Node1中的信号或者信号组配置了UB（Update Bit），路由信息之前，需要进行UB位检查。
（一）问题现象采集的数据如下所示：
如上图，在T1时刻，Node1停止发送E2E Tx PDU，即：E2E Tx PDU包含的信号SignalCnt停发。而在T2时刻，Node2接收到的SignalCnt UB = 1，继续接收SignalCnt，但是，此时的SignalCnt = 11，而上一次的SignalCnt = 12，Node2做E2E校验时，认为此时Sequence Number Error，进而进行了故障处理，eg：故障指示灯提示等。具体错误 ：由于DeltaCounter >MaxDeltaCounter，导致E2EPW_STATUS_WRONGSEQUENCE。DeltaCounter的计算如下：(ReceiverCounter >= State->LastValidCounter)？(DeltaCounter = ReceivedCounter -State->LastValidCounter):(DeltaCounter = 15 + ReceivedCounter - State->LastValidCounter)由于Node2最新一次接收的值ReceiverCounter = 11，State->LastValidCounter = 12，DeltaCounter = 14。而配置的State->MaxDeltaCounter = 8，最终导致E2EPW_STATUS_WRONGSEQUENCE。
2、问题分析
这个问题的本质是因为信号小周期（本文：10ms）转大周期（本文：320ms）过程中，UB处理问题。如下图：
t0时刻，Node1正常发送E2E报文，且Tx UB = 1，Gateway Node正常路由信号SignalCnt，Rx UB = 1，Node2正常接收E2E报文，并做E2E校验；
t1时刻，Node1停发E2E报文，但是，t0~t1期间，由于Tx UB = 1，Gateway Node仍正常路由信号SignalCnt，且路由的SignalCnt值为11；
t1~t2期间，由于Tx UB = 0，Gateway Node不再路由信号SignalCnt；
t2时刻，由于Gateway Node所在的Flexray并没有停止通信，Gateway Node继续路由数据，而此时路由的SignalCnt = 11。由于t0~t1期间，Gateway Node的发送缓冲区数据有更新，因此，t2时刻发送数据时，UB = 1，因此，Node2接收到的Rx UB = 1，进而Node2继续校验Node1发送的E2E报文，由于此时，SignalCnt = 11，不是预期的SignalCnt = 13，且DeltaCounter >MaxDeltaCounter，进而导致校验失败。
3、处理措施
如上的分析，问题并不出在收/发两方，而是通信矩阵设计时，未有充分考虑E2E路由的问题，即：小周期转大周期的E2E路由问题。
如上的通信设计中，已经失去了E2E的保护意义。因为发送端的Counter值路由到接收端时，可能存在随机性。发送端每10ms发送一次，而接收端每320ms接收一次，也就是说，发送端的Counter更新了32次，接收端才接收到一次。收/发两端SignalCnt变化情况如下所示：
如上图，可以看出，接收端在接收到SignalCnt存在一定的随机性。
所以，上述问题，需要系统重新评估和设计通信矩阵，或者接收端优化网络休眠时的E2E处理策略。
来源 **|**开心果 Need Car