ECSS DFMECA: Drone Hardware

This example demonstrates hardware reliability analysis for a BVLOS (Beyond Visual Line of Sight) FPV (First Person View) quadcopter drone using the ECSS library. The model performs component-level Design FMECA with circuit-level detail including real ICs, reference designators, and Hardware-Software Interaction Analysis.

Tip

This example models actual hardware components (LTC4368, TMP100, MOSFETs, resistors) with PCB reference designators, making it suitable for electrical engineering teams performing board-level reliability analysis.

Model Structure

The example consists of four SysML v2 model files:

• Drone_PhysArch.sysml - Physical hardware architecture

• Drone_RefCircuits.sysml - Reusable circuit definitions

• Drone_HwFMECA.sysml - Complete FMECA analysis

• HwFmecaCustomizations.sysml - Project-specific extensions

Hardware Architecture

System Architecture

The drone follows a three-tier hierarchy: TopLevelSystem → Subsystem → Component.

System hierarchy structure

part def DroneDesign {
    part drone : TopLevelSystem {
        action <F1> performFlight subsets functions {
            attribute redefines description default "Perform BVLOS FPV flight mission";
        }

        part drone_MB : Subsystem {
            action <F1> assembleSubsystems subsets functions {
                attribute redefines description default
                    "Assemble drone's power, flight control, TTC, payload subsystems.";
            }

            part power : Subsystem {
                action <F1> distributePower subsets functions;
                action <F2> protectBatteries subsets functions;
                action <F3> measureTLM subsets functions;

                // Circuit components defined here
            }

            part flightControl : Subsystem { /* ... */ }
            part ttc : Subsystem { /* ... */ }
            part payload : Subsystem { /* ... */ }
        }
    }
}

Each subsystem defines functions that must be subsets of the parent’s functions collection, establishing clear functional hierarchy.

Circuit Abstraction Pattern

The model uses abstract part definitions for circuits that appear multiple times, then instantiates them with specific reference designators.

Abstract circuit definition

part power : Subsystem {
    // Define abstract circuit that will be instantiated twice
    abstract part batterySwitches : 'Protection Switch CKT - LTC4368' [2] {
        doc
        /* Generalized superset of 2 Battery protection switches */

        action redefines protectRail {
            attribute redefines description default
                "Provide UV/OV/OC/reverse protection for single battery pack";
        }
    }

    // First instance with specific reference designators
    part batterySwitch_BP1 subsets batterySwitches {
        doc
        /* Battery protection switch - Battery Pack 1 */

        action redefines protectRail {
            attribute redefines description =
                "Provide UV/OV/OC/reverse protection for battery pack 1";
        }

        part redefines 'Gate Controller IC' {
            attribute redefines refDes = "U1";
        }
        part redefines 'MOSFET Transistor' {
            attribute redefines refDes = ("Q1", "Q3");
        }
        part redefines 'Switch Current Sense Resistor' {
            attribute redefines refDes = "R7";
        }
        part redefines 'OV voltage divider' {
            attribute redefines refDes = ("R13", "R14");
        }
        part redefines 'UV voltage divider' {
            attribute redefines refDes = ("R1", "R2");
        }
    }

    // Second instance with different reference designators
    part batterySwitch_BP2 subsets batterySwitches {
        part redefines 'Gate Controller IC' {
            attribute redefines refDes = "U2";
        }
        // ... different ref designators for Q2, Q4, R8, etc.
    }
}

This pattern avoids duplicating circuit definitions while maintaining traceability to physical PCB components.

Reference Designators

Each component part references its physical PCB designator for schematic correlation.

Reference designator mapping

part batterySwitch_BP1 subsets batterySwitches {
    part redefines 'Gate Controller IC' {
        attribute redefines refDes = "U1";  // Maps to U1 on schematic
    }
    part redefines 'MOSFET Transistor' {
        attribute redefines refDes = ("Q1", "Q3");  // Two transistors
    }
    part redefines 'Switch Current Sense Resistor' {
        attribute redefines refDes = "R7";
    }
    part redefines 'nFAULT current limiter resistor' {
        attribute redefines refDes = "R9";
    }
    part redefines 'Bypass capacitor' {
        attribute redefines refDes = "C1";
    }
}

This enables direct lookup from SysML model to hardware schematics and bill of materials.

FMECA Analysis

FMECA Structure

Failure modes are organized by hierarchy level with clear naming and grouping.

Failure mode organization

part AnalysisProject subsets ECSS_ProjectTypes::DesignFMECA {
    part redefines workSheet {
        // Group failure modes by subsystem
        part 'FMs: Power' {
            alias SOI for DroneDesign::drone::drone_MB::power;

            occurrence Power_F2_FM1 subsets FailureModeInitial {
                ref part :>> focusItem = SOI;
                ref action :>> focusFunction = SOI.protectBatteries;

                attribute :>> origin = FailureModeOrigins::Additional;
                attribute :>> failureModeType = FailureModeTypes::SuddenLossOfFunction;
                attribute :>> description =
                    "Battery protection circuit fails to detect overvoltage condition";

                attribute :>> failureCauses_Comments =
                    "LTC4368 gate controller failure, voltage divider resistor drift";
                attribute :>> failureEffects_Local_Comments =
                    "Battery overvoltage not detected, potential battery damage";
                attribute :>> failureEffects_TOP_Comments =
                    "Possible thermal runaway, fire hazard";

                attribute :>> rating_Severity_TOP = Severity::Critical_2_SP;
                attribute :>> rating_Probability = Probability::PN2_Remote;

                attribute :>> detection_ObservableSymptoms =
                    "Battery voltage exceeds safe limits; thermal sensors show temperature rise";
                attribute :>> detection_ExistingMethods =
                    "Redundant voltage monitoring; thermal cutoff; battery management system";
            }
        }

        part 'FMs: FlightControl' {
            alias SOI for DroneDesign::drone::drone_MB::flightControl;
            // Flight control failure modes here
        }
    }
}

