FS-05 安全目标与功能安全概念从HARA到系统架构的桥梁来源依据ISO 26262-3:2018 Clause 7.4.2、Clause 8、Clause 9系列FS系列Functional Safety|篇目FS-05/20FS-05 安全目标与功能安全概念从HARA到系统架构的桥梁一、引言从HARA到安全架构的必经之路在ISO 26262功能安全标准体系中危害分析与风险评估HARA完成了对系统潜在危害的识别与风险量化而安全目标与功能安全概念则是将这些分析结果转化为具体技术要求的桥梁。这一环节决定了系统将如何设计其安全性——从抽象的不能造成人员伤害到具体的检测到转向助力失效后200ms内进入跛行回家模式。本文将深度解析ISO 26262-3:2018 Clause 7.4.2规定的安全目标定义以及Clause 9规定的功能安全概念Functional Safety Concept, FSC开发过程为工程师提供从HARA到系统架构的完整技术路径。来源依据ISO 26262-3:2018 Clause 7.4.2、Clause 8、Clause 9二、Safety Goal安全目标顶层安全需求2.1 Safety Goal的定义与定位Safety Goal是功能安全生命周期的最高层级安全要求直接继承自HARA输出的危害事件hazard event和ASIL等级。根据ISO 26262-3:2018 Clause 7.4.2.1Safety Goal是为避免不合理风险而制定的顶层安全要求从HARA中导出的每个危害事件至少对应一个Safety Goal。Safety Goal具有以下核心特征特征说明顶层性最高层级的功能安全需求不从其他需求派生继承性直接来自HARA的危害事件和ASIL等级目标性描述期望达到的安全状态而非具体实现方式可追溯性必须能够追溯到具体的危害事件可测试性Safety Goal必须是可验证的2.2 Safety Goal的编写规范根据工程实践经验Safety Goal应遵循SMART原则-Specific具体明确具体的安全功能要求Measurable可测量有明确的量化指标Achievable可实现在现有技术条件下可行Relevant相关直接关联到危害事件Time-bound有时限有明确的响应时间要求示例对比❌不好的Safety Goal EPS系统应该安全✅符合SMART原则的Safety Goal 当车速10km/h且检测到转向助力电机失效时系统应在200ms内进入跛行回家模式维持最小转向助力正常助力的20%直至车速降至0或驾驶员关闭电源2.3 Safety Goal的数量控制一个Item相关项通常会有多个Safety Goal数量取决于HARA分析识别出的危害事件数量。但需要注意1.避免过度细化如果一个Safety Goal可以通过更简单的系统设计来满足则不需要将其拆分为多个 2.避免过度抽象如果多个危害事件有共同的根因可以共享一个Safety Goal 3.ASIL合并来自同一危害事件的多个Safety Goal应具有相同的ASIL等级实际工程建议简单系统3-8个Safety Goal复杂系统如自动驾驶控制器10-30个Safety GoalSafety Goal过多可能意味着HARA分析过于细碎或系统边界定义不当2.4 Safety Goal与Safety Requirement的关系Safety Goal是顶层需求其下会分解为多层安全需求Safety Goal (顶层) ↓ Functional Safety Requirements (功能安全需求) ↓ Technical Safety Requirements (技术安全需求) ↓ Hardware/Software Requirements (硬件/软件需求)这种分解关系必须通过追溯矩阵Traceability Matrix进行管理确保每个Safety Goal的满足都能得到验证。来源依据ISO 26262-3:2018 Clause 7.4.2.2, Clause 7.4.2.3三、FTTI故障容错时间间隔时间维度的安全约束3.1 FTTI的定义Fault Tolerant Time Interval (FTTI)是ISO 26262中最关键的时间参数之一。根据ISO 26262-3:2018 Clause 7.4.2.2FTTI是从系统内故障发生到危害事件可能发生之间的时间间隔。在FTTI内系统必须检测到故障并进入安全状态以防止危害事件发生。FTTI是HARA分析的时间维度延伸——S/E/C三因子回答了风险有多严重而FTTI回答了系统必须多快响应。3.2 FTTI的组成结构FTTI可以分解为多个子阶段阶段描述典型时间占比故障检测时间从故障发生到系统检测到故障10-30%诊断时间确认故障性质、排除误报20-40%安全机制响应时间执行安全动作、进入安全状态30-50%驾驶员反应时间可控性评估可选C0/C1场景可忽略-计算公式FTTI t_fault_detection t_diagnosis t_safe_state_transition t_driver_reaction如果考虑可控性3.3 FTTI的确定方法FTTI的确定需要综合考虑以下因素3.3.1 基于驾驶员行为学数据对于涉及驾驶员反应的场景FTTI应考虑驾驶员平均反应时间约700ms复杂场景可达1500ms专业驾驶员反应时间约400-500ms紧急情况下的最短反应时间约300ms3.3.2 基于危害事件动力学某些危害事件的发生需要特定条件车辆减速度累积到危险水平所需时间方向盘转角偏差累积到危险程度所需时间电池过温导致热失控的传播时间3.3.3 基于系统架构约束硬件处理周期、软件任务调度周期都会影响FTTI的下限硬件看门狗响应周期通常10-50ms软件任务周期通常5-100ms传感器采样周期通常1-20ms3.4 FTTI典型数值参考系统类型FTTI范围说明制动系统50-100ms制动失效直接威胁安全转向系统100-200ms助力失效但机械转向仍可用安全气囊20-50ms碰撞检测到展开的时间ADAS控制器100-500ms取决于具体功能电池管理系统500ms-2s热失控传播相对较慢来源依据ISO 26262-3:2018 Clause 7.4.2.2, ISO 26262-9:2018 Clause 4四、Safe State安全状态系统故障后的归宿4.1 Safe State的定义根据ISO 26262-1:2018 Clause 3.133Safe State是指系统在故障后能够达到的、不存在不合理风险的状态。Safe State的核心要求是 1.无危害在该状态下危害事件不会发生 2.可维持系统能够在该状态下持续运行或安全停机 3.可转换系统能够从故障状态转换到Safe State4.2 Safe State的分类根据系统的具体特点Safe State可以分为三种主要类型4.2.1 跛行回家模式Limp Home Mode适用场景系统部分功能丧失但核心功能仍可维持特征功能降级运行性能受限但可用允许驾驶员将车辆驾驶到安全地点EPS系统示例关闭电子助力保留机械转向连接提供有限的被动助力依赖车速的液压助力限制最大转向速度4.2.2 降级运行模式Degraded Mode适用场景系统检测到潜在故障但尚未完全失效特征部分冗余通道失效提高监控频率限制功率或性能BMS系统示例单体电池过压时限制充放电功率降低充电电流上限禁用快充功能4.2.3 功能关闭模式Function Shutdown适用场景故障无法通过降级运行来控制风险特征完全关闭危险功能可能影响车辆正常运行优先保障人员安全制动系统示例检测到ABS泵电机故障时关闭ABS功能保持基础制动能力点亮故障灯提醒驾驶员4.3 Safe State Transition安全状态转换安全状态转换是FSC的核心内容之一需要明确定义项目内容触发条件哪些故障信号触发安全状态转换转换时间从故障检测到进入Safe State的最大时间转换路径直接转换还是分步降级状态保持进入Safe State后如何保持恢复条件何时可以恢复到正常状态设计要点1. Safe State Transition必须在FTTI内完成 2. 转换过程本身不能产生新的危害 3. 需要考虑转换过程中的瞬态行为来源依据ISO 26262-3:2018 Clause 7.4.2.1, ISO 26262-4:2018 Clause 6五、Functional Safety Concept功能安全概念5.1 FSC的定义与范围根据ISO 26262-3:2018 Clause 9.1功能安全概念定义了实现Safety Goal所需的安全机制并将这些机制分配到初步的系统架构中。FSC是连接需要达到什么安全目标与如何实现这些目标的关键环节。5.2 FSC的开发输入FSC开发需要以下输入输入来源说明Safety GoalHARA输出顶层安全要求Item DefinitionISO 26262-3 Clause 5系统边界、功能、环境系统初步架构系统设计可用的架构元素ASIL等级HARA输出安全要求等级FTTIHARA/FSC确定时间约束Safe State定义FSC确定目标状态5.3 FSC的核心内容5.3.1 安全机制定义安全机制Safety Mechanism是FSC的主体内容包括检测类机制故障检测Fault Detection识别系统中存在的故障故障诊断Fault Diagnosis确定故障的性质和位置故障预测Fault Prediction识别即将发生的故障高级功能响应类机制故障处理Fault Handling检测到故障后的处理逻辑安全状态转换Safe State Transition进入安全状态的路径冗余切换Redundancy Switching从主通道切换到备份通道防止类机制故障预防Fault Prevention通过设计避免故障发生故障避免Fault Avoidance通过质量管理避免系统性故障5.3.2 安全机制选型决策安全机制的选型需要综合考虑以下因素安全机制选型 f(ASIL, 故障类型, FTTI, 系统复杂度, 成本)基于ASIL的选型指导ASIL等级推荐安全机制类型ASIL A自检、简单监控、Timeout保护ASIL B双通道冗余、周期性自检、CRC校验ASIL C多样化冗余、诊断覆盖率90%、看门狗ASIL D2oo3/2oo2投票、异构冗余、硬件监控、故障注入测试5.3.3 架构元素分配FSC需要将安全机制分配到初步的系统架构元素-分配到ECU哪个ECU负责执行哪个安全机制分配到传感器哪些传感器用于故障检测分配到执行器哪些执行器用于安全响应分配到通信安全相关的通信路径5.4 FSC的工作产品根据ISO 26262-3:2018 Clause 9.5FSC的主要工作产品包括工作产品内容功能安全概念安全机制定义、分配方案追溯矩阵Safety Goal → FSC的追溯关系安全状态定义各危害事件对应的Safe StateFTTI分配各子阶段的时间分配来源依据ISO 26262-3:2018 Clause 9, Clause 10六、工程实践以EPS系统为例6.1 系统背景电动助力转向系统Electric Power Steering, EPS是典型的安全关键系统ASIL等级通常ASIL C或更高功能辅助驾驶员实现转向危害助力失效可能导致转向困难或失控6.2 HARA输出示例危害事件SECASIL助力突然失效导致转向困难S2E4C2ASIL C助力过大导致过度转向S3E4C2ASIL C助力失控导致车辆突然转向S3E3C3ASIL D6.3 Safety Goal定义基于HARA定义以下Safety GoalSG-01 当车速在10-80km/h范围内时如果检测到助力电机失效系统应在200ms内进入跛行回家模式提供最小助力正常助力的20%直至车速降为0ASILD从最严重危害事件继承FTTI200msSG-02 系统应防止任何导致非驾驶员意图的转向力输出ASILDFTTI50ms更严格的响应要求6.4 Safe State定义Safety GoalSafe State说明SG-01Limp Home减少助力但保持功能可用SG-02Function Shutdown完全关闭电机输出6.5 功能安全概念设计6.5.1 故障检测机制故障类型检测方法检测周期电机过流电流传感器阈值比较1ms电机温度过高温度传感器10ms传感器信号异常传感器冗余交叉验证1ms控制信号异常看门狗超时检测5ms电源电压异常电压监控1ms6.5.2 安全机制架构┌─────────────────────────────────────────────────┐ │ EPS Controller │ ├─────────────────────────────────────────────────┤ │ ┌──────────────┐ ┌──────────────┐ │ │ │ Main Channel │◄──►│ Monitor MCU │ │ │ │ (ASIL C) │ │ (ASIL C) │ │ │ └──────┬───────┘ └──────┬───────┘ │ │ │ │ │ │ └────────┬─────────┘ │ │ │ Cross-Check │ │ ┌────────▼─────────┐ │ │ │ Safety Relay │ │ │ │ (双路切断) │ │ │ └────────┬─────────┘ │ │ │ │ │ ┌────────▼─────────┐ │ │ │ Motor Driver │ │ │ └────────┬─────────┘ │ └─────────────────┼───────────────────────────────┘ │ ┌───────▼───────┐ │ DC Motor │ │ (助力电机) │ └───────────────┘6.6 TSR初步分配TSR编号需求描述分配元素ASILTSR-001主MCU与监控MCU每秒交叉验证一次Main/Monitor MCUCTSR-002检测到不一致后10ms内切断电机输出Safety RelayDTSR-003跛行回家模式激活后保持20%助力Motor DriverCTSR-004电机电流每秒采样不少于1000次Current SensorC来源依据ISO 26262-3:2018 Clause 9, ISO 26262-4:2018 Clause 5-6七、常见陷阱与避坑指南7.1 Safety Goal编写常见问题问题1Safety Goal过于抽象❌错误示例 EPS系统应保证转向安全✅正确做法 当车速10km/h时如果助力电机电流超过额定值150%且持续超过50ms系统应在100ms内进入跛行回家模式问题2Safety Goal与系统需求混淆❌错误示例 系统应使用双CAN通道冗余通信✅正确做法 安全相关的控制指令必须具备冗余传输能力任何单点故障不得导致指令丢失分析第一条是系统实现方案第二条才是Safety Goal——描述需要达到的安全特性而非具体实现。问题3FTTI设定不合理过短导致的问题系统架构无法满足硬件周期约束成本急剧上升可能需要引入更复杂的安全机制过长导致的问题可能无法有效防止危害事件与驾驶员可控性评估冲突认证审核可能被质疑建议在满足安全要求的前提下FTTI应尽可能宽松以降低实现难度。7.2 Safe State设计常见问题问题1Safe State不等于系统正常状态某些工程师会错误地将无故障状态等同于Safe State。实际上Safe State是故障后的状态正常状态是无故障的状态两者需要分别定义问题2Safe State转换过程的风险在设计Safe State Transition时需要注意转换过程本身不能产生瞬态危害降级过程应有平滑过渡某些情况下直接切断可能比降级更安全问题3多故障场景的Safe State当系统同时发生多个故障时需要定义故障优先级可能需要组合多种Safe State策略应考虑级联故障的处理7.3 FSC开发常见问题问题1安全机制与功能需求冲突某些安全机制可能影响系统性能冗余检查增加响应延迟看门狗复位导致功能中断传感器交叉验证增加计算负载解决方案在FTTI允许范围内优化实现考虑软硬件分工使用专用硬件加速安全检查问题2安全机制本身的失效需要考虑的问题安全机制是否会失效安全机制失效后如何处理是否需要安全的安全机制这引出了深度防御Defense in Depth理念和元余的监控Monitoring of Monitors概念。来源依据ISO 26262-3:2018 Clause 9.4, ISO 26262-4:2018 Annex B八、总结与展望8.1 核心要点回顾概念关键点Safety Goal顶层安全要求继承自HARASMART原则FTTI从故障到危害的时间窗口必须在FTTI内进入Safe StateSafe State故障后可达到的安全状态三种主要类型FSC安全机制定义与架构分配连接目标与实现8.2 与后续阶段的衔接FSC完成后将进入系统级产品开发ISO 26262-4阶段FSC输出的TSR将细化为Technical Safety Requirements系统架构将精化为详细的硬件/软件架构安全机制将具体化为硬件电路和软件模块8.3 第三版标准趋势根据ISO 26262第三版WD草案预计2027年发布的讨论方向增强的SOTIF集成FSC将与SOTIF危害分析更紧密地结合软件定义安全随着软件复杂度增加FSC对软件架构的指导将更加具体AI/ML组件如何为基于AI的组件定义Safety Goal和FSC将成为新课题8.4 实践建议1.尽早介入Safety Goal的确定应与HARA并行迭代而非HARA完成后再开始 2.多方参与FSC开发需要安全专家、系统工程师、硬件工程师、软件工程师的协作 3.持续评审Safety Goal和FSC应经过多轮评审确保完整性和一致性 4.文档管理所有安全相关的决策必须有明确的文档记录和追溯关系附录关键标准条款索引ISO 26262条款内容Part 3 Clause 7.4.2Safety Goal定义Part 3 Clause 7.4.2.2FTTI定义Part 3 Clause 9功能安全概念开发Part 3 Clause 9.4安全机制定义Part 3 Clause 9.5FSC工作产品Part 4 Clause 5技术安全需求Part 4 Clause 6系统架构设计Part 1 Clause 3.133Safe State定义Part 1 Clause 3.59FTTI定义Part 1 Clause 3.140Safety Goal定义本文标签#功能安全 #ISO26262 #汽车电子 #SafetyGoal #FTTI #SafeState #FunctionalSafetyConcept #HARA #EPS #BMS #安全架构 #自动驾驶 #AUTOSAR #FS系列下期预告FS-06 功能安全管理体系FSMS组织级安全治理的工程实践本文基于ISO 26262:2018标准编写所有技术内容可追溯到标准原文条款。 FS系列文章导航FS-01 ISO 26262标准体系全景解析FS-02 功能安全核心术语精解FS-03 ASIL等级体系深度解读FS-04 危害分析与风险评估HARA工程实践FS-05 安全目标与功能安全概念本文FS-06 功能安全管理体系预告标签#功能安全 #ISO26262 #汽车电子 #SafetyGoal #FTTI #SafeState #FunctionalSafetyConcept #HARA #EPS #BMS下期预告FS-06 功能安全管理体系FSMS组织级安全治理的工程实践