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文件，然后再去选定测量信号和标定量。

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

• 测量和标定与CAN通讯有什么关系?？
• 为什么去设置报文的发送ID和接收ID？
• A2L文件是什么?？与测量和标定有什么关系?？

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

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

• 这个CANape或CANalyzer脚本怎么实现刷写的?？
• 这个刷写的数据流怎么看?？是什么意思?？?
• 刷死了去发送一个特定的指令，为啥要快速重复地发送?？又为啥能救回？

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

到此，仍然有很多问题：

• checksum, rolling counter都表示什么意思?？
• 应用层软件收到CAN信号都在底层软件中做了什么?？
• CANape或CANalyzer是怎么发送报文?的？为了更进一步了解这些问题，有幸从事了底层软件开发。

3 底层软件中的CAN通讯

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

4 系统中的CAN通讯

有了软件开发CAN通讯经验，再接触系统工作之后，又是如何去理解CAN通讯呢？可参考：

安全验证 - 知乎

5 小结

这就是目前与CAN通讯的故事，对于汽车研发而言，基本上涉及到了总成系统测试，控制器系统开发和控制器软硬件开发的CAN通讯内容。也是在这样一个长期的工作过程，不断地带着问题又不断解决问题，走成了目前的职业生涯。想了解CAN通讯更多更深刻的内容，请持续关注知乎或微信公众号 谦益行 已有的CAN通讯文章。