CAN总线简介

CAN 是 Controller Area Network 的缩写(以下称为 CAN),是 ISO国际标准化的串行通信协议。

历史背景

CAN 最初出现在80年代末的汽车工业中,由德国 Bosch 公司最先提出。当时,由于消费者对于汽车功能的要求越来越多,而这些功能的实现大多是基于电子操作的,这就使得电子装置之间的通讯越来越复杂,同时意味着需要更多的连接信号线。

在1980年代初期,博世的工程师正在评估现有的串行总线系统,以探讨其在汽车中的可能用途。由于没有可用的网络协议能够满足汽车工程师的要求,因此Uwe Kiencke于1983年开始开发新的串行总线系统。

新的总线协议主要是要增加新的功能 --- 减少线束不是CAN发展背后的驱动力。

1986年2月,CAN诞生了:在底特律的SAE大会上,新的总线系统被称为"Automotive Serial Controller Area Network(汽车串行控制器局域网)"。Uwe Kiencke,Siegfried Dais和Martin Litschel介绍了多主网络协议。它基于一种非破坏性仲裁机制,该机制允许总线访问具有最高优先级的帧而没有任何延迟。没有中心控制器。此外,CAN之父(上述人员以及博世员工Wolfgang Borst,Wolfgang Botzenhard,Otto Karl,Helmut Schelling和Jan Unruh)已经实现了几种错误检测机制。错误处理还包括自动断开故障总线节点,以保持其余节点之间的通信。传输的帧不是由帧发送器或帧接收器的节点地址(几乎在所有其他总线系统中)识别的,而是由它们的内容识别的。表示帧有效载荷的标识符,还具有指定帧在网络段内的优先级。

随后,许多介绍该创新通信协议的演讲和出版物,直到1987年中期(比计划提前两个月),英特尔才交付了第一款CAN控制器芯片82526。这是CAN协议的第一个硬件实现。在短短四年内,一个想法就变成了现实。此后不久,飞利浦半导体推出了82C200。CAN控制器的这两个最早的祖先在接受过滤和帧处理方面有很大的不同。一方面,与飞利浦选择的BasicCAN实施相比,英特尔所青睐的FullCAN概念要求所连接的微控制器的CPU负载更少。另一方面,FullCAN设备在可以接收的帧数方面受到限制。BasicCAN控制器还需要更少的硅。在当今的CAN控制器中,实现了接受过滤和帧处理这两种概念的混合。这使BasicCAN和FullCAN的误导性术语过时了。

现在,CAN 的高性能和可靠性已被认同,并被广泛地应用于工业自动化、船舶、医疗设备、工业设备等方面。

发展阶段

  • 1986年发布CAN1.0。
  • 1991年博世发布CAN2.0规范,分为CAN2.0A(11位标识符)和CAN2.0B(11+18=29位标识符)。
  • 1993年ISO组织发布国际标准ISO11898(高速应用)和ISO11519(低速应用)规范:
    1. ISO11898-1 涵盖数据链路层。
    2. ISO 11898-2 涵盖高速CAN的CAN物理层(经典CAN速度1Mbps,CAN FD 5Mbps)。
    3. ISO 11898-3 涵盖低速、容错CAN的物理层(速度125kbps)。
    4. 后续推出ISO 11898-4 -5 和-6标准。
  • 2012年博世发布CAN FD 1.0(速度2Mbps,使用加强版CAN PHY的CAN FD-SiC可以做到5-8Mbps)。
  • 2014,Infineon 开发出支持CAN FD
  • 2015,ISO 组织发布CAN FD 标准(ISO 11898-1 )
  • 2018年发布第三代CAN数据链路层协议CAN XL,速度提升至10Mbps,兼容CAN FD。

帧格式

Classic CAN和CANFD帧长度

不管是Classic CAN还是CANFD,其帧结构都由以下7个段组成

  • SOF;
  • 仲裁字段(包含标识符字段和部分格式字段);
  • 控制字段(包含 DLC 字段和部分格式字段);
  • 数据字段(包含 LLC 数据字段)
  • CRC 字段
  • ACK 字段;

SOF:帧起始

  • 标识一个数据帧的开始,用于同步
  • 固定格式:一个显性位
  • 只有在总线空闲期间,节点才能够发送SOF

ID:标识符

  • 唯一确定一条报文
  • 表明报文的含义,可以包含报文的源地址和目标地址
  • 确定报文的仲裁优先级,ID 数值越小,优先级越高
  • 标准帧:11位;扩展帧:29位

