IEC 60812

The IEC 60812 standard provides guidelines for performing Failure Modes and Effects Analysis (FMEA) in a structured and systematic way. It defines the essential elements of a proper FMEA process, including the identification of failure modes, their causes and effects, associated risks, and the planning of actions to reduce those risks.

Although Truke KF implements a simplified 4-column FMEA format, it retains the core structure and functionality required by IEC 60812, making it fully compatible in principle and purpose. Here's how each aspect is addressed:

Identification of the Item Under Analysis

IEC 60812 requires a clear definition of the item being analyzed. In KF, this is directly represented in the "Item" column, which links to a structured object in the knowledge base. These items can be part of a product hierarchy or system architecture, fulfilling the standard's requirement for traceability and context.

Failure Modes, Effects, and Causes

KF groups failure modes, their effects, and causes vertically under the "Failures" column. This preserves the causal chain explicitly, even if it doesn’t separate them into distinct columns. This format makes the logic easy to follow while avoiding redundancy. It is compliant with the standard as long as the causal relationships are clearly documented, which they are.

The "Actions" column covers the recommendations or measures taken to eliminate or mitigate causes or effects. KF supports tracking the implementation status (pending, done, not applicable), aligning with the process-oriented nature of IEC 60812, which emphasizes not just identification but also response and follow-up.

Risk Evaluation

KF calculates risk based on impact (severity) and probability, two of the three classical FMEA factors (the third being detection). IEC 60812 acknowledges that different risk evaluation methods may be used, and explicitly allows for customization based on context or industry practice. The risk matrix in KF allows for prioritization in line with the standard’s risk-based thinking.

Conclusion

KF’s approach to FMEA is lean and purpose-driven, eliminating bureaucratic overhead while keeping the essential logic of IEC 60812 intact. By focusing on the core analytical relationships — item, failure, cause/effect, action, and risk — it enables teams to comply with the spirit and structure of the standard, while integrating failure analysis seamlessly into the broader process of knowledge capture and reuse.

  • --

IEC 60812 is an international standard that provides guidelines for conducting Failure Modes and Effects Analysis (FMEA) and its variant, Failure Modes, Effects, and Criticality Analysis (FMECA). This standard is applicable to various life cycle stages involving hardware, software, processes, and human interactions, either individually or in combination. It emphasizes the importance of planning, performing, documenting, and maintaining FMEA to enhance dependability and support decision-making regarding risk treatments.

Significant updates in the 2018 edition include:

  • Generic Normative Text: The standard now covers all applications, making it more universally applicable.
  • Informative Annexes: Added examples for safety, automotive, software, and service processes to illustrate FMEA applications in various contexts.
  • Tailoring Guidance: Instructions on customizing FMEA for different applications to ensure relevance and effectiveness.
  • Reporting Formats: Descriptions of various reporting formats, including database information systems, to facilitate proper documentation.
  • Risk Priority Number (RPN) Calculations: Introduction of alternative methods for calculating RPNs to prioritize failure modes effectively.
  • Criticality Matrix Method: Inclusion of a matrix-based method for assessing criticality, aiding in the evaluation of failure consequences.
  • Relationship to Other Methods: Clarification of how FMEA relates to other dependability analysis methods, promoting integrated risk assessment approaches.

These enhancements aim to provide a more comprehensive and flexible framework for implementing FMEA across various industries and applications.

To ensure an effective Failure Modes and Effects Analysis (FMEA), the analysis must fulfill several key requirements. These requirements align with the guidelines set by IEC 60812:2018 and industry best practices:

Clear Objective Definition

- Purpose: Define the goal of the FMEA clearly (e.g., enhancing reliability, improving safety, reducing downtime). - Scope: Specify the boundaries of the analysis, including the system, subsystems, or processes under review.

Comprehensive Identification of Failure Modes

- Identify all potential failure modes for each element, function, or process step within the defined scope. - Consider hardware, software, human factors, and environmental influences.

3. Thorough Effects Analysis

