1. 总线架构与通信模型

1.1 单主多从架构

• 拓扑为单主多从：1 个主节点 + 最多 15 个从节点。
• 主节点负责总线调度，从节点仅在收到对应帧头后方可发送响应。
• 无主从竞争：不存在总线仲裁机制，通信时序由主节点完全控制。
• 主节点通常同时作为 CAN 网关，负责将 LIN 集群的数据转发到 CAN 骨干网。

1.2 与 CAN 的差异

1.3 典型应用场景

LIN 作为 CAN 的低成本补充，适用于对实时性要求不高、布线简单的场景：

• 车门模块（车窗升降、门锁、后视镜调节）
• 座椅控制（位置记忆、加热）
• 空调系统（风门执行器、温度传感器）
• 灯光控制（氛围灯、阅读灯）
• 雨刷与洗涤系统

2. 物理层与信号定义

2.1 信号电平

LIN 基于 ISO 9141（K-line）单线架构：

与 CAN 类似，LIN 也采用线与逻辑：任意节点将总线拉低（显性）即可覆盖其他节点的隐性状态。区别仅在于 CAN 用差分对实现，LIN 用单线 + 上拉电阻实现。

2.2 上拉电阻

• 每个节点内部有弱上拉电阻（约 30 kΩ）+ 二极管。
• 主节点外部需接强上拉电阻（典型 1 kΩ），用于维持总线隐性状态。
• 上拉电阻取值影响上升时间、静态功耗与负载能力。典型范围：1 kΩ ~ 2 kΩ。

2.3 位时序与同步

• 采用 UART/SCI 风格的异步串行通信。
• 总线上传输的每一个字节在物理层均封装为：1 个起始位（显性）+ 8 个数据位 + 1 个停止位（隐性），共 10 个位时间。
• 从节点通过 Sync Field（0x55，即 01010101b）测量主节点的位时间，校准自身波特率。

3. 帧格式

LIN 帧由**帧头（Header）和响应（Response）**两部分组成。主节点发送帧头，从节点根据帧头决定是否发送响应。

3.1 帧结构

3.2 PID 奇偶校验

PID 中高 2 位 P0、P1 由低 6 位 ID 计算得出：

• P0 = ID0 ⊕ ID1 ⊕ ID2 ⊕ ID4
• P1 = ¬(ID1 ⊕ ID3 ⊕ ID4 ⊕ ID5)

从节点接收后重新计算并比对，若不一致则忽略该帧。

3.3 数据长度与 ID 的关系（典型配置）

3.4 校验和机制

诊断帧（ID 0x3C / 0x3D）固定使用 Classic Checksum。

4. 帧类型与调度机制

所有帧类型在总线上遵循完全相同的物理帧格式：Sync Break → Sync Field → PID → Data → Checksum。帧类型的差异体现在主节点的调度策略与从节点的响应行为上，而非帧格式本身。

4.1 无条件帧（Unconditional）

• 主节点按调度表周期性发送帧头，指定从节点响应。
• 用于需要持续监控的状态量（如车门状态、座椅位置），即使数据未变化，周期性刷新也可确认节点在线并检测通信故障。

4.2 事件触发帧（Event Triggered）

• 主节点发送帧头，多个关联从节点可能同时响应。
• 用于偶尔变化的状态（如门把手、座椅按键）。若多个从节点同时响应，总线数据冲突，主节点在后续周期改用无条件帧逐一查询关联节点。
• 作用：减少总线负载。避免对低频变化信号进行周期性无条件轮询导致的带宽浪费。

冲突回退机制：主节点在调度表中预先定义该事件触发帧所关联的无条件帧集合。冲突发生后，主节点在接下来的调度周期中，依次发送这些关联无条件帧的帧头，逐一接收响应，间接确定哪些从节点有数据待发送。

4.3 偶发帧（Sporadic）

• 主节点在调度表中预留的时隙内，当关联信号更新时发送。
• 用于主节点需要主动广播的、非周期性数据。
• 动态优先级：多个偶发帧同时待发时，ID 最小者优先发送。

4.4 诊断帧（Diagnostic）

• ID 0x3C（主节点请求），ID 0x3D（从节点应答）。
• 固定 8 byte 数据场，基于 UDS/ISO-TP 协议。
• 用途：故障码读取、节点配置（如配置 NAD、PID 映射表）、软件刷写等。

4.5 保留帧（Reserved）

• ID 0x3E：用户自定义帧，厂商可自由定义用途。
• ID 0x3F：LIN 规范保留，不建议使用。

5. 通信调度

5.1 时间触发调度表

