3. 概念阶段：项目定义、HARA 与功能安全概念
概念阶段，说白了就是回答三个问题：我们在做什么？会出什么危险？怎么防止危险？
我见过不少团队，一上来就急着写代码、画板子，结果做到一半发现安全目标没定，ASIL 等级没分，最后推倒重来。嗯，概念阶段省下的时间，迟早要在后期加倍还回去。
3.1 项目定义：把边界画清楚
项目定义不是写个产品名称就完事了。你得把功能、边界、运行场景、已知风险都列出来。
我个人习惯用一张表来收拢信息：
| 项目定义要素 | 内容示例（以电动助力转向 EPS 为例） |
|---|---|
| 系统名称 | 电动助力转向系统（EPS） |
| 主要功能 | 根据方向盘扭矩和车速，提供辅助转向力矩 |
| 运行模式 | 上电自检、助力模式、故障降级模式 |
| 运行场景 | 城市道路、高速、停车场、雨雪天气 |
| 系统边界 | 与 VCU、ESP、仪表盘有信号交互；与驾驶员有机械连接 |
| 已知假设 | 驾驶员始终在座位上；车辆供电正常 |
我的经验：项目定义阶段一定要拉上系统工程师、硬件工程师、软件工程师一起过一遍。我曾经吃过亏——项目定义里没写「支持 OTA 升级」，结果后期加功能安全需求时，发现升级过程中的安全机制完全没覆盖，补起来非常痛苦。
3.2 HARA：危害分析与风险评估
HARA 是概念阶段最核心的活儿。它的目标就一个：找出所有可能造成人身伤害的危害，并给每个危害定个安全等级（ASIL）。
HARA 的标准流程分三步：
- 场景分析——列出所有可能的运行场景和故障模式
- 危害识别——分析每个故障会导致什么危害
- 风险评估——评估严重度（S）、暴露概率（E）、可控性（C），算出 ASIL
举个例子，EPS 系统的 HARA 片段：
| 故障 | 危害 | 场景 | S | E | C | ASIL |
|---|---|---|---|---|---|---|
| 非预期助力 | 车辆突然转向 | 高速行驶 | 3 | 2 | 3 | C |
| 助力丧失 | 转向沉重 | 低速泊车 | 1 | 3 | 1 | A |
| 助力反向 | 方向盘反向转动 | 弯道行驶 | 3 | 2 | 2 | C |
避坑指南：我曾经见过一个团队，把「非预期助力」的 E 值估低了，理由是「这种故障很少见」。但 ISO 26262 要求的是「暴露概率」，不是「故障概率」——只要车辆在高速上跑，驾驶员就暴露在这个风险里，E 值应该按场景算，不是按故障率算。
评估完 ASIL 之后，你会得到一组安全目标（Safety Goal）。每个安全目标对应一个危害，格式通常是：
SG-01：防止非预期转向助力导致车辆失控
ASIL：C
安全状态：EPS 进入降级模式，助力力矩限制在安全范围内
FTTI：100ms安全目标是后续所有工作的输入。你想想看，没有安全目标，功能安全设计就是无头苍蝇。
3.3 功能安全概念（FSC）：把安全目标变成技术方案
有了安全目标，接下来就是功能安全概念。FSC 要回答的是：怎么用功能手段来实现安全目标？
FSC 的核心输出包括：
- 安全机制分配——哪个安全机制负责检测哪个故障？
- 故障检测与响应——检测到故障后，系统做什么？
- 降级策略——故障时系统怎么降级？
- 驾驶员警告——什么时候需要提醒驾驶员？
还是拿 EPS 举例，针对 SG-01（防止非预期转向），FSC 可能这样设计：
安全机制 SM-01：扭矩传感器合理性检查
检测对象：主扭矩传感器 vs 副扭矩传感器
检测方法：比较两个传感器的差值，超过阈值则报错
响应动作：切断助力，点亮 EPS 故障灯
响应时间：< 50ms
安全机制 SM-02：电机电流监控
检测对象：实际电机电流 vs 目标电流
检测方法：偏差超过 20% 持续 10ms 则报错
响应动作：关闭 MOSFET 驱动，进入安全状态
响应时间：< 20ms
关键点：FSC 阶段不要陷入硬件或软件的具体实现。你只需要定义「做什么」，不需要定义「怎么做」。比如「扭矩传感器合理性检查」是功能需求，至于用 SPI 还是 CAN 通信，那是后续详细设计的事。
下面这张图展示了概念阶段三个步骤的递进关系：
3.4 概念阶段常见的坑
做了这么多年功能安全，我总结几个概念阶段最容易踩的坑：
- 项目定义太模糊——比如只说「支持自动驾驶」，没写 L2 还是 L3，导致 HARA 场景没法收敛。我建议项目定义里明确写上「ODD（运行设计域）」。
- HARA 漏场景——只考虑正常驾驶，没考虑维修模式、充电模式、OTA 升级模式。这些场景下的危害同样要分析。
- ASIL 分解过早——有些人拿到 ASIL C 就直接分解成 ASIL B + ASIL B，但 ISO 26262 要求先做 FSC，再考虑分解。顺序搞反了，评审过不了。
- FSC 写得太细——把 FSC 写成了详细设计，比如「用 STM32F407 的 ADC 采样扭矩信号」。概念阶段不应该绑定具体器件，否则后面换芯片，整个 FSC 都得重写。
我的习惯：概念阶段结束时，我会组织一次「安全目标评审会」，邀请系统、硬件、软件、测试、项目经理一起参加。每个人对着安全目标逐条过一遍，确认「这个目标合理吗？能验证吗？有没有遗漏？」。这一步虽然花时间，但能避免后期大量返工。
概念阶段做扎实了，后面的系统设计、硬件设计、软件设计才有根。你想想看，如果安全目标本身就有问题，后面再努力也是白搭。