课程导入:学习目标、课程结构、ISO 26262整体框架与功能安全基本概念

欢迎进入《ISO 26262概念阶段与功能安全》课程的第一章。在正式开始学习之前,我们需要先回答三个根本性问题:为什么要学这门课?这门课怎么学?以及ISO 26262到底在讲什么?功能安全并非一个孤立的工程活动,它贯穿于整车电子电气系统的需求定义、系统设计、硬件开发、软件开发、生产运维直至报废回收的全生命周期。本章作为整个课程的基石,将帮助你建立对ISO 26262标准的整体认知框架,明确概念阶段在标准体系中的位置与作用,并掌握功能安全的核心术语与底层逻辑。无论你是系统工程师、软件工程师、硬件工程师、项目经理还是质量管理人员,本章内容都将为你后续深入学习各个阶段提供必要的知识锚点。

ISO 26262 整体框架与概念阶段定位 ISO 26262 全生命周期(Part 2 管理 / Part 3 概念 / Part 4 系统 / Part 5 硬件 / Part 6 软件 / Part 7 生产运维) 功能安全管理 · 概念阶段 · 系统级开发 · 硬件级开发 · 软件级开发 · 生产与运行 概念阶段(Part 3) 本章聚焦:项目定义 → 安全生命周期 → 危害分析与风险评估(HARA)→ 功能安全概念(FSC) 1. 相关项定义 Item Definition 边界、功能、接口、环境 2. 危害分析与风险评估 HARA S / E / C → ASIL等级 3. 功能安全概念 FSC 安全目标、安全状态、FSR 输出:安全目标(Safety Goals) + 功能安全需求(FSR) 分配给系统级架构,进入系统阶段(Part 4) ASIL等级:A(最低)→ B → C → D(最高) | QM(无安全要求) | 由S(严重度)、E(暴露率)、C(可控性)综合评定

1.1 学习目标与课程结构设计

本课程共30章,按照ISO 26262标准的核心逻辑链条组织,从概念阶段出发,逐步深入到系统、硬件、软件、支持流程及生产运维。第一章作为课程导入,需要你完成以下学习目标:第一,理解ISO 26262标准的整体架构与Part 1至Part 12的对应关系;第二,掌握功能安全的基本术语,包括安全、风险、危害、ASIL等核心概念;第三,明确概念阶段(Part 3)在标准中的位置及其输入输出;第四,建立"安全生命周期"的思维模式,理解V模型与安全活动的关系。

课程结构遵循"总-分-总"的认知规律。前5章聚焦概念阶段,包括本章导入、相关项定义、HARA方法论、安全目标与功能安全概念、以及概念阶段的评审与确认。第6至15章进入系统级开发(Part 4),涵盖技术安全概念、系统架构设计、安全机制、集成与测试。第16至22章深入硬件与软件开发(Part 5/6),讲解硬件随机失效度量、软件安全需求、软件架构设计等。第23至27章覆盖支持流程(Part 8)与ASIL分解、安全文化、确认措施。最后3章讨论生产运维(Part 7)与功能安全审核。每一章都包含理论讲解、案例拆解、常见误区与实战练习,确保学以致用。

学习建议:本课程强调"标准条款+工程实践"的双轨学习。建议你在学习每一章时,手边准备一份ISO 26262标准原文(或至少是Part 3的条款清单),对照标准条款阅读本课程内容,并尝试将标准语言转化为你所在企业的实际工程语言。例如,标准中的"相关项(Item)"在你的项目中可能对应一个"域控制器"或"ADAS摄像头模组"。

1.2 ISO 26262标准整体框架

ISO 26262《道路车辆——功能安全》是国际标准化组织(ISO)专门针对汽车电子电气系统制定的功能安全标准,其前身是IEC 61508(工业领域功能安全基础标准)。2018年发布的第二版(ISO 26262:2018)相比2011年第一版,新增了半导体(Part 11)和摩托车(Part 12)的指导内容,并强化了对"安全案例(Safety Case)"和"分布式开发"的要求。标准共分为12个部分,每个部分都有明确的适用范围和与其他部分的接口关系。