- Assess the local, system-level, and end-user effects of each failure mode. - Consider effects on functionality, safety, regulatory compliance, and customer satisfaction.

4. Cause and Mechanism Identification

- Identify root causes and mechanisms for each failure mode to facilitate effective mitigation. - Include contributing factors, such as design flaws, material defects, or operational errors.

5. Risk Assessment

  • Evaluate each failure mode's risk using metrics such as:
    • Severity: The impact of the failure.
    • Occurrence (Likelihood): The probability of the failure occurring.
    • Detection: The likelihood of detecting the failure before it impacts the system.
  • Use tools like Risk Priority Numbers (RPN) or a criticality matrix.

- Propose risk mitigation measures for significant failure modes. - Actions may include design changes, process adjustments, or enhanced maintenance practices.

7. Traceability and Documentation

- Maintain thorough documentation, including: - Analysis assumptions. - Identified failure modes and effects. - Risk assessments and recommendations. - Use structured reporting formats, such as tables or database systems.

  • --

8. Team Collaboration

- Conduct the analysis with a multidisciplinary team to incorporate diverse expertise and perspectives.

  • --

9. Iterative Process

- Update the FMEA as the system evolves (e.g., design changes, new operational insights, or process updates).

  • --

10. Customization and Adaptability

- Tailor the FMEA process to suit the application (e.g., automotive, software, service industry) while maintaining compliance with IEC 60812.

  • --

11. Integration with Other Methods

- Align the FMEA with other reliability and risk assessment tools (e.g., Fault Tree Analysis, Root Cause Analysis) for a comprehensive dependability study.

  • --

These requirements help ensure that the FMEA effectively identifies and mitigates risks, contributing to the reliability, safety, and overall dependability of the system or process under analysis.

Risk vs criticality

Both are tools to achieve the same end: identifying and mitigating potential issues, but they differ in how they weigh "how bad it is" versus "how often it happens." This difference becomes crucial when the stakes are high, as in safety-critical industries.

KF merges C and D

1. Modeling Detection as an Action

  • Create a “Detection” action for each safety-relevant event (for instance, “Sensor monitors brake pressure”).
  • Give that action its own O (or D, if you prefer) rating to represent the probability that this detection measure will actually catch the fault before it causes harm.
  • Link the action to the event just as you would any preventive or corrective action.
  • KF’s FMEA table then shows the event → its causes/effects → linked actions → overall risk, but the detectability sits squarely in the action row, not as a mysterious field on the event.

2. Why This Works Better in KF

  • Separation of concerns: The event stays focused on “what can go wrong,” while the detection action describes “how we’ll catch it.”
  • Flexible attributes: You can choose to reuse the O field as “detection probability” if you’d rather not introduce a separate D field at all.
  • Clear lineage: Every detection action carries its own status (pending, done, N/A) and can even inherit checklists from previous similar events—so you build a library of proven detection measures over time.

3. Impact on ASIL and Risk Calculations

  • When an event is marked ISO 26262–relevant, KF still uses S, E, and C (controllability) for ASIL determination.
  • The linked detection action’s rating doesn’t feed into the ASIL matrix, but it does influence the post-action residual risk of the event if you choose to incorporate it into your Impact×Probability calculation.
  • In practice, you can model your safety chain as:

1. Event: “Brake fluid leak” (S/E/C → ASIL B) 2. Detection action: “Fluid-level sensor” (O or D → 70% chance to detect) 3. Mitigation action: “Automatic limp-home mode” (updates C or S)

4. When True D vs. An Action Matters

Separating detection into its own action becomes crucial if:

  • Detection and control are handled by different subsystems (e.g. a software diagnostic vs. a hardware fail-safe).
  • You need to track the effectiveness of multiple independent detection layers (sensor A vs. sensor B).
  • Regulators or auditors ask for explicit proof of detectability measures, with their own statuses and follow-up tasks.
  • --

In summary, by turning D into a first-class “detection” action rather than a built-in event attribute, KF lets you keep your FMEAs both lean and semantically precise—and still deliver everything you need for ISO 26262 compliance.



/products/kf/norm/iec60812