【CAN通讯系列2】与CAN通讯的故事

3年前在知乎撰写很多CAN通讯相关的文章，那时主要偏于软件视角，反馈还不错。3年过去了，随着系统与软件的增加，对CAN通讯的认识有所加深，那就在此基础上，重新更新一个CAN通讯系列文章。

---

先从我与CAN通讯的故事说起：

1 初始CAN通讯

最初接触CAN通讯，那时刚工作，在主机厂的研发部门，经常需要去车上采集和分析数据。比如使用CANalyzer，先选定对应控制器的DBC文件导入，再选定许多CAN信号，配置好波特率就可以采集数据；然后可能需要对采集数据进行处理，通常使用CAPL语言编写一些脚本文件。

、

在这个使用过程会关注的一些点：

• CAN波特率是500kbps还是250kbps？

• 报文协议或DBC，即每条CAN报文都有哪些信号

• 也许会使用CAPL脚本实现数据过滤或加工处理

2 应用层软件中的CAN通讯

后续做具体的应用层软件开发工作后，几乎天天都需要使用CANape进行测量与标定。这时，仍需要选定CAN的波特率，同时需要配置这个报文的发送ID和接收ID，还要选择A2L文件，然后再去选定测量信号和标定量。

Source：如何使用CANape实现XCP/CCP“Measurement测量”和“Calibration标定”变量_canape标定

在这个过程会产生一些疑问：

- 测量和标定与CAN通讯有什么关系？

- 为什么去设置报文的发送ID和接收ID？

- A2L文件是什么？与测量和标定有什么关系？

同时，作为应用层软件工程师，经常需要刷写软件，一般采用UDS服务来刷写，也有支持XCP刷写。这时使用CANape或CANalyzer脚本来刷写，当选择目标可执行文件（hex或s19格式等），运行起来会看到类似下图所示的数据流。大多数时候刷写都会成功，偶尔刷写失败，而且还刷死了，这时有同事会告诉去快速重复地发送一个指令，看是否能够救回来。

Source: UDS Bootloader刷写软件 - 元享技术

在这个过程又会产生很多问题：

• 这个CANape或CANalyzer脚本怎么实现刷写的？

• 这个刷写的数据流怎么看？是什么意思？

• 刷死需要发送特定的指令，为啥要快速重复地发送？又为啥能救回？

后面又接触了应用层软件中的CAN通讯模块，这时能模块中有做信号转换的逻辑，有做ID , checksum, rolling counter等信息检查的逻辑，有做信号有效性校验的逻辑，另外，也需要去CAN通讯模块的测试，比如使用CANalyzer或CANape发送一条报文，看软件是否按照预期的逻辑执行。

source: 使用CANAPE脚本script周期性发送报文_canape发送can报文

到此，仍然有很多问题：

• checksum, rolling counter都表示什么意思？

• 应用层软件收到CAN信号都在底层软件中做了什么？

• CANape或CANalyzer是怎么发送报文的？

为了更进一步了解这些问题，有幸从事了底层软件开发。

3 底层软件中的CAN通讯

对于一个成熟的底层软件平台，会发现客户最多的需求变更就是和通信相关，一会要增加一条报文，一会要报文中增减信号，一会要改波特率或采样点。对于基于AutoSAR工具链的底层软件开发，这部分内容好像并不是很难，理想地情况下，也许只需要一份guideline，你依葫芦画瓢就可以整出来了。然后利用CANape或CANalyzer进行测试，发现确实正确地实现客户的需求。但是基于AutoSAR架构在底层软件中具体是如何实现CAN通讯的？其控制流和数据流是怎么样的？

source: Vector learning

4 系统中的CAN通讯

有了软件开发CAN通讯经验，再接触系统工作之后，又是如何去理解CAN通讯呢？可参考：
【CAN通讯系列1】需求解析（上）

【CAN通讯系列1】需求解析（下）

5 小结

这就是目前与CAN通讯的故事，对于汽车研发而言，基本上涉及到了总成系统测试，控制器系统开发和控制器软硬件开发的CAN通讯内容。也是在这样一个长期的工作过程，不断地带着问题又不断解决问题，走成了目前的职业生涯。

想了解CAN通讯更多更深刻的内容，请持续关注后续文章。

-------------------------------------------------------------------------------------------------------------------------

创作不易，欢迎点赞收藏关注。

汽车研发交流群，有兴趣的朋友请添加群主：prOmiseyes，备注：公司+职务入群。仅限汽车行业从业人员。