理解标准框架的关键在于把握两条主线:一是产品开发的技术主线(Part 3至Part 7),二是管理支持的过程主线(Part 2、Part 8、Part 9、Part 10)。技术主线遵循V模型:左侧是需求定义与设计(概念→系统→硬件/软件),右侧是集成、验证与确认(硬件/软件测试→系统集成测试→整车确认)。过程主线则贯穿始终,包括功能安全管理(Part 2)、支持过程(Part 8,如配置管理、变更管理、验证)、ASIL导向与安全分析(Part 9)、以及指南(Part 10)。

标准部分 标题 核心内容 与概念阶段的关系
Part 1 术语 定义功能安全相关术语 提供统一语言,如"安全目标"、"危害"
Part 2 功能安全管理 安全文化、组织角色、项目计划、安全案例 概念阶段需在项目计划中明确安全活动
Part 3 概念阶段 相关项定义、HARA、功能安全概念 本章核心,输出安全目标与FSR
Part 4 系统级开发 技术安全概念、系统架构、集成测试 接收FSR并细化为技术安全需求(TSR)
Part 5 硬件级开发 硬件设计、随机硬件失效度量 硬件安全需求来源于系统级分配
Part 6 软件级开发 软件安全需求、架构设计、单元测试 软件安全需求来源于系统级分配
Part 7 生产与运行 生产计划、运行维护、报废 概念阶段需考虑可生产性与可维护性
Part 8 支持过程 配置管理、变更管理、验证、文档化 概念阶段文档需纳入配置管理
Part 9 ASIL导向与安全分析 ASIL分解、冗余、相关性失效分析 HARA中确定ASIL,概念阶段可能涉及ASIL分解
Part 10 指南 标准应用的非规范性指导 提供HARA示例和解释
Part 11 半导体应用指南 半导体器件及IP的功能安全 概念阶段需考虑半导体失效模式
Part 12 摩托车 摩托车特定要求 适用时参考

从上表可以看出,概念阶段(Part 3)处于标准技术主线的起点,其输出质量直接决定了后续所有开发活动的安全完整度。如果概念阶段对危害识别不充分或ASIL等级评定错误,后期即使投入再多的测试和验证,也无法弥补设计层面的安全缺陷。这也是为什么本课程将概念阶段作为重点内容,用前5章篇幅深入讲解。

1.3 功能安全基本概念与核心术语

功能安全(Functional Safety)的定义是:"不存在由电子电气系统的功能异常表现所引起的不合理风险"。这个定义包含三个关键要素:一是"电子电气系统",即我们讨论的范围限定于E/E系统,不包括机械液压等非电子系统;二是"功能异常表现",包括系统故障(如传感器失效、软件逻辑错误)和随机硬件失效(如芯片引脚短路);三是"不合理风险",意味着并非所有风险都需要消除,而是将风险降低到可接受的合理水平。

理解功能安全需要区分几个容易混淆的概念:安全(Safety)与功能安全(Functional Safety)。安全是一个广义概念,包括碰撞安全、信息安全、功能安全等;功能安全特指由E/E系统故障导致的风险。例如,安全气囊的碰撞传感器如果误触发,属于功能安全问题;而如果车辆被黑客远程控制,则属于信息安全问题。另一个重要区分是系统安全(System Safety)与功能安全。系统安全关注整个车辆系统的安全,包括机械、液压、人机交互等;功能安全聚焦于E/E系统的随机失效和系统失效。

核心术语中,危害(Hazard)是指由相关项的功能异常表现引起的潜在伤害源;风险(Risk)是危害发生的概率与伤害严重程度的组合;安全目标(Safety Goal)是针对每个危害制定的最高层级安全要求,例如"避免车辆在行驶过程中发生非预期的加速";ASIL(Automotive Safety Integrity Level)是汽车安全完整性等级,分为A、B、C、D四个等级,D为最高等级,代表风险最高、需要最严格的安全措施。ASIL的确定基于三个参数:严重度(Severity, S)、暴露概率(Exposure, E)和可控性(Controllability, C)。

