在专栏文章仿真CAN报文发送的CRC校验算法（附CAPL代码）和同星TSMaster中如何自定义E2E校验算法中分别给出了CRC算法和E2E校验实现，从中也明白了为什么在测试中需要去做这些仿真。在车载网络测试中经常会出现CRC、E2E、checksum、rollcounter这几个词，这篇文章想搞清楚这几个概念具体的含义及用途。在车载网络测试中，E2E校验更注重端到端也就是ECU到ECU的完整性校

结合大端小端的定义，在DBC数据库中新建信号来梳理Intel和Motorola传输格式的区别不失为一种好的了解方式。理清了LSB、MSB、Intel和Motorola，能够举一反三的理解其他的字节序和位序的数据传输的具体实现。

在ISO 15765-2中对于网络层协议数据单元N_PDU有4种类型，分别为单帧SF、首帧FF、连续帧CF、流控帧FC，并且在帧格式上区分CAN和CANFD。

最近因项目需要，用到TSMaster进行E2E校验算法实现。第一次使用TSMaster，把整个的过程做一个记录，仅供参考。当然有任何问题欢迎批评指正！首先，TSMaster已经提供了很多定义好的CRC算法来调用，并且对于基本的E2E校验也做了适配，还是很赞的。但是如果加入异或运算的DID数据是实时变化的，如何在TSMaster中实现E2E算法呢？选择程序->C小程序->自定义函数，右键添加自定义函

CAN高负载测试，即验证CAN网络将负载提高至某一值时，总线节点是否还能够准确的发送报文。实际传输的bit数是包含所有CAN报文的开销：从帧起始、仲裁区到帧结束的。BusLoad = 实际传输bit / 理论最大传输bit。因此一个标准CAN帧有108+17=125bit。中实时运行查看Busload。

以下图空调功能为例，当二氧化碳浓度传感器（主动唤醒源）检测到车内二氧化碳浓度超标后，就会触发空调放大器ECU（主动唤醒节点）主动唤醒，空调放大器ECU通过发送NM网络管理报文（被动唤醒源）去唤醒相关功能连接的ECU和执行器（被动唤醒节点）。原因在于：主动唤醒节点需要快发NM报文唤醒其他ECU节点来与其进行通信，如果先发APP报文，其他的ECU节点处于休眠状态，不会对其发送的APP报文做出响应。对于

方便大家搜索，没有直接贴图，哈哈哈哈。

蛇年伊始，火出圈的除了《哪吒2》登顶中国影史票房第一外，科技圈的DeepSeek国产大模型引爆全球，关于在DeepSeek上的提问无奇不有。就车载通信自动化测试，本文也来蹭蹭热度。作为CAN/LIN协议一致性自动化测试脚本的开发调试人员之一，比较好奇DeepSeek能不能帮助我们进行协议一致性测试脚本的开发及脚本可用性。

CANoe（CAN open environment）： 用于汽车ECU网络仿真、数据分析、测试和诊断，还可以进行数据回放、程序刷写等。具有实时报文跟踪、数据解析及匹配、信号可视化分析、总线数据统计、自定义面板开发、扩展编程应用等功能。分析仿真测试诊断关于数据回放功能的实现上，CANoe提供的两种方式。

校验方法：翻转八位和。将校验对象的各字节作带进位二进制加法(每当结果大于等于 256 时就减去 255。一个字节8位，最多表示0到256)，并将所得最终的和逐位取反，以该结果作为要发送的校验和。接收方根据校验和类型，对接收数据作相同的带进位二进制加法，最终的和不取反，并将该和与接收到的校验和作加法，如果结果为 0xFF，则校验和无误。在12V供电环境下，LIN总线（Local Interconne