第3章 概念阶段：项目定义、HARA、安全目标与功能安全概念
概念阶段，说白了就是功能安全的「地基」。地基没打好，后面做得再漂亮也白搭。我见过不少项目，因为概念阶段草草了事，到了后期才发现安全目标定得太高或太低，结果要么成本爆炸，要么功能安全不达标，只能返工。
这一章，我们就把概念阶段的四个核心环节掰开揉碎讲清楚：项目定义、HARA（危害分析与风险评估）、安全目标、功能安全概念。
3.1 项目定义：搞清楚你到底在做什么
项目定义听起来简单，不就是描述一下产品嘛？但实际做起来，很多人会漏掉关键信息。
我个人习惯，项目定义至少要包含以下内容：
- 系统边界：哪些功能归你管，哪些是外部系统的事？
- 功能清单：列出所有功能，包括正常功能和降级功能。
- 运行模式：比如启动、运行、休眠、故障模式等。
- 环境条件：温度、湿度、电磁干扰、振动等。
- 法规要求：比如GB/T、ECE R13、R79等。
- 假设条件：比如假设驾驶员会定期检查轮胎气压。
我的经验：项目定义阶段，一定要拉上系统工程师、硬件工程师、软件工程师一起过一遍。我曾经遇到过一个项目，项目定义里没写「系统支持OTA升级」，结果后面做安全分析时发现，OTA过程本身会引入新的危害，不得不补做一轮HARA，浪费了两周时间。
3.2 HARA：危害分析与风险评估
HARA是概念阶段最核心的工作。它的目标就一个：找出所有可能造成人身伤害的危害事件，并评估其风险等级。
HARA的流程，我习惯分成三步走：
- 危害识别：分析系统功能失效后，会引发什么危害。
- 场景分析：这个危害在什么驾驶场景下会发生？
- 风险等级评估：用ASIL等级（A、B、C、D）或QM来量化风险。
3.2.1 危害识别
危害识别，说白了就是「如果这个功能坏了，最坏能坏到什么程度？」
举个例子，电动助力转向系统：
- 功能失效：转向助力突然消失。
- 危害：驾驶员需要更大的力才能转动方向盘，可能导致车辆偏离车道。
- 潜在后果：碰撞。
嗯，这里要注意，危害识别不能只盯着「功能完全失效」，还要考虑功能错误执行的情况。比如转向系统突然自己打方向，那比没助力更危险。
3.2.2 场景分析与ASIL等级评估
同一个危害，在不同场景下，风险等级可能天差地别。
ISO 26262用三个参数来评估风险：
| 参数 | 全称 | 含义 | 等级 |
|---|---|---|---|
| S | Severity（严重度） | 伤害的严重程度 | S0~S3 |
| E | Exposure（暴露概率） | 场景发生的概率 | E0~E4 |
| C | Controllability（可控性） | 驾驶员能否避免伤害 | C0~C3 |
ASIL等级由S、E、C组合决定：
- ASIL D：最高等级，比如刹车系统、转向系统。
- ASIL C：比如自适应巡航的纵向控制。
- ASIL B：比如自动大灯。
- ASIL A：比如车窗防夹。
- QM：质量管理即可，比如车内氛围灯。
避坑指南：我曾经犯过一个错误——把E值估得太低。当时分析「高速公路上突然爆胎」这个场景，我觉得概率很低，给了E2。结果安全评审时被专家怼了：「你想想看，每年有多少爆胎事故？E2太乐观了。」最后改成了E3，ASIL等级从B升到了C，整个安全方案都得重做。
3.3 安全目标：给安全定个「小目标」
HARA做完之后，每个危害事件都会对应一个安全目标。安全目标是一个顶层安全要求，它描述了「系统必须做什么来避免或减轻危害」。
安全目标的写法有讲究。我建议用这个模板：
安全目标 SG-01：
当 [触发条件] 时，系统应 [安全行为]，
以避免 [危害事件]。
ASIL等级：[ASIL D/C/B/A/QM]
安全状态：[描述安全状态]
容错时间间隔：[FTTI，单位ms]举个例子：
安全目标 SG-EPAS-01：
当转向助力系统发生故障时，
系统应确保驾驶员仍能通过人力控制车辆转向，
以避免车辆失控。
ASIL等级：ASIL D
安全状态：转向助力降级或关闭，但机械连接保持
容错时间间隔：≤ 500 ms
我的习惯：安全目标一定要写清楚「安全状态」和「容错时间间隔」。很多项目只写了「系统应如何如何」，但没写「多久之内必须进入安全状态」，结果到了系统设计阶段才发现时间根本不够用。
3.4 功能安全概念：把安全目标变成具体方案
安全目标定好了，接下来就是功能安全概念。说白了，就是「怎么实现这些安全目标」。
功能安全概念要做三件事：
- 分配安全要求：把安全目标分解到系统架构的各个元素上（传感器、控制器、执行器）。
- 定义安全机制：比如故障检测、故障响应、降级策略。
- 定义安全状态：系统进入什么状态才算安全？
3.4.1 安全要求的分配
举个例子，还是转向系统：
- 安全目标：转向助力故障时，驾驶员仍能人力转向。
- 分配到传感器：需要检测转向扭矩和转角。
- 分配到控制器：需要监控助力电机状态，检测到故障后切断助力。
- 分配到执行器：需要保证机械连接始终有效（比如蜗轮蜗杆不能自锁）。
3.4.2 安全机制示例
我整理了几个常见的安全机制：
| 安全机制 | 作用 | 典型实现 |
|---|---|---|
| 故障检测 | 发现故障 | 看门狗、CRC校验、信号范围检查 |
| 故障响应 | 进入安全状态 | 切断电源、切换到冗余通道、降级运行 |
| 故障容错 | 故障时仍能工作 | 双通道冗余、三模冗余 |
| 故障通知 | 告知驾驶员 | 仪表盘报警灯、声音提示 |
注意：功能安全概念不是一次就能定死的。我做过一个项目，最初的功能安全概念里用了「双通道冗余」方案，结果成本太高被砍了。后来改成了「单通道+降级策略」，虽然ASIL等级没变，但安全机制的设计复杂度反而更高了。所以，功能安全概念一定要和系统架构、成本、开发周期反复迭代。
3.5 概念阶段的知识体系
下面这张图，是我自己总结的概念阶段核心逻辑，你看一眼就能明白整个流程：
3.6 概念阶段的常见误区
最后，我总结几个概念阶段最容易踩的坑：
- 项目定义太模糊：比如只写「转向系统」，没写「包含哪些传感器、控制器、执行器」，导致HARA漏掉关键危害。
- HARA场景不够全：只考虑了正常驾驶场景，没考虑维修、充电、OTA升级等场景。
- ASIL等级估错：要么过于乐观（低估风险），要么过于保守（成本爆炸）。
- 安全目标写得太虚：比如「系统应保证安全」，但没写「安全状态是什么」「多久进入安全状态」。
- 功能安全概念脱离实际：比如要求「双通道冗余」，但硬件平台根本不支持。
血的教训：我曾经在一个项目里，HARA阶段漏掉了「系统在低温环境下响应延迟」这个场景。结果冬天路试时，转向助力在-30°C下响应慢了300ms，差点出事。后来补做HARA，发现这个场景的E值其实不低（北方冬天很常见），ASIL等级从B升到了C，整个软件架构都得改。所以，HARA一定要拉上测试工程师和标定工程师一起做，他们最清楚实际场景。
概念阶段做扎实了，后面的系统设计、硬件开发、软件开发才能顺风顺水。你想想看，如果地基都没打牢，楼盖得再高也是危楼，对吧？