RRS

  • 对应传统CAN报文RTR位
  • CAN FD 没有定义远程帧
  • 发送节点发送显性位

IDE

  • 用于区分标准帧和扩展帧
  • 标准帧,IDE=0(11 位ID)
  • 扩展帧,IDE=1(29 位ID)

FDF

  • 用于区分普通CAN报文和CAN FD报文
  • CAN 报文,FDF=0
  • CAN FD 报文,FDF=1
  • 不用于仲裁
  • 对于同一ID 值只能分配给Classic CAN 报文或者FD 报文

res

  • 保留位
  • 当前置0

BRS(Bit Rate Switch)

  • 速率切换指示位
  • BRS=1 ,进行速率切换
  • BRS=0 ,不进行速率切换

ESI(Error State Indicator)

  • 错误状态指示
  • ESI=0 ,处于主动错误状态的节点
  • ESI=1 ,处于被动错误状态的节点

DLC

数据场

  • 具有0-64个字节长度,由DLC确定
  • 包含CAN数据帧发送的内容

CRC

CRC界定符(DEL)

  • 界定CRC序列
  • 1~2位(相位偏移引起)
  • 在界定符的第一位进行速率切换

ACK

  • 确定报文被至少一个节点正确接收
  • 发送节点发送隐性位,接收节点正确接收后发送显性
  • FD报文中所有节点最多可正确接收两位显性ACK

ACK界定符(DEL)

  • 界定ACK
  • 固定格式,1个隐性位

EOF

  • 表示数据帧结束
  • 固定格式,7个连续的隐性位

CAN 与ISO CAN FD 报文格式对比( 标准帧)

CAN 与ISO CAN FD 报文格式对比( 扩展帧)

Classic CAN Standard Frame标准帧(不考虑位填充)共:108Bit

帧起始(1bit)、仲裁段(12bit)、控制段(6bit)、数据段(8×8bit)、循环冗余码段(16bit)、应答段(2bit)和帧结束(7bit)

Classic CAN Extended Frame扩展帧(不考虑位填充)共:128Bit

帧起始(1bit)、仲裁段(32bit)、控制段(6bit)、数据段(8×8bit)、循环冗余码段(16bit)、应答段(2bit)和帧结束(7bit)

CANFD Standard Frame标准帧(不考虑位填充;DLC = 8)共:117Bit

帧起始(1bit)、仲裁段(12bit)、控制段(9bit)、数据段(8×8bit)、循环冗余码段(22bit)、应答段(2bit)和帧结束(7bit)

CANFD Standard Frame标准帧(不考虑位填充;DLC = 64)共:569Bit

帧起始(1bit)、仲裁段(12bit)、控制段(9bit)、数据段(64×8bit)、循环冗余码段(26bit)、应答段(2bit)和帧结束(7bit)

CANFD CAN Extended Frame扩展帧(不考虑位填充;DLC = 8)共:136Bit

帧起始(1bit)、仲裁段(32bit)、控制段(8bit)、数据段(8×8bit)、循环冗余码段(22bit)、应答段(2bit)和帧结束(7bit)

CANFD CAN Extended Frame扩展帧(不考虑位填充;DLC = 64)共:588Bit

帧起始(1bit)、仲裁段(32bit)、控制段(8bit)、数据段(64×8bit)、循环冗余码段(26bit)、应答段(2bit)和帧结束(7bit)

单个帧的"负载率"

对Classic CAN Standard Frame标准帧来说,发送一帧实际长度(不考虑位填充;帧间隔3Bit;DLC = 8):108+3=111Bit;

比特率/波特率 一个Bit的位时间 单个帧的"负载率"
250 Kbps 4000纳秒 ((111 * 4000纳秒) / 1秒) *100%= 0.0444%
500 Kbps 2000纳秒 ((111 * 2000纳秒) / 1秒) *100%= 0.0222%
1 Mbps 1000纳秒 ((111 * 1000纳秒) / 1秒) *100%= 0.0111%

对Classic CAN Extended Frame扩展帧来说,发送一帧实际长度(不考虑位填充;帧间隔3Bit;DLC = 8):

128+3=131Bit;

比特率/波特率 一个Bit的位时间 单个帧的"负载率"
250 Kbps 4000纳秒 ((131 * 4000纳秒) / 1秒) *100%= 0.0524%
500 Kbps 2000纳秒 ((131 * 2000纳秒) / 1秒) *100%= 0.0262%
1 Mbps 1000纳秒 ((131 * 1000纳秒) / 1秒) *100%= 0.0131%

