K4-01 热管理嵌入式软件架构与 AUTOSAR 基础

课程代码 K4-01 · 板块 K 控制、软件与标定 / 嵌入式软件与开发 时长 约 4.0 小时（8 讲） 前置 K2-01 热管理控制器（域控/ECU）硬件架构；体系外前置（需自备）：嵌入式C与实时操作系统基础常识 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 K4-01 大纲的完整展开版

---

引言：架构图上有那个框，不等于车上那件事成立

一台热管理域控制器上，同时跑着几类性质完全不同的东西：按固定节拍刷新的执行器输出（压缩机 PWM、水泵与阀的开度）、慢得多的水温闭环、随时可能插进来的 CAN 接收中断、平时不出声一出事就必须立刻断开的安全联锁，以及一整套对着诊断仪应答的服务。它们共用一颗 MCU、一片 Flash、一块 RAM 和一条总线。这些东西怎么摆、谁先谁后、谁能碰谁的数据、谁在什么时候被允许多花一点时间——这就是本课要讲的软件架构。

AUTOSAR Classic Platform 是这套摆法在行业里的共同语言：把驱动、通信、操作系统这些共性下沉成基础软件（BSW），把业务逻辑收进可复用的软件组件（SWC），中间用一层生成出来的运行时环境（RTE）把两边解耦。这套分层不是审美，它要买的东西非常具体——换一颗芯片、换一版硬件、换一个车型的时候，有多少代码必须跟着动。

但一门架构课如果只讲到「有这么三层」，它就白讲了。真正难的地方在于：这些框都很容易画出来，而画出来之后，它们成不成立是另一回事。本课全程要敲的，是合起来的一句话——

AUTOSAR 给的是「机制」，不是「保证」。架构图上有那个框，不等于车上那件事成立。

它拆成两根钉子，八讲都在往这两根钉子上敲。

钉子 1：分层的判据是「它随什么变」，不是「它看起来像什么」

把一个功能放进哪一层，靠直觉是判不了的——「它看起来像驱动还是像应用」这个问法，几乎每次都能给出一个听上去合理、过两年就要还债的答案。唯一站得住的问法只有一个：这段逻辑会随着什么东西的改变而必须跟着改？

随芯片变，它就属于 MCAL；随本 ECU 的接线与外围器件变，属于 ECU 抽象层；随整车功能配置变，属于 BSW 服务层的配置；随控制算法变，属于 SWC；随车型或配置变而算法本身不变，那就该在 SWC 里参数化出去，交给变型编码处理。

由此得到一个本课全程都要用的动作：看到任何一段新逻辑，先问「它随什么变」，再问「我要放的这一层是不是恰好也随这个变」。两者对不上，就是把变化关错了笼子。代价不是难看——是下一次换芯片、换车型、换 Tier1 时，被迫重写本来一个字都不该动的代码。第 1 讲会把这条判据展开成一张九问核对表，动手做的第一问就用它。

⚠ 顺带提醒一句，免得矫枉过正：分层本身不是目的，分错了层的分层比不分层更贵——多了一层胶水，而变化的传播半径一点没缩小。判据始终是「它随什么变」，不是「层数够不够多」。

钉子 2：每个机制背后都挂着一个必须由人填的空格

第二根钉子是第一根的验收版，也是本课后半程的主线：本课列出的每一条机制，背后都挂着一个必须由人填的配置量，或一笔必须由人算的账；没人填、没人算，这个机制在架构图上存在，在车上不成立。

每一条都能举出它自己的那个空格：OS 的 Resource 能把阻塞限成一次最长临界区——前提是这段共享访问真的用了 Resource，而不是自己写了个标志位；Timing Protection 能拦住超预算的任务——前提是有人给出了那个执行预算的数；FiM 能抑制不该跑的功能——前提是有人配了事件到 FID 的映射；网络管理能让整车按时睡下去——前提是有人在 run-on 期间持续发出网络请求、并在动作收尾后释放；OS-Application 加 MPU 能隔开两个安全等级——前提是链接脚本真的把那些段放进了受保护区域；利用率判据能说明 CPU 够用——前提是中断、OS 开销与 RTE 生成代码的开销都被记进了账。

