阅读指引：

1. 术语过多，故各术语在第一次出现时解释，跳读时遇到不明的词可向上搜索看看；

2. 信息量过大，很多细节没有展开，正文只写多数人可以了解的基础知识，请按需点击文中链接详情。

1 综述

CAN，Controller Area Network，直译是控制器局域网，如字面意思是连接多个控制器的一种网络结构。它具体是以总线（bus）拓扑结构连结、按特定数据协议传输的，因此中文常叫做CAN总线。首次发布于1986年的CAN历史悠久，有众多公司和组织参与优化完善，2015年发布了第二代CAN FD，2020年推出第三代CAN XL。CAN的软硬件实现方式已形成ISO国际规范（specification），其网络数据传输方式也称为CAN协议，不过CAN协议只定义了物理层和数据链路层。基于CAN的应用层协议也很多，最典型的是OBD汽车诊断。由于实现和维护都较简单，CAN已被用于汽车外的很多领域。

围绕CAN底层的软件开发都属于嵌入式开发领域，需要查阅众多规范，并对C语言和芯片寄存器控制有深入了解。总体来说门槛较高，但日常写代码的工作量减少，时间多花在设计调试上。类比我们熟知的领域，CAN的应用层开发就像是使用了底层有自动重传机制的UDP广播，这是相对简单的。

CAN的数据链路层协议是由硬件芯片实现的，和我们日常用的网卡一样，所以出故障的可能性极小。而应用层的业务需求通常都较简单，很容易复现，在开发自测阶段应能发现和解决。在真实应用中，故障基本都出在物理层——某种原因导致的断路。

2 应用领域

CAN的诞生是为了解决汽车中ECU（Electronic Control Unit，电子控制单元）间的数据交互问题。随着大规模应用检验和规范完善，CAN目前还被用于很多工业自动化领域，例如：

1. 工业机械设备：包装、塑料成型、纺织、耕种、冷冻柜、打印机、半导体制造、磨刀砂轮等

2. 其它交通领域：火车内通信、售票机、滑翔机、轮船、潜艇、摩托车等

3. 建筑自动化：电梯

4. 医疗系统：手术室、病床、血液分析仪等

5. 餐厅设备：咖啡机

6. 实验室设备：核子研究、磁学与物理性质测量等。

3 优劣

车载网络拓扑结构选择的考虑点有：成本、可靠性、时延和带宽速率。注：拓扑结构基础知识参考百度百科-拓扑结构。

选择CAN的考虑点：

1. 跟其它拓扑结构（星形、环形等）比，总线结构能省线材。线材少意味着成本少，布线工作量少，车能减重就能降能耗。汽车线束重量每增加50kg，每百公里油耗会增加0.2L。优化车载网络设计，能减少9~17kg，电缆长度缩短200~1000m。

2. 可靠性，在物理层表现为通过差分电压和屏蔽双绞线抗电磁干扰，数据链路层主要表现在加入CRC检验等多种措施来发现错误，还有关闭节点发送功能来防止持续错误。

3. 跟传统以太网的数据链路层比（我们熟知的“MAC地址”在这一层），CAN每帧（frame）的bit更少

4. 跟车载以太网比，车载以太网在成本、带宽上胜出，但延时较大、实现较复杂，且沿用CAN的系统设计改动少，还需时日才能替换。

简单地说，各类网络的选择都已经取得成本和带宽间的平衡，没有绝对的优劣，CAN就是成本和带宽双低。车载网络的开发模式是先设计后选择，而不是先选择高性能且贵的部件。

多种车载网络的对比，请参考文章：智能汽车中的CAN会被以太网替代吗？

4 层次模型

多节点示意图：

从图中可知：

1. 各节点通过两根导线相连，是并联的关系。

2. 通过提高CAN_H导线的电压且降低CAN_L导线的电压，来实现发数据。即默认电压代表数字“1”，电压变化后为“0”。

3. 一方发数据改变电压，全体都能检测到。这也就是广播。

4. 发数据的时候也能同时监听。如果同一时刻，自己发“1”不会改变电压，而别人发“0”改变了电压，这就能知道除了自己还有别人在发数据。此时就需要冲突仲裁和排错机制，见下文。

典型的单节点层次模型与作用：

注：

1. 实际的系统（电路）设计更复杂，见下文的MCU方案。

2. SOC：System on Chip，系统级芯片。日常交流中意为ECU的主控芯片。

