3、系统级需求分析：整车厂视角的需求层次、功能需求与非功能需求、需求追溯矩阵（RTM）建立方法
好，我们进入第三讲。这一讲，我打算聊聊系统级需求分析。说白了，就是站在整车厂的角度，把TPMS这个系统到底要干什么、干到什么程度，掰开了揉碎了讲清楚。
很多工程师容易犯一个毛病——上来就写代码、画电路。我个人习惯是，先花时间把需求理清楚。为什么？因为需求是源头。源头错了，后面全白干。我在项目里见过太多次，因为需求没对齐，最后胎压误报、通信延迟、甚至跟其他ECU打架，搞得大家焦头烂额。
3.1 整车厂视角的需求层次
整车厂看TPMS，跟零部件供应商看TPMS，角度完全不一样。供应商可能更关注“这个传感器能不能测准0.1bar”，而整车厂更关注“这个系统能不能在-40°C到125°C的极端环境下稳定工作，并且不影响整车的电磁兼容性”。
我习惯把需求分成三个层次来看：
- 战略层需求：这是最顶层的。比如“满足中国GB 26134法规”、“支持未来OTA升级”、“成本控制在XX元以内”。这些需求往往来自市场部、法规部、甚至公司高层。它们不涉及具体技术，但决定了整个项目的走向。
- 系统层需求：这是中间层。比如“系统需在车辆启动后60秒内完成所有轮胎的压力和温度采集”、“系统需支持4个轮胎+1个备胎的监测”。这些需求是系统工程师根据战略层需求分解出来的，是后续硬件、软件、结构设计的输入。
- 组件层需求：这是最底层。比如“传感器模块的静态电流需小于1μA”、“天线阻抗需匹配到50Ω”。这些需求是硬件工程师、软件工程师、结构工程师各自负责的。
我的经验是：很多项目出问题，就是因为战略层需求没分解好，直接跳到了组件层。比如法规要求“报警响应时间小于3秒”，但系统层没定义清楚“从哪个时刻开始计时”，结果硬件和软件各算各的，最后测试对不上。
3.2 功能需求与非功能需求
需求还可以从另一个维度切分：功能需求和非功能需求。这个划分，说白了就是“系统要做什么”和“系统要做得怎么样”的区别。
3.2.1 功能需求
功能需求是具体的、可操作的行为。对于TPMS来说，典型的功能需求包括：
- 胎压监测：实时监测每个轮胎的气压值，范围0-800kPa，精度±10kPa。
- 胎温监测：实时监测每个轮胎的内部温度，范围-40°C到125°C，精度±2°C。
- 报警功能：当胎压低于设定阈值（比如1.6bar）或高于设定阈值（比如3.2bar）时，触发声光报警。
- 快速漏气报警：当检测到胎压在短时间内（比如30秒内）下降超过0.3bar时，触发紧急报警。
- 自诊断功能：系统上电时进行自检，如果传感器失效或通信中断，需上报故障码。
嗯，这里要注意。功能需求一定要写清楚“输入-处理-输出”的完整链路。比如“胎压监测”这个需求，不能只写“监测胎压”，要写清楚：传感器采集数据→通过RF发送→接收模块解码→CAN总线发送→仪表盘显示。每一步的接口、协议、时序都要明确。
3.2.2 非功能需求
非功能需求，说白了就是系统的“质量属性”。它不直接描述功能，但决定了功能实现得好不好。我遇到过最头疼的非功能需求，就是“系统不能因为TPMS的射频信号干扰到收音机”。
常见的非功能需求包括：
- 可靠性：系统在整车生命周期内（比如10年或20万公里）的失效率需低于100ppm。
- 实时性：从传感器采集到仪表盘显示，端到端延迟不超过2秒。
- 安全性：系统需满足ISO 26262 ASIL B等级要求，防止因TPMS故障导致驾驶员误判。
- 电磁兼容性（EMC）：系统需通过CISPR 25 Class 5的辐射发射和抗扰度测试。
- 环境适应性：传感器需能在-40°C到125°C、95%相对湿度、盐雾、振动等恶劣环境下正常工作。
- 可维护性：系统需支持通过诊断工具（如CANoe）进行在线升级和故障排查。
避坑指南：我曾经在一个项目中，只写了功能需求，没写非功能需求。结果样车测试时，发现TPMS在高温环境下频繁掉线。后来一查，是传感器模块的散热设计没做好。如果当初在需求里明确写了“环境适应性：125°C下连续工作8小时无故障”，这个问题在设计阶段就能发现。
3.3 需求追溯矩阵（RTM）建立方法
需求写完了，怎么保证每个需求都被实现了、被测试了？这就是需求追溯矩阵（RTM）的用武之地。RTM说白了就是一张表，把需求、设计、实现、测试全部串起来。
我建议的RTM结构如下：
| 需求ID | 需求描述 | 需求类型 | 来源 | 设计文档 | 测试用例 | 状态 |
|---|---|---|---|---|---|---|
| REQ-TPMS-001 | 系统需监测4个轮胎的气压，精度±10kPa | 功能需求 | GB 26134 | SDD-TPMS-001 | TC-TPMS-001 | 已实现 |
| REQ-TPMS-002 | 系统端到端延迟不超过2秒 | 非功能需求 | 系统架构文档 | SDD-TPMS-002 | TC-TPMS-002 | 已验证 |
| REQ-TPMS-003 | 系统需满足ISO 26262 ASIL B | 非功能需求 | 功能安全计划 | SDD-TPMS-003 | TC-TPMS-003 | 进行中 |
建立RTM的步骤，我一般这么走：
- 需求编号：每个需求分配一个唯一ID。我习惯用“REQ-TPMS-XXX”的格式，方便后续追溯。
- 需求分类：明确每个需求是功能需求还是非功能需求，以及它的优先级（比如P0、P1、P2）。
- 来源追溯：记录这个需求是从哪里来的。是法规要求？是客户需求？还是内部架构决定？这一步很重要，因为如果法规变了，你能快速定位到受影响的系统需求。
- 设计关联：把每个需求关联到对应的设计文档。比如“胎压精度±10kPa”这个需求，要关联到传感器选型报告、信号处理算法设计文档。
- 测试关联：把每个需求关联到对应的测试用例。没有测试用例的需求，就是没被验证的需求，说白了就是“假需求”。
- 状态跟踪：定期更新每个需求的状态，比如“已实现”、“已验证”、“已关闭”、“变更中”。
注意：RTM不是一次性建完就完事的。它需要在整个项目生命周期中持续维护。我见过最糟糕的情况是，项目快结束了才想起来建RTM，结果发现有一半的需求没被测试覆盖。那时候再补测试，成本就高了去了。
最后，我想说一句。需求分析这件事，看起来是“纸上谈兵”，但实际上是最能体现工程师功力的地方。你想想看，一个清晰的需求文档，能让硬件、软件、测试、生产、售后所有团队都朝着同一个方向努力。反之，一个模糊的需求，就是项目灾难的开始。
好，这一讲就到这里。下一讲，我们会聊聊TPMS的通信协议设计，包括RF链路预算和天线匹配。到时候我会分享一些我在实际项目中踩过的坑，保证让你少走弯路。