【Android进阶】车载通信架构——CAN分布式

in 博客目录
【Android进阶】车载通信架构——CAN分布式

本文介绍了车载通信架构中的CAN（Controller Area Network）通信协议相关内容。

车载通信中的CAN（Controller Area Network，控制器局域网）协议是汽车电子系统中应用最广泛的串行通信协议之一，一种专门为恶劣环境设计的串行通信协议。它的老家是德国，由博世公司在1986年正式发布，后来被写进了ISO11898-1标准，定义了OSI模型的数据链路层和物理层。

其设计初衷是为了解决汽车内部日益复杂的电子控制单元（ECU）之间的通信需求，替代传统的点对点布线方式，以减少线束重量、降低成本并提高通信可靠性。

现在，它已广泛应用于汽车、工业自动化、医疗设备等领域，作为一种高效、可靠的通信方式。

一种典型架构

CAN架构

CAN 总线是一种消息导向（message-based）的通信协议，而不是地址导向（address-based）。这意味着总线上的所有设备（称为节点或 ECU - Electronic Control Unit）都能“听到”所有传输的消息，每个消息都包含一个标识符（ID），而不是一个目标地址。节点会根据这个 ID 来决定是否接收和处理该消息。

核心设计目标

CAN的诞生初衷是为了解决汽车内部电子控制单元（ECU）之间通信的麻烦。以前，ECU之间需要一大堆线缆连接，布线复杂得像蜘蛛网。CAN总线的出现让这一切变得简单：只需一对差分信号线，就能让所有ECU愉快地聊天。

CAN总线有以下几个特点：

  1. 多主站（Multi-master）：网络中没有中心控制器，所有节点（ECU）都可以在总线空闲时尝试发送消息，适合分布式电子架构。
  2. 广播（Broadcast）：所有发送的消息都会被网络中的所有节点接收。
  3. 优先级仲裁（Arbitration）：当多个节点同时尝试发送消息时，CAN 总线通过一个基于消息 ID 的仲裁机制来解决冲突。ID 值越低，优先级越高，拥有更高优先级的消息会赢得总线，而低优先级的消息会暂停发送，等待总线空闲后重试。
  4. 高可靠性和容错性（High Reliability and Fault Tolerance）：CAN 总线内置了强大的错误检测和错误处理机制，例如循环冗余校验（CRC）、位填充（Bit Stuffing）和应答（ACK），确保数据传输的完整性。即使出现错误，系统也能进行错误隔离和恢复。
  5. 低成本：简化线束设计（两根信号线即可连接所有节点），降低整车布线复杂度与成本。
  6. 差分信号传输（Differential Signalling）：CAN 总线通过两根双绞线（CAN_H 和 CAN_L）传输差分信号，这有助于抵御电磁干扰（EMI），使其在嘈杂的环境中也能可靠工作。
  7. 终端电阻（Termination Resistors）：CAN 总线两端需要各放置一个 120 欧姆的终端电阻，以消除信号反射，保证信号完整性。
  8. 实时性：通过优先级仲裁机制确保关键信息（如制动、安全气囊控制）优先传输。

CAN协议的物理层与数据链路层

CAN协议分为物理层和数据链路层（逻辑链路控制子层LLC和介质访问控制子层MAC），其中物理层和MAC子层由CAN标准（ISO 11898）定义，LLC子层由用户自定义。

物理层

  • 信号传输介质：通常采用双绞线（CAN_H和CAN_L），通过差分信号传输（平衡传输），抗干扰能力强。
  • 信号电平：
    • 显性电平（Dominant）：CAN_H电压高于CAN_L（典型值：CAN_H=3.5V，CAN_L=1.5V），逻辑“0”。
    • 隐性电平（Recessive）：CAN_H与CAN_L电压相等（约2.5V），逻辑“1”。
    • 优先级规则：显性电平可覆盖隐性电平（类似“线与”逻辑），用于仲裁。
  • 通信速率：支持多种速率（如125kbps、250kbps、500kbps、1Mbps等），速率越高，通信距离越短（例如1Mbps时最大距离约40米，500kbps时约100米）。