⇒ 本课的验收动作因此非常具体：指着架构图上任何一个框，说得出「它的那个空格是谁在什么时候填的、填的依据是什么」。说不出来，这个框就只是一张图。

反钉子：本课最容易被读反的那一句

下面这句话，在架构评审上几乎每次都会有人说，而且说得很有底气：

⛔ 「CPU 利用率算出来才 0.67，还有三成裕量，所以任务不会超时；要是紧张，把周期拉长一点，利用率就降下来了。」

它的每一半单独看都像常识——利用率确实是资源账，拉长周期确实降利用率。错的是它把一个全局的、与截止期无关的资源指标，当成了每个任务各自的时间承诺。看一眼利用率的定义式就清楚了：截止期 D_i 根本不出现在里面。利用率看不见某个任务的截止期是多少，也看不见谁抢占谁、谁被谁锁住、中断什么时候插进来。它是资源账，回答「这颗 CPU 的总时间够不够分」；时间账要另算，回答「这一个任务来不来得及」——那是响应时间分析（RTA）的活。两个账是不同维度的，谁也不能替谁作保。

读反之后会做错的动作有三个方向，本课都会走到底：

• 方向 A（拿低利用率当通行证）：算出利用率偏低就宣布调度没问题，不做逐任务校核。第 5 讲的教学算例把这个动作走完：一个利用率 0.67 的任务集，其中截止期最短的那个安全相关任务，最坏响应时间是 30.0 ms，而它的截止期是 20 ms ⇒ 它超时，而利用率这个数从头到尾没有任何异常。量产上的表现就是「算下来只有六成却偶发超时」。
• 方向 B（最危险：拉长周期去「优化」利用率）：发现紧张就把慢任务的周期加倍，利用率掉下来了，报表好看了；而那个任务的截止期一点没变，它的最坏响应时间也一点没变，仍是 30.0 ms——因为响应时间只由本任务的执行时间、阻塞时间与更高优先级任务决定，拉长自己的周期对自己的响应时间毫无影响。⇒ 这个动作只改善了指标、没有改善任何东西，还顺带把采样率做坏了（周期同时是这条闭环的采样间隔，见 K1-01 热管理传感器信号处理与故障诊断 的截止频率反选与 K3-05 PID/前馈/增益调度控制实战 的延迟总账）。⛔ 这是本课点名禁止的动作。
• 方向 C（反过来把 0.693 当红线，成本方向做反）：把利用率上界在任务数趋于无穷时的极限 ln2 ≈ 0.693 读成「CPU 只许用到七成」，于是明明可调度的任务集被判不合格，去加芯片、砍功能、拆 ECU。而这个上界是充分非必要条件：低于它一定可调度，高于它并不表示不可调度。判「不可调度」的依据只能是 RTA 算出的响应时间超过截止期，⛔ 不能是「利用率超过了 0.693」。

★ 第 5 讲还会把一件反直觉的事摆在台面上：那个算例真正有效的修法（把安全联锁拆成一个带截止期的判定任务加一个慢逻辑任务），让四个任务的响应时间全部满足各自截止期，而利用率从 0.67 升到了 0.85。把系统改对的那个动作，让「利用率」这个指标变差了。⛔ 所以不要把利用率当成要优化的目标函数。（⚠ 上述算例的全部数值为教学设定，⛔ 不对应任何平台，⛔ 禁止照抄取用。）

本课由此归纳出一条硬口径（⛔ 这是本课归纳的，不是标准条文）：利用率判据只做初筛，且初筛的结论只有一个方向可用——「过不了初筛 ⇒ 一定要改」；「过了初筛」不构成任何关于单个任务的承诺。安全相关任务、以及任何截止期短于周期的任务，必须逐个走 RTA。

另有两句同型的错话，本课分别在第 4 讲与第 8 讲显式点破，这里先立个牌子：一句把被控热过程慢推成「热管理 ECU 的软件实时性要求低」，另一句把RTE 当成跨分区的那道保护边界。两句都会在对应的讲里连同它们导致的具体错误动作一起拆开，⛔ 在别处不以正面表述出现。

本课管什么、不管什么

