4. 功能安全目标定义：安全目标(SG)制定、功能安全概念(FSC)、技术安全概念(TSC)
好，咱们进入第四讲。这一讲非常关键，说白了就是要把「安全」这件事从抽象的想法，一步步变成可执行的技术方案。我见过不少项目，前期安全分析做得轰轰烈烈，到了定义阶段就开始含糊了——结果后面开发、测试全乱套。所以这一讲，咱们把 SG、FSC、TSC 这三个东西彻底捋清楚。
4.1 安全目标（SG）制定——从危害到目标
上一讲我们做了 HARA，得到了 ASIL 等级和危害事件。那接下来呢？你得给每个危害事件定一个「安全目标」。
安全目标（Safety Goal, SG），就是最高层级的安全要求。它描述的是：「系统必须避免什么情况发生」。注意，是「避免」，不是「实现」。
举个例子，我在一个 400V 逆变器项目里，识别出一个危害：直流母线高压意外放电到外壳。那对应的安全目标就是：
SG-01：在车辆运行过程中，逆变器外壳对地电压不得超过 60V DC（ASIL C）。
写 SG 有几个要点，我总结一下：
- 每个危害事件至少对应一个 SG，但一个 SG 可以覆盖多个危害
- SG 要可验证——你不能写「系统要足够安全」，得写具体数值
- SG 要分配 ASIL 等级，直接继承自 HARA 的结果
- SG 要有 FTTI（故障容错时间间隔），比如「故障发生后 100ms 内必须进入安全状态」
我个人习惯，在 SG 定义阶段就会把 FTTI 和安全状态一起写进去。这样后面做 FSC 和 TSC 时，心里就有底了。
| SG ID | 安全目标描述 | ASIL | FTTI | 安全状态 |
|---|---|---|---|---|
| SG-01 | 避免直流母线高压意外放电到外壳 | C | 100 ms | 断开高压接触器，泄放母线电压 |
| SG-02 | 避免逆变器输出过流导致电机失控 | B | 50 ms | 关断功率管，进入主动短路 |
| SG-03 | 避免温度过高引发热失控 | B | 200 ms | 降功率运行，必要时停机 |
注意：SG 是最高层级的要求，不要在这里写具体实现。比如「用光耦隔离」这种话，那是后面 TSC 的事。SG 只关心「要避免什么」，不关心「怎么避免」。
4.2 功能安全概念（FSC）——谁来做什么
SG 定好了，接下来就是功能安全概念（Functional Safety Concept, FSC）。FSC 回答的问题是：系统通过什么功能来满足 SG？
说白了，FSC 就是把 SG 分解成一个个「安全功能」。每个安全功能要明确：
- 由哪个系统元素执行（比如 MCU、隔离驱动、接触器）
- 在什么条件下触发
- 输出什么动作
- 分配到什么 ASIL 等级
我举个例子。还是上面 SG-01（避免高压放电到外壳），它的 FSC 可以分解成这样：
FSC-01.1：绝缘监测功能（由绝缘监测单元执行）——当检测到绝缘电阻低于 500kΩ 时，在 50ms 内发出故障信号。
FSC-01.2：高压泄放功能（由主动泄放电路执行）——接收到故障信号后，在 50ms 内将母线电压泄放到 60V 以下。
FSC-01.3：接触器断开功能（由 BMS 或主控执行）——接收到故障信号后，在 20ms 内断开高压接触器。
你看，每个 FSC 都指向一个具体的执行者。而且 FSC 之间是有时序关系的——绝缘监测先发现故障，然后接触器断开，同时泄放电路工作。这个时序关系，在 FSC 阶段就要画清楚。
我记得有一次做项目，FSC 阶段没把时序理清楚，结果测试时发现：接触器都断开了，泄放电路还没启动，母线电压在那挂着。嗯，后来加了个时序约束，才把问题解决。
FSC 的输出通常包括：
- 安全功能列表（每个功能对应一个 SG）
- 功能分配矩阵（哪个功能由哪个组件执行）
- 安全状态定义（正常、降级、安全状态）
- 故障响应时间链（从检测到动作的总时间）
4.3 技术安全概念（TSC）——具体怎么干
FSC 是「谁来做什么」，TSC 就是「具体怎么干」。技术安全概念（Technical Safety Concept, TSC）把 FSC 中的每个安全功能，进一步细化到硬件和软件的具体实现。
你想想看，FSC 说「绝缘监测功能要检测绝缘电阻」，但怎么检测？用交流注入法还是直流偏置法？采样频率多少？阈值怎么设？这些就是 TSC 要回答的。
我拿 FSC-01.1（绝缘监测功能）来展开 TSC：
TSC-01.1.1：采用交流注入法，注入频率 10Hz，幅值 5V。通过采样电阻两端的电压计算绝缘电阻值。
TSC-01.1.2：采样周期 10ms，采用滑动窗口滤波（窗口长度 5 个采样点）。
TSC-01.1.3：当绝缘电阻低于 500kΩ 持续 30ms 时，判定为故障。
TSC-01.1.4：故障信号通过硬件引脚（GPIO）直接输出到主控，不经过软件协议栈，减少延迟。
你看，TSC 已经具体到「用什么方法」「采样周期多少」「滤波怎么搞」「信号怎么传」了。这些细节，在 FSC 阶段是不需要写的。
TSC 还有一个重要任务：定义安全机制。安全机制就是用来检测故障、防止故障传播的手段。比如：
- 诊断机制：比如 ADC 自检、RAM 校验、看门狗
- 冗余机制：比如双通道比较、三取二表决
- 故障响应机制：比如进入安全状态、降级运行
我的经验：写 TSC 时，一定要考虑「故障覆盖率」。比如你用一个 ADC 采样绝缘电阻，那 ADC 本身会不会坏？所以 TSC 里要加上「ADC 自检」这个安全机制。我曾经在一个项目里漏了这一步，结果 ADC 漂移了，绝缘监测一直报假故障，整车直接趴窝。后来加了个参考电压源做自检，才算搞定。
4.4 从 SG 到 FSC 到 TSC 的映射关系
这三个概念不是孤立的，它们是一层一层往下分解的。我画个表格给你看：
| 层级 | 抽象程度 | 关注点 | 输出物 |
|---|---|---|---|
| SG | 最高 | 避免什么危害 | 安全目标列表（含 ASIL、FTTI） |
| FSC | 中等 | 谁做什么功能 | 安全功能列表、功能分配矩阵 |
| TSC | 最低 | 具体怎么实现 | 技术方案、安全机制、接口定义 |
映射关系是这样的：
- 一个 SG 可以分解成多个 FSC
- 一个 FSC 可以分解成多个 TSC
- 每个 TSC 必须能追溯到它对应的 FSC 和 SG
这个追溯性很重要。ISO 26262 审核时，审核员会随机抽一个 SG，然后问：「你怎么证明这个 SG 被满足了？」你得能拿出 FSC 和 TSC 的文档链，一路追下去。追不上？那就不符合。
4.5 避坑指南
最后，我分享几个实际项目中踩过的坑：
坑1：SG 写得太笼统。 比如「系统要安全」——这等于没写。SG 必须有量化指标，比如电压阈值、时间要求。
坑2：FSC 和 TSC 混在一起写。 我见过有人把「用 I2C 通信」直接写在 FSC 里。FSC 只关心「谁和谁通信」，不关心「用什么协议」。I2C 是 TSC 的事。
坑3：忘了分配 ASIL 等级。 每个 FSC 和 TSC 都要继承 SG 的 ASIL 等级。如果 SG 是 ASIL C，那它分解出来的 FSC 和 TSC 至少也是 ASIL C（除非有安全分解）。
坑4：时序没对齐。 比如 FSC 要求 100ms 内进入安全状态，但 TSC 里每个安全机制加起来要 150ms。那这个 TSC 就不满足 FSC 的要求。
我曾经在一个项目里，FSC 阶段没仔细算时序，结果到了 TSC 阶段发现：绝缘监测要 50ms，接触器断开要 30ms，泄放要 50ms，加起来 130ms，超过了 SG 要求的 100ms。最后只能优化泄放电路，把时间压到 20ms。嗯，如果 FSC 阶段就做时序预算，后面就不用这么折腾了。
好，这一讲就到这里。SG、FSC、TSC 这三个概念，是功能安全落地的核心骨架。下一讲，我们会进入硬件设计阶段，聊聊怎么把 TSC 变成真正的电路和代码。