3. BootLoader：嵌入式系统的系统引导程序，相当于PC的BIOS。请参考百度百科-BootLoader。

4. SPI：Serial Peripheral Interface，串行外设接口。它可以使单片机与各种外围设备以串行方式进行通信以交换信息。外围设备包括Flash存储、网络控制器、LCD显示驱动器、A/D转换器和MCU等。

5. MCU：Micro Control Unit，微控制单元，也叫单片机。具体介绍请参考百度百科-MCU。

6. TX/RX：transmit发送/receive接收 的缩写。

特别注意：

• 狭义的CAN，指的是物理层和数据链路层。简单地以“CAN”作为关键字去搜索，都是这两层的知识。

• 广义的CAN，包括应用层协议，主流有3种，互不兼容，见下文。

下文如无说明是“应用层”的内容，默认指狭义CAN。

5 分层介绍

5.1 历史与类型版本

CAN协议有多个版本和类型，需要做好区分。

先整理术语如下：

• BOSCH：德国 博世 公司，CAN的发明者，全球第一大汽车技术供应商。

• 中国官网：https://www.bosch.com.cn/

• CiA：CAN in Automation，德国的CAN自动化协会，有很多家成员单位，是一些CAN规范的提出者。

• 官网：https://www.can-cia.org

• 百科百科：https://baike.baidu.com/item/CIA/920128

• SAE：Society of Automotive Engineers，美国汽车工程师学会，一些CAN规范的提出者。自动驾驶级别（即日常说的L2、L3等）的美国标准也是由它定。

• 官网：https://www.sae.org/

• 百科百科：https://baike.baidu.com/item/SAE/3657709。

• ISO：International Organization for Standardization，国际标准化组织，目前的CAN标准维护者。

• 官网：https://www.iso.org/

• 经典CAN：Classical CAN，指CAN FD之前的规范，包括BOSCH发明的CAN 1.0、2.0以及ISO收编后的ISO 11898-1协议。

• CAN FD：CAN with Flexible Data rate。业界称为第二代CAN总线。

• CAN XL：CAN Extra Long。业界称为第三代CAN总线，由CiA提出，主要为了跟车载以太网竞争。CiA对它的官方介绍：Controller Area Network Extra Long (CAN XL)

• CAN frame/帧：有两种，以帧中的ID段的bit位数区分。有【CAN 2.0A规定的11bit ID的标准帧】和【CAN 2.0B规范的29bit ID的扩展帧】。

简史：

1. 1983年，BOSCH开始内部开发车身网络（in-vehicle network）

2. 1986年，BOSCH在SAE大会发布CAN

3. 1991年，BOSCH发布CAN 2.0，包括2.0A和2.0B两部分（即标准CAN和扩展CAN）注：CAN2.0比1.0多了扩展帧的定义，跟高低速CAN没有关系。总线上可同时有标准帧和扩展帧。

4. 1993年起，ISO收编发布CAN规范

5. 2015年，ISO发布CAN FD。CAN FD实际是从2011年开始开发。

6. 2020年，CiA推出CAN XL。

以上仅需理解“历史悠久，参与者众多”即可。详细请参考：汽车的中枢神经系统——CAN总线简介。

各类CAN速率对比：

ECU会根据用途选择合适的CAN总线速率：

1. 低速总线，对数据的实时性要求较低，无关行车安全。例如灯光、雨刮、座椅、门锁、后视镜、空调、胎压等。注：部分也可能被LIN总线代替。

2. 高速总线，需要实时计算，例如发动机、ABS、安全气囊、电控悬架、巡航、电池、ESP、EPS、能耗、尾气排放量等

各类CAN的帧格式都不同，不同类的CAN帧是通过特定的bit来标记识别的（详见下文协议介绍），均实现了向后兼容。即经典CAN设备能接收并可能忽视CAN FD帧，但不能发出经典CAN帧，否则会使CAN FD设备解析错乱。兼容方式参考文章：CAN-FD兼容CAN的三种方式。

实际应用中，不同类的CAN会独立分出一路总线，再通过网关转换来通信。理想情况下，仪表ECU会作为网关，网络组成如下：

多路CAN的实际例子，请参考：小鹏P7内部ECU技术信息梳理_懂车帝。

下图再简单梳理一下类型关系。

5.2 物理层

线束和接头见下文“硬件成本”一节，有样件图。