LIN 采用时间触发调度表（Schedule Table），由主节点严格按照时隙轮询各从节点。

• 调度表是主节点内部维护的一张时间-动作映射表，规定每个时隙应发送哪个帧头（以 PID 标识）及帧间间隔。
• 无总线竞争：主节点控制所有通信时序，从节点仅在收到对应帧头后才可发送响应。
• 确定性延迟：每个帧的传输时隙预先定义，最坏情况下的响应时间可计算。
• 从节点无主动发信权：不能主动向总线发送数据，必须等待主节点轮询。

5.2 从节点响应机制

• 每个从节点在配置阶段（通过 LDF 文件或诊断配置）建立响应映射表，记录自身需要响应的 PID 列表、对应的数据长度及数据来源。
• 从节点收到帧头后，将 PID 与本地映射表比对；若匹配，则在规定时隙内发送响应（数据场 + 校验和场）。
• 从节点不发送帧头（Sync Break、Sync Field、PID），仅发送响应部分。
• 若 PID 不匹配，从节点保持静默，不占用总线。

6. 睡眠与唤醒

6.1 睡眠模式

• 进入条件：主节点发送睡眠命令（诊断帧 ID 0x3C，首字节为 0x00）；或总线空闲 ≥ 4 秒。
• 进入后所有节点停止通信，总线保持隐性状态，降低静态功耗。

6.2 唤醒机制

• 唤醒信号：总线上出现 250~5000 μs 的显性脉冲。
• 主节点或从节点均可发送唤醒信号。
• 若首次唤醒失败，最多重复 3 次，间隔 150~250 ms。
• 唤醒后所有节点重新同步，主节点恢复调度表运行。

7. 版本差异与行业现状

7.1 LIN 1.x 与 LIN 2.x 的差异

7.2 行业现状

• 当前汽车行业主流使用 LIN 2.x（以 LIN 2.1 和 LIN 2.2A 为主），LIN 1.x 已基本淘汰。
• LIN 2.x 与 AUTOSAR（AUTomotive Open System ARchitecture，汽车领域开放式系统架构标准）兼容，已成为 OEM（Original Equipment Manufacturer，整车厂）的普遍要求。
• 新项目中几乎不会选用 LIN 1.x。

8. 调度表与响应映射表设计

8.1 主节点调度表设计

主节点调度表是一张时间-动作映射表，定义了总线运行期间每个时隙的通信任务。调度表在系统初始化时加载，主节点在运行期间严格按照表中的时隙顺序与间隔时间执行。

调度表条目结构：

调度表运行逻辑：

1. 主节点按 slot_index 顺序遍历调度表。
2. 在每个时隙开始时，主节点发送对应 pid 的帧头（Sync Break + Sync Field + PID）。
3. 若为无条件帧 / 诊断帧：主节点发送帧头后等待从节点响应，或主节点自身发送数据（诊断请求）。
4. 若为事件触发帧：主节点发送帧头后监听总线，若收到有效响应则记录数据；若检测到冲突（校验和错误），则在后续周期中依次发送 assoc_frames 中的无条件帧逐一查询。
5. 若为偶发帧：主节点检查关联信号是否更新，若未更新则跳过该时隙（发送帧头但无响应，或完全不发送）。
6. 当前时隙结束后，主节点等待 delay_ms 再进入下一个时隙。
7. 调度表遍历完毕后，主节点可选择循环执行或进入睡眠。

8.2 从节点响应映射表设计

从节点响应映射表是各从节点内部维护的一张PID-响应规则映射表，在配置阶段（通过 LDF 文件或诊断配置）写入。从节点在运行期间仅依赖该表决定是否响应总线上的帧头。

响应映射表条目结构：

响应映射表运行逻辑：

1. 从节点持续监听总线。
2. 检测到 Sync Break 后，接收 Sync Field 并校准波特率。
3. 接收 PID，提取低 6 位 ID 并验证奇偶校验位。
4. 若奇偶校验失败，忽略该帧，继续监听。
5. 若奇偶校验通过，将 ID 与响应映射表中的 pid 逐一比对。
6. 若匹配且 enabled 为 true：从节点在帧头结束后，从 data_src 读取 data_len 字节数据，计算 checksum_type 指定的校验和，依次发送数据场与校验和场。
7. 若不匹配或 enabled 为 false：从节点保持静默，不占用总线。
8. 发送响应期间，从节点持续监听总线；若检测到总线电平与自身发送不一致（事件触发帧冲突场景），立即停止发送并返回监听状态。

8.3 调度表示例

以下为一个典型汽车 LIN 集群的完整调度表：

调度表运行流程：