经验提醒:在项目实践中,很多团队容易将"功能安全"与"功能安全目标"混为一谈。功能安全是一个系统属性,而安全目标是具体的技术要求。例如,"车辆应能在100ms内检测到驾驶员无响应并触发紧急停车"是一个安全目标,而"功能安全"则是该目标所体现的系统整体属性。在编写安全目标时,务必使用可验证、可测量的语言,避免模糊表述。

1.4 安全生命周期与V模型

ISO 26262强调"安全生命周期(Safety Lifecycle)"的概念,即从项目启动到报废的整个过程中,安全活动必须贯穿始终。安全生命周期分为三个阶段:概念阶段(Concept Phase)、产品开发阶段(Product Development)和生产运行阶段(Production & Operation)。每个阶段都有明确的输入、活动、输出和评审节点。这种生命周期思维要求我们在项目初期就规划好安全活动,而不是在开发完成后"补做"安全分析。

V模型是理解安全生命周期与开发活动关系的经典工具。V模型的左侧是需求分解与设计:从相关项定义出发,经过HARA得到安全目标,再细化为功能安全需求(FSR),然后进入系统级开发形成技术安全需求(TSR),最后分配到硬件和软件。V模型的右侧是集成与验证:从单元测试、集成测试到系统验证、整车确认,每一层验证活动都对应左侧的某一层需求。概念阶段位于V模型的左上角,是需求链的源头。

在概念阶段,安全生命周期的主要活动包括:相关项定义(Item Definition)、危害分析与风险评估(HARA)、功能安全概念(Functional Safety Concept)。相关项定义是起点,需要明确系统的边界、功能、接口、环境条件及已知的失效模式。HARA是核心,通过系统化的方法识别危害事件并评定ASIL等级。功能安全概念则是将安全目标转化为初步的功能安全需求,包括安全机制、安全状态、故障容错策略等。这三项活动的输出将作为系统阶段(Part 4)的输入。

风险警示:许多企业在概念阶段最容易犯的错误是"跳过相关项定义直接做HARA"。没有清晰的相关项边界,HARA就会变成无源之水,导致危害识别不完整或ASIL评定失真。例如,一个ADAS摄像头模组,如果相关项定义中没有明确其与制动系统的接口关系,那么在HARA中就可能遗漏"摄像头误识别导致紧急制动"这一危害。务必先花足够时间做好相关项定义,再启动HARA。

1.5 案例拆解:从整车视角理解概念阶段

为了帮助你更直观地理解概念阶段在ISO 26262中的位置,我们以一个简化的电动汽车"电子稳定控制(ESC)"系统为例进行说明。假设某整车厂正在开发一款新型电动车,ESC系统由轮速传感器、转向角传感器、横摆角速度传感器、液压控制单元(HCU)和ESC控制单元(ECU)组成。该系统的功能是:在车辆出现转向不足或过度时,通过对单个车轮施加制动力来恢复车辆稳定性。

背景与约束:该车型定位为高端运动型轿车,最高车速250km/h,整备质量2.2吨。ESC系统需要满足ISO 26262 ASIL D等级(因为ESC失效可能导致车辆失控,严重度S3、暴露率E4、可控性C3)。项目周期为36个月,功能安全团队由3名全职安全工程师和1名功能安全经理组成。