CAN的线束只有两根导线，根据其上的电平不同，分别命名为高电平的CAN_H和低电平的CAN_L。接线时需要注意，接反就不能正常工作。这两根线的塑料外皮颜色是不同的。

CAN收发器的作用是把上层数据转换成电信号通过总线发出去，以及把收到的电信号转换为数据（数字信号，0和1表示）。收发器本身只是个IC（简单的集成电路），规格分支持哪类CAN总线、电流电压等，只要外围电路按照规范来设计就能直接用。

工业用途的CAN收发器，至少还会做到：

1. 带电流限制、过热警告等功能的低损耗电压调节器

2. 多种低功耗运行模式，且支持多种唤醒模式

3. 极低的休眠/待机电流

4. 抗射频干扰，去噪

5. 看门狗、中断和复位可软件编程

6. 高级版支持更多功能特性的可编程控制

关于功耗，收发器和控制器都有睡眠模式等低功耗模式，由芯片或ECU控制切换。图例：

CAN收发器的详细介绍可参考：高速CAN总线收发器TJA1043（NXP）。

5.3 数据链路层

5.3.1 协议

数据链路层的协议模型：

具体的LLC、MAC子层内容可参考汽车总线CAN网络分层机构 --3。以上了解即可，不重要。

CAN2.0定义了两种帧格式，2.0A即标准帧，使用11bit的ID；2.0B即扩展帧，使用29bit的ID。可在帧数据中根据IDE标识符做判断。图示：

CAN FD和CAN XL的帧格式介绍请参考：下一代CAN通信技术CAN XL简介。了解即可。

应用层只收发ID、DLC（数据场长度）和Data Field（数据场）——可结合下文的DBC一节来理解。

ID的知识点：

1. CAN帧中包含ID，在数据链路层只起到优先级判断的作用。ID的数值越小，CAN帧的优先级越高，会获得总线控制权。多节点同时开始发送数据时，按照电路设计，ID按每一bit传输时，ID小的数据会覆盖ID大的值，即0&1=0，此时只要判断到自己发出的bit1实际是收到bit0，就停止发送后续的bit，稍后重试。

更详细的解答请参考 CAN总线原理-精华整理。

2. CAN ID值的业务意义由应用层决定。一种典型用法是，部分bit代表消息类型，部分bit代表发送者设备，即ID和设备绑定。只要ID的前几bit代表设备号，后几bit代表业务值，就能兼顾优先级判断的规范。

数据场的知识点：

3. 数据场是放高层业务数据的地方。

4. 数据链路层协议只规定了一帧的格式，数据跨越多帧的情况由应用层协议实现拆包和重组。详细介绍：CAN总线多帧发送方式

5. 经典CAN，数据场最多8bytes；CAN FD最多64bytes；CAN XL最多2048bytes，即一帧可以有更多业务数据。当一帧的业务数据量>8且<64时，用CAN FD就不需要在业务层把数据拆成多帧和重组了，这也提升了性能。

更具体的协议内容比较多，本文不会展开讲，可参考多篇链接的文章。

5.3.2 控制器

协议的实现由CAN控制器负责，它是个独立的MCU，根据型号，可以对接1个或多个CAN收发器。对接多个时，也就相当于成为多路CAN的集线器了。只对接1个收发器的独立控制器结构图如下：

实际上控制器有两种硬件构成方案：

1. SOC控制器（或SOC的协处理器MCU） + 独立CAN控制器 + CAN收发器。使用独立CAN控制器程序复用移植性较好，但占用主控芯片I/O资源。

2. SOC+集成了CAN控制器模块的MCU + CAN收发器。该方案程序复用性不佳，有很强针对性，但可以使电路更加简单。

CAN控制器只会把正常的帧传递到SOC，在内部进行数据链路层的错误处理。没有部件记录详情，ECU只可读取寄存器了解基本信息，如错误计数、最近一次的错误类型。

CAN控制器是需要被编程控制的，根据芯片规范，SOC要在驱动层正确地初始化和动态控制CAN控制器。

5.3.3 报文过滤

过滤的目的是使SOC只接收到该ECU需要处理的数据。

消息过滤是根据CAN ID做的，因为都是业务需求，每个ECU都知道自己只处理哪些ID的信号。

有几种实现方式：

1. CAN控制器自带的验收屏蔽寄存器和验收滤波寄存器，可以过滤掉不想要的报文。只要SOC对其做设置即可。（像操作系统设置网卡属性）

2. SOC或协处理器MCU来实现编程实现。通常在MCU中实现，不占用SOC的资源。（像软件网络代理）

