4. 功能安全概念(FSC)：安全目标定义、功能安全概念导出、安全机制分配
好，我们进入功能安全概念阶段。说实话，这是整个安全开发中最需要「动脑子」的环节。前面你做的HARA分析，说白了就是搞清楚「哪里会出问题」。而FSC要回答的是——「我们怎么保证出了问题也不出事」。
我个人习惯把FSC比作「给系统上保险」。你得先知道保什么（安全目标），再设计怎么保（功能安全概念），最后分配谁来保（安全机制分配）。这三步走完，你的安全架构才算有了骨架。
4.1 安全目标定义
安全目标（Safety Goal, SG）是从HARA的每个危害事件中提炼出来的顶层安全要求。每个危害事件至少对应一个安全目标。
举个例子，我在做网关项目时，HARA分析发现「CAN总线被攻击导致错误报文转发」这个危害，对应的安全目标就是：网关必须防止未授权的报文跨域转发。
定义安全目标时，有几个关键点要注意：
- 每个SG只描述一个危害的避免，不要合并多个危害
- SG必须可验证，不能写「系统要足够安全」这种废话
- SG要分配ASIL等级，直接继承自对应的危害事件
- SG要定义FTTI（Fault Tolerant Time Interval），即从故障发生到系统进入安全状态的最大允许时间
安全目标示例（车载网关）
| SG编号 | 描述 | ASIL | FTTI | 安全状态 |
|---|---|---|---|---|
| SG-01 | 网关必须防止未授权的CAN报文跨域转发 | ASIL D | 10 ms | 阻断转发，记录日志 |
| SG-02 | 网关必须检测并报告CAN总线通信中断 | ASIL B | 50 ms | 切换到冗余通道 |
| SG-03 | 网关固件更新必须验证签名，防止篡改 | ASIL C | N/A | 拒绝更新，保持当前版本 |
这里有个坑——FTTI怎么定？我曾经在一个项目中，把FTTI拍脑袋设成100ms，结果硬件团队说「你疯了吧，我们CAN收发器响应就要80ms」。所以FTTI一定要和硬件、软件团队对齐，别闭门造车。
4.2 功能安全概念导出
功能安全概念（Functional Safety Concept, FSC）是把安全目标转化为系统层面的功能要求。说白了，就是告诉系统「你要做什么来保证安全」。
FSC的导出过程，我一般分三步走：
- 分解安全目标：把每个SG拆成若干个安全要求（Safety Requirement, SR）
- 分配SR到系统元素：每个SR要明确由哪个硬件或软件模块负责
- 定义安全机制：每个SR背后要有具体的实现方案
举个例子，SG-01「防止未授权报文跨域转发」可以分解为：
- SR-01.1：网关必须实现基于ID的报文过滤（分配给：路由引擎模块）
- SR-01.2：网关必须验证报文来源域是否合法（分配给：安全认证模块）
- SR-01.3：网关必须记录所有被拒绝的转发请求（分配给：日志模块）
我的经验：FSC阶段最容易犯的错误是「过度设计」。你想想看，如果每个SR都搞三重冗余，成本直接爆炸。我建议先做最小可行安全方案，然后通过安全分析（比如FTA、FMEA）来识别薄弱点，再逐步加固。
4.3 安全机制分配
安全机制分配，就是把FSC中定义的SR落实到具体的实现技术上。这是架构师最需要发挥经验的地方。
常见的车载网关安全机制包括：
| 安全机制 | 适用场景 | 典型实现 | ASIL等级 |
|---|---|---|---|
| 报文过滤 | 防止非法报文跨域 | 硬件防火墙 + 软件白名单 | ASIL D |
| 心跳监控 | 检测通信中断 | 定时器 + 看门狗 | ASIL B |
| CRC校验 | 检测数据篡改 | 硬件CRC引擎 | ASIL C |
| 冗余通道 | 主通道失效时接管 | 双CAN控制器 + 切换逻辑 | ASIL D |
| 安全启动 | 防止固件被篡改 | 签名验证 + 信任链 | ASIL C |
分配安全机制时，要特别注意独立性。比如，你不能把报文过滤和日志记录放在同一个软件模块里——万一这个模块挂了，两个功能同时失效。我曾经见过一个项目，把安全监控和业务逻辑混在一起，结果安全监控被业务逻辑的bug带崩了，整个网关直接「裸奔」。
避坑指南：安全机制分配后，一定要做「安全机制覆盖度检查」。我习惯用一张矩阵表，横轴是安全目标，纵轴是安全机制，每个格子打勾确认覆盖。如果发现某个安全目标没有对应的安全机制，或者某个安全机制没有对应的安全目标，那就是设计缺陷。
4.4 FSC阶段的知识体系
下面这张图，是我自己总结的FSC阶段核心逻辑。你可以把它当作检查清单来用。
嗯，到这里FSC的核心内容就讲完了。记住一句话：安全目标定方向，功能安全概念定方案，安全机制定实现。这三层缺一不可。