AutoSar通信服务—车载LIN总线详解

诞生背景和应用场景

LIN总线（Local Interconnect Network）是一种低成本、低速率的串行通信总线，主要应用于汽车电子领域。它的诞生背景和应用场景如下：

1. 背景：

   • 成本压力： 汽车制造商需要降低成本，特别是对于辅助功能和车内通讯系统。
   • 功能要求： 需要一种低复杂度、低功耗的通信解决方案，以满足车辆电子系统之间的基本通信需求。

2. 应用场景：

   • 车身电子控制单元（ECU）通信： LIN总线通常用于连接车内各种辅助设备的控制单元，如窗户升降控制、座椅调节、天窗控制等。这些设备通常不需要高速率或复杂的通信协议，LIN提供了足够的带宽和简单的通信机制。
   • 门控系统： 控制车门锁、窗户升降等功能。
   • 照明系统： 控制车内和车外的照明设备。
   • 座椅控制： 调节座椅位置、加热、通风等功能。
   • 信息娱乐系统： 控制音响系统、显示屏等。
   • 车身控制模块： 管理车身上的各种传感器和执行器的通信。

LIN总线因其简单、低成本的特点，在车辆内部的辅助系统和控制单元中得到了广泛应用。它与其他高速率总线（如CAN总线）相比，不同点在于其通信速率低（通常在19.2 kbit/s到20 kbit/s之间），但适合于不需要高速率通信的应用场景，同时具备较低的功耗和成本优势。

LIN总线和CAN总线在汽车电子系统中常常一起配合工作，以实现不同功能需求的通信。这两者的结合通常体现在不同类型的控制单元中，它们各自负责不同的任务并通过特定的方式互联。以下是LIN和CAN配合工作的机制：

1. 分层结构：

   • CAN总线： 主要负责高带宽、实时性强的通信需求，常用于动力总成控制系统、底盘控制系统、安全系统（如ABS、ESP）等重要模块之间的通信。
   • LIN总线： 通常用作CAN总线的补充，处理较低优先级和低带宽需求的通信。LIN总线主要用于车内非关键性设备的通信，如车窗、座椅、车灯等。

2. 主从架构：

   LIN总线采用主从架构，而CAN总线是多主架构。它们之间的协作通常通过一个网关节点实现，这个节点既连接CAN总线又连接LIN总线，并负责在两者之间进行数据交换。

3. 网关节点：

   网关节点是一个具有双总线接口的ECU，能够在LIN总线和CAN总线之间传递信息。它的作用包括：

   • 协议转换： CAN总线和LIN总线之间的通信协议不同，网关节点可以将CAN帧转换为LIN帧，反之亦然。
   • 数据管理和同步： 网关根据数据优先级、带宽需求和时序要求来调度LIN与CAN之间的数据传输。例如，从CAN总线上接收到的指令可能需要传递给LIN网络中的某个设备，网关将数据缓存在一定的时间窗口内，按照LIN的主从通信规则传送给相应的设备。

4. 典型应用场景：

   • 车门模块： 车门模块可以通过LIN总线控制车窗、座椅、镜子等低速通信设备，而车门模块本身通过CAN总线与车辆的中央控制器通信。中央控制器接收到的CAN指令通过网关转换为LIN信号，再由LIN总线控制相关设备执行操作。
   • 空调系统： 中央空调控制模块通过CAN总线接收来自驾驶员控制面板的命令，然后通过LIN总线控制风扇、温度调节器等设备。

5. 优点：

   • 优化资源使用： CAN总线负责高优先级、关键性的通信任务，而LIN总线则处理低优先级和低速通信任务，减少CAN总线的负载。
   • 降低成本： 通过LIN总线连接不需要高速通信的设备，可以减少对高速CAN节点的依赖，从而降低系统整体的成本。
   • 减少布线复杂度： 采用LIN总线可以减少系统的线缆

LIN总线硬件接口

和大部分通讯总线一样，LIN总线也是由LIN控制器和收发器组成。LIN的控制器是基于UART数据格式，采用单主多从设备的模式。是 UART的一种特殊模式。一般控制器会集成在MCU内部，只需要配置寄存器就能使能LIN通信

