📚 课程目录第3章概念阶段开发

3. 概念阶段开发：项目定义、安全生命周期启动、HARA方法

概念阶段，说白了就是给整个功能安全项目「打地基」的阶段。我见过不少团队，一上来就急着做技术设计，结果做到一半发现安全目标没定清楚，回头返工，那叫一个痛苦。所以，咱们今天就把概念阶段的三个核心动作——项目定义、安全生命周期启动、HARA——彻底聊透。

3.1 项目定义：先搞清楚我们要做什么

项目定义不是写个产品名称就完事了。你得把系统的边界、功能、接口、运行模式、环境条件全列出来。我个人习惯，先画一张系统上下文图，把系统跟外部实体（人、其他系统、环境）的关系理清楚。

  项目定义的核心输出：
  系统边界：哪些功能在系统内，哪些在系统外
功能清单：每个功能的描述、触发条件、预期行为
接口定义：传感器、执行器、通信总线、人机交互
运行模式：正常模式、故障模式、维护模式、紧急模式
环境条件：温度、湿度、振动、电磁干扰等

举个例子。我之前做过一个电动助力转向（EPS）项目。项目定义阶段，我们花了整整两周跟系统工程师、硬件工程师、软件工程师一起过功能清单。你猜怎么着？我们发现「自动泊车辅助」这个功能，在项目定义里写的触发条件是「车速低于10km/h」，但实际系统里还有个「驾驶员按下按钮」的前提。这个细节没写清楚，后面HARA分析时差点漏掉一个关键场景。

我的小技巧： 项目定义文档最好用表格形式，把每个功能的「功能ID」「功能名称」「触发条件」「预期行为」「故障行为」列清楚。这样后面做HARA时，直接拿这个表来用，效率翻倍。

3.2 安全生命周期启动：别急着干活，先定规矩

安全生命周期启动，听起来很玄乎，其实就三件事：定计划、定角色、定流程。

ISO 26262 要求每个项目都要有一个安全计划（Safety Plan）。这个计划不是写出来应付审核的，而是真正指导你每天怎么干活。我建议安全计划至少包含以下内容：

安全计划要素	说明	我的经验
安全活动时间表	每个安全活动什么时候做、谁做、输出什么	用甘特图，别用文字描述，审核员看着也清楚
角色与职责	安全经理、安全工程师、评审员、测试员	一定要明确「谁对安全目标负责」，别搞成集体负责
评审与审批流程	每个安全工件谁来评审、谁来批准	我习惯设一个「安全评审委员会」，每周过一遍关键工件
工具链与配置管理	用什么工具做HARA、FMEA、FTA，版本怎么管	工具链一定要提前验证，别等到做FTA时才发现工具不支持
偏差管理流程	如果计划跟实际有偏差，怎么处理	偏差管理是审核时最容易出问题的地方，提前定好流程

注意： 安全生命周期启动时，一定要跟项目管理层对齐。我曾经遇到一个项目，安全计划写得很好，但项目经理根本不看，结果安全活动跟项目进度完全脱节。最后审核时，安全计划成了摆设。所以，安全计划一定要跟项目计划绑定，安全里程碑要跟项目里程碑对齐。

3.3 HARA：危害分析与风险评估

HARA 是整个概念阶段最核心、最费脑子的活动。它的目标就一个：找出系统所有可能的危害，评估每个危害的风险等级，然后定出安全目标。

HARA 的标准流程，我习惯分成五步走：

场景分析： 列出所有可能的运行场景和故障场景
危害识别： 每个场景下，系统故障会导致什么危害
风险评估： 评估每个危害的 Severity（严重度）、Exposure（暴露概率）、Controllability（可控性）
ASIL 等级确定： 根据 S、E、C 查表得到 ASIL 等级
安全目标定义： 为每个危害定义安全目标，明确要避免什么

下面这张图，是我做 HARA 时常用的流程框架：

3.4 场景分析：别漏掉「阴间场景」

场景分析是HARA的第一步，也是最容易出问题的一步。我见过太多团队，只分析了「正常驾驶场景」，结果审核时被问「如果车辆在隧道里、路面结冰、同时系统部分失效，会发生什么？」——直接懵了。

