CAN 是Controller AreaNetwork 的缩写，中文名为控制器局域网络，是ISO国际标准化的串行通信协议，是一种用于实时应用的串行通讯协议总线，它可以使用双绞线来传输信号，是世界上应用最广泛的现场总线之一。
现代汽车拥有大量控制系统，这些控制系统基于web技术开发并在多种微服务处理中发挥作用，如安全气囊、刹车、巡航控制、电动助力转向、音响系统、电动车窗、门、后视镜调整按钮、电池和充电系统等。这些系统需要相互通信和状态读取，因此CAN协议被开发并派上用场，如同为汽车配置了神经系统。
可以把CAN认为是汽车用来进行传感器数据传递的简单网络，它完美地集成了各种复杂部件，从而在汽车使用中展示和实现了各种我们所想所愿的各种新型功能。以下为1988年款的宝马8系，这是全球第一台采用CAN总线的汽车.
随着自动驾驶技术的的飞速发展，CAN-Bus的应用概念也变得非常普及。为什么呢？因为很多自动驾驶公司并不会大规模地从头制造无人汽车，而是把关注点放在编程控制车辆方面。而通过汽车CAN-Bus协议的逆向工程分析，无人汽车工程师可以利用软件方式实现对汽车的命令发送控制，如转向、加速和刹车等。
通过使用类似激光雷达（LIDAR）这样的传感器，无人汽车就具备了超凡的“感知”世界的能力，车内微型PC可以就引导、加速、刹车等动作做出决定。
CAN 总线最早是由德国 Bosch 公司在 1986 年为汽车监测和控制而设计，主要用于汽车内部测量与执行部件之间的通信。自宝马公司 1989 年推出第一款使用 CAN-BUS的汽车后，CAN 总线就开始了其辉煌的历程。CAN 的高性能和可靠性已被认同，并被广泛地应用于工业自动化、船舶、医疗设备、工业设备等方面。CAN总线是当今自动化领域技术发展的热点之一，被誉为自动化领域的计算机局域网。它的出现为分布式控制系统实现各节点之间实时、可靠的数据通信提供了强有力的技术支持。
CAN 总线从诞生之初就凭借着其优良的实时性与可靠性迅速发展成为现场总线的领航者，但它仍存在一些缺陷。CAN 总线通信采用载波监听无损的仲裁技术，在网络负载较小时，CAN 总线实时性可以满足各方面的需求，但随着网络负载不断增大，信息在总线上碰撞的概率也随之增大，如果继续使用基本的 CAN 协议，优先级较低的信息发送的实时性就会受到影响，网络负载到达一定程度后甚至会退出总线竞争。CAN总线协议采用静态固定优先级分配方式，这样不同优先级的信息就很难公平的共享总线使用权，这些缺陷成为制约其进一步发展的问题。
CAN协议的特性包括完整性的串行数据通讯、提供实时支持、传输速率高达1Mb/s、同时具有11位的寻址以及检错能力。
CAN总线用户接口简单，编程方便。网络拓扑结构采用总线式结构。这种网络结构简单、成本低，并且采用无源抽头连接，系统可靠性高。通过CAN总线连接各个网络节点，形成多主机控制器局域网(CAN)。
信息的传输采用CAN通信协议，通过CAN控制器来完成。各网络节点一般为带有微控制器的智能节点完成现场的数据采集和基于CAN协议的数据传输，节点可以使用带有在片CAN控制器的微控制器，或选用一般的微控制器加上独立的CAN控制器来完成节点功能。传输介质可采用双绞线、同轴电缆或光纤。
如果需要进一步提高系统的抗干扰能力，还可以在控制器和传输介质之间加接光电隔离，电源采用DC-DC变换器等措施。这样可方便构成实时分布式测控系统。微控制器，或选用一般的微控制器加上独立的CAN控制器来完成节点功能。传输介质可采用双绞线、同轴电缆或光纤。如果需要进一步提高系统的抗干扰能力，还可以在控制器和传输介质之间加接光电隔离，电源采用DC-DC变换器等措施。这样可方便构成实时分布式测控系统。
本段主要讨论无人驾驶系统获取到CAN消息后，如何根据CAN协议，解析出想要的数据？
从CAN总线中解析出传感器的信息，是每个自动驾驶工程师，甚至每一个汽车电子工程师必备的技能。
可以看到这个名为CanFrame的消息结构中包含4个关键信息，分别是：
1.uint32_t id （CAN消息的ID号）
由于CAN总线上传播着大量CAN消息，因此两个节点进行通信时，会先看id号，以确保这是节点想要的CAN消息。最初的CAN消息id号的范围是000-7FF（16进制数），但随着汽车电控信号的增多，需要传递的消息变多，信息不太够用了。工程师在CAN消息基础上，扩展了id号的范围，大大增加了id号的上限，并将改进后的CAN消息称为“扩展帧”，旧版CAN消息称为“普通帧”。
如果拿写信做比较，这个id就有点类似写在信件封面上的名字。
2.uint8_t len（CAN消息的有效长度）
每一帧CAN消息能够传递最多8个无符号整形数据，或者说能够传递8*8的bool类型的数据。这里的len最大值为8，如果该帧CAN消息中有些位没有数据，这里的len就会小于8。
3.uint8_t data[8]（CAN消息的实际数据）
正如刚才提到的，每一帧CAN消息都包含至多88个bool类型的数据，因此可以通过88个方格，可视化CAN消息中的data。如下图所示：
在没有CAN协议帮助我们解析的情况下，这里的数据无异于乱码，根本无法得到有用的消息，这也是CAN消息难以破解的原因之一。
4.timestamp（CAN消息的时间戳）
时间戳表示的是收到该CAN消息的时刻。通过连续多帧的时间戳，可以计算出CAN消息的发送周期，也可以用于判断CAN消息是否被持续收到。
综上，每帧CAN消息中最重要的部分其实是data，即88的bool值。所谓解析CAN消息，其实就是解析这88个bool类型的值。
目前业界的CAN协议，都是以后缀名为dbc的文件进行存储的。德国Vector公司提供CANdb++ Editor是一款专门用于阅读dbc文件的软件。
如下图所示，为本人提供的车辆的dbc文件。
每个信号的具体描述显示在软件右侧，其中与解析直接相关的三个要素已用绿色框选中。
1.Value Type（Unsigned或Signed）
某些物理量在描述时是有符号的，比如温度。而描述另外一些量时，是没有符号的，即均为正数，比如说曲率。
2.Factor 和 Offset
这两个参数需要参与实际的物理量运算，Factor是倍率，Offset是偏移量。例如Lane_Type和Quality信号的Factor为1，Offset为0，而其他信号的Factor均为小数。具体的计算方法请往下看。
双击LKA_Left_Lane_A，打开Layout页，会发现很熟悉的方块阵列，如下图所示。
工程师真正关心的恰好是这块彩色图，因为该图上的每个小方块和data中的每一个bool量一一对应。这就是CAN协议的真面目。
一辆车内有多种CAN总线，为了实现A/C系统的打开和关闭，我们需要找到正确的CAN运行总线，以福特Fusion来说，其中至少标记有4个总线，其中3个为运行500kbps的高速率CAN总线HS1、HS2、HS3，1个为运行125kbps的中速CAN总线MS。
OBD-II接口具备两种这类型CAN总线：HS1和HS2，但为了以防一些恶意命令，它们都是被阻断状态的。但在来自Voyage的Alan帮助下，我们彻底把OBD-II这个限制问题翻转解决了，我们发现了直接访问HS1、HS2、HS3和MS的方式。关键在于OBD-II接口背后，一个所有总线汇总，叫做网关模块（Gateway Module）的部件上。以下为Voyage第一辆无人驾驶出租车Homer后座控制接口概览：
由于A/C系统可以通过汽车的媒体界面（SYNC）进行更改，所以，我们直奔MS中速总线而去。但是我们如何才能让电脑可以读写CAN数据包呢？答案就是SocketCAN，这是一个由大众公司向Linux内核基金会研发的开源CAN驱动和网络栈协议集。
我们可以把车辆的GND、MSCANH、MSCANL3条线连接到Kvaser Leaf Light HSv2和CANable设备中，然后在另一端，使用安装有较新版本Linux内核的电脑连接，把CAN总线作为网络设备识别加载：
modprobe can
modprobe kvaser_usb
ip link set can0 type can bitrate 1250000
ifconfig can0 up
GND：地线，公共接地线；
MSCAN：中速总线，也称飞思卡尔控制器局域网总线，是BOSCH公司定义的CAN2.0和CAN3.0协议下的CAN总线控制器,是当前汽车控制器中流行的CAN控制框架。MSCANH、MSCANL为其高电平和低电平线。
Kvaser Leaf Light HSv2是一个用于CAN的单通道USB接口，它能够方便地把几个接口连接到标准的PC机上。
加载之后，我们可以尝试使用candump can0命令，分析其中的流量情况：
但是，这相当于观察声音信号振幅一样，很难从中发现动作和行为模式。在此，我们需要使用工具cansniffer对频率进行等效化分析，cansniffer显示的一串数据包ID号，可以帮助我们在CAN帧数据区变化时进行准确定位。有了这个功能，我们就能分辨出哪些数据包是应该丢弃的，而哪些又是与我们问题相关的。
CANSniffer：一款收发CAN格式数据包的分析软件,通过串口与外部设备交互，用于分析串口数据包。
以下是cansniffer在MS中速总线的抓包示例，我们正在对所有通过串口的数据包进行过滤，只需要CAN id为355、356和358的数据包。同时，通过按下汽车空气调节按钮后观察数据包变化情况，发现001C00000000代表了该按钮的开关作用。
接下来就是把A/C系统功能连接到我们运行于汽车内的微型PC，该PC为机器人操作系统（ROS），而幸运的是，利用前述提及的SocketCAN和ROS中的一个模块，就能很容易实现连接和操作。而且用socketcan_bridge方式可以将我们的CAN数据帧转换成ROS可接收的消息格式。完美！
以下就是A/C系统功能数据包解码方式的一个示例：
if frame.id == 0×356:
raw_data = unpack(‘BBBBBBBB’, frame.data)
fan_speed = raw_data[1] / 4
driver_temp = parse_temperature(raw_data[2:4])
passenger_temp = parse_temperature(raw_data[4:6])
由此生成的数据被存储在名为CelsiusReport.msg的文件中：
bool auto
bool system_on
bool unit_on
bool dual
bool max_cool
bool max_defrost
bool recirculation
bool head_fan
bool feet_fan
bool front_defrost
bool rear_defrost
string driver_tempstring passenger_temp
在按下汽车A/C系统相关功能的按钮之后，我们将得到以下这个对应的代码清单：
CONTROL_CODES = {
‘ac_toggle’: 0x5C,
‘ac_unit_toggle’: 0×14,
‘max_ac_toggle’: 0×38,
‘recirculation_toggle’: 0x3C,
‘dual_temperature_toggle’: 0×18,
‘passenger_temp_up’: 0×24,
‘passenger_temp_down’: 0×28,
‘driver_temp_up’: 0x1C,
‘driver_temp_down’: 0×20,
‘auto’: 0×34,
‘wheel_heat_toggle’: 0×78,
‘defrost_max_toggle’: 0×64,
‘defrost_toggle’: 0x4C,
‘rear_defrost_toggle’: 0×58,
‘body_fan_toggle’: 0×04,
‘feet_fan_toggle’: 0x0C,
‘fan_up’: 0x2C,
‘fan_down’: 0×30,
}
现在，我们就可以直接将以上字符串对应的数据代码发往ROS节点，由它将这些数据信息转换成汽车可以识别的特殊代码：
rostopic pub /celsius_control celsius/CelsiusControl ac_toggle
由于彩色方块图与data是一一对应的，我们将两个图叠加，将得到如下图所示的data图。
1.Factor为1的物理量
由于Lane_Type和Quality的Factor为1，Offset为0，因此十进制值为多少，实际物理量即为多少。
从图中就能直接看出Quality这个信号占据两个位，二进制数11，换算为十进制是3（12 + 11）；Lane_Type占据四个位，二进制数为0010，换算为十进制是2（08 + 04 + 12 + 01）。
所以这一帧信号表示此时的左车道线Lane_Type值为2，Quality值为3。对于整数值，通信双方可以约定规则，比如Mobileye就规定了，Quality为0或者1时表示车道线的置信度较低，不推荐使用此时的值；2表示置信度中等，3表示置信度较高，请放心使用。
2.Factor为小数的物理量
对于Factor不为1的物理量，比如Position，需要使用移位的方法进行解析，但解析公式保持不变。以百度 Apollo提供的源码为例进行讲解。
这里的bytes即为CAN消息中的data，首先将Position信号所在的行取出来，将第1行的8个bool值存储在变量t1中，将第二行的8个bool值存储在变量t0中。由于在这条CAN消息中，Position同时占据了高8位和低8位，因此需要将第一行和第二行的所有bool位拿来计算，高8位存储在32位的变量x中，低8位存储在32位的变量t中。
现在需要将高8位和低8位拼接，将高8位左移8位，然后与低8位求或运算，即可得到Position的二进制值。随后进行的左移16位，再右移16位的操作是为了将32位的变量x的高16位全部初始化为0。之后将x乘以Factor再加上Offset即可得到真实的Position值，给真实值加上单位meter，即可获取实际的物理量。
VCU、雷达等通过CAN总线传递信号，随着CAN的负载越来越高，很多传感器选择了其他通信方式。比如激光雷达的点云数据量太过庞大，使用的是局域网的方式进行传递；再比如GPS和惯导使用的是串口进行通信。
虽然通信方式和通信协议千差万别，但解析的方法都是一样的。
最后，提醒一下，由于不同ID的CAN消息的结构不一样，因此工程师在写解析代码时，需要十分仔细，否则会给后续处理带来想不到的bug。