本课交付四样具体东西，⛔ 不是「讲一遍 AUTOSAR」：一套分层与归属的判据（钉子 1）；一份任务周期表与两笔账（资源账与时间账）；一个可隔离的分区方案；一张机制清单，每条机制后面写着它那个空格由谁填。

有几条边界要在开讲前说死。安全定级不在本课——本课讲的是隔离机制怎么落地，定级依据与方法去向 K2-03 功能安全（ISO 26262）在热管理中的应用；芯片、外设与 MPU 保护区域的预算去向 K2-01 热管理控制器（域控/ECU）硬件架构；整车网络、报文周期与信号分配去向 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成；DTC 策略与 UDS 服务设计去向 K5-01 OBD/UDS 诊断与故障码（DTC）设计；非易失数据怎么分块、怎么校验去向 K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化；run-on 时长与休眠期能耗预算去向 K3-11 热管理域的上下电时序、run-on 编排与休眠期能耗预算；版本、配置与变体的管理办法去向 K4-04 软件版本、配置与变量管理。本课只负责把这些接口摆出来，并要求每一个都有人认领。

标准侧还有一条更要紧的纪律。本课涉及的几份文件（AUTOSAR Classic Platform 规范、OSEK/VDX OS 规范、ISO 26262 的第 6 部分与第 9 部分、MISRA C:2012）均未取到原文，因此本课只写术语归属与去向，不写条款内容：⛔ 不写子条款号、⛔ 不写标准给出的分类清单、⛔ 不写任何限值与论证格式；⚠ 版次与年份以现行目录为准，引用前须核。⇒ 后面凡是本课自己归纳出来的判据与全集（第 8 讲那张干扰路径表尤其要注意），正文都会当场标明它是本课归纳的、不是标准条文，⛔ 不得拿去当功能安全工作产品的论证模板。

前置方面，本课假定你已经知道这台 ECU 的硬件长什么样（K2-01 热管理控制器（域控/ECU）硬件架构），并具备嵌入式 C 与实时操作系统的基础常识；不假定你写过 AUTOSAR 配置。

八讲怎么排

第 1 讲建立分层判据：从「一坨代码」的真正代价（变化的传播半径）讲到三层与 BSW 的四分，以及横穿三层的复杂驱动，收在「一个新功能该落在哪一层」的九问核对。第 2 讲进到应用侧：端口与两类通信模式、Runnable 与它到任务的映射——那是应用侧与 OS 侧唯一的接缝，并解释「数据为什么慢一拍」。第 3 讲讲配置即制品：工具链产物之间谁产出谁消费，以及绑定时机为什么是架构决策而不是工具选项。

第 4 讲与第 5 讲是本课的重心，也是反钉子的战场：第 4 讲建调度模型与资源账（任务、中断、资源、事件；周期由什么定；利用率判据为什么是充分非必要条件），第 5 讲回答「资源账过了为什么还会超时」——优先级反转与 Resource 机制、CPU 的时间到底被哪几类东西吃掉、RTA 怎么迭代，最后用一个可以跟着手算的教学算例把三种修法摆在一起比。

第 6 讲是通信与诊断栈：信号怎么走上总线，诊断三件套各自的那个空格，以及这些栈的开销该记在谁头上。第 7 讲是上下电与掉电保全：整车什么时候可以一起睡、run-on 期间执行器还要动作时该怎么办、关机写入与关机时长怎么互相牵制。第 8 讲回到安全：免于干扰要论证哪几条干扰路径、每条路径对应哪个具名机制、保护语义到底落在哪一层，并用一个案例把两根钉子同时用一遍，再交给你去做那份架构设计实操。

第 1 讲　为什么要分层：从「一坨代码」到 AUTOSAR Classic 三层

这一讲不急着报模块名。先回答一个更前面的问题：分层到底买的是什么？这个问题不答清楚，后面所有关于「这段代码该放哪儿」的争论都会退化成审美之争——有人觉得放这儿顺眼，有人觉得放那儿顺眼，谁也说服不了谁。本讲要给的是一把可以当场用的尺子：这段逻辑会随着什么东西的改变而必须跟着改？把这一问问出来，分层就从风格问题变回了工程问题。本讲的四件事依次是：分层买的那样东西是什么（1.1）、三层各自的职责与 RTE 的特殊身份（1.2）、BSW 内部的四分与那条横穿三层的旁路（1.3、1.4）、以及把这把尺子做成可复核的九问核对表（1.5、1.6），最后用一个「过了所有工具检查却完全没分层」的误区收口（1.7）。