3. 网关中设置某路的CAN哪些消息不转发到这路CAN。（像设置路由器）

信号（消息的具体内容）过滤需要解析数据场的数据，只能MCU实现。关于信号请参考DBC一节。

5.3.4 CAN故障

主要有这几类：

1. 电磁辐射干扰；

2. 工作电压不正常，包括电源故障、电路元件不符合电路设计规范（含电阻阻抗不对）等；

3. 各类原因导致的线路短路、断路，包括线松、线断、潮湿、线接错等。

4. 线路物理性质变化引起通信信号衰减或失真，如高温

5. ECU故障，即传输协议或软件程序有bug

数据链路层本身的出错概率非常小，各种芯片都很成熟了，只是通常在这层入手排查物理层问题，物理层的故障通常需要电子工程师用CANoe（见下文）、示波器、万用表来检测，具体请参考：

1. CAN总线故障的常见故障与万用表检修方法

2. can总线故障一般原因及问题解决方法 - 全文 - 接口/总线/驱动 - 电子发烧友网

3. 《带您全面认识“CAN总线错误”》系列文章，一、二、三、四。

由于应用层都是脚本自动化生成代码，高层框架也成熟，这层出bug应该是必现的。正如CAN的名字里有“局域网”，本地网络的问题风险相对可控。

5.3.5 CAN BUS OFF问题

测试和预警方案：

1. 测试触发方法：参考说说Busoff那点事。

2. 可以对BUS OFF打log警告，log时机（根据具体芯片规范）有BUS OFF回调机制或定时读取芯片寄存器

更多参考资料：

1. CAN总线报文格式—错误帧

2. CAN通信：Busoff问题知多少，CAN通信基础：错误帧

3. 基础涨知识篇：CAN总线错误分析与解决。一个根因不同的CAN BUS OFF例子，更详细地解释了BUS OFF的排查手段。

5.4 内核驱动层

嵌入式软件开发中，CAN总线数据收发的实现方案经历过一些迭代，最终在Linux形成SocketCAN方案，即内核用socket模型来封装底层实现，应用层只需给socket API设置特定参数即可。内核的net模块根据这些参数来确定是否以及怎样调用CAN驱动，同时内核也能提供socket缓冲区。socket封装的结果请参考下文的应用层代码示例。

内核驱动层需要正确初始化CAN控制器，按照芯片规范要求实现数据读写，处理硬件中断。通常芯片或板子供应商都会提供成熟的驱动程序，且已按客户要求做了最佳配置。

这层的具体工作请参考下文应用层的例子，更多详细介绍请参考：

1. Linux内核官方关于SocketCAN的介绍： Readme file for the Controller Area Network Protocol Family

2. 内核与驱动层的实现介绍：SOCKET CAN的理解

5.5 应用层

5.5.1 SocketCAN应用实例

以下是经简化的C++ 11代码片段，了解跟普通socket编程的差异即可，不用深入理解：

#include <linux/can.h>
#include <sys/socket.h> //PF_CAN SOCK_RAW
#include <net/if.h>     //struct ifreq
#include <sys/ioctl.h>

// Open
int m_fd = socket(PF_CAN, SOCK_RAW, CAN_RAW); 
struct ifreq ir;
strncpy(ir.ifr_name, m_filePath.c_str(), IFNAMSIZ - 1);  // m_filePath = "can0"
ioctl(m_fd, SIOCGIFINDEX, &ir)
ir.ifr_ifindex = if_nametoindex(ir.ifr_name);
struct sockaddr_can addr;
addr.can_family = AF_CAN;
addr.can_ifindex = ir.ifr_ifindex;
bind(m_fd, (struct sockaddr *)&addr, sizeof(addr))

// Read，子线程中执行
struct can_frame frame; // 收发CAN frame，对socket的read/write调用每次都是一帧。

fd_set fs_read;
FD_ZERO(&fs_read);
FD_SET(m_fd, &fs_read);

struct timeval out;
out.tv_sec = 0;
out.tv_usec = 1000 * 100;

auto fs_sel = select(m_fd + 1, &fs_read, nullptr, nullptr, &out);
if (fs_sel > 0) {
    auto cnt = read(m_fd, &frame, sizeof(frame));
    if(cnt==0){
        LOG_NORMAL_ERROR("can file|read close,{}",m_filePath);
    }else if(cnt<0){
        LOG_NORMAL_ERROR("can file|read error,{},{}",strerror(errno),m_filePath);
    }else{
        memcpy(buff, &frame.can_id, 4);
        memcpy(buff + 4, &frame.data, 8);
        return 12;    
    }
}

