4. 需求工程与可验证性设计
在Bosch车辆控制系统的开发中，需求工程不是“把客户的话抄一遍”，而是一次有约束的翻译：把客户以整车功能语言表达的需求，转化为系统层面可设计、可实现、可验证的条目，并让每一条需求都能被追溯到来源与验证证据。客户说“车辆在雨天高速行驶时不应出现误制动”，这是需求；但系统工程师必须把它拆成传感器置信度、路面附着估计、制动执行阈值、故障降级策略等可测试条目，否则验证团队无法设计用例，也无法判断通过与否。
从客户需求到系统需求的转化
客户需求通常来自整车厂的功能需求文档、法规要求或平台化规范，表述偏功能与场景，例如“ACC在0–130 km/h范围内应保持安全跟车距离”。系统需求则要落到Bosch可交付的控制器、传感器、执行器与软件模块上，必须包含明确的输入、输出、边界条件、性能指标和异常行为。转化过程一般经历四步：场景分解、功能分解、接口定义、指标量化。
以“雨天高速不误制动”为例，场景分解得到：车速>80 km/h、雨量传感器激活、路面湿滑、前方无真实障碍。功能分解得到：雷达目标置信度评估、摄像头车道线有效性判断、制动请求仲裁。接口定义明确：雷达通过CAN FD发送目标列表，周期20 ms；摄像头通过以太网发送车道线曲率，周期30 ms；ESC接收制动请求，响应时间≤50 ms。指标量化则把“不应误制动”转化为：在湿滑路面、目标置信度<0.6时，误制动触发率≤1×10⁻⁶/小时，且任何单点故障不得导致非预期制动。
需求可测试性准则
可测试性不是验证阶段才考虑的事，而是在写需求时就要嵌入的约束。一条可测试的系统需求通常满足以下准则：
- 可观测：存在明确的测量点或信号，如CAN报文、诊断DID、标定变量或台架传感器。
- 可量化：包含数值、单位、容差和统计口径，如“≤150 ms”而非“快速”。
- 可复现：前置条件、输入激励和初始状态可被独立设置，如车速、雨量、目标距离。
- 可判定：通过/失败准则唯一，不依赖主观评价，如“误制动次数=0”而非“感觉正常”。
- 可分解：能映射到至少一个测试层级（单元、SIL、HIL、整车）和一种验证方法（测试、分析、评审、演示）。
在Bosch实践中，常用“需求质量检查表”逐条评审。例如一条需求写“系统应在通信丢失时进入安全状态”，评审时会追问：丢失判定时间是多少？安全状态是降级、关闭还是保持？由哪个ECU执行？恢复条件是什么？若无法回答，该需求即不可测试，必须退回补充。
需求追溯矩阵（RTM）的建立与维护
RTM是需求工程的中枢台账，它把客户需求、系统需求、软件/硬件需求、测试用例、验证结果和变更记录串成一条链。建立RTM时，先给每条需求分配唯一ID，再建立双向链接：向上追溯到客户需求或法规条款，向下追溯到设计元素与测试用例。维护RTM的关键是“变更驱动更新”：任何需求变更都必须同步更新受影响的下游链接，并标记验证状态。
下表给出一个简化的RTM示例，字段和粒度可根据项目裁剪，但追溯方向与状态必须完整。
| 需求ID | 需求描述（摘要） | 来源 | 下游设计/模块 | 验证方法 | 测试用例ID | 状态 |
|---|---|---|---|---|---|---|
| SYS-ACC-012 | 湿滑路面目标置信度<0.6时禁止非预期制动 | CUS-ACC-004 | 雷达融合、制动仲裁 | HIL测试 | TC-ACC-045 | 已通过 |
| SYS-ACC-013 | ESC收到制动请求至0.3 g减速度≤150 ms | CUS-ACC-004 | ESC控制、CAN FD | 台架测试 | TC-ESC-021 | 待验证 |
| SYS-ACC-014 | 单点通信丢失后100 ms内进入降级模式 | ISO 26262 | 通信监控、安全状态机 | 故障注入 | TC-SAF-009 | 已通过 |
RTM的维护还要关注“孤儿需求”和“悬空链接”：没有上游来源的需求可能是范围蔓延，没有下游测试的需求则无法验证。建议在每次需求基线冻结前运行追溯完整性检查，覆盖率应达到100%；对于安全相关需求，还需额外记录ASIL等级和独立验证证据。
在实际项目中，RTM通常由需求管理工具（如DOORS、Polarion或内部平台）承载，但工具只是载体，关键仍是需求条目本身的质量。建议在需求评审时同时检查三件事：这条需求能否被测试？它的上游来源是否明确？它的下游链接是否完整？只有三者同时成立，需求才真正具备可验证性，后续的HIL测试、整车标定和量产放行才有可靠依据。