3. 安全目标定义
概念阶段，说白了就是回答三个问题：我们要做什么？会出什么危险？怎么防止危险？
我见过不少团队，一上来就急着写代码、画原理图，结果做到一半发现安全目标没定清楚，回头再补HARA，那叫一个痛苦。所以，概念阶段千万别赶进度，地基打不牢，后面全是坑。
3.1 项目定义（Item Definition）
项目定义是功能安全的第一步。你得把你要开发的系统说清楚：它是什么、装在哪、跟谁通信、怎么用。
项目定义的核心输出：
- 系统边界：哪些功能归你管，哪些是外部依赖
- 功能清单：列出所有主要功能和子功能
- 运行模式：正常模式、故障模式、维护模式等
- 环境条件：温度、振动、电磁干扰等
- 法规要求：ISO26262之外，还有没有其他标准要满足
我个人习惯，在项目定义阶段就拉上系统工程师、硬件工程师、软件工程师一起过一遍。为什么？因为很多边界问题，一个人想不全。比如一个电动助力转向系统，你以为是纯电子的，结果机械工程师告诉你转向柱的机械限位会影响故障响应时间——这种坑，我踩过不止一次。
3.2 HARA：危害分析与风险评估
HARA（Hazard Analysis and Risk Assessment）是整个功能安全流程的基石。它的目标就一个：找出所有可能造成人身伤害的系统故障，并给每个危害定个等级。
3.2.1 HARA的三要素
做HARA之前，你得先理解三个核心参数：
| 参数 | 含义 | 取值 |
|---|---|---|
| S（Severity） | 危害的严重度 | S0（无伤害）~ S3（致命） |
| E（Exposure） | 暴露在危险场景中的概率 | E0（几乎不）~ E4（非常高） |
| C（Controllability） | 驾驶员或其他人控制风险的能力 | C0（完全可控）~ C3（几乎不可控） |
这三个参数组合起来，就得到了ASIL等级（Automotive Safety Integrity Level）：
- ASIL A：最低安全等级
- ASIL B：中等
- ASIL C：较高
- ASIL D：最高安全等级（比如刹车、转向）
- QM：质量管理即可，无安全要求
一个小技巧： 我一般先做S、E、C的初步评估，再跟团队一起评审。因为一个人打分容易偏，三个人一起讨论，结果会更客观。有一次我们做ADAS的HARA，我打了S2，系统工程师坚持S3，最后发现他考虑的场景我确实漏了——多个人看，确实不一样。
3.2.2 HARA的执行步骤
- 场景分析：列出所有可能的运行场景（高速、城市、停车、充电等）
- 危害识别：每个场景下，系统故障会导致什么危害？
- 风险评估：对每个危害，评估S、E、C，确定ASIL等级
- 安全目标定义：每个危害对应一个安全目标
举个例子，一个电子刹车助力系统：
| 危害 | 场景 | S | E | C | ASIL |
|---|---|---|---|---|---|
| 刹车助力突然失效 | 高速行驶中 | S3 | E3 | C2 | ASIL D |
| 刹车助力延迟响应 | 城市拥堵 | S2 | E4 | C1 | ASIL B |
| 刹车意外自动触发 | 停车场低速 | S1 | E2 | C1 | QM |
注意： HARA不是一次性工作。系统设计变了、使用场景变了，HARA就要跟着更新。我曾经在一个项目里，因为没及时更新HARA，导致后期安全机制设计跟实际风险不匹配，最后返工了两个月。嗯，从那以后，我每次需求变更都会问一句：HARA要不要改？
3.3 功能安全概念（Functional Safety Concept）
有了安全目标，接下来就是功能安全概念。说白了，就是怎么用功能手段来实现安全目标。
3.3.1 功能安全概念的核心内容
- 安全机制：检测故障、防止故障、减轻故障后果的具体方法
- 故障响应时间：从故障发生到安全机制生效的最大允许时间
- 安全状态：系统进入安全状态后的行为（比如降级运行、关闭、保持当前状态）
- 功能冗余：是否需要备份路径
举个例子，还是那个电子刹车助力系统，它的安全目标是：“防止刹车助力在高速行驶中突然完全失效”（ASIL D）。
对应的功能安全概念可能是：
- 故障检测：监控助力电机电流和位置传感器，检测异常
- 故障响应：检测到故障后，50ms内切换到机械备份模式
- 安全状态：降级为纯机械刹车（无助力，但能刹住）
- 冗余设计：主控制器失效时，独立监控芯片直接触发安全状态
3.3.2 功能安全概念的分配
功能安全概念要分配到具体的系统元素上：
| 安全机制 | 分配给 | ASIL等级 |
|---|---|---|
| 电机电流监控 | 硬件（电流传感器+ADC） | ASIL D |
| 故障诊断逻辑 | 软件（诊断模块） | ASIL D |
| 机械备份切换 | 硬件（电磁离合器） | ASIL D |
| 独立监控芯片 | 硬件（独立看门狗+安全逻辑） | ASIL D |
我的经验： 功能安全概念阶段，一定要写清楚故障响应时间。很多项目后期出问题，就是因为响应时间没定死，硬件说我能50ms，软件说我要100ms，最后谁都不改，系统达不到安全目标。所以，概念阶段就把时间线画清楚，后面才好落地。
3.4 概念阶段的知识体系
下面这张图，是我自己总结的概念阶段核心流程，你一看就明白了：
3.5 避坑指南
概念阶段常见的坑，我列几个：
- 项目定义太模糊：边界不清，导致HARA漏掉关键场景。我建议用系统边界图把内外接口画清楚。
- HARA打分靠拍脑袋：没有数据支撑，全靠“我觉得”。最好参考历史项目数据或行业基准。
- 安全目标写得太笼统：比如“防止刹车失效”，没有具体时间和条件。要写成“在高速行驶中，刹车助力失效后，50ms内进入机械备份模式”。
- 功能安全概念不考虑成本：ASIL D的方案当然好，但成本也高。要在安全目标和工程成本之间找到平衡点。
最后提醒一句： 概念阶段的文档，一定要版本管理。我见过一个项目，HARA改了三次，但功能安全概念还是第一版，结果安全机制跟实际风险对不上。嗯，从那以后，我每次更新HARA，都会同步更新功能安全概念，并且做一次一致性检查。