ECSS-Q-ST-30-02C: FMEA/FMECA

This section shows you how to use the Derisker ECSS library to build reliability analysis models in SysML v2. Derisker parses these models to extract failure modes, compute derived values, and generate analysis results.

The ECSS library implements the ECSS-Q-ST-30-02C standard for space systems. It provides SysML v2 elements for three analysis types:

Design FMECA: Extends FMEA with criticality ranking (severity × probability)
Design FMEA: Analyzes design failure modes with severity classification only
Process FMECA: Analyzes process failure modes with severity, probability, and detection ratings

Each workflow shows which library elements to use and how to structure your model.

Design FMECA Workflow

This workflow demonstrates the complete process using Design FMECA.

Prerequisites

ECSS library templates available in your workspace
Syside Modeler installed
Derisker extension enabled

Step 1: Set Up Project Files

Copy the ECSS template files to your project directory:

models/myproject/
├── MySystem_Design.sysml           # (from Derisker_ECSS_TemplateDFMECA_Design.sysml)
├── MySystem_DesignFMECA.sysml      # (from Derisker_ECSS_TemplateDFMECA.sysml)
└── MySystem_Customizations.sysml   # (from Derisker_ECSS_TemplateCustomizations.sysml)

Each file imports the base ECSS library:

private import Derisker_ECSS::ReliabilityAnalyses::*;

Step 2: Model System Architecture

Define your system hierarchy using ECSS library elements. See ECSS-Q-ST-30-02C: FMEA/FMECA Quick Reference for full element list.

Example Structure

package MySystem_Design {
    private import Derisker_ECSS::SystemAnalyses::*;

    part def DesignContext {
        part mySystem : TopLevelSystem {
            action systemFunction : Function;

            part powerSubsystem : Subsystem {
                action providePower : Function;

                part battery : Component {
                    attribute redefines referenceDesignator = "BAT1";
                    action storePower : Function;
                }
            }
        }
    }
}

Key Points:

Define at least one function for each element
Use clear, descriptive names for parts and functions
Set referenceDesignator attributes for components

Step 3: Configure Analysis Worksheet

In your DesignFMECA file, configure the project metadata and define compensating provisions.

Cover Sheet Metadata

part redefines coverSheet {
    attribute :>> fmeaTitle = "MySystem Hardware FMECA";
    attribute :>> fmeaRefNo = "FMECA-001";
    attribute :>> companyName = "Your Company";
    attribute :>> customerName = "Customer Name";
    attribute :>> fmeaStartDate.date = "2026-01-15";
    attribute :>> crossFunctionalTeam = "Systems, Reliability, Design";
    attribute :>> approvalAuthority = "Chief Engineer";
    attribute :>> confidentialityLevel = ConfidentialityLevels::BusinessUse;
}

Compensating Provisions

Define mitigation actions that failure modes can reference:

part redefines compensatingProvisions {
    action CP_Redundancy : CompensatingProvision {
        attribute redefines description = "Redundant unit provides backup";
    }
    action CP_Monitoring : CompensatingProvision {
        attribute redefines description = "Telemetry monitoring with ground intervention";
    }
}

Step 4: Define Failure Modes

Organize failure modes hierarchically by system level. Each failure mode follows this structure:

occurrence <Name> subsets FailureModeInitial {
    ref part :>> focusItem = <reference to system element>;
    ref action :>> focusFunction = <reference to function>;
    attribute :>> origin = FailureModeOrigins::<FromIntegration or Additional>;
    attribute :>> description = "<failure mode description>";
    // ... additional attributes
}

Hierarchical Organization

Top-Level System Failures (FromIntegration):

Represent mission/system-level failures
Caused by subsystem failures via #causation links
Assign rating_Severity_TOP

Subsystem Failures (FromIntegration or Additional):

Link to component failures (if FromIntegration) or are root causes (if Additional)
Provide both local and top-level effects

Component Failures (Additional):

Typically root causes (no lower-level causes)
MUST set rating_Probability and rating_Probability_Comments

Example Pattern