LIN总线协议

LIN总线协议（Local Interconnect Network）是一种专为汽车电子系统设计的低成本、低速率的串行通信协议。它采用单主多从架构，主要用于车内非关键系统的通信，如车窗、座椅、车灯等控制。以下是LIN总线协议的主要组成部分和工作原理：

1. 架构

LIN协议采用主从架构，总线上的所有通信由主节点控制，主节点发起通信并调度从节点的响应。典型的架构包括一个主节点和多个从节点（最多16个从节点）。所有从节点都被动监听总线，只有在主节点发出请求时，指定的从节点才会进行数据传输。

2. 数据帧格式

LIN总线采用帧结构来传输数据，典型的LIN帧由报文头和响应部分组成。一个完整的LIN帧包括以下几部分：

2.1 报文头（Header）：

• 同步间隔（Break Field）： 用于标记数据帧的开始，长度一般为13位的低电平信号，确保所有从节点都能检测到即将到来的通信。
• 同步字段（Sync Field）： 一个固定的字节（0x55），用于同步从节点的时钟，使所有节点能够根据该同步信号调整它们的采样时间。
• 标识符字段（Identifier Field）： 用于标识当前帧的功能或目的，6位数据位加上2位奇偶校验位。标识符指定帧的类型，以及哪个从节点应该响应。

2.2 响应部分（Response）：

• 数据字段（Data Field）： 实际的数据信息，由1到8个字节组成，可以是主节点或从节点发送。
• 校验和字段（Checksum Field）： 用于错误检测，计算方式可以是经典的LIN 1.3校验（仅基于数据字段），或LIN 2.0增强校验和（包括标识符）。

具体形式如下所示

3. 通信过程

   • 主节点发起通信： LIN总线的通信完全由主节点控制。主节点周期性地向总线发送报文头，包括同步字段和标识符字段。

   • 从节点响应： 从节点根据接收到的标识符决定是否发送响应数据。如果报文头中指定了该从节点，它将在响应部分中发送数据。如果未指定该从节点，则保持监听状态。

     

   • 数据传输： 传输的数据可以是主节点发送给从节点的，也可以是从节点发送给主节点的，具体取决于标识符。

4. 帧类型

   LIN协议定义了几种不同类型的帧，用于不同的通信需求：

   • 无应答帧（Unconditional Frame）： 主节点发出请求，从节点按预定协议响应。这种帧常用于固定周期的数据传输。
   • 事件触发帧（Event-Triggered Frame）： 主节点发出包含一组标识符的帧，从节点只有在某个特定事件发生时才会发送响应。
   • 诊断帧（Diagnostic Frame）： 用于传输诊断和配置信息。这种帧的标识符是保留的，用于专门的诊断通信。

5. 主节点的角色

   主节点不仅仅负责发起通信，还需要管理整个总线的调度。主节点有一个调度表，规定在特定的时间间隔内发送哪些帧。通过调度表，主节点确保所有从节点的通信按时发生，避免总线冲突。

6. 错误检测

   LIN协议提供了一些简单的错误检测机制，主要包括：

   • 校验和： 用于验证数据的完整性，如果校验和不匹配，接收方将丢弃数据。
   • 奇偶校验： 标识符字段中的两个校验位用于检测标识符传输中的错误。

LIN总线应用举例—获取四个车门状态

每个车门可能都有一个独立的LIN从节点来监控门的状态（开关状态、锁定状态等），而车身控制单元（BCM, Body Control Module）作为LIN总线的主节点，负责与各个车门节点通信并获取它们的状态。LIN总线拓扑结构是主从结构的星型模型，所有传输都是Master发起，Slave不能主动发起请求，想要获取某个变量值，就需要不断轮询对应的状态。

1. 架构概述：

• 主节点：车身控制单元（BCM）是LIN总线的主节点，它负责发起与四个车门LIN从节点的通信，周期性地查询各个车门的状态。
• 从节点：每个车门上有一个LIN从节点，负责检测车门的状态（例如：车门是否关闭、是否锁定）并将其状态信息通过LIN总线返回给主节点。