1.1 分层买的是「变化的传播半径」，⛔ 不是好看

是什么。在一份没有分层的 ECU 实现里，读一个温度、判一次阈值、写一次标定量，完全可能写在同一个函数里：上面几行是 ADC 寄存器地址与转换启动，中间几行是滤波系数与阈值比较，下面几行是随车型不同的补偿值。三样东西挨着写，读起来甚至挺顺——它们本来就是同一件事的三个步骤。问题不在读，在改。

为什么。软件架构真正要管的量只有一个：一次变化会波及多少代码。把它叫做变化的传播半径。耦合让这个半径等于整个工程——因为三样东西写在一起，任何一侧动了，另外两侧都要跟着被重新验证。于是「换硬件要重写全部代码」这句话不是夸张，是耦合的必然结果：

• 换一颗芯片：寄存器地址、外设初始化序列变了。可它们和控制逻辑写在同一个文件里，于是控制逻辑也进了这次改动的范围，也要重新验证一遍。
• 换一版硬件：接线变了，第 3 路 ADC 现在接的是另一个传感器，分压电阻也换了。同上。
• 换一个车型：标定量变了。标定量硬编码在控制逻辑中间，于是改一个数要动一次代码、走一次代码变更流程、再验一次控制逻辑。

三次变化，每一次都把本来一个字都不该动的东西拖下水。分层要买的，就是把这三次变化各自关进一个笼子里：换芯片时只有一个笼子被打开，另外两个连锁都不用碰。

工程量级。⛔ 本课不给「重写多少行」「回归多少人天」这类数——它们是平台相关量，取决于工程规模、代码风格、测试策略与团队分工，换一个项目就全变。本课给的是一条结构判据（本课归纳，不是既有的通行说法、也不是任何标准的条文）：数一数「换芯片」这一件事要碰到几个文件，其中有几个文件里写着控制逻辑；控制逻辑文件被碰到的数量，就是耦合的度量。这个数不需要工具，今天下午就能在自己的工程里数出来，而且它是可复核的——两个人分别去数，应该数出同一个数。

易错点。这条最容易被读成「所以要多分层」。⛔ 分层本身不是目的。分错了层的分层，比不分层更贵：你多了一层胶水要维护、多了一份配置要生成、多了一次接口变更要走流程，而变化的传播半径一点没缩小。判据从头到尾只有那一句——它随什么变？我要放的这一层，是不是恰好也随这个变？两者对不上，就是把变化关错了笼子。

图上那条变化传播条上的色块，表示的是「这次变化要重新验证哪些部分」的定性范围，⛔ 不是代码行数、不是工作量、也不是时间，所以图上不带任何刻度。中间那一态是本课特意补出来的一格（本课归纳），因为它是三态里唯一看不出来的那一个——它确实有 SWC、有 RTE、有 BSW 三条带，评审时投影上去与右栏长得一样；只有把「换芯片」代进去，才会发现三样东西还在同一条 SWC 带里，整条带都要重新验证。1.7 会把这一态单独拿出来讲。

1.2 三层的分工是一句话，而 RTE 是被生成出来的、不是被手写的

是什么。AUTOSAR Classic Platform 把一台 ECU 上的软件分成三层：

• SWC（应用层软件组件）：承载控制功能本身——状态机、控制律、判定逻辑。
• BSW（基础软件）：与具体功能无关的通用能力——通信、诊断、存储、模式与网络管理、监控、操作系统，以及往下贴到芯片的那几层。
• RTE（运行时环境）：夹在两者中间，按配置生成 SWC 之间、以及 SWC 与 BSW 之间的全部访问代码。

三层的分工可以用一句话记住：SWC 说「我要什么」，BSW 说「我能提供什么」，RTE 说「按这份配置，你要的那件事具体走哪条代码路径」。