数据链路层

一个标准CAN消息帧包含以下几个关键部分:

  • 帧起始（SOF）：一个显性位，标志着消息的开始，相当于敲门声，提醒大家有新消息来了。
  • 标识符（ID）：11位长度，决定了消息的优先级。ID越小，优先级越高。这就像在群聊里，谁的ID靠前，谁的消息就先被处理。
  • 远程传输请求（RTR）：通常是显性位，但当某个节点想请求数据时，会变成隐性位。
  • 标识符扩展（IDE）：显性位表示这是标准CAN帧，不是扩展帧。
  • 数据长度码（DLC）：4位，告诉接收方这次消息带了多少字节数据。
  • 数据字段：实际要传的内容，最多8字节。比如发动机转速、油门开度啥的。
  • 循环冗余校验（CRC）：16位校验码，用来检测传输错误，堪称数据的保镖。
  • 应答位（ACK）：接收方如果正确收到消息，会把这个隐性位覆盖为显性位，相当于说：收到，靠谱！
  • 帧结束（EOF）：7位隐性位，用于标记消息结束，同时检测是否有位填充错误。
  • 帧间间隔（IFS）：一段空闲时间，让CAN控制器有空把收到的消息塞进缓冲区。

后来，CAN升级了，推出了扩展CAN，把标识符从11位扩展到29位，消息ID数量暴增到2的29次方，满足更复杂的应用场景。扩展帧在11位ID后加了个替代远程请求（SRR）位，IDE位变成隐性，表示后面还有18位ID。其他部分和标准帧差不多。

消息类型

CAN总线支持四种消息类型：

  1. 数据帧（Data Frame）：用于传输实际数据。这是最常见的帧类型。RTR和IDE都是显性位。
  2. 远程帧（Remote Frame）：用于请求其他节点发送特定 ID 的数据帧。不带数据，RTR为隐性，用于请求某个节点发送数据，相当于喊一嗓子：兄弟，发个数据包过来！
  3. 错误帧（Error Frame）：当节点检测到错误时发送，通知网络其他节点有错误发生，然后出错的节点会重发消息。
  4. 过载帧（Overload Frame）：用于通知总线上当前负载过高，请求短暂延迟。当某个节点忙不过来，处理不过收到的帧时，会发个过载帧，争取点喘息时间。

CAN协议的关键机制

多主仲裁机制

简单来说，就是解决多个节点同时想发消息时的优先级问题。

  • 所有节点通过总线竞争发送数据时，ID数值越小的帧优先级越高（例如ID=0x100的帧优先于ID=0x200的帧）。
  • 仲裁过程：节点同时发送数据时，逐位比较电平。若某节点发送隐性电平（1），而总线上出现显性电平（0），则该节点主动退出竞争，转为接收状态。

错误检测与处理

  • 错误类型：位错误（发送与接收电平不一致）、填充错误（连续5个相同电平未插入相反电平）、CRC错误、格式错误、ACK错误等。
  • 错误处理：节点检测到错误后发送错误帧，通知所有节点丢弃当前帧；错误计数器记录错误次数，超过阈值（如127次）的节点进入“被动错误状态”（仅能发送被动错误帧），严重错误时进入“总线关闭状态”（暂时退出通信）。

数据重传机制

  • 若发送方未收到ACK确认（可能因接收方故障或总线冲突），会自动重传数据帧（最多重传多次，具体次数由实现决定）。

CAN协议的扩展版本

为满足更高数据传输需求，CAN协议衍生出多个扩展版本：

  1. CAN FD（Flexible Data-Rate）：
    • 核心改进：数据段速率可提升至5Mbps（仲裁段仍保持较低速率），数据场长度扩展至64字节（标准CAN仅8字节）。
    • 应用场景：适用于需要传输大量数据的应用（如高级驾驶辅助系统ADAS、摄像头数据传输）。
  2. CAN XL：
    • 更高带宽：支持更高速率（如10Mbps以上）和更大 payload（最高2048字节），面向未来智能汽车的高带宽需求。

