K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成

课程代码 K2-02 · 板块 K 控制、软件与标定 / 控制器硬件与安全 时长 约 3.5 小时（7 讲） 前置 K2-01 域控硬件架构或等效通信/嵌入式基础 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 K2-02 大纲的完整展开版

---

引言：把周期从 200 ms 提到 20 ms，实时性可能反而更差

热管理域控是整车上「对话对象最多」的控制器之一。它要向 BMS 要电芯温度、SOC 与热失控相关状态，要跟 VCU 与整车能量管理来回谈功率请求与仲裁结果，要向压缩机、PTC、电子阀、水泵、风门逐个下发指令并收回反馈，还要给仪表与 HMI 送状态与告警。上车之后最难查的那几类问题，也恰好都长在这条线上：台架上整定得好好的电池温控环，装到车上响应慢半拍，回头去改 PID 参数怎么改都不对；一路温度偶尔跳到一个「合法但离谱」的值，控制策略照单全收，事后翻数据看不出任何报错；诊断仪一挂上、或者一进 OTA 刷写窗口，本来跑得很稳的功能报文开始零星丢帧。这三件事的共同点是：在控制算法里找不到原因。它们的成因写在通信设计这一层——报文周期与最坏时延、失效值与判读顺序、以及这条总线上到底还有谁在占带宽。

这门课要交出的东西很具体：一份可评审、可交付的热管理通信矩阵，以及支撑它的四项判断力——给一路信号选对承载（CAN、CAN-FD、LIN 三者给的是三种性质不同的时间保证，不是档次高低）；读懂并写出矩阵里的关键字段，尤其是失效语义那几栏；把总线负载率与最坏情况延迟算到「能判断有没有裕量」的程度；以及在整车 EEA 里（网关转换、Zonal 路径、诊断与 OTA 报文共存）看出热管理信号的时序与优先级问题。前置是 K2-01 热管理控制器（域控/ECU）硬件架构：那门课讲这块板自己的边界，本课讲这块板与外面几十个节点之间的约定。

全课的走法是七讲。第 1 讲把三条总线的时间保证性质摆平，收成一条选承载的判据链；第 2 讲进 CAN 的错误检测、错误界定与 bus-off，讲清「协议怎么把一个坏节点逐级请出总线」，以及域控该怎么处置；第 3 讲专门给 LIN——调度表、地址冲突、诊断承载、从机状态字节与休眠唤醒；第 4 讲从「跟谁说话」开始定矩阵的字段，逐格填；第 5 讲写失效语义，也就是「收不到、收错了、收陈旧了」那几栏；第 6 讲算账——负载率怎么拆、最坏时延怎么分解、事件报文与周期报文各解决什么；第 7 讲把这份矩阵放回整车 EEA 里，看它跨过网关与区域控制器之后还剩多少假设成立。

钉子①：每一路信号的报文周期、超时时长与超时替代值，都要反选出来——本课把它归纳成三问：谁拿它闭环、那个环要多快、拿不到时它替代成什么。不由发送方按「我这个量自己变化多快」来定，更不照抄上一代平台或隔壁域控的经验值。理由是一条硬约束：当某个量是跨 ECU 闭环的反馈量（BMS 上报电芯温度 → 域控跑电池温控环；VCU 上报功率 → 前端散热环），报文周期与它的最坏时延直接决定这个环的带宽上界——链路给不了的响应速度，控制侧再怎么整定也补不回来。所以这三问的答案不在通信这一侧，而在消费者那一侧；它是动手写矩阵之前要先去问的，不是写完之后再补一段理由。

钉子②：通信矩阵不是一张信号表，是一份失效契约。只写了物理值、分辨率、偏移量、单位与周期的表，回答的只是「一切正常时这个数怎么解」。而链路上真正会发生的是另外四件事，每一件都必须逐信号写死在矩阵里：收不到（每个信号单独的 timeout 时长，以及超时后替代成什么）、收错了（E2E 保护的接收侧状态机、允许的最大连续错误数与恢复条件）、对方声明自己算不出来（SNA／无效值编码，以及「先判 SNA、再做量纲换算」这个判读顺序）、从不可用回到可用（回切要去抖，且进出用不同的门槛）。这四件里空着的任何一格，都不会自动变成「默认安全」——它是未定义行为；而未定义行为不会被任何测试用例覆盖，因为没有人知道该去测什么。集成阶段各家会按自己的理解各补一个默认值，那些默认值互不相同，且谁都没有写下来。