概念阶段的关键活动与输出:

  1. 相关项定义:明确ESC系统的功能边界——它接收来自底盘域控制器的车辆状态信号,输出制动力请求给HCU。定义中特别注明:ESC系统与制动防抱死系统(ABS)共享轮速传感器,但ABS属于另一个相关项。接口包括CAN FD总线(500kbps)和私有PWM信号(用于HCU控制)。
  2. HARA分析:在干燥沥青路面(μ=0.9)、湿滑路面(μ=0.4)和冰雪路面(μ=0.2)三种典型工况下,识别出以下危害事件:
    • H1:ESC在高速弯道中误触发制动(例如传感器噪声导致),导致车辆突然减速——严重度S2(可能造成追尾),暴露率E4(高速弯道常见),可控性C2(驾驶员可部分控制)→ ASIL B
    • H2:ESC在湿滑路面失效(无任何制动干预),导致车辆转向不足冲出道路——严重度S3(可能致命),暴露率E4(湿滑路面常见),可控性C3(驾驶员难以控制)→ ASIL D
    • H3:ESC在冰雪路面过度干预,导致车辆横摆——严重度S3,暴露率E3(冰雪天气较少),可控性C3 → ASIL C
  3. 安全目标制定:基于HARA结果,制定安全目标:
    • SG1:避免ESC在非预期工况下触发制动(ASIL B)
    • SG2:避免ESC在湿滑路面完全失效(ASIL D)
    • SG3:避免ESC在低附着路面产生过度横摆(ASIL C)
  4. 功能安全概念:针对SG2(ASIL D),定义功能安全需求:
    • FSR1:ESC控制单元应能在100ms内检测到轮速传感器信号丢失,并进入降级模式(仅保留ABS功能)——ASIL D
    • FSR2:ESC控制单元应具备自检功能,在每次上电时验证液压控制单元的压力响应——ASIL D
    • FSR3:当ESC检测到内部故障时,应通过仪表盘警告灯提示驾驶员,并禁用ESC功能(安全状态)——ASIL D

结果与复盘:通过概念阶段的系统分析,团队发现H2(湿滑路面失效)是最高风险项,因此将主要安全资源投入到轮速传感器的故障检测和降级策略上。在后续系统阶段,FSR1被细化为技术安全需求,要求轮速传感器信号采用双通道冗余(两个独立霍尔传感器),并通过CAN FD发送CRC校验。这一概念阶段的决策直接影响了硬件选型和软件架构。复盘经验表明:概念阶段投入1个月的时间进行HARA和功能安全概念设计,为后续开发节省了至少3个月的返工时间。如果没有在概念阶段识别出H2的ASIL D等级,后续硬件设计可能只采用单通道传感器,导致在功能安全审核时被判定为不符合项,需要重新设计。

1.6 常见误区与总结复盘

在功能安全概念阶段的实践中,我们总结了以下常见误区,希望你在学习后续章节时引以为戒:

误区编号 常见误区 后果 正确做法
1 将ISO 26262视为"文档工作",只关注产出文档而忽视分析质量 文档与实际设计脱节,审核时发现大量"纸面安全" 将安全分析嵌入到实际工程决策中,文档是分析结果的记录而非目的
2 HARA中只分析"正常驾驶"场景,忽略边缘工况(如冰雪、爆胎、驾驶员分心) 危害识别不完整,ASIL等级偏低 建立场景库,覆盖典型工况、极端工况和故障注入工况
3 安全目标编写过于笼统,如"确保系统安全" 无法验证,无法分配到具体需求 使用SMART原则编写安全目标,明确时间、条件、可测量指标
4 概念阶段不考虑可生产性和可维护性 生产阶段发现安全机制无法实现或维护困难 在相关项定义中纳入生产、维修、报废的约束条件
5 ASIL等级评定后不进行复核 参数变化(如新增功能)导致ASIL需要调整但未调整 建立ASIL评审机制,在需求变更时重新评估

本章总结:ISO 26262概念阶段是整个功能安全工作的起点和基石。通过本章学习,你应该能够:描述ISO 26262标准的12个部分及其相互关系;解释功能安全、危害、风险、ASIL等核心术语;识别概念阶段的三项主要活动(相关项定义、HARA、功能安全概念)及其输入输出;理解安全生命周期与V模型的关系。在下一章中,我们将深入探讨相关项定义的具体方法和实践技巧,帮助你为HARA分析打下坚实基础。

课后思考:请回顾你正在参与或熟悉的汽车E/E项目,尝试回答以下问题:1)该项目的相关项边界是什么?2)如果按照ISO 26262进行HARA,你认为最严重的危害事件是什么?3)该危害事件的ASIL等级应该是多少?带着这些问题进入下一章的学习,你将更有针对性地掌握相关项定义的方法。