我参加过不少FMEA-MSR的评审会经常能看到这样一幕讨论到步骤三功能分析时会议室里坐满了人两个多小时过去屏幕上只憋出来一句“系统应具备过压监测功能”。当时没人觉得这是个问题可等做到步骤四失效分析主持人问“过压监测功能如果失效表现是什么”一屋子人面面相觑半天挤不出几条像样的失效模式。问题的根源不在步骤四而是在步骤三埋下的。FMEA-MSR的七步法里步骤三功能分析是最容易被轻视、却又最决定成败的一环。结构分析告诉你“系统由哪些部件组成”功能分析则要回答“这些部件分别干什么、彼此之间怎么配合、出了问题系统怎么知道、知道了以后怎么反应”。这一步做不扎实后面的失效分析永远是挤牙膏风险分析全是拍脑袋。这篇文章就来把步骤三掰开揉碎了讲从功能描述的写法到功能网的搭建从MSR格外关注的监测功能与系统响应功能到我在实际项目里踩过的坑一次性说透。适合正在做FMEA-MSR的研发工程师、质量工程师、功能安全工程师也适合那些FMEA刚刚入门、正被各种术语绕晕的新人。1. 这一步在整个FMEA-MSR流程里的真实地位1.1 七步法里的“承上启下”不是句空话FMEA-MSR七步法是一个完整的逻辑链步骤一策划准备步骤二结构分析步骤三功能分析步骤四失效分析步骤五风险分析步骤六优化步骤七结果文件化。很多人把步骤一和步骤二看得很重因为要定边界、画结构树、拉团队看起来“工作量很足”。到了步骤三反而容易松懈——不就是把每个零件翻译成一句话吗还真不是。我的理解是结构树是整个分析的骨架功能分析则是给骨架接上神经系统。骨骼决定了哪些部件存在神经决定了信号怎么传、动作怎么发。没有神经系统的骨架只是一堆静态零件而FMEA-MSR后半程全部要讨论的是动态行为——失效、监测、响应、恢复全部建立在“这个系统应该怎样工作”的认知之上。打个比方你做人体结构分析能列出心脏、血管、神经系统这些器官。但如果你不写清楚“心脏通过泵血为全身供氧”“血管负责输送血液”“神经系统检测到缺氧后触发呼吸加快”后面讨论“心脏病发作会有什么后果”时你连分析的方向都没有。功能分析就是把“器官清单”升级成“生理机制图”。1.2 功能定义是失效模式的“最小分析单位”在FMEA-MSR里功能是失效模式的直接主语。失效模式的定义是“功能无法按预期要求执行”没有清晰的功能定义失效模式就失去了锚点。我评审过很多份FMEA失效模式发散、重复、遗漏追根溯源全是功能描述出了问题。比如你把功能写成“监控电压”到了失效分析就不知道该怎么拆——到底是采集异常、判断异常、还是输出异常而你如果把功能拆成“以10ms周期采集动力电池总电压并在总电压低于9V时生成欠压标志位”失效模式自然就清晰了采集周期超差、电压采样精度不足、阈值判错、标志位没生成。这就是功能分析最关键的价值它直接决定了步骤四能拆出多少条有意义的失效模式决定了步骤五的风险优先级评分是否可信。功能这一步省了多少力后面就要加倍补回来。1.3 MSR给功能分析悄悄加了两个任务FMEA-MSR面向的是“带监测和系统响应功能的系统”。它和传统DFMEA最大的区别在于传统DFMEA只需要分析“系统能做什么、失效后有什么后果”而MSR还必须分析“系统能不能自己发现失效发现之后会不会做出正确的响应”。翻译成功能分析的语言就是你要在功能网里额外识别两类功能一类是监测功能感知、判断、诊断另一类是系统响应功能报警、降级、关断、恢复。这两类功能如果不放进功能网步骤四的失效分析就永远差一环。比如你做BMS的FMEA-MSR分析“电芯过压”这个失效模式光写“电芯电压超过4.2V”不完整一定要补上“过压监测功能如何探测到这一状态”“探测到之后BMS是否执行限功率或断充的响应”。MSR名字里的Monitoring and System Response就是这两个词——没有监测失效就是盲盒没有响应监测就只是看客。2. 动手之前先备料功能分析的输入和前置条件功能分析不是凭空开脑洞它建立在结构分析输出和一堆设计规范之上。这一步的准备工作做得越足工作坊的产出质量越高。我至少见过三四个团队拿着半张结构树就冲进功能分析会议结果一半时间在争论“这个零件到底归谁管”这纯粹是浪费工时。2.1 结构树的“最后一轮检查”进入功能分析之前结构树必须满足几个条件。第一每个系统要素都有明确的功能载体不存在“既没有功能、也没有失效”的僵尸要素。第二父子层级关系清晰特别是MSR项目经常要区分“被监测对象”和“监测载体”。例如动力电池系统里电芯是被监测对象电池管理单元是监测载体两者虽然在同一个结构树里但是各自承担的功能性质完全不同。第三协作元素的边界已经说清楚尤其是跨控制器、跨域的功能比如充电桩给BMS发的充电允许信号到底算外部输入还是系统内部功能必须在结构分析阶段定死。我习惯在功能分析工作坊开始前花15分钟把结构树整体过一遍每个要素走一个问题“如果这个要素明天消失了系统会少什么能力”答不上来的要素不是删掉就是重新补定义绝不让它带病进入功能分析。2.2 边界图和接口分析功能不会凭空产生功能是要素对输入做出处理、并产生输出的行为所以功能的梳理离不开接口分析。在AIAG-VDA手册的方法论里结构分析阶段通常要配套做边界图Boundary Diagram和接口分析识别机械接口、电气接口、热接口、信号接口、人机接口和诊断接口。到功能分析时这些接口直接翻译成一组“接口功能”。举一个很常见的遗漏整车控制器和BMS之间的CAN通信。结构树上你会画出两个控制器但很多团队做功能分析时只写“BMS采集电压”“整车控制器控制电机”把“BMS通过CAN向整车控制器周期发送状态报文”这个接口功能漏得干干净净。等到做失效分析CAN通信超时、报文连续丢失、信号无效这些故障模式全都没有功能主语。所以我的经验是功能分析之前先把接口矩阵拉出来每个箭头都必须能对应到至少一个功能。2.3 工作坊前必须到位的输入文档清单功能分析不是设计讨论会它是把已有的设计逻辑“翻译”成功能逻辑所以输入文档质量直接决定功能分析质量。以下几类文档必须在会前发给与会者没发就推迟开会系统需求规范/功能规范功能要求通常从这上面来软件需求规范MSR里监测逻辑和响应策略很多是软件行为需要软件架构师参会系统架构图、电气原理图帮助确认信号流和能量流的方向诊断规格书DTC清单、故障码表、诊断服务监测功能的输出在诊断侧如何落地网络通信矩阵报文信号、周期、超时时间CAN通信类功能的时序要求ISO 26262相关文档安全目标、安全状态、故障容错时间间隔FTTI这些直接给功能要求提供量化指标会前我一般会给每类文档标注“必须读”还是“参考”并且要求DRE、软件负责人在会上带电脑随时查证参数。功能分析最忌讳的事情之一就是凭空编要求。3. 功能定义的写法一句“动词加名词”藏着大学问3.1 功能的基本公式动词加名词但不止于此FMEA领域里流传着一个简单说法功能描述就是“动词加名词”。这句话没错但只说对了一半。完整的功能描述应该包括四要素动作用什么方式执行、作用在哪个对象上、在什么条件下触发、输出结果达到什么要求。我用一个公式来概括功能 主动动词 宾语受作用对象 边界条件/触发条件 可测量的性能要求拿BMS的电压监测来举例只写“监控电压”——不及格无法验收写成“采集动力电池总电压”——及格了一半但还是没有判断逻辑写成“在车辆ON状态下以10ms周期采集动力电池总电压当总电压低于9V时在50ms内生成欠压故障标志位”——这才是可以进入FMEA表格的功能描述后半句的两个数字10ms、9V、50ms就是功能要求。没有要求的功能是散弹有了要求的功能才是子弹。很多团队做FMEA只写功能不写要求到失效分析里讨论“采样周期超差”时连超差的标准都没有整个评分体系就悬空了。3.2 功能要求除了性能指标还要写时序和非功能要求功能要求的来源通常有三个整车或系统需求规范、安全目标ISO 26262、法规企标。在MSR场景里功能要求特别要关注几个维度时序要求响应延迟是多少例如过压报警必须在100ms内发出如果超过这个时间后果等级完全不同精度/范围测量的精度是多少判断阈值是多少有没有迟滞区间避免临界抖动环境边界在温度范围-40到85摄氏度之间功能要保持有效在电磁干扰环境下不能误报故障条件下的行为传感器失效、通信丢失时功能应该进入什么降级状态最后一条对MSR尤其重要。功能要求不能只描述“正常情况下做什么”还要描述“非正常情况下如何保底”。比如“当电压传感器信号无效时系统采用冗余估算值并点亮故障灯而不产生错误报警”。这条要求本质上就是一条系统响应功能的输入。AIAG-VDA手册里功能和要求是可以拆开成两列的功能列写“做什么”要求列写“做到什么程度”。实际操作中我建议在功能分析表格里保留两列但每个功能对应的要求必须绑定在同一行因为后续失效分析是同时基于功能和要求展开的任何一个悬空都会导致分析断链。3.3 好功能和坏功能放在对比表里看我把多年来评审中见到的高频问题整理成一张对比表新人在动笔前先过一遍这三组对照能少踩一半的坑。场景差的功能描述好的功能描述BMS过压监测监控电池电压在车辆ON状态下以10ms周期采集电芯单体电压当任一电芯电压超过4.2V时在50ms内生成过压告警标志位并记录DTC整车VCU功率限制限制电机输出当收到BMS过温降功率请求且持续1s以上时在100ms内将电机输出扭矩限制到请求值的90%以内并取消蠕行扭矩补偿ADAS摄像头识别识别前方目标在雨雾天气下连续识别前方3米至120米范围内的车辆与行人目标目标丢失持续时间超过500ms时输出传感器无效标志充电口互锁防止带高压拔枪在枪座互锁信号断开后10ms内禁止高压继电器闭合并在仪表显示“充电连接异常”提示每个“好的功能描述”里都藏着可验证的信息触发条件、测量周期、阈值、时间要求、输出结果。有些人觉得这样写太长表格塞不下。我的经验是正式评审表格里写精简版动词名词关键要求工作坊白板上必须写全量版等所有逻辑都对齐了再压缩进表格。千万别在讨论阶段就为了表格美观而牺牲完整度。3.4 功能与要求的映射关系多对多很正常但要管理好实际项目里一个功能往往绑着多条要求一条要求也可能指向多个功能。比如“过压监测”这个功能既有“10ms周期采集”的要求又有“采集精度±1%FS”的要求还有“在-40至85摄氏度范围内保持功能”的要求。反过来“总电压低于9V时输出欠压标志位”这条要求既涉及电压采集功能也涉及阈值判断功能还涉及诊断输出功能。多对多关系如果不管理好到了步骤四就会出现失效模式的重复计数或遗漏。我的习惯是给每个功能分配一个唯一编号比如FN001、FN002在功能矩阵里做关联检查这一步会直接帮助步骤七做追溯审计。编号管理看起来是个笨功夫但没有它一张功能网超过30个节点时你就分不清谁是谁了。4. 从结构树到功能网顺着信号流把逻辑串起来4.1 功能网的层级逻辑顾客功能、系统功能、组件功能FMEA-MSR功能分析常用的呈现方式是功能网Function Network。功能网不是把功能列成一个表就完了而是要按照结构树的层级把功能之间的作用关系用箭头串起来形成从顾客功能、系统功能到组件功能的完整链条。三个层级各有定位顾客功能Customer Function顾客能感知或关心的最终能力比如“为车辆提供安全可靠的驱动能量”系统功能System Function系统为支撑顾客功能而提供的具体能力比如“在正常工况下输出满足驾驶员请求的功率”“在异常工况下执行电池保护”组件功能Component Function由具体部件或软件模块实现的功能比如“采集电芯单体电压”“生成过压告警标志位”“切断充电回路”层级不是越多越好但至少要有三层才能支撑MSR的完整逻辑。很多团队只做“系统功能到组件功能”两层丢掉了顾客功能这一层到了失效分析分析“影响”时链条到不了整车层面严重度S评分就失去了依据只能拍脑袋给个中间分。往上补一层顾客功能失效影响自然就顺理成章了。4.2 功能网怎么连线不是画关系图是画因果链功能网连线的核心逻辑是“如果……那么……”的因果关系。A功能为B功能提供输入A一旦失效B就受到影响。这个因果逻辑既是功能网的连线基础也是步骤四失效模式的传播路径基础。我画功能网时遵循一个原则每个箭头都代表一条真实的信号流、能量流或物质流。比如电压采集功能输出“电压值”给电压判断功能电压判断功能输出“过压标志”给报警输出功能报警输出功能点亮仪表灯并发送报文。如果连线不能对应到物理或逻辑上的传递关系这跟线就是多余的。箭头方向也很重要。功能网通常是从“感知和输入”指向“处理和判断”再指向“输出和响应”也就是说箭头方向大体和信号流方向一致。有些团队把箭头画反了功能网看起来像组织结构图一步四分析时怎么都理不顺传播路径最后只能全部重新画。宁可画得慢一点每条线都要过一遍“如果前一个功能没了后一个功能会怎样”。4.3 一组BMS过压场景的功能网实例拆解为了把抽象的说法落地我用BMS过压场景把功能网完整走一遍。结构层是动力电池系统父项—电池管理单元子项—电压采集模块、过压判断模块软件、放电/充电回路子项。功能网从顾客功能开始顾客功能在各类驾驶工况下安全地为车辆提供驱动能量系统功能一层电池系统在正常范围内为电机提供功率输出系统功能二层MSR重点当电芯电压超过安全边界时电池系统自动进入保护状态组件功能层电压采集模块以10ms周期采集电芯单体电压经线性化处理后输出准确电压值过压判断模块将单体电压值与4.2V阈值比较当电压超过阈值且持续200ms时输出过压标志充电回路控制模块接收到过压标志后在50ms内断开充电接触器故障输出模块将过压标志转换为DTC并请求仪表点亮报警灯连线逻辑是电芯电压物理量→电压采集模块→过压判断模块→故障输出模块充电回路控制模块→整车层面保护→顾客功能安全。这条链上每一步都对应一个功能每一个功能都可能在步骤四产生独立的失效模式比如采集精度失准、判断阈值错误、断接触器超时、DTC未记录、报警灯未点亮。这张功能网画完之后MSR真正关心的“监测—响应”闭环就已经肉眼可见了哪一环断了后面风险分析时探测度D评分就会非常难看。4.4 功能矩阵防止“僵尸要素”和“幽灵功能”功能网画完还需要通过功能矩阵做一次交叉检查。功能矩阵的结构很简单行是结构分析里的所有系统要素列是功能分析里定义的所有功能交叉处用对勾或功能编号标记。这个矩阵逼着团队回答两个问题第一个问题是不是存在有要素但没有任何功能的格子如果有说明这个要素是僵尸要素要么结构分析多了东西要么功能分析漏了东西。第二个问题是不是存在有功能但没有挂靠任何要素的格子如果有说明这是一个幽灵功能在实际系统中找不到执行者可能出现在功能分析过程中被虚构了。功能矩阵还有一个附加价值它能帮助你在评审会上快速定位“责任空白区”。两个要素的边界上经常出现功能真空比如“电压采集模块”和“过压判断模块”之间的信号传递到底算谁的功能如果矩阵里没有一个叫“输出电压值并传输给判断模块”的功能这个接口在失效分析时就会成为三不管地带。5. MSR格外看重的两件事监测功能与系统响应功能怎么写5.1 MSR在功能分析阶段的关注点是什么FMEA-MSR全称是Failure Mode and Effects Analysis - Monitoring and System Response翻译过来是“失效模式及影响分析监测与系统响应补充版”。它关注的是对于某些失效模式系统是否具备足够的监测能力能不能发现以及发现之后系统是否给出了正确的响应怎么处理。在步骤三功能分析阶段你必须提前识别出这些“监测类功能”和“响应类功能”把它们编入功能网否则后半程的MSR分析就是无源之水。一个常见的认知误区是MSR是给“软件系统”或者“带诊断功能的系统”用的我的产品不带软件就不用做。实际上现代整车电子电气系统里几乎没有不依赖监测和响应的功能了。哪怕一个最简单的雨量传感器也有自检功能和故障降级功能。所以做MSR功能分析时默认前提是凡是系统里有传感器、控制器、执行器的组合就必须思考监测和响应功能怎么定义。5.2 监测功能的写法对象、方式、判断标准三要素监测功能不是一句话“检测故障”就完了。在MSR功能分析里每个监测功能要交代三个要素监测对象监测的是什么物理量或信号比如电芯电压、母线电流、冷却液温度、CAN报文存活计数器、执行器反馈状态。监测方式通过什么手段监测是连续采样、周期性检测、事件触发还是上电自检这个信息直接决定失效分析里“探测方法”一栏怎么写。判断标准什么条件下判定为故障阈值是多少持续时间是否需要滤波去抖是单次越限还是累计次数这些参数基本来自标定表和诊断规范不能自己拍脑袋。举个例子同一根CAN信号线监测功能可以拆成两条功能A 以10ms周期采样来自整车控制器的扭矩指令报文当报文存活计数器连续3帧不变时判定通信中断功能B 当通信中断后执行器进入默认扭矩状态并在500ms内记录故障码功能A是典型的监测功能功能B其实是系统响应功能。两者互为补充拆得越清楚后续失效分析就能分别讨论“监测功能漏报”和“响应功能不动作”这两类失效。5.3 系统响应功能的类别写法降级、限功率、关断、警示系统响应是监测功能发现故障之后系统的执行动作。系统响应功能有很多种类型在功能分析阶段建议按类别梳理避免遗漏降级运行系统以降低性能的跛行模式继续工作比如某控制器检测到主传感器失效后切换到备用传感器或默认值限功率/限扭矩限制输出能力例如电池过温时限制充电功率完全关断直接切断高压回路或输出继电器进入安全状态警告与提示点亮仪表报警灯、弹文字提示、发出蜂鸣记录与上报存储DTC、发送诊断报文、上报网管中心写系统响应功能时最关键的是要写清楚“响应的触发条件、响应动作、响应时间限值、退出条件”。第一、二、三项很多团队都能想到但第四项“退出条件”经常被忽略。比如某系统因为温度过高触发了限功率温度降下来以后系统是立即恢复全功率还是需要满足一个滞回条件、或者需要重新上电才能恢复这个退出逻辑如果不在功能分析里定义到了失效分析分析“故障恢复”时就会失真。5.4 一条完整的MSR功能链长什么样把监测功能和响应功能串起来一条完整的MSR功能链应该包括五个环物理状态探测、信号采集与转换、故障诊断与判断、系统响应动作、故障恢复与表征。我用BMS过压场景把这条链补全物理状态探测电芯因过充导致电压升高至4.35V采集与转换电压采集模块将模拟电压转换为数字值并传送给诊断模块诊断与判断诊断模块比较电压值超出4.2V阈值并持续200ms确认过压故障系统响应充电接触器断开、充电请求被拒绝、DTC置位、仪表屏幕点亮“充电故障”提示故障恢复当电芯电压回落到4.0V以下且无其他故障时清除DTC并允许重新充电这五个环节里任何一个环节的功能缺失都会导致整个MSR链路断链。实操中我经常问团队一个问题“这个失效发生的时候第5环存不存在Recovery条件写清楚没有”能立刻回答上来的功能分析基本合格支支吾吾的多半漏了恢复功能。6. 功能分析阶段最常见的四个坑6.1 把实现方式写成了功能这是新手最容易犯的错误也是最隐蔽的。功能回答的是“系统做什么”实现方式回答的是“系统怎么做”。比如“采用高精度ADC对电压进行采样”——这是实现方式不是功能“准确记录当前电压值并输出数字信号”——这才是功能。为什么这个区别这么重要因为步骤四的失效分析要围绕功能展开。如果你把实现方式当成功能失效模式就变成了对某个特定设计的批评比如“ADC芯片失效”而正确的失效模式应该是不依赖具体实现的抽象描述比如“电压输出值错误”。一个好的功能定义应该做到无论以后是换芯片、换算法、换架构功能描述都基本不变。这也是为什么我评审时常常问一句话“你写的这个功能如果换一套硬件实现这句话还成立吗”6.2 功能描述写得太粗失效分析无米下锅功能描述写得越粗失效模式就越发散。我在评审会上最怕看到的功能描述是“监测电压”“控制电机”“处理信号”这类三五个字的高度概括。一旦你说完“监测电压”后面没有接任何量化要求参会的人就会各自脑补自己的理解讨论一小时也统一不了。解决这个问题没有捷径就是逼着每个功能至少带一个可验证的要求。不用太复杂哪怕只写“监测周期100ms阈值9V”也比干巴巴的“监测电压”强得多。我给团队定的规矩是功能描述里至少要出现一个数字除非这个功能确实是纯定性的比如“记录充电状态”但即便如此也要把输出结果的载体写清楚记录到哪里、用什么格式。6.3 漏掉边界功能和接口功能接口功能是最容易丢的一类功能。常见的接口功能主要有这么几种通信类功能报文发送、报文接收、信号周期监测、网络唤醒/休眠管理供配电类功能控制器上下电时序管理、保险丝状态监测、电源电压监测时钟同步类功能时间戳管理、同步信号触发尤其在分布式诊断场景里人机交互类功能按键扫描、指示灯驱动、声音报警输出这些功能单独看着不起眼但它们往往是故障传播链路里的关键一环。CAN总线断了所有跨控制器功能都会失效可如果你在功能网里根本没有定义“CAN报文收发”这个功能那后续所有关于通信丢失的失效模式都无从归类。我的建议是在功能矩阵交叉检查时专门用荧光笔把所有跨要素连线点标出来这些点就是接口功能的高发区。6.4 监测—响应链断裂有监测无响应有响应无监测MSR最独特的地方是强调“监测—响应”成对出现。我复盘过很多失败案例发现断链主要有三种表现第一种是只有监测没有响应。系统诊断模块已经识别出故障了但代码里没有对应的处理策略故障只是被记录成一个码对整车功能没有任何影响。功能分析里如果只写了“生成故障码”而没有写“故障码生成后触发的响应对策”这就是一条断链。第二种是只有响应没有监测。系统有“进入跛行模式”的功能但没有说明由什么逻辑触发进入这样失效分析就没法讨论“错误进入跛行模式”和“该进的时候没进”这两类失效。判定逻辑必须作为监测功能的一部分提前写清楚。第三种是响应动作与故障类型不匹配。比如冷却液温度过高按说应该降功率或请求风扇高速运转结果诊断逻辑只点亮了一个指示灯对热源不采取任何保护动作。功能分析阶段如果不能把“什么故障对应什么响应等级”梳理清楚MSR的优化工作基本无从谈起。6.5 一个返工复盘的真实场景我曾经参与过一个ADAS摄像头的FMEA-MSR项目功能分析阶段大家赶着过节点摄像头的基础功能目标识别、车道线检测、障碍物预警写得很快但是没人注意到“镜头脏污”这个工况。等到步骤四失效分析我们讨论“雨天高速公路行驶镜头脏污导致前方目标漏检”的失效模式时发现整个功能网里没有一条功能能和“镜头脏污”搭上关系——没有定义脏污程度评估功能也没有定义传感器清洁请求功能。这就是链条断裂现场。我们只好折回步骤三重新在功能网里补了两条功能一是根据图像对比度下降或特定区域检测值持续低于阈值来评估镜头污染程度的监测功能二是当污染程度超过阈值时输出清洁请求并在仪表提示的系统响应功能。本来计划三天收尾的FMEA硬生生拖了一周。这个教训我现在经常讲给团队听功能分析阶段多花一小时把各种真实工况下的边界功能过一遍胜过后面复盘一周。7. 功能分析的出口检查怎么判定这一步做得够不够7.1 一张可以直接拿去用的自检清单功能分析收尾时我会拿一张清单逐条过这里分享出来可以直接复用到自己的项目里序号检查项判定标准1功能覆盖度结构树每个要素至少有一个对应功能没有僵尸要素2功能可验证每个功能描述至少包含一个可测量的要求性能、时间、精度等3层级完整性功能网覆盖顾客功能、系统功能、组件功能三个层级4接口覆盖跨控制器、跨子系统边界的所有接口都有对应的接口功能5监测覆盖所有安全相关功能S或D评分可能较高的功能都定义了对应的监测功能6响应覆盖每个监测功能至少匹配一个系统响应功能没有“只报警不动作”7恢复路径每个响应功能定义了故障恢复条件和退出状态8唯一标识每个功能有唯一编号功能矩阵中无重复、无缺漏9与规范一致功能要求与系统需求规范、安全目标、诊断规范一致无冲突或未对齐项10可追溯性功能可以追溯到结构树中的指定要素也可以在后续失效分析中作为失效模式的锚点这十条全过功能分析这一关才算真正通过。7.2 功能分析的输出物和文档形态功能分析阶段的交付物通常包括三类功能网/功能树、功能矩阵表、功能要求清单。如果是用FMEA软件工具做的项目功能分析的所有内容会直接作为下一环节的输入字段如果是Excel流派的团队我建议至少建三张工作表一张放结构树一张放功能网用编号引用连线关系而不是靠画图一张放功能矩阵。功能要求清单的格式可以这样组织功能编号、功能描述、所属要素、要求类型性能/时间/精度/环境、量化值、来源文件编号。这张清单在步骤四失效分析时可以直接辅助判断每一个失效模式所违反的具体要求也能在步骤七审计时提供清晰的追溯链路。7.3 往步骤四失效分析走的“接口”从功能到失效模式的映射功能分析的最后一件事就是为步骤四铺好路。在失效分析里每个功能至少要问三组问题第一组功能本身失效了怎么表现比如“电压采集功能”采集到的电压值偏高、偏低、无输出、输出抖动。第二组功能的上游输入失效了这个功能会怎样比如传感器供电掉了采集功能的结果是什么。第三组功能的监测和响应链路是否被考虑到了比如过压诊断功能自己漏报了系统会进入什么状态。如果功能分析阶段每个功能都写清了功能和要求的绑定关系这三组问题基本不用重新梳理逻辑直接照着功能链一条条拆就行。所以我说功能分析做到位失效分析就是水到渠成的事。这里有一个实操小技巧在功能矩阵里把每个功能的编号记录好做失效分析时直接用功能编号作为失效模式的第一列前缀比如FN003-01、FN003-02。这样评审时大家看到编号就能立刻知道这个失效模式对应的功能是谁不用来回翻。步骤七审计时也不至于被人指着表格问“这条失效模式到底是哪个功能的”。带团队做FMEA这么多年我的核心体会就是一句俗话磨刀不误砍柴工。步骤三看起来只是写写句子、连连箭头不像步骤五风险评估那样大红大绿、也不像步骤六优化那样有立竿见影的整改措施但它决定了整个FMEA-MSR分析的骨架有没有立稳。你在这里投入的时间会在步骤四到步骤七的每一刻都得到回报。最后再分享一个小建议功能分析表格里的每个功能务必配一个唯一编号别用文字描述代替。评审、追溯、修改、审计有好几次我都靠这串编号在几十页的FMEA文档里快速定位问题这也是这些年我带项目养成的习惯建议你也从一开始就保持。