CAN-FD的两种应用,你了解多少?

CAN-FD(CAN with Flexible Data Rate)作为CAN协议(基于CAN2.0)的改进,它与CAN有什么样的区别呢?今日一哥就和大家一起聊一下CAN-FD常见的一些应用情况。

一、什么是CAN总线?

///插播一条:我自己在今年年初录制了一套还比较系统的入门单片机教程和毕业设计指导,想要的同学找我拿就行了免費的,私信我就可以哦~点我头像白色字体加我也能领取哦,记得口令一哥///

CAN是控制器局域网络(ControllerAreaNetwork,CAN)的简称,是由以研发和出产汽车电子产品著称的德国BOSCH公司开发的,并最终成为国际规范(ISO11898),是国际上应用最广泛的现场总线之一。

在北美和西欧,CAN总线协议已经成为汽车计算机控制系统和嵌入式工业控制局域网的规范总线,并且拥有以CAN为底层协议专为大型货车和重工机械车辆设计的J1939协议。

二、CAN总线的特点

1、多主机方式工作:网络上任意节点可在任意时刻其他节点发送数据,通信方式灵敏;

2、网络上每个节点都有不同的优先级,能够满足实时性的要求;

3、采用非破坏性仲裁总线构造,当两个节点同时向网络上传送信息时,优先级高的优先传送;

4、传送方式有点对点、点对多点、点对全局广告三种;

5、通信距离可达6km,通信速率可达1MB/s,节点数可达110个;

6、采用的是短帧构造,每帧有8个有效字节;

7、具有可靠的检错机制,使得数据的出错率极低;

8、当发送的信息遭到破坏后,可自动重发;

9、节点在严重错误时,会自动切断与总线联络,以免影响总线上其他操作。

相比CAN协议,CAN-FD新增两个比较大的特点:

1、 支持可变速率

a) 仲裁段与标准CAN速率相同

b) 数据段:速率最高可达8Mbit/s

2、 支持更大的payload(数据长度)

a) 帧的长度可达64字节

从特性可以看出:CAN-FD的优势:

·更快的刷写速率

·避免将数据拆分多帧

·减少现有总线的总线负载

·避免拆分网络

通过上述阐述,CAN-FD针对目前CAN总线带宽资源不足的问题具有一定的缓解作用。目前国内局部OEM针对CAN-FD协议的运用主要有两种:一种是固定好通信内容,仅增加了报文长度;另一种是AUTOSAR的思想,采用PDU的思维,能够达到更为灵敏的应用,如下分别介绍两种思维。

1、增加报文长度,在DBC格式的数据库中定义CAN-FD帧,如图1 所示。

打开网易新闻 查看精彩图片

图1 CAN-FD报文在DBC数据库文件中的定义

2、完全按照CAN-FD协议要求,在arxml格式的数据库中定义CAN-FD帧,如图2所示。

打开网易新闻 查看精彩图片

图2 CAN-FD报文在arxml数据库中的定义

到这里是不是有童鞋不禁要问了,这二者有什么区别呢?嘿嘿,且听一哥细细道来。

针对第一种:仅增加了CAN-FD报文的帧长度,数据场的内容是固定的。OEM在DBC数据库文件中定义了CAN-FD的报文长度,规定数据场的内容,也就是将信号的排列顺序规定好。将DBC数据库释放给零部件供给商后,供给商依据OEM释放的文件,进行通信开发。此种优势在于一旦出现信号交互问题,测试人员能快捷定位问题,同时零部件供给商也能依据报文快捷定位控制器软件问题。但是劣势也比较明显,一旦总线出现高负载的情况,没法调整报文长度,没法灵敏降低负载,灵敏性不足。

打开网易新闻 查看精彩图片

一条CAN-FD总线上有节点A、节点B等等20个节点,假如这些节点将自身的报文全部发送,总线负载到达75%,节点A发送的2条CAN-FD:报文M(长度为64)与报文N(长度为64)。针对总线高负载的情况下,节点A中报文M的信号P(信号长度占4个字节)是一个重要的信号,此时节点A只须要将信号P所在的报文发出。由于DBC数据库将每一帧CAN-FD报文的长度固定,所以节点A一旦须要发送信号P的报文,必需得将报文M所有的信号全部发出。假如对于其余节点也都是这样的话,总线负载率没法进行降低,造成带宽资源的浪费。

看完第一种情况,再来看一下第二种:应用CAN-FD的协议,在arxml数据库中定义CAN-FD帧。此时引入PDU的概念:PDU(Protocol Data Unit)协议数据单元。一般用到的PDU有:NMPDU(网络管理PDU)、I-signal-PDU(信号PDU)、Container-PDU(PDU簇)。AUTOSAR中规定:Frame是由PDU组成,PDU是由signal组成。常规CAN报文一般是由I-signal-PDU组成,而CAN-FD报文(报文长度超过8字节)一般是由Container-PDU组成,Container-PDU则是由若干个I-signal-PDU组成,如下图3所示。

打开网易新闻 查看精彩图片

图3 I-signal-PDU在Container-PDU分布

OEM一般将arxml数据库文件释放给零部件供给商,供给商能够依据AUTOSAR框架进行软件架构划分,各司其职。这种方式益处为对于整车交互时,一旦总线出现高负载的情况,控制器能够依据自身需求缩短报文的长度,降低负载,灵敏性较高。我们沿用上个栗子来看:

节点A中信号P(信号P占4个字节)是一个重要的信号,此时节点A只须要将信号P发出即可。此时利用AUTOSAR架构概念,在设计时将信号P放到一个I-signal-PDU(PDU Y)中,此时只须要将PDU Y (4个字节)+ PDU Y的shortHeaderID(占3个字节) + PDU Y的DLC(占1个字节)放到报文M中,此时只须要发送M报文(8个字节),即可满足总线需求,而其他非重要的信号,能够不发送、少发送、增长发送周期等方式,来降低总线负载。

看到这里,是不是有童鞋又要问了:这个真能这样达到吗?下图所示,能够看到同一个报文里包括了不同PDU的情况。

打开网易新闻 查看精彩图片

图4 报文0xB5 PDU信息显示

不过还是要给各位童鞋泼泼水冷静下。第二种虽然益处众多,但是也是有一些劣势的。首先架构须要重新定义,传统架构中报文与信号中并没有插入PDU的概念,最多引入信号组(signalgroup)的概念,因此须要将信号与报文信息进行重新归类。然后,对开发人员素质要求较高,整体合作度增强。AUTOSAR架构虽然将各个架构进行划分,但是一旦出现问题,须要每个参与的人员进行整体性的查看问题、定位问题。其次,测试人员素质要求增强,传统CAN-FD DLC测试时,可用CANoe自带函数进行检查校核,但针对AUTOSAR CAN-FD测试时,自带函数没法施展,须要自身提取CAN-FD报文长度与数据场内容(PDU信息),通过数据场内容的提取进行报文长度的比照,从而达到测试,而同时测试人员还须要掌握一定的AUTOSAR知识。

综上所述,对于CAN-FD在车上的两种应用,各有优劣。就目前而言,第一种方式由于简略易用被很多主机厂采用,第二种方式目前则多数情况被用于预研。“万里长城非一日建成”,相信AUTOSAR CAN-FD会逐步的扩充其应用市场,被大面积采用。

想要学习单片机的朋友 ,做毕业设计的同学,关注我们,口令一哥,与导师一起学习成长,共同进步,还有更多资料领取。

说了这么多,大家记得留意下方评论第一条(或者私信我)有干货~

-END-

*本文系网络转载,版权归原作者所有,如有侵权请联系删除