part 'FMs: Battery' {
    alias SOI for DesignContext::mySystem::powerSubsystem::battery;

    occurrence Battery_OpenCircuit_FM subsets FailureModeInitial {
        ref part :>> focusItem = SOI;
        ref action :>> focusFunction = SOI.storePower;

        attribute :>> origin = FailureModeOrigins::Additional;
        attribute :>> description = "Internal open circuit in battery cell";

        attribute :>> failureCauses_Comments =
            "Manufacturing defect, internal electrode breakage, wear-out";
        attribute :>> failureEffects_Local_Comments =
            "Battery cannot provide current";
        attribute :>> failureEffects_TOP_Comments =
            "Loss of stored energy, system power loss";

        attribute :>> rating_Probability = Probability::PN2_Remote;
        attribute :>> rating_Probability_Comments =
            "Based on MIL-HDBK-217F, battery failure rate 10^-5/hour";

        ref action :>> recommendations = compensatingProvisions::CP_Redundancy;
    }
}

Required Attributes by Origin

Attribute	FromIntegration	Additional
`focusItem`	Required	Required
`focusFunction`	Required	Required
`description`	Required	Required
`#causation` links	Required (to lower-level FMs)	Not applicable
`rating_Severity_TOP`	Top-level only	Auto-computed
`rating_Probability`	Auto-computed	Required
`rating_Probability_Comments`	Not required	Required
`failureEffects_Local_Comments`	Subsystem/Component	Subsystem/Component
`failureEffects_TOP_Comments`	All	All

Step 5: Assign Ratings

Use ECSS library enumerations for ratings. See ECSS-Q-ST-30-02C: FMEA/FMECA Quick Reference for full rating tables and criteria.

Severity Example

attribute :>> rating_Severity_TOP = Severity::Catastrophic_1_SP;

Suffix meanings:

_SP: Single-Point failure
_R: Redundant
_SH_SP or _SH_R: Safety Hazard variants

Probability Example

attribute :>> rating_Probability = Probability::PN2_Remote;
attribute :>> rating_Probability_Comments =
    "Based on MIL-HDBK-217F Part Stress method: λ = 2.3E-6 failures/hour";

Automatic Calculations

Derisker computes automatically:

Severity propagation: Top-down from effects (highest severity flows to causes)
Probability aggregation: Bottom-up from causes (probabilities combine upward)
Criticality Number: CN = SN × PN
Criticality Category: Critical if SN=4 OR CN ≥ 6

Step 6: Parse and Review

Open Derisker panel (click  in left sidebar)

Enter analysis root qualified name, e.g.

MySystem_DesignFMECA::AnalysisContext::AnalysisProject

Enter physical architecture root, e.g.

MySystem_Design::DesignContext::mySystem

Click Parse Failure Modes

Derisker validates your model, extracts failure modes, computes derived values, and opens table view with results.

See Features for detailed instructions on parsing, table view, and graph view features.

Step 7: Refine and Iterate

Review results in table view - sort by criticality, edit text fields
Visualize failure chains with graph view
Edit in table view OR navigate to source and edit SysML
Re-parse to update computed values
Repeat until analysis is complete

The workflow is iterative - leverage bidirectional sync between SysML and Derisker table view.

Step 8: Export Results

Export to CSV:

Click Export to CSV in table view
File contains all failure modes with column headers

Export graph to image:

Open graph view, click Export
Select format (PNG or JPEG)

See Features for detailed export options.

Design FMEA Workflow

Design FMEA is a qualitative variant without probability ratings.

Key Differences from Design FMECA

Template File:

Use Derisker_ECSS_TemplateDFMEA.sysml (and Derisker_ECSS_TemplateDFMEA_Design.sysml) instead of the DesignFMECA templates.

No Probability Ratings:

rating_Probability is automatically set to 'Not Applicable'
Do not set rating_Probability_Comments

Criticality Logic:

Critical if:

Severity is Catastrophic (SN=4), OR
Single-Point failure (isSinglePoint == true)

When to Use:

Early design phases before reliability data is available
Qualitative risk assessment focus

All other steps (architecture modeling, failure mode definition, parsing, review) remain the same as Design FMECA workflow.

Process FMECA Workflow

Process FMECA analyzes manufacturing and operational processes.

Key Differences from Design FMECA

Different Library Elements

Use process-specific elements instead of system elements:

Design Element	Process Element	Purpose
`TopLevelSystem`	`TopLevelProcess`	Overall process
`Subsystem`	`ProcessStation`	Process area/station
`Component`	`ProcessStep`	Individual operation

Example Structure

part vehicleAssembly : TopLevelProcess {
    part bodyShop : ProcessStation {
        part welding : ProcessStep {
            action weldPanels : Function;
        }
    }
}

Additional Rating: Detection

Process FMECA includes Detection ratings (DN). See ECSS-Q-ST-30-02C: FMEA/FMECA Quick Reference for criteria.

All failure modes must have rating_Detection and rating_Detection_Comments.