为什么这一条重要。因为最后那一句里的「按这份配置」四个字，决定了本课后面所有关于「边界」的判断。RTE 不是有人一行行写出来的中间件，它是生成物：配置怎么写，它就生成什么。由此得到一条几乎所有误判的源头——它不会拒绝任何被配置出来的访问。它没有判断力，也不该有：它的职责是把你在配置里表达的意图实例化成可以编译的代码，而不是替你审查这个意图对不对。

换个说法：RTE 是一条被实例化的通道，⛔ 不是一道被执行的检查。这句话现在听起来还有点抽象，第 8 讲讲免于干扰时它会变得非常具体。

工程量级。⛔ 本课不给「RTE 会生成多少行代码」「它占多少 Flash」这类数——它们是平台相关量，随端口数量、数据类型、以及分区方案而变，须由本项目在目标端从实际编译产物读取。这里要记住的不是一个数，是一条归属关系：生成出来的代码确实要跑、确实要占空间，它必须记在某个人的账上。记在谁账上，第 2 讲与第 5 讲会讲清。

易错点。两个，方向不同：

1. 把 RTE 理解成一道「守门」的中间层——以为数据从 A 到 B 经过了 RTE，就等于经过了一次检查或一道保护。⛔ 它不守门。这是本课要点破的一句错话，第 8 讲会把后果讲透，那里的代价比这里想象的大得多。
2. 把三层当成「文件目录的分法」——以为分层就是把代码放进三个文件夹。它是职责与变化源的分法：同一个目录里完全可能既有 SWC 又有复杂驱动，而两份放在同一个目录里的代码，可以属于完全不同的层。反过来，把文件挪进正确的目录，也不会让一段耦合的代码变得不耦合（这正是 1.7 那个误区的形态）。

1.3 BSW 再分四块，而复杂驱动不是第四层，是横穿三层的旁路

是什么。BSW 内部再分：

• MCAL：直接操作芯片外设的那一层，随芯片变。
• ECU 抽象层：把「这颗芯片的第 3 路 ADC」翻译成「冷却液温度输入」，随本 ECU 的接线与外围器件变。
• 服务层：提供与具体功能无关的通用服务——通信、诊断、存储、模式与网络管理、监控、操作系统，随整车功能配置变。
• 复杂驱动（CDD）：为标准接口兜不住的需求开的旁路，允许直接访问硬件并向上暴露自定义接口。

前三块可以用「越往下越贴近芯片」这句话概括，而这句话只描述了前三块。第四块不在这条线索上：CDD 不是「更靠下的第四层」，它是竖着穿过三层的一条通道。

为什么它必须存在。热管理里 CDD 的典型用法是高频 PWM 输出、非标准的传感器接口、以及时序敏感到不能经过标准栈的访问——标准接口的抽象层次是为「大多数情况」定的，总有一些访问它兜不住。取消 CDD 不会让这些需求消失，只会逼人用更坏的方式实现它们。

但它同时是分层纪律的缺口。因为它可以合法地跳过 ECU 抽象层直达芯片，所以「换芯片只改 MCAL」这个承诺在它身上不成立——换芯片时，每一个 CDD 都要被单独审视一遍。

工程量级。⛔ 本课不给「CDD 该占多少比例」「几个算多」这类数——它取决于这台 ECU 接了什么外围器件、以及所选 BSW 供应商的标准栈覆盖到哪里。本课给的是一条判据（本课归纳）：每引入一个 CDD，架构评审上都要当场回答「换芯片时它要改哪些、谁负责改」。答不上来，就说明这条旁路没有人认领——它会在下一次换平台时以「怎么这里还有一块没人认识的代码」的形态出现。

易错点。两个方向都要防：

1. 把 CDD 当成「不守规矩」的东西而回避它：为了绕开它，把时序敏感的访问硬塞进标准栈，结果做出一个又慢又绕、还得靠一堆特殊配置维持的东西——比老老实实写一个 CDD 更坏。
2. 反过来把 CDD 当成万能出口：凡是配置麻烦的都走它。这样下去，分层会退化成一层——所有东西都直连硬件，只是每一段都自称是「复杂驱动」。