★ 本课最容易被读反的一句是「提高报文频率就等于提高实时性」。它的典型形态是：现场反映电池温升发现得晚，于是把电池最高温度报文的周期从 200 ms 改快十倍到 20 ms，然后认为问题解决了（200 ms 是本课典型案例给定的输入、20 ms 是那个错误动作的结果，两个数都不对应任何平台，⛔ 都不是推荐周期）。这个动作有两层是反的。其一，提频压不掉最坏时延的主项：一条报文从「值就绪」到「接收端可用」，要等到本报文的下一个发送时刻，要等总线上正在传的那一帧传完（仲裁是非抢占的，最坏一整帧），还要排在所有更高优先级报文的后面。提频只压缩第一项，同时把总线负载抬上去、让排队那一项一起变差——对一个优先级排在后面的 ID，在本来就繁忙的总线上，净效果可能是实时性反而更差，方向恰好相反。其二，它连缺口都找错了：电芯温度是分钟级的慢变量，200 ms 相对它并不慢；「越限与热失控前兆要尽快知道」这类需求要的是有最坏时延保证的事件触发报文，而周期报文在原理上给不了这个保证，两者的时延量级相差约两个数量级——量化对照放在第 6 讲，那里也是这条错话的合账处。⇒ 「快变量给短周期、慢变量给长周期」这句顺口的话，在本课只以被点破的错句形态出现；正面的规矩是第 4 讲那一条——周期按消费者反选。

本课凡是要「列一张表」的地方——有哪些链路类型可选、矩阵里要跟谁说话、负载核算要把谁算进去、这条链路上会出哪些事、矩阵里有哪几类信号、这条总线在整个生命周期里被谁用——都先把全集画出来、再逐项核射程，而不是顺着自己最熟的那条线索往下数。这不是讲究：沿单一线索枚举时漏掉的从来不是「少了一条」，而是整类不出现，而表面上那张表还是齐的、还是有头有尾。三个已经踩实的例子：沿「CAN → LIN」数链路类型，会整类漏掉车载以太网（Zonal 骨干绕不开它），也会整类漏掉 SENT／PWM 这类无仲裁、无寻址的点对点数字编码——把总线的概念套上去，会推出一堆并不存在的失效模式；沿「整车主要控制器」数通信对端，会整类漏掉诊断仪、产线设备与 OTA 主控，它们不出现在任何行驶场景里，却照样占总线、照样跟功能报文抢时间；沿「我这个域自己发的周期报文」数总线占用者，会整类漏掉诊断多帧与流控帧、DTC 上报与冻结帧读取、网络管理报文、OTA 刷写块传输、标定 DAQ 流量与网关转发进来的流量——而这几项全是突发的，最坏时延由尖峰决定、不由稳态均值决定。

射程也先划清，免得在正文里白找。CAN、CAN-FD 与 LIN 三条讲透；车载以太网只讲它在骨干上的位置、以及它把热管理信号的路径改成什么样，协议机制不展开。明确不在本课的几件事只写去向：SENT／PWM／模拟电压这类点对点接口归 K1-01 热管理传感器信号处理与故障诊断、G12-03 执行器硬件接口与电气规格 与 K2-01 热管理控制器（域控/ECU）硬件架构，无线上行遥测的车端实现归 K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算；拿到失效标志之后怎么分级、替代值在「保持上次值／保守常量／模型估计」里怎么三选一，判据本体归 K1-01 热管理传感器信号处理与故障诊断、降级等级归 K5-02 热管理故障处理与降级策略，本课只管把选择结果写进矩阵；一个量以哪一侧为权威（语义归属）以及场景枚举的定义权归 K3-01 整车热管理控制策略总览与模式管理；为什么要做 E2E 归 K2-03 功能安全（ISO 26262）在热管理中的应用，本课只讲接收侧怎么配；DTC 与诊断服务本身归 K5-01 OBD/UDS 诊断与故障码（DTC）设计；产线写入与追溯归 K6-09 产线下线与售后标定：工位项清单、配置写入与学习值管理，平台级地址规划归 G8-04 模块化标准化与平台复用策略；执行器失联后驱到哪个安全位归 G12-03 执行器硬件接口与电气规格，风门执行器那一侧交过来的模式切换时序约束来自 C2-03 风门驱动电机与执行器（步进/有刷/PWM）选型；休眠判据与暗电流预算归 K3-11 热管理域的上下电时序、run-on 编排与休眠期能耗预算；遥测信号的取舍与数据回流成本归 K7-03 数据驱动的能效自学习控制 与 K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算；接收侧任务相位归 K4-01 热管理嵌入式软件架构与 AUTOSAR 基础；集成模块把多个节点收进一个壳体之后的走线与地址问题衔接 G8-01 集成热管理模块（TMM/阀岛/超级水壶）架构 与 G8-02 多通阀 + 泵 + 传感器的一体化集成设计；燃料电池电堆控制器这一路对端归 O3-07 FCEV 系统级热管理模式管理与功率—热仲裁。还有一条不能忘：算出来的最坏时延不能停在本课，它要折进等效纯滞后的总账，那本账在 K3-05 PID/前馈/增益调度控制实战。标准这一层同样只写去向：CAN 的帧格式、错误界定与物理层去向 ISO 11898，LIN 系列去向 ISO 17987（北美整车的应用规范另有 SAE J2602），基于 CAN 的诊断承载去向 ISO 15765，诊断服务定义去向 ISO 14229——本课未取任何一份原文，因此只写「各管什么、去哪查」，不复述条款内容与限值，版次与实施日期一律以现行目录为准、引用前须自行核对。