CAN协议在车载网络中的应用

CAN总线在汽车电子和工业控制领域简直无处不在。

比如新能源汽车的BMS（电池管理系统），通过CAN总线实时监控电池状态，SOC、SOH、温度、电压等数据飞速在ECU间传递。

工业领域，像是Modbus或DeviceNet这样的协议，底层也靠CAN总线撑腰。

相比传统的点对点连接，CAN总线的多主架构让系统扩展性强到爆，甚至随手加个节点都随随便便。

想象一下现代汽车，发动机控制、ABS、仪表盘、空调系统……每个模块都是一个ECU，它们通过CAN总线组成一个高效的通信网络。

就像一群人在群聊里实时交流，消息井然有序，互不干扰。比如你踩油门，发动机ECU立马收到指令，调整喷油量，整个过程非常顺畅。

  1. 典型应用场景：
    • 动力系统：发动机控制、变速箱控制（需高实时性）。
    • 底盘系统：ABS防抱死、ESP电子稳定程序。
    • 车身电子：车窗控制、灯光控制、空调系统。
    • 安全系统：安全气囊、碰撞检测。
  2. 与其他车载网络的协同：
    • CAN通常作为整车通信的骨干网络，与LIN（低速、低成本，用于车窗等简单设备）、FlexRay（高实时性、高带宽，用于底盘控制）、以太网（大数据传输，如自动驾驶传感器数据）协同工作，形成分层网络架构。

CAN协议凭借其高可靠性、实时性和低成本优势，成为汽车电子通信的基石。随着汽车智能化与电动化的发展，CAN FD和CAN XL等扩展版本进一步提升了带宽与数据处理能力，而CAN与其他车载网络（如以太网）的协同也将成为未来车载通信架构的核心趋势。

如何分析 CAN 总线通信协议

分析 CAN 总线通信通常涉及到捕获总线上的原始数据，然后对这些数据进行解码和解释，以理解各个消息的含义。对于 Android 开发者来说，这可能涉及到通过蓝牙 OBD-II 适配器与车辆 CAN 总线交互，或者在嵌入式系统中直接与 CAN 控制器通信。

1. 硬件工具准备：

  • CAN 总线分析仪/接口卡：这是最核心的工具。它们可以将 CAN 总线上的物理信号转换为计算机可以理解的数字信号。常见的有：
    • USB 转 CAN 接口：如 PCAN-USB, Kvaser USBcan, IXXAT USB-to-CAN 等。这些通常用于连接到 PC 进行分析。
    • OBD-II 转 CAN 适配器：对于汽车应用，许多 OBD-II 适配器（例如 ELM327 兼容的蓝牙或 Wi-Fi 适配器）可以让你通过手机或电脑访问车辆的 CAN 总线数据，但功能可能受限。
  • 连接线缆：连接 CAN 分析仪和 CAN 总线（通常是 OBD-II 端口或直接连接到 CAN_H/CAN_L）。
  • 带有合适软件的计算机：用于捕获、显示和解析 CAN 数据。

2. 软件工具准备：

  • CAN 总线监测软件：大多数 CAN 接口卡都附带自己的软件，例如 PCAN-View, Kvaser CanKing 等。这些软件可以实时显示总线上的消息，包括 ID、数据、时间戳等。
  • CAN 数据库文件（DBC 文件）：这是分析 CAN 数据的关键。DBC 文件是一种标准格式，它包含了 CAN 消息的定义，例如：
    • 每个 CAN ID 对应的消息名称。
    • 每个消息中各个信号（Sensor Readings, Status, Commands）的起始位、长度、字节顺序（大小端）、缩放因子、偏移量和单位。
    • 信号的有效值范围。
    • 枚举值（例如，某个字节代表“开”或“关”）。 有了 DBC 文件，原始的十六进制数据就能被解析成有意义的物理值，例如发动机转速、车速、油门位置等。
  • 数据分析工具：如果需要更深入的分析，可以使用 MATLAB/Simulink, Python (使用 python-can 库), Wireshark (结合 CAN 插件) 等工具进行数据处理、可视化和模式识别。