图上带的厚度、面积与前后顺序，⛔ 不代表代码量或开销——它画的是职责与变化源，不是文件目录结构，也不是调用关系图。右侧那行「它随什么变」的标注与图右那一列，都是本课补上去的（本课归纳）；下一节讲的就是那一列。

1.4 沿「三层」这条线索数，会整类漏掉四种东西

这里做一次全集清点：这台热管理 ECU 上「所有会跑的东西」。清点的线索不是「AUTOSAR 三层」，而是归属与谁维护——因为沿三层数，漏掉的那些会整类消失，看起来清单还是完整的。每一格都标出射程内／射程外：射程外不表示它不重要，只表示判据在别的课，本课只给去向。

① SWC（应用层软件组件）：射程内·主干。 ② RTE（生成的胶水层）：射程内·主干。 ③ BSW 服务层（通信／诊断／存储／模式／网络管理／监控／OS）：射程内，逐条见第 4 讲与第 6、7 讲。 ④ BSW ECU 抽象层：射程内——它随本 ECU 的接线与外围器件变。 ⑤ MCAL：射程内，但只到「它是随芯片变的那一层」；具体驱动配置与寄存器级内容射程外，去向 K2-01 热管理控制器（域控/ECU）硬件架构。 ⑥ 复杂驱动 CDD：射程内。★ 本课单列的一格（本课归纳）——它不在「越往下越贴近芯片」那条线索上，而是横穿三层的旁路。沿三层数，它会整格消失。 ⑦ 启动代码与 bootloader（含刷写引导）：射程外，去向 K4-04 软件版本、配置与变量管理（版本与刷写）与 K7-02 软件定义热管理与 OTA 迭代（OTA）。★ 本课单列它，是因为它不是 AUTOSAR BSW 的一部分，而它确实在这台 ECU 上跑、确实吃 Flash——不列出来，读者会以为「三层」就是全部。 ⑧ 不受 OS 管理的中断服务例程：射程内。★ 本课单列的一格，理由是它不进按任务统计的 CPU 利用率——第 4、5 讲的时间账里，这一格是最常缺席的那个。 ⑨ 标定数据与参数集（不是代码，但占 Flash、且随车型变）：射程内，只到「它占空间、随变型走」；标定量规格射程外去向 K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量，标定流程去向 K6-01 热管理标定流程与工具（INCA/CANape）。 ⑩ 非易失数据的运行期镜像：射程内，只到「服务层有这条栈」；分块、校验、掉电一致性射程外，去向 K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化。 ⑪ 供应商以二进制交付的件（协议栈、加密库等）：射程外，交付边界与联合验证去向 K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署。

沿单一线索会漏掉什么。只沿「SWC → RTE → BSW 三层」数，会整类漏掉 ⑥（横穿的 CDD）、⑦（不属于 AUTOSAR 却在同一片 Flash 上的启动与刷写代码）、⑧（不受 OS 管的中断服务例程）、⑨（不是代码但吃空间且随车型变的标定数据）。这四类漏掉的不是细节：⑧ 是「利用率算得漂亮却偶发超时」的直接来源（第 4、5 讲要用整整两讲处理它），⑥⑦⑨ 是资源账对不上的常见来源——map 文件里的占用比预期大一截，找了半天找不到，因为找的人只在三层里找。

★ 最后补一句边界（也是这张表的正确用法）：这张表列到十一格，是按「谁维护、随什么变」数出来的。如果你的平台上还有本表没有列到的东西，⛔ 不要因为它不在表上就当它不存在或不该有——把它加进你自己的那张表，并写明它随什么变、谁维护。没有被列进来的那一类，不会被任何验证覆盖，这正是清点全集要解决的问题。

1.5 Classic 与 Adaptive 的分界不是「旧与新」，是「确定性与灵活性」

是什么。AUTOSAR Classic 的对象——任务、中断、内存分区、通信路径——在编译与链接时就固定下来，运行期不新增。Adaptive 面向大算力域控（以太网、POSIX 类操作系统接口），支持应用在运行期加载与调度，代价是时间行为不再是静态可分析的。

为什么热管理域一般仍是 Classic。理由是需求形态，⛔ 不是「还没升级」：