我个人习惯，做场景分析时用「场景矩阵」来穷举：

维度	典型取值	说明
运行模式	正常、故障、维护、紧急	每个模式都要分析
环境条件	白天/夜晚、晴天/雨/雪/雾、城市/高速/山路	极端环境往往暴露高风险
道路类型	直道、弯道、坡道、隧道、桥梁	不同道路对危害后果影响很大
交通状况	空旷、正常、拥堵、事故现场	拥堵时危害后果可能更严重
驾驶员状态	正常、疲劳、分心、紧急操作	驾驶员状态影响可控性评估

避坑指南： 我曾经在一个ADAS项目中，漏掉了「隧道内GPS信号丢失」这个场景。结果HARA评审时，安全评审委员会直接指出：隧道内GPS丢失会导致车道保持功能降级，如果同时遇到路面湿滑，车辆可能偏离车道。这个场景的ASIL等级是C级。所以，场景分析时一定要拉上系统工程师、测试工程师、甚至售后工程师一起 brainstorm，他们往往能提供你没想到的场景。

3.5 风险评估：S/E/C 的取值没那么简单

风险评估是HARA里最「主观」的一步。ISO 26262 给了 S/E/C 的取值表格，但实际项目中，同一个危害，不同工程师可能给出不同的等级。为什么会这样？因为大家对「严重度」「暴露概率」「可控性」的理解不一样。

我分享一个我自己的做法：

S（严重度）： 不要只看「会不会死人」，要看「最坏情况下可能造成什么伤害」。比如，EPS失效导致方向盘卡死，在高速上可能是S3，但在停车场可能只有S1。所以，严重度要结合场景来定。
E（暴露概率）： 不是看「这个故障发生的概率」，而是看「这个场景发生的概率」。比如，「车辆在高速上以120km/h行驶」这个场景，暴露概率是E4（高暴露），因为很多车每天都在高速上跑。
C（可控性）： 这是最难评估的。我建议用「95%的驾驶员在故障发生后能否避免伤害」作为判断标准。如果95%的驾驶员能控制住，那就是C2或C1；如果只有50%能控制住，那就是C3。

注意： S/E/C 的取值一定要有依据。我见过一些团队，直接拍脑袋给个值，审核时被问「为什么这个危害的暴露概率是E3而不是E2？」——答不上来。所以，每个取值都要写清楚理由，最好引用场景分析中的具体场景。

3.6 ASIL 等级与安全目标

S/E/C 确定后，查 ISO 26262-3 的表格就能得到 ASIL 等级。ASIL 等级从 A 到 D，D 是最严格的。如果 S/E/C 组合落在 QM 区域，那就不需要按功能安全流程开发，但建议还是记录一下。

安全目标怎么写？我有个模板：

安全目标 ID: SG-001
关联危害: HZ-003（EPS非预期助力导致方向盘突然偏转）
ASIL 等级: C
安全目标描述: 在车辆行驶过程中，EPS系统应避免非预期的方向盘偏转，防止车辆偏离车道。
安全状态: EPS系统进入降级模式，方向盘助力降低至安全水平，同时点亮警告灯。
故障容错时间间隔: ≤ 100ms

  关键点： 安全目标一定要可验证。你写「避免非预期方向盘偏转」，那怎么验证？测试时怎么判断「非预期」？所以，安全目标最好加上量化指标，比如「方向盘偏转角速度不超过 5°/s」。

3.7 我的 HARA 避坑清单

最后，分享一份我这些年做 HARA 总结的避坑清单：

别漏场景： 场景分析至少做两轮，第一轮 brainstorm，第二轮用场景矩阵穷举
别主观取值： S/E/C 每个取值都要写依据，最好引用具体场景
别忽略组合故障： 两个独立故障同时发生，可能导致更严重的危害
别忘记安全状态： 每个安全目标都要定义安全状态，以及进入安全状态的时间
别跳过评审： HARA 结果一定要经过独立评审，最好让不同项目组的人来评审

嗯，概念阶段的内容就这些。项目定义、安全生命周期启动、HARA，这三步走扎实了，后面的技术开发才有方向。记住一句话：概念阶段多花一周，开发阶段少返工一个月。这是我在无数项目中用血泪换来的经验。