2. 功能安全基础

在OBC(车载充电机)的开发中,功能安全不是附加项,而是与电气性能、热管理、EMC并列的基础设计约束。理解功能安全的定义、生命周期、ASIL等级以及ISO 26262标准框架,是后续开展危害分析、安全目标设定和安全机制设计的前提。

一、功能安全的定义与核心逻辑

功能安全(Functional Safety)是指通过系统自身的功能设计,将因电子电气系统失效而导致的不可接受风险降低到可接受水平。它的核心逻辑不是“让系统不出故障”,而是“即使出现故障,系统也能进入安全状态或维持安全行为”。

对OBC而言,典型的安全相关功能包括:充电功率控制、绝缘监测、过压/过流保护、温度监控、继电器粘连检测、通信超时处理等。这些功能一旦失效,可能导致电池过充、高压触电、热失控等危害。功能安全要回答三个问题:

  • 危害是什么?——识别OBC失效可能造成的整车级危害。
  • 风险有多高?——通过ASIL等级量化风险。
  • 如何控制?——通过安全目标、安全机制和验证确认闭环。
功能安全与“可靠性”不同:可靠性关注故障发生的概率,功能安全关注故障发生后的行为是否安全。两者互补,但目标不同。

二、安全生命周期:从概念到报废的闭环

ISO 26262将功能安全活动组织为“安全生命周期”(Safety Lifecycle),覆盖从概念阶段到产品报废的全过程。对OBC项目而言,主要阶段如下:

  1. 相关项定义:明确OBC的边界、功能、接口和运行环境,例如输入为交流电网,输出为动力电池高压直流。
  2. 危害分析与风险评估:通过HARA识别危害事件,评估严重度(S)、暴露率(E)和可控性(C),确定ASIL等级。
  3. 安全目标与功能安全概念:为每个危害事件定义安全目标,并分配功能安全需求到OBC子系统或外部接口。
  4. 技术安全概念与系统设计:将功能安全需求转化为技术安全需求,设计安全机制,如过压关断、绝缘监测、看门狗等。
  5. 硬件与软件开发:按ASIL等级执行相应的开发流程、验证方法和工具链要求。
  6. 集成、验证与确认:通过测试证明安全目标被满足,包括故障注入、边界测试和整车级验证。
  7. 生产、运行、维护与报废:确保量产一致性,处理现场失效,直至产品退役。

安全生命周期的关键不是“一次性通过认证”,而是形成可追溯的证据链:从危害到安全目标,再到安全需求、设计、测试用例和验证结果,每一层都可追溯。

OBC功能安全生命周期与ASIL等级映射 从相关项定义到报废,安全活动逐层展开,ASIL等级决定开发严格度 1. 相关项定义 OBC边界/功能/接口 2. HARA S/E/C → ASIL 3. 安全目标 功能安全概念 4. 技术安全 系统/硬件/软件 5. 验证 确认与集成 ASIL等级与OBC典型安全目标对照 ASIL等级 风险程度 OBC典型安全目标 开发要求 ASIL D 最高风险 防止电池过充导致热失控 最严格,独立冗余 ASIL C 高风险 绝缘失效时切断高压输出 严格,多重安全机制 ASIL B 中等风险 充电通信超时安全停机 标准安全机制 ASIL A 低风险 充电状态指示错误告警 基础安全要求 QM 无安全要求 非安全相关功能 常规质量管理 ASIL = Automotive Safety Integrity Level,由严重度S、暴露率E、可控性C共同决定

三、ASIL等级:风险量化的标尺

ASIL(Automotive Safety Integrity Level)是ISO 26262中用于量化风险等级的核心参数,分为A、B、C、D四个等级,D级最高,另有QM表示无功能安全要求。ASIL等级由三个维度共同决定:

  • 严重度(Severity, S):S0至S3,描述危害对人员伤害的严重程度。
  • 暴露率(Exposure, E):E0至E4,描述运行场景发生的概率。
  • 可控性(Controllability, C):C0至C3,描述驾驶员或其他人员控制危害的能力。

以OBC为例:如果充电过程中绝缘失效,且车辆处于车库夜间充电场景(暴露率高),驾驶员无法及时干预(可控性低),可能导致高压触电(严重度高),则对应ASIL C或D。相反,如果仅是充电指示灯显示错误,不涉及人身伤害,则可能为QM或ASIL A。

ASIL等级 风险程度 OBC典型安全目标 开发要求
ASIL D 最高风险 防止电池过充导致热失控 最严格,独立冗余
ASIL C 高风险 绝缘失效时切断高压输出 严格,多重安全机制
ASIL B 中等风险 充电通信超时安全停机 标准安全机制
ASIL A 低风险 充电状态指示错误告警 基础安全要求
QM 无安全要求 非安全相关功能 常规质量管理
ASIL等级不是越高越好。过高的ASIL会显著增加开发成本和周期。正确的做法是通过HARA准确评估,避免“一刀切”地全部定为ASIL D。

四、ISO 26262标准框架概述

ISO 26262是道路车辆功能安全的国际标准,当前主流版本为2018版,共12个部分。与OBC开发最相关的部分包括:

  • Part 3:概念阶段——相关项定义、HARA、安全目标。
  • Part 4:系统级产品开发——技术安全需求、系统架构、安全机制。
  • Part 5:硬件级产品开发——硬件安全需求、诊断覆盖率、失效模式。
  • Part 6:软件级产品开发——软件安全需求、架构、单元设计与测试。
  • Part 8:支持过程——配置管理、变更管理、验证确认。
  • Part 9:ASIL导向与安全论证——如何证明安全目标被满足。

对OBC团队而言,ISO 26262不是“文档模板”,而是一套可裁剪的开发流程。裁剪的依据是ASIL等级和相关项的边界。例如,ASIL D的过充保护功能需要独立冗余的电压采样和关断路径,而ASIL A的告警功能则可以采用单通道设计。

五、案例与常见误区

案例:OBC过压保护的安全目标设定

某OBC项目在HARA中识别出“充电时输出电压超过电池允许上限”这一危害事件。评估结果为S3(可能引发热失控)、E4(充电场景频繁)、C2(驾驶员难以干预),对应ASIL D。由此导出安全目标:“防止OBC输出电压超过电池允许上限”,并分配技术安全需求:

安全目标 SG-01:防止OBC输出电压超过电池允许上限
ASIL等级:D
安全状态:在检测到过压后100ms内关断输出继电器
安全机制:
  - 独立电压采样通道(冗余)
  - 比较器硬件过压检测
  - 看门狗监控MCU运行状态
  - 继电器粘连检测
验证方法:故障注入测试、边界测试、整车级过压测试

常见误区:

  1. 把功能安全等同于可靠性:可靠性高不代表功能安全达标,功能安全关注的是故障后的安全行为。
  2. ASIL等级拍脑袋决定:必须通过HARA的S/E/C三维度评估,不能凭经验直接定级。
  3. 忽视安全生命周期的后期阶段:量产后的现场监控、维护和报废同样属于功能安全范围。
  4. 安全需求不可追溯:从危害到安全目标再到测试用例,必须形成完整的追溯链,否则无法通过审核。
功能安全不是“认证通过就结束”。OBC在量产后的任何设计变更,都需要重新评估对安全目标的影响,并更新相关安全分析和验证证据。