Accendo Reliability

Your Reliability Engineering Professional Development Site

  • Home
  • About
    • Contributors
  • Reliability.fm
    • Speaking Of Reliability
    • Rooted in Reliability: The Plant Performance Podcast
    • Quality during Design
    • Way of the Quality Warrior
    • Critical Talks
    • Dare to Know
    • Maintenance Disrupted
    • Metal Conversations
    • The Leadership Connection
    • Practical Reliability Podcast
    • Reliability Matters
    • Reliability it Matters
    • Maintenance Mavericks Podcast
    • Women in Maintenance
    • Accendo Reliability Webinar Series
  • Articles
    • CRE Preparation Notes
    • on Leadership & Career
      • Advanced Engineering Culture
      • Engineering Leadership
      • Managing in the 2000s
      • Product Development and Process Improvement
    • on Maintenance Reliability
      • Aasan Asset Management
      • AI & Predictive Maintenance
      • Asset Management in the Mining Industry
      • CMMS and Reliability
      • Conscious Asset
      • EAM & CMMS
      • Everyday RCM
      • History of Maintenance Management
      • Life Cycle Asset Management
      • Maintenance and Reliability
      • Maintenance Management
      • Plant Maintenance
      • Process Plant Reliability Engineering
      • ReliabilityXperience
      • RCM Blitz®
      • Rob’s Reliability Project
      • The Intelligent Transformer Blog
      • The People Side of Maintenance
      • The Reliability Mindset
    • on Product Reliability
      • Accelerated Reliability
      • Achieving the Benefits of Reliability
      • Apex Ridge
      • Metals Engineering and Product Reliability
      • Musings on Reliability and Maintenance Topics
      • Product Validation
      • Reliability Engineering Insights
      • Reliability in Emerging Technology
    • on Risk & Safety
      • CERM® Risk Insights
      • Equipment Risk and Reliability in Downhole Applications
      • Operational Risk Process Safety
    • on Systems Thinking
      • Communicating with FINESSE
      • The RCA
    • on Tools & Techniques
      • Big Data & Analytics
      • Experimental Design for NPD
      • Innovative Thinking in Reliability and Durability
      • Inside and Beyond HALT
      • Inside FMEA
      • Integral Concepts
      • Learning from Failures
      • Progress in Field Reliability?
      • R for Engineering
      • Reliability Engineering Using Python
      • Reliability Reflections
      • Testing 1 2 3
      • The Manufacturing Academy
  • eBooks
  • Resources
    • Accendo Authors
    • FMEA Resources
    • Feed Forward Publications
    • Openings
    • Books
    • Webinars
    • Journals
    • Higher Education
    • Podcasts
  • Courses
    • 14 Ways to Acquire Reliability Engineering Knowledge
    • Reliability Analysis Methods online course
    • Measurement System Assessment
    • SPC-Process Capability Course
    • Design of Experiments
    • Foundations of RCM online course
    • Quality during Design Journey
    • Reliability Engineering Statistics
    • Quality Engineering Statistics
    • An Introduction to Reliability Engineering
    • Reliability Engineering for Heavy Industry
    • An Introduction to Quality Engineering
    • Process Capability Analysis course
    • Root Cause Analysis and the 8D Corrective Action Process course
    • Return on Investment online course
    • CRE Preparation Online Course
    • Quondam Courses
  • Webinars
    • Upcoming Live Events
  • Calendar
    • Call for Papers Listing
    • Upcoming Webinars
    • Webinar Calendar
  • Login
    • Member Home

by Carl S. Carlson 7 Comments

FMEA Q and A – System-Level Functions

FMEA Q and A – System-Level Functions

FMEA Q and A

In this question, a reader asks how to define system-level functions, and how they are different from subsystem and component functions.

“A prudent question is one-half of wisdom.”
Francis Bacon

Reader’s Question

How can you define a system level function? The DFMEA team tends to drill down functions to subsystem and component functions when we conduct system level DFMEA. It would be endless and low efficiency, and should be handled by subsystem/component DFMEA. So could you please share some of your experience regarding how to define system level functions, subsystem functions and component functions?

Answer to Reader’s Question

Staying within the boundaries of the analysis is important in order to avoid overly long FMEAs. This takes good preparation (FMEA block diagrams, etc.) and good facilitation. This concept can be demonstrated using excerpts from fictitious FMEAs on an All-Terrain Bicycle: System FMEA on entire bicycle, a subsystem Design FMEA on the handbrake subsystem and a component design FMEA on the brake cable.