3. 分析步骤：

  1. 连接硬件：将 CAN 分析仪连接到目标 CAN 总线。对于汽车，通常是连接到 OBD-II 端口。确保总线已上电。
  2. 配置软件：
    • 选择正确的 CAN 接口：在软件中选择你连接的 CAN 接口设备。
    • 设置波特率（Baud Rate）：CAN 总线上的所有设备必须以相同的波特率通信（例如 500 kbps, 250 kbps）。你需要根据目标系统设置正确的波特率。许多分析仪支持自动检测。
    • 设置过滤（Filtering）：如果你只对特定 ID 的消息感兴趣，可以设置 ID 过滤器，以减少显示的数据量。
  3. 捕获数据：开始捕获 CAN 总线上的数据。你会看到一系列十六进制的 CAN 帧。
    • 观察总线活动：注意哪些 ID 的消息频繁出现，哪些消息在特定操作下（例如踩油门、刹车）会发生变化。
    • 触发特定事件：在分析车辆 CAN 总线时，执行特定的操作（如打开车窗、踩刹车、启动引擎等），然后观察哪些 CAN 消息随之变化。这有助于你找到与这些操作相关的消息 ID 和数据。
  4. 解码数据（使用 DBC 文件）：
    • 导入 DBC 文件：将对应的 DBC 文件导入你的 CAN 分析软件。
    • 实时解析：软件会根据 DBC 文件的定义，将原始的十六进制数据自动解析成有意义的信号值（例如，从 0x1A0 ID 的消息中解析出“发动机转速”为 2500 RPM）。
    • 手动解码（如果无 DBC）：如果没有 DBC 文件，你需要进行逆向工程。这通常是一个耗时且需要经验的过程：
      • 隔离消息：通过筛选和观察，找到你感兴趣的特定功能（如车速、门状态）对应的 CAN ID。
      • 分析数据变化：对特定 ID 的数据字段进行多次捕获，每次都改变对应的物理量（例如，让车速从 0 加速到 100 km/h，观察数据字段的十六进制值如何变化）。
      • 推断数据格式：根据数据变化的规律，推断出数据的字节顺序、长度、缩放因子、偏移量。这可能需要了解一些常见的编码方式，如 little-endian/big-endian，有符号/无符号整数，浮点数等。
      • 创建自己的 DBC 文件：当你识别出一些信号后，可以创建自己的 DBC 文件来记录这些发现，方便后续分析和开发。
  5. 数据分析与应用：
    • 数据可视化：将解析出的信号数据绘制成图表，更直观地观察其变化趋势。
    • 故障诊断：通过分析 CAN 消息，可以识别通信故障、传感器故障或 ECU 内部问题。
    • 功能开发：对于 Android 开发者，理解 CAN 消息后，你可以在应用程序中读取车辆数据（例如仪表盘信息、故障码），或发送特定指令来控制车辆功能（如果允许且安全）。

CAN协议的优缺点

  • 优点：
    • 高可靠性：抗干扰能力强，错误检测与恢复机制完善。
    • 实时性强：优先级仲裁确保关键信息优先传输。
    • 成本低：简化线束设计，降低整车成本。
    • 成熟生态：广泛支持的工具链和芯片（如NXP、Infineon的CAN控制器）。
  • 缺点：
    • 带宽有限：标准CAN最大速率1Mbps，数据场仅8字节，难以满足高清摄像头等大数据传输需求（需CAN FD或以太网补充）。
    • 无内置加密：需额外机制（如SecOC）保障信息安全（针对新能源车的V2X通信需求）。

下一篇将介绍基于中央服务的SOA架构，和CAN总线的分布式架构做对比。