• 热管理域控的功能集在整车生命周期里相对稳定——不需要频繁地上架下架应用。
• 它的核心诉求恰恰是可分析的时间行为。第 4、5 讲要算的两笔账（资源账与时间账）都以静态配置为前提：任务集是已知的、优先级是固定的、谁会抢占谁在编译期就能列全。一旦允许运行期动态部署，这两笔账的前提就没有了，算出来的数也就不再有它声称的含义。
• 成本。Classic 的运行环境对硬件的要求低得多。

反过来，需要跑大模型、需要频繁通过 OTA 更换算法的场景，才需要 Adaptive 的灵活性（去向 K7-02 软件定义热管理与 OTA 迭代）。

工程量级。⛔ 本课不给两者的性能对比数，也不给「什么算力以上该用 Adaptive」的门槛——这是平台相关量，而且本课未取到规范原文，任何这类门槛都须由本项目按自己的功能形态与生命周期确定。

易错点。

1. ⛔ 不许把它说成「Adaptive 更先进／是趋势，Classic 早晚要被替代」。这句话把一次需求驱动的选型说成了时代问题。它和「浮点比定点先进」是同一型的错（那一条见 K4-02 基于模型开发（MBD）：Simulink 建模与代码生成）：两个东西解决的是不同的问题，把它们排成先后，选型就没法做了——因为你已经预设了答案。
2. ★ 更实际的一个：以为 Classic 就没有动态性。它有——复杂驱动会带来标准栈之外的行为，运行期变体切换会改变执行路径，模式仲裁会改变哪些功能可用。区别不在于「有没有动态行为」，而在于 Classic 的可能状态在编译期是穷举得出来的：你能把所有可能的组合列全，因此也能对每一种组合去算那两笔账。Adaptive 拿掉的正是这个「列得全」。

1.6 一个新功能该落在哪一层：九问核对，第一问永远是「它随什么变」

是什么。「这个新功能该落在哪一层、该不该做成可复用件」这件事，是可以被判据化的，不必靠某个人的直觉。本课给出九问核对表（本课归纳，⛔ 不是既有的通行清单、也不是任何标准的条文）：

① 它随什么变？（芯片／本 ECU 硬件／整车网络配置／车型标定／控制算法）——主判据，射程内·主干。 ② 它的时间尺度与抖动要求（要不要独占一个高优先级任务、能不能容忍一个周期的延迟）：射程内。 ③ 它要不要访问硬件寄存器、要不要绕过标准接口（是 ⇒ 落 MCAL 或 CDD）：射程内。 ④ 标准 BSW 里是不是已经有了（⛔ 不要自己造第二个通信栈、第二套故障管理）：射程内。 ⑤ 它要不要跨车型复用（是 ⇒ 车型相关量必须参数化出去，⛔ 不许写死在里面）：射程内。 ⑥ 它的安全等级、要不要与别的等级隔开：射程内（机制侧，第 8 讲）；定级判据射程外 → K2-03 功能安全（ISO 26262）在热管理中的应用。 ⑦ 它要不要被诊断看见、要不要被标定看见（是 ⇒ 接口要在架构描述里显式暴露，不是事后加）：射程内。 ⑧ 它是不是黑盒交付：射程外 → K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署。 ⑨ 它属于哪个变体、绑定时机在编译前还是运行时：射程内（架构影响，第 3 讲）；管理办法射程外 → K4-04 软件版本、配置与变量管理。

为什么要做成一张表。因为分层决策做错的代价，要到下一次变更时才显现——而那时改动成本已经翻了几番，当初那个决定是谁做的、依据是什么，也没人说得清了。一张可复核的表，把判断从「某个人当时觉得」变成「当时是这么答的，你可以来看」。

★ 实践里抓到错最多的是第四问：标准 BSW 里是不是已经有了。自己造第二套信号打包、第二套故障计数，是「一坨代码」在 AUTOSAR 外壳下的复辟——形式上它是个规规矩矩的 SWC，实质上它把一件本该由配置决定的事重新写成了代码。

工程量级。⛔ 本课不给「几问答『是』就该做成可复用件」这种打分表——那会把判断降级成算术，而算术是可以被凑出来的。本课给的是每一问答错的具体后果，读者据后果决定。

