3. 控制系统功能分解与架构设计

在完成功能清单梳理之后，下一步并不是立刻进入建模或写代码，而是把“功能清单”转化为“可分配、可验证、可追溯”的功能架构。功能分解与架构设计的核心任务，是把整车或系统级需求逐层拆解为控制、监控、诊断与安全四类功能，并明确它们之间的层级关系、接口关系与执行顺序。这一步做得好，后续的 MIL 验证才有明确的被测对象和判据；做得不好，模型再精确也只是在验证一个错误的结构。

一、功能分解的层级逻辑

功能分解通常采用“系统级—子系统级—组件级—功能项”四层结构。以电子驻车制动系统（EPB）为例，系统级功能是“实现车辆驻车与释放”；子系统级可拆为“卡钳夹紧控制”“释放控制”“坡道保持”“热保护”；组件级进一步落到“电机驱动”“电流采样”“开关采集”“CAN 通信”；功能项则是最小可验证单元，例如“电流闭环控制”“夹紧力估算”“开关防抖”。

分解时建议遵循三条原则：第一，单一职责，一个功能项只完成一个明确动作，避免“控制+诊断”混在同一功能项中；第二，接口显式，每个功能项必须写清输入信号、输出信号、触发条件和执行周期；第三，可验证，功能项应能对应到至少一条测试用例或一个观测变量。分解粒度并非越细越好，一般以“能在 MIL 环境中独立激励并观测输出”为下限。

二、控制、监控、诊断与安全功能的划分

四类功能的划分依据是“职责”而非“模块”。控制功能负责把期望状态转化为执行器指令，例如根据目标夹紧力计算电机目标电流；监控功能负责判断系统当前是否处于允许状态，例如监测电源电压、电机温度、开关状态是否满足夹紧条件；诊断功能负责识别故障并记录，例如电流采样开路、电机堵转、CAN 超时；安全功能负责在异常时把系统导向安全状态，例如夹紧失败时禁止释放、故障时点亮报警灯并限制再次夹紧。

划分时最容易出现的问题是“监控与诊断边界模糊”。一个实用的区分方法是：监控回答“现在能不能做”，诊断回答“为什么不能做”。例如电压低于 9V 时，监控功能输出“夹紧禁止”，诊断功能则记录“电源欠压故障码”。两者可以共享同一路 ADC 采样，但输出对象不同：监控输出使能条件，诊断输出故障状态。

三、功能架构图的建立方法

功能架构图不是模块框图，它表达的是“功能之间的数据流、使能关系与优先级”。建立时按以下顺序推进：先画控制链，再叠加监控与诊断，最后插入安全路径。控制链体现从驾驶员输入到执行器输出的主通路；监控与诊断以旁路形式挂在控制链的关键节点上；安全路径则表现为对控制链的覆盖或切断。

下图给出 EPB 夹紧过程的功能架构示例。图中实线表示控制数据流，虚线表示监控/诊断信号，粗线表示安全覆盖路径。可以看到，安全功能并不直接参与正常控制，而是在监控判定异常时接管使能信号，使控制链无法继续输出。

四、接口定义与执行顺序

功能架构图完成后，必须为每条连线定义接口。接口至少包含五项：信号名、数据类型、单位、更新周期、有效范围。以“目标夹紧力计算”到“电机电流闭环”的接口为例，可定义为：TargetCurrent_A，float32，单位 A，周期 10 ms，范围 0～25 A。接口定义不清，MIL 阶段就会出现“模型能跑但结果对不上”的问题。

执行顺序同样需要在架构阶段确定。同一周期内，监控功能应先于控制功能执行，安全功能应在控制输出之前完成使能判定。推荐顺序为：输入采集 → 监控判定 → 诊断记录 → 安全使能 → 控制计算 → 输出执行。若使用 Simulink 建模，可通过 Function-Call Subsystem 或 Stateflow 的并行状态显式表达这一顺序，避免依赖求解器默认排序。

五、可追溯性与验证准备

功能架构的最终价值在于可追溯。建议为每个功能项建立唯一编号，例如 EPB-C-003 表示控制类第 3 项，EPB-S-001 表示安全类第 1 项。编号应同时出现在功能清单、架构图、模型命名和测试用例中。这样在 MIL 验证时，任何一条失败用例都能快速定位到对应功能项及其上下游接口。

完成以上工作后，功能架构就具备了进入 MIL 验证的条件：控制链有明确的输入输出，监控与诊断有可观测的判定变量，安全路径有可注入的故障条件。下一阶段即可基于该架构搭建被控对象模型、控制器模型与测试激励，逐项验证功能行为是否符合设计预期。