Key patterns:

• Part grouping: part 'FMs: Power' contains all power subsystem failure modes

• SOI alias: alias SOI for DroneDesign::drone::drone_MB::power simplifies references

• Naming: Power_F2_FM1 = Subsystem_FunctionNumber_FailureModeNumber

Causal Links

Causal links connect component failures to subsystem and system-level failures.

Failure propagation through causal links

// Component-level failure mode
occurrence GateController_U1_FM1 subsets FailureModeInitial {
    ref part :>> focusItem = /* ... U1 component ... */;
    attribute :>> description = "LTC4368 gate controller IC fails";
    attribute :>> origin = FailureModeOrigins::Additional;
}

// Subsystem-level failure caused by component failure
occurrence Power_F2_FM1 subsets FailureModeInitial {
    ref part :>> focusItem = SOI_Power;
    attribute :>> description =
        "Battery protection circuit fails to detect overvoltage";

    // Link to component-level cause
    #causation connection : CausalLinkDef connect
        'FMs: BatterySwitch_BP1'::GateController_U1_FM1 to this;

    attribute :>> failureCauses_Comments =
        "Gate controller U1 failure propagates to protection function";
}

// System-level failure caused by subsystem failure
occurrence Drone_F1_FM3 subsets FailureModeInitial {
    ref part :>> focusItem = SOI_TopLevel;
    attribute :>> description = "Drone mission aborted due to battery hazard";

    // Link to subsystem-level cause
    #causation connection : CausalLinkDef connect
        'FMs: Power'::Power_F2_FM1 to this;

    attribute :>> failureCauses_Comments =
        "Power subsystem protection failure requires immediate landing";
}

The #causation connection syntax creates directed links from lower-level failures to higher-level effects, enabling Derisker to visualize complete failure chains.

Hardware-Software Interaction Analysis (HSIA)

FMECA includes HSIA fields analyzing how software responds to hardware failures.

HSIA fields example

occurrence FlightController_MCU_FM2 subsets FailureModeInitial {
    ref part :>> focusItem = /* flight control MCU */;
    attribute :>> description = "Flight controller MCU degraded performance";

    attribute :>> failureCauses_Comments =
        "MCU thermal throttling, voltage droop, clock instability";
    attribute :>> failureEffects_Local_Comments =
        "Reduced control loop frequency, delayed sensor processing";

    // Standard FMECA ratings
    attribute :>> rating_Severity_TOP = Severity::Critical_2_SP;
    attribute :>> rating_Probability = Probability::PN3_Occasional;

    // HSIA: How does software respond to this HW failure?
    attribute :>> software_Trigger_Params =
        "Control loop execution time exceeds threshold, watchdog warnings";
    attribute :>> software_Actions =
        "Reduce control bandwidth, disable non-critical features, " +
        "initiate controlled landing sequence";
    attribute :>> software_Requirements =
        "REQ-SW-FC-015: Monitor control loop timing; " +
        "REQ-SW-FC-023: Graceful degradation modes; " +
        "REQ-SW-FC-041: Emergency landing procedures";
    attribute :>> effect_On_Hardware =
        "Software workload reduction may allow MCU to recover from thermal throttling";
    attribute :>> recommendations_HSIA =
        "Implement adaptive control loop frequency based on MCU load; " +
        "Add temperature-based performance derating table";

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

HSIA fields document the bidirectional interaction between hardware failures and software mitigation strategies.

Notable Features

EE-Level Detail

Models actual ICs (LTC4368, TMP100) with datasheet-based failure modes including electrical characteristics (UV/OV/OC protection thresholds, I2C communication timing)

Multi-Instance Circuits

Abstract circuit definitions enable reuse with different reference designators, avoiding duplication while maintaining schematic traceability

Complete Traceability

Every component maps to PCB reference designator (U1, Q1, R7) for direct correlation with hardware schematics, BOM, and assembly documentation

Causal Chain Analysis

Explicit causal links between failure modes at different hierarchy levels enable visualization of complete fault propagation paths

HSIA Integration

Analyzes software response to hardware failures including trigger parameters, actions taken, requirements traceability, and hardware feedback effects

Related Topics

• ECSS-Q-ST-30-02C: FMEA/FMECA — Design FMECA workflow

• ECSS DFMECA: Earth Observation Satellite — Satellite DFMECA (system-level, without circuit detail)

• ECSS DFMEA: Electric Vehicle — Electric Vehicle DFMEA (qualitative variant)

• ECSS-Q-ST-30-02C: FMEA/FMECA — ECSS library reference

• Features — Derisker features