2. 通信流程：

  1. **主节点发送报文头：**
     - BCM作为主节点，按照预设的调度表，定期向每个车门的LIN从节点发送报文头。每个报文头包含一个特定的标识符（ID），用于指定哪个从节点应响应。
     - 假设每个车门的状态使用不同的标识符，例如：
       - 标识符 0x01：请求左前门的状态
       - 标识符 0x02：请求右前门的状态
       - 标识符 0x03：请求左后门的状态
       - 标识符 0x04：请求右后门的状态

  2. 从节点响应：
     - 当某个车门的LIN从节点接收到匹配的标识符后，它会通过LIN总线返回数据。这个响应数据字段可能包括车门的当前状态，例如：
       - 位0：车门是否关闭（1表示关闭，0表示打开）
       - 位1：车门是否锁定（1表示锁定，0表示解锁）
     - 例如，假设响应数据为`0x03`，表示车门已关闭且已锁定。

  3. 数据传输顺序：
     - 主节点按照一定的时间表轮询每个车门的状态。通常，BCM会首先发送同步信号和标识符，然后各个车门的从节点在指定的时间窗口内发送响应数据。

3. 数据传输示例：

  1. 获取左前门状态：
     - 主节点发送报文头，包含标识符 0x01，表示查询左前门的状态。
     - 左前门从节点接收标识符 0x01，检测车门状态（假设车门已关闭且已锁定），并发送响应数据`0x03`。
     - 主节点接收到响应后，将解析数据，并更新车门状态信息。

  2. 获取右前门状态：
     - 主节点发送报文头，标识符 0x02，用于查询右前门的状态。
     - 右前门从节点返回数据`0x01`，表示车门打开，未锁定。

  3. 按顺序轮询其他车门状态：
     - 主节点继续按类似方式发送报文头，依次查询左后门和右后门的状态。

4. 状态更新和处理：

• 当BCM轮询完所有车门的状态后，它将所有结果存储在内存中，以便车内其他系统（如中控锁、报警系统）根据车门的状态采取行动。如果某个车门未关好或者未锁定，可能会触发警告或安全锁定功能。

5. LIN通信调度：

• 主节点通常有一个预先设定的调度表，定期轮询每个车门的状态。例如，车身控制单元每隔100毫秒查询一次四个车门的状态，以确保系统能快速响应用户的操作（如车门的开关或锁定）。

LIN总线诊断应用流程

在LIN（Local Interconnect Network）总线上，诊断应用主要用于检测、报告和处理车辆中的电子控制单元（ECU）的故障以及监控系统的状态。这种诊断功能在汽车中尤为重要，确保系统能够及时发现问题，保障安全性和稳定性。在AUTOSAR架构中，LIN诊断功能也是通信服务层的一部分，并与诊断通信协议（如UDS）结合使用。

LIN诊断应用的关键要素

• 诊断服务：LIN网络中的诊断服务用于检查ECU的健康状态、读取错误码、清除错误码、监控系统运行状态等功能。这些服务通常依赖于诊断协议，如UDS（Unified Diagnostic Services）。
• 诊断请求和响应帧：LIN网络上的诊断功能通过特定的诊断帧进行通信。诊断帧主要包括：
  • Master Request Frame（主节点请求帧）：用于主节点发起诊断请求。
  • Slave Response Frame（从节点响应帧）：从节点根据请求发送诊断响应。
• 故障存储：每个从节点通常会具有故障存储功能，用于记录ECU的错误状态。在诊断时，主节点可以请求从节点读取这些故障存储中的数据，了解潜在问题。
• 诊断会话：诊断会话是进行高级诊断操作的状态。例如，写入新配置参数或执行ECU重置等。这些会话通常需要认证或特定的安全解锁步骤。

LIN诊断通信的工作流程

LIN诊断应用的工作流程通常如下：

1. 主节点发起诊断请求：主节点通过发送“Master Request Frame”向从节点发起诊断请求，例如读取ECU的故障码或状态信息。
2. 从节点处理诊断请求：从节点接收到诊断请求后，会根据请求类型执行相应的操作，例如从故障存储读取错误码，或执行特定的测试操作。
3. 从节点发送响应帧：从节点完成诊断请求后，通过“Slave Response Frame”将诊断结果或数据返回给主节点。
4. 主节点处理诊断数据：主节点接收到从节点的响应后，处理相关诊断信息，并在必要时执行后续的动作，比如清除错误码或发出进一步的诊断命令。