最后交代一类数，免得在正文里白找。总线负载率的可接受上限、各路信号的具体报文周期与 timeout 取值、信号年龄的阈值、E2E 允许的最大连续错误数与回切去抖时间、bus-off 分级重入的退避间隔与次数上限、网关转发时延与 Zonal 各跳时延——这些全是平台相关量，取决于本项目的完整报文集、优先级分配、安全需求与后续扩展预留，只能由本项目的时序分析与实测给出，⛔ 本课一个都不给，图上也不会偷偷画一条门槛线代替它。本课给的是它们各自该由谁、按什么反选出来，以及算出来之后写进矩阵的哪一栏。这门课的交付物不是一组推荐值，是一张每一格都有人负责、每一格都写死了「不正常时怎么办」的表。

第 1 讲　三条总线不是档次高低，是三种不同性质的时间保证

拿到一份热管理域的信号清单，最省事的读法是按「重要的走 CAN、不重要的走 LIN、数据多的走 CAN-FD」把每一行分完。这一讲第一件事就是把这条捷径掐掉。三条总线的差别不是快慢排序，是它们各自能给出什么样的时间保证——CAN 给的是「优先级序下的有界时延」，LIN 给的是「排好的确定性时隙」，CAN-FD 只加宽了数据场、仲裁那一层一个字没改。这三种保证互相不能替代：一路要求「越限之后必须在有界时间内被对方看到」的信号，挂到一条更快但优先级排在后面的通道上并不会变好；一路只需要每秒刷新一次的状态量，挂到 CAN 上也不会因为总线更快而变得更值钱。判错这一步，后面整份通信矩阵的周期、超时、优先级与负载核算全部建在错的地基上，而且不会有任何一道测试报错——因为每一路信号都「通了」。

本讲交付五件：① 三条总线各给什么性质的时间保证，以及本课射程之外那几类承载去哪里找；② CAN 的帧结构与逐位仲裁，以及由它推出的一条硬结论——低优先级报文的时延不是它自己能定的；③ LIN 的主从分工，以及它「确定的是时隙、不是刷新率」这一层含义；④ 物理层三件事（波特率／采样点／终端电阻）为什么决定总线长度与节点数的上界；⑤ CAN-FD 的收益边界，以及给一路信号选承载的六问。本讲不交付：CAN 的错误检测与错误界定、bus-off 三态与恢复（第 2 讲）；LIN 的调度表怎么排、NAD 与自动寻址、UDS-over-LIN、从机状态字节与休眠唤醒（第 3 讲）；矩阵字段怎么写、周期按什么反选（第 4 讲）；失效语义与信号新鲜度（第 5 讲）；负载率与最坏时延怎么算（第 6 讲）；网关、Zonal 路径与拓扑（第 7 讲）。凡本讲写「见第 N 讲」的地方都是刻意的分工，不是漏讲。

1.1 先分清三条总线各给什么样的时间保证——选承载是在选保证的性质，不是在选速率

车上能把一路热管理信号送出去的承载，不止本课要讲的这三条。先把候选集摆全，再说本课取哪几条：CAN 2.0（高速 CAN 与低速容错 CAN）、CAN-FD、LIN、车载以太网（100/1000BASE-T1 及其上的 SOME/IP、DoIP）、点对点数字编码 SENT、PWM 占空比／频率信号、模拟电压与电阻分压信号、经 T-Box 的无线上行。⚠ 沿着「CAN → LIN」这条最熟的线索往下数，会整类漏掉两样：一是车载以太网——它是 Zonal 骨干，跨域的信号路径绕不开它；二是非总线的点对点数字编码——SENT 与 PWM 既无仲裁也无寻址，把「总线」的概念套上去会推出一堆并不存在的失效模式。

