3、系统级安全设计：危害分析与风险评估(HARA)、安全目标定义、功能安全概念(FSC)
好，咱们进入系统级安全设计的核心环节。说实话，很多工程师一上来就写代码，结果做到一半发现安全目标没定清楚，回头改架构，那叫一个痛苦。我个人习惯是，在项目启动阶段，先把HARA、安全目标和FSC这三板斧抡明白。
说白了，系统级安全设计就是回答三个问题：车会不会出危险？出了危险我们能不能接受？怎么从设计上避免或减轻这个危险？
3.1 危害分析与风险评估（HARA）
HARA，全称Hazard Analysis and Risk Assessment。你想想看，一个防抱死系统，如果它在关键时刻失效了，会发生什么？车轮抱死、车辆侧滑、制动距离变长……这些都是潜在的危害。
HARA的目的，就是把这些潜在的危害一个个揪出来，然后评估它们的风险等级。我参与过一个项目，团队一开始只关注了“制动失效”这种大故障，结果忽略了“轮速传感器信号间歇性丢失”这种小毛病。嗯，后来在测试阶段，这个问题差点让项目延期。
3.1.1 危害识别
这一步，我们要列出所有可能的系统级危害。怎么找？从功能出发，反向思考。
- 功能失效：比如ABS完全没反应，制动踏板踩下去直接抱死。
- 功能异常：比如ABS在不该介入的时候突然介入，导致制动踏板抖动异常。
- 功能降级：比如部分轮速传感器失效，ABS进入降级模式，制动性能下降。
我记得有一次，我们分析一个线控制动系统，发现“制动踏板位置传感器失效”会导致系统误判驾驶员意图。这个危害一开始被低估了，后来重新评估才发现，它可能引发非预期的急加速或急减速。
3.1.2 风险评估（ASIL等级确定）
ISO 26262里，风险评估主要看三个维度：严重度（S）、暴露概率（E）、可控性（C）。三者组合，得出ASIL等级（A、B、C、D）。
| 维度 | 等级 | 描述 |
|---|---|---|
| 严重度（S） | S0 - S3 | S0：无伤害；S1：轻伤；S2：重伤；S3：致命伤 |
| 暴露概率（E） | E0 - E4 | E0：几乎不暴露；E4：每次驾驶都暴露 |
| 可控性（C） | C0 - C3 | C0：完全可控；C3：几乎不可控 |
举个例子：ABS完全失效，导致车辆在湿滑路面制动时无法转向。严重度S3（可能致命），暴露概率E4（每次制动都可能遇到湿滑路面），可控性C3（普通驾驶员几乎无法控制）。组合起来，ASIL等级就是D。
3.2 安全目标定义
HARA做完，我们手里有一堆危害和对应的ASIL等级。接下来，要为每个危害定义安全目标。安全目标，说白了就是一句话：系统必须避免什么。
比如，针对“ABS完全失效”这个危害，安全目标可以定义为：“ABS系统在车辆行驶过程中，必须避免因自身故障导致车轮完全抱死。”
安全目标有几个关键属性：
- ASIL等级：继承自HARA分析结果。
- 安全状态：系统在检测到故障后，应该进入什么状态？比如“降级为常规制动”、“完全关闭ABS”、“点亮故障灯”。
- 故障容错时间间隔（FTTI）：从故障发生到系统进入安全状态，允许的最长时间。ABS的FTTI通常很短，可能只有几十毫秒。
我个人习惯，在定义安全目标时，会同时写一个“安全目标ID”，方便后续追溯。比如：SG_ABS_001。这样在写代码和做测试时，一看到ID就知道对应哪个安全目标。
3.3 功能安全概念（FSC）
安全目标定义好了，接下来就是功能安全概念（FSC）。FSC要回答的问题是：我们怎么通过系统架构和功能设计，来实现这些安全目标？
FSC不是代码，也不是硬件原理图。它是一份高层设计文档，描述了安全机制如何分配到系统的各个组件上。
3.3.1 安全机制分配
举个例子，针对“ABS完全失效”这个安全目标，我们可以设计以下安全机制：
- 故障检测机制：比如轮速传感器自检、电磁阀驱动电路诊断。
- 故障响应机制：比如检测到故障后，立即切断ABS电磁阀电源，让系统进入常规制动模式。
- 故障通知机制：比如点亮仪表盘上的ABS故障灯，并通过CAN总线发送故障码。
这些机制，要分配到具体的硬件和软件模块上。比如：
- 轮速传感器自检 → 由传感器接口芯片的硬件诊断功能实现。
- 电磁阀驱动电路诊断 → 由MCU的ADC采样和软件诊断逻辑实现。
- 故障响应 → 由MCU的GPIO控制继电器，切断电磁阀电源。
3.3.2 安全状态与降级策略
FSC里还要定义清楚，系统在不同故障下，应该进入什么安全状态。我建议用一张表来梳理：
| 故障类型 | 检测机制 | 安全状态 | FTTI |
|---|---|---|---|
| 轮速传感器失效 | 信号合理性检查 | 降级为3轮ABS | 100ms |
| 电磁阀驱动短路 | 回读诊断 | 关闭该通道ABS | 50ms |
| MCU自检失败 | LBIST | 完全关闭ABS | 10ms |
你想想看，如果轮速传感器坏了，直接关闭整个ABS，是不是太激进了？降级为3轮ABS，保留大部分功能，才是更合理的设计。这就是FSC要权衡的地方。
3.3.3 FSC的输出物
一份完整的FSC文档，通常包含以下内容：
- 安全目标列表（每个目标对应一个或多个安全机制）
- 安全机制描述（检测、响应、通知）
- 安全机制到系统元素的分配（哪个硬件/软件负责）
- 安全状态定义（正常、降级、故障安全）
- 故障容错时间间隔（FTTI）
- 安全相关的依赖关系（比如：安全机制A依赖传感器B的供电正常）
嗯，这里要注意，FSC是技术安全概念（TSC）的输入。TSC会更具体，涉及到软件架构、硬件架构、通信协议等。但FSC是承上启下的关键一环，它把“安全目标”翻译成了“系统设计的要求”。
好了，系统级安全设计这部分，核心就是这三步：HARA找危害、定ASIL；安全目标定要求；FSC定方案。每一步都环环相扣，缺一不可。下一章，我们会深入技术安全概念（TSC），看看这些安全机制怎么落地到具体的软件和硬件设计中去。