4. 底盘域控制器软件平台需求工程

底盘域控制器（Chassis Domain Controller，CDC）把制动、转向、悬架、驻车等多个原本独立的控制功能集中到一个软件平台上。平台一旦承载多源需求，需求工程就不再是“写文档”，而是决定后续架构、代码、测试能否收敛的源头。本节围绕四类需求与两条管理主线展开：功能需求回答“系统要做什么”，非功能需求约束“做到什么程度”，安全需求规定“失效时如何不伤人”，需求追踪与变更管理保证“改动可控、证据可查”。

一、功能需求：从整车行为落到可验证条目

功能需求描述系统对外可观察的行为，通常以“触发条件—输入—处理—输出—约束”五要素表达。以线控制动中的“舒适制动”为例，一条可落地的需求可写成：当驾驶员踩下制动踏板且减速度需求小于 3 m/s² 时，CDC 应在 20 ms 内计算目标轮缸压力，并通过 CAN FD 发送给制动执行器，压力跟随误差不超过 ±0.3 MPa。这里“20 ms”“±0.3 MPa”就是可验证的量化约束，而不是“响应要快”这类无法测试的表述。

底盘域功能需求常按功能域分组：纵向（驱动、制动）、横向（转向）、垂向（悬架）以及跨域协同（如自动泊车时转向与制动的时序配合）。分组后要识别功能间的耦合点，例如“制动与悬架协同抑制俯仰”会同时涉及两个执行器，需求中必须明确仲裁优先级与降级策略，否则集成阶段极易出现执行器争抢。

二、非功能需求：平台级约束决定可维护性

非功能需求不描述具体功能，却决定平台能否长期演进。底盘域控制器常见的非功能需求包括：实时性（关键控制回路周期 ≤ 5 ms，抖动 ≤ 10%）、资源占用（CPU 负载 ≤ 70%，RAM 预留 ≥ 20%）、启动时间（上电到可响应 ≤ 300 ms）、通信带宽（CAN FD 总线负载 ≤ 60%）、诊断与刷写（UDS 刷写单区 ≤ 90 s）、以及可移植性（应用层不直接调用硬件寄存器）。这些指标应写成可测量条目并绑定验证方法，例如“CPU 负载”需说明在何种工况、何种采样窗口下测量。

三、安全需求：从危害分析反推技术约束

安全需求来自危害分析与风险评估（HARA）。假设“制动助力失效导致制动力不足”被评定为 ASIL D，则安全需求可能包括：CDC 应能检测助力回路压力异常，并在 50 ms 内切换至备份路径；若备份路径不可用，应点亮报警并限制车速。安全需求必须可追溯到具体危害与安全目标，且每条都应有独立的验证证据，不能与功能需求混写在同一句里。

四、需求追踪与变更管理：让改动有据可依

需求追踪建立双向链路：向上追溯到整车需求或安全目标，向下追溯到架构元素、软件组件、测试用例。常用做法是给每条需求分配唯一 ID（如 REQ-BRK-012），并在需求管理工具中维护“派生自/满足/验证”关系。当某条需求变更时，工具能自动列出受影响的架构模块与测试用例，形成影响分析清单。

变更管理则规定流程：变更申请→影响分析→评审决策→实施→验证→基线更新。以“将制动响应时间从 20 ms 收紧到 15 ms”为例，影响分析需检查执行器能力、总线负载、CPU 余量、相关测试用例是否仍有效；若评审通过，则更新需求基线并同步刷新追踪矩阵，确保测试覆盖不遗漏。

五、落地要点与常见误区

第一，需求粒度要一致。功能需求写到“CDC 在 20 ms 内输出目标压力”即可，不必展开到函数级；安全需求则必须写到可验证的检测与降级动作。第二，非功能需求要绑定测量条件，否则“负载 ≤ 70%”在不同工况下结论不同。第三，追踪矩阵不是一次性文档，每次基线更新都应同步刷新，否则变更影响分析会失真。第四，变更评审要保留决策记录，包括驳回理由，这对后续审计与复盘同样重要。

把三类需求分栏管理、用唯一 ID 串联追踪、以变更流程控制基线，底盘域控制器软件平台才能在多轮迭代中保持需求、架构、代码与测试的一致。需求工程做扎实，后续的集成与验证才有稳定的参照系。