本课的射程就此划定：CAN／CAN-FD／LIN 三条讲透；车载以太网只讲它在骨干上的位置与它对热管理信号路径的影响（第 7 讲），协议机制不展开；SENT／PWM／模拟量的信号处理归 K1-01 热管理传感器信号处理与故障诊断，它们的电气规格归 G12-03 执行器硬件接口与电气规格，控制器侧的接口资源归 K2-01 热管理控制器（域控/ECU）硬件架构；无线上行的信号表与带宽预算归 K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算。⛔ 「不在本课射程」不等于「不存在」，更不等于「不许用」——本讲的六问（1.6）出口里专门留了一条「这不是总线」的旁路，就是为了不让它们被默认排除掉。

三条总线的分工，先用一张表钉死：

	CAN 2.0	CAN-FD	LIN
谁能起发	多主，任何节点在总线空闲时都可起发	同 CAN（仲裁语义不变）	单主多从，只有主节点能起发帧头
触发方式	事件驱动	事件驱动	时间触发，主节点按调度表点名
谁先谁后	按 ID 逐位仲裁，ID 数值小者优先	同 CAN	不仲裁，由调度表排定
给的是什么时间保证	优先级序下的有界时延：高优先级几乎立即，低优先级要排队	与 CAN 同一种保证，只是一帧能装的更多、数据段可提速	确定性时隙：什么时候发是排好的，抖动小
保证的代价	低优先级的排队时间由别人的到达过程决定	同 CAN；另加混跑总线上的转换与配置代价	调度表转一圈才轮到一次，刷新率受限
典型工作速率	常见 125 kbit/s／250 kbit/s／500 kbit/s 三档（典型）	仲裁段仍走标称速率；数据段典型 2~5 Mbit/s	20 kbit/s 量级（典型）

速率这一行必须带着口径读。经典 CAN 的速率上限去向 ISO 11898，LIN 的速率上限去向 ISO 17987——两者的版次与年份以现行目录为准，引用前须核；本课未取标准原文，只写去向。⛔ 表里的区间是行业典型值，端点不得被当成「能做到」的承诺：一条 500 kbit/s 的总线在实车拓扑与节点数下能不能稳定跑，要由本项目的物理层核算回答（1.4），不由这张表回答。

为什么「保证的性质」比「速率」更该先问。三种保证解决的是三个不同的问题：

• CAN 的保证是有序的、有条件的。它保证的是「优先级更高的先走」，而不是「每一条都快」。对一个高优先级 ID，时延几乎只由总线上当前正在传的那一帧决定；对一个低优先级 ID，时延由所有比它优先级高的报文的到达过程决定——它是被别人定的（1.2 展开，量化分解在第 6 讲）。
• LIN 的保证是排定的、无竞争的。同一时刻只有一个被点名的从机在说话，所以不需要仲裁，抖动也小。但代价写在刷新率上——一路信号多久出现一次，等于调度表转一圈的时间（1.3）。
• CAN-FD 只改带宽不改仲裁。它把数据场加长、允许数据段提速，但仲裁段的位数与速率一个都没变。所以它回答的是「一帧能装多少」，从来不回答「谁先发」（1.5）。

两个易错点，第二个更隐蔽：

① 把「选总线」做成「选速率」。看到一路信号「重要」就往更快的通道上挂，却没问它在那条通道上排第几。一条 500 kbit/s 总线上排在末位的 ID，未必比一条排在前列的 250 kbit/s 通道更快拿到手——决定它的是优先级序与总线上别人的到达过程，不是波特率那个数。 ② 把 LIN 的「确定性」读成「实时」。这两个词在工程口语里几乎混用，含义却不同：确定性说的是「什么时候发是可预知的」，实时说的是「多快能拿到」。LIN 确定的是时隙，不是刷新率。把一路要求有界时延的越限信号挂到 LIN 上，它的响应必须等主节点按调度表点到它——这条链上没有任何机制能让它插队。

1.2 CAN 的优先级写在 ID 里，仲裁是非破坏性的——所以低优先级报文的时延不是它自己能定的

先看一帧长什么样。经典 CAN 标准帧（11 位 ID）按发送先后逐段计数：

场	位数
SOF 帧起始	1
仲裁场（11 位 ID + RTR）	12
控制场（IDE + r0 + DLC）	6
数据场	8n
CRC 场（CRC 序列 15 + 分隔符 1）	16
ACK 场（槽 1 + 分隔符 1）	2
EOF 帧结束	7
小计（不含帧间隔）	44 + 8n
帧间隔 IFS	3
合计（含帧间隔）	47 + 8n

⚠ 这张表的来源级别要写清楚：逐段位数按通行工程口径列出，加和过程在表里可以自己复核；帧格式的权威定义去向 ISO 11898-1，版次以现行目录为准，本课未取标准原文，用于正式核算之前请自行核对一遍。⛔ 不要把这张表读成「标准规定」。