// Write
struct can_frame frame;
memset(&frame, 0, sizeof(frame));
memcpy(&frame.can_id, buff, 4);
memcpy(frame.data, buff + 4, 8);
if(frame.can_id>0x7ff){
    frame.can_id |= CAN_EFF_FLAG;
}
frame.can_dlc = 8;

auto cnt = write(m_fd, &frame, sizeof(frame));

5.5.2 主流协议

应用层协议有好几种，主流的是3种：

1. CANopen：基于CAN2.0A定义的标准帧，由CiA提出和维护。最初是为工业自动化设计的，但很快应用在了其它领域。具体介绍：什么是CANopen总线协议？CANopen通信协议概述周立功的教学：CANopen 轻松入门 入门教程CiA官方规范分成了多份，下载入口：https://www.can-cia.org/groups/specifications/

2. J1939：基于CAN2.0B定义的扩展帧，由SAE提出。多用于重型机械，如大巴、挖掘机、拖拉机、坦克、消防车等。具体介绍：从应用角度来讲讲J1939协议

3. DeviceNet：基于CAN2.0A定义的标准帧，由美国的Allen-Bradley公司所开发。主要应用包括资讯交换、安全设备及大型控制系统，在美国的市场占有率较高。比起CANopen，对物理层的要求更严格，从而使得不同厂商的设备更通用。具体介绍：CAN应用层协议详解之DeviceNet协议

协议具体内容太多，多数人不用学习。我们了解这些即可：

1. 三者互不兼容

2. 都对CAN ID再做了规范，即对数据链路层的ID值是有要求的。

经典CAN的一帧只有8 bytes的内容，如果数据>8bytes，是需要在应用层拆包和重组的。这对于实时性有一定的影响，还要考虑后面的帧收不到的场景，所以最好是设计时就做到数据只在一帧内表示完毕。实际应用中数据经常会超出可表示的范围，可以在业务层约定，最终值是通过怎样的公式计算转换出来的，从而使量程符合要求。例如1byte=8bit，可表示0~255，约定最终值要乘以2在加3，则1byte可表示3~513。这个约定可以在DBC（见下文）中表示。有些约定也成为了通用标准，但具体车厂车型会有自定义的部分。

注：AutoSAR为UDS定义了CAN-TP（Transport Layer）协议来拆包和重组，但按定义，这协议算是传输层。请看考 AUTOSAR使用小技巧——CanTp模块大揭秘！。

上述主流协议是通用的，还有专用的规范协议，例如OBD（见下文）。

5.5.3 DBC

DBC：DataBase CAN，是Vector公司（见工具一节的介绍）定义的描述CAN帧业务层规范的文件格式，文件后缀名即.dbc。

简单总结，DBC定义了：

1. 每个ECU会发出的消息（Message）及这些消息对应的CAN ID。也就是说，根据CAN ID可以反推消息是哪个ECU发出的。

2. 每种消息的长度（0~64字节），即CAN帧的数据场的长度

3. 消息的数据场每bit或bit组合代表的意义，称为信号（signal）。一个消息内可以有多个信号

4. 每个信号在数据场中的起始bit位置、长度，上层解析的数据类型、取值范围、枚举定义、计算公式、单位、周期消息的发送间隔、接收者等。

DBC相当于不同ECU的开发人员间的协议文档，特定软件可导入后以此解析CAN帧，支持所有的数据链路层以及应用层CAN协议。这已成为行业惯用工具，实际上不只Vector公司的软件使用DBC，周立功也可以用。

规范文档请见：格式规范文档。由于有规范，所以可以用脚本解析再自动生成高级编程语言的代码。

更多详情：

5. 具体介绍：CAN通信 DBC文件解析

5.5.4 独立控制器方案

系统框架图简化版：

SOC软件层的细分层工作：

1. BootLoader：把SPI接口映射到内存空间地址，初始化寄存器。配置由板子供应商提供

2. 驱动层：初始化控制器通信，注册内核中断号，实现基于SPI的can_frame读写系统代码路径：/kernel/drivers/net/can/spi/mcp251x.c，由芯片供应商提供，板子供应商打包给出。

3. 内核层：加载驱动，映射CAN总线为(/dev/)can0，在socket实现层调用驱动