LIN诊断帧的构成

诊断通信是通过特定的 诊断帧（Diagnostic Frame） 来进行的。诊断帧的构成与普通的 LIN 数据帧略有不同，通常使用 0x3C 和 0x3D 的帧ID 来标识。诊断通信主要用于传输诊断请求和响应数据，比如读取故障码、ECU配置等。

诊断帧的两种类型

1. 主节点请求帧（Master Request Frame，ID=0x3C）

• 这是主节点向从节点发起诊断请求的帧。在数据域中，主节点可以请求从节点的诊断信息或发送控制命令。

结构：

• Frame ID: 0x3C
• Data: 8字节的诊断请求数据
• Checksum: 校验和

例子：主节点请求从节点提供ECU故障码。

2. 从节点响应帧（Slave Response Frame，ID=0x3D）

• 当从节点接收到主节点的诊断请求后，使用 0x3D ID 发送诊断响应帧。数据域中包含响应数据，如故障码或其他诊断信息。

结构：

• Frame ID: 0x3D
• Data: 8字节的诊断响应数据
• Checksum: 校验和

例子：从节点返回主节点请求的诊断数据，如故障码或传感器状态。

诊断请求帧通常由以下几部分构成：

• NAD: 用于标识目标从节点。
• PCI (Protocol Control Information): 用于描述数据传输的控制信息。
• SID (Service Identifier): 表示具体的诊断服务，例如读DTC、发送数据等。
• 数据字节: 具体的诊断数据。

根据官方文档来看

稍微翻译一下，其中NAD (Node Address Identifier) 代表了节点的地址，以便主节点能够在多从节点的网络中准确地与特定的从节点进行通信。

LIN诊断通信中LIN TP的作用

LIN TP（Transport Protocol） 是为了在 LIN总线 上支持大数据量的传输而设计的协议，因为标准的 LIN帧 每次最多只能传输 8字节 的数据。在某些应用场景下，特别是诊断服务或固件更新过程中，往往需要传输更大的数据量，因此引入了LIN TP来实现更大数据块的传输。

与CAN TP的功能类似—都是通过将大数据包分割成多个小帧，并通过帧序列的方式来逐个发送这些小帧。传输协议保证了各个帧的顺序以及整个数据块的完整性

LIN TP通常用于以下两类通信：

• 单帧通信（Single Frame）：适用于数据量小于或等于8字节的情况。一个帧就能完成数据传输，不需要进一步分割。
• 多帧通信（Multi-Frame Transmission）：当需要传输的数据大于8字节时，使用多帧传输，LIN TP将数据分成多个帧发送，并通过 分段和组装 来实现大数据包的完整传输。

在LIN TP中有两类主要的帧，用来支持多帧传输过程：

• SF（Single Frame，单帧）：用于小于或等于8字节的数据传输，一次性传输全部数据。
• FF（First Frame，首帧）：用于多帧传输的第一个帧，携带了要传输的总数据长度信息。首帧的前几字节包含数据长度，后面的字节则是实际的数据。
• CF（Consecutive Frame，连续帧）：在多帧传输中，首帧之后的后续帧，依次传输剩余的数据。
• FC（Flow Control，流控制帧）：接收方用来通知发送方是否可以继续发送连续帧，控制流的发送速度。

LIN TP的基本流程

在多帧通信中，LIN TP的传输流程通常如下：

1. 发送首帧（FF）：
   • 当发送的数据大于8字节时，发送方首先发送一个首帧（FF）。该帧包含了总的数据长度以及首部分数据。
2. 流控制（FC）：
   • 接收方在接收到首帧后，发送流控制帧（FC），通知发送方可以继续发送连续帧。
3. 发送连续帧（CF）：
   • 发送方收到流控制帧后，开始分段发送剩余的数据，直到所有数据发送完成。
4. 接收与组装：
   • 接收方根据帧序列号按顺序接收数据，并将所有的连续帧组装成一个完整的数据包。