在 一文了解CAN矩阵与DBC文件 中已经介绍了CAN通讯矩阵或DBC文件的内容具体是怎么做出来的,包括信号如何命名,信号的数据如何定义,以及信号如何放置等内容。本文将继续这个话题,尽可能把CAN通讯矩阵设计的内容介绍全面,因此接下来将探讨CAN矩阵和DBC文件制作过程需要考虑的一些关键因素,比如负载率,信号路由以及国标数据上传等内容。1 负载率计算
为什么首先要谈负载率,因为当新增的CAN信号经常以负载率过高原因被退回,此时此景,如果你深刻地明白什么是负载率,到底负载率增加了多少,那么过程会顺利很多。什么是负载率?
通俗地讲,一条条报文就像CAN总线上一辆辆飞驰的汽车,如果发送的报文太快太频繁,就会出现拥挤,从而导致信息的传输阻塞,延迟甚至是丢失。因此,一条CAN总线有多少报文,报文以多快频率传输,要充分考虑,这个就用负载率来衡量。
负载率:在给定时间内,CAN总线所采用的通信参数与总线容量之比。具体可以这样理解,假设CAN总线具备1s传递1000bit数据的能力,如果设计是1s传递500 bit数据,那么负载率就是50%,如果设计是1s传递1000bit数据,那么负载率就是100%。
对于不同CAN帧类型,具体怎么计算负载率呢?可以参考:CAN通讯系列9- 负载率怎么计算。总之,负载率计算的逻辑就是:
首先要明确目标的CAN总线波特率是多少;
然后明确该总线有哪些类型的CAN帧,有多少条,发送周期是多少等;
再考虑帧间隔,最后根据前面的信息计算负载率。
这里不再开展具体计算过程,不同CAN帧的负载率如下统计:

假设当前负载率为50%,CAN的波特率为500Kbps,CAN FD的波特率-仲裁段500Kbps,数据段2Mbps,DLC为8。基于以上数据,如果新增一条报文,那么负载率会发生什么变化?
假设增加一条CAN标准帧,发送周期10ms,那么负载率将增加2.22%假设增加一条CAN扩展帧,发送周期10ms,那么负载率将增加2.62%假设增加一条CANFD帧,发送周期10ms,那么负载率将增加1.035%
建立了上述基础,那么每增加一条报文,我们就可以清晰的知道负载率具体会增加多少,另一方面我们可以合理设置CAN帧类型,争取传输更多数据的同时,尽可能降低CAN总线的负载率。
2 信号的路由随着新能源汽车的快速发展,这两年各个主机厂所采用的电子电器架构方案基本都是域控制器方案或区域控制方案,这样的架构会有动力总成,底盘总成,车身,高级辅助驾驶和车联网等域控制器,或者前后左右几个区域控制器,然后每个域控制器或区域控制器下又有多个子控制器和多条CAN总线,如下示意:

Source: ADAS/AD域控制器01-域控制器的当前与未来这样的架构就形成了几种通讯形式,
域控制器之间的通讯,跨域通讯同一域控制器内同一条CAN总线同一域控制器内不同的CAN总线
假设架构是这样:VCU有两条CAN,一条CAN上有OBC和BMS,另一条CAN上有TMS(热管理控制器),T-BOX上有远程控制器。假设有这样一个场景:在一个寒冷的冬天的夜晚,车辆插着慢充枪,但未充电。然后用户睡觉前想起来了,就在远离车辆的地方打开手机端的车控APP,点击开始慢充充电。那么此时控制逻辑是:
远控控制器接收到远控的慢充请求,先发送给T-Box, T-Box不需要做该信号做任何的逻辑处理,只需要路由转发给VCU;VCU收到该信号后,一方面会进行相关的逻辑判断,另一方面路由转发给OBC和BMS,OBC和BMS监测到当前温度太低,不利于电池充电太低,需要先预热,BMS请求TMS来加热,此时BMS的报文也需要VCU路由到另一条CAN总线给TMS。

通过这个例子不难发现,域控制器经常需要路由子控制器的报文到域内其他CAN总线的子控制器或其他域控制器下的子控制器,也就是说报文路由越发常见,这就要求在CAN通讯矩阵设计时,要特别注意报文的路由,准确识别出来,与相关方确认好,以避免亡羊补牢,消耗殆尽的精力。3 国标数据上传车联网时代,政府对新能源汽车数据有标准化数据上传强制要求。通过国家标准GB/T32960-2016等法规,要求新能源汽车制造商将特定车辆数据上传至企业平台,之后这些数据再被转发到政府监管的公共平台。GB/T32960-2016 是电动汽车远程服务与管理系统技术规范,它有三部分总则,车载部分,通信协议和数据格式。该法规明确要求需要上传哪些数据,比如车辆状态、充电状态、系统运和行状态等,如下图示意:

source: GB/T32960-2016
因此在设计CAN通讯矩阵时,需要明确哪些信号是国标数据上传要求的,这些信号将需要被传输到T-BOX,最终由T-BOX上传到规定的云平台。
这点与上一点类似,不要漏掉了,不然后续要花费很大的精力来纠错。
4 小结通过对以上内容的介绍,我们可以知道原来CAN通讯矩阵的设计,除了基本内容的定义与设计之外,还需要考虑更多的点,这样才能设计出更完善的CAN通讯矩阵。如果对负载率,信号路由和国标数据上传等其他因素没有明确情绪,后续可能就会增加返工的次数,很可能导致CAN通讯矩阵无法及时交付或者多次交付,这样在如今如此紧张的交付周期下,很可能面临着各方都催的情况,背锅的压力着实会不小。因此,尽可能考虑全面,尽可能把技术做到位,把技术要求没那么高的CAN通讯矩阵和DBC文件做到位。
到此,就通过 一文了解CAN矩阵与DBC文件和本篇文章把CAN通讯矩阵所要考虑的设计思路介绍完毕,希望对你的工作有所帮助。
创作不易,欢迎点赞再看收藏关注!
CAN通讯群,有兴趣的朋友请添加群主:prOmiseyes,备注:公司+职务入群。仅限汽车从业人员。
CAN通讯47
经验分享40
CAN通讯 · 目录
上一篇CAN通讯系列29 - CAN信号背后都经历了什么?