FMEA-MSR做到第三步功能分析的时候很多团队容易产生一个错觉功能嘛就是把产品说明书里的功能列一遍不就行了。真这么干了后面步骤四的失效分析一定会卡壳因为你会发现失效模式要么列不出来要么列出来了一堆跟系统实际行为对不上号的东西。我在实际项目里带过好几轮FMEA-MSR功能分析这一步跑得越扎实后面失效分析和风险评价就越顺它是一个承上启下的节点绝对不是走个过场。这篇东西就是聊清楚一件事FMEA-MSR的步骤三功能分析到底该怎么拆、拆到什么颗粒度、拆完怎么为下一步失效分析铺路。如果你正在做汽车电子、新能源三电、控制器类产品的MSR分析或者你刚接手团队想规范FMEA流程可以参考我在实操里沉淀出来的这套做法。1. 在FMEA-MSR的5步法中功能分析到底承担什么角色1.1 功能分析是失效分析的地基FMEA-MSR整套方法论的底层逻辑很朴素先搞清楚系统“应该做什么”再去分析“做不好会怎样”最后评估“做不好之后系统能不能自己发现、能不能自己应对”。步骤三功能分析对应的就是“应该做什么”这个环节。这一步没梳理清楚后面所有失效分析都是无源之水。用盖房子打比方结构分析是搭框架功能分析是往框架里填充墙体。步骤二结构分析给你的是零件清单、系统层级、物理连接关系它回答的是“系统由什么组成”。到了步骤三你要回答的是“各个组成部分各自承担什么职责、彼此之间怎么协作、整个系统对外提供什么价值”。同样是让电机转起来在结构分析里你只能看到一个电机和它的接线端子在功能分析里你才能表达出“控制器按驾驶员的加速踏板意图向电机控制系统输出扭矩指令”这样有逻辑关系的行为。这里我特别想提醒一点很多团队在步骤二结构分析上投入大量精力画边界图、画结构树到了功能分析就明显泄气常常半天时间草草收场。这个习惯非常危险因为FMEA-MSR后半程的失效分析、风险评价、优化措施全部是以功能分析作为索引的。功能定义得越模糊失效模式就越是拍脑袋想出来的最终的FMEA表格看似填得满满当当实际上经不起推敲。1.2 MSR与传统DFMEA功能分析的最大区别传统DFMEA的功能分析关注的是系统本身为客户提供什么功能比如“提供制动力”“传输扭矩”“储存电能”。这些功能一般可以用动词加名词来描述分析的对象是产品正常工作的行为。FMEA-MSR则多了一条完整的逻辑主线监测功能与系统响应功能。我最早接触MSR时最大的困惑就在这里。后来把AIAG和VDA联合发布的FMEA手册翻来覆去看了几遍又在实际项目里试错了几轮才真正形成感觉MSR分析的对象不只是“系统要做什么”还包括“系统如何知道自己做得不好”以及“系统知道自己做得不好之后怎么应对”。具体来说MSR的功能分析至少要覆盖三类功能。第一类是系统的基本功能也就是客户能感知到的那些功能比如“电池管理系统根据温度信号对电池组进行加热或冷却”。第二类是监测功能也就是系统对自己状态、对输入信号、对外部环境的监测能力比如“监测高压接触器是否正常闭合”、“监测绝缘电阻是否低于阈值”。第三类是响应功能也就是系统在识别到异常状态后执行的动作比如“在过流工况下断开高压接触器”、“在绝缘故障时限制功率输出并点亮故障灯”。这三类功能放在一起分析才是完整的功能分析。如果你的MSR功能分析只写了第一类基本功能那后面出现的所谓“MSR特有失效模式”就都是空中楼阁。我见过不少团队的FMEA-MSR表格里根本没有体现监测功能最后的失效模式却写了一大堆传感器故障、诊断失效前后完全对不上这就是功能分析阶段埋下的雷。1.3 功能分析输出物与其他步骤的关系从流程管理的角度看步骤三的功能分析不是孤立存在的。它的输入是步骤二结构分析输出的边界图、结构树、功能矩阵它的输出比如功能树、功能网、参数图、功能要求表直接决定了步骤四失效分析时失效模式的完整程度也决定了步骤五风险分析时S、O、D评分的准确性。我们团队现在做FMEA-MSR时有一个铁律步骤三功能分析没有完成评审坚决不进入步骤四。评审标准就三条。第一条所有客户功能、产品功能、监测功能、响应功能是否都有清晰的责任主体也就是对应到步骤二里的结构元素上。第二条所有功能是否都有可量化的功能要求至少要有性能指标、时间指标或者状态判定条件里的一种。第三条所有功能是否都画进了功能网不存在孤立节点。这三条有一条不满足就打回重做。2. 动手之前先备齐三样东西功能分析的输入准备2.1 边界图与接口图把系统框起来功能分析开始之前第一件要做的事是把系统的边界重新确认一遍。边界图如果画得不清楚功能分析过程中团队一定会争吵“这个功能算不算我们系统的”。物理边界、信号边界、能量边界要分开画。物理边界是指哪些零件归你管哪些零件算外部。比如做电池包BMS电芯、采集板、主控板、接触器、熔断器是你的边界整车VCU、充电桩则不属于物理边界只在接口层面说明。信号边界是指哪些传感器信号、通讯信号流入你的系统哪些控制指令由你的系统发出去。能量边界是指系统输入什么电压、什么功率对外输出什么能量。这一步很多人嫌麻烦尤其是老产品做MSR分析时觉得系统是现成的边界画不画无所谓。我建议还是老老实实画一遍因为MSR功能分析中监测功能往往涉及“同一个信号在不同条件下被不同功能使用”的情况边界不明确后面写监测功能时就会漏掉跨边界的干扰因素。比如高压接触器控制功能既受BMS内部控制策略影响又受整车VCU的放电请求信号影响边界图上如果不标清楚信号来源功能分析时你很可能漏掉“整车通讯故障后接触器应该如何动作”这条关键的响应功能。2.2 需求文档与客户技术要求没有量化指标的“功能”都很危险功能分析不是凭空想象功能清单而是要把需求文档里的每一条要求转化成功能描述。需求可能来自客户提供的技术规范、内部产品定义文档、法规要求甚至是上一个项目积累下来的经验教训清单。这些需求输入本质上是给功能分析提供了“标准答案”的素材。这里我要强调“量化”这个词。很多需求文档里写着“系统应具备过流保护功能”这种描述在功能分析时是不能直接用的。你得继续追问过流多少安培算是过流持续多长时间触发保护保护动作的时间要求是几毫秒之内保护动作后的系统状态是什么。把这些问题全部定义清楚功能要求才算是写完整了。我在项目例会上经常对团队说功能描述里如果出现“能够”、“应该”、“可靠”这种含糊词汇就说明功能要求还没有定义到位。法规和标准要求往往是最容易被忽略的输入尤其是功能安全相关的要求ISO 26262里定义的安全目标、安全状态、容错时间间隔这些在普通需求文档里不一定有但它们是MSR响应功能的核心输入。做MSR功能分析时把安全机制、安全状态的定义提前拉出来监测功能和响应功能的框架基本上就有了雏形。2.3 功能清单草稿把已有信息先摊在桌面上正式开功能分析会之前我会要求功能负责人先拉一个功能清单草稿。这个草稿不追求完美但要把已掌握的信息全部摊在桌面上。清单的格式很简单功能名称、功能描述、所属结构元素、输入信号/能量/物料、输出信号/能量/物料、功能的要求指标。这个草稿的作用有两层。第一层它让会议有靶子团队可以在草稿基础上补充和修正而不是面对一张白纸各说各话。第二层它逼着功能负责人在会前就过一遍资料避免会议上现翻图纸、现找说明书浪费时间。我会控制在功能分析评审会之前至少两个工作日把草稿发给参会人员让大家提前看会上直接进入争论和确认环节。草稿阶段还有一个附加动作把所有与“监测”、“诊断”、“降级”、“保护”、“响应”相关的功能词条单独标出来。这些关键词通常在需求文档里散落各处比如“检测到绝缘故障”、“点亮故障指示灯”、“进入跛行模式”、“断开高压回路”等等。把它们归拢到一起你就有了MSR功能分析里监测功能和响应功能的雏形。很多团队做MSR分析时觉得监测功能无从下手其实问题就出在没有提前做这个归拢整理的动作。3. 功能拆分实操从客户功能到产品功能一层一层拆3.1 用功能树拆出层级功能树是最基础的功能分析工具它解决的问题是功能之间的“父子承接关系”。顶层的客户功能代表客户可感知的价值底层的基础功能代表具体的实现手段。做MSR功能分析时功能树至少要画到三层客户功能、系统功能、组件功能。举个例子客户功能是“车辆在充电过程中保持高压系统安全”这是终端用户关注的命题。系统功能则是“电池管理系统在充电过程中监测绝缘状态”、“电池管理系统在绝缘故障时断开充电回路”、“电池管理系统在充电过程中控制接触器按序闭合”。再往下拆组件功能是“绝缘检测模块采集绝缘电阻值”、“主控芯片计算绝缘电阻变化率”、“接触器驱动电路输出断开信号”。拆功能树时最常见的错误是层级跳变。有人从客户功能直接跳到组件功能中间的系统和子系统层级完全忽略也有人在同一层面混入了不同粒度的功能比如把“提供扭矩”和“检查制动踏板位置传感器”放在同一层级。这两种情况都会让功能树失去索引意义后续失效模式分析时就会出现混乱。判定层级是否正确的标准是父功能能够通过子功能的组合来实现子功能的组合结果能完整支撑父功能。3.2 用功能网解决功能之间的依赖功能树展示了层级但它表达不了功能之间的横向依赖关系。MSR功能分析里大量的关键逻辑藏在横向关系里比如“监测功能”与“基本功能”之间常常是监测功能为基本功能提供服务。为了把这种依赖表达清楚我会在功能树的基础上再画一张功能网。功能网的节点是功能连线是功能之间的支持、触发、使能、约束关系。举个简单例子“高压接触器闭合”这个基础功能依赖“接触器状态监测功能”返回的状态信号“接触器状态监测功能”依赖“采集板供电功能”正常工作“采集板供电功能”又受“低压电源监测功能”的约束。这一连串的依赖关系在功能树里只能看到纵向的归属在功能网里才能看到横向的传递链。画功能网时我建议用不同颜色区分功能类型。基本功能用一种颜色监测功能用另一种颜色响应功能用第三种颜色。这么做的好处特别明显套色之后你会发现监测功能几乎都是通过“信号”节点与基本功能、响应功能连接在一起的而这些信号节点往下一步就直接对应到失效分析时的监测失效模式。我在实际项目中功能网画完之后后续失效分析的主干逻辑基本已经清晰了剩下的工作很大程度上是在这个网上做“找失效”的填空。3.3 功能分析实操以BMS高压接触器控制为例用一个具体的系统把上面的方法串一遍。我们就拿新能源车电池管理系统里的“高压接触器控制”这个典型功能来说。先确定边界系统是电池包内部的BMS结构元素包括主控板、高压采集板、低压采集板、正极接触器、负极接触器、预充电阻、加热继电器等。边界之外是整车VCU、充电桩、快充继电器等。然后画功能树。客户功能是“在正常驾驶和充电工况下可靠地建立和断开高压回路”系统功能拆成“接收整车上下电请求”、“执行上下电时序控制”、“监测接触器真实状态”、“诊断接触器粘连/开路故障”、“在故障时执行安全断开”这几个功能。组件功能继续往下拆比如“监测接触器真实状态”下面是“采集接触器辅助触点信号”、“采集母线电压变化”、“结合主控算法判断接触器状态”这三个组件功能。再画功能网。这里最关键的依赖关系是上下电时序控制功能依赖接触器状态监测功能提供准确的状态反馈如果监测功能失效时序控制就可能在错误的时机执行闭合或断开动作。响应功能“在故障时执行安全断开”依赖诊断功能给出准确的故障判定而诊断功能又依赖采集功能提供可靠的电压和触点信号。这张网画清楚之后你会自然地识别出一个MSR失效场景接触器触点已经粘连但辅助触点信号因为烧结拉弧没有变化系统误以为接触器已正常断开于是进入下一步操作最终导致带载分断烧蚀接触器。这个失效场景完全是从功能网的依赖关系里推出来的。我在这一步的经验是不要试图在一张纸上画全所有功能先把核心功能链画准确再从功能节点逐步发散。功能网画到能覆盖所有三类功能并且每个节点都能在结构元素上找到责任主体时就可以进入下一步了。4. MSR特有功能监测功能与响应功能的识别4.1 监测功能怎么定义才算完整MSR功能分析的灵魂是监测功能。很多团队做完基本功能分析就觉得完事了实际上在MSR语境下监测功能不加进去整个分析就是不完整的。那监测功能怎么定义才算完整我总结了三个维度。第一个维度是对象。系统到底在监测什么是系统自身的内部状态还是外部环境的输入还是被控对象的反馈比如BMS监测自身的供电电压这是监测系统状态监测绝缘电阻这是监测外部环境与系统之间的边界监测接触器闭合状态这是监测被控对象的反馈。这三个对象类别都要识别到漏了任何一类后面就会漏掉对应的失效模式。第二个维度是参数。监测功能到底监测哪些物理量这些物理量的量程、精度、采样频率、滤波方式是怎样的写监测功能时很多团队只写“监测母线电压”参数完全缺位。我要求至少写出量程范围和采样频率因为这两个参数直接决定了监测功能能够捕捉到的失效类型。采样频率太慢瞬态故障捕捉不到量程范围不够过压信号一进来就饱和监测功能实际上已经失效。第三个维度是时间。监测是连续监测还是周期巡检从异常发生到系统识别出异常这个延迟时间是多久在MSR分析里时间是一个贯穿始终的关键变量因为响应功能的效果完全取决于监测功能发现异常的早晚。举例来说母线过压监测如果50毫秒才能触发一次报警而母线电压在10毫秒内就能被充到器件耐压极限那这个监测功能指标就是不合格的。4.2 响应功能要写到什么颗粒度响应功能是MSR的另一半灵魂。响应功能描述系统在识别到异常状况之后做了什么。最让团队头疼的是响应功能到底写到什么颗粒度算合适。我的判断标准是写到人们能够依据这个响应功能描述来设计硬件执行器的控制逻辑的程度。以“过流保护响应功能”为例不能只写“在过流时断开高压”要写清楚触发条件是什么母线电流超过多少安培持续多长时间、确认机制是什么一次采样确认还是连续两次采样确认、响应动作是什么主动断开正极接触器并禁止重新闭合、响应时间是多少从电流事件发生到接触器完成断开不超过多少毫秒、恢复策略是什么需要人工下电重新上电才能恢复还是系统自动恢复、降级策略是什么如果接触器断开失败是否启用熔断器作为最后一级保护。这六个方面都写清楚响应功能才算是完整的。实际操作中响应功能经常跟故障诊断策略、故障处理策略混在一起其实它们是有边界要求的。诊断策略是“怎么判定故障”对应的是监测和诊断算法响应功能是“判定故障之后执行什么动作”对应的是执行器控制逻辑。这两个一定要分开写但又要保证在时序上能够衔接得上。我在评审时经常遇到的场景是诊断功能里写了“检测到过温故障后进入降功率模式”响应功能里也写了“进入降功率模式”两边都写了但到底是诊断负责触发还是响应负责执行没人说得清这就是颗粒度没有切分清楚。4.3 参数图(P-Diagram)在MSR里的特殊用法参数图是功能分析阶段一个被很多人低估的工具它在MSR里有特殊的应用价值。参数图的结构是理想功能在中心输入信号从左边进入输出信号从右边出来控制因素在顶部噪声因素从底部影响系统。它的核心作用是帮助团队识别所有影响功能实现的因素为后续失效分析和风险评价提供依据。用于MSR功能分析时参数图的输入不再仅仅是正常的控制信号还要把故障状态信号、干扰信号作为输入一并考虑。更关键的是噪声因素的分类在MSR里要扩展除了传统的环境噪声温度、湿度、振动、负载噪声、时间退化、相互作用噪声之外我还要额外列出“传感器相关噪声”和“执行器相关噪声”。因为在纯机械或纯电气的FMEA里传感器噪声通常只影响某一个信号的精度但在MSR里传感器噪声可能会直接触发错误的诊断和错误的响应行为其后果要严重得多。还是用BMS举例来做一次实际推演。功能档位同轴度检测失败后门控单元按备用策略判定档位状态并允许启动电机。其终极目标是避免整车在误判状态下启动行驶产生安全隐患。这里我们先聚焦于BMS绝缘监测功能中的MSR参数图推演。输入变量包括传感器原始绝缘阻值、温度补偿值、采样时钟基准。理想功能是“根据绝缘电阻值与标准阈值比较准确输出绝缘故障标志”。噪声因素在这里要细看绝缘电阻测试本身存在激励电压漂移环境湿度会造成漏电流增大连接器端子氧化导致接触电阻变大采样电路本身的温漂会引起基准电压变化。这些噪声因素在传统DFMEA里可能只影响测量精度被评价为低严重度问题但在MSR分析里它们会直接影响监测功能的可靠性进而导致误报或漏报。一个误报会导致车辆抛锚一个漏报则会导致绝缘失效时无保护。这两种失效的严重度都不低。参数图画到这一步输出的非预期表现就自然出来了一是误报正常绝缘状态下触发故障码二是漏报绝缘劣化时未能及时报警三是延迟报警绝缘故障已经存在但报警延时超过了安全阈值。这三类非预期输出直接就是步骤四失效分析中监测功能失效模式的雏形。5. 功能分析与失效分析怎么衔接为步骤四铺路5.1 功能要求、功能度量与功能形态功能分析阶段产出的功能要求是步骤四失效分析的重要判据。功能要求明确之后失效模式的定义就有了基准。所谓失效就是功能要求不被满足的表现。功能要求写得越具体失效模式就越好识别。这里我常用的一句话是失效模式就是功能要求的反义词。功能度量是为了确保功能要求可以被验证。每个功能要求都应该有一个或多个可测量的度量指标这些指标后续用于确认失效模式的影响程度也用于D值探测度评分时判断现有探测手段是否足够。举个例子功能要求是“绝缘电阻低于100欧姆每伏时在100毫秒内发出绝缘故障报警”那功能度量就明确为“从绝缘电阻穿越阈值到故障码置位的时间偏差不超过10毫秒”。没有这样的度量指标后面步骤五里D值的评分就完全是拍脑袋。功能形态是指系统实现功能时的物理或逻辑结构形式包括硬件实现、软件实现、人机交互等。在MSR功能分析中功能形态决定了失效模式分析时需要考虑的失效类型。硬件失效要考虑开路、短路、漂移软件失效要考虑逻辑错误、时序错误、配置错误人机交互失效要考虑误操作、未操作、信息误读。功能分析阶段把功能形态定义清楚后面失效分析时才能做到不漏项。5.2 从功能到失效模式的映射方法功能分析完成后如何顺利过渡到步骤四失效分析关键在功能网。功能网上的每一个功能节点理论上都应该有对应的失效模式这是最基本的完整性要求。具体做法是从每个功能节点出发逐项问三个问题功能完全不工作会怎样功能意外工作了会怎样功能工作但性能不达标会怎样。这三个问题对应的就是失效模式的三种基本类型功能丧失、功能误动作、功能劣化。对于MSR特别关注的监测功能这三个问题要这样问监测功能完全不工作系统就成了瞎子任何故障都发现不了监测功能误动作系统就成了惊弓之鸟把正常工况误判为故障频繁触发不必要的保护动作监测功能工作但性能不达标比如采样精度不够、响应时间过长系统发现了故障但为时已晚。这三个方向都列一遍监测功能相关的失效模式基本上就齐了。从功能网到失效模式的映射还有一个隐蔽性问题失效传播路径。功能网里的依赖关系决定了某个底层功能的失效会沿着依赖链向上传播最终体现为顶层客户功能的失效。在步骤四失效分析时团队往往能识别出直接失效但容易遗漏间接失效。我的解决办法是在功能分析阶段就标注出功能网里每一条依赖链的关键程度用一个简单的三级标记强依赖、中依赖、弱依赖。到了失效分析时优先保证强依赖链上的每个功能节点都要有完整的失效模式覆盖。5.3 团队怎么高效完成功能分析功能分析不是一个人的工作它是一个典型的跨职能团队活动。我在实操中总结出的高效会议模式是系统工程师、功能安全工程师、硬件工程师、软件工程师、测试工程师五类角色必须到场五类角色各自带着不同视角参与分析。系统工程师维护功能树的逻辑一致性功能安全工程师把关安全机制和安全目标的映射硬件工程师负责确认监测功能在硬件层面的可实现性软件工程师负责确认响应功能在软件层面的逻辑可行性测试工程师负责确认功能度量的可验证性。会议节奏上我会把功能分析拆成三次专题会。第一次会议只做一件事梳理功能树确认层级和功能描述大约需要半天。第二次会议做功能网和参数图重点识别监测功能和响应功能以及功能之间的依赖关系这需要一天左右。第三次会议是功能要求的细化评审逐条过功能要求和功能度量把含糊的表述全部澄清掉也需要一天左右。三次会议之间留出足够的间隔时间让工程师们有机会回去查数据、补资料而不是一次性开一个马拉松会议开到后面大家都疲劳了分析质量直线下降。6. 常见问题与排查技巧实录6.1 功能定义含糊导致的失效模式遗漏实际操作中最典型的问题是功能定义本身就含糊。比如“电池管理系统应具备故障诊断功能”这种描述在功能分析中一定要打回去重写。故障诊断功能至少可以拆成“诊断输入信号合理性”、“诊断执行器回读状态”、“诊断内部控制器状态”、“诊断通信链路状态”这四个子功能每个子功能还要明确诊断对象、诊断方法、诊断周期和故障响应。如果功能定义含糊后面失效分析时就会出现一个典型现象大家对着“故障诊断功能失效”这一条发呆不知道该怎么拆。然后有人会说“诊断功能失效就是诊断不出来呗”于是表格里填了一大堆同义反复的失效模式。解决这个问题的唯一办法就是在功能分析阶段把每个功能定义到不可再拆的原子级。什么算原子级我的判断标准是如果继续拆下去拆分后的功能没有办法对应到具体的硬件引脚或者软件函数那么这个功能就不用再拆了。6.2 层级混乱跨级拉通还是逐级展开另一个常见问题是功能分析的层级混乱。有些团队为了省事直接拿客户功能对照组件功能跳过了系统和子系统层级。这种做法的直接后果是失效分析时无法定位失效的责任组件FMEA表格里的“结构元素”一栏只能填系统级名称导致后续措施无法落地。在我的团队里层级问题有一个硬性要求功能树必须与结构树一一对应功能树的每一个节点都必须能在结构树上找到对应的结构元素。客户功能对应产品级结构系统功能对应系统级结构组件功能对应组件级结构。一旦出现跨级映射评审时必须停下来确认是功能描述层级不对还是结构树本身缺层了。这一步虽然麻烦但它是保证FMEA-MSR表格结构可追溯性的基础。6.3 功能分析与仿真测试脱节我在实际项目里踩过的最大的坑是功能分析做完之后分析结果束之高阁完全没有传达到仿真和测试团队。功能分析里定义的监测功能响应时间指标、功能度量方法如果测试团队根本不知道那后续的验证工作就是盲人摸象测了一堆项目却覆盖不到关键的功能要求。现在我们的流程里功能分析评审会必须邀请测试工程师参加评审通过后的功能要求清单直接纳入测试用例编写输入。凡是功能要求里定义了“监测功能在100毫秒内发出故障报警”测试用例里就必须有一条对应的验证项同时用示波器实测故障信号到报警置位的实际时间用来和功能要求指标做比对。这样的闭环才是功能分析这件工作真正的价值所在它不只是填一份FMEA表格而是让整个团队对系统的行为形成共同的理解基线。6.4 常见问题速查表我把实操中频繁遇到的功能分析问题整理成了一个速查表方便你在做FMEA-MSR时对照自查。常见问题典型表现排查方向预防措施功能定义含糊功能描述中出现“能够、应该、可靠”等词逐条追问功能的任务对象、触发条件、成功标准用动词名词量化指标的结构重写功能描述客户功能遗漏评审时发现某条客户需求没有对应任何功能核对客户需求清单与功能树顶层的映射关系建需求追溯矩阵逐条确认需求被覆盖监测功能缺失失效分析无法回答“系统怎么知道出事了”检查功能网中是否有监测类型节点按监测对象系统自身/外部环境/被控对象逐项排查响应功能与诊断功能混淆诊断策略与响应动作描述重复且互相矛盾明确诊断归属监测侧、动作归属响应侧分开两个清单评审时逐一对齐触发条件和执行逻辑功能层级跳变功能树上顶层直接连底层节点检查父子功能之间是否缺少中间层功能树与结构树逐级对应跨级需评审确认功能度量缺失功能要求无法通过测试或仿真验证补充可量化的指标明确测试条件和判定阈值每个功能要求至少绑定一个可验证的度量指标参数图噪声不全传感器漂移、连接器老化等噪声被忽略从环境、负载、时间、相互作用、传感器、执行器六个维度筛查噪声源按噪声分类清单逐项过一遍团队跨职能不足会上只有系统工程师在发言检查硬件、软件、测试、功能安全工程师是否全程参与会议前明确各角色的输入要求会议中推行动态引导式讨论6.5 一点补充工具功能分析评审检查单最后分享一个我在每个项目功能分析完成后都会用的评审检查单它只有几个问题但每个问题都值得认真回答。第一功能树是否完整覆盖了客户需求中所有可感知的功能。第二功能网中是否存在没有任何输入的输出或者没有任何输出的输入。第三每个监测功能是否都定义了监测对象、监测参数、采样周期和判定阈值。第四每个响应功能是否都定义了触发条件、执行动作、执行时间和恢复策略。第五功能要求清单里的每个指标在当前测试条件或仿真条件下是否具备可验证性。第六功能树、功能网、参数图这三套交付物是否能够与结构树完全对上。这些检查项看起来平淡无奇但每一条都是在项目里付出过代价之后沉淀出来的。功能分析是FMEA-MSR全流程中技术密度较高的一步也是最容易被低估的一步。你在这一步投入的每一分精力后面都会成倍地省回来。