3. 底盘与动力控制软件需求分析

在 SPC5 这类面向底盘与动力控制的 32 位 MCU 平台上，需求分析不是把功能描述改写成条目，而是把整车层面的功能意图，翻译成可分配、可实现、可验证的软件约束。底盘域涉及扭矩、制动、转向三条控制链，它们共享传感器、CAN/FlexRay 通信、电源与安全监控资源，因此需求必须同时回答“做什么”“做到什么程度”“失效时怎么办”“如何证明做到了”。本节围绕功能安全需求、实时性需求、扭矩/制动/转向控制需求、诊断需求与需求管理方法展开。

功能安全需求：从安全目标到软件安全机制

功能安全需求以 ISO 26262 的 ASIL 等级为起点。假设某底盘域控制器承担“防止非预期驱动扭矩输出”的安全目标，ASIL D 要求单点故障度量与潜伏故障度量达到严格阈值。软件侧的安全需求通常包括：扭矩监控（Torque Monitoring）、三层监控概念（Level 1 功能监控、Level 2 程序流监控、Level 3 外部看门狗）、RAM/Flash 自检、锁步核比较、ADC 冗余采样一致性检查等。

以扭矩监控为例，需求可写成：安全监控模块应在 10 ms 周期内，将实际扭矩与驾驶员请求扭矩的偏差与标定阈值比较；若偏差超过 ±15 N·m 且持续 3 个周期，则触发降扭并请求安全状态。这里“10 ms”“±15 N·m”“3 个周期”都是可验证的量化约束，而不是“及时”“合理”这类模糊表述。SPC5 的锁步核与 FCCU（Fault Collection and Control Unit）为这类需求提供了硬件基础，软件需求需明确故障注入测试点与响应路径。

实时性需求：周期、抖动与端到端时延

底盘控制的实时性需求通常以控制周期、执行抖动和端到端时延三个指标描述。扭矩控制环常见 1 ms～10 ms 周期，制动压力控制约 5 ms，转向助力控制约 1 ms～2 ms。需求分析阶段必须把这些周期与 SPC5 的定时器、中断优先级、DMA 通道绑定，并给出最坏执行时间（WCET）预算。

例如某转向控制任务需求：控制周期 2 ms，抖动不超过 200 μs，从角度传感器采样到 PWM 输出的端到端时延不超过 1.5 ms。分析时需拆解为采样延迟、CAN 传输延迟、任务调度延迟、算法计算时间与执行器响应时间，并逐项分配预算。若某段预算超限，应在需求阶段就提出降采样、提高任务优先级或改用硬件触发采样等方案，而不是留到集成阶段才发现。

扭矩、制动与转向控制需求

扭矩控制需求的核心是“请求—仲裁—执行—监控”四段。驾驶员扭矩请求、巡航请求、ESC 降扭请求、变速箱换挡请求可能同时存在，需求必须定义仲裁优先级。例如：安全类降扭请求优先级最高，其次为驾驶员请求，再次为舒适性请求。仲裁结果经扭矩协调后输出给发动机或电机控制器，同时送入扭矩监控模块做独立校验。

制动控制需求需区分常规制动与 ESC 干预。常规制动关注踏板力—减速度线性度与踏板感，ESC 干预关注单轮增压/减压的响应时间与压力控制精度。转向控制需求则关注助力扭矩随车速与方向盘力矩的变化曲线、回正特性以及失效时的降级策略（如助力降级但保留机械转向）。三类需求共享传感器信号时，必须定义信号有效性与超时判定，例如方向盘角度信号超时 20 ms 即进入降级。

诊断需求：UDS、DTC 与去抖策略

诊断需求通常基于 UDS（ISO 14229）。底盘控制器需支持 0x19 读取 DTC、0x22 读取数据标识符、0x2E 写入配置、0x31 例程控制等。每个 DTC 需定义故障判定条件、去抖时间、恢复条件与冻结帧内容。例如“扭矩传感器信号超范围”DTC：当采样值超出 0.5 V～4.5 V 且持续 100 ms 时置位；当采样值恢复正常并持续 500 ms 后清除。去抖参数需在需求中明确，避免诊断误报或漏报。

需求管理方法：追溯与变更控制

需求管理不是文档管理，而是变更影响控制。每条需求应有唯一 ID，并建立“需求—设计—代码—测试用例”双向追溯矩阵。当某条实时性需求从 2 ms 调整为 1 ms 时，追溯矩阵应能立即定位受影响的算法模块、任务配置与测试用例，并触发安全与实时性影响分析。需求基线冻结后，任何变更须经变更评审，评估对 ASIL 分解、WCET 预算与诊断覆盖率的连锁影响。

综上，底盘与动力控制软件需求分析的关键在于：把安全目标量化为可验证的安全机制，把实时性拆解为可分配的时延预算，把扭矩/制动/转向控制写成带仲裁与降级策略的明确约束，把诊断写成带去抖与恢复条件的 DTC 规则，并用双向追溯与变更控制把四类需求串成闭环。只有需求阶段做到可量化、可追溯，后续的 SPC5 软件实现与 HIL 验证才有可靠依据。