★ FEATURED ARTICLE 1. 功能安全到底是在防什么“险”做汽车电子这行当这些年被问到最多的一个问题是功能安全和我平时说的主动安全、被动安全到底是不是一回事很多老工程师也会在这个概念上交锋几句。我给一个能记住的答案主动安全防的是“外部环境刁难你”比如前车急刹、行人窜出、路面打滑被动安全防的是“撞了以后别伤着人”比如气囊、吸能溃缩而功能安全防的是“系统自己出毛病”比如传感器突然报错、芯片寄存器翻转、软件跑飞导致刹车误动作。一句话概括功能安全在电子电气系统发生可预见的故障时系统仍有能力把风险控制在可接受范围内不造成对人的伤害。这个定义听起来简单做起来却是一场贯穿整个产品生命周期的硬仗。ISO 26262就是把这场仗的作战手册标准化了。它从概念阶段、系统设计、硬件设计、软件设计到生产、运维、报废全链条地告诉你每一步该分析什么、设计什么、验证什么、留什么文档。因为汽车电子系统越来越复杂ADAS、域控制器、线控底盘、智能座舱层层叠加一旦系统内部某个环节失效后果可能比“被动安全没触发”还严重——毕竟被动安全是在碰撞后起作用而电子系统故障可能在正常行驶中直接引发危险。适合谁来学这套东西如果你是系统工程师、嵌入式软件工程师、硬件工程师或者正在做域控制器、BMS、EPS、线控制动这类安全相关产品的开发功能安全是绕不开的必修课。即便你是刚入行的新人理解这套方法论也能让你看问题的视角从“代码能不能跑”上升到“系统出错了会怎样”。我特别喜欢用一个时间概念来开场——FTTIFault Tolerant Time Interval故障容错时间间隔。这个概念是整个功能安全的灵魂。想象一下你在高速上开着自适应巡航前车减速系统需要自动刹车。如果此时测距雷达的内部供电突然掉电传感器输出错误数据系统从“故障发生”到“进入安全状态”之间有一个窗口期这个窗口就是FTTI。如果超过这个窗口还没有把系统拉回安全状态危险就可能发生。所有安全机制设计的本质都是在FTTI内完成“检测故障→做出决策→执行保护动作”这一整套闭环。2. 风险是怎么量化的HARA与ASIL等级2.1 三要素把“危险”变成数学题功能安全的第一课是先搞清楚“什么样的事故是我们不能接受的”。ISO 26262给出了一套叫HARAHazard Analysis and Risk Assessment危害分析与风险评估的方法论。做HARA之前很多人会问风险评估不是靠经验拍脑袋吗这套方法论高明之处就在于它把模糊的“危险”拆解成三个可以打分、可以比较的维度。SSeverity严重度如果危害发生人员受伤的严重程度。从S1轻伤到S3危及生命或致命。EExposure暴露率车辆处于该危害场景的概率。比如高速行驶比停车场倒车暴露率高E从E1极低到E4非常高。CControllability可控性驾驶员或其他交通参与者能否通过反应避免伤害。C1通常可控到C3很难控制甚至不可控。2.2 ASIL是怎么算出来的拿电动助力转向EPS举例。假设EPS的扭矩传感器在行驶中发生电气故障向电机控制器发送一个错误的“方向盘向左打死”的信号车辆会在驾驶员毫无防备的情况下突然向左偏驶。分析这个场景S车辆在行驶中突然失控大概率与邻车或障碍物碰撞乘客可能致命评为S3。EEPS在每次行驶中都持续工作传感器故障可能在任意行驶时刻发生暴露率评为E4。C方向盘信号突变造成的横摆远超驾驶员即时修正能力在高速场景下基本不可控评为C3。查ISO 26262的ASIL分级表格S3E4C3落在ASIL D——这是汽车领域最高安全等级。整车的制动、转向这类核心系统基本都是ASIL D的命。ASIL等级不仅有D还有A、B、C它决定了后面所有开发工作的严格程度。ASIL D要求的安全机制、验证深度、文档完整度都比ASIL A高一个量级。这里有一个关键操作并不是每个功能都需要做到ASIL D比如车内氛围灯、娱乐系统即使失效也不会危及人身安全评下来可能就是ASIL A甚至QMQuality Management仅需质量管理。2.3 安全目标怎么写才有效HARA的产出物叫“安全目标”Safety Goal它是所有后续设计工作的总纲。安全目标不能写成模糊的语句它必须包含失效行为、危害场景、安全状态、FTTI要求、ASIL等级。一个示范写法SG1确保车辆在行驶过程中当EPS扭矩传感器发生内部电气故障时系统在故障容错时间间隔300ms内检测到该故障并切换至安全状态切断助力电机输出保留机械转向连接避免车辆发生非预期偏驶。ASIL D。写安全目标的通病有两个一是漏写FTTI没有时间约束的“尽快切换到安全状态”在设计实现时根本无法验证二是把安全状态定义得模糊。安全状态必须是硬件可执行、软件可配置、测试可观察的具体状态而不是“保证安全”这种口号。3. 安全生命周期与V模型流程不是摆设3.1 V模型的左右两侧分别做些什么ISO 26262把功能安全开发组织成一个V模型。V的左侧是“从上到下”的设计分解右侧是“从下到上”的验证确认。很多工程师觉得V模型是形式主义但真正按它走完项目的人会发现V模型本质上是在强制你做“每一步都有据可循”的工程闭环。左侧概念阶段定义item定义系统范围、HARA、安全目标。左侧系统阶段把安全目标分解到系统架构形成功能安全需求FSR和技术安全需求TSR。左侧硬件/软件阶段继续细化为硬件安全需求HSR和软件安全需求SSR。右侧各层验证软件单元测试验证编码实现软件集成测试验证架构交互系统集成测试验证技术安全需求最后在整车层面做安全目标验证。3.2 安全需求是怎么一层层分解的安全目标的分解要遵循“ASIL裁剪”规则。这里我多说一句ASIL是允许分解的比如一个ASIL D的安全目标可以分解成两个相互独立的ASIL C的子需求——“相互独立”四个字是核心。常见做法是你无法让单个ECU做到ASIL D的完整可靠性就用两条不同路径比如双通道传感器、双MCU分别实现ASIL C再把两者的结果交叉校验。这条路径上最忌讳的是形式上分解了实际两条路径共享同一个失效起因。例如两个通道用同一颗电源芯片供电电源芯片一失效两个通道同时失效独立性就不成立。这类问题在官方文档里叫“共因失效”是需要用DIADependent Failure Analysis依赖失效分析专门抓出来的。在实操中我见过不少团队在需求分解阶段就开始“偷工减料”把“应确保……”“应避免……”这类安全需求写成一句话带过等做到软件层才发现需求不可验证只能推翻重做代价非常大。3.3 每个阶段该交付什么文档功能安全项目另一个让人头痛的点是“文档”。一次性交付的文档清单大概包括HARA报告、安全目标清单、功能安全概念FSC、技术安全概念TSC、硬件安全需求规格、软件安全需求规格、安全分析报告FMEA/FTA、安全案例Safety Case等。写文档的原则是不是为了给审核员看而是为了让你自己项目里每个人的设计决策可追溯。三个月后你回头改代码如果翻安全需求文档能立刻定位到“当初为什么这样设计”这份文档就值了。反之文档写完就归档再也不看等审核前疯狂补材料这种项目必翻车。4. 安全机制设计从架构到硬件的落地打法4.1 常用安全机制与它们的典型场景安全目标定了剩下的工作就是回答一个核心问题系统发生什么样的故障用什么手段检测检测到之后做什么。这是安全机制设计的全部命题。稍微整理一下主流的安全机制手段安全机制类型解决什么问题典型实现方式故障检测与自检传感器/芯片内部故障MCU内置LBIST、传感器自诊断、信号合理性校验冗余与表决单点失效导致错误输出双通道采集、三路表决2-out-of-3监控与看门狗软件跑飞、卡死窗口看门狗、问答式监控、程序流监控数据保护内存比特翻转、传输错误ECC内存、CRC校验、端到端通信保护降级与安全状态故障后维持基本功能降扭矩、切机械助力、整车安全停车拿BMS电池管理系统举例更直观。电池过充是极其危险的场景BMS需要在FTTI内检测到单体电压过高并切断充电回路。这背后至少要叠加三道安全机制电压采样通道的合理性校验防止采样芯片自身故障、充电接触器的冗余驱动防止单一驱动回路失效、以及独立于主控芯片的硬件过充保护电路。三级保护缺一级ASIL等级都可能降档。4.2 FTTI、安全状态与故障注入测试FTTI在设计层决定了你用什么速度实现检测和响应。举个例子某系统的安全目标是“碰撞后250ms内解除高压”那么你的高压接触器断开时间、控制器处理时间、传感器检测时间加起来必须小于250ms。这个时间预算要像做电源时序一样一项一项算清楚否则后面测试时就会发现硬件断开速度根本达不到。安全状态的定义在不同系统里差异很大。EPS的安全状态是“助力关闭但有机械连接”BMS的安全状态是“主回路断开高压下电”线控制动的安全状态是“保留冗余制动通道”。安全状态还分“可达安全状态”和“故障后维持状态”前者是所有故障都能导向的后者是故障不影响某个功能时继续工作的状态。故障注入测试是验证安全机制的试金石。我在实际项目里最常用的三类软件故障注入修改信号值模拟传感器故障、硬件故障注入短路、断路、接地故障、以及MCU寄存器级别的故障注入模拟位翻转、时钟故障。这些测试必须在系统层面验证不仅要验证“故障被检测到了”更要验证“在FTTI时限内系统进入了安全状态”。4.3 硬件指标与ASIL等级的量化账到了硬件设计ISO 26262给出了可以定量的硬指标这也是让我觉得这套标准特别“硬核”的地方。对随机硬件失效ASIL D有三个数值门槛SPFM单点故障度量≥99%衡量所有可能直接导致违反安全目标的单点故障中被安全机制覆盖的比例。LF潜伏故障度量≥90%衡量潜伏故障没有被及时发现、在后续某个时候才暴露的故障被覆盖的比例。PMHF随机硬件失效概率≤10 FIT即每10^9小时内失效不超过10次按1亿辆车每年跑2万小时算相当于每辆车每跑5年半只能允许大约1次由随机硬件失效导致的危险事件。这个数字天然就把芯片选型、单元设计、失效率计算的严谨性推到了极致。我常跟硬件同事说SPFM和LFM其实就是两张账本账本记录所有失效模式安全机制覆盖了哪些遗漏了哪些覆盖率算下来不达标就回去补机制或者从芯片层面重新选型。FMEDAFailure Modes, Effects and Diagnostic Analysis失效模式影响与诊断分析工具在这里派上大用场它把每个元器件的失效模式、失效率、诊断覆盖率算得清清楚楚。5. 实操中容易翻车的几个地方与排查实录5.1 分析工具链FMEA、FTA、FMEDA怎么配合功能安全的分析工具不是越多越好而是各司其职。我见过团队把FMEA做成了流水账表格填了一大堆实际设计漏洞一个没找出来。用我的经验说清楚三个工具的分工FMEA失效模式与影响分析自底向上从“某个部件怎么失效”推演到“系统会不会违反安全目标”。适合发现单点失效。FTA故障树分析自顶向下从“安全目标被违反”反推导致它的所有路径组合适合发现组合失效和共因失效。FMEDA偏向量化计算失效率、诊断覆盖率为SPFM/LFM/PMHF提供数据。FMEA是查漏FTA是找路径FMEDA是算数。三者交叉验证比只做其中哪一个都靠谱得多。5.2 安全机制误触发可用性与安全性的死结这是我在项目中踩过最深的坑也是路测现场最容易暴露的问题。安全机制的初衷是“发现故障就介入”但过度敏感的安全机制会频繁触发降级或安全状态导致用户体验悬崖式下跌。举个例子。某款ADAS车辆在高速上正常行驶前方无任何障碍物但AEB自动紧急制动突然介入车辆剧烈减速。查了一周最终定位为前摄像头被一只飞虫撞击图像信号短暂异常AEB的故障检测机制把这种情况判定为“传感器失效”进入了紧急制动安全状态。安全是安全了但这显然不可接受。这就是“安全机制误报”的典型。解决办法通常有几个方向一是对检测结果做“确认”处理短暂故障不立即触发降级而是持续观察多个检测周期二是引入信号合理性交叉校验用毫米波雷达的信号和摄像头做一致比对三是对安全状态做分层处理——不是所有故障都要跳到“急刹车”这个最终安全状态可以先“降级”、再“报警”、最后“停车”。误报率是衡量功能安全设计成熟度的重要指标一个动不动就吓人的系统长期看消费者不会接受这也是功能安全落地时最大的现实挑战。5.3 常见问题速查表问题现象常见根因排查建议故障注入测试不通过安全机制的检测时间超过FTTI预算逐环节量测检测-响应时间压缩软件轮询周期或改用中断触发SPFM达标但LFM不达标潜伏故障无诊断覆盖增加周期性自检如上电自检、运行中周期性内建自测ASIL分解后独立性被否定两个通道共享电源/时钟/复位做DIA分析识别共因失效增加隔离或冗余安全状态执行后无法退出缺少故障恢复和状态复位逻辑定义退出安全状态的必须在系统设计阶段明确路测偶发误触发无法复现故障持续时间短日志记录不完整增加故障记录缓冲用循环缓冲区保存触发前后数据6. 从功能安全到预期功能安全下一波浪潮写到这里如果你的目光只停留在ISO 26262本身视野会窄一点。功能安全处理的是“系统有没有毛病”而随着AI算法大量进入汽车一个新的姊妹标准正在被越来越高频地提起——ISO 21448SOTIF预期功能安全。SOTIF处理的场景是什么呢系统本身没有故障硬件软件都健康但算法对某些场景的理解能力不足导致错误行为。比如雨雾天气下摄像头无法识别车道线系统既没有报告故障也没有降级而是维持错误的高车速又比如前方卡车车厢上贴着一张巨幅广告里面恰好是一辆汽车的图片AEB算法把它误认为真实车辆。这些都不是“硬件故障”而是“预期功能不足”。SOTIF就是专门设计来补这一块的思路是通过场景分析、触发条件识别、功能不足评估、以及“用边界场景测试把未知危险场景变成已知”的手段来降低风险。将来功能安全工程师要面对的系统会比今天复杂一个量级AI的可解释性、持续学习系统的安全监控、车路协同场景下多车交互的风险分配都会把传统ISO 26262的方法论推向极限。我做功能安全这几年个人最深的体会是这套体系真正的价值不是给你一堆表格和文档让你填而是逼着团队用“最坏情况”的视角去审视自己的每一个设计决策。一个按章办事走完HARA、安全目标、安全机制、故障注入测试的团队和一支只靠经验堆代码的团队做出来的产品在可靠性上差的不是一点半点。每次被客户追问“你们怎么证明这个设计是安全的”我都能拿出从分析到验证的完整证据链这种感觉是写代码本身给不了的。最后再分享一个我很喜欢的小习惯。每次评审功能安全设计文档时我都会问自己三个问题如果这里失效了会发生什么我怎么第一时间知道它失效了我知道之后有没有足够的时间做点什么这三个问题问下来绝大多数设计漏洞都藏不住。这套思路同样适用于你身边的智能家居、机器人、医疗器械万变不离其宗。
阅读完成 · 觉得有帮助？
