HIL如何对控制器接收与输出的CRC及RC进行测试

andyo7

最近更新的比较频繁，是因为项目任务重，域控的开发及测试还是比较有难度的，涉及的知识点特别多，所以这些文章也算记录一个项目所需知识的学习与应用的过程。

随着车载域控制器电气化与智能化的发展，越来越多的信息通过ECU控制器与ECU控制器之间，ECU控制器与Cloud云端之间，控制器内部芯片（CPU内核与存储器，外设与存储器等）之间进行交互。信息传递的数据安全成为了必须要考虑的问题。

以ECU控制器与ECU控制器之间进行CAN通讯为例，对于控制器中一帧报文的传输来说，数据很容易被模拟和仿造，如果报文被截获且被恶意篡改，将极大地影响车辆驾/乘人员的人身安全。控制器领域的三座大山：ASPICE、ISO26262、AUTOSAR。

AUTOSAR中的E2E为解决该问题应运而生，E2E的功能不仅适用于板级间通信（Ecu之间），还适用于核间通信。E2E的解决的本质问题是：E2E属于功能安全，信息可以被截获，但是被篡改就会被识别出来进而采取安全措施，只能确保车辆功能的安全。

在需求中按照特定的需求进行定义：

对于E2E报文，未使用部分填充1；对于非E2E报文，未使用部分填充0。可能就是为了区别一下。



非E2E报文



E2E报文

加入E2E，那么诊断部分的功能也会有额外的要求，要对接收到的E2E报文进行校验，包括CRC校验， RC校验和信号有效性校验，以此确保接收的数据是安全可靠的。E2E配置的报文都是注重安全性的报文，要求等级高，在项目中E2E报文有严格的检查时序： PDU有效性->CRC有效->RC有效->信号有效性->处理。

RollingCounter:

RollingCounter位于报文的数据段，一般为4个bit,主要用于检测是否丢帧，也就是发送端是否能够周期性的连续发送报文。其原理是发送端每发送一帧报文，Rolling Counter的值就加1，满15就从0重新开始计数。如果Counter的值没有更新，则说明该报文发送不连续，出现了丢帧或者漏帧的情况。

CRC8：（J1850）

CRC8校验，一般为8个bit,是用于判断接收端接收的信号是否正确的算法。CRC8位于报文的数据段，发送端将报文的数据段用相应的算法处理，得出CRC8的值，并跟随报文发送；接收端采用同样的算法，将接收到的数据段进行算法处理，并得出CRC8的值，然后将接收到的值进行比较，若相同则接收到的信号是正确的，判断信号有效，若不同，则接收到的信号不正确，判定信号无效。



在测试过程中，真实控制器接收的模拟报文CRC及RC检测通过功能是否正常以及通过UDS可以判断，真实控制器发出的CRC和RC需要通过反校验模型进行算法的确认。如下图，可以自己摸索，2018版的Matlab比较好处理，2016之前的Matlab版本软件需要通过下图中的方式进行处理。图片是网上找的。