第二章 需求分析与系统架构：客户需求解读、系统架构设计、功能分配、接口定义

说实话，很多工程师拿到客户需求的第一反应是——直接开干。我年轻时也这样，结果呢？做了三个月，客户说“这不是我要的”。嗯，那滋味真不好受。

这一章，咱们聊聊怎么把客户那些“模棱两可”的话，变成实实在在的硬件方案。说白了，就是把需求翻译成技术语言。

2.1 客户需求解读：别猜，要问

客户说“我要一个稳定的ECU”。什么叫稳定？是-40℃能工作？还是99.9%的可靠性？还是EMC过Class 5？

我习惯把客户需求拆成三层：

• 功能需求：要做什么？比如“控制雨刮器”
• 性能需求：做到什么程度？比如“响应时间<10ms”
• 环境需求：在什么条件下做？比如“工作温度-40~125℃”

这里有个小技巧：拿一份需求检查清单，逐条跟客户确认。比如：

需求项	客户描述	技术量化	确认状态
供电电压	12V系统	9V~16V（含抛负载）	✅
工作温度	车规级	-40℃~125℃	✅
通信接口	CAN总线	CAN 2.0B, 500kbps	✅

2.2 系统架构设计：画图比写代码重要

需求清楚了，下一步就是画架构图。我个人习惯先画功能框图，再画电气架构图。

为什么？因为架构决定了后续所有设计。电源怎么分配？信号怎么走？MCU选哪家？全看这张图。

下面是我常用的一个ECU系统架构图，用SVG画的，你感受一下：

2.3 功能分配：谁做什么，划清楚

架构图有了，接下来就是功能分配。说白了，就是决定哪个功能由硬件做，哪个由软件做。

举个例子：

• 硬件做：电源保护、信号调理、看门狗定时器
• 软件做：诊断策略、通信协议、控制算法
• 软硬件协同：PWM生成（硬件定时器+软件占空比配置）

这里有个原则：能硬件做的，尽量别让软件做。为什么？硬件稳定，软件容易出bug。我见过一个项目，软件工程师用软件模拟PWM，结果CPU负载一高，PWM波形就抖。后来改成硬件PWM模块，问题解决。

2.4 接口定义：细节决定成败

接口定义，是ECU设计中最容易出问题的地方。我见过太多因为接口定义不清导致的“飞线”和“割板”。

接口定义包括：

1. 电气接口：电压、电流、频率、阻抗
2. 逻辑接口：电平定义、时序要求、协议格式
3. 物理接口：连接器型号、引脚定义、线束颜色

举个例子，一个简单的数字输入接口：

/* 数字输入接口定义 */
/* 引脚：J1-3 */
/* 电气参数： */
/*   - 高电平阈值：> 3.5V (VBAT=12V时) */
/*   - 低电平阈值：< 1.5V */
/*   - 上拉电阻：10kΩ 到 VCC */
/*   - 滤波时间：软件去抖 50ms */
/* 逻辑定义： */
/*   - 高电平：开关闭合（有效） */
/*   - 低电平：开关断开（无效） */
/* 注意：该引脚支持唤醒功能，需配置SBC的WAKE引脚 */

你看，一个简单的输入，定义清楚后，硬件工程师知道怎么画原理图，软件工程师知道怎么写代码，测试工程师知道怎么测。大家都省心。

2.5 需求跟踪矩阵：别让需求“丢了”

最后，我建议做一个需求跟踪矩阵。把每条客户需求，对应到具体的硬件模块、软件模块、测试用例。

比如：

需求ID	需求描述	硬件模块	软件模块	测试用例
REQ-001	工作电压9V~16V	电源模块	电压监测	TC-001~TC-005
REQ-002	CAN通信500kbps	CAN收发器	CAN驱动	TC-010~TC-015
REQ-003	过流保护	输出驱动	诊断模块	TC-020~TC-025

这个矩阵的好处是：任何需求变更，你都能立刻知道影响范围。客户说“我要加一个功能”，你一看矩阵，就知道要改哪个模块，影响哪些测试。心里有底，报价也准。

嗯，这一章的内容就这些。需求分析和系统架构，说白了就是把话说清楚，把图画明白。别急着动手，先把这些基础打牢。后面设计原理图、画PCB的时候，你会感谢现在的自己。