4. VCU硬件系统架构

做VCU架构设计这些年，我踩过最大的坑，就是需求没理清楚就急着画框图。你想想看，一个需求理解偏差，到了实车测试阶段才暴露，那改动的成本可不是翻倍那么简单，简直是几何级增长。所以这一章，咱们把需求分析的方法论掰开揉碎了讲。

4.1 谁在提需求？—— Stakeholder 需求分析

很多人一上来就问“VCU要做什么功能”，这其实是个陷阱。你得先问“谁需要VCU做什么”。Stakeholder（利益相关方）不只有客户，还包括法规、生产、售后、甚至隔壁做BMS的兄弟团队。

我个人习惯，在项目启动阶段先拉一张 Stakeholder 清单。别嫌麻烦，这张表能帮你挡住至少一半的需求变更。

4.2 从“想要”到“要做”—— 系统需求导出

Stakeholder 的需求往往是模糊的、口语化的。比如“加速要猛”，这没法写进软件需求规格书。系统需求导出的过程，就是把“想要”翻译成“要做”。

我常用的方法是 “5W1H + 量化”：

• Who： 谁在什么场景下使用？
• What： 期望的行为是什么？
• Where： 在哪个系统边界内？
• When： 触发条件是什么？
• Why： 为什么需要这个行为？
• How： 如何验证这个需求？

举个例子，Stakeholder说“上坡起步不能溜车”。导出的系统需求可能是：

系统需求编号：SYS-REQ-0042
需求描述：当车辆处于坡度 ≥ 5% 的上坡路面，且驾驶员从制动踏板切换到加速踏板的时间间隔 ≤ 2s 时，VCU应通过EPB或液压制动保持车辆静止，溜车距离 ≤ 10cm。
验证方法：在20%坡道上进行实车测试，记录溜车距离。

你看，这样写出来的需求，测试工程师拿到手就知道怎么测，软件工程师也知道怎么实现。

4.3 功能需求 vs 非功能需求

很多刚入行的工程师容易把这两者混在一起写。我建议你从一开始就分开管理，否则后期做测试用例和架构评估时会非常痛苦。

非功能需求在VCU领域尤其重要，因为它直接决定了你用什么样的MCU、多大的RAM、什么样的通信协议。比如：

• 实时性： 扭矩控制周期 ≤ 10ms，状态机切换 ≤ 5ms
• 可靠性： 系统在 -40°C ~ 125°C 环境下连续运行 1000 小时无故障
• 安全性： 满足 ASIL C/D 等级，单点故障覆盖率 ≥ 99%
• 可维护性： 支持通过 CAN 进行 Bootloader 刷写，刷写时间 ≤ 3 分钟

4.4 需求追溯矩阵 —— 别让需求“失联”

需求追溯矩阵（RTM），说白了就是一张“需求-设计-测试”的对照表。它的核心价值在于：当有人提出需求变更时，你能立刻知道哪些代码、哪些测试用例、哪些文档需要跟着改。

我习惯用三层追溯结构：

1. Stakeholder 需求 → 系统需求： 确保每个“想要”都被翻译成了“要做”
2. 系统需求 → 软件/硬件需求： 确保每个“要做”都有对应的实现方案
3. 系统需求 → 测试用例： 确保每个“要做”都有验证手段

下面是一个简化的 RTM 示例：

4.5 知识体系总览

为了让你更直观地理解这一章的知识结构，我画了一张图。它把需求分析的四个核心步骤串在了一起，从Stakeholder出发，最终落到可追溯的测试验证。

这张图从左到右、从上到下，就是需求分析的标准流程。你每次做新项目，都可以拿这张图来对照，看看自己走到了哪一步，有没有跳步。