1. T=0 ms：时隙 0，Node A 发送 PID 0x10 帧头，Node B 响应 2 byte 车门状态，间隔 15 ms。
2. T=15 ms：时隙 1，Node A 发送 PID 0x20 帧头，Node C 响应 2 byte 座椅位置，间隔 15 ms。
3. T=30 ms：时隙 2，Node A 发送 PID 0x30 帧头，Node B 与 Node C 可能同时响应。
   • 若无冲突：正常接收数据，间隔 20 ms。
   • 若冲突：Node A 在下一周期中依次发送 PID 0x10（查询 Node B）与 PID 0x20（查询 Node C），间隔累加。
4. T=50 ms：时隙 3，Node A 检查故障码是否更新，若有则发送 PID 0x40 帧头，Node B 响应 4 byte，间隔 15 ms。
5. T=65 ms：时隙 4，Node A 发送 PID 0x3C 诊断请求帧（主节点自身发送 8 byte 数据），间隔 25 ms。
6. T=90 ms：时隙 5，Node A 发送 PID 0x3D 帧头，被诊断的从节点响应 8 byte，间隔 25 ms。
7. T=115 ms：时隙 6，Node A 发送 PID 0x3E 保留帧，间隔 15 ms。
8. T=130 ms：调度表遍历完毕，主节点可选择循环执行或进入睡眠。

8.4 响应映射表示例

Node B（车门模块）的响应映射表：

Node C（座椅模块）的响应映射表：

映射表运行示例：

• Node B 收到 PID 0x10 的帧头 → ID 匹配 → 从车门状态寄存器读取 2 byte → 计算 Enhanced Checksum → 发送数据场 + 校验和场。
• Node B 收到 PID 0x20 的帧头 → ID 不匹配 → 保持静默，不发送任何数据。
• Node C 收到 PID 0x30 的帧头 → ID 匹配 → 从按键状态寄存器读取 2 byte → 发送响应。若 Node B 同时响应，总线冲突，两者均检测到不一致后停止发送。

9. 三节点网络通信过程模拟

以下以一个典型汽车 LIN 集群为例，模拟三个节点在 LIN 总线上的完整交互过程。

9.1 网络拓扑与节点定义

总线波特率：19.2 kbps（位时间约 52 μs）。

9.2 场景一：无条件帧周期性通信

Node A 按调度表发送无条件帧，轮询 Node B 与 Node C。

时隙 1：Node A → Node B

时隙 2：Node A → Node C

节点过滤行为：

• Node B 在收到 PID 后比对 ID，仅当 ID 匹配自身配置（如 0x10）时才发送响应。
• Node C 收到 0x10 的帧头后，忽略该帧，不发送响应。
• Node A 在发送帧头后等待响应超时（约 40 个位时间），若未收到响应则记录通信错误。

9.3 场景二：事件触发帧冲突处理

Node A 在调度表中插入事件触发帧，用于检测门把手或座椅按键的偶发输入。

冲突发生：

冲突检测：

• Node B 与 Node C 同时在数据场期间发送响应。
• 由于两者发送的数据不同，总线上出现位电平不一致（线与结果与发送方预期不符）。
• Node B 与 Node C 在发送过程中监听总线，检测到不一致后均停止发送。
• Node A 在接收数据时发现校验和不匹配，判定该帧无效。

冲突解决：

1. Node A 在下一调度周期中，改用无条件帧分别查询 Node B（ID 0x10）与 Node C（ID 0x20）。
2. Node B 响应：车门把手状态 0x01。
3. Node C 响应：座椅按键状态 0x02。
4. 冲突解决后，Node A 恢复事件触发帧的调度。

9.4 场景三：诊断帧通信

Node A 通过 UDS 协议对 Node B 进行诊断。

诊断请求：

诊断应答：

诊断帧固定使用 8 byte 数据场，不足部分填充 0xFF。Classic Checksum 仅覆盖数据场，不覆盖 PID。

9.5 场景四：睡眠与唤醒

进入睡眠：

1. Node A 发送睡眠命令：诊断帧 ID 0x3C，首字节为 0x00，其余字节为 0xFF。
2. Node B 与 Node C 收到睡眠命令后，在 4 秒内完成本地状态保存，随后进入睡眠模式。
3. 若 4 秒内无新帧，总线空闲超时，所有节点自动进入睡眠。
4. 睡眠后总线保持隐性，静态功耗降至微安级。

唤醒过程：

若 Node A 在 3 次唤醒脉冲内未响应，Node B 停止唤醒尝试，等待下一次外部事件触发。

9.6 通信时序汇总

以下为一个完整调度周期内三个节点的总线活动概览：