4. 车规软件架构与RH850集成约束
在RH850车规ECU项目里，集成测试的难度往往不来自单个函数写得对不对，而来自软件架构本身的分层、映射与多核部署方式。AUTOSAR Classic Platform（CP）与Adaptive Platform（AP）是两套不同的组织逻辑：CP以静态配置、RTE为中心、SWC通过端口和接口通信，适合硬实时、深嵌入式控制；AP以动态调度、POSIX进程、服务化通信为主，适合高算力域控与SOA场景。RH850通常承载CP侧MCAL与BSW，也可能作为AP的MCU侧协处理器或安全岛。集成测试必须先把“谁在哪个核、通过什么接口、受哪个OS约束”看清楚，否则测试用例会落在错误的抽象层上。
从下往上看，MCAL直接操作RH850外设寄存器，包括ADC、PWM、GPT、CAN、LIN、SPI、ICU等。MCAL配置由工具生成，集成测试要验证的是配置参数与硬件行为是否一致，例如ADC通道采样时间、CAN波特率与采样点、PWM死区时间、ICU边沿捕获极性。BSW位于MCAL之上，包含通信栈（CanIf、CanTp、PduR、Com）、诊断栈（Dcm、Dem、FiM）、存储栈（NvM、Fee、Fls）、模式管理（EcuM、BswM、ComM）以及OS。RTE是SWC与BSW之间的胶水层，负责端口连接、数据映射和运行实体调度。SWC映射则决定每个SWC实例落在哪个核、哪个分区、以什么周期或事件触发。
RH850的多核分区是集成约束的核心。以RH850/U2A或RH850/F1K为例，常见做法是把实时控制SWC放在CPU0，通信与诊断放在CPU1，安全监控放在锁步核或独立核。OS配置需要明确每个核上的Task、ISR、Alarm、ScheduleTable、Spinlock和IOC。跨核通信不能直接读写共享变量，必须通过IOC（Inter-OS Application Communication）或共享内存加自旋锁。集成测试要重点检查：跨核数据是否在预期周期内到达、Spinlock是否造成优先级反转、IOC缓冲区是否溢出、核间启动顺序是否满足EcuM状态机。
下面这张图把RH850 CP侧集成测试中最容易混淆的“分层—映射—多核—观测点”关系压缩成一张结构图。图中左侧是CP分层，右侧是RH850多核分区，中间用箭头标出SWC到核、RTE到BSW、MCAL到外设的映射路径，底部列出集成测试在各层应观察的对象。
把这张图落到集成测试用例设计上，可以按“层—核—接口”三个维度拆解。第一层是MCAL与硬件：用示波器或调试器观察ADC采样触发到转换完成的延迟，确认是否满足配置的采样时间；用CAN分析仪检查报文周期与DLC，确认CanIf与CanDrv的配置一致。第二层是BSW与RTE：通过Dcm发送诊断服务，观察响应时间与NRC；通过RTE端口回调或调试变量，确认SWC收到的数据与Com发送的PDU一致。第三层是SWC与多核：在CPU0和CPU1分别设置断点或GPIO翻转，测量跨核IOC的端到端延迟，判断是否超过Task周期。
OS配置对集成测试的影响非常直接。如果两个SWC被映射到不同核，却通过RTE的Sender-Receiver接口通信，RTE会生成IOC调用；如果映射到同一核，则可能退化为直接函数调用。测试时必须确认生成的RTE代码路径与预期一致，否则会出现“单核测试通过、多核集成失败”的典型问题。另外，Spinlock保护共享资源时，若临界区过长，会导致高优先级Task被阻塞，表现为控制周期抖动。集成测试应记录最坏情况下的Task响应时间，并与OS配置中的ExecutionBudget对比。
下面给出一个可参考的集成测试检查表，用于RH850 CP侧多核项目。表中字段直接对应架构对象与观测手段，不引入无关管理字段。
| 架构层 | 检查对象 | 观测手段 | 通过判据（示例） |
|---|---|---|---|
| MCAL | ADC通道采样时间 | 调试器读寄存器 + 示波器 | 转换完成中断在配置窗口内触发 |
| MCAL | CAN波特率与采样点 | CAN分析仪 | 500kbps下采样点75%，无错误帧 |
| BSW | Dcm诊断响应 | 诊断仪发送0x22/0x2E | 响应时间<50ms，NRC符合预期 |
| BSW | Com发送周期 | CAN分析仪统计 | 周期抖动<±10% |
| RTE | 端口数据映射 | 调试变量 + 断点 | SWC接收值与Com发送PDU一致 |
| 多核 | IOC跨核延迟 | GPIO翻转 + 示波器 | 端到端延迟<1个Task周期 |
| OS | Task最坏响应时间 | Trace工具或GPIO | 不超过ExecutionBudget的80% |
对于Adaptive Platform与RH850混合的架构，集成测试还要额外关注AP与CP之间的边界。常见做法是RH850运行CP负责实时控制与安全监控，AP运行在另一颗高算力SoC上，两者通过SOME/IP或DDS通信。此时集成测试的重点从“核内RTE”转移到“跨平台服务接口”：服务发现是否成功、序列化格式是否一致、端到端延迟是否满足功能安全要求。若RH850作为AP的MCU侧代理，还需验证AP进程与CP SWC之间的数据同步机制，例如通过共享内存或SPI网关。
最后，集成测试的入口条件必须与架构配置冻结绑定。MCAL配置、OS配置、RTE生成代码、SWC映射表这四类文件一旦变更，就必须重新评估受影响的测试用例。建议在测试用例中记录其依赖的配置版本号，例如“MCAL_ADC_v1.3 / OS_CPU0_v2.1 / RTE_v1.7”，这样当配置更新时能快速定位回归范围。对于多核项目，还要额外记录核间通信矩阵，明确每个IOC通道的发送核、接收核、数据长度和刷新周期，避免测试遗漏。
总结来说，RH850车规ECU的集成测试不是简单的“跑用例”，而是先读懂架构：CP分层决定了观测点在哪，MCAL/BSW/RTE/SWC的映射决定了数据怎么流，多核分区和OS配置决定了时序怎么约束。把这三件事在测试设计阶段就对齐，才能让集成测试真正覆盖车规软件的实际风险。