Criticality Calculation

Criticality Number: CN = SN × PN × DN (range 1-64)

Critical if: SN ≥ 3, OR PN = 4, OR DN = 4, OR CN ≥ 12

Different Failure Effects

Process FMECA does not use hierarchical effects (Local vs TOP). Instead, describe effects in terms of Safety, Product, Process, and Programmatic impacts.

Document in failureEffects_TOP_Comments. The failureEffects_Local_Comments field is not used for Process FMECA.

Best Practices

Naming Conventions:

Failure modes: <Item>_<Function>_FM<Number>
Parts grouping: 'FMs: <ItemName>'
Use descriptive, consistent names throughout

Top-Down Hierarchical Modelling:

Define top-level system failures first
Work down to subsystem level
Finally add component-level root causes

Frequent Parsing:

Parse after each hierarchy level
Catch errors early (missing links, incorrect types)
Verify computed values match expectations

Always Link FromIntegration Failures:

#causation connection : CausalLinkDef
    connect 'FMs: Component'::Component_FM to this;

Verify Visually:

Use graph view to verify all FromIntegration failures have causes and check that causal chains make physical sense. Avoid cycles - Derisker detects and reports these.

ECSS-Q-ST-30-02C: HSIA

Hardware-Software Interaction Analysis (HSIA) is a critical supplement to FMEA/FMECA for systems with software control, per ECSS-Q-ST-30-02C Annex I.

HSIA identifies risks from software-hardware interactions that may not be apparent in standard hardware FMEA/FMECA.

Prerequisites

Completed Design FMEA or Design FMECA (see ECSS-Q-ST-30-02C: FMEA/FMECA)
System with software control elements (e.g., state management, avionics, autonomous systems)
Hardware failure modes documented in SysML v2 model

When to Use

HSIA applies to systems where software can:

Detect hardware failures - Software monitors sensors/telemetry
Respond to mitigate effects - Software can take compensating actions
Worsen hardware failures - Incorrect software actions could aggravate failures

Examples: Flight management units, spacecraft avionics, drone flight controllers, autonomous vehicle systems, safety-critical embedded systems.

Workflow

Step 1: Identify Software-Controlled Systems

Review your Design FMEA/FMECA and identify hardware failure modes where:

Software receives telemetry or sensor data about the hardware state
Software controls hardware operation or has recovery capabilities
Software actions could potentially affect hardware behavior

Step 2: Answer HSIA Questions

For each hardware failure mode identified in Step 1, answer these questions:

Detection: Does software receive information about the failure?
Action capability: Can software take action to mitigate effects?
Adverse effects: Can software actions worsen the failure?
Trigger parameters: What specific parameters trigger software detection?
Software actions: What actions does software take in response?
Requirements: Which software requirements govern the response?
Observability: Is telemetry provided for ground/crew intervention?
Timing: Is response time adequate for mission success?

Step 3: Document HSIA Attributes

Add HSIA attributes to each hardware failure mode in your SysML v2 model:

occurrence Battery_OpenCircuit_FM subsets FailureModeInitial {
    // ... existing failure mode attributes ...

    // HSIA Extension
    attribute :>> software_Trigger_Params =
        "Battery voltage < 10V for 100ms, current sensor reads zero";
    attribute :>> software_Actions =
        "Switch to backup battery, reduce power consumption mode, "
        "send telemetry alert to ground station";
    attribute :>> software_Requirements =
        "REQ-SW-123: Battery health monitoring; "
        "REQ-SW-124: Automatic failover to backup power";
    attribute :>> effect_On_Hardware =
        "Beneficial: Preserves primary battery, extends mission duration. "
        "Adverse: Backup battery drains, potential delay in recovery";
    attribute :>> recommendations_HSIA =
        "Verify backup battery capacity sufficient for mission duration. "
        "Add automated test of failover logic during pre-flight checks";
}

HSIA Attribute Descriptions

Attribute	Purpose
`software_Trigger_Params`	What parameters/sensors trigger software detection of the failure?
`software_Actions`	What actions does software take in response to the failure?
`software_Requirements`	Which software requirements govern detection and response?
`effect_On_Hardware`	How does software affect hardware (both beneficial and adverse effects)?
`recommendations_HSIA`	HSIA-specific recommendations for software-hardware interaction improvements

Step 4: Re-Parse with Derisker

After adding HSIA attributes to your failure modes:

