Android 车载应用开发指南系列文章
Android 车载应用开发指南（1）- 车载操作系统全解析
Android 车载应用开发指南（3）- SystemUI 详解
Android 车载应用开发指南（4）- CarService 详解
Android 车载应用开发指南（5）- CAN Bus 协议详解
一 概述
1.1 背景
汽车工业蓬勃发展，汽车的电子控制单元逐渐增多。各电控单元之间的信号交换导致汽车线束的级数增加，复杂粗大的线束与汽车有限的布线空间之间矛盾越来越突出，繁多的线束导致电气系统可靠性下降，同时增加了重量。
CAN Bus 将汽车内部各电控单元之间连接成一个局域网络，实现了信息的共享，大大减少了汽车的线束，如下图所示：
CAN Bus 可以满足子系统数据传输的需求，可以实现汽车内互联系统由传统的点对点互联向总线式系统的进化，大大降低汽车内电子系统布线的复杂度。
1.2 什么是 CAN Bus
CAN（Control Area Network）Bus ，控制器局域网总线，是一种串行通信协议，能够让设备之间可靠而高效地传输数据。它广泛应用于车辆领域，像神经系统一样连接车辆内部的各个电子控制单元。
CAN Bus 最初由德国跨国工程技术巨头博世公司（Robert Bosch ）为汽车应用而设计。它是一种多主、多从、半双工、具有容错能力的协议，非常适合汽车领域的需求。它简单、低成本、可靠，能够在恶劣的环境中工作。CAN Bus 为车辆中所有电子控制单元提供了一个统一的接入点，方便进行连接和诊断。
1.3 CAN Bus 发展简史
CAN Bus 由博世在 20 世纪 80 年代初开发，旨在为汽车应用提供一种高效的通信系统，主要目的是简化车辆内部线束的复杂程度。
1986 年，博世发布了首个 CAN 协议，由于其可靠性和健壮性，很快受到了汽车制造商的青睐。1993 年，它成为 ISO-11898 国际标准。该协议演进过程大致如下：
- CAN 之前的版本： 汽车 ECU 是复杂的点对点布线
- 1986 年： 博世开发了 CAN 协议作为解决方案
- 1991 年： 博世发布了 CAN 2.0（CAN 2.0A：11 位，2.0B：29 位）
- 1993 年： CAN 被采用为国际标准（ISO 11898）
- 2003 年： ISO 11898 成为标准系列
- 2012 年： 博世发布了 CAN FD 1.0
- 2015 年： CAN FD 协议标准化（ISO 11898-1）
- 2016 年： CAN 物理层，数据速率高达 5 Mbit / s，已通过 ISO 11898-2 标准化
除了汽车领域外，CAN Bus 协议还逐渐应用于其它行业，例如工业自动化系统（CANopen）和船用电子设备（NMEA 2000）。它的广泛应用主要得益于它能够在恶劣的条件下稳定运行，并且实施成本较低。
1.4 CAN Bus 优点
CAN Bus 标准已被广泛接受，几乎用于所有车辆和多种设备。这主要由于其具备以下多种优点：
- 简单且低成本：ECU 通过单个 CAN 系统进行通信，而不是直接的复杂模拟信号线通信，这样减少了错误，重量，接线和成本
- 完全集中：CAN 总线提供了“一个进入点”，可以与所有网络 ECU 进行通信——支持集中诊断，数据记录和配置
- 极其稳健：CAN 总线具有强大的抗电干扰和抗电磁干扰能力，非常适合对安全要求严格的应用（例如车辆）
- 非常高效：CAN 帧按 ID 号划分优先级。最优先的数据可以立即访问总线，而不会造成其他帧的中断
当需要对复杂系统进行分布式控制时，CAN 是一种理想的协议。它减少了繁重的布线，从而降低了成本和重量。芯片的成本较低，并且由于协议设计简洁，实现 CAN 相对容易。
二 CAN Bus 工作原理
2.1 物理连接及协议工作原理
CAN Bus 是一种分布式的通信协议。它的分布式特点使它非常适合对可靠性和实时性有较高要求的应用，如汽车和工业系统。
在 CAN 网络中，所有的节点都通过双绞线或光纤相连。每个节点都有自己的微控制器，负责处理收到的消息和发送的消息。数据由节点在共享总线上广播，所有其它节点都能收到。通信过程的几个关键阶段包括：
- 仲裁： 为了避免多个节点同时发送数据产生冲突，CAN 采用了一种基于消息优先级的仲裁过程。消息的标识符值越小，优先级越高
- 错误检测： 内置的错误检测机制保证了 CAN 网络中数据的完整性。这些机制包括循环冗余校验（CRC）、帧校验序列（FCS）以及接收节点确认位
- 故障界定： 如果节点在传输过程中检测到错误或故障，它会进入“被动错误”状态，直到问题解决。这种机制可以防止故障对整个系统功能造成干扰
这些特性相互配合，使得 CAN Bus 能够高效运行，确保车辆或工厂自动化设备等复杂系统中各个组件之间的可靠通信。
2.2 消息结构
在 CAN Bus 系统中，消息结构对于设备间的高效通信非常重要。CAN 总线的通信是通过 CAN 报文完成的。
消息长度有两种变体：标准长度和扩展长度。
下图是带有 11 位标识符（CAN ID）的标准帧（CAN 2.0A），这是大多数汽车中使用的类型。
扩展的 29 位标识符（CAN ID）报文（CAN 2.0B）除了更长的 ID 外，其它部分都是相同的。它主要在重型车辆的 J1939 协议 中使用。
CAN Bus 的 8 个报文字段
| FIELD | BITS | DESCRIPTION |
|---|---|---|
| SOF | 1 | 帧开始是“显性 0”，告诉其他节点 CAN 节点打算进行通信 |
| ID | 11 | ID 是帧标识符 – 较低的值具有较高的优先级 |
| RTR | 1 | 远程传输请求指示节点是否发送数据或向另一个节点请求专用数据 |
| Control | 6 | 控制包含标识符扩展位 (IDE)，它是 11 位的“显性 0”。它还包含 4 位数据长度代码 (DLC)，指定要传输的数据字节的长度（0 到 8 个字节） |
| Data | 0 - 64 | 数据包含数据字节，也称为有效负载，其中包括可以提取和解码信息的 CAN 信号 |
| CRC | 16 | 循环冗余校验用于确保数据完整性 |
| ACK | 2 | ACK 槽指示节点是否已确认并正确接收数据 |
| EOF | 7 | EOF 标记 CAN 帧的结束 |
仲裁字段包含消息标识号和远程传输请求位。越重要的消息具有越低的 ID 号。
如果多个节点同时传输，它们会启动同时仲裁。具有最低消息 ID 号的节点获得优先权。
显性位会覆盖 CAN 总线上的隐性位。消息标识符的长度可以是 11 位 （标准 CAN，2048 个不同的消息标识符）或 29 位（扩展 CAN，5.37 亿个不同的消息标识符）。远程传输请求位占主导地位，表示正在传输数据。
在大多数系统中，逻辑 1 代表高电平，逻辑 0 代表低电平。但在 CAN 总线上则相反。因此，CAN 收发器通常在驱动器输入和接收器输出上使用上拉电阻，以便设备默认为隐性总线状态。
2.3 CAN Bus 的种类
ISO 11898 标准 定义 了 CAN 的多个版本。汽车行业使用的主要 CAN 类型有：
低速 CAN
低速 CAN，也叫做容错 CAN 或 ISO 11898-3，最高传输速度为 125 kbps。它适用于像车身控制模块、门锁、窗户控制等不太重要的系统，这些系统对数据传输速度的要求不高。它的主要特点是即使总线中的一根线断了，也能继续正常工作。
高速 CAN
高速 CAN，或 ISO 11898-2，传输速度最高可达 1 Mbps。通常用于需要高更新率和高数据准确性的关键子系统之间的通信（例如防抱死制动系统、电子稳定控制、安全气囊、发动机控制单元等）。 高速 CAN 比低速更快，但是，它没有低速网络的容错能力。
CAN FD
CAN FD 由博世在 2012 年推出，是高速网络的扩展版，具有更高的数据传输速度，最高可达 8 Mbps，同时向后兼容现有高速设备。这项技术的主要优势在于它比传统的 CAN 能更有效地传输更大的载荷，使其非常适合现代车辆日益复杂的电子系统。
CAN FD 还向后兼容，支持 CAN 2.0 通信协议以及 SAE J1939 等特殊协议，其中 CAN 输出用作只读。 CAN FD 本质上是 ISO 11898-1 中指定的原始 CAN 标准的扩展，并且与经典 CAN 系统完全兼容。
CAN FD 是向前迈出的重要一步，因为它允许 ECU 动态改变其传输速率并根据实时要求选择更大或更小的消息大小。它现在已出现在高性能车辆中，但随着 ECU 性能的提高和 CAN FD 硬件成本的下降，CAN FD 进入几乎所有车辆只是时间问题。
三 CAN 在车载开发中的应用
3.1 车载中的总线协议
目前汽车上普遍采用的汽车总线有局部互联协议 LIN 和控制器局域网 CAN，正在发展中的汽车总线技术还有高速容错网络协议 FlexRay、用于汽车多媒体和导航的 MOST 以及与计算机网络兼容的蓝牙、无线局域网等无线网络技术。
| LIN | CAN | CAN FD | FLEXRAY | MOST | ETHERNET | |
|---|---|---|---|---|---|---|
| Speed | 10-20 kbps | 1 Mbps | 8 Mbps | 10 Mbps | 150 Mbps (shared) | 100 Mbps (per node) |
| Data size | 8 B | 8B | 64 B | 254 B | 370 B | 1500 B |
| Cabling | Single wire | UTP* | UTP | UTP | UTP or fiber optic | UT |
| Topology | Bus | Bus | Bus / passive star | Bus / Star / Mixed | Ring | Star / Tree / Ring |
| Where Used | Sensors, Actuators (lights, mirrors, etc.) | Backbone, Body, Chassis, Powertrain | Body, Powertrain, Distributed Control, Chassis | High-performance powertrain, Backbone, Drive-by-wire, Chassis | Information & Entertainment Systems | Diagnostics, ECU Programming, Information & Entertainment |
| Error Detection | 8-bit CRC | 15-bit CRC | 17 or 21-bit CRC | 24-bit CRC | CRC | 32-bit CRC |
| Redundancy | N/A | N/A | N/A | Yes | Yes | N/A |
| Determinism | N/A | N/A | N/A | Yes | Yes | Not inherent |
| Cost | $ | $$ | $$$ | $$$ | $$ | $$ |
Notes: * UTP = unshielded twisted pair（非屏蔽双绞线）
与任何联网和互操作系统一样，汽车总线的选择最好以需求为导向，同时关注成本和预期的行业要求和趋势。显然，如果有更好的总线可供选择，而且部署成本相当或更低，那么汽车制造商就不会在新设计中采用旧总线。
3.2 CAN Bus 在车载开发中的应用
作为 Android 应用开发你可能会问：CAN Bus 属于底层的东西，我们掌握了能有什么用？
其实，CAN 报文与应用开发也息息相关，学习并掌握 CAN Bus 协议是必要的！ 以下就举例一个车载空调应用开发的场景，解释为什么应用开发也需要掌握 CAN Bus。
熟悉手机应用开发的同学都知道，在代码开发完成后需要进行实机调试，而调试环境其实搭建起来很简单，基本只需要有对应 Android 版本的工程机就可以在自己的工位前模拟调试大部分场景。如果你连实机都没有！用 Android 模拟器也能覆盖大部分调试场景。
但是，对于车载应用开发而言，想在实车上的车载系统调试其实是很奢侈的事。因为实车资源少，所以大部分时候只能在自己工位旁的模拟车载系统上开发调试。而模拟车载系统通常只有主机、显示屏等外设，汽车上的传感器、天线等各种 ECU 是不具备的。
那么对于车载空调应用开发，其环境温度、出风口角度、出风速度等变量都无法动态反馈到车载系统中，进而影响调试。这时候就轮到 CAN Bus 出场了。可以通过 CAN 分析仪连接车载系统主机，使用 ZCANPRO 等信号模拟软件 读取上行 CAN 信号或者模拟发出下行信号。只有对 CAN 信号中的帧结构熟悉，才能读懂和模拟收发信号。
VHAL 通过 CAN 总线或其他车辆专用总线系统与车辆 ECU 建立通信。这些专用互连网络充当车辆内组件通信的骨干网。为了检索车辆数据（例如速度），车载信息娱乐 (IVI) ECU 与其他 ECU 交互，并且车辆 HAL 精心地将提取的信息存储为车辆属性。 Android 框架将数据传输协议和网络选择（包括车载网络）留给 VHAL 的实现。这种灵活性不仅允许 CAN 总线集成，还允许连接到本地互连网络 (LIN) 等内部网络和未来的车载通信标准。