仲裁怎么发生。多个节点可以同时起发。从 SOF 之后的第一位开始，每个节点一边发一边回读总线：显性位（0）会把隐性位（1）压下去，所以只要有一个节点在某一位发显性，总线上就是显性。发隐性却读回显性的节点判定自己输了，立即退出并在下次总线空闲时重试；发显性的节点读回显性，继续往下发。由于 ID 排在帧的最前面，比较到某一位就分出胜负，ID 数值小者胜。

这个机制有两个必须分开记的性质：

• 非破坏性——输的一方是自己退出，不会把赢者这一帧撞坏，也不会触发重传。所以赢者的传输完全不受影响，总线带宽没有因为这次竞争而损失。
• 非抢占——赢者一旦开始发，这一帧就会发完，中途来了更高优先级的报文也只能等。所以任何一条报文，都可能被「当前正在传的那一帧」挡住，最坏是一整帧。

工程量级：把一帧的时间算出来。取 R_baud = 500 kbit/s，位时间 t_bit = 1/R_baud = 2 μs（这一式在 1.4 展开）。一帧 8 字节的标准帧，按含帧间隔的口径是 47 + 8×8 = 111 位；再加上最坏情况下的位填充（可填充区间为 34+8n 位，n=8 时最坏填充 24 位），得 111 + 24 = 135 位，对应 135 × 2 μs = 270 μs。本课全程用 2 μs 与 270 μs 这一对数作量级参照。

⚠ 这里有一处口径分歧，必须两个都记：上面的 47+8n 是「已含 3 位帧间隔」的口径；工程实务里也存在把 47+8n 当作不含帧间隔、末尾再加 3 位的用法，那样 n=8 时得到的是 138 位。两者差 3 位、约 2%，而这个差会原样搬进总线负载率。⛔ 本课不替你裁决哪一个对，只把两个都写出来并要求你做一件事：动手算之前，先确认你手上那份口径含不含帧间隔。完整的位数记账与两种口径的并列算例在第 6 讲。

⚠ 另一条一起带走：最坏位填充是用来留裕量的上界，⛔ 不得反过来拿它当实际占用去反算总线上真实传了多少位——实际填充位数取决于数据内容，它比最坏值小，且不可预先知道。

三个易错点：

① 以为优先级是「设出来的」。优先级不是矩阵里的一个独立字段，它就是 ID 的数值本身。改优先级等于改 ID，而 ID 一改，收发两端的解析、诊断脚本、网关路由表、已发布的通信矩阵版本全要跟着动。ID 分配为什么是「一次性花光的资源」，在第 4 讲。 ② 把非破坏性读成「不会有人受影响」。不受影响的是赢者。输的一方要等到下次总线空闲再来一次，而这中间可能又来了几条比它优先级高的——低优先级 ID 的排队时间，是由总线上别人的到达过程决定的，不由它自己的周期决定。 ③ 最贵的一个：以为「把周期设短就能让它快」。⛔ 这句话是错的。周期只决定这条报文多久被放进发送队列一次，完全不决定它放进队列之后要排多久——而排队那一段恰恰是最坏时延里最不可控的一项，且提高频率还会抬高总线负载、把别人的排队一起做差。这条错觉是本课最需要被扭过来的一条，第 4 讲给正面的规矩（周期由消费者反选），第 6 讲给量化的反证（事件触发与周期触发的时延量级差多少）。

1.3 LIN 是单主多从的时间触发：一帧被切成帧头与响应两半，谁发哪一半是写死的

是什么。一条 LIN 上只有一个主节点与若干从节点，单线、无仲裁。主节点内部同时含有一个「主任务」（负责按调度表发帧头）和一个「从任务」（它自己也可以填某些帧的响应）。一帧被切成两半：帧头（同步间隔 + 同步场 + PID）由主节点发，响应（数据字节 + 8 位校验和）由 PID 点到的那个从节点发。从机之间不会撞车，因为同一时刻只有一个被点名者有资格说话。

为什么这样设计。去掉仲裁场，就去掉了对位级同步与收发器一致性的大部分要求——LIN 因此可以做成单线、低成本，挂十几个小执行器也不贵。代价写在同一处：从机没有「我有急事」这句话的表达方式。它想说什么，只能等被点名。（LIN 侧确实有事件触发帧这一类，但那同样是主节点在调度表里开出来的时隙；帧类型与排表方法在第 3 讲。）

工程量级。LIN 的典型工作速率是 20 kbit/s 量级（典型；速率上限由 LIN 规范给出，去向 ISO 17987，版次以现行目录为准、引用前须核）。帧时间可以按 UART 的字节结构估：每字节含 1 位起始、8 位数据、1 位停止，约 10 位，于是

