4. 车规ECU软件架构与AUTOSAR基础

在RH850这类车规MCU上做HIL闭环验证，第一步不是接板子、跑脚本，而是先弄清被测ECU的软件“骨架”长什么样。AUTOSAR Classic Platform把ECU软件切成三层：最上面是应用层SWC（Software Component），中间是RTE（Runtime Environment），最下面是BSW（Basic Software）。RTE是唯一允许SWC与BSW通信的通道，SWC之间、SWC与BSW之间都不允许直接调用。理解这条“只能走RTE”的约束，是后续判断HIL激励该从哪个接口注入、观测点该挂在哪一层的前提。

三层结构：SWC、RTE、BSW各管什么

SWC是功能逻辑的载体，比如发动机扭矩控制、电机温度监控，它只描述“输入什么、输出什么、内部怎么算”，不关心数据从CAN来还是从ADC来。RTE负责把SWC的端口（Port）与底层信号绑定，并生成Runnable实体，决定谁在什么事件下被调用。BSW则提供通信（CanIf、Com）、诊断（Dcm、Dem）、存储（NvM）、IO硬件抽象（IoHwAb）以及最底层的MCAL（Microcontroller Abstraction Layer）。MCAL直接操作RH850的寄存器：ADC、PWM、GPT、CAN、PORT、ICU等驱动都在这一层。

一个常见的误解是把MCAL当成“驱动库”随便调。实际上MCAL由EB tresos或DaVinci Configurator这类工具生成配置代码，配置项与RH850硬件强绑定。例如ADC通道的扫描顺序、GPT通道的预分频、CAN控制器的波特率与采样点，都在MCAL配置阶段固定，运行时只允许通过标准接口读写，不允许绕过MCAL直接改寄存器，否则HIL测试中会出现“软件读到的值与示波器测到的不一致”这类难排查问题。

MCAL配置：从硬件参数到生成代码

以RH850的ADC为例，HIL测试中常需要采集多路模拟量。MCAL配置阶段要确定：采样通道组（Group）、转换模式（单次/连续）、触发源（软件触发或GPT触发）、结果对齐方式。假设使用ADC0的AN0～AN3四通道，配置为连续扫描模式，由GPT0的周期中断触发，转换结果右对齐12位。生成的配置代码会初始化ADC0的扫描序列和中断使能。运行时通过Adc_ReadGroup()读取结果缓冲区，HIL上位机再通过CAN或XCP把数据取走。如果配置时把触发源误设为软件触发，而应用层又没调用Adc_StartGroupConversion()，HIL就会看到数据一直不更新——这类问题在分层结构里定位很快：先看MCAL配置，再看RTE是否把结果传给了SWC。

CAN配置同理。RH850的CAN-FD控制器需要配置波特率、采样点、FD数据段速率。例如仲裁段500 kbps、数据段2 Mbps，采样点均取80%。这些参数一旦与HIL板卡的CAN配置不一致，通信就会大量错误帧。MCAL生成的Can_Write()和Can_MainFunction_Write()是标准接口，HIL脚本通过CANoe或类似工具发送报文时，实际进入的是CanIf→Com→RTE这条路径，而不是直接写寄存器。

任务调度与中断管理

AUTOSAR OS在RH850上通常采用固定优先级抢占式调度。任务分为基本任务和扩展任务，基本任务只有运行、就绪、挂起三态，扩展任务多一个等待态。调度表（Schedule Table）用于周期性激活任务，比如1 ms任务处理快速控制，10 ms任务处理通信与诊断，100 ms任务处理慢速监控。RH850的INTC支持多级中断，MCAL的ICU驱动把硬件中断映射为AUTOSAR中断，再由OS的中断服务例程决定是否激活对应任务。

HIL测试中一个典型场景是验证任务时序。假设1 ms任务里执行ADC读取、扭矩计算和PWM更新，如果计算量过大导致任务执行超过1 ms，下一次触发就会延迟，表现为PWM占空比更新抖动。用HIL的示波器或逻辑分析仪抓PWM引脚，同时用XCP读任务执行时间，就能判断是任务超时还是中断被长时间屏蔽。RH850的中断优先级配置很关键：如果CAN接收中断优先级低于GPT中断，且GPT中断服务程序执行过长，CAN报文就可能丢失。MCAL配置中每个中断的优先级和抢占属性都要与OS配置一致，否则会出现“配置看起来对、运行起来丢帧”的现象。

落地检查清单

把上述分层关系、MCAL配置要点和调度中断机制串起来，HIL闭环验证就有了明确的“抓手”：激励从哪进、信号经过哪几层、观测点挂在哪、异常时先查哪一层。RH850的硬件资源与AUTOSAR标准接口之间的映射关系，正是后续编写测试用例和排障脚本的基础。