Bootstrap

【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,备注:公司+职务入群。仅限汽车行业从业人员。

;