2. 底盘控制系统需求分析与功能定义
底盘控制系统的开发起点不是某个ECU的选型，也不是某段控制算法的推导，而是整车级需求。整车级需求回答的是“这辆车在底盘域要达成什么”，例如制动距离、操纵稳定性、转向手感、乘坐舒适性、功能安全等级以及法规符合性。系统级功能需求则回答“由哪些功能、以什么接口和性能边界去实现这些目标”。两者之间必须建立可追溯的映射关系，否则后续的软件架构、标定和验证都会失去判据。
一、整车级需求如何落到系统级功能需求
整车级需求通常以整车性能指标、法规条目和用户可感知属性三种形式出现。以制动为例，整车级需求可能表述为“在附着系数0.8的路面上，100 km/h初速下的冷态制动距离不超过38 m”，同时要求满足ECE R13-H的制动法规。这类需求不能直接交给ABS或ESP去实现，必须先分解为系统级功能需求：制动系统需具备车轮滑移率控制能力、前后轴制动力分配能力、失效降级能力，以及与其他底盘系统（如EPS、CDC）的协同接口。
分解过程遵循“性能指标→功能行为→接口与约束”的路径。性能指标是“做到什么程度”，功能行为是“通过什么动作实现”，接口与约束是“在什么边界内、与谁交互”。例如，将“操纵稳定性”分解为横摆角速度跟踪、不足转向/过度转向抑制、单轮制动干预等系统级功能；将“转向手感”分解为助力扭矩随车速和方向盘力矩的调节特性、回正补偿、阻尼补偿等功能。
二、需求分解与追溯的工程方法
需求分解的核心是保持语义可验证。每条系统级功能需求应包含触发条件、输入信号、功能行为、输出动作和性能边界。以ESP的“不足转向抑制”为例，可写成：当车速大于40 km/h、方向盘转角与横摆角速度的偏差超过阈值、且驾驶员有转向意图时，系统应对内侧后轮施加制动，产生附加横摆力矩，使横摆角速度偏差在500 ms内收敛到目标带内。这样的表述可以直接转化为测试用例和标定目标。
追溯关系通常用需求追溯矩阵（RTM）维护。矩阵的行是整车级需求，列是系统级功能需求，交叉点标注覆盖关系。反向追溯同样重要：当某个系统级功能需求变更时，必须能查到它影响哪些整车级需求、哪些测试用例、哪些标定参数。工程实践中，RTM常与需求管理工具（如DOORS、Polarion）中的链接关系绑定，但即使没有工具，手工维护一张“需求ID—父需求ID—验证方法—责任人”的表也能支撑中小项目。
三、典型功能清单的工程定义方法
底盘域典型功能包括ABS、ESP、EPS、CDC等，每个功能的工程定义都应覆盖“功能边界、输入输出、性能指标、失效策略”四个维度。以下以表格形式给出示例定义，参数为教学示例，不代表任何具体车型的实测值。
| 功能 | 功能边界 | 关键输入 | 关键输出 | 性能指标（示例） | 失效策略 |
|---|---|---|---|---|---|
| ABS | 制动工况下的车轮滑移率控制 | 四轮轮速、制动主缸压力、车速估计 | 各轮增压/保压/减压指令 | 滑移率目标0.15~0.25，控制周期≤10 ms | ABS失效时退回常规制动，报警灯点亮 |
| ESP | 不足转向/过度转向抑制、驱动防滑 | 横摆角速度、方向盘转角、轮速、纵向/横向加速度 | 单轮制动压力请求、发动机扭矩请求 | 横摆角速度偏差收敛时间≤500 ms | ESP关闭或降级时保留ABS，提示驾驶员 |
| EPS | 转向助力、回正、阻尼补偿 | 方向盘扭矩、方向盘转角、车速、电机电流 | 电机目标电流/扭矩 | 助力扭矩跟随误差≤5%，响应延迟≤30 ms | 助力失效时保留机械转向，故障灯点亮 |
| CDC | 连续阻尼控制，车身姿态与舒适性调节 | 车身加速度、车轮加速度、车速、转向角 | 各减振器电磁阀电流 | 阻尼力调节范围覆盖舒适到运动模式 | CDC失效时减振器回到默认阻尼，提示驾驶员 |
四、从功能定义到可验证需求的检查要点
功能定义完成后，需要用一组检查问题来确认需求质量。第一，每条需求是否有明确的触发条件和退出条件；第二，性能指标是否可测量，例如“响应快”不可验证，“响应延迟≤30 ms”可验证；第三，接口信号是否有明确的来源、更新周期和有效范围；第四，失效策略是否定义了降级路径和驾驶员提示方式；第五，需求之间是否存在冲突，例如ESP的制动干预与ABS的滑移率控制在同一车轮上同时请求时，优先级如何仲裁。
在工程实践中，ABS与ESP的仲裁通常由ESP控制器统一协调：ABS负责单轮滑移率闭环，ESP在其上层请求附加横摆力矩，两者通过制动压力请求的优先级和限幅逻辑合并。EPS与ESP之间则通过整车网络交换方向盘转角和横摆角速度信号，ESP的横摆稳定请求可以触发EPS的主动转向补偿（若配备），但必须定义请求的使能条件和退出条件，避免驾驶员感到转向被“抢夺”。
完成本章的需求分析与功能定义后，后续的软件架构设计、信号接口定义、标定和测试都将以这里的追溯链为基准。需求定义的质量直接决定后续开发返工量，因此在项目早期投入足够时间把整车级需求分解到可验证的系统级功能需求，是底盘控制系统工程开发中回报最高的环节之一。