Open Derisker panel (click :nerdfont:`` in left sidebar)
Re-parse your analysis (same qualified names as original FMEA/FMECA)
HSIA attributes appear as additional columns in table view

Step 5: Review Hardware-Software Interactions

Use Derisker’s table view to review HSIA data:

Identify critical interactions: Sort by severity to find high-risk software-hardware interactions
Verify coverage: Ensure all software-controlled failure modes have HSIA data
Check adverse effects: Review effect_On_Hardware for unintended consequences
Validate requirements: Cross-reference software_Requirements with software specifications

Key review questions:

Are software response times adequate for all critical failures?
Are there failure modes where software could worsen the situation?
Is telemetry sufficient for ground operators to intervene?
Are software requirements complete and testable?

Best Practices

Early Integration:

Perform HSIA early in software development to influence architecture
Update HSIA as software design evolves
Include HSIA in design reviews

Cross-Functional Analysis:

Involve both hardware and software engineers
Include software safety/reliability experts
Review with operators/mission planners

Documentation:

Link HSIA attributes to software requirements documents
Reference software test procedures in recommendations
Document timing constraints explicitly

Testing and Verification:

Create test cases based on HSIA scenarios
Verify software detection thresholds match hardware failure signatures
Test failover/recovery actions under realistic conditions

Customizing the ECSS Library

The ECSS library can be extended to meet project-specific requirements while maintaining compatibility with the ECSS-Q-ST-30-02C standard.

When to Customize

Customize the ECSS library when you need to:

Add project-specific failure mode types - Beyond standard ECSS categories
Add domain-specific attributes - Industry-specific data fields (automotive, aerospace, medical)
Tailor severity/probability criteria - Organization-specific rating definitions
Add custom enumerations - Project-specific classification schemes

Note

The ECSS standard allows tailoring per Section 1.3. Document all customizations in your FMEA cover sheet by setting fmeaDefsCustom = true.

Customization Workflow

Step 1: Copy Template Customization File

Start from the ECSS template:

models/myproject/
├── MySystem_Design.sysml
├── MySystem_DesignFMECA.sysml
└── MySystem_Customizations.sysml    ← Copy from Derisker_ECSS_TemplateCustomizations.sysml

Step 2: Define Custom Failure Mode Types

Extend the FailureModeTypes enumeration:

package MySystem_Customizations {
    private import Derisker_ECSS::InternalDefs::FailureMode;

    // Define custom failure mode types
    enum def FailureModeTypes {
        // Standard ECSS types
        enum SuddenLossOfFunction;
        enum PartialFunction;
        enum IntermittentFunction;
        enum DegradedFunction;

        // Custom types for your project
        enum StuckOpen;
        enum StuckClosed;
        enum Oscillation;
        enum DelayedResponse;
        enum TBD;
    }
}

Common custom types by domain:

Aerospace: UncontrolledMotion, LeakageExternal, StructuralFailure
Automotive: UnintendedAcceleration, LossOfBraking, SteeringLockup
Medical devices: IncorrectDosage, SterilityBreach, PowerInterruption

Step 3: Extend Failure Mode Definition

Add custom attributes to FailureModeExtension:

occurrence def FailureModeExtension specializes FailureMode {
    // Standard failure mode type
    attribute failureModeType : FailureModeTypes default FailureModeTypes::TBD;

    // Custom attributes for your project
    attribute testVerificationMethod : String default "" {
        doc /* How will this failure mode be tested/verified? */
    }
    attribute safetyClassification : SafetyClass default SafetyClass::TBD {
        doc /* Safety classification per project safety plan */
    }
    attribute costImpact : Real default 0.0 {
        doc /* Estimated cost impact of failure (currency units) */
    }

    // Add any other project-specific attributes
}

// Custom enumeration for safety classification
enum def SafetyClass {
    enum SafetyCritical;
    enum MissionCritical;
    enum PerformanceDegrading;
    enum Nuisance;
    enum TBD;
}

Step 4: Use Custom Extension in Analysis

Reference your FailureModeExtension in the analysis worksheet:

package MySystem_DesignFMECA {
    private import Derisker_ECSS::ReliabilityAnalyses::*;
    private import MySystem_Customizations::*;

    part def AnalysisContext {
        part AnalysisProject subsets ECSS_ProjectTypes::DesignFMECA {
            // Merge your extension with the standard ECSS failure mode
            occurrence FailureModeInitial : FailureModeExtension subsets ECSS_FailureMode;

            part redefines coverSheet {
                // Indicate custom definitions are used
                attribute :>> fmeaDefsCustom = true;
            }

            part redefines workSheet {
                // Use FailureModeInitial with your custom attributes
                occurrence MyFailure_FM subsets FailureModeInitial {
                    attribute :>> failureModeType = FailureModeTypes::StuckOpen;
                    attribute :>> safetyClassification = SafetyClass::SafetyCritical;
                    attribute :>> testVerificationMethod =
                        "Hardware-in-loop testing, fault injection";
                    // ... other failure mode attributes
                }
            }
        }
    }
}

