个人主页云纳星辰怀自在座右铭“所谓坚持就是觉得还有希望”前言案例某BMS项目在功能安全审核时被退回审核员指出“Item Definition中没有描述与其他Item的接口依赖关系HARA分析中未识别‘电池过充’这一危害场景。”项目因此延期两个月重新补充概念阶段文档。工程师无奈“我们直接从安全目标开始写的以为概念阶段只是走个过场。”在ISO 26262功能安全开发中概念阶段Concept Phase是整个V模型开发流程的起点位于V模型左侧的最顶层。它的核心使命是在相对抽象的逻辑功能层面通过安全分析提出功能安全开发最初的安全需求。概念阶段的质量决定了所有后续活动的方向和严格程度——概念阶段的缺陷会像滚雪球一样被后续阶段放大。本文将从工程实战角度彻底讲透概念阶段的四大工作包工作包1Item Definition相关项定义——界定研究对象为HARA提供唯一输入工作包2Initiation of Safety Lifecycle安全生命周期启动——判定开发类别合理裁剪流程工作包3HARA危害分析与风险评估——识别危害事件量化ASIL等级导出安全目标工作包4FSC功能安全概念——从安全目标推导功能安全需求FSR完整流程图与交付物清单——可直接作为项目SOP使用适用读者功能安全工程师、系统架构师、项目经理、审核准备人员适用标准ISO 26262-2018 Part 3适用场景新项目功能安全启动、HARA分析、概念阶段审核准备更新时间2026年8月一、先说结论概念阶段决定整个功能安全项目的成败容易混淆的说法正确理解概念阶段只是走个过场直接从安全目标开始写就行✔ Item Definition是HARA的唯一输入缺少它HARA无法开展HARA分析时可以考虑已有的安全机制✔ HARA分析时必须忽略所有安全机制否则会低估风险暴露率评价只有一种方法✔ 必须区分基于持续时间还是基于频率选错会导致ASIL偏差概念阶段做完就结束了后续不需要再回顾✔ HARA是迭代过程系统设计阶段发现新场景需回归更新裁剪就是省略部分安全活动✔ 裁剪是合理调整活动范围但裁剪理由必须以文档形式记录总结概念阶段是功能安全开发的地基——地基不牢后续所有工作都可能需要返工。Item Definition决定分析范围HARA决定安全目标等级FSC决定安全需求方向。任何一个环节的缺陷都会在后续阶段被指数级放大。二、概念阶段的定位与总览2.1 概念阶段在V模型中的位置┌──────────────────┐ │ ★ 概念阶段 │ ← V模型最顶层左侧起点 │ Item Definition │ ← 整车级功能需求 │ HARA → SG │ ← 顶层安全目标 │ FSC → FSR │ ← 系统级安全需求 └────────┬─────────┘ │ ↓ ┌──────────────────┐ │ 系统阶段 │ ← TSR、系统架构设计 └────────┬─────────┘ │ ┌────────────┴────────────┐ ↓ ↓ ┌───────────────┐ ┌───────────────┐ │ 硬件阶段 │ │ 软件阶段 │ └───────────────┘ └───────────────┘2.2 概念阶段包含的四大工作包Ref.STEPWP of Concept Phase3-5Item DefinitionSpecification of the scope of the item3-6Initiation of the safety lifecycleInfluence analysis and tailoring of safety lifecycleA refined version of the safety plan3-7Hazard Analysis and Risk Assessment(HARA)HARA(ASIL)SGsVerification review report of HARA and SGsIndependent assessment of the results3-8FSCFSCVerification report of FSC2.3 概念阶段与后续阶段的关系概念阶段输出 → 后续阶段输入 ───────────────────────────────────────────────── Item Definition → 系统架构设计、HSI定义 安全目标SG → 功能安全需求FSR的源头 功能安全需求FSR → 技术安全需求TSR的源头 ASIL等级 → 硬件/软件的安全等级分配 安全状态/FTTI → 系统响应时间预算、硬件/软件时序设计三、工作包1Item Definition相关项定义3-53.1 什么是ItemItem相关项是在整车层面实现一个功能的系统或系统组合是ISO 26262应用的最顶层对象如ACC、AEB、VCU、BMS。术语层级关系Item相关项System系统Element要素Item 整车级功能如ACC范围最大System 传感器控制器执行器的完整链路如ACC前向雷达系统Element 任意组成部分范围可大可小如一个MCU、一个软件单元3.2 Item Definition的五大核心内容序号内容维度关键要求示例BMS①整车级功能描述描述Item在整车层面要实现什么功能非技术层面的细节描述“BMS实现电池状态监测、充放电管理和安全保护”②功能框图与交互关系框图展示功能要素及其交互含与其他Item之间的接口与依赖BMS与VCU、PCS、热管理系统的通信接口③环境与使用条件运行环境道路/温度/湿度、使用工况温度-40°C~85°C充电/放电/静置工况④法规与规范性要求国标、ECE法规、ISO标准等对该功能的强制性要求GB/T 34131、UN R100⑤外部风险降低措施组织或技术层面的外部措施ESP、AEB、安全气囊、灭火器非Item自身功能⚠️关键原则Item Definition应包含HARA分析所需的所有信息The item definition includes all information, which is needed for the following assessment of possible hazards!3.3 常见错误与正确做法❌ 错误做法✅ 正确做法Item Definition只写“BMS”三个字详细描述BMS的整车级功能、接口、运行模式只画内部框图不画与外部Item的接口明确标注与其他ItemVCU/PCS的接口和依赖关系忽略法规要求列出所有适用的国标、ECE法规、ISO标准把Item自身的安全机制算作外部措施外部措施指独立于Item的其他系统如ESP、安全气囊四、工作包2Initiation of Safety Lifecycle安全生命周期启动3-64.1 目的与核心任务目的根据开发类别确定后续开发路径对生命周期进行合理裁剪避免过度工程。4.2 三类开发场景的判定与处理开发类别判定标准核心活动后续路径全新Item开发无现有安全档案可参考必须执行HARAHARA结果有ASIL≥2 → 按ISO 26262完整流程全部QM → 按IATF 16949质量体系现有Item修改在既有产品基础上变更/提升执行影响分析识别影响范围驾驶场景/接口/环境→ 裁剪生命周期 → 记录理由现有Item复用至新场景部署到新整车平台或不同场景执行影响分析描述新使用条件 → 识别影响范围 → 裁剪生命周期 → 记录理由4.3 裁剪Tailoring的实操要点要点说明裁剪≠省略裁剪是合理调整活动范围不是“省略安全活动”裁剪理由必须记录裁剪理由必须以文档形式记录如记录在安全计划Safety Plan中影响分析是裁剪的基础必须先分析“变更了什么、影响了什么”再决定裁剪哪些活动4.4 HARA结果作为“分水岭”HARA分析结果 │ ├── 至少一个 ASIL ≥ B 的安全目标 │ └── ✅ 触发ISO 26262完整功能安全流程 │ → 需要系统阶段、硬件阶段、软件阶段的完整安全活动 │ → 需要功能安全审核、评估 │ └── 全部为 QMASIL A/B/C/D均无 └── ✅ 仅需标准质量管理体系IATF 16949开发 → 无需功能安全专项活动五、工作包3HARA危害分析与风险评估3-75.1 目的识别危害事件量化风险等级ASIL导出顶层安全目标Safety Goal。5.2 HARA的完整四步法Step 1危害分析 → 方法HAZOP引导词 → 输出整车级危害列表 Step 2场景识别 → 三维度运行模式操作场景环境条件 → 输出运行场景集 Step 3风险评估 → S严重度 E暴露率 C可控性→ ASIL Step 4分析整理 → 危害事件 → 安全目标SG ASIL分配5.3 Step 1危害分析HAZOPHAZOP引导词SAE J2980引导词含义示例转向功能Loss of Function功能丧失有转向需求时不转向More than intended大于/多于预期转向角度过大Less than intended小于/少于预期转向角度不足Wrong direction方向相反左转时右转Unintended Activation非预期激活无需求时自行转向Output Stuck输出卡滞转向指令无法更新关键原则原则说明危害必须定义在整车层面如“非预期加速”而非“扭矩输出过大”不考虑将要实施或已有的安全机制避免乐观偏差HARA是“裸风险”分析仅考虑Item自身功能异常假设其他Item正常工作结果可复现不同分析人员应得出类似结论5.4 Step 2场景识别三维度综合识别维度内容示例Operating Modes运行模式车辆当前的工作状态充电模式、行驶模式、驻车模式Operational Situations操作场景驾驶员的操作行为加速、刹车、转向、泊车Environmental Conditions环境条件外部环境因素高速/城市、雨/雪/雾、白天/夜间关键原则原则说明兼顾正确使用和合理可预见的误用如“把油门当刹车”属于合理误用场景粒度需合理过细可能导致暴露率E降低无形降低ASIL等级可参考VDA 702典型场景库结合目标市场数据持续扩充5.5 Step 3风险评估S/E/C → ASILSeverityS严重度等级定义示例S0无伤害轻微不适S1轻伤需要医疗处理但无长期影响S2重伤需住院治疗有长期影响S3致命危及生命或致命伤害关键原则评估对人的伤害非物体损坏保守按最坏情况评分。ExposureE暴露率等级定义示例E0极低几乎不会发生E1低每年几次E2中每月几次E3高每周几次E4极高几乎每次驾驶⚠️ 关键区分——暴露率评价方式的选择评价方式适用条件评价依据示例基于持续时间Duration功能故障直接导致危害场景在总运行时间中的占比高速行驶时EPS故障→偏离路径基于频率Frequency故障已发生需结合特定场景才暴露场景发生频率车灯故障在前进入隧道时才暴露⚠️选错评价方式ASIL等级可能直接偏差一个级别ControllabilityC可控性等级定义说明C0完全可控所有驾驶员都能避免伤害C1简单可控多数驾驶员能避免伤害C2一般可控部分驾驶员能避免伤害C3难以控制大多数驾驶员无法避免伤害关键原则含驾驶员周围人员的控制能力C2/C3需基于用户测试数据而非主观判断ASIL等级判定简易计算法SEC值ASIL等级10ASIL D9ASIL C8ASIL B7ASIL A 7QM5.6 Step 4分析整理活动说明每个危害事件对应一个安全目标一对一映射或一对多合并类似安全目标可合并继承最高ASIL等级安全目标描述整车层级的功能性、目的性表述安全状态若安全目标通过转移/保持到安全状态实现须明确对应安全状态5.7 HARA的输出物输出物说明① HARA报告含S/E/C评估依据、ASIL判定② 安全目标清单SGs所有安全目标的集合③验证评审报告Verification review report of HARA and SGs④独立评估结果Independent assessment of the results后两项强调了HARA不是个人分析而是需要系统化验证和独立评估的正式工程活动。5.8 HARA示例VCU驱动扭矩控制要素内容ItemVCU驱动扭矩控制危害HAZOP非预期加速Unintended Acceleration场景高速行驶80km/h跟车场景S评级S2高速碰撞风险E评级E4高速行驶频繁C评级C2有经验的驾驶员可部分控制ASILASIL C安全目标防止非预期加速导致碰撞六、工作包4FSC功能安全概念3-86.1 目的基于安全目标推导功能安全需求FSR系统化形成功能安全方案。6.2 FSC的核心活动核心活动说明示例VCU驱动扭矩推导FSR将安全目标分解为功能安全需求分配到系统架构要素FSR-1检测加速踏板信号合理性ASIL C定义安全状态失效发生后应转移到的安全运行模式驱动扭矩归零车辆进入滑行/蠕行模式定义FTTIFault Tolerant Time Interval — 从失效发生到进入安全状态的最大允许时间FTTI ≤ 100ms定义紧急运行时间失效后、进入安全状态前的过渡时间≤ 50ms架构分配将FSR分配至系统架构中的具体要素硬件/软件FSR-1分配给VCU传感器信号处理模块6.3 HARA到FSC的完整链路HARA输出 危害事件高速巡航时非预期加速导致碰撞 ASIL等级ASIL C 安全目标防止非预期加速 ↓ FSC推导 FSR-1系统应检测加速踏板传感器信号是否合理ASIL C FSR-2当检测到非预期加速时应在50ms内关闭驱动扭矩输出ASIL C 安全状态驱动扭矩归零车辆进入滑行模式 FTTI≤ 100ms 架构分配FSR-1→VCU信号处理模块FSR-2→VCU执行器控制模块6.4 FSC的输出物输出物说明① 功能安全需求FSR清单每条FSR含ASIL等级、FTTI、安全状态② 安全状态定义每种失效场景对应的安全运行模式③ FTTI定义每条安全相关时间链路的容错时间间隔④ 架构分配FSR与系统架构要素的映射关系⑤ FSC验证报告验证FSR是否覆盖所有安全目标七、概念阶段完整流程图与V模型映射7.1 概念阶段完整流程图┌─────────────────────────────────────────────────────────────────────────┐ │ 概念阶段完整工作流程 │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-5 Item Definition相关项定义 │ │ │ │ ├─ 整车级功能描述 │ │ │ │ ├─ 功能框图 接口/依赖关系 │ │ │ │ ├─ 环境与使用条件 │ │ │ │ ├─ 法规要求 │ │ │ │ └─ 外部风险降低措施 │ │ │ └───────────────────────────┬───────────────────────────────────────┘ │ │ ↓ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-6 Initiation of Safety Lifecycle安全生命周期启动 │ │ │ │ ├─ 判定开发类别全新 / 修改 / 复用 │ │ │ │ ├─ 修改/复用 → 影响分析 → 裁剪生命周期 │ │ │ │ └─ 裁剪理由记录于安全计划Safety Plan │ │ │ └───────────────────────────┬───────────────────────────────────────┘ │ │ ↓ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-7 HARA危害分析与风险评估 │ │ │ │ ├─ Step 1危害分析HAZOP引导词 │ │ │ │ ├─ Step 2场景识别运行模式操作场景环境条件 │ │ │ │ ├─ Step 3风险评估S/E/C → ASIL │ │ │ │ └─ Step 4分析整理 → 安全目标SG │ │ │ │ 输出HARA报告 安全目标 验证评审 独立评估 │ │ │ └───────────────────────────┬───────────────────────────────────────┘ │ │ ↓ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-8 FSC功能安全概念 │ │ │ │ ├─ 安全目标 → 功能安全需求FSR │ │ │ │ ├─ 定义安全状态 │ │ │ │ ├─ 定义FTTI容错时间间隔 │ │ │ │ ├─ 定义紧急运行时间 │ │ │ │ └─ FSR分配至系统架构要素 │ │ │ └───────────────────────────────────────────────────────────────────┘ │ │ │ │ ↓ 进入系统阶段技术安全需求 TSR / 硬件安全需求 HSR / 软件安全需求 SSR│ └─────────────────────────────────────────────────────────────────────────┘7.2 概念阶段输出与后续阶段的衔接概念阶段输出 → 后续阶段输入 ───────────────────────────────────────────────── Item Definition → 系统架构设计系统边界定义 安全目标SG → 系统阶段的技术安全需求TSR 功能安全需求FSR → 硬件安全需求HSR和软件安全需求SSR ASIL等级 → 硬件/软件的ASIL等级分配 安全状态/FTTI → 系统响应时间预算、硬件/软件时序设计八、核心原则汇总与交付物清单8.1 核心原则汇总序号核心原则1概念阶段是功能安全开发的起点决定了所有后续活动的方向和严格程度2Item Definition是HARA的唯一输入必须包含HARA所需的所有信息3Item的边界定义必须基于整车级功能而非技术实现4开发类别全新/修改/复用决定后续流程范围裁剪理由须正式记录5HARA是分水岭ASIL≥2触发完整功能安全流程QM级仅需质量管理体系6HARA分析时不考虑安全机制危害必须定义在整车层面7暴露率评价必须区分基于持续时间还是基于频率选错直接导致ASIL偏差8可控性评估需同时考虑故障车辆驾驶员和周围交通参与者9HARA是迭代过程ASIL定级需与既有系统经验对照必要时调整10HARA结果需要验证评审和独立评估非个人分析活动8.2 概念阶段各工作包交付物汇总工作包交付物3-5 Item Definition相关项定义说明书含功能描述、框图、接口、法规、环境条件、外部措施3-6 Safety Lifecycle Initiation影响分析报告、裁剪的安全计划含裁剪理由3-7 HARAHARA报告、安全目标清单SGs、验证评审报告、独立评估报告3-8 FSC功能安全概念FSC、功能安全需求FSR、安全状态定义、FTTI定义、FSC验证报告8.3 概念阶段评审检查清单检查项说明状态□ Item Definition是否包含所有HARA所需信息功能描述、框图、接口、法规、外部措施□ 是否明确了开发类别全新/修改/复用影响分析结果□ 裁剪理由是否记录在安全计划中不能口头说明□ HARA是否考虑了所有HAZOP引导词Loss/More/Less/Wrong/Unintended/Stuck□ 危害是否定义在整车层面非技术层面□ HARA分析是否忽略了安全机制不能考虑已有或将要实施的安全机制□ 暴露率评价方式是否正确区分Duration/Frequency选错导致ASIL偏差□ 每个危害事件是否都对应了安全目标一对一或合并继承最高ASIL□ FSR是否覆盖了所有安全目标追溯完整性□ FTTI是否明确量化有具体数值九、总结与面试高频考点9.1 核心结论表要点结论概念阶段的定位V模型开发流程的起点位于V模型左侧最顶层四大工作包Item Definition → Initiation → HARA → FSCItem Definition的作用为HARA提供唯一输入界定研究对象范围HARA的本质分析裸风险不考虑安全机制危害定义在整车层面ASIL判定三要素S严重度 E暴露率 C可控性E评价的关键区分Duration故障直接导致vsFrequency需结合场景HARA结果ASIL≥2触发完整功能安全流程全部QM仅需质量管理体系FSC的核心安全目标 → FSR功能安全需求 安全状态 FTTI审核必查验证评审 独立评估 完整追溯链9.2 面试高频考点问题标准回答概念阶段包含哪四个工作包3-5 Item Definition、3-6 Initiation of Safety Lifecycle、3-7 HARA、3-8 FSCItem和System的区别Item是整车级功能如ACCSystem是传感器控制器执行器的完整链路ItemSystemElementHARA分析时应不应该考虑安全机制不应该HARA分析的是“裸风险”考虑安全机制会导致风险被低估暴露率评价的两种方式怎么选功能故障直接导致危害→用Duration故障需结合特定场景才暴露→用FrequencyHARA结果ASIL≥2意味着什么触发ISO 26262完整功能安全流程全部QM则仅需IATF 16949质量管理体系FSR和SG的关系SG是顶层安全目标FSR是SG分解出的功能安全需求——SG是“为什么安全”FSR是“怎么做才安全”FTTI和紧急运行时间的区别FTTI是从失效发生到进入安全状态的最大允许时间紧急运行时间是进入安全状态前的过渡时间十、参考资料ISO 26262-2018. Road vehicles — Functional safety. Part 3: Concept phase.SAE J2980. Considerations for ISO 26262 ASIL Hazard Classification.VDA 702. Typical scenarios for HARA.AUTOSAR. Functional Safety Concept Template Specification.参考文章ISO26262系列: FSR到TSR转化ISO26262系列: MISRA C与汽车软件的安全工程学ISO26262系列: 故障注入硬件注入与软件注入完整对比ISO26262功能安全系列: 技术安全需求TSR编写 ISO26262功能安全系列: Concept Phase工作项指南
个人主页云纳星辰怀自在座右铭“所谓坚持就是觉得还有希望”前言案例某BMS项目在功能安全审核时被退回审核员指出“Item Definition中没有描述与其他Item的接口依赖关系HARA分析中未识别‘电池过充’这一危害场景。”项目因此延期两个月重新补充概念阶段文档。工程师无奈“我们直接从安全目标开始写的以为概念阶段只是走个过场。”在ISO 26262功能安全开发中概念阶段Concept Phase是整个V模型开发流程的起点位于V模型左侧的最顶层。它的核心使命是在相对抽象的逻辑功能层面通过安全分析提出功能安全开发最初的安全需求。概念阶段的质量决定了所有后续活动的方向和严格程度——概念阶段的缺陷会像滚雪球一样被后续阶段放大。本文将从工程实战角度彻底讲透概念阶段的四大工作包工作包1Item Definition相关项定义——界定研究对象为HARA提供唯一输入工作包2Initiation of Safety Lifecycle安全生命周期启动——判定开发类别合理裁剪流程工作包3HARA危害分析与风险评估——识别危害事件量化ASIL等级导出安全目标工作包4FSC功能安全概念——从安全目标推导功能安全需求FSR完整流程图与交付物清单——可直接作为项目SOP使用适用读者功能安全工程师、系统架构师、项目经理、审核准备人员适用标准ISO 26262-2018 Part 3适用场景新项目功能安全启动、HARA分析、概念阶段审核准备更新时间2026年8月一、先说结论概念阶段决定整个功能安全项目的成败容易混淆的说法正确理解概念阶段只是走个过场直接从安全目标开始写就行✔ Item Definition是HARA的唯一输入缺少它HARA无法开展HARA分析时可以考虑已有的安全机制✔ HARA分析时必须忽略所有安全机制否则会低估风险暴露率评价只有一种方法✔ 必须区分基于持续时间还是基于频率选错会导致ASIL偏差概念阶段做完就结束了后续不需要再回顾✔ HARA是迭代过程系统设计阶段发现新场景需回归更新裁剪就是省略部分安全活动✔ 裁剪是合理调整活动范围但裁剪理由必须以文档形式记录总结概念阶段是功能安全开发的地基——地基不牢后续所有工作都可能需要返工。Item Definition决定分析范围HARA决定安全目标等级FSC决定安全需求方向。任何一个环节的缺陷都会在后续阶段被指数级放大。二、概念阶段的定位与总览2.1 概念阶段在V模型中的位置┌──────────────────┐ │ ★ 概念阶段 │ ← V模型最顶层左侧起点 │ Item Definition │ ← 整车级功能需求 │ HARA → SG │ ← 顶层安全目标 │ FSC → FSR │ ← 系统级安全需求 └────────┬─────────┘ │ ↓ ┌──────────────────┐ │ 系统阶段 │ ← TSR、系统架构设计 └────────┬─────────┘ │ ┌────────────┴────────────┐ ↓ ↓ ┌───────────────┐ ┌───────────────┐ │ 硬件阶段 │ │ 软件阶段 │ └───────────────┘ └───────────────┘2.2 概念阶段包含的四大工作包Ref.STEPWP of Concept Phase3-5Item DefinitionSpecification of the scope of the item3-6Initiation of the safety lifecycleInfluence analysis and tailoring of safety lifecycleA refined version of the safety plan3-7Hazard Analysis and Risk Assessment(HARA)HARA(ASIL)SGsVerification review report of HARA and SGsIndependent assessment of the results3-8FSCFSCVerification report of FSC2.3 概念阶段与后续阶段的关系概念阶段输出 → 后续阶段输入 ───────────────────────────────────────────────── Item Definition → 系统架构设计、HSI定义 安全目标SG → 功能安全需求FSR的源头 功能安全需求FSR → 技术安全需求TSR的源头 ASIL等级 → 硬件/软件的安全等级分配 安全状态/FTTI → 系统响应时间预算、硬件/软件时序设计三、工作包1Item Definition相关项定义3-53.1 什么是ItemItem相关项是在整车层面实现一个功能的系统或系统组合是ISO 26262应用的最顶层对象如ACC、AEB、VCU、BMS。术语层级关系Item相关项System系统Element要素Item 整车级功能如ACC范围最大System 传感器控制器执行器的完整链路如ACC前向雷达系统Element 任意组成部分范围可大可小如一个MCU、一个软件单元3.2 Item Definition的五大核心内容序号内容维度关键要求示例BMS①整车级功能描述描述Item在整车层面要实现什么功能非技术层面的细节描述“BMS实现电池状态监测、充放电管理和安全保护”②功能框图与交互关系框图展示功能要素及其交互含与其他Item之间的接口与依赖BMS与VCU、PCS、热管理系统的通信接口③环境与使用条件运行环境道路/温度/湿度、使用工况温度-40°C~85°C充电/放电/静置工况④法规与规范性要求国标、ECE法规、ISO标准等对该功能的强制性要求GB/T 34131、UN R100⑤外部风险降低措施组织或技术层面的外部措施ESP、AEB、安全气囊、灭火器非Item自身功能⚠️关键原则Item Definition应包含HARA分析所需的所有信息The item definition includes all information, which is needed for the following assessment of possible hazards!3.3 常见错误与正确做法❌ 错误做法✅ 正确做法Item Definition只写“BMS”三个字详细描述BMS的整车级功能、接口、运行模式只画内部框图不画与外部Item的接口明确标注与其他ItemVCU/PCS的接口和依赖关系忽略法规要求列出所有适用的国标、ECE法规、ISO标准把Item自身的安全机制算作外部措施外部措施指独立于Item的其他系统如ESP、安全气囊四、工作包2Initiation of Safety Lifecycle安全生命周期启动3-64.1 目的与核心任务目的根据开发类别确定后续开发路径对生命周期进行合理裁剪避免过度工程。4.2 三类开发场景的判定与处理开发类别判定标准核心活动后续路径全新Item开发无现有安全档案可参考必须执行HARAHARA结果有ASIL≥2 → 按ISO 26262完整流程全部QM → 按IATF 16949质量体系现有Item修改在既有产品基础上变更/提升执行影响分析识别影响范围驾驶场景/接口/环境→ 裁剪生命周期 → 记录理由现有Item复用至新场景部署到新整车平台或不同场景执行影响分析描述新使用条件 → 识别影响范围 → 裁剪生命周期 → 记录理由4.3 裁剪Tailoring的实操要点要点说明裁剪≠省略裁剪是合理调整活动范围不是“省略安全活动”裁剪理由必须记录裁剪理由必须以文档形式记录如记录在安全计划Safety Plan中影响分析是裁剪的基础必须先分析“变更了什么、影响了什么”再决定裁剪哪些活动4.4 HARA结果作为“分水岭”HARA分析结果 │ ├── 至少一个 ASIL ≥ B 的安全目标 │ └── ✅ 触发ISO 26262完整功能安全流程 │ → 需要系统阶段、硬件阶段、软件阶段的完整安全活动 │ → 需要功能安全审核、评估 │ └── 全部为 QMASIL A/B/C/D均无 └── ✅ 仅需标准质量管理体系IATF 16949开发 → 无需功能安全专项活动五、工作包3HARA危害分析与风险评估3-75.1 目的识别危害事件量化风险等级ASIL导出顶层安全目标Safety Goal。5.2 HARA的完整四步法Step 1危害分析 → 方法HAZOP引导词 → 输出整车级危害列表 Step 2场景识别 → 三维度运行模式操作场景环境条件 → 输出运行场景集 Step 3风险评估 → S严重度 E暴露率 C可控性→ ASIL Step 4分析整理 → 危害事件 → 安全目标SG ASIL分配5.3 Step 1危害分析HAZOPHAZOP引导词SAE J2980引导词含义示例转向功能Loss of Function功能丧失有转向需求时不转向More than intended大于/多于预期转向角度过大Less than intended小于/少于预期转向角度不足Wrong direction方向相反左转时右转Unintended Activation非预期激活无需求时自行转向Output Stuck输出卡滞转向指令无法更新关键原则原则说明危害必须定义在整车层面如“非预期加速”而非“扭矩输出过大”不考虑将要实施或已有的安全机制避免乐观偏差HARA是“裸风险”分析仅考虑Item自身功能异常假设其他Item正常工作结果可复现不同分析人员应得出类似结论5.4 Step 2场景识别三维度综合识别维度内容示例Operating Modes运行模式车辆当前的工作状态充电模式、行驶模式、驻车模式Operational Situations操作场景驾驶员的操作行为加速、刹车、转向、泊车Environmental Conditions环境条件外部环境因素高速/城市、雨/雪/雾、白天/夜间关键原则原则说明兼顾正确使用和合理可预见的误用如“把油门当刹车”属于合理误用场景粒度需合理过细可能导致暴露率E降低无形降低ASIL等级可参考VDA 702典型场景库结合目标市场数据持续扩充5.5 Step 3风险评估S/E/C → ASILSeverityS严重度等级定义示例S0无伤害轻微不适S1轻伤需要医疗处理但无长期影响S2重伤需住院治疗有长期影响S3致命危及生命或致命伤害关键原则评估对人的伤害非物体损坏保守按最坏情况评分。ExposureE暴露率等级定义示例E0极低几乎不会发生E1低每年几次E2中每月几次E3高每周几次E4极高几乎每次驾驶⚠️ 关键区分——暴露率评价方式的选择评价方式适用条件评价依据示例基于持续时间Duration功能故障直接导致危害场景在总运行时间中的占比高速行驶时EPS故障→偏离路径基于频率Frequency故障已发生需结合特定场景才暴露场景发生频率车灯故障在前进入隧道时才暴露⚠️选错评价方式ASIL等级可能直接偏差一个级别ControllabilityC可控性等级定义说明C0完全可控所有驾驶员都能避免伤害C1简单可控多数驾驶员能避免伤害C2一般可控部分驾驶员能避免伤害C3难以控制大多数驾驶员无法避免伤害关键原则含驾驶员周围人员的控制能力C2/C3需基于用户测试数据而非主观判断ASIL等级判定简易计算法SEC值ASIL等级10ASIL D9ASIL C8ASIL B7ASIL A 7QM5.6 Step 4分析整理活动说明每个危害事件对应一个安全目标一对一映射或一对多合并类似安全目标可合并继承最高ASIL等级安全目标描述整车层级的功能性、目的性表述安全状态若安全目标通过转移/保持到安全状态实现须明确对应安全状态5.7 HARA的输出物输出物说明① HARA报告含S/E/C评估依据、ASIL判定② 安全目标清单SGs所有安全目标的集合③验证评审报告Verification review report of HARA and SGs④独立评估结果Independent assessment of the results后两项强调了HARA不是个人分析而是需要系统化验证和独立评估的正式工程活动。5.8 HARA示例VCU驱动扭矩控制要素内容ItemVCU驱动扭矩控制危害HAZOP非预期加速Unintended Acceleration场景高速行驶80km/h跟车场景S评级S2高速碰撞风险E评级E4高速行驶频繁C评级C2有经验的驾驶员可部分控制ASILASIL C安全目标防止非预期加速导致碰撞六、工作包4FSC功能安全概念3-86.1 目的基于安全目标推导功能安全需求FSR系统化形成功能安全方案。6.2 FSC的核心活动核心活动说明示例VCU驱动扭矩推导FSR将安全目标分解为功能安全需求分配到系统架构要素FSR-1检测加速踏板信号合理性ASIL C定义安全状态失效发生后应转移到的安全运行模式驱动扭矩归零车辆进入滑行/蠕行模式定义FTTIFault Tolerant Time Interval — 从失效发生到进入安全状态的最大允许时间FTTI ≤ 100ms定义紧急运行时间失效后、进入安全状态前的过渡时间≤ 50ms架构分配将FSR分配至系统架构中的具体要素硬件/软件FSR-1分配给VCU传感器信号处理模块6.3 HARA到FSC的完整链路HARA输出 危害事件高速巡航时非预期加速导致碰撞 ASIL等级ASIL C 安全目标防止非预期加速 ↓ FSC推导 FSR-1系统应检测加速踏板传感器信号是否合理ASIL C FSR-2当检测到非预期加速时应在50ms内关闭驱动扭矩输出ASIL C 安全状态驱动扭矩归零车辆进入滑行模式 FTTI≤ 100ms 架构分配FSR-1→VCU信号处理模块FSR-2→VCU执行器控制模块6.4 FSC的输出物输出物说明① 功能安全需求FSR清单每条FSR含ASIL等级、FTTI、安全状态② 安全状态定义每种失效场景对应的安全运行模式③ FTTI定义每条安全相关时间链路的容错时间间隔④ 架构分配FSR与系统架构要素的映射关系⑤ FSC验证报告验证FSR是否覆盖所有安全目标七、概念阶段完整流程图与V模型映射7.1 概念阶段完整流程图┌─────────────────────────────────────────────────────────────────────────┐ │ 概念阶段完整工作流程 │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-5 Item Definition相关项定义 │ │ │ │ ├─ 整车级功能描述 │ │ │ │ ├─ 功能框图 接口/依赖关系 │ │ │ │ ├─ 环境与使用条件 │ │ │ │ ├─ 法规要求 │ │ │ │ └─ 外部风险降低措施 │ │ │ └───────────────────────────┬───────────────────────────────────────┘ │ │ ↓ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-6 Initiation of Safety Lifecycle安全生命周期启动 │ │ │ │ ├─ 判定开发类别全新 / 修改 / 复用 │ │ │ │ ├─ 修改/复用 → 影响分析 → 裁剪生命周期 │ │ │ │ └─ 裁剪理由记录于安全计划Safety Plan │ │ │ └───────────────────────────┬───────────────────────────────────────┘ │ │ ↓ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-7 HARA危害分析与风险评估 │ │ │ │ ├─ Step 1危害分析HAZOP引导词 │ │ │ │ ├─ Step 2场景识别运行模式操作场景环境条件 │ │ │ │ ├─ Step 3风险评估S/E/C → ASIL │ │ │ │ └─ Step 4分析整理 → 安全目标SG │ │ │ │ 输出HARA报告 安全目标 验证评审 独立评估 │ │ │ └───────────────────────────┬───────────────────────────────────────┘ │ │ ↓ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-8 FSC功能安全概念 │ │ │ │ ├─ 安全目标 → 功能安全需求FSR │ │ │ │ ├─ 定义安全状态 │ │ │ │ ├─ 定义FTTI容错时间间隔 │ │ │ │ ├─ 定义紧急运行时间 │ │ │ │ └─ FSR分配至系统架构要素 │ │ │ └───────────────────────────────────────────────────────────────────┘ │ │ │ │ ↓ 进入系统阶段技术安全需求 TSR / 硬件安全需求 HSR / 软件安全需求 SSR│ └─────────────────────────────────────────────────────────────────────────┘7.2 概念阶段输出与后续阶段的衔接概念阶段输出 → 后续阶段输入 ───────────────────────────────────────────────── Item Definition → 系统架构设计系统边界定义 安全目标SG → 系统阶段的技术安全需求TSR 功能安全需求FSR → 硬件安全需求HSR和软件安全需求SSR ASIL等级 → 硬件/软件的ASIL等级分配 安全状态/FTTI → 系统响应时间预算、硬件/软件时序设计八、核心原则汇总与交付物清单8.1 核心原则汇总序号核心原则1概念阶段是功能安全开发的起点决定了所有后续活动的方向和严格程度2Item Definition是HARA的唯一输入必须包含HARA所需的所有信息3Item的边界定义必须基于整车级功能而非技术实现4开发类别全新/修改/复用决定后续流程范围裁剪理由须正式记录5HARA是分水岭ASIL≥2触发完整功能安全流程QM级仅需质量管理体系6HARA分析时不考虑安全机制危害必须定义在整车层面7暴露率评价必须区分基于持续时间还是基于频率选错直接导致ASIL偏差8可控性评估需同时考虑故障车辆驾驶员和周围交通参与者9HARA是迭代过程ASIL定级需与既有系统经验对照必要时调整10HARA结果需要验证评审和独立评估非个人分析活动8.2 概念阶段各工作包交付物汇总工作包交付物3-5 Item Definition相关项定义说明书含功能描述、框图、接口、法规、环境条件、外部措施3-6 Safety Lifecycle Initiation影响分析报告、裁剪的安全计划含裁剪理由3-7 HARAHARA报告、安全目标清单SGs、验证评审报告、独立评估报告3-8 FSC功能安全概念FSC、功能安全需求FSR、安全状态定义、FTTI定义、FSC验证报告8.3 概念阶段评审检查清单检查项说明状态□ Item Definition是否包含所有HARA所需信息功能描述、框图、接口、法规、外部措施□ 是否明确了开发类别全新/修改/复用影响分析结果□ 裁剪理由是否记录在安全计划中不能口头说明□ HARA是否考虑了所有HAZOP引导词Loss/More/Less/Wrong/Unintended/Stuck□ 危害是否定义在整车层面非技术层面□ HARA分析是否忽略了安全机制不能考虑已有或将要实施的安全机制□ 暴露率评价方式是否正确区分Duration/Frequency选错导致ASIL偏差□ 每个危害事件是否都对应了安全目标一对一或合并继承最高ASIL□ FSR是否覆盖了所有安全目标追溯完整性□ FTTI是否明确量化有具体数值九、总结与面试高频考点9.1 核心结论表要点结论概念阶段的定位V模型开发流程的起点位于V模型左侧最顶层四大工作包Item Definition → Initiation → HARA → FSCItem Definition的作用为HARA提供唯一输入界定研究对象范围HARA的本质分析裸风险不考虑安全机制危害定义在整车层面ASIL判定三要素S严重度 E暴露率 C可控性E评价的关键区分Duration故障直接导致vsFrequency需结合场景HARA结果ASIL≥2触发完整功能安全流程全部QM仅需质量管理体系FSC的核心安全目标 → FSR功能安全需求 安全状态 FTTI审核必查验证评审 独立评估 完整追溯链9.2 面试高频考点问题标准回答概念阶段包含哪四个工作包3-5 Item Definition、3-6 Initiation of Safety Lifecycle、3-7 HARA、3-8 FSCItem和System的区别Item是整车级功能如ACCSystem是传感器控制器执行器的完整链路ItemSystemElementHARA分析时应不应该考虑安全机制不应该HARA分析的是“裸风险”考虑安全机制会导致风险被低估暴露率评价的两种方式怎么选功能故障直接导致危害→用Duration故障需结合特定场景才暴露→用FrequencyHARA结果ASIL≥2意味着什么触发ISO 26262完整功能安全流程全部QM则仅需IATF 16949质量管理体系FSR和SG的关系SG是顶层安全目标FSR是SG分解出的功能安全需求——SG是“为什么安全”FSR是“怎么做才安全”FTTI和紧急运行时间的区别FTTI是从失效发生到进入安全状态的最大允许时间紧急运行时间是进入安全状态前的过渡时间十、参考资料ISO 26262-2018. Road vehicles — Functional safety. Part 3: Concept phase.SAE J2980. Considerations for ISO 26262 ASIL Hazard Classification.VDA 702. Typical scenarios for HARA.AUTOSAR. Functional Safety Concept Template Specification.参考文章ISO26262系列: FSR到TSR转化ISO26262系列: MISRA C与汽车软件的安全工程学ISO26262系列: 故障注入硬件注入与软件注入完整对比ISO26262功能安全系列: 技术安全需求TSR编写