K4-01 · 控制、软件与标定 / 嵌入式软件与开发
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 能画出一台热管理域控软件的分层架构图，说清BSW/RTE/SWC各自的职责边界
- 能判断一个新功能该落在哪一层、该不该做成可复用SWC
- 能用利用率判据（Liu&Layland）对任务集做一次过筛，再用响应时间分析（RTA）校核关键任务的最坏响应时间是否满足截止期
- 能识别 ISO 26262 的「免于干扰／元素共存」在软件架构里的具名落点（OS-Application、MPU 内存分区、Timing Protection、WdgM、IOC），避免功能安全需求被架构设计架空
- 能看懂AUTOSAR工具链产物（ARXML、Runnable）之间的对应关系
内容大纲
- 为什么要分层：从「一坨代码」到 AUTOSAR Classic 三层架构
- 早期ECU软件的痛点：驱动/算法/标定耦合在一起，换硬件要重写全部代码
- AUTOSAR Classic Platform 三层：应用层(SWC) / 运行时环境(RTE) / 基础软件(BSW)
- BSW再分MCAL/ECU抽象/服务层/复杂驱动，越往下越贴近芯片
- Adaptive AUTOSAR 面向大算力域控（以太网/POSIX），热管理域一般仍是Classic
- SWC 与 RTE：应用软件怎么写、哪些该做成可复用件
- SWC的端口(Port)与接口：Sender-Receiver / Client-Server两类通信模式
- Runnable：一个SWC里可被OS调度的最小执行单元，周期或事件触发
- RTE生成的意义：SWC间通信不直接调函数，靠RTE解耦，换平台不用改算法代码
- 内部行为(Internal Behavior)描述：数据依赖与执行顺序约束——RTE 生成器据此确定 runnable 的调用顺序，时序设计必须显式排 runnable 顺序，别指望 RTE 自动解决
- 软件产品线：同一套架构靠变型编码覆盖多车型/多硬件（前指K4-04）
- 架构决策的代价：过度抽象/过度复用带来的运行时开销与调试难度
- AUTOSAR OS 与任务调度：利用率初筛、RTA 校核与中断负载
- AUTOSAR OS基于OSEK：任务(Task)/中断(ISR)/资源(Resource)/事件(Event)
- 固定优先级抢占式调度，热管理任务周期常见量级（10ms级/100ms级）；周期选择除了满足 U=Σ(C_i/T_i) 的资源侧约束，还要满足所在闭环的采样—带宽约束——否则会出现「架构先定了周期、控制侧才发现环跑不快」的返工（延迟总账见K3-05，滤波截止频率按控制带宽反选见K1-01）
- Liu&Layland可调度性判据：CPU利用率上界是充分非必要条件，任务集设计要留裕量而非跑满；谐波任务集（周期两两整除）可到 U≤1，关键任务另用响应时间分析（RTA）校核
- 优先级反转与资源锁：热管理控制回路共享变量的保护方式
- 中断负载必须单列：CAN Rx、定时器等 ISR 的优先级高于所有 Task，其 CPU 占用与释放抖动不体现在按 Task 统计的 U 里，要单独计入执行时间与干扰项，否则利用率算得漂亮、关键任务照样超时
- 关键任务还须过响应时间分析（RTA）这一关：R_i = C_i + B_i + Σ_{j∈hp(i)} ⌈R_i/T_j⌉·C_j 迭代到不动点，判据 R_i ≤ D_i；B_i 是共享资源锁带来的阻塞，OSEK/AUTOSAR OS 的 Resource 机制本身就是立即优先级天花板协议（IPCP），把 B_i 限制为一次最长临界区且不会死锁——这正好把同节「优先级反转与资源锁」接上
- ISR（CAN Rx、定时器）的优先级高于所有 Task，其 CPU 占用与释放抖动必须单列进核算——只按 Task 统计的 U 里看不见这部分干扰，而诊断栈与通信栈恰恰是中断负载的大头
- 通信与诊断栈：COM/PDU Router、DCM/DEM/FiM 与它们的资源开销
- COM/PDU Router：信号打包进CAN/CAN-FD报文的路径
- DCM/DEM/FiM 诊断三件套：故障码产生(DEM)、UDS服务对外呈现(DCM)、功能抑制管理(FiM)——FiM 按 DEM 的事件状态去抑制上层功能与其它诊断的运行，是「使能条件」在架构层的落点，事件—FID 映射必须有人配；本课只讲架构里有这一层及其映射关系，使能窗口与抑制矩阵的设计衔接K5-01
- 通信/诊断/存储栈占用的CPU、RAM 与 Flash 开销，不是免费的
- 上下电与掉电保全：NM、EcuM/BswM 与 NvM 存储栈的协同
- NM网络管理：ECU休眠/唤醒与整车EEA的配合（前指K2-02）；热管理执行器在 run-on 期间仍要动作时，靠持续发出网络请求（Network Request）抑制总线休眠，动作收尾后再释放，否则总线先睡、执行器停在半路
- EcuM/BswM 是电源模式管理在 AUTOSAR 里的机制落点：EcuM 管 ECU 状态机 STARTUP/RUN/SHUTDOWN/SLEEP、唤醒源校验（wakeup validation）与 RUN 请求/休眠请求的表决，BswM 用模式规则（Mode Request/Arbitration）把整车电源模式映射成 BSW 与应用的可用性，NvM 的关机写入序列也由 EcuM 在 SHUTDOWN 阶段编排。本课只讲机制不讲判据：「该定义哪些模式、迁移条件与判据是什么」的语义侧见 K3-11，数据侧见 K4-06
- EcuM（ECU 状态管理）与 BswM（基础软件模式管理器）是电源模式管理在 AUTOSAR 里的机制落点：ECU 状态机 STARTUP/RUN/SHUTDOWN/SLEEP、唤醒源校验（wakeup validation）、RUN 请求与休眠请求的表决、模式规则（Mode Request/Arbitration）把整车电源模式映射成 BSW 与应用的可用性；NvM 的关机写入序列也由 EcuM 在 SHUTDOWN 阶段编排。本课只讲机制，该定义哪些模式、迁移条件是什么属语义侧，见 K3-11
- BSW 服务层还有 NvM/MemIf/Fee/Ea 这条存储栈，与 COM/PDU Router、DEM/DCM 并列：负责车端运行期自产数据（学习值、零点补偿、DTC 老化计数与冻结帧、累计量）的非易失保全；块类型选择、掉电写一致性、上电有效性校验与回退见 K4-06
- 存储栈 NvM/MemIf/Fee/Ea：BSW 服务层里与 COM、DCM/DEM 并列的第三条栈，负责车端运行期数据（学习值、诊断计数与老化状态、累计量）的非易失保全与掉电写一致性；数据侧怎么分块、怎么校验、怎么在换件与升级后迁移，见 K4-06
- 免于干扰与 ASIL 共存：OS-Application、MPU、Timing Protection、WdgM 与 IOC
- 免于干扰（freedom from interference）与元素共存：ISO 26262-6/-9 的标准术语，业内俗称「ASIL 隔离」——不同安全等级的SWC如何在同一ECU上共存而不互相污染（判据侧呼应K2-03，本课讲落地机制）
- 具名机制：空间上靠 OS-Application 划分 + MPU 内存分区，时间上靠 AUTOSAR OS 的 Timing Protection（执行预算、到达率/锁定时间监控）与 WdgM 程序流监控，防止低ASIL任务拖垮高ASIL任务
- 跨 OS-Application 的数据交换由 RTE 按分区映射生成 IOC（Inter-OS-Application Communicator）调用——RTE 是把受保护路径实例化的生成层，保护语义由 OS-Application 与 MPU 提供，RTE 本身不是保护边界
- RTE 本身不是保护边界：SWC 同分区时 RTE 生成的可能就是同一块内存的直接读写，跨 OS-Application 时才按配置生成 IOC（Inter-OS-Application Communicator）或可信函数调用路径——RTE 是把受保护路径实例化的那一层，保护语义由 OS-Application/MPU/Timing Protection 提供；跨分区数据是否再叠加 E2E 保护，按相关失效分析（DFA）结论决定，不是强制项
- 别把 RTE 当保护边界：RTE 只是通信代码的生成层——SWC 同分区时它生成的可能就是同一块内存的直接读写，跨分区时才按配置生成 IOC 或可信函数调用；保护语义由 OS-Application/MPU/Timing Protection 提供，RTE 负责把这条受保护路径实例化。跨分区数据是否再叠加 E2E 保护，按相关失效分析（DFA）结论定：E2E 主要面向 ECU 间网络通信，ECU 内跨分区是可选加固而非强制项
关键公式
U = Σ(C_i / T_i)
任务集CPU利用率：每个任务最坏执行时间C_i除以周期T_i后求和，架构设计阶段用来核算调度裕量
U_lub = n·(2^(1/n) − 1)，n→∞时 → ln2 ≈ 0.693
Liu&Layland固定优先级可调度性的充分非必要条件（速率单调调度）：任务数越多，可调度利用率上界越降至约69%；但谐波任务集（周期两两整除，如10ms/100ms/1s）在RM下 U≤1 即可调度，热管理任务集通常正属此类，别把69%当成硬性红线照搬
R_i = C_i + B_i + Σ(j∈hp(i)) ⌈R_i / T_j⌉ · C_j，判据 R_i ≤ D_i
响应时间分析（RTA）的不动点迭代：本任务执行时间 C_i、阻塞时间 B_i、加上所有更高优先级任务在 R_i 窗口内的抢占；迭代收敛后与截止期 D_i 比较。B_i 来自共享资源锁，OSEK/AUTOSAR OS 的 Resource 用立即优先级天花板协议把它限制为一次最长临界区。利用率判据只做初筛，安全相关任务必须走这一层
ASIL(A) 与 ASIL(B) 共存 ⇒ 需空间/时间免于干扰
不同安全等级软件在同一ECU共存时的免于干扰约束：空间靠 OS-Application ＋ MPU，时间靠 Timing Protection ＋ WdgM，跨分区数据走 IOC；表达设计约束而非数值公式
关键概念
BSWRTESWCRunnableOSEK任务调度ASIL隔离变型编码NM网络管理DEM/DCMARXML可调度性免于干扰（freedom from interference）OS-Application/MPU分区/Timing Protection/WdgM/IOCRTA 响应时间分析NvM/MemIf/Fee/Ea 存储栈EcuM/BswM 模式管理
推荐工具与标准
dSPACE SystemDesk / EB tresos（AUTOSAR配置工具） Vector DaVinci Developer Simulink/TargetLink（应用层建模，衔接K4-02） Lauterbach/Trace32（运行时调试与任务时序分析） Vector TA Tool Suite / Gliwa T1（AUTOSAR 时序分析与响应时间核算，对应 AUTOSAR Timing Extensions/TIMEX）
AUTOSAR Classic Platform 规范（体系名） ISO 26262-6（软件层面功能安全要求） OSEK/VDX OS 规范 MISRA C:2012 ISO 26262-9（元素共存准则与相关失效分析 DFA）
工程案例
某车型热管理域控制器要同时支持压缩机PWM控制（普通软件）与电池冷却安全联锁（ASIL C）。架构评审时把安全相关SWC单独归入一个 OS-Application，用 MPU 划出独立内存分区（空间免于干扰），并配 AUTOSAR OS 的 Timing Protection 执行预算与 WdgM 程序流监控（时间免于干扰）；跨分区数据交换由 RTE 按分区映射生成 IOC 调用，是否再叠加 E2E 保护按相关失效分析（DFA）结论决定。注意 RTE 只是把受保护路径实例化的生成层，保护语义来自 OS-Application 与 MPU，RTE 本身不构成保护边界。
动手做
交付物 · 给定某域控功能清单（压缩机PWM控制/电池冷却安全联锁/CAN诊断）：① 画出BSW/RTE/SWC三层架构图并标出功能归属层；② 给出任务周期表并核算CPU利用率是否留有裕量；③ 标出免于干扰边界：哪些SWC归入哪个 OS-Application、MPU 分区怎么划、Timing Protection 的执行预算给多少、跨分区数据走哪条 IOC。交付架构图+任务表+隔离说明。
常见误区
- 把标定参数、状态机逻辑、硬件访问全揉进同一个SWC，换硬件平台时被迫重写整个算法
- 任务周期设计只看单个任务够不够快，不核算总CPU利用率，多任务叠加后CPU跑满导致偶发丢帧
- 高低ASIL功能共用同一任务/同一块RAM，没做真正隔离，安全等级形同虚设
- 迷信“AUTOSAR自带诊断”，DEM事件配置和实际DTC策略脱节，故障该报的没报
- 把RTE当普通函数调用理解，忽视其对通信时序的影响（延迟一个任务周期），调试时找不到数据为什么慢一拍
- 只按 Task 统计 CPU 利用率，漏掉 ISR（CAN 接收、定时器）——ISR 优先级高于所有任务，其占用与释放抖动不进 U，却实打实吃掉关键任务的响应时间余量，量产上表现为「算下来只有 60% 却偶发超时」
相关课题