Android 车载应用开发指南（5）- CAN Bus 协议详解

汽车工业蓬勃发展，汽车的电子控制单元逐渐增多。各电控单元之间的信号交换导致汽车线束的级数增加，复杂粗大的线束与汽车有限的布线空间之间矛盾越来越突出，繁多的线束导致电气系统可靠性下降，同时增加了重量。

CAN Bus 将汽车内部各电控单元之间连接成一个局域网络，实现了信息的共享，大大减少了汽车的线束，如下图所示：

CAN Bus 可以满足子系统数据传输的需求，可以实现汽车内互联系统由传统的点对点互联向总线式系统的进化，大大降低汽车内电子系统布线的复杂度。

CAN（Control Area Network）Bus ，控制器局域网总线，是一种串行通信协议，能够让设备之间可靠而高效地传输数据。它广泛应用于车辆领域，像神经系统一样连接车辆内部的各个电子控制单元。

CAN Bus 最初由德国跨国工程技术巨头博世公司（Robert Bosch ）为汽车应用而设计。它是一种多主、多从、半双工、具有容错能力的协议，非常适合汽车领域的需求。它简单、低成本、可靠，能够在恶劣的环境中工作。CAN Bus 为车辆中所有电子控制单元提供了一个统一的接入点，方便进行连接和诊断。

CAN Bus 由博世在 20 世纪 80 年代初开发，旨在为汽车应用提供一种高效的通信系统，主要目的是简化车辆内部线束的复杂程度。

1986 年，博世发布了首个 CAN 协议，由于其可靠性和健壮性，很快受到了汽车制造商的青睐。1993 年，它成为 ISO-11898 国际标准。该协议演进过程大致如下：

除了汽车领域外，CAN Bus 协议还逐渐应用于其它行业，例如工业自动化系统（CANopen）和船用电子设备（NMEA 2000）。它的广泛应用主要得益于它能够在恶劣的条件下稳定运行，并且实施成本较低。

CAN Bus 标准已被广泛接受，几乎用于所有车辆和多种设备。这主要由于其具备以下多种优点：

当需要对复杂系统进行分布式控制时，CAN 是一种理想的协议。它减少了繁重的布线，从而降低了成本和重量。芯片的成本较低，并且由于协议设计简洁，实现 CAN 相对容易。

CAN Bus 是一种分布式的通信协议。它的分布式特点使它非常适合对可靠性和实时性有较高要求的应用，如汽车和工业系统。

在 CAN 网络中，所有的节点都通过双绞线或光纤相连。每个节点都有自己的微控制器，负责处理收到的消息和发送的消息。数据由节点在共享总线上广播，所有其它节点都能收到。

通信过程的几个关键阶段包括：

在 CAN Bus 系统中，消息结构对于设备间的高效通信非常重要。CAN 总线的通信是通过 CAN 报文完成的。

消息长度有两种变体：标准长度和扩展长度。

下图是带有 11 位标识符（CAN ID）的标准帧（CAN 2.0A），这是大多数汽车中使用的类型。

扩展的 29 位标识符（CAN ID）报文（CAN 2.0B）除了更长的 ID 外，其它部分都是相同的。

它主要在重型车辆的 J1939 协议 中使用。

CAN Bus 的 8 个报文字段

仲裁字段包含消息标识号和远程传输请求位。越重要的消息具有越低的 ID 号。

如果多个节点同时传输，它们会启动同时仲裁。具有最低消息 ID 号的节点获得优先权。

显性位会覆盖 CAN 总线上的隐性位。消息标识符的长度可以是 11 位 （标准 CAN，2048 个不同的消息标识符）或 29 位（扩展 CAN，5.37 亿个不同的消息标识符）。远程传输请求位占主导地位，表示正在传输数据。

在大多数系统中，逻辑 1 代表高电平，逻辑 0 代表低电平。但在 CAN 总线上则相反。因此，CAN 收发器通常在驱动器输入和接收器输出上使用上拉电阻，以便设备默认为隐性总线状态。

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 进入几乎所有车辆只是时间问题。

目前汽车上普遍采用的汽车总线有局部互联协议 LIN 和控制器局域网 CAN，正在发展中的汽车总线技术还有高速容错网络协议 FlexRay、用于汽车多媒体和导航的 MOST 以及与计算机网络兼容的蓝牙、无线局域网等无线网络技术。

Notes: * UTP = unshielded twisted pair（非屏蔽双绞线）

与任何联网和互操作系统一样，汽车总线的选择最好以需求为导向，同时关注成本和预期的行业要求和趋势。

显然，如果有更好的总线可供选择，而且部署成本相当或更低，那么汽车制造商就不会在新设计中采用旧总线。

作为 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) 等内部网络和未来的车载通信标准。

链接：https://juejin.cn/post/7369470562144305162

本文经授权转载，转载文章所包含的文字来源于作者。如因内容或版权等问题，请联系进行删除