1. TCU系统概述：从整车架构到FTA的全局视角
大家好，我是老张。做TCU系统级FTA这些年，我最大的感触是——很多人一上来就画故障树，结果画到一半发现连TCU到底管什么都说不清楚。所以今天这第一讲，咱们先把地基打牢。
我个人习惯，做任何安全分析之前，先问自己三个问题：
- 这东西在车里到底扮演什么角色？
- 它必须干好哪些活？干不好会怎样？
- 我这次FTA要分析到什么程度？
嗯，这三个问题搞明白了，后面的故障树才不会跑偏。
1.1 TCU在汽车电子架构中的角色
先说说TCU的位置。现在的汽车电子架构，说白了就是一张网。网关是枢纽，域控制器是分舵主，而TCU呢？它是这辆车跟外界通信的唯一窗口。
你想想看，没有TCU，车就是一座孤岛。导航没法实时更新，远程控车想都别想，更别提OTA升级了。我在2018年做过一个项目，客户非要省成本把TCU砍掉，结果车卖出去三个月，用户投诉导航地图太旧——这就是典型的「省了小钱，丢了口碑」。
具体来说，TCU在架构里干三件事：
- 桥接内外网：一边连着车内的CAN/CANFD、以太网，一边连着4G/5G基站。它就是个翻译官，把车内信号转成云端能懂的协议。
- 数据中转站：车辆状态、故障码、驾驶行为……这些数据通过TCU上传到TSP平台。我记得有个项目，客户要求每10秒上传一次GPS轨迹，结果TCU的缓存设计没做好，数据丢包率高达30%——这就是典型的「功能定义没对齐」。
- 安全边界：TCU是黑客攻击的第一道防线。我建议所有做TCU的同行，一定要把「安全启动」和「安全通信」当成硬性指标，别等出了漏洞再补。
核心观点：TCU不是简单的「加个4G模块」，它是整车电子电气架构中「连接」与「安全」的交汇点。FTA分析时，这两个维度必须覆盖。
1.2 TCU核心功能与性能指标
功能这块，我习惯把它们分成三类：
1.2.1 通信类功能
- 蜂窝通信：4G/5G，这是基本功。注意，5G的URLLC（超低时延）特性对TCU的硬件要求很高，我见过不少方案在实验室跑得好，一上车就掉线——因为没考虑车规级振动对天线的影响。
- 短距通信：Wi-Fi、蓝牙、V2X。V2X这块水很深，DSRC和C-V2X的协议栈完全不同，选型时一定要看客户的目标市场。
- 定位服务：GPS/北斗/GLONASS。这里有个坑：多星座融合定位时，TCU的算力够不够？我有个项目就是算力不足，导致定位更新频率只有1Hz，完全满足不了L2+级自动驾驶的需求。
1.2.2 计算与存储类功能
- 数据预处理：原始数据量太大，直接上传不现实。TCU需要做滤波、压缩、特征提取。比如，碰撞事件触发时，TCU要能快速提取碰撞前5秒的CAN信号——这个「快速」到底多快？我建议定义在100ms以内。
- 本地存储：断网时数据不能丢。我记得有个项目，TCU的eMMC选的是消费级，结果在-30℃低温下直接罢工——从那以后，我所有项目都强制要求车规级存储。
1.2.3 安全与诊断类功能
- 安全启动：上电时校验签名，防止固件被篡改。
- 入侵检测：监控异常流量。比如，CAN总线突然出现大量0x123报文，那八成是有人在搞事情。
- 远程诊断：云端下发诊断请求，TCU转发给ECU。这个功能对FTA来说很关键——如果TCU转发错了诊断ID，可能导致ECU误操作。
性能指标方面，我列个表，大家参考：
| 指标项 | 典型值 | 说明 |
|---|---|---|
| 上行速率 | ≥50Mbps (4G) / ≥1Gbps (5G) | 取决于天线设计和信号强度 |
| 定位精度 | ≤2.5m (单点) / ≤1m (差分) | 多星座融合时注意算力 |
| 启动时间 | ≤3s (冷启动) / ≤1s (热启动) | 安全启动会额外增加0.5-1s |
| 数据存储 | ≥32GB | 建议eMMC 5.1以上，车规级 |
| 工作温度 | -40℃ ~ +85℃ | 注意散热设计，尤其是5G模块 |
个人经验：性能指标不是越高越好。我见过一个项目，客户要求5G峰值速率，结果TCU的散热成本翻了一倍，最后发现实际场景根本用不到——FTA分析时，一定要基于「实际使用场景」定义指标，别被纸面参数忽悠了。
1.3 TCU系统级FTA的目标与范围
好，到了最核心的部分。TCU系统级FTA，到底要分析什么？
我个人的定义是：找出所有可能导致TCU「无法完成核心功能」的故障模式，并量化其概率。
目标有三个层次：
- 识别单点故障：比如，电源芯片失效导致TCU掉电。这是最基础的。
- 识别共因故障：比如，软件bug导致所有通信协议栈同时崩溃。这个容易被忽略，我建议用CCA（共因分析）辅助。
- 量化系统可靠性：比如，TCU在10年生命周期内，因硬件故障导致通信中断的概率是多少？这个数字要能跟客户的安全目标对标。
范围怎么定？我一般画个边界：
- 包含：TCU硬件（PCB、芯片、天线）、基础软件（OS、协议栈）、中间件（通信管理、诊断管理）。
- 不包含：云端服务器、基站网络、车内其他ECU（除非TCU的故障会传播到它们）。
避坑指南：我曾经犯过一个错误——把「天线被遮挡」也纳入了FTA范围。结果分析了一堆「用户把车停在信号屏蔽车库」的场景，最后发现这些场景根本没法通过TCU设计来解决。记住，FTA只分析「TCU自身可控」的故障。外部环境因素，交给使用场景定义去处理。
最后说一句，FTA不是一次性工作。我习惯在项目初期做一次「粗粒度FTA」，识别出高风险区域；然后在详细设计阶段做「精粒度FTA」，把每个故障模式的概率算清楚。嗯，这个后面几章会详细讲。
这一章就到这里。下一章，咱们聊聊故障树的基本符号和建树规则——别觉得简单，很多人就是栽在基础符号用错上。