阅读指引：

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的发明者，全球第一大汽车技术供应商。

• 中国官网：主页 | 博世在中国

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

• 官网：CAN in Automation (CiA): Controller Area Network (CAN)

• 百科百科：CIA（德国CiA协会）_百度百科

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

• 官网：The Mission of SAE International is to advance mobility knowledge and solutions

• 百科百科：SAE（美国汽车工程师学会）_百度百科。

• 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代表业务值，就能兼顾优先级判断的规范。
   

数据场的知识点：

1. 数据场是放高层业务数据的地方。
2. 数据链路层协议只规定了一帧的格式，数据跨越多帧的情况由应用层协议实现拆包和重组。详细介绍：CAN总线多帧发送方式
3. 经典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 fd = socket(PF_CAN, SOCK_RAW, CAN_RAW);
struct ifreq ir;
strncpy(ir.ifr_name, "/dev/can0", IFNAMSIZ - 1);
ioctl(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(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(fd, &fs_read);

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

auto fs_sel = select(fd + 1, &fs_read, nullptr, nullptr, &out);
if (fs_sel > 0) {
    auto cnt = read(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);
frame.can_dlc = 8;

auto count = write(fd, &frame, sizeof(frame));

5.5.2 主流协议

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

1. CANopen：基于CAN2.0A定义的标准帧，由CiA提出和维护。最初是为工业自动化设计的，但很快应用在了其它领域。具体介绍：什么是CANopen总线协议？CANopen通信协议概述周立功的教学：CANopen 轻松入门 入门教程CiA官方规范分成了多份，下载入口：CAN in Automation (CiA): Technical documents
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（见下文）中表示。有些约定也成为了通用标准，但具体车厂车型会有自定义的部分。

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

注2：AutoSAR的应用层还有一些机制，例如E2E，请参考关于AUTOSAR E2E及测试开发实践。

上述主流协议是通用的，还有专用的规范协议，例如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，周立功也可以用。

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

更多详情：

1. 具体介绍：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：公司名为广州致远电子股份有限公司，官网 ZLG致远电子-广州致远电子股份有限公司。创始人就名为周立功，关于他的介绍可参考百度百科。公司总部位于广州市天河区，是一家工业互联网产品与解决方案供应商。也是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相关软件有关的概念：

1. CANdb++：CANoe的附属工具，可单独使用，用于解析编辑DBC文件。教学视频：【北汇信息】CANoe培训视频 | 数据库搭建-生成CAN通信数据库_哔哩哔哩_bilibili
2. CAPL：Communication Access Programming Language，即通信访问编程语言。专门为CANoe配置的语言，主要用于仿真过程的编程。具体介绍：CANoe学习4—CAPL语言设计

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

6.3.2 周立功

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

CAN盒本身没有记录功能，是连上电脑后配套的软件可以记录在电脑，所以不能支持真机实飞过程的故障排查。它还支持二次开发，有多种开发语言的套件，给它外接一个SoC再做点开发工作是可以记录故障的，那就可用于监控。二次开发请参考：高性能以太网转CANFD设备-广州致远电子股份有限公司。

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

6.3.3 Linux工具

can-utils工具可命令行收发CAN总线的消息。可apt install can-utils安装，开源地址为GitHub - linux-can/can-utils: Linux-CAN / SocketCAN user space applications。使用方法请百度，例如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和UDS

• OBD，On-Board Diagnostics system，主要关注环保排放数据的诊断。 详细介绍：OBD(On-Board Diagnostic)介绍
• UDS，Unified Diagnostic Services，被汽车厂商增强地用于诊断所有ECU错误。 更多介绍：百度百科-UDS

两者都有自己的规范，跨越OSI网络七层模型的物理层、数据链路层、网络层、会话层、应用层。其中在某些层次的实现可能相同，也都可以基于CAN或车载以太网。简单来说，应用层协议都规定了诊断仪会发哪些CAN ID消息，各ECU要怎样响应。

一些额外的基础知识：

1. OBD的规范内容已经超出了CAN的范畴，它定义了几种专门用途的CAN ID，在电路设计时需要避开。ECU实现响应这些ID的消息就是实现了OBD。
2. UDS是诊断服务的统一化应用层规范，是OBD的增强型诊断。可以在CAN线上实现，也可以在车载以太网上再基于DoIP（Diagnostic over Internet Protocol）实现。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. 软件开发方面，大头不在于写代码，而是验证程序逻辑符合各种规范和业务要求。

CAN知识梳理

书籍入门：

1. 汽车CAN总线系统原理、设计与应用
2. CAN总线的技术及应用教程
3. CAN总线轻松入门与实践

延伸了解：

1. CAN是现场总线（Field Bus）的一种。Field之所以翻译成“现场”，是因为这些总线最初用于“现场解决问题”。更好理解是把Field翻译成“专业领域”。
2. 车载总线还有这几个：LIN、FlexRay、MOST、车载以太网、LVDS。
3. 轻松看懂汽车电路原理图

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