Step 5: Parse and Verify

Parse your customized model with Derisker
Verify custom attributes appear as columns in table view
Export to CSV to see all custom fields

Advanced Customization Examples

Custom Severity Criteria

Tailor severity definitions for your organization:

enum def CustomSeverity specializes SeverityDef {
    SN4_ProgramCancellation {
        doc /* Catastrophic - leads to program cancellation */
        attribute redefines severityNumber = 4;
    }
    SN3_MajorRework {
        doc /* Critical - requires major design rework */
        attribute redefines severityNumber = 3;
    }
    SN2_MinorRework {
        doc /* Major - requires minor design changes */
        attribute redefines severityNumber = 2;
    }
    SN1_Acceptable {
        doc /* Minor - acceptable risk */
        attribute redefines severityNumber = 1;
    }
}

Domain-Specific Attributes

Automotive example:

occurrence def AutomotiveFMExtension specializes FailureMode {
    attribute asilLevel : ASILLevel default ASILLevel::QM {
        doc /* ASIL level per ISO 26262 */
    }
    attribute diagnosticCoverage : Real default 0.0 {
        doc /* Diagnostic coverage percentage */
    }
}

enum def ASILLevel {
    enum ASIL_D;  // Highest
    enum ASIL_C;
    enum ASIL_B;
    enum ASIL_A;
    enum QM;      // Quality Management (no ASIL)
}

Medical device example:

occurrence def MedicalFMExtension specializes FailureMode {
    attribute hazardSeverity : IEC60601Severity {
        doc /* Severity per IEC 60601-1 */
    }
    attribute riskControlMeasures : String default "" {
        doc /* Risk control measures per ISO 14971 */
    }
}

enum def IEC60601Severity {
    enum Death;
    enum SeriousInjury;
    enum InjuryRequiringIntervention;
    enum Inconvenience;
    enum Negligible;
}

Best Practices

Documentation:

Document all customizations in your FMEA cover sheet comments
Set fmeaDefsCustom = true to indicate tailoring
Link to standards - reference which standard you’re tailoring from

Consistency:

Use consistent naming conventions for custom attributes
Align custom types with your organization’s taxonomy
Review customizations with stakeholders before implementation

Compatibility:

Don’t remove standard ECSS attributes - only add new ones
Extend, don’t replace - use specializes to build on standard definitions

Version Control:

Keep customization file under version control
Tag versions when customizations change
Document breaking changes

ECSS-Q-ST-30-02C: FMEA/FMECA

Design FMECA Workflow

Prerequisites

Step 1: Set Up Project Files

Step 2: Model System Architecture

Example Structure

Step 3: Configure Analysis Worksheet

Cover Sheet Metadata

Compensating Provisions

Step 4: Define Failure Modes

Hierarchical Organization

Example Pattern

Required Attributes by Origin

Step 5: Assign Ratings

Severity Example

Probability Example

Automatic Calculations

Step 6: Parse and Review

Step 7: Refine and Iterate

Step 8: Export Results

Design FMEA Workflow

Key Differences from Design FMECA

Process FMECA Workflow

Key Differences from Design FMECA

Different Library Elements

Example Structure

Additional Rating: Detection

Criticality Calculation

Different Failure Effects

Best Practices

ECSS-Q-ST-30-02C: HSIA

Prerequisites

When to Use

Workflow

Step 1: Identify Software-Controlled Systems

Step 2: Answer HSIA Questions

Step 3: Document HSIA Attributes

HSIA Attribute Descriptions

Step 4: Re-Parse with Derisker

Step 5: Review Hardware-Software Interactions

Best Practices

Customizing the ECSS Library

When to Customize

Customization Workflow

Step 1: Copy Template Customization File

Step 2: Define Custom Failure Mode Types

Step 3: Extend Failure Mode Definition

Step 4: Use Custom Extension in Analysis

Step 5: Parse and Verify

Advanced Customization Examples

Custom Severity Criteria

Domain-Specific Attributes

Best Practices

Feedback

Legal

Company