2. 功能安全基础概念：危害、风险、安全目标、FSC、TSC、ASIL
各位工程师朋友，欢迎来到第二章。这一章我们聊聊功能安全里最基础、也最核心的几个概念。说实话，这些术语你肯定在文档里见过无数次，但真正把它们串起来、用对地方，还是需要一点功夫的。
我个人习惯把这一章叫做“功能安全的通用语言”。不管你是做系统、硬件还是软件，大家得用同一套词儿沟通。否则，你说“风险”，我说“危害”，项目还没开始就乱了。
2.1 危害（Hazard）与风险（Risk）
先搞清楚这两个词。很多人混着用，其实它们有本质区别。
| 术语 | 定义 | 打个比方 |
|---|---|---|
| 危害（Hazard） | 由系统功能异常导致的潜在伤害源 | 一把没保险的刀放在桌上 |
| 风险（Risk） | 危害发生的概率 × 伤害的严重程度 | 这把刀会不会割到人？概率多大？ |
危害是客观存在的。比如，电动车突然意外加速，这就是一个危害。它就在那里，不管你有没有意识到。
风险则是一个评估值。同样是“意外加速”，在高速公路上和在停车场里，风险完全不一样。你想想看，高速上发生事故的严重程度（Severity）高得多，对吧？
核心公式：
风险 = 危害的严重程度 × 暴露概率 × 可控性
ISO 26262 就是通过这个公式，把模糊的“危险”变成可量化的“风险等级”。
我在项目中遇到过一位同事，把“刹车失灵”直接定义为ASIL D。我说等等，你得先分析：是哪种失灵？是完全没刹车，还是制动力不足？是在什么场景下？不同的危害场景，风险等级可能差很多。
2.2 安全目标（Safety Goal）
安全目标，说白了就是“我们要避免什么”。它是从危害分析里提炼出来的顶层安全要求。
举个例子：
- 危害：车辆在行驶中非预期加速
- 安全目标：防止车辆非预期加速导致人员伤害
每个安全目标都会分配一个 ASIL 等级（A、B、C、D）。这个等级决定了后续开发工作的“用力程度”。
⚠️ 避坑指南：
我曾经见过一个项目，安全目标写得太笼统。比如“确保系统安全”。这等于没写。安全目标必须具体到“什么事件”、“什么后果”、“什么等级”。否则，后续的验证工作根本没法做。
2.3 ASIL 等级定义
ASIL（Automotive Safety Integrity Level）是汽车安全完整性等级。它分四个级别：A、B、C、D。D 是最严格的。
ASIL 的确定，靠三个参数：
- 严重度（Severity, S）： 伤害有多重？S0（无伤害）到 S3（致命）
- 暴露概率（Exposure, E）： 这个场景发生的频率？E0（几乎不）到 E4（非常高）
- 可控性（Controllability, C）： 驾驶员能避免吗？C0（完全可控）到 C3（几乎不可控）
| ASIL 等级 | 典型场景 | 开发严格度 |
|---|---|---|
| ASIL A | 轻微不适，如空调故障 | 较低 |
| ASIL B | 可恢复的伤害，如车窗夹手 | 中等 |
| ASIL C | 严重但非致命，如转向助力失效 | 高 |
| ASIL D | 致命伤害，如刹车完全失效 | 最高 |
嗯，这里要注意：QM（Quality Management）不算 ASIL 等级。它表示“没有安全相关要求”，按普通质量管理做就行。
2.4 功能安全概念（FSC）
有了安全目标，接下来就是怎么实现它。这就是 功能安全概念（Functional Safety Concept, FSC） 的活儿。
FSC 是系统层面的安全措施。它回答一个问题：“系统要做什么来保证安全？”
FSC 通常包括：
- 故障检测机制（比如：监控传感器是否失效）
- 故障响应措施（比如：检测到失效后，进入安全状态）
- 驾驶员警告（比如：点亮故障灯）
我个人习惯，在做 FSC 时，先画一张功能架构图。把每个组件、每个信号、每个故障模式都标出来。这样，安全措施才能落到具体功能上。
💡 小技巧：
FSC 不要写得太细。它是给系统架构师看的，不是给硬件工程师看的。太细了反而限制后续设计。我见过有人把 FSC 写成软件需求，结果硬件那边根本没法用。
2.5 技术安全概念（TSC）
技术安全概念（Technical Safety Concept, TSC） 是 FSC 的细化。它把系统级的安全要求，分解到硬件和软件层面。
举个例子：
- FSC 要求： 当制动踏板传感器失效时，系统应在 100ms 内进入安全状态。
- TSC 分解：
- 硬件：选用双通道冗余传感器，诊断覆盖率 ≥ 99%
- 软件：实现传感器信号交叉校验算法，诊断周期 10ms
TSC 是真正指导开发的技术文档。硬件工程师看 TSC 知道要选什么料，软件工程师看 TSC 知道要写什么逻辑。
2.6 知识体系总览
下面这张图，是我自己总结的。它把这一章的核心概念串在了一起。你保存下来，以后做项目时随时翻出来看看。
2.7 避坑总结
最后，分享几个我踩过的坑：
- 别把危害和风险搞混。 危害是“有没有”，风险是“有多大”。做 HARA（危害分析与风险评估）时，先列危害，再评风险。
- 安全目标要可验证。 我曾经写过一个安全目标：“系统应足够安全”。结果测试团队问我：怎么算“足够”？后来改成“当传感器A失效时，系统应在50ms内进入降级模式”，这才可测。
- FSC 和 TSC 的边界要清晰。 FSC 是“系统要做什么”，TSC 是“硬件/软件怎么做”。别混在一起写，否则文档又臭又长，还没人看得懂。
- ASIL 分解要谨慎。 一个 ASIL D 的安全目标，可以分解成 ASIL C + ASIL B 的冗余路径。但分解必须有依据，不能为了省成本乱拆。
好了，这一章就到这里。这些概念是后续所有工作的基础。你花时间把它们吃透，后面做系统设计、硬件开发、软件实现，都会顺很多。