企业官网建设流程全解析

我参加过不少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 好功能和坏功能放在对比表里看

我把多年来评审中见到的高频问题整理成一张对比表，新人在动笔前先过一遍这三组对照，能少踩一半的坑。

每个“好的功能描述”里都藏着可验证的信息：触发条件、测量周期、阈值、时间要求、输出结果。有些人觉得这样写太长，表格塞不下。我的经验是：正式评审表格里写精简版（动词+名词+关键要求），工作坊白板上必须写全量版，等所有逻辑都对齐了再压缩进表格。千万别在讨论阶段就为了表格美观而牺牲完整度。

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过压场景把这条链补全：

1. 物理状态探测：电芯因过充导致电压升高至4.35V
2. 采集与转换：电压采集模块将模拟电压转换为数字值并传送给诊断模块
3. 诊断与判断：诊断模块比较电压值超出4.2V阈值并持续200ms，确认过压故障
4. 系统响应：充电接触器断开、充电请求被拒绝、DTC置位、仪表屏幕点亮“充电故障”提示
5. 故障恢复：当电芯电压回落到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 一张可以直接拿去用的自检清单

功能分析收尾时，我会拿一张清单逐条过，这里分享出来，可以直接复用到自己的项目里：

这十条全过，功能分析这一关才算真正通过。

7.2 功能分析的输出物和文档形态

功能分析阶段的交付物通常包括三类：功能网/功能树、功能矩阵表、功能要求清单。如果是用FMEA软件工具做的项目，功能分析的所有内容会直接作为下一环节的输入字段；如果是Excel流派的团队，我建议至少建三张工作表，一张放结构树，一张放功能网（用编号引用连线关系，而不是靠画图），一张放功能矩阵。

功能要求清单的格式可以这样组织：功能编号、功能描述、所属要素、要求类型（性能/时间/精度/环境）、量化值、来源文件编号。这张清单在步骤四失效分析时，可以直接辅助判断每一个失效模式所违反的具体要求，也能在步骤七审计时提供清晰的追溯链路。

7.3 往步骤四失效分析走的“接口”：从功能到失效模式的映射

功能分析的最后一件事，就是为步骤四铺好路。在失效分析里，每个功能至少要问三组问题：

第一组：功能本身失效了怎么表现？比如“电压采集功能”采集到的电压值偏高、偏低、无输出、输出抖动。

第二组：功能的上游输入失效了，这个功能会怎样？比如传感器供电掉了，采集功能的结果是什么。

第三组：功能的监测和响应链路是否被考虑到了？比如过压诊断功能自己漏报了，系统会进入什么状态。

如果功能分析阶段每个功能都写清了功能和要求的绑定关系，这三组问题基本不用重新梳理逻辑，直接照着功能链一条条拆就行。所以我说，功能分析做到位，失效分析就是水到渠成的事。

这里有一个实操小技巧：在功能矩阵里把每个功能的编号记录好，做失效分析时直接用功能编号作为失效模式的第一列前缀，比如FN003-01、FN003-02。这样评审时，大家看到编号就能立刻知道这个失效模式对应的功能是谁，不用来回翻。步骤七审计时，也不至于被人指着表格问“这条失效模式到底是哪个功能的”。

带团队做FMEA这么多年，我的核心体会就是一句俗话：磨刀不误砍柴工。步骤三看起来只是写写句子、连连箭头，不像步骤五风险评估那样大红大绿、也不像步骤六优化那样有立竿见影的整改措施，但它决定了整个FMEA-MSR分析的骨架有没有立稳。你在这里投入的时间，会在步骤四到步骤七的每一刻都得到回报。最后再分享一个小建议：功能分析表格里的每个功能，务必配一个唯一编号，别用文字描述代替。评审、追溯、修改、审计，有好几次我都靠这串编号在几十页的FMEA文档里快速定位问题，这也是这些年我带项目养成的习惯，建议你也从一开始就保持。