4. 系统需求工程与需求分解

线控转向（Steer-by-Wire, SBW）系统取消了方向盘与转向器之间的机械连接，整车的转向手感、安全冗余和功能安全都依赖电子电气架构与软件逻辑来保证。这种“以电信号替代机械力传递”的本质，使得需求工程成为项目成败的关键：整车级的一句“转向响应应线性且可调”，必须逐层分解为系统级、子系统级、软件级和硬件级可验证、可追踪、可变更管理的需求条目。本节围绕“分解—分配—追踪—变更”四条主线，说明如何把整车需求落到可实现的工程对象上。

一、需求层级与分解逻辑

需求分解不是简单地把一句话拆成几句话，而是沿着“整车—系统—子系统—软硬件”的架构边界，把功能需求、性能需求、安全需求和接口需求分别落到对应的责任主体上。以 ZF 线控转向系统为例，典型的层级关系如下：

• 整车级需求（Vehicle Level）：如“车辆在 0～120 km/h 范围内，方向盘转角到前轮转角的传动比可在 8:1～16:1 之间连续可调”，以及“满足 ISO 26262 ASIL-D 的转向功能安全目标”。
• 系统级需求（System Level）：SBW 系统需在方向盘模块与转向执行模块之间通过冗余 CAN FD 或以太网传输转角指令，端到端延迟 ≤ 10 ms，并具备双电源、双通信、双绕组电机冗余。
• 子系统级需求（Subsystem Level）：路感模拟器子系统需在方向盘上输出 0～8 N·m 的反馈力矩，分辨率 ≤ 0.05 N·m；转向执行子系统需输出 0～12 kN 的齿条力，位置控制精度 ±0.5 mm。
• 软件级需求（Software Level）：转角控制算法需在 1 ms 周期内完成目标转角解析、前馈+反馈计算和限幅保护；故障诊断模块需在 20 ms 内识别传感器信号失效并进入降级模式。
• 硬件级需求（Hardware Level）：电机绕组绝缘等级 H 级，位置传感器精度 ±0.1°，MCU 需满足 ASIL-D 并具备锁步核与 ECC 内存。

分解过程中要遵循“需求可分配、可验证、无歧义”的原则。例如“转向应安全”无法直接分配，必须转化为“在单点故障下，系统应在 100 ms 内进入安全状态，且剩余转向能力不低于 50% 的齿条力”。

二、需求分配与追踪矩阵

需求分配的核心是建立“需求—架构—验证”三者的映射关系。工程上通常使用需求管理工具（如 DOORS、Polarion 或 Jama）维护追踪矩阵，确保每条下级需求都能向上追溯到整车需求，每条整车需求都能向下找到实现与验证的责任项。追踪关系至少应覆盖：

• 派生关系（Derives）：整车需求 → 系统需求 → 子系统需求 → 软硬件需求。
• 满足关系（Satisfies）：架构元素（如路感模拟器 ECU、转向执行 ECU）满足对应需求。
• 验证关系（Verifies）：测试用例、仿真场景或台架试验验证对应需求。
• 接口关系（Interface）：定义信号名称、数据类型、周期、超时阈值和失效默认值。

以“端到端延迟 ≤ 10 ms”为例，其追踪链可表示为：整车操控性需求 → SBW 系统通信需求 → 转角指令传输接口需求 → CAN FD 报文周期 2 ms + 接收超时 4 ms → 台架延迟测试用例。任何一环缺失，都会导致需求无法闭环。

三、需求变更管理

线控转向项目周期长、涉及供应商多，需求变更几乎不可避免。变更管理的目标不是“阻止变更”，而是让每一次变更都经过影响分析、审批和追踪刷新。典型流程包括：变更请求（CR）提出 → 影响分析（涉及哪些系统、子系统、软硬件、测试用例和整车验证）→ 变更控制委员会（CCB）评审 → 基线更新 → 追踪矩阵同步 → 通知相关方。

以“将传动比范围从 8:1～16:1 调整为 6:1～18:1”为例，影响分析至少应覆盖：路感模拟器软件标定表范围、转向执行电机峰值力矩需求、通信报文数据长度、HIL 测试用例边界值、整车操控稳定性验证场景。若遗漏其中一项，就可能在后期出现“软件改了、测试没改”的追踪断裂。

四、可执行的追踪矩阵示例

下表给出一个简化的需求追踪矩阵片段，字段可根据项目裁剪，但“需求编号、需求描述、上级需求、责任架构、验证方法、验证用例、状态”应作为最小集合保留。

需求工程的价值最终体现在“可追踪、可验证、可变更”三个维度上。整车级需求只有经过系统化分解、明确分配、闭环追踪和受控变更，才能真正落到 ZF 线控转向系统的软硬件实现中，并在整车验证阶段获得可信的确认结果。