先复习：概念阶段到底包含哪些活动？
根据ISO 26262-3（概念阶段），概念阶段包含三大核心活动：
概念阶段的本质就是：在相对抽象的逻辑功能层面，通过安全分析提出功能安全开发最初的安全需求。
简单说就是三件事：
- 相关项定义→ “我们要分析什么？”
- HARA分析→ “它出事了会怎样？风险多大？”
- 功能安全概念→ “我们要做什么来防止？”
今天我们就把这三件事，用ACC系统完整走一遍。
第一步：相关项定义（Item Definition）
目标：说清楚“我们要分析的是什么系统”，画出它的边界和接口。
ACC系统的相关项定义
相关项名称：自适应巡航控制（ACC）系统
功能描述：ACC系统能够自动调整车速，以保持与前车的安全距离。
系统边界：
关键接口：
| 接口方向 | 接口对象 | 交互内容 |
|---|---|---|
| ➡️ 输入 | 前向雷达 | 目标车辆距离、相对速度 |
| ➡️ 输入 | 前向摄像头 | 车道线、目标车辆识别 |
| ➡️ 输入 | ESP系统 | 车身稳定状态、轮速信号 |
| ➡️ 输入 | 驾驶员 | 按键设定/取消、车速设定 |
| ⬅️ 输出 | 发动机/制动 | 扭矩请求、制动压力请求 |
| ⬅️ 输出 | 仪表盘 | 当前状态显示、报警信息 |
约束条件：
- 仅在铺装路面可用
- 能见度≥50m
- 车速范围0-130km/h
- 依赖ESP系统正常工作
这一步的输出是一份《相关项定义说明书》——它是后续所有安全活动的“地基”。
🔍 第二步：HARA分析——危害识别与场景构建
目标：找出ACC系统所有可能的危害事件。
ACC系统的危害识别
根据ISO 26262标准，ACC系统可能存在以下几类危害：
| 危害类别 | 具体描述 |
|---|---|
| 🔴传感器故障 | 雷达或摄像头失效，无法正确监测前车距离或速度 |
| 🔴软件错误 | 系统软件缺陷导致ACC控制逻辑错误，车速控制不当 |
| 🔴过度信任 | 驾驶员过分依赖ACC，紧急情况下反应不及时 |
| 🔴恶劣天气 | 大雨、大雪或浓雾影响传感器性能 |
| 🔴静止目标识别 | ACC无法识别静止或缓慢移动的目标 |
| 🔴弯道性能 | 急弯中无法维持与前车的安全距离 |
构建危害事件（危害 + 驾驶场景）
以“非预期急刹车”这个危害为例，匹配不同的驾驶场景：
| 危害事件ID | 功能异常 | 驾驶场景 | 潜在后果 |
|---|---|---|---|
| HE-001 | 非预期急刹车 | 高速公路，120km/h，晴天 | 后车追尾，可能致命 |
| HE-002 | 非预期急刹车 | 高速公路，120km/h，雨天 | 后车追尾+侧滑 |
| HE-003 | 非预期急刹车 | 城市道路，30km/h，夜间 | 后车轻微追尾 |
| HE-004 | 非预期急刹车 | 停车场，5km/h | 基本无伤害 |
关键洞察：同一个功能异常（非预期急刹车），在不同的驾驶场景下，风险等级天差地别。
第三步：HARA分析——S/E/C评分与ASIL判定
目标：对每个危害事件进行S/E/C评分，确定ASIL等级。
三维评分与ASIL判定
| 危害事件 | S（严重度） | E（暴露率） | C（可控性） | ASIL |
|---|---|---|---|---|
| HE-001：高速+晴天+急刹车 | S3（致命） | E4（几乎每次） | C3（难以控制） | D |
| HE-002：高速+雨天+急刹车 | S3（致命） | E3（每月几次） | C3（难以控制） | C |
| HE-003：城市+急刹车 | S2（重伤） | E4（几乎每次） | C2（一般可控） | B |
| HE-004：停车场+急刹车 | S0（无伤害） | E2（偶尔） | C1（极易控制） | QM |
💡注意：如果S、E、C中有一项为0，直接判为QM——不需要功能安全措施。
第四步：输出安全目标（Safety Goal）
目标：针对每个危害事件，制定顶层的安全要求。
安全目标必须遵循SMART原则——具体、可测量、可实现、相关、有时限。
ACC系统的安全目标清单
| 危害事件 | ASIL | 安全目标 |
|---|---|---|
| HE-001 | D | ACC系统应避免在非必要情况下输出超过阈值的减速度请求，安全状态为退出ACC并发出声光报警，FTTI ≤ 100ms |
| HE-002 | C | ACC系统在恶劣天气条件下应检测环境状态，在不可靠时主动降级或退出 |
| HE-003 | B | ACC系统在城市低速场景下的减速度请求应限制在安全范围内 |
多个危害事件可以合并为一个安全目标，ASIL等级取最高值。
第五步：功能安全概念（FSC）
目标：从安全目标导出功能安全需求（FSR），并分配至系统架构。
从SG导出FSR
以SG-01（防止非预期急刹车，ASIL-D）为例：
用FTA方法倒推：什么原因会导致“非预期急刹车”？
- 传感器误判（雷达把阴影当成了障碍物）
- 控制器计算错误（安全距离算错了）
- 执行器失控（刹车指令执行过度）
- 通信故障（CAN信号被干扰）
针对每个原因，制定FSR：
| ID | 功能安全需求 | 分配给谁 | ASIL |
|---|---|---|---|
| FSR-01 | 雷达传感器应能正确检测前方目标，距离误差≤±2m | 雷达模块 | D |
| FSR-02 | 控制器应正确计算安全跟车距离，响应时间<300ms | 域控制器 | D |
| FSR-03 | 执行器应限制最大减速度不超过X m/s² | 制动执行器 | D |
| FSR-04 | 系统应监控CAN通信，检测到异常时在50ms内进入安全状态 | 通信模块 | D |
定义安全状态和FTTI
| 安全目标 | 安全状态 | FTTI |
|---|---|---|
| SG-01（非预期急刹车） | 退出ACC，声光报警，恢复手动控制 | ≤ 100ms |
| SG-02（恶劣天气降级） | 降级为普通定速巡航，提示驾驶员 | ≤ 200ms |
概念阶段全流程总览图
把以上五个步骤串起来，就是概念阶段的完整流程图：
