3. 基于AUTOSAR的TPMS系统需求分析
好，咱们进入第三章。这一章我打算聊聊TPMS系统的需求分析。说实话，很多工程师一上来就画架构、写代码，结果做到一半发现需求没理清，回头再改，那叫一个痛苦。我个人习惯是，先把需求掰开了揉碎了，再动手。
TPMS的需求，我一般分成三大块：功能需求、安全需求（ISO 26262）、通信需求。这三块缺一不可。你想想看，功能需求决定了车能不能用，安全需求决定了人会不会出事，通信需求决定了数据能不能传得通。
3.1 功能需求：TPMS到底要干什么
功能需求是最直观的。说白了，就是回答一个问题：这个系统要帮驾驶员做什么？
我记得有一次跟一个刚入行的同事聊，他说TPMS不就是测个胎压吗？我说，你太小看它了。一个完整的TPMS功能需求，至少包括下面这些：
- 胎压监测：实时或周期性采集轮胎气压值，精度要求通常在±0.1 bar以内。
- 胎温监测：轮胎内部温度，用于辅助判断轮胎状态。
- 低压报警：当胎压低于设定阈值（比如1.7 bar）时，触发报警。
- 高压报警：胎压过高时也要报警，防止爆胎。
- 快速漏气报警：短时间内气压下降超过一定速率（比如0.2 bar/秒），立刻报警。
- 传感器电池低电量报警：传感器内部电池快没电了，得提醒驾驶员更换。
- 传感器ID自学习：更换轮胎或传感器后，系统能自动识别新传感器的ID。
这里有个坑：很多项目只关注了低压报警，忽略了快速漏气报警。我曾经在一个项目中吃过这个亏——轮胎被扎了，气压缓慢下降，低压报警是触发了，但驾驶员没在意。结果后来扎了个大钉子，气压瞬间掉下来，系统却没反应。嗯，从那以后，我要求所有TPMS项目必须加上快速漏气检测逻辑。
在AUTOSAR架构下，这些功能需求会被映射到具体的SWC（Software Component）上。比如：
- SensorDataSWC：负责接收传感器原始数据，解析胎压、胎温、电池电压。
- AlarmSWC：负责报警逻辑判断，输出报警信号到仪表盘。
- LearnSWC：负责传感器ID自学习功能。
3.2 安全需求：ISO 26262怎么说
安全需求这块，是TPMS系统里最容易被忽视，但也是最要命的部分。TPMS属于安全相关系统，按照ISO 26262标准，它通常被定义为ASIL B等级。为什么是B？因为胎压不准不会直接导致车辆失控（那是ASIL C/D的事），但漏报或误报会间接引发事故。
我个人习惯把安全需求分成两类：系统级安全需求和软件级安全需求。
3.2.1 系统级安全需求
- 故障检测覆盖率：系统必须能检测到传感器失效、通信中断、电池耗尽等故障，覆盖率要求≥90%。
- 故障容错时间间隔（FTTI）：从故障发生到系统做出反应，时间不能超过500ms。你想想看，如果轮胎爆了，系统要等2秒才报警，那黄花菜都凉了。
- 安全状态：当检测到不可恢复的故障时，系统应进入安全状态，比如点亮报警灯并禁用某些功能。
3.2.2 软件级安全需求
- 数据完整性：传感器数据在传输过程中不能被篡改或丢失。AUTOSAR里通常用CRC校验来保证。
- 时序监控：每个SWC的执行时间、通信周期都要被监控，防止死锁或任务超时。
- 内存保护：关键数据（比如报警阈值）不能被意外修改。AUTOSAR的Memory Partitioning机制就是干这个的。
注意：ISO 26262要求做安全分析，比如FMEA（失效模式与影响分析）或FTA（故障树分析）。我建议在需求阶段就做，别等到开发完了再补。我曾经见过一个项目，开发完了才发现某个故障模式没覆盖，结果整个软件架构要重改，那叫一个惨。
3.3 通信需求：数据怎么传
通信需求，说白了就是TPMS传感器和ECU之间怎么说话。TPMS的通信方式主要有两种：RF射频通信和LF低频通信。
3.3.1 RF射频通信
这是TPMS的主通信通道。传感器通过RF发射器，把胎压、胎温、电池电压、传感器ID等信息，以无线方式发送给接收器（通常是BCM或独立的TPMS ECU）。
通信参数一般如下：
| 参数 | 典型值 | 说明 |
|---|---|---|
| 载波频率 | 433.92 MHz / 315 MHz | 不同地区法规不同 |
| 调制方式 | ASK / FSK | ASK简单，FSK抗干扰好 |
| 数据速率 | 9.6 kbps ~ 19.2 kbps | 够用就行，太快了功耗高 |
| 发射周期 | 静止时60秒，运动时3~10秒 | 省电策略 |
| 编码方式 | Manchester / NRZ | Manchester自带时钟同步 |
在AUTOSAR架构里，RF通信通常由CAN或LIN总线来承载。接收器收到RF数据后，会通过CAN/LIN把数据转发给TPMS的SWC。我个人建议用CAN，因为CAN的实时性和可靠性更好。LIN虽然便宜，但带宽低，容易丢包。
3.3.2 LF低频通信
LF通信主要用于传感器激活和ID写入。比如，当车辆进入维修模式时，诊断工具通过LF天线发送激活信号，唤醒传感器并写入新的ID。
LF通信的参数：
- 频率：125 kHz
- 通信距离：通常小于1米
- 用途：激活、ID写入、触发强制发射
小技巧：LF通信的功耗很低，但距离短。我在项目中遇到过一个问题——LF天线安装位置不对，导致维修时死活激活不了传感器。后来我把天线挪到了轮拱附近，问题就解决了。所以，天线布局一定要在需求阶段就考虑进去。
3.4 需求如何映射到AUTOSAR架构
好，需求分析完了，怎么落地到AUTOSAR里？我一般会做一张需求-组件映射表，把每个需求对应到具体的SWC、RTE、BSW模块上。
举个例子：
| 需求ID | 需求描述 | 映射到AUTOSAR组件 | 备注 |
|---|---|---|---|
| FUNC-001 | 胎压监测，精度±0.1 bar | SensorDataSWC | 数据解析逻辑 |
| SAFE-002 | 故障检测覆盖率≥90% | WdgM（看门狗管理） | 监控SWC执行状态 |
| COMM-003 | RF数据通过CAN总线传输 | CanIf / CanTp | 配置CAN报文ID和周期 |
这张表看起来简单，但做起来很费功夫。我建议在需求评审阶段，就让系统工程师、软件工程师、测试工程师坐在一起，逐条过一遍。别怕花时间，前期多花1小时，后期能省10小时。
3.5 避坑指南：我踩过的几个坑
最后，分享几个我亲身踩过的坑，希望能帮你少走弯路：
- 忽略RF干扰：有一次在测试场，TPMS老是误报，查了半天发现是附近有个基站干扰了433 MHz频段。后来我们在需求里加了抗干扰策略，比如跳频或重传机制。
- 安全需求写得太虚：很多需求文档里写「系统应具备高可靠性」，这种话等于没说。要写具体，比如「系统在-40°C到+125°C范围内，误报率小于0.1%」。
- 通信周期没对齐：RF发射周期是10秒，CAN报文周期是100ms，结果导致数据不同步。后来我们在RTE配置里加了数据保鲜机制，超时的数据直接丢弃。
嗯，这一章的内容差不多就这些。需求分析是TPMS系统的基础，基础打牢了，后面的架构设计、代码实现才能顺风顺水。下一章，我会聊聊TPMS的软件架构设计，包括SWC的划分和RTE的配置，到时候见。