The facilitator must keep the team focused on both the scope and the level of the analysis. The team can drill down by doing lower levels of analyses. Notice the functions have increasing detail as you move to lower levels of analysis.

The following definition of System FMEA will help to clarify the appropriate functions at the system level.

System FMEA is the highest-level analysis of an entire system, made up of various subsystems. The focus is on system-related deficiencies, including system safety, system integration, interfaces or interactions between subsystems or with other systems, interactions with the surrounding environment, human interaction, service and other issues that could cause the overall system not to work as intended. In a System FMEA, the focus is on functions and relationships that are unique to the system as a whole (i.e., do not exist at lower levels). The System level FMEA includes failure modes associated with interfaces and interactions in addition to considering single-point failures (where a single component failure can result in complete failure of the entire system). Some practitioners separate out human interaction and service into their own respective FMEAs.
An example from a fictitious bicycle System FMEA, hand brake Subsystem FMEA and brake cable Design FMEA will help to illustrate.

One function from the fictitious bicycle System FMEA:

The bicycle must provide safe and reliable transportation, including safe stopping distances and safe operation under all customer usage conditions as defined in the All-Terrain technical specification.

One function from the fictitious bicycle hand brake Subsystem FMEA:

Provides the correct level of friction between brake pad assembly and wheel rim to safely stop bicycle in the required distance, under all operating conditions.

One function from the fictitious bicycle brake cable Design FMEA:

Provides adjustable and calibrated movement between the brake lever and brake caliper, under specified conditions of use and operating environment.

Notice how the high-level system function is decomposed to subsystem function, and further decomposed to the component function.

System functions should be described at a high level, and be unique to the system as a whole (i.e., do not exist at lower levels), with the addition of system interaction and interface functions (including interfaces between subsystems).

All types of FMEA functions are thoroughly described, including examples and application information, in chapter 6 of my book Effective FMEAs.

Next article

Do you make this mistake when defining your failure modes? The FMEA Definitions and Concepts Series continues with, “Understanding FMEA Failure Modes: Essential Elements.” The article will provide theory and practical examples of defining failure modes, and highlight a mistake that some practitioners make.

 

Filed Under: Articles, Inside FMEA, on Tools & Techniques

About Carl S. Carlson

Carl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines, supporting over one hundred clients from a wide cross-section of industries. He has 35 years of experience in reliability testing, engineering, and management positions, including senior consultant with ReliaSoft Corporation, and senior manager for the Advanced Reliability Group at General Motors.

« Are We Teaching Reliability All Wrong?
12 Conference Best Practices »

