第3章 概念阶段:项目定义、HARA与安全目标

概念阶段,说白了就是整个功能安全开发的起点。很多人觉得这步就是写写文档、走个过场,我刚开始做项目时也这么想。直到有一次,因为项目定义没写清楚,后期才发现系统边界划错了,整个HARA重做,项目延期了两个月。嗯,从那以后,我再也不敢轻视概念阶段了。

这一章,我们重点聊三件事:项目定义、HARA(危害分析与风险评估)、安全目标定义。这三步是功能安全的地基,地基不稳,后面全白搭。

3.1 项目定义:把边界画清楚

项目定义要回答一个核心问题:我们到底要对什么做功能安全?

我个人习惯,先拉一张表,把项目的基本信息列清楚:

项目定义要素 内容示例 常见坑点
系统名称 电动助力转向系统(EPS) 名称太宽泛,比如写“转向系统”
系统功能 提供转向助力、回正控制 漏掉非安全功能,比如诊断功能
系统边界 从方向盘扭矩传感器到齿条 边界画得太小,漏了供电和通信
外部接口 CAN总线、电源、驾驶员输入 只写电气接口,漏了机械接口
运行模式 驾驶模式、泊车模式、故障模式 漏掉故障降级模式
法规要求 UN R79、ISO 26262 只写标准号,不写具体条款
我的小技巧:项目定义阶段,我会拉上系统工程师、硬件工程师、软件工程师一起开个边界对齐会。每人拿一支笔,在白板上画自己理解的系统边界。你猜怎么着?每次都能发现至少3个理解不一致的地方。

项目定义还有一个容易被忽略的点——假设条件。比如“假设驾驶员始终手握方向盘”、“假设供电电压在9V-16V之间”。这些假设要写清楚,因为后面HARA和安全目标都依赖这些假设。如果假设变了,整个安全分析都要重新来。

3.2 HARA:危害分析与风险评估

HARA是概念阶段的重头戏。它的目标就一个:找出系统可能造成的危害,并评估风险等级。

HARA的标准流程,我一般分四步走:

  1. 功能清单梳理——列出系统的所有功能,包括安全功能和非安全功能
  2. 危害识别——对每个功能,思考“如果这个功能失效了,会发生什么?”
  3. 场景分析——在什么驾驶场景下,这个危害会导致事故?
  4. 风险等级评估——用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,团队把E参数打低了,理由是“这个场景很少见”。但后来发现,这个场景虽然单次概率低,但车辆全生命周期内出现的总次数并不少。ISO 26262要求的是“在车辆寿命内评估暴露概率”,不是“单次驾驶的概率”。从那以后,我每次评估E参数,都会先算一下“车辆跑15年,这个场景会出现多少次”。

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 概念阶段知识体系总览

下面这张图,把概念阶段的核心流程和产出串起来了。我建议你把它打印出来,做项目时贴在工位上。

概念阶段知识体系总览 项目定义 系统边界 / 功能清单 接口 / 假设条件 HARA 危害识别 / 场景分析 S/E/C评分 / ASIL等级 安全目标定义 SG描述 / ASIL继承 FTTI / 安全状态 核心产出:危害清单 + 安全目标列表 + ASIL等级分配 后续活动:功能安全概念(FSC)→ 技术安全概念(TSC) 关键评审节点:项目定义评审 → HARA评审 → 安全目标评审 💡 概念阶段的质量,直接决定后续安全活动的有效性和效率 建议投入项目总时间的15%-20%在概念阶段,不要急于进入开发

概念阶段做完,你手里应该有:一份清晰的项目定义、一份完整的危害清单、一组可验证的安全目标。这些东西看着是文档,但它们是后续所有安全工作的源头。源头错了,后面全是错的。

我记得有一次评审,项目经理问我:“概念阶段花这么多时间,值吗?”我说:“你想想看,如果地基没打好,楼盖到一半才发现要拆了重来,哪个更费时间?”他想了想,没再催进度了。

给新人的建议:概念阶段不要一个人闷头写。拉上系统工程师、功能安全工程师、测试工程师一起做。每个人的视角不同,能发现你一个人看不到的问题。尤其是HARA,多一个人参与,就多一双发现危害的眼睛。