3. ISO 26262 体系结构
概念阶段，说白了就是整个功能安全开发的起点。很多人觉得这步就是写写文档、走个过场，我刚开始做项目时也这么想。直到有一次，因为项目定义没写清楚，后期才发现系统边界划错了，整个HARA重做，项目延期了两个月。嗯，从那以后，我再也不敢轻视概念阶段了。
这一章，我们重点聊三件事：项目定义、HARA（危害分析与风险评估）、安全目标定义。这三步是功能安全的地基，地基不稳，后面全白搭。
3.1 项目定义：把边界画清楚
项目定义要回答一个核心问题：我们到底要对什么做功能安全？
我个人习惯，先拉一张表，把项目的基本信息列清楚：
| 项目定义要素 | 内容示例 | 常见坑点 |
|---|---|---|
| 系统名称 | 电动助力转向系统（EPS） | 名称太宽泛，比如写“转向系统” |
| 系统功能 | 提供转向助力、回正控制 | 漏掉非安全功能，比如诊断功能 |
| 系统边界 | 从方向盘扭矩传感器到齿条 | 边界画得太小，漏了供电和通信 |
| 外部接口 | CAN总线、电源、驾驶员输入 | 只写电气接口，漏了机械接口 |
| 运行模式 | 驾驶模式、泊车模式、故障模式 | 漏掉故障降级模式 |
| 法规要求 | UN R79、ISO 26262 | 只写标准号，不写具体条款 |
项目定义还有一个容易被忽略的点——假设条件。比如“假设驾驶员始终手握方向盘”、“假设供电电压在9V-16V之间”。这些假设要写清楚，因为后面HARA和安全目标都依赖这些假设。如果假设变了，整个安全分析都要重新来。
3.2 HARA：危害分析与风险评估
HARA是概念阶段的重头戏。它的目标就一个：找出系统可能造成的危害，并评估风险等级。
HARA的标准流程，我一般分四步走：
- 功能清单梳理——列出系统的所有功能，包括安全功能和非安全功能
- 危害识别——对每个功能，思考“如果这个功能失效了，会发生什么？”
- 场景分析——在什么驾驶场景下，这个危害会导致事故？
- 风险等级评估——用S（严重度）、E（暴露概率）、C（可控性）三个参数打分
这里我重点说说风险等级评估。ISO 26262用三个参数来确定ASIL等级：
| 参数 | 含义 | 等级范围 | 评估依据 |
|---|---|---|---|
| S（Severity） | 危害对人员的伤害严重度 | S0~S3 | 伤害类型、受伤程度 |
| E（Exposure） | 危害场景的发生概率 | E0~E4 | 场景出现频率、持续时间 |
| C（Controllability） | 驾驶员或其他人员控制危害的能力 | C0~C3 | 驾驶员反应时间、可操作性 |
三个参数组合，查表得到ASIL等级（A、B、C、D）或QM。ASIL D是最高的，要求也最严格。
HARA的输出是一张危害清单，每条危害包含：危害描述、场景描述、S/E/C评分、ASIL等级、安全目标编号。这张表是后续所有安全活动的输入，一定要写清楚、写完整。
3.3 安全目标定义：把“不做什么”写清楚
安全目标，说白了就是“系统不能做什么”。比如“系统不能输出超出规定范围的转向扭矩”、“系统不能在无请求时触发制动”。
安全目标的写法，ISO 26262有明确要求：
- 每个安全目标对应一个危害
- 安全目标要描述“避免或减轻危害的行为”
- 安全目标要继承HARA的ASIL等级
- 安全目标要可验证、可测试
我给大家看一个实际项目的安全目标示例：
安全目标编号：SG-001
关联危害：H-003（非预期的转向助力输出）
安全目标描述：EPS系统在检测到非预期转向助力输出时，必须在100ms内将助力扭矩限制到安全值以下。
ASIL等级：ASIL D
FTTI（故障容错时间间隔）：100ms
安全状态：转向助力降级至0，驾驶员可手动转向
验证方法：故障注入测试、仿真分析安全目标定义完，概念阶段的核心产出就齐了。我个人习惯，在概念阶段结束时，会做一次安全目标评审，邀请系统、硬件、软件、测试、项目经理一起参加。评审的重点是：
- 安全目标是否覆盖了所有危害？
- ASIL等级是否合理？
- 安全目标是否可验证？
- 安全目标之间是否有冲突？
你想想看，如果安全目标本身就有问题，后面做再多的安全机制、再多的测试，都是白费功夫。所以概念阶段的评审，一定要认真对待。
3.4 概念阶段知识体系总览
下面这张图，把概念阶段的核心流程和产出串起来了。我建议你把它打印出来，做项目时贴在工位上。
概念阶段做完，你手里应该有：一份清晰的项目定义、一份完整的危害清单、一组可验证的安全目标。这些东西看着是文档，但它们是后续所有安全工作的源头。源头错了，后面全是错的。
我记得有一次评审，项目经理问我：“概念阶段花这么多时间，值吗？”我说：“你想想看，如果地基没打好，楼盖到一半才发现要拆了重来，哪个更费时间？”他想了想，没再催进度了。