Comments

  1. Chris Damon says

    April 30, 2020 at 2:45 AM

    Hi Carl,

    I enjoy reading your insights about FMEA, and would love to get your opinion on below query.

    Using your example of the bicycle system.

    For system level FMEA:
    a) Function (F1): Stop the bicycle safely whenever the brake is activated by user.
    b) Failure mode (FM1): Stopping distance exceeds requirement.
    c) Failure effect (FE1): User injury or accident.
    d) Failure cause (FC1): Insufficient friction between brake pad and disc.

    The FC1 could have been caused by multiple factors (wrong material, wrong calculation, wrong design etc.) which are covered under various sub-assembly FMEA. In this case, what should be the guideline for setting the occurrence rating for FC1?

    Thanks
    Chris

    Reply
    • Carl Carlson says

      April 30, 2020 at 6:36 AM

      Hi Chris,

      By definition, “Occurrence is a ranking number associated with the likelihood that the failure mode and its associated
      cause will be present in the item being analyzed. For System and Design FMEAs, the occurrence ranking
      considers the likelihood of occurrence during the design life of the product.”

      Therefore, in this fictitious example of the bicycle system FMEA, the occurrence is the likelihood that sometime during the design life of the bicycle, the bicycle will not achieve safe stopping distance due to insufficient friction between brake pad and wheel rim. The bicycle FMEA team would take into consideration past failure information, current prevention controls and the degree of change from previous bicycle designs in order to make the occurrence assessment.

      Let me know if this answers your question.

      Carl

      Reply
      • Chris says

        April 30, 2020 at 1:01 PM

        Hi Carl,

        Appreciate your reply.

        Would like to clarity with you that if “insufficient friction between brake pad and wheel rim” could be further drilled down into different causes such as:
        1. Poor selection of brake pad material – covered in brake pad FMEA.
        2. Poor finishing of wheel rim – covered in wheel rim FMEA.

        As you mention in this article, the focus of System FMEA is on functions and relationships that are unique to the system as a whole. So i am wondering when allocating Occurrence of “insufficient friction between brake pad and wheel rim” in the System FMEA, should #1 and #2 be considered as well since they have already been covered in lower level FMEA?

        Love to hear your thought.

        Thanks
        Chris

        Reply
        • Carl Carlson says

          May 1, 2020 at 1:59 AM

          Hi Chris,

          I’ll begin my reply by showing you a chart from my book. The chart is called “Failure Mode and Cause progression from system to subsystem to component.” You can access this chart from the following link:

          https://lucas-accendo-site-speed.sprod01.rmkr.net/wp-content/uploads/2019/06/FailureModeandCauseprogression.pdf

          Please note that the lower level FMEAs for Hand Brake and Brake Cable each take causes to deeper levels. The root causes in the example brake cable FMEA excerpt are “corrosion of cable wiring due to wrong material selected” and “fatigue cracks in cable wiring due to inadequate cable thickness.”

          The answer to your question about whether “insufficient friction between brake pad and wheel rim” could be further drilled down into different causes is “yes.” The chart that is linked to this answer shows how this works.

          The occurrence ranking for each FMEA is related to the specific failure mode / cause line in the same FMEA. Therefore the occurrence of a failure mode / cause in the system FMEA does not relate to the lower level causes, only the system failure mode / cause.

          Please let me know if this answers your question.

          Carl

          Reply
          • Chris says

            May 3, 2020 at 8:17 PM

            Hi Carl,

            That’s brilliant, thanks!

            Chris

  2. Sven Barlev says

    June 23, 2021 at 5:10 AM

    Hi Carl,

    Regarding recommended actions for system level failures; If the failure is mitigated on a component level, is it then sufficient to reference that on the system level? For instance with the bike example, would you have different mitigations for the cable breaking than on the cable (component) level?

    Your input on this would be very helpful.

    Sven

    Reply
    • Carl Carlson says

      June 25, 2021 at 1:33 PM

      Hi Sven,

      Thanks for your question.

      My answer includes a bit of caution. One of the objectives of a System FMEA is to include the interfaces, interactions and other system issues. Therefore, I would not assume the system will be fine merely because the lower level component is no longer an issue.

      For example, in chapter 8 of my book, I include practice FMEAs on a bicycle system, bicycle hand brake subsystem and bicycle brake cable. The bicycle system has a failure mode “Does not stop in required distance,” and a cause “Insufficient friction delivered by hand brake subsystem between brake pads and wheels.” This issue is only partially resolved at the component level when the bicycle brake cable is revised with a corrosion resistant material. Other system-level recommended actions include braking system analytical model to optimize hand brake operation, and modifying bicycle system testing to include all weather conditions.

      Hope that helps. Please let me know if you have any follow-up questions.

      Carl

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Articles by Carl Carlson
in the Inside FMEA series

[popup type="" link_text="Logo Info" ]

Information about FMEA Icon

Inside FMEA can be visually represented by a large tree, with roots, a solid trunk, branches, and leaves.

- The roots of the tree represent the philosophy and guiding principles for effective FMEAs.
- The solid trunk of the tree represents the fundamentals for all FMEAs.
- The branches represent the various FMEA applications.
- The leaves represent the valuable outcomes of FMEAs.
- This is intended to convey that each of the various FMEA applications have the same fundamentals and philosophical roots.

 

For example, the roots of the tree can represent following philosophy and guiding principles for effective FMEAs, such as:

1. Correct procedure         2. Lessons learned
3. Trained team                 4. Focus on prevention
5. Integrated with DFR    6. Skilled facilitation
7. Management support

The tree trunk represents the fundamentals of FMEA. All types of FMEA share common fundamentals, and these are essential to successful FMEA applications.

The tree branches can include the different types of FMEAs, including:

1. System FMEA         2. Design FMEA
3. Process FMEA        4. DRBFM
5. Hazard Analysis     6. RCM or Maintenance FMEA
7. Software FMEA      8. Other types of FMEA

The leaves of the tree branches represent individual FMEA projects, with a wide variety of FMEA scopes and results. [/popup]

Join Accendo

Receive information and updates about articles and many other resources offered by Accendo Reliability by becoming a member.

It’s free and only takes a minute.

Join Today

Recent Posts

  • test
  • test
  • test
  • Your Most Important Business Equation
  • Your Suppliers Can Be a Risk to Your Project

© 2025 FMS Reliability · Privacy Policy · Terms of Service · Cookies Policy