对CANFD Standard Frame标准帧来说,发送一帧实际长度(不考虑位填充;帧间隔3Bit;DLC = 8;启用BRS位加速):117+3=120Bit

其中:

  • 29Bit使用仲裁段波特率:1位SOF段,12位仲裁段,1位IDE,1位FDF,1位R0,1位BRS,2位ACK段,7位EOF段,3位帧间隔;
  • 91Bit使用数据段波特率;1位ESI,4位DLC,64位数据段,22位CRC段。
比特率/波特率 一个Bit的位时间 单个帧的"负载率"
仲裁段500 Kbps 2000纳秒 ((29 * 2000纳秒) / 1秒) *100%= 0.0058%
数据段2 Mbps 500纳秒 ((91 * 500纳秒) / 1秒) *100%= 0.00455 %
单个帧的"负载率" 0.01035%

对CANFD Standard Frame标准帧来说,发送一帧实际长度(不考虑位填充;帧间隔3Bit;DLC = 64;启用BRS位加速):569+3=572Bit;

其中:

  • 29Bit使用仲裁段波特率:1位SOF段,12位仲裁段,1位IDE,1位FDF,1位R0,1位BRS,2位ACK段,7位EOF段,3位帧间隔;
  • 543Bit使用数据段波特率;1位ESI,4位DLC,512位数据段,26位CRC段。
比特率/波特率 一个Bit的位时间 单个帧的"负载率"
仲裁段500 Kbps 2000纳秒 ((29 * 2000纳秒) / 1秒) *100%= 0.0058%
数据段2 Mbps 500纳秒 ((543 * 500纳秒) / 1秒) *100%= 0.02715%
单个帧的"负载率" 0.03295%

对CANFD Extended Frame扩展帧来说,发送一帧实际长度(不考虑位填充;帧间隔3Bit;DLC = 8;启用BRS位加速):136+3=139Bit;

其中:

  • 48Bit使用仲裁段波特率:1位SOF段,32位仲裁段,1位FDF,1位R0,1位BRS,2位ACK段,7位EOF段,3位帧间隔;
  • 91Bit使用数据段波特率;1位ESI,4位DLC,64位数据段,22位CRC段。
比特率/波特率 一个Bit的位时间 单个帧的"负载率"
仲裁段500 Kbps 2000纳秒 ((48 * 2000纳秒) / 1秒) *100%= 0.0096%
数据段2 Mbps 500纳秒 ((91 * 500纳秒) / 1秒) *100%= 0.00455%
单个帧的"负载率" 0.01415%

对CANFD Extended Frame扩展帧来说,发送一帧实际长度(不考虑位填充;帧间隔3Bit;DLC = 64;启用BRS位加速):588+3=591Bit;

其中:

  • 48Bit使用仲裁段波特率:1位SOF段,32位仲裁段,1位FDF,1位R0,1位BRS,2位ACK段,7位EOF段,3位帧间隔;
  • 543Bit使用数据段波特率;1位ESI,4位DLC,512位数据段,26位CRC段。
比特率/波特率 一个Bit的位时间 单个帧的"负载率"
仲裁段500 Kbps 2000纳秒 ((48 * 2000纳秒) / 1秒) *100%= 0.0096%
数据段2 Mbps 500纳秒 ((543 * 500纳秒) / 1秒) *100%= 0.02715%
单个帧的"负载率" 0.03675%
相关推荐
Renderbus瑞云渲染农场7 小时前
云渲染与汽车CGI图像技术优势和劣势
汽车
美格智能10 小时前
美格智能5G车规级通信模组: 5G+C-V2X连接汽车通信未来十年
5g·汽车
车载诊断技术10 小时前
电子电气架构 --- 整车控制系统
网络·架构·汽车·soa·电子电器架构
叫我:松哥16 小时前
基于python多准则决策分析的汽车推荐算法设计与实现
python·算法·数据挖掘·数据分析·汽车·推荐算法
ACRELKY16 小时前
新能源汽车与公共充电桩布局
汽车
来可小闵儿18 小时前
智诊小助手-AP/Station模式切换
汽车·电脑
思茂信息1 天前
CST汽车天线仿真(双向混合求解)
javascript·人工智能·5g·汽车·ar·软件工程
朗迪锋2 天前
虚拟现实辅助工程技术如何加速汽车设计与制造
汽车·制造·vr
李恒-聆机智能专精数采2 天前
从零开始了解数采(十二)——汽车锂电池板自动装配线数据采集方案
大数据·数据挖掘·云计算·汽车·边缘计算·制造·数据可视化
EVERSPIN2 天前
汽车车辆控制单元SRAM存储解决方案
汽车