4. App socket层代码示例见上文。

5. App业务层，根据帧ID确定信号类型并解析数据，再按业务协议继续执行。解析和组帧的代码可以用脚本根据DBC自动生成。

5.5.5 自开发MCU方案

系统框架图简化版：

注：

1. UART：Universal Asynchronous Receiver/Transmitter， 通用异步收发传输器。通信的两端可各自有一块芯片，或该功能模块内置于SOC中。详细介绍：串口通信（UART）介绍

MCU相当于一个集线器HUB，把多路CAN信息整合起来后再与SOC通信，也相当于一个协处理器。MCU要做到屏蔽CAN信号来源，就需要记录每个CAN ID的路由，即具体的CAN ID应通过哪个收发器收发。由于硬件是固定的，这个路由表可以写死在MCU代码或配置文件里。

5.6 HUB与网关

网关的作用就是在不同种类的网络间转发消息，核心功能是协议解析转换，典型应用为：

• 连接不同速率的CAN网络

• 连接CAN和车载以太网

• 连接CAN和WiFi网络

• 连接CAN和串口RS232toUSB，供调试诊断用

它可以是独立设备、独立ECU或者SOC中的某个软件模块：

• 独立设备就像我们日常用的因特网路由器一样，只是车载网关设备通常连接了多种网络，且符合车规级要求。一些高级的设备支持更多的设置，如帧过滤、监控记录、错误报警等，甚至可以做二次开发。

• 独立ECU是自己开发的网关设备，可以耦合特定的业务逻辑，通常需要在内存中维护一些状态才能对消息进行处理。自己开发的挑战：如何实现低成本、高可靠、易维护。参考周立功的用户手册可了解下难度。

• 假如消息量不大，处理过程占用SOC CPU不多，可以由SOC直接在软件层实现。

常见的网关设备有：

1. CAN2Eth，CAN转以太网：一种CAN总线和以太网互通数据的中转设备。可通过软件或网页配置，支持TCP Server、TCP Client、UDP Client、UDP Broadcast模式。支持帧过滤。例子：某ECU Client在以太网连接上作为TCP Server的网关，能按网关协议收发CAN数据，由网关在CAN网络转发和监听。注：CAN口数据包和网口数据包用透传方式通信。

2. Tbox：本质是个独立的网关ECU，可桥接CAN、车载以太网、WiFi、4G/5G、蓝牙。现在正处于车联网快速发展的阶段，各厂家都在推出自己的特有功能，所以是还没标准化的，需要进行嵌入式开发，有专门的Tbox软件开发岗位。

6 开发测试

6.1 MCU开发简介

一个典型的开发流程：

1. 明确任务分析和了解项目的总体要求，并综合考虑系统使用环境、可靠性要求、可维护性及产品的成本等因素，制定出可行的性能指标。

2. 划分软、硬件功能MCU由软件和硬件两部分，有些功能既可由硬件来实现，也可以用软件来完成。硬件的使用可以提高系统的实时性和可靠性;使用软件实现，可以降低系统成本，简化硬件结构，合理地制定硬件和软件任务的比例。

3. 确定芯片及其他关键部件根据硬件设计任务，选择能够满足系统需求并且性价比高的芯片及其他关键器件，如A/D、D/A转换器、传感器、放大器等，这些器件需要满足系统精度、速度以及可靠性等方面的要求。

4. 硬件设计根据总体设计要求，以及选定的芯片及关键器件，利用软件设计出应用系统的电路原理图。

5. 软件设计在系统整体设计和硬件设计的基础上，确定软件系统的程序结构并划分功能模块，然后进行各模块程序设计。

6. 仿真调试软件和硬件设计结束后，需要进行进行进入两者的整合调试阶段。为避免浪费资源，在生成实际电路板之前，可以利用软件进行系统仿真，出现问题可以及时修改。

7. 系统调试完成系统仿真后，利用绘图软件，根据电路原理图绘制PCB(Printed Circuit Board)，即印刷电路板图，然后将PCB图交给相关厂商生产电路板。拿到电路板后，为便于更换器件和修改电路，可首先在电路板上焊接所需芯片插座，并利用编程器将程序写入MCU。然后将MCU及其他芯片插到相应的芯片插座中，接通电源及其他输入、输出设备，进行系统联调，直至调试成功。

8. 测试修改、集成试用经测试检验符合要求后，与ECU其它部件以及对手件集成联调，对于出现的实际问题进行修改完善，系统开发完成。