t_LIN,byte ≈ 10 / R_baud

这是可以逐位数出来的算术，不是转述来的标准限值。⚠ 但排调度表不能用标称值：LIN 规范给出了最坏帧时长与标称帧时长之比（含帧头在内），排表一律取最坏值——具体怎么排、时隙怎么分、主节点调度周期怎么定，是第 3 讲的内容；它与模式切换时序怎么对齐，见 C2-03 风门驱动电机与执行器（步进/有刷/PWM）选型。

三个易错点：

① 把 LIN 当成「慢一点的 CAN」。两者的差别不在速率而在机制：CAN 上任何节点都能在总线空闲时起发，LIN 上从机永远只能应答。这不是量的差别，是能不能表达「紧急」这件事的差别。 ② 把一路要求有界时延的信号挂到 LIN 上。典型形态是把某个执行器的越限告警接在 LIN 从机上，指望它「一超限就上报」——⛔ 它做不到，它只能等下一次被点名。要么把这一路挪到 CAN 上，要么接受「最坏一轮调度周期」这个时延并把它写进需求。 ③ 拿 LIN 的校验和去套 CAN 的 CRC 认知。两者位宽、算法与检错能力都不同，⛔ 不能互相类比着推断「够不够安全」。跨节点信号要不要另加 E2E 保护，是矩阵层的决定（第 5 讲，为什么要加见 K2-03 功能安全（ISO 26262）在热管理中的应用），与承载用的是哪一套帧内校验并不等价。

1.4 物理层三件事（波特率／采样点／终端电阻）定的是总线长度与节点数的上界，不是「接上就行」

是什么。位时间

t_bit = 1 / R_baud

是一切位级时序的尺子。一个位时间被切成若干时间份额（通行的分段是同步段、传播段与两个相位缓冲段），采样点落在其中某一处——收发器就在那一刻判定这一位是显性还是隐性。高速 CAN 是一条有特性阻抗的传输线，需要在总线两端各接一个终端电阻。

为什么这三件事互相锁死。位时间必须长到让电平沿着总线跑完全长、并被最远的那个节点认出来（传播时延与收发器的发送、接收延迟都要算进传播段）。所以波特率越高，允许的总线越短——这不是经验，是位时间被谁占满的问题。采样点则是一个两头受夹的位置：偏早会在信号还没稳定时采样（读到错值），偏晚会把重同步需要的余量挤掉（节点间时钟稍有偏差就跟丢）。终端电阻少接一个会反射，多接会把总线拉不到显性电平——两种错法的机理完全不同，但都表现为「偶发错误帧」。

工程量级，三个数各带各的口径：

• t_bit @ 500 kbit/s = 2 μs——由 t_bit = 1/R_baud 直接算得，是算术，不需要查任何标准。
• 采样点位置典型 75%~87.5% 一档——来源级别是行业协会与手册口径（CiA），⛔ 本课未取原文，⛔ 不得把它写成或读成标准限值；实际取值须按本项目的收发器、总线长度与节点数核定。
• 终端电阻工程通行取 120 Ω 一档、总线两端各一个——⛔ 不要写成「标准规定 120 Ω」；阻抗匹配与拓扑约束的权威定义去向 ISO 11898-2（物理层分册），版次以现行目录为准、引用前须核。

⛔ 本课不给「某波特率对应多长总线、能挂多少节点」的数。那两个上界由本项目的收发器延迟、拓扑形式、支线长度与节点数共同决定，须由本项目的物理层核算与实测给出——⛔ 也不许从上一代平台抄一组过来当结论。

三个易错点：

① 改波特率时只在工具里改一个数。波特率一动，位时间跟着变，采样点的绝对位置、允许的总线长度、支线长度上界全部跟着变。⛔ 改波特率不是改一个配置项，是重做一次物理层核算。 ② 台架上「能通」就当物理层没问题。台架常常只有两三个节点、线也短，终端电阻凑合接一个也能通；装到整车、线长起来、节点多起来，问题以「偶发错误帧」的形态出现，而它在总线上的表现与外部干扰、与线束接触不良几乎一样，很难往回追。 ③ 把物理层问题当成软件问题查。采样点偏、终端电阻缺失、接地偏移，这三样最终都表现为错误计数上升，而错误计数上升在软件侧看到的是「某某节点通信不稳」。⛔ 先量物理层再改软件——五类错误各在哪一步被检出、错误计数怎么增减，是第 2 讲。

1.5 CAN-FD 的收益随数据场长度增长，对短帧几乎没有

是什么。CAN-FD 在经典 CAN 之上做了两件事：数据场可以更长，以及——当 BRS（位速率切换）位置位时——数据段与 CRC 切换到更高的数据速率，而仲裁段仍走标称速率：

