3. 底盘控制原型系统需求分析
底盘控制原型系统（MicroAutoBox 快速控制原型，RCP）的需求分析，本质上是把“整车想怎么动”翻译成“控制器要算什么、要接什么、要在多长时间内算完、算错或算不出来时怎么办”。它不是一个简单的功能清单，而是一条从整车动力学目标逐层收敛到执行器接口、实时性预算、安全与诊断约束的需求链。本节按这条链展开，并给出可直接用于后续建模与配置的示例参数。
一、从整车动力学目标导出被控量与控制自由度
需求分析的起点是整车层面的运动目标。以常见的底盘域控制为例，整车级目标通常包括：纵向车速跟踪、横摆角速度跟踪、侧偏角约束、车身侧倾/俯仰抑制、车轮滑移率控制。这些目标对应到可测量的状态量：车速 vx、横摆角速度 r、质心侧偏角 β、侧向加速度 ay、各轮轮速 ωi、车身加速度与角速度。控制自由度则来自执行器：驱动/制动扭矩、转向角、悬架阻尼或主动力。
在需求文档中，应把“目标—状态—执行器”写成可追溯的映射。例如：横摆角速度跟踪目标 r_ref 由方向盘转角 δsw 与车速经参考模型生成，控制量是四轮差动制动扭矩 ΔT_i 与后轮转向角 δr；侧偏角约束 |β| ≤ 5°（示例阈值）作为安全边界，超出时触发降级。这里必须明确坐标系约定：采用 ISO 8855 车辆坐标系，x 向前、y 向左、z 向上，横摆角速度绕 z 轴逆时针为正，转向角左转为正。全文与图示保持该约定。
二、执行器接口需求：从物理量到信号与协议
MicroAutoBox 本身不直接驱动大功率执行器，需求分析要明确“控制器输出什么、经谁转换、反馈什么”。典型接口分三类：
- 模拟量输出：如 0–5 V 对应制动压力 0–10 MPa，用于驱动比例阀或作为 ECU 的扭矩请求。需定义量程、偏置、增益与故障安全值（如断线时输出 0 V）。
- PWM/数字输出：如 1 kHz PWM，占空比 10%–90% 对应阻尼电流 0–2 A，用于电磁阀或主动悬架。需定义频率、死区、最小/最大占空比。
- CAN/CAN FD 总线：与转向 ECU、制动 ECU、电机控制器交互。需定义报文 ID、周期、信号名、字节序、缩放因子与超时判定。例如 0x1A0 报文 10 ms 周期，信号 SteerAngReq 缩放 0.1 °/bit，偏移 −780 °。
反馈侧同样要定义：轮速、压力、电流、转角、温度等传感器信号的范围、采样率与滤波需求。接口需求必须包含“上电默认值、通信丢失默认值、越界钳位”三类安全行为，否则后续 HIL 测试无法判定通过与否。
三、功能需求与非功能需求
功能需求描述“系统必须做什么”，例如：在 10–120 km/h 车速范围内，横摆角速度跟踪误差在稳态下不超过 2 °/s；在方向盘阶跃输入下，响应超调不超过 15%。非功能需求描述“在什么约束下做”，包括实时性、计算资源、内存、标定便利性、代码可移植性、温度与供电范围。两者必须分开编号，避免把“跟踪误差 ≤ 2 °/s”和“任务周期 1 ms”混为一谈。
一个常见的误区是只写功能不写非功能，导致模型在 Simulink 中仿真通过，但生成代码后因任务超时无法运行。因此需求分析阶段就要给出 CPU 负载上限（示例：≤ 70%）、最坏执行时间（WCET）预算、堆栈与 RAM 余量。
四、实时性指标：把控制周期拆成时间预算
实时性需求的核心是“控制周期 T_s 与任务链延迟”。以 1 ms 控制周期为例，一个控制步内要完成：ADC 采样与滤波、状态估计、参考模型、控制律、执行器输出、CAN 收发、诊断与记录。这些必须在一个 1 ms 窗口内完成，且留出抖动余量。
示例预算：采样与滤波 80 μs，状态估计 150 μs，控制律 200 μs，输出与 CAN 150 μs，诊断 50 μs，合计 630 μs，占周期 63%，满足 ≤ 70% 的负载要求。若某步超时，应触发超时计数器并记录，而不是静默丢帧。此外还要定义端到端延迟：从传感器采样到执行器输出不超过 2 个控制周期（示例 2 ms），否则闭环相位裕度会明显下降。
五、安全与诊断需求：把“算错”变成可检测、可降级
安全需求不是附加项，而是与功能需求同时定义的约束。对底盘控制原型，至少应覆盖：信号合理性（范围、变化率、冗余互校验）、通信超时（CAN 报文连续丢失超过 3 个周期即判故障）、任务超时（WCET 超过预算触发计数）、执行器输出越界钳位、以及故障后的降级策略。降级策略要具体：例如横摆控制失效时，将差动制动请求置零、后轮转向回正、仪表点亮故障灯，并限制车速。
诊断需求还应定义故障码（DTC）与快照数据。示例：DTC P0A01 表示“横摆角速度传感器信号无效”，快照记录车速、r、β、四个轮速与输出扭矩。这样在 HIL 或实车复盘时，能判断是传感器问题、模型问题还是接口问题。
六、需求条目的组织与可追溯性
建议用统一编号组织需求，例如 FR-01 功能需求、NFR-01 非功能需求、IF-01 接口需求、RT-01 实时性需求、SA-01 安全需求。每条需求包含：描述、验证方法（仿真/HIL/台架/实车）、通过判据、关联的模型模块与测试用例。这样从整车目标到执行器接口、从实时性预算到诊断降级，形成一条可追溯的链，后续建模、代码生成与测试才有依据。