可以通过一个实例了解下CAN开发面对的问题：CAN总线指定帧唤醒的硬件实现方式。

MCU软件开发和系统及应用开发的不同点：

1. 更深入了解硬件，看协议规范，掌握电子电气基础知识。在各类总线规范之上，还有AutoSAR规范等。

2. 要使用示波器、外接LED灯、仿真器等工具调试

3. 使用C语言开发为主，没有API，直接对内存地址读写即是操作硬件。需要考虑编译结果，例如某段代码必须放在数据段还是代码段。

4. 芯片厂商会提供驱动、上层应用示例，还可能有开发IDE。由于历史悠久，现成产物多，多数工作是适配新板子

5. 功耗是重要的性能指标，多种低功耗模式的切换过程是最复杂的场景之一。

6. 异常主要由硬件引起，关注电平滤波、整形、时间同步等问题。

7. 对口专业：电子信息、计算机科学与技术

8. 人力成本参考：一线城市5年工龄内大专本科，月薪8~25k

6.2 硬件成本

简述：最简线路的物理层+数据链路层在10块钱内（批发价哈）。网关价格中值需要5千元。仿真测试设备需要5万元+。

芯片的知名厂商：

1. NXP：荷兰 恩智浦 半导体公司，车载设备的供应商。前身是飞利浦半导体事业部。车载芯片领域在高通进入前是由NXP主宰。

2. Microchip：美国 微芯半导体 公司，全球领先的单片机和模拟半导体供应商。

3. Renesas：日本 瑞萨 公司，世界十大半导体芯片供应商之一。

软硬件开发工具的厂商：

1. Vector：德国 维克多 公司，是总线开发工具、网络节点测试验证工具和嵌入式软件组件供应商，为汽车总线网络的设计、建模、仿真、分析、测试以及ECU的开发、测试、标定和诊断等领域提供一系列强有力的软硬件工具和源代码。

2. 周立功、ZLG：公司名为广州致远电子股份有限公司，官网 https://www.zlg.cn/。创始人就名为周立功，关于他的介绍可参考百度百科。公司总部位于广州市天河区，是一家工业互联网产品与解决方案供应商。也是CANopen协会CiA的会员。

材料价格表：

6.3 工具

6.3.1 Vector系列

Vector公司是车载网络开发工具领域的泰斗，软件主要有3款：

1. CANoe：CAN open environment，为汽车总线的开发而开发的一款集总线仿真、测试分析和诊断等功能为一体的图形化开发环境，实际还支持除CAN外的其它车载网络类型。需要绑定硬件使用（硬件成本和样件见上文），软件有多个版本，售价600~1500美元。详细介绍：CANoe与CANalyzer工具的区别开发过程视频：合集和视频列表-手把手教你CANoe，可理解如何仿真。

2. CANalyzer：功能上相当于CANoe的子集，价格也便宜一半。

3. CANape：CAN Application Programming Environment是一款可用于ECU测量、标定、诊断以及ADAS传感器数据记录验证的综合性工具软件。

与Vector相关软件有关的概念：

4. CANdb++：CANoe的附属工具，可单独使用，用于解析编辑DBC文件。教学视频：【北汇信息】CANoe培训视频 | 数据库搭建-生成CAN通信数据库_哔哩哔哩_bilibili

5. CAPL：Communication Access Programming Language，即通信访问编程语言。专门为CANoe配置的语言，主要用于仿真过程的编程。具体介绍：CANoe学习4—CAPL语言设计

由于Vector软硬件太贵，软件有破解，软硬件也有模仿。原理并不复杂，因为底层协议都已公开，只是做成商业化产品就要以功能和质量见高低了。CANoe的配套硬件是带有CAN控制器的，在实验室或实机诊断时，可以直接观察到数据链路层的错误，包括错误帧。

6.3.2 周立功

CAN盒（ZLG CANFDNET-400U）本身是CAN和以太网的网关，也具备调试分析功能。其配套软件是ZCANPRO，可免费下载使用。

CAN盒本身没有记录功能，是连上电脑后配套的软件可以记录在电脑，所以不能支持真机实飞过程的故障排查。它还支持二次开发，有多种开发语言的套件，给它外接一个SOC再做点开发工作是可以记录故障的，那就可用于监控。二次开发请参考：https://www.zlg.cn/can/down/down/id/255.html。

