3、功能安全概念（FSC）：安全目标的定义、功能安全需求的导出、安全机制的概念设计
好，咱们进入功能安全概念阶段。说白了，FSC 就是把上一阶段做的危害分析，落地成具体的技术要求。我个人习惯把这一步叫做「从纸上谈兵到真刀真枪」的转折点。你想想看，HARA 分析完了，一堆 ASIL 等级和危害事件摆在那，接下来怎么办？
嗯，这里就要引出三个核心动作：定义安全目标、导出功能安全需求、设计安全机制。咱们一个一个来拆。
3.1 安全目标（SG）的定义
安全目标，英文叫 Safety Goal。它是对每个危害事件提出的最高层级安全要求。我遇到过不少新手，上来就写「TCU 不能失效」——这太笼统了，没法用。
一个合格的安全目标，必须满足三个条件：
- 可验证：能不能通过测试或分析来确认它被满足了？
- 可追溯：能不能追溯到具体的危害事件？
- 有 ASIL 等级：继承自 HARA 分析结果。
举个例子，对于 TCU 的「非预期换挡」这个危害，安全目标可以这样写：
SG-01：TCU 应防止在车速大于 5 km/h 时，从 D 挡非预期切换至 R 挡。
ASIL：C
继承自危害事件：HE-03（高速行驶中误挂倒挡）
这里要注意，安全目标描述的是「系统要避免什么」，而不是「系统要做什么」。前者是安全目标，后者是功能需求。我曾经在一个项目里看到有人把「TCU 每 10ms 采集一次车速」写进了安全目标——这其实是功能安全需求，不是目标本身。
我的小技巧：写安全目标时，试着用「防止……发生」或「避免……出现」来开头。如果写成了「实现……功能」，那大概率是跑偏了。
3.2 功能安全需求（FSR）的导出
安全目标定好了，接下来就是导出功能安全需求。这一步，说白了就是把「防止什么」翻译成「怎么做」。
功能安全需求，英文叫 Functional Safety Requirement。它和安全目标最大的区别在于：FSR 是具体的技术措施，而 SG 是抽象的安全主张。
我习惯用「分解法」来做这件事。举个例子，针对上面那个 SG-01，我会问自己几个问题：
- 怎么检测到「非预期换挡」？——需要挡位传感器和车速信号。
- 检测到了怎么办？——需要执行安全动作。
- 安全动作是什么？——禁止换挡，或者退回空挡。
这样一问，FSR 就出来了：
| FSR 编号 | 描述 | ASIL | 关联 SG |
|---|---|---|---|
| FSR-01 | TCU 应通过两路独立传感器（主/副）采集挡位信号，并在软件中进行交叉比较。 | C | SG-01 |
| FSR-02 | 当检测到挡位信号不一致超过 50ms 时，TCU 应禁止执行换挡指令。 | C | SG-01 |
| FSR-03 | TCU 应通过车速传感器（冗余设计）确认当前车速，若车速 > 5 km/h 且收到 R 挡请求，应拒绝执行。 | C | SG-01 |
你看，一个安全目标，可以分解出多个功能安全需求。每个 FSR 都继承了 SG 的 ASIL 等级。这里有个坑：不要试图用一个 FSR 覆盖所有情况。我见过有人写「TCU 应确保换挡安全」——这种需求没法验证，也没法设计测试用例。
注意：FSR 的 ASIL 等级可以向下分解。比如 SG 是 ASIL C，但某个 FSR 如果通过「充分独立」的冗余设计实现，可以降级到 ASIL B。但这事需要做安全分析来证明，不能拍脑袋。
3.3 安全机制的概念设计
安全机制，就是具体怎么实现 FSR 的技术方案。到了这一步，咱们要开始想「电路怎么搭、软件怎么写」了。
我个人把安全机制分成三类：
- 检测机制：发现问题。比如看门狗、CRC 校验、信号范围检查。
- 响应机制：处理问题。比如故障降级、安全状态切换。
- 避免机制：预防问题。比如冗余设计、多样化实现。
拿 TCU 的挡位信号举例。针对 FSR-01（双路传感器交叉比较），安全机制可以这样设计：
安全机制 SM-01：挡位信号冗余与交叉比较
- 检测：主传感器（模拟信号）和副传感器（数字信号）分别采集挡位位置。
- 比较：软件每 10ms 读取两路信号，计算差值。
- 阈值：若差值超过 5% 满量程，且持续 3 个周期，则判定为故障。
- 响应：置位故障标志，禁止换挡，点亮仪表盘故障灯。
这里有个经验之谈：安全机制不是越多越好。我早期做过一个项目，给 TCU 加了 7 层安全机制，结果系统响应时间从 50ms 变成了 200ms，反而引入了新的风险。你想想看，安全机制本身也是要消耗资源的，而且可能互相干扰。
所以，概念设计阶段，我建议你画一张「安全机制矩阵图」：
| FSR | 检测机制 | 响应机制 | 诊断覆盖率 | 故障容错时间 |
|---|---|---|---|---|
| FSR-01 | 双路传感器交叉比较 | 禁止换挡 | 99% | 100ms |
| FSR-02 | 看门狗监控主芯片 | 系统复位 | 95% | 200ms |
| FSR-03 | 车速信号合理性检查 | 使用备用车速值 | 90% | 150ms |
这张表能帮你一眼看出：哪个 FSR 的覆盖率不够？哪个故障容错时间太紧？我曾经在一个 TCU 项目里，就是因为没画这个矩阵，结果 FSR-02 的看门狗超时时间设成了 500ms，而系统要求的故障容错时间只有 200ms——这要是上了车，后果不堪设想。
避坑指南：概念设计阶段，一定要和系统工程师、软件工程师、硬件工程师坐在一起过一遍。安全机制不是功能安全工程师一个人的事。我吃过这个亏——自己闷头设计了一套机制，结果硬件说「这个传感器我没地方放」，软件说「这个算法我跑不动」……嗯，从那以后，我每次做概念设计都拉上大家一起评审。
3.4 小结
好了，咱们捋一下功能安全概念阶段的核心产出：
- 安全目标：每个危害事件对应一个 SG，描述要避免什么。
- 功能安全需求：每个 SG 分解成多个 FSR，描述要怎么做。
- 安全机制：每个 FSR 对应一个或多个 SM，描述具体怎么实现。
这三者之间是层层递进的关系。你从 SG 出发，导出 FSR，再设计 SM，最后形成一份完整的 功能安全概念文档。这份文档，就是后续系统设计、硬件设计、软件设计的「宪法」——所有技术决策都要以它为准。
下一章，咱们会聊怎么把 FSC 落地到系统架构设计中。到时候我会拿一个真实的 TCU 项目案例，带大家走一遍完整的流程。今天就先到这儿，有问题随时问我。