易错点。

1. 只答第一问就下结论。第一问定的是层，第五问才定要不要做成可复用件——「它属于 SWC 层」与「它应该做成一个跨车型复用的件」是两件事，常被混为一谈。一个只服务本平台、接口每个车型都要改的功能，放在 SWC 层是对的，做成可复用件是错的。
2. 把第七问留到最后。功能做完了才发现这个量诊断读不到、标定改不了，于是回头改接口——而接口一改，前面的验证就得重来一遍。这类返工几乎全部来自「第七问问晚了」。

图上框的排列顺序表示提问顺序，⛔ 不表示重要性排序——它是判断顺序图，不是评分表也不是权重表。第八、第九两问在图上只给去向课号、不写内容，因为它们的判据在别的课。

1.7 误区：把标定参数、状态机逻辑与硬件访问全揉进同一个 SWC——它能过所有工具检查

现象。一个 SWC 里，既有寄存器级的访问（经复杂驱动或经硬件抽象绕出去），又有大段状态机，又硬编码着几十个随车型变的数。它有规规矩矩的端口、规规矩矩的接口描述，配置工具查下来一个错都没有。

为什么错。因为这三样东西的变化源完全不同——硬件访问随芯片与接线变，状态机随控制策略变，标定量随车型与整车匹配变。绑在一起意味着：任意一个变化源被触发时，都要重新验证全部三样。这正是 1.1 说的传播半径，只不过半径从「整个工程」缩小成了「这一个 SWC」——缩小了，但没有缩小到该有的程度。

★ 更隐蔽的一层，也是这条误区真正难对付的地方：它在架构图上看起来是分层的。它确实在 SWC 层，画出来与一份健康的架构图没有区别；配置工具也查不出问题，因为工具查的是「配置合不合法」，⛔ 不查「变化被关进了哪个笼子」。⇒ 分层的形式满足了，分层要买的东西一样没买到。这就是图 2 中间那一态——回头再看一眼那张图，它画的就是这件事：三条带都在，而三个变化源代进去，覆盖的仍然是整条 SWC 带。

正确做法。按 1.6 的九问拆，拆的对象是变化源，不是文件：

• 硬件访问下沉到 ECU 抽象层；标准接口兜不住的，走复杂驱动，并按 1.3 的判据当场认领「换芯片时它要改哪些、谁负责改」。
• 随车型变的量参数化成标定量，让它随变型走而不是随代码走（标定量的规格去向 K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量，标定流程去向 K6-01 热管理标定流程与工具（INCA/CANape））。
• 状态机留在 SWC 里——它本来就随控制策略变，放这儿是对的；它的模式定义与状态机完备性核对去向 K4-05 模式状态机的完备性核对与可验证性设计。

易错点。拆的时候只拆出接口、不拆出变化源：把硬件访问包了一层函数，函数仍然放在同一个 SWC 里，寄存器地址照旧写在这份代码里——换芯片时一样得改这份代码、一样得重新验证它旁边的状态机。⇒ 判断拆没拆成功，别看接口漂不漂亮，回到 1.1 那个可以数出来的判据上：换芯片这一件事，现在要碰到几个文件，其中有几个文件里写着控制逻辑？这个数没有变小，就是没拆成。

本讲小结：分层买的是变化的传播半径，判据只有一句——它随什么变。三层的分工是 SWC 说要什么、BSW 说能提供什么、RTE 说按这份配置走哪条路径，而 RTE 是生成出来的通道，不是一道检查（第 8 讲会兑现这句话的分量）。BSW 内部四分里，复杂驱动不是第四层而是横穿三层的旁路，它必须存在、也必须被认领。沿「三层」这条线索清点会整类漏掉四种东西，其中「不受 OS 管理的中断服务例程」这一格，第 4、5 讲还要专门回来收拾。Classic 与 Adaptive 的分界是确定性与灵活性，⛔ 不是旧与新。最后，把这把尺子做成九问核对表：第一问定层、第五问定复用，其余七问只产出约束——而一个能过所有工具检查、架构图上看起来分好了层的 SWC，可能一点变化都没有关进笼子。