周立功另有分析仪CANScope，价格16万起。它是 CAN 总线开发与测试的专业工具，集海量存储示波器、网络分析仪、 误码率分析仪、协议分析仪及可靠性测试工具于一身，并把各种仪器有机的整合和关连；可对 CAN 网络通信正确性、可靠性、合理性进行多角度全方位的评估。详情参见CAN总线故障诊断与解决、测试方法。

6.3.3 Linux工具

can-utils工具可命令行收发CAN总线的消息。可apt install can-utils安装，开源地址为https://github.com/linux-can/can-utils。使用方法请百度，例如can-utils4.0.6使用方法。

6.4 记录与回放

CANoe和周立功的配套软件可以记录总线上的CAN帧数据，保存为文件：BINLOG files(.blf)、Vector ASCII logfiles(.asc)。根据这些记录，工具可以实现数据回放（见TSMaster快速入门篇（2）-报文回放 ），即往总线上按序重发这些数据。

6.5 标定

ECU的标定工作就是对ECU中的控制参数进行优化，使其满足发动机动力性、经济型、可靠性、安全性、排污性并确定各工况最佳空燃比、最佳点火提前角的要求。关于标定的目标，请参考发动机标定那些事-有驾。

这项工作有专门的岗位：标定工程师。为实现这一目的，标定工程师需要对不同参数进行获取（读操作）和标定（写操作），通过分析参数改变带来的性能变化，反复迭代更新后才能完成标定。为规范标定工作，常见的应用层标定标准有CCP（CAN Calibration Protocol，CAN标定协议）协议和XCP（Universal Measurement and Calibration Protocol）协议。其中XCP协议可在多种总线上使用，包括CAN。标定协议本身是不需要深入理解的，有多种现成的软件支持。关于软件怎么用，可参考视频：Vector CANAPE 标定基础视频_哔哩哔哩_bilibili

6.6 OBD

OBD，On-Board Diagnostics system。只讲些基础知识：

1. OBD有一套独立规范，在OSI网络七层模型的物理层、数据链路层、网络层、会话层、应用层都有规范。这些规范使得诊断仪可以不局限于用在一个厂家或车型。规范内容已经超出了CAN的范畴，只是其中的物理层和数据链路层可以基于CAN也可以基于车载以太网。简单来说就是规定了诊断仪发哪些CAN ID消息，各ECU要怎样响应。注：OBD定义了几种专门用途的CAN ID，在电路设计时需要避开。ECU实现响应这些ID的消息就是实现了OBD。详细介绍：OBD(On-Board Diagnostic)介绍

2. UDS：Unified Diagnostic Services，是诊断服务的统一化应用层规范，是OBD的增强型诊断。可以在CAN线上实现，也可以在车载以太网上再基于DoIP（Diagnostic over Internet Protocol）实现。UDS还不是行业标准，但已有很多车厂支持。更多介绍请参考：百度百科-UDS

3. ECU需要实现OBD协议，其中一个要求是记录错误。诊断仪发出OBD请求时，ECU需答复上报这些记录。在诊断仪发出清空记录的命令前，ECU不主动删除记录。

4. K线：在CAN未应用前，车辆主要使用K线进行诊断。是一条独立的双向传输线。

5. L线：用来对控制单元进行查询的导线，此线在目前生产的车辆中已经不存在。

6. OBD接口有I型和II型，分美标（SAE定义）和欧标（ISO定义）。使用CAN线做诊断时，需要注意接线位置。

7 知识体系

简单总结：

1. MCU开发测试的知识量不算大，而是深度大，门槛是更高的，但掌握后，工作量相对很少。

2. 信息量大，需要不断查阅软硬件规范，不太可能记住很多。这些信息量比Android App开发还多。

3. 因为已经是计算机最底层，需要对原理的理解和掌握程度非常高。

4. 软件开发方面，大头不在于写代码，而是验证程序逻辑符合各种规范和业务要求。

书籍入门：

1. 汽车CAN总线系统原理、设计与应用

2. CAN总线的技术及应用教程

3. CAN总线轻松入门与实践

延伸了解：

1. CAN是现场总线（Field Bus）的一种。Field之所以翻译成“现场”，是因为这些总线最初用于“现场解决问题”。更好理解是把Field翻译成“专业领域”。

2. 车载总线还有这几个：LIN、FlexRay、MOST、车载以太网、LVDS。

3. 轻松看懂汽车电路原理图

部分图片找不回原出处了，侵删，谢谢