CAN总线协议
Posted hursing
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了CAN总线协议相关的知识，希望对你有一定的参考价值。
阅读指引：
术语过多，故各术语在第一次出现时解释，跳读时遇到不明的词可向上搜索看看；
信息量过大，很多细节没有展开，正文只写多数人可以了解的基础知识，请按需点击文中链接阅读更多详情。
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目前还被用于很多工业自动化领域，例如：
工业机械设备：包装、塑料成型、纺织、耕种、冷冻柜、打印机、半导体制造、磨刀砂轮等
其它交通领域：火车内通信、售票机、滑翔机、轮船、潜艇、摩托车等
建筑自动化：电梯
医疗系统：手术室、病床、血液分析仪等
餐厅设备：咖啡机
实验室设备：核子研究、磁学与物理性质测量等。
3 优劣
车载网络拓扑结构选择的考虑点有：成本、可靠性、时延和带宽速率。注：拓扑结构基础知识参考百度百科-拓扑结构。
选择CAN的考虑点：
跟其它拓扑结构（星形、环形等）比，总线结构能省线材。线材少意味着成本少，布线工作量少，车能减重就能降能耗。汽车线束重量每增加50kg，每百公里油耗会增加0.2L。优化车载网络设计，能减少9~17kg，电缆长度缩短200~1000m。
可靠性，在物理层表现为通过差分电压和屏蔽双绞线抗电磁干扰，数据链路层主要表现在加入CRC检验等多种措施来发现错误，还有关闭节点发送功能来防止持续错误。
跟传统以太网的数据链路层比（我们熟知的“MAC地址”在这一层），CAN每帧（frame）的bit更少
跟车载以太网比，车载以太网在成本、带宽上胜出，但延时较大、实现较复杂，且沿用CAN的系统设计改动少，还需时日才能替换。
简单地说，各类网络的选择都已经取得成本和带宽间的平衡，没有绝对的优劣，CAN就是成本和带宽双低。车载网络的开发模式是先设计后选择，而不是先选择高性能且贵的部件。
多种车载网络的对比，请参考文章：智能汽车中的CAN会被以太网替代吗？
4 层次模型
多节点示意图：
从图中可知：
各节点通过两根导线相连，是并联的关系。
通过提高CAN_H导线的电压且降低CAN_L导线的电压，来实现发数据。即默认电压代表数字“1”，电压变化后为“0”。
一方发数据改变电压，全体都能检测到。这也就是广播。
发数据的时候也能同时监听。如果同一时刻，自己发“1”不会改变电压，而别人发“0”改变了电压，这就能知道除了自己还有别人在发数据。此时就需要冲突仲裁和排错机制，见下文。
典型的单节点层次模型与作用：
注：
实际的系统（电路）设计更复杂，见下文的MCU方案。
SOC：System on Chip，系统级芯片。日常交流中意为ECU的主控芯片。
BootLoader：嵌入式系统的系统引导程序，相当于PC的Bios。请参考百度百科-BootLoader。
SPI：Serial Peripheral Interface，串行外设接口。它可以使单片机与各种外围设备以串行方式进行通信以交换信息。外围设备包括Flash存储、网络控制器、LCD显示驱动器、A/D转换器和MCU等。
MCU：Micro Control Unit，微控制单元，也叫单片机。具体介绍请参考百度百科-MCU。
TX/RX：transmit发送/receive接收 的缩写。
特别注意：
狭义的CAN，指的是物理层和数据链路层。简单地以“CAN”作为关键字去搜索，都是这两层的知识。
广义的CAN，包括应用层协议，主流有3种，互不兼容，见下文。
下文如无说明是“应用层”的内容，默认指狭义CAN。
5 分层介绍
5.1 历史与类型版本
CAN协议有多个版本和类型，需要做好区分。
先整理术语如下：
BOSCH：德国 博世 公司，CAN的发明者，全球第一大汽车技术供应商。
CiA：CAN in Automation，德国的CAN自动化协会，有很多家成员单位，是一些CAN规范的提出者。
SAE：Society of Automotive Engineers，美国汽车工程师学会，一些CAN规范的提出者。自动驾驶级别（即日常说的L2、L3等）的美国标准也是由它定。
ISO：International Organization for Standardization，国际标准化组织，目前的CAN标准维护者。
经典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的扩展帧】。
简史：
1983年，BOSCH开始内部开发车身网络（in-vehicle network）
1986年，BOSCH在SAE大会发布CAN
1991年，BOSCH发布CAN 2.0，包括2.0A和2.0B两部分（即标准CAN和扩展CAN）注：CAN2.0比1.0多了扩展帧的定义，跟高低速CAN没有关系。总线上可同时有标准帧和扩展帧。
1993年起，ISO收编发布CAN规范
2015年，ISO发布CAN FD。CAN FD实际是从2011年开始开发。
2020年，CiA推出CAN XL。
以上仅需理解“历史悠久，参与者众多”即可。详细请参考：汽车的中枢神经系统——CAN总线简介。
各类CAN速率对比：
CAN分类 | 速率 | 备注 |
容错CAN | 5Kbit/s~125Kbit/s间的某个固定值 | 其中一根线不工作还能靠另一根维持通路。相对而言也叫低速CAN。参考文章一文读懂容错CAN。 |
（普通）CAN | 125Kbit/s~1Mbit/s间的某个固定值，通常为500Kbit/s | 速率由电路决定，是个常量，通常速率越低，成本越低。在CAN FD没问世前，>125Kbit/s的CAN网络称为高速CAN。 |
第二代CAN FD | 可变速率，数据比特率最高8Mbit/s，通常为2Mbit/s | CANFD不叫3.0，因为1.0和2.0特指CAN帧中ID位数的区别，而CAN FD的区别是速率。 传输仲裁段时是2Mbit/s，传输数据段时最大是8Mbit/s。所以叫可变速率。 |
第三代CAN XL | 最大10Mbit/s | 还没大规模应用 |
ECU会根据用途选择合适的CAN总线速率：
低速总线，对数据的实时性要求较低，无关行车安全。例如灯光、雨刮、座椅、门锁、后视镜、空调、胎压等。注：部分也可能被LIN总线代替。
高速总线，需要实时计算，例如发动机、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收发器，至少还会做到：
带电流限制、过热警告等功能的低损耗电压调节器
多种低功耗运行模式，且支持多种唤醒模式
极低的休眠/待机电流
抗射频干扰，去噪
看门狗、中断和复位可软件编程
高级版支持更多功能特性的可编程控制
关于功耗，收发器和控制器都有睡眠模式等低功耗模式，由芯片或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的知识点：
CAN帧中包含ID，在数据链路层只起到优先级判断的作用。ID的数值越小，CAN帧的优先级越高，会获得总线控制权。多节点同时开始发送数据时，按照电路设计，ID按每一bit传输时，ID小的数据会覆盖ID大的值，即0&1=0，此时只要判断到自己发出的bit1实际是收到bit0，就停止发送后续的bit，稍后重试。
更详细的解答请参考 CAN总线原理-精华整理。
CAN ID值的业务意义由应用层决定。一种典型用法是，部分bit代表消息类型，部分bit代表发送者设备，即ID和设备绑定。只要ID的前几bit代表设备号，后几bit代表业务值，就能兼顾优先级判断的规范。
数据场的知识点：
数据场是放高层业务数据的地方。
数据链路层协议只规定了一帧的格式，数据跨越多帧的情况由应用层协议实现拆包和重组。详细介绍：CAN总线多帧发送方式
经典CAN，数据场最多8bytes；CAN FD最多64bytes；CAN XL最多2048bytes，即一帧可以有更多业务数据。当一帧的业务数据量>8且<64时，用CAN FD就不需要在业务层把数据拆成多帧和重组了，这也提升了性能。
更具体的协议内容比较多，本文不会展开讲，可参考多篇链接的文章。
5.3.2 控制器
协议的实现由CAN控制器负责，它是个独立的MCU，根据型号，可以对接1个或多个CAN收发器。对接多个时，也就相当于成为多路CAN的集线器了。只对接1个收发器的独立控制器结构图如下：
实际上控制器有两种硬件构成方案：
SOC控制器（或SOC的协处理器MCU） + 独立CAN控制器 + CAN收发器。使用独立CAN控制器程序复用移植性较好，但占用主控芯片I/O资源。
SOC+集成了CAN控制器模块的MCU + CAN收发器。该方案程序复用性不佳，有很强针对性，但可以使电路更加简单。
CAN控制器只会把正常的帧传递到SOC，在内部进行数据链路层的错误处理。没有部件记录详情，ECU只可读取寄存器了解基本信息，如错误计数、最近一次的错误类型。
CAN控制器是需要被编程控制的，根据芯片规范，SOC要在驱动层正确地初始化和动态控制CAN控制器。
5.3.3 报文过滤
过滤的目的是使SOC只接收到该ECU需要处理的数据。
消息过滤是根据CAN ID做的，因为都是业务需求，每个ECU都知道自己只处理哪些ID的信号。
有几种实现方式：
CAN控制器自带的验收屏蔽寄存器和验收滤波寄存器，可以过滤掉不想要的报文。只要SOC对其做设置即可。（像操作系统设置网卡属性）
SOC或协处理器MCU来实现编程实现。通常在MCU中实现，不占用SOC的资源。（像软件网络代理）
网关中设置某路的CAN哪些消息不转发到这路CAN。（像设置路由器）
信号（消息的具体内容）过滤需要解析数据场的数据，只能MCU实现。关于信号请参考DBC一节。
5.3.4 CAN故障
主要有这几类：
电磁辐射干扰；
工作电压不正常，包括电源故障、电路元件不符合电路设计规范（含电阻阻抗不对）等；
各类原因导致的线路短路、断路，包括线松、线断、潮湿、线接错等。
线路物理性质变化引起通信信号衰减或失真，如高温
ECU故障，即传输协议或软件程序有bug
数据链路层本身的出错概率非常小，各种芯片都很成熟了，只是通常在这层入手排查物理层问题，物理层的故障通常需要电子工程师用CANoe（见下文）、示波器、万用表来检测，具体请参考：
由于应用层都是脚本自动化生成代码，高层框架也成熟，这层出bug应该是必现的。正如CAN的名字里有“局域网”，本地网络的问题风险相对可控。
5.3.5 CAN BUS OFF问题
测试和预警方案：
测试触发方法：参考说说Busoff那点事。
可以对BUS OFF打log警告，log时机（根据具体芯片规范）有BUS OFF回调机制或定时读取芯片寄存器
更多参考资料：
基础涨知识篇：CAN总线错误分析与解决。一个根因不同的CAN BUS OFF例子，更详细地解释了BUS OFF的排查手段。
5.4 内核驱动层
嵌入式软件开发中，CAN总线数据收发的实现方案经历过一些迭代，最终在Linux形成SocketCAN方案，即内核用socket模型来封装底层实现，应用层只需给socket API设置特定参数即可。内核的net模块根据这些参数来确定是否以及怎样调用CAN驱动，同时内核也能提供socket缓冲区。socket封装的结果请参考下文的应用层代码示例。
内核驱动层需要正确初始化CAN控制器，按照芯片规范要求实现数据读写，处理硬件中断。通常芯片或板子供应商都会提供成熟的驱动程序，且已按客户要求做了最佳配置。
这层的具体工作请参考下文应用层的例子，更多详细介绍请参考：
Linux内核官方关于SocketCAN的介绍： Readme file for the Controller Area Network Protocol Family
内核与驱动层的实现介绍：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种：
CANopen：基于CAN2.0A定义的标准帧，由CiA提出和维护。最初是为工业自动化设计的，但很快应用在了其它领域。具体介绍：什么是CANopen总线协议？CANopen通信协议概述周立功的教学：CANopen 轻松入门 入门教程CiA官方规范分成了多份，下载入口：https://www.can-cia.org/groups/specifications/
J1939：基于CAN2.0B定义的扩展帧，由SAE提出。多用于重型机械，如大巴、挖掘机、拖拉机、坦克、消防车等。具体介绍：从应用角度来讲讲J1939协议
DeviceNet：基于CAN2.0A定义的标准帧，由美国的Allen-Bradley公司所开发。主要应用包括资讯交换、安全设备及大型控制系统，在美国的市场占有率较高。比起CANopen，对物理层的要求更严格，从而使得不同厂商的设备更通用。具体介绍：CAN应用层协议详解之DeviceNet协议
协议具体内容太多，多数人不用学习。我们了解这些即可：
三者互不兼容
都对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定义了：
每个ECU会发出的消息（Message）及这些消息对应的CAN ID。也就是说，根据CAN ID可以反推消息是哪个ECU发出的。
每种消息的长度（0~64字节），即CAN帧的数据场的长度
消息的数据场每bit或bit组合代表的意义，称为信号（signal）。一个消息内可以有多个信号
每个信号在数据场中的起始bit位置、长度，上层解析的数据类型、取值范围、枚举定义、计算公式、单位、周期消息的发送间隔、接收者等。
DBC相当于不同ECU的开发人员间的协议文档，特定软件可导入后以此解析CAN帧，支持所有的数据链路层以及应用层CAN协议。这已成为行业惯用工具，实际上不只Vector公司的软件使用DBC，周立功也可以用。
规范文档请见：格式规范文档。由于有规范，所以可以用脚本解析再自动生成高级编程语言的代码。
更多详情：
具体介绍：CAN通信 DBC文件解析
5.5.4 独立控制器方案
系统框架图简化版：
SOC软件层的细分层工作：
BootLoader：把SPI接口映射到内存空间地址，初始化寄存器。配置由板子供应商提供
驱动层：初始化控制器通信，注册内核中断号，实现基于SPI的can_frame读写系统代码路径：/kernel/drivers/net/can/spi/mcp251x.c，由芯片供应商提供，板子供应商打包给出。
内核层：加载驱动，映射CAN总线为(/dev/)can0，在socket实现层调用驱动
App socket层代码示例见上文。
App业务层，根据帧ID确定信号类型并解析数据，再按业务协议继续执行。解析和组帧的代码可以用脚本根据DBC自动生成。
5.5.5 自开发MCU方案
系统框架图简化版：
注：
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直接在软件层实现。
常见的网关设备有：
CAN2Eth，CAN转以太网：一种CAN总线和以太网互通数据的中转设备。可通过软件或网页配置，支持TCP Server、TCP Client、UDP Client、UDP Broadcast模式。支持帧过滤。例子：某ECU Client在以太网连接上作为TCP Server的网关，能按网关协议收发CAN数据，由网关在CAN网络转发和监听。注：CAN口数据包和网口数据包用透传方式通信。
Tbox：本质是个独立的网关ECU，可桥接CAN、车载以太网、WiFi、4G/5G、蓝牙。现在正处于车联网快速发展的阶段，各厂家都在推出自己的特有功能，所以是还没标准化的，需要进行嵌入式开发，有专门的Tbox软件开发岗位。
6 开发测试
6.1 MCU开发简介
一个典型的开发流程：
明确任务分析和了解项目的总体要求，并综合考虑系统使用环境、可靠性要求、可维护性及产品的成本等因素，制定出可行的性能指标。
划分软、硬件功能MCU由软件和硬件两部分，有些功能既可由硬件来实现，也可以用软件来完成。硬件的使用可以提高系统的实时性和可靠性;使用软件实现，可以降低系统成本，简化硬件结构，合理地制定硬件和软件任务的比例。
确定芯片及其他关键部件根据硬件设计任务，选择能够满足系统需求并且性价比高的芯片及其他关键器件，如A/D、D/A转换器、传感器、放大器等，这些器件需要满足系统精度、速度以及可靠性等方面的要求。
硬件设计根据总体设计要求，以及选定的芯片及关键器件，利用软件设计出应用系统的电路原理图。
软件设计在系统整体设计和硬件设计的基础上，确定软件系统的程序结构并划分功能模块，然后进行各模块程序设计。
仿真调试软件和硬件设计结束后，需要进行进行进入两者的整合调试阶段。为避免浪费资源，在生成实际电路板之前，可以利用软件进行系统仿真，出现问题可以及时修改。
系统调试完成系统仿真后，利用绘图软件，根据电路原理图绘制PCB(Printed Circuit Board)，即印刷电路板图，然后将PCB图交给相关厂商生产电路板。拿到电路板后，为便于更换器件和修改电路，可首先在电路板上焊接所需芯片插座，并利用编程器将程序写入MCU。然后将MCU及其他芯片插到相应的芯片插座中，接通电源及其他输入、输出设备，进行系统联调，直至调试成功。
测试修改、集成试用经测试检验符合要求后，与ECU其它部件以及对手件集成联调，对于出现的实际问题进行修改完善，系统开发完成。
可以通过一个实例了解下CAN开发面对的问题：CAN总线指定帧唤醒的硬件实现方式。
MCU软件开发和系统及应用开发的不同点：
更深入了解硬件，看协议规范，掌握电子电气基础知识。在各类总线规范之上，还有AutoSAR规范等。
要使用示波器、外接LED灯、仿真器等工具调试
使用C语言开发为主，没有API，直接对内存地址读写即是操作硬件。需要考虑编译结果，例如某段代码必须放在数据段还是代码段。
芯片厂商会提供驱动、上层应用示例，还可能有开发IDE。由于历史悠久，现成产物多，多数工作是适配新板子
功耗是重要的性能指标，多种低功耗模式的切换过程是最复杂的场景之一。
异常主要由硬件引起，关注电平滤波、整形、时间同步等问题。
对口专业：电子信息、计算机科学与技术
人力成本参考：一线城市5年工龄内大专本科，月薪8~25k
6.2 硬件成本
简述：最简线路的物理层+数据链路层在10块钱内（批发价哈）。网关价格中值需要5千元。仿真测试设备需要5万元+。
芯片的知名厂商：
NXP：荷兰 恩智浦 半导体公司，车载设备的供应商。前身是飞利浦半导体事业部。车载芯片领域在高通进入前是由NXP主宰。
Microchip：美国 微芯半导体 公司，全球领先的单片机和模拟半导体供应商。
Renesas：日本 瑞萨 公司，世界十大半导体芯片供应商之一。
软硬件开发工具的厂商：
Vector：德国 维克多 公司，是总线开发工具、网络节点测试验证工具和嵌入式软件组件供应商，为汽车总线网络的设计、建模、仿真、分析、测试以及ECU的开发、测试、标定和诊断等领域提供一系列强有力的软硬件工具和源代码。
周立功、ZLG：公司名为广州致远电子股份有限公司，官网 https://www.zlg.cn/。创始人就名为周立功，关于他的介绍可参考百度百科。公司总部位于广州市天河区，是一家工业互联网产品与解决方案供应商。也是CANopen协会CiA的会员。
材料价格表：
材料 | 价格（百度&淘宝价） | 备注 | 样件图 |
屏蔽双绞线 | 大概2~3元1米 | 详解CAN总线：什么是CAN总线？ |