R_data(FD) > R_arbitration　（BRS 置位时生效）

仲裁段之所以不提速，是为了保住仲裁语义：逐位仲裁要求所有参与节点在同一位上同时回读总线，那一层的时序不能动。于是一帧跨了两个速率，帧时间必须分段相加：

t_frame(FD) = N_arb / R_arb + N_data / R_data

为什么收益随数据场长度增长。把上式拆开看：第一项 N_arb/R_arb 是一个与数据场长度无关的常数——位数没变、速率没变。数据场越短，这个常数项在一帧里的占比越大，第二项能省下的绝对时间越小。极端情形是 1 字节的信号帧：数据段本来就只占一帧里很小一段，把它提速几倍，整帧时间几乎不动。

工程量级。数据场从经典 CAN 的最多 8 字节扩到最多 64 字节（协议形制，去向 ISO 11898-1，版次以现行目录为准，须核）；数据段的典型速率见 1.1 的表。⛔ FD 帧的逐段位数本课一律不给（未取标准原文），本课只交付「分段相加」这一条算法。

三个易错点，第一个几乎每个项目都撞：

① 「上了 FD，负载率自然就降」。⛔ 不会。热管理域里大量信号是 1~2 字节的温度、转速与状态位，把原来的报文原样搬到 FD 上，帧数不变、仲裁段不变，省下的只是那一小段数据场的时间，负载几乎不降。 ② 以为「重新打包」是一个纯收益的动作。FD 真正的收益要靠重新打包才拿得到——把多路信号合并进一个长数据场，减少帧数，从而把那个加不掉的仲裁段常数项摊薄。但合并进同一帧的信号从此共用一个周期、共用一次发送时刻：原本各发各的一个快量与一个慢量，合帧之后只能取一个周期，慢的那个被迫提频（占更多带宽），或者快的那个被迫降频（新鲜度变差）。⇒ 重新打包是一次要重做整份矩阵的动作，它会改变各信号的周期与新鲜度，必须连着第 4 讲（周期怎么定）与第 5 讲（新鲜度怎么判）一起做，⛔ 不能当成一次「格式升级」。 ③ 把 FD 帧代进单一波特率去算负载。这是数学上就不成立的一步：代 R_data 相当于假设整帧都在高速传，严重低估帧时间与负载（错在危险侧）；代 R_arb 相当于假设整帧都在低速传，高估。混跑总线上 FD 帧与经典帧必须分开算再相加，算例在第 6 讲；网关在两侧之间怎么转换、转换配置漏了会怎样，在第 7 讲。

1.6 给一路信号选承载的六问：本课归纳的判据，不是「越高级越好」

前面五节各讲了一条总线的性质，这一节把它们收成一条可以当场走一遍的链。⚠ 先声明来源：下面这六问是本课归纳出来的判据，不是任何标准或既有规范里的现成条目；它的作用是让「为什么这一路选它」这件事在评审上说得出口，用之前请按本项目的电子电气架构规范再校一遍。

拿到一路待承载的信号，依次问六件事：

问	问什么	它定的是
①	要传多少信息？是不是双向？	够不够
②	有没有有界时延需求？谁拿它做安全或闭环判断？	够不够
③	要多快刷新？	够不够
④	对端节点的成本与数量是多少？	值不值
⑤	要不要在这条链路上做诊断与配置写入？	通不通
⑥	它在整车电子电气架构里跨不跨域？	通不通

前三问定「够不够」，后三问定「值不值、通不通」。顺序不是随手排的：② 必须排在 ③ 之前。「有界时延」与「刷新快」是两件不同的事——刷新快说的是平均多久来一个新值，有界时延说的是「最坏情况下多久之内一定能拿到」。先问刷新率，就会用一个「够快」的通道去顶一个它在原理上给不了保证的需求，而这个错误在台架上通常测不出来：平均表现完全正常，只在总线繁忙或调度表最不利的那一轮才暴露。

出口有四类，不是三类。三个候选承载 LIN／CAN／CAN-FD 之外，还必须留两条：

• 「这不是总线」的旁路——SENT、PWM 占空比／频率、模拟电压与电阻分压。它们是点对点的，既无仲裁也无寻址，⛔ 不参与这条链；把总线的概念套上去，会推出一堆并不存在的失效模式（比如去为它设计「优先级」或「总线负载」）。信号处理见 K1-01 热管理传感器信号处理与故障诊断，电气规格见 G12-03 执行器硬件接口与电气规格。
• 跨域骨干——车载以太网。当 ⑥ 的答案是「跨域」时，这一路信号大概率要经过骨干，本课只讲它在路径上的位置与它带来的转换次数（第 7 讲），协议细节不在射程内。

