4. 模型架构重构与接口标准化
快速控制原型（RCP）阶段的模型，目标通常是“尽快验证控制算法是否有效”。为了这个目标，工程师往往会把传感器采集、控制律、执行器驱动、标定量、甚至一些调试用的观测逻辑全部塞进同一个 Simulink 模型里，用全局变量、直接 I/O 读写和大量 From/Goto 模块把信号连来连去。这样的模型在台架上跑得通，但一旦要迁移到量产软件，就会暴露出三个致命问题：层次不清、接口不定、依赖不净。本节要做的，就是把 RCP 模型重构为可量产的分层架构，定义标准接口，并彻底消除非量产依赖。
一、先看清 RCP 模型与量产架构的差距
量产软件（尤其是 AUTOSAR 体系）对模型有明确的架构约束：应用层算法必须封装为软件组件（SWC），组件之间只能通过端口（Port）和接口（Interface）通信，数据类型必须来自统一的数据字典，任何对硬件寄存器、全局变量、调试通道的直接访问都不允许出现在应用层。而 RCP 模型恰恰相反——它默认“整个模型就是一块”，信号可以随意跨层引用。
因此重构的第一步不是改模型，而是建立目标架构的骨架。一个典型的分层结构自下而上分为：
- 硬件抽象层（HAL / BSW）：由底层驱动和 AUTOSAR 基础软件提供，负责 ADC、PWM、CAN 等硬件访问，对上层暴露标准化的 RTE 接口。
- 传感器处理层：把原始 ADC 码值转换为物理量（如电压→温度、计数→转速），并完成滤波、限幅、合理性检查。
- 应用控制层：真正承载控制算法的 SWC，例如扭矩控制、温度闭环、状态机，只处理物理量，不碰硬件。
- 执行器输出层：把控制量转换为驱动请求（占空比、电流设定值），再交给 HAL 输出。
- 标定与诊断层：标定量通过 RTE 端口读取，诊断事件通过标准接口上报，不直接写全局变量。
这五层之间的数据流是单向、明确的：传感器层→应用层→执行器层，标定和诊断作为旁路接口接入。下图给出了这一分层架构与接口关系，其中每个 SWC 都通过明确的端口类型与相邻层通信。
二、接口标准化的具体做法
分层只是骨架，真正决定迁移成败的是接口。在 AUTOSAR 语境下，接口标准化要落到三个层面：端口、数据类型、接口契约。
端口层面，每个 SWC 只允许通过 RPort（接收）和 PPort（发送）与外界交互。RCP 模型中常见的 From/Goto 全局跳转、Data Store Memory 跨层共享，都必须替换为显式的端口连接。例如，原来温度控制算法直接读取全局变量 TEMP_RAW，重构后应改为：传感器处理 SWC 通过 PPort 输出 TEMP_PHYS（float32，单位 ℃），温度控制 SWC 通过 RPort 接收该信号。这样，两个 SWC 之间只存在一条明确的接口，谁产生、谁消费一目了然。
数据类型层面，必须建立统一的数据字典。RCP 阶段经常出现同一个物理量在不同地方用不同精度表示的情况，比如转速在传感器层是 uint16 的 RPM 计数，在控制层却变成 double。迁移到量产时，应统一为：物理量用 float32，状态码用 uint16，布尔标志用 boolean，并明确每个信号的单位、取值范围和初始值。数据字典一旦确定，所有 SWC 的端口都从字典中引用类型，不允许在模型里临时定义。
接口契约层面，每个端口要写清楚：信号名称、数据类型、单位、有效范围、更新周期、无效值处理方式。例如 TEMP_PHYS 的契约可以定义为：float32，单位 ℃，范围 −40～150，周期 10 ms，无效值用 −100 表示。这些信息应作为接口文档的一部分，与模型同步维护。
三、消除非量产依赖
RCP 模型里有一批“方便但不可量产”的东西，必须在重构时清除。常见的有以下几类：
- 直接硬件访问：模型里直接读 ADC 寄存器、写 PWM 比较寄存器。应改为通过 HAL 提供的 RTE 接口访问。
- 全局变量与 Data Store Memory：跨层共享的全局变量应改为端口连接；如果确实需要全局状态，应封装为独立的 SWC，通过端口暴露。
- 调试与观测逻辑：Scope、To Workspace、Display 等模块只用于 RCP 阶段观测，量产代码中不应保留。应改为通过诊断端口按需上报，或直接删除。
- 非标准数学库与浮点依赖：某些 RCP 模型使用了主机端才有的数学函数或双精度浮点运算。量产目标机若为定点 MCU，需要替换为定点实现或查表法，并验证精度损失在可接受范围内。
- 采样时间不一致：RCP 模型常把不同采样率的模块混在一起而不加速率转换。量产时应明确每个 SWC 的周期任务，跨速率信号必须经过 Rate Transition 模块，避免数据竞争。
四、一个可执行的重构检查表示例
下面给出一份重构检查表，可用于每个 SWC 迁移前的自检。表中字段直接对应本节讲到的分层、接口和依赖三个维度。
| 检查项 | 合格标准 | 常见不合格表现 |
|---|---|---|
| 层次归属 | SWC 明确属于传感器/应用/执行器/标定诊断层之一 | 一个 SWC 里同时做 ADC 读取和控制运算 |
| 端口使用 | 所有输入输出均通过 RPort/PPort | 存在 From/Goto 跨层跳转或 Data Store Memory |
| 数据类型 | 所有端口类型来自数据字典 | 模型内临时定义 double 或未指定单位 |
| 硬件访问 | 应用层无任何寄存器或驱动直接调用 | 应用 SWC 内直接写 PWM 寄存器 |
| 调试模块 | 无 Scope / To Workspace / Display | 保留观测模块用于“以后调试” |
| 采样周期 | 每个 SWC 周期明确，跨速率有 Rate Transition | 不同周期信号直接相连 |
| 接口契约 | 每个端口有名称、类型、单位、范围、周期、无效值 | 端口只有名称，无单位和范围说明 |
五、重构后的验证方式
重构完成不等于迁移成功，还需要验证接口是否真正标准化。最直接的方法是做一次“接口替换测试”：把应用层 SWC 单独取出，用信号发生器模拟传感器层的输出，观察应用层是否能正常产生控制量；再把执行器层单独取出，用固定控制量输入，观察驱动请求是否符合预期。如果某个 SWC 脱离原模型就无法运行，说明它仍然隐式依赖了非接口的东西，需要继续解耦。
另一个有效手段是代码生成后的接口审查。用目标编译器生成 SWC 的 C 代码后，检查生成的 _step() 函数签名和 RTE 调用，确认没有出现全局变量直接引用、没有出现未在数据字典中定义的类型、没有出现硬件地址常量。这一步能把模型层面的“看起来干净”落实到代码层面的“确实干净”。
最后要强调的是，架构重构和接口标准化不是一次性的动作，而应成为 RCP 到量产迁移的固定环节。每新增一个控制功能，都按同样的分层和接口规则纳入模型，才能避免迁移后期出现“改一处、动全身”的被动局面。