3. 底盘控制与整车集成的需求工程

在新能源汽车底盘控制与整车集成项目中，需求工程不是“写文档”，而是把整车层面的性能目标逐级翻译成可设计、可标定、可验证的控制需求。整车目标通常以主观评价与客观指标混合表达，例如“高速变线稳定、制动不跑偏、颠簸路面车身姿态收敛快、能量回收介入不突兀”。底盘控制团队必须把这些目标拆解为悬架、转向、制动、驱动/回收四个执行子系统的控制需求，并明确接口、优先级与验证指标。

一、分解主线：从整车目标到控制需求

推荐采用“目标—场景—功能—控制需求—验证指标”的五级分解链。第一级是整车性能目标，如稳态回转不足转向度、蛇行试验侧倾角、制动距离、能量回收减速度波动。第二级是典型场景，如双移线、对开路面制动、减速带、低附起步。第三级是底盘功能，如侧倾控制、横摆稳定控制、制动力分配、回收扭矩协调。第四级是控制需求，必须写成可执行、可判定的语句，包含输入信号、控制量、执行器、边界条件与失效策略。第五级是验证指标，包括客观测量量、通过阈值与试验工况。

分解时最容易出错的是“目标不可测量”和“需求不可执行”。例如“提升操稳性”不是需求，应改写为：在车速80～120 km/h、方向盘正弦扫频输入下，横摆角速度相位滞后不超过某阈值，且侧向加速度增益波动小于设定范围。再如“回收要平顺”应改写为：在回收扭矩阶跃请求下，纵向减速度变化率不超过设定值，且与液压制动切换时无扭矩中断。

二、典型需求文档结构

底盘控制需求文档通常由需求编号、需求描述、来源目标、适用场景、输入信号、输出控制量、执行器、边界条件、失效策略、验证方法、优先级和版本状态组成。需求描述必须使用“在……条件下，系统应……”的句式，避免“尽量”“较好”等模糊词。每条需求应可追溯到上层整车目标，并向下关联到测试用例。

以“回收扭矩与液压制动协调”为例，可写成：在车速大于20 km/h、电池允许充电功率大于30 kW、制动踏板开度小于15%的条件下，VCU应在200 ms内将回收扭矩从0提升至目标值，且纵向减速度变化率不超过0.5 m/s³；当ABS触发时，回收扭矩应在50 ms内退出，液压制动保持。该需求包含输入、输出、时间、边界和失效策略，可直接用于HIL测试。

三、验证指标与判据

验证指标分为客观测量与主观评价两类。客观指标包括横摆角速度增益、侧倾角、制动距离、减速度波动、扭矩响应时间、信号延迟等；主观评价包括转向手感、车身跟随性、制动线性度、回收介入突兀感。每项指标需明确工况、测量设备、采样率和通过阈值。

四、从需求到验证的闭环

需求分解完成后，应建立需求—测试用例—验证结果的追溯矩阵。每个控制需求至少对应一个测试用例，每个测试用例明确输入激励、测量信号、通过判据和失败处理。验证顺序通常为MIL（模型在环）、SIL（软件在环）、HIL（硬件在环）、实车场地和主观评价。若某指标不通过，应回溯到对应控制需求，判断是需求定义不合理、算法实现偏差还是标定参数不当，再决定修改需求或调整实现。

实际项目中，需求变更不可避免。建议对每条需求设置版本号和变更记录，变更后重新评估对上层整车目标的影响，并同步更新测试用例。只有形成“目标—需求—实现—验证—变更”的闭环，底盘控制与整车集成才能真正做到可交付、可复现、可追溯。