3. 功能安全概念（FSC）设计：从定义到安全机制分配
好，咱们进入功能安全概念设计这个环节。说实话，这是整个安全开发流程里最考验「系统思维」的一步。你 Hazard Analysis 做得再漂亮，如果 FSC 这一步没走对，后面全是白忙活。
我个人习惯把 FSC 比作「搭骨架」——你得先想清楚，这个系统到底靠什么来保证安全？是靠冗余？靠监控？还是靠降级？想清楚了，后面的技术安全概念（TSC）和软硬件实现才有方向。
3.1 功能安全概念（FSC）到底在定义什么？
先别急着翻标准。ISO 26262-3 里对 FSC 的描述其实挺抽象的。我用大白话翻译一下：FSC 就是告诉你，针对每一个安全目标，系统应该「做什么」来避免或控制危害。
它不关心具体用哪个芯片、写什么代码。它只关心「功能层面的安全策略」。举个例子：
- 安全目标：防止制动踏板信号丢失导致意外加速。
- FSC 给出的方案：系统应具备踏板信号合理性检查功能，当检测到信号异常时，应在 100ms 内进入跛行回家模式。
看到了吗？FSC 只说了「要检查」「要进入跛行模式」，至于怎么检查、用硬件还是软件实现，那是 TSC 的事。
核心要点：FSC 是连接「安全目标」和「技术实现」的桥梁。它把「要安全」翻译成了「怎么做才安全」。
3.2 功能安全需求（FSR）的导出——别想一口吃成胖子
FSR 的导出，说白了就是「把安全目标拆成可执行的功能需求」。我见过很多新手一上来就想写 FSR，结果写出来的东西要么太抽象，要么直接跳到实现细节。
这里我分享一个我自己用了多年的三步法：
- 第一步：识别安全相关功能——从安全目标出发，列出所有与之相关的系统功能。比如「制动信号采集」「车速计算」「故障诊断」。
- 第二步：定义故障响应行为——每个功能在发生故障时，系统应该怎么反应？是报警、降级还是停机？
- 第三步：分配 ASIL 等级——每个 FSR 继承其对应安全目标的 ASIL 等级。注意，如果多个安全目标映射到同一个 FSR，取最高等级。
举个例子，我之前做过一个 EPS（电动助力转向）项目，其中一个安全目标是「防止非预期的转向助力丢失」。导出的 FSR 长这样：
| FSR ID | 需求描述 | ASIL | 关联安全目标 |
|---|---|---|---|
| FSR-01 | 系统应持续监控扭矩传感器信号的有效性 | D | SG-01 |
| FSR-02 | 当检测到扭矩传感器故障时，系统应在 50ms 内切断助力输出 | D | SG-01 |
| FSR-03 | 系统应提供故障指示，通知驾驶员转向系统异常 | A | SG-01 |
我的经验：写 FSR 时，尽量用「系统应……」「当……时，系统应……」这种句式。别写「软件应……」「硬件应……」，那是 TSC 的事。保持 FSR 在功能层面，别往下跳。
3.3 安全机制（Safety Mechanism）的初步分配
FSR 写完了，接下来就是「怎么实现这些需求」的第一步——分配安全机制。注意，这里只是「初步分配」，不是最终设计。你只需要回答一个问题：针对每个 FSR，用哪种类型的安全机制来满足？
常见的几类安全机制，我列个表：
| 安全机制类型 | 典型做法 | 适用场景 |
|---|---|---|
| 故障检测 | 自检、回读、CRC、看门狗 | 单点故障、潜伏故障 |
| 故障响应 | 降级模式、安全状态切换 | 检测到故障后的行为 |
| 冗余 | 双通道、三取二 | 高 ASIL 等级、不可停机场景 |
| 故障避免 | 去耦合、物理隔离 | 共因失效、系统性失效 |
嗯，这里要注意一点：安全机制的分配不是拍脑袋。你得考虑 ASIL 等级、系统架构、成本、甚至量产可行性。我曾经在一个项目里，为了满足 ASIL D 的要求，给一个简单的传感器信号加了双通道冗余。结果后来发现，单通道加诊断也能满足，白白浪费了 BOM 成本。
避坑指南：安全机制不是越多越好。过多的安全机制会增加系统复杂度，反而引入新的失效模式。我见过一个项目，因为安全机制之间的交互没考虑清楚，导致系统在正常工况下误触发安全状态——这叫「安全过度」，同样危险。
3.4 FSC 设计的核心逻辑——一张图说清楚
说了这么多，咱们用一张图把 FSC 设计的核心逻辑串起来。这张图我每次做项目都会贴在白板上，提醒自己别跑偏。
3.5 文档编写的几个实用技巧
最后聊几句文档的事。FSC 文档写得好不好，直接决定了后续评审能不能顺利通过。我总结了几条经验：
- 每个 FSR 都要可验证——你写「系统应快速响应」，评审老师一定会问「多快？」。改成「系统应在 100ms 内响应」，这才叫可验证。
- 安全机制要有关联性——别把安全机制写成孤立的列表。每个安全机制要明确它覆盖了哪个 FSR，以及它与其他机制的交互关系。
- ASIL 分解要留证据——如果你把 ASIL D 的需求分解成 ASIL B(D) + ASIL B(D)，一定要在文档里说明为什么这样分解是合理的。我见过太多项目因为分解理由不充分，被评审打回来重做。
一个小技巧：写 FSC 文档时，我习惯在每一条 FSR 后面加一列「验证方法」。比如「测试」「评审」「分析」。这样评审老师一眼就能看出你的需求是不是可验证的，省得来回扯皮。
好了，FSC 设计这部分就聊到这儿。说白了，它就是把你从 HARA 得到的「安全目标」翻译成「系统该怎么做」的过程。别想得太复杂，也别想得太简单。把握好「功能层面」这个度，你的 FSC 就成功了一半。