2、功能安全标准基础：ISO 26262概述、ASIL等级概念、安全生命周期、HARA在安全生命周期中的触发条件
各位同学，欢迎来到第二讲。上一章我们聊了HARA为什么重要，这一章咱们得先把地基打牢——功能安全标准ISO 26262到底是个啥？ASIL等级怎么定？安全生命周期长什么样？以及，我们最关心的HARA，到底在哪个节点被触发？
我个人习惯是，学任何标准之前，先搞清楚它要解决什么问题。ISO 26262说白了就是一本「汽车电子系统的安全作业指导书」。它告诉你：从概念设计到量产，每一步该做什么，才能把系统失效的风险降到可接受的水平。
2.1 ISO 26262概述：一本「活」的标准
ISO 26262的全称是「Road vehicles — Functional safety」。它脱胎于工业领域的IEC 61508，但专门针对汽车行业做了适配。我记得2011年第一版发布时，很多同行还在观望，觉得「不就是个推荐标准吗？」。直到2018年第二版发布，把半导体、摩托车、卡车全纳进来，大家才意识到——这玩意儿已经成了行业准入门槛。
标准的核心思想其实就一句话：把风险量化，然后管理它。它不要求你做到「绝对安全」，因为那不可能。它要求你做到「足够安全」，并且有证据证明你做到了。
关键点：ISO 26262不是设计指南，而是风险管理框架。它不告诉你「怎么设计一个刹车系统」，它告诉你「设计刹车系统时，你要考虑哪些失效场景，以及如何证明你的设计是安全的」。
标准覆盖了从A到L共12个部分。但对我们做HARA的人来说，最核心的是Part 3（概念阶段）和Part 4（系统级开发）。嗯，这里要注意：Part 3里的HARA分析结果，直接决定了后续所有开发工作的安全目标。
2.2 ASIL等级概念：风险的分级管理
ASIL，全称Automotive Safety Integrity Level，汽车安全完整性等级。它把风险分成四个等级：ASIL A、B、C、D，外加一个QM（Quality Management，质量管理级）。
你想想看，一个车灯失效和一个刹车失效，风险能一样吗？ASIL就是用来区分这个的。等级越高，要求越严，开发成本也越高。
ASIL的确定，靠的是三个参数：
- Severity (S)：严重度。人员受伤的程度。分S0（无伤害）到S3（致命）。
- Exposure (E)：暴露率。危险场景发生的概率。分E0（几乎不）到E4（非常高）。
- Controllability (C)：可控性。驾驶员或其他人员能否避免伤害。分C0（完全可控）到C3（几乎不可控）。
这三个参数组合起来，查表就能得到ASIL等级。我给大家一个简化版的对照表：
| 严重度 (S) | 暴露率 (E) | 可控性 (C) | ASIL等级 |
|---|---|---|---|
| S1 | E1 | C1 | ASIL A |
| S2 | E2 | C2 | ASIL B |
| S3 | E3 | C2 | ASIL C |
| S3 | E4 | C3 | ASIL D |
个人经验：我在做ADAS项目时，经常遇到一个误区——大家觉得「只要功能复杂，ASIL等级就高」。其实不是。ASIL只跟风险后果有关，跟功能复杂度无关。一个简单的门锁控制，如果失效会导致车门在高速上突然打开，那它也可能是ASIL D。别被复杂度骗了。
2.3 安全生命周期：从摇篮到坟墓
安全生命周期，是ISO 26262里最让我觉得「嗯，这标准确实靠谱」的部分。它把整个产品开发过程，按时间轴切成了几个阶段：
- 概念阶段：定义功能、分析风险、制定安全目标。
- 产品开发阶段：系统级、硬件级、软件级的设计与验证。
- 生产与运行阶段：制造、调试、维护。
- 退役阶段：产品报废时的安全考虑。
说白了，安全不是设计完了再「加」上去的，而是从一开始就「长」在系统里的。我见过太多项目，原型做完了才想起来做功能安全，结果发现架构根本没法满足ASIL要求，只能推倒重来。那成本，啧啧，够买好几辆测试车了。
安全生命周期还有一个重要概念——安全档案（Safety Case）。它就像产品的「安全护照」，记录了从概念到退役的所有安全证据。没有这个，审核员是不会放你量产的。
2.4 HARA在安全生命周期中的触发条件
好，终于到重点了。HARA到底什么时候做？
答案是：在概念阶段的最早期。具体来说，是在定义了项目范围和功能清单之后，开始系统架构设计之前。
为什么会是这个时间点？因为HARA的输出——安全目标——会直接影响架构设计。比如，HARA分析发现某个功能需要ASIL D，那你的架构就必须支持冗余、故障检测、安全状态切换等机制。如果架构已经定死了，再回头改，那叫「打补丁」，不是「做设计」。
我给大家画个简单的触发流程图：
项目启动 → 定义功能清单 → 执行HARA → 制定安全目标 → 系统架构设计 → ...注意，HARA不是只做一次。在以下情况，需要重新触发HARA：
- 功能变更：新增或修改了某个功能。
- 架构变更：系统拓扑、通信方式、冗余策略变了。
- 使用场景变更：比如原本只在城市道路用的车，现在要跑高速。
- 法规更新：新的安全法规要求重新评估。
避坑指南：我曾经在一个项目中，团队觉得「HARA做一次就够了」，结果后期发现某个功能的使用场景变了（从有人驾驶变成了远程遥控），但HARA没更新。最后审核时被开了严重不符合项，项目延期了三个月。所以，HARA一定要跟着项目走，别偷懒。
另外，HARA的触发条件在标准里写得很清楚——ISO 26262-3:2018，第7条。我建议各位把标准原文翻出来看看，虽然读起来有点枯燥，但比任何二手资料都准确。
2.5 小结
这一章我们讲了：
- ISO 26262是汽车功能安全的「作业指导书」，核心是风险管理。
- ASIL等级由S、E、C三个参数决定，等级越高，开发要求越严。
- 安全生命周期覆盖了从概念到退役的全过程，安全档案是核心交付物。
- HARA在概念阶段早期触发，且需要随项目变更而更新。
下一章，我们会深入HARA的具体执行步骤——怎么定义功能、怎么识别危险、怎么评估风险。到时候我会拿一个真实项目案例，带大家一步步走一遍。咱们下章见。