工程量级。⛔ 六问各自的门限一律不给数——「多少信息算多」「多快算有界」「多少个节点算多」全部是平台相关量，由本项目的电子电气架构规范与时序分析给出。本课在这一格上交付的是能当场判真假的六个问题，不是六个阈值。

两个易错点：

① 只按 ①③ 选，把 ② 跳过去。这是本节最想拦住的一种：只看「数据量不大、刷新也不用很快」，于是把一路越限告警挂上 LIN——而它要的是「一超限就在有界时间内被看到」，LIN 在原理上给不了这个保证，它只能等被点名。⚠ 判据是：只要这一路有人拿它做安全判断或闭环反馈，② 就必须被显式回答并写进记录，⛔ 不能默认「反正够快」。 ② 把这条判据与执行器接口选型混成一件事。G12-03 执行器硬件接口与电气规格 回答的是「这颗执行器配哪一种接口」，本课回答的是「这一路信号走哪一条承载」——两者射程不同，同一颗执行器上的不同信号完全可以走不同的承载（例如位置反馈走 LIN，而一个安全相关的使能位单独走 CAN）。⛔ 不要因为部件选了某种接口，就把它身上所有信号一律锁死在那条链路上。

1.7 本课的符号约定：三对易混的量必须分列，正文里禁止裸写

后面六讲会反复出现速率、位数与时间这三类量，而每一类里都有两三个只差下标、量纲却相同的成员。在这里一次性约定，全课统一沿用：

符号	含义	单位	射程与禁忌
R_baud	单一位速率（所有帧共用同一个速率时）	bit/s	用于所有帧共用同一个速率的场景——经典 CAN 的帧时间与负载率，以及 LIN 侧的 t_LIN,byte（1.3、第 3 讲 3.1、公式③）；⛔ 在 CAN-FD 语境里禁止裸写 R_baud
R_arb	CAN-FD 仲裁段速率（标称速率）	bit/s	与 R_data 成对出现，⛔ 不得单独代替 R_baud
R_data	CAN-FD 数据段速率（BRS 置位后）	bit/s	R_data > R_arb；⛔ 不得拿它算整帧
L_i	第 i 条报文的最坏总线占用位数	bit	用于负载率求和（第 6 讲）；含最坏位填充与帧间隔
N_arb ／ N_data	CAN-FD 一帧两段各自的位数	bit	与 L_i 同量纲、射程不同，⛔ 不得混用同一个符号
t_bit	一个位的时间	s	t_bit = 1/R_baud
t_LIN,byte	LIN 一个字节的时间	s	≈ 10/R_baud（UART 帧格式）
t_frame	一帧的时间	s	经典 CAN 为 L/R_baud；CAN-FD 须分段相加
age	信号年龄（当前时刻减去该信号最后一次成功更新的时刻）	s	第 5 讲；接收侧维护的量
timeout	该信号的超时门限	s	第 5 讲；矩阵里写死的门限，与 age 同量纲、含义不同
ρ_bus	总线负载率	无量纲	第 6 讲；分协议算再相加

三条硬约定，都是为了防同一类错：

• 速率：⛔ 凡出现 CAN-FD 的地方，速率必须带 arb 或 data 下标。裸写的 R_baud 一旦被代进 FD 帧，得到的不是「精度差一点」，是方向明确的低估或高估（1.5）。
• 位数：L_i 与 N_arb／N_data 都是 bit，但 L_i 是「一整帧最坏占多少位」、N 是「其中某一段占多少位」。⛔ 两者不得共用符号，也不得互相代入。
• 时间：t_bit、t_LIN,byte 与 t_frame 三个量都是秒，但尺度相差约三个数量级。⛔ 正文中禁止裸写不带下标的 t——丢一个下标，读者就可能拿位时间去当帧时间估调度周期。

本讲小结：四条要带走的判断——① 三条总线给的是三种不同性质的时间保证（优先级序下的有界时延／确定性时隙／带宽更大但仲裁不变），选承载首先是在选保证的性质；② CAN 的优先级就是 ID 数值，仲裁非破坏且非抢占，所以低优先级报文的时延由别人的到达过程决定，把周期设短并不能让它更快；③ 物理层三件事互相锁死，改一个波特率等于重做一次物理层核算，而总线长度与节点数的上界⛔ 由本项目核出来、不许抄上一代；④ CAN-FD 的仲裁段是加不掉的常数项，对短帧几乎没有收益，想拿到收益就得重新打包——而重新打包是一次要重做整份矩阵的动作。选承载的六问在 1.6，其中第二问「有没有有界时延需求」是最常被跳过、代价也最大的一问。