如今，在汽车行业能够保证和提高系统组件质量的措施得到越来越多的关注，原因之一是车辆召回事故的次数快速增长到了令人震惊的数量。在北美洲，召回比例由2013年的142.5%攀升到2014前半年的455%。多个oem在不同的车系中复用同一个系统组件是导致这个高召回比例的原因之一。为此，能够传播的质量问题会对制造业公司的生存造成一定的威胁。
fmea分析是避免质量问题的方法之一，产品开发的全部过程中贯穿fmea分析能在开发初期有效避免质量问题。在系统设计阶段，通过分析潜在失效和风险定义应对措施并评估这些措施对风险的控制和降级能力。fmea是一个完善的并被广泛使用的方法，在开发工程中fmea的有效性和易损性可能导致系统的质量问题，所以如何保证fmea的有效性和避免易损性才是避免质量问题的关键。
fmea分析过程，需要考虑下列情况：
fmea与其他开发活动需同时开展，但是，如果与其他活动的结合不够充分。这将会导致一致性问题以及附加的成本/工时。在极端情况下，fmea与系统当前的开发状态完全不匹配。这样将会无法识别失效，或者制定的应对措施不够完整。
对fmea表格里面定义的应对措施跟踪不够充分。通常这些措施是不可能并入到需求管理过程中或者被需求管理过程所忽视。
对于部件，组件，子系统和系统开发的fmea表格之间的链接关系不充分。因此，在组件或者部件级的功能失效的潜在影响在整车级并不能全部看到或者进行分析。
fmea的复用只在一定程度上具有可行性。但如果fmea是独立系统模型进行开发的，他们的复用将会很困难。例如：在设计初期定义的失效很容易忽视何时更新的设计版本或者何时复用的组件。另一方面，已有系统的fmea表格无法提供足够的证据，用于分析潜在失效以及这些失效对原有系统变体或者改进部分的影响分析。
为了解决这些问题，需要进行过程改进即将fmea开发紧密的集成到系统开发过程中，需要按照一致和rule-compliant要求执行fmea开发，同时还要将fmea和系统模型更好的链接起来。
如果通过适当的辅助工具，可以很快的识别和很容易的解决fmea开发过程的一致性问题。
基于模型的开发方法即使用半形式语言(如sysml)，是改进开发过程（fmea开发集成到系统开发过程中），解决一致性和效率问题的一个关键因素。
.jpg)
上图所示的是使用sysml语言设计的热水器模型。这个模型显示了系统的组件以及组件间的层级和连接关系。此外，在模型中还定义了分配到每个组件上的功能以及功能之间的依赖性。此时，所有fmea开发所需的关键初始信息都已具备。同时，为了避免不一致性和重复的工作步骤，在系统模型中还直接加入了组件的失效模式和功能的故障（如下图所示）。一方面，可以通过典型的方法例如hazop分析识别功能的故障。另一方面，从组件/部件库（在随机硬件失效情况下）或者从对当前应用领域的统计和调查（覆盖系统故障）获得失效模式。
.jpg)
fehlfunktionen = malfunctions
fehlermode = failure modes
下一步，通过fmea表格将这些失效模式和功能故障信息链接起来。在系统模型中直接添加注释作为失效细节，这个“信息来源”的概念避免例如在不同工具中树型结构的复制和与之相关的不一致的风险。基于sysml模型开发的fmea表格，可以从系统模型中直接获得包含失效模型和功能故障的系统架构。
在fmea表格中定义每一个失效模式和功能故障的causes/effects的失效链。同时，进行风险评估，并获得和定义必要的应对措施（如下图所示）。
.jpg)
所有在模型架构中的变化能够同步的在表格中呈现是fmea表格和sysml模型紧密链接的结果。甚至，可以通过sysml模型的层级和面向组件的架构获得事件链，通过事件链可跟踪到系统顶事件失效的影响。除了上述的优势之外，sysml模型开发中的type/instance概念促使了fmea数据的复用性。例如，通过组件库管理复用的组件，组件的失效模式，以及组件内部影响链，确保组件在其他项目的可用性。
此处描述的基于sysml的fmea开发方法在实践中需要适当的工具，否则这些预期的优势----改进的一致性和提高效率—将无法实现。一个适当的工具不仅增加了fmea的验收方法,也可避免fmea被认为只是一个系统开发所必要的耗时和繁琐的额外活动。