Hardware Metrics Explained: PMHF, SPFm, and LFm Standards

Discover how automotive engineers calculate hardware metrics like PMHF, SPFm, and LFm to mathematically prove system safety in modern vehicle architectures. This guide explores the foundational standards used to quantify risk and ensure compliance.
Imagine designing the central compute unit for a next-generation autonomous vehicle. A single processing chip now handles everything from climate control to the Automatic Emergency Braking system. How do you mathematically prove that a random silicon defect will not cause an uncommanded braking event?
Subjective safety assurances are no longer acceptable in modern automotive engineering. System architects and safety engineers must rely on rigorous, quantitative hardware metrics to validate their designs. Chief among these is the PMHF (Probabilistic Metric for random Hardware Failures), a foundational standard used to calculate the residual risk of a system over its operational lifetime. Alongside other key metrics, PMHF provides the objective evidence required to prove that an electronic system meets its safety goals.
This article explores the conceptual standards used to calculate automotive hardware metrics, offering a high-level view of how engineers quantify risk without diving into the exhaustive mathematical derivations. We will examine the core pillars of hardware safety, the boundaries of these calculations, and how they apply to real-world architectures.
PMHF and the Evolution of Automotive Hardware Safety
The automotive industry is experiencing a fundamental architectural shift. Traditional vehicles relied on highly distributed networks containing hundreds of distinct Electronic Control Units. Each unit managed a specific, isolated function. Today, the transition toward Software-Defined Vehicles has consolidated these functions into centralized High-Performance Computers.
This evolution does not eliminate complexity; it simply transforms it. Moving from distributed hardware complexity to centralized computational density introduces new challenges. A single hardware failure in a modern domain controller can now cascade across multiple vehicle functions simultaneously. This is precisely why calculating the PMHF is more critical than ever.
Hardware metrics provide the mathematical foundation for proving that these dense electronic systems are safe. As computational power increases, engineers must account for virtualization layers, shared memory resources, and mixed-criticality workloads on single System-on-Chips. The PMHF serves as the ultimate safety budget, ensuring that the cumulative risk from unpredictable component wear-out and stress-related failures remains within acceptable limits.
The Three Pillars: SPFm, LFm, and PMHF Explained
| Metric | Primary Focus | Nature of Measurement | ASIL D Target |
|---|---|---|---|
| SPFm | Single-point & residual faults | Percentage (%) of diagnostic coverage | ≥ 99% |
| LFm | Dormant / hidden faults | Percentage (%) of diagnostic coverage | ≥ 90% |
| PMHF | Cumulative failure risk over time | Absolute probability (FIT / 10^-8 per hour) | < 10 FIT |
To comprehensively evaluate the robustness of hardware against random failures, the functional safety standards define three distinct quantitative metrics. These metrics do not cover systematic flaws, such as coding errors or design mistakes, which are mitigated through rigorous development processes. Instead, they focus entirely on random, physical hardware failures.
Single Point Fault Metric (SPFm)
The SPFm measures a system's architectural robustness against single-point and residual faults. A single-point fault is a failure that leads directly to a safety goal violation because no fault tolerance or safety mechanism exists to catch it. The SPFm calculates the proportion of these dangerous faults that are successfully covered by diagnostics or prevented by safe design. A high SPFm indicates a strong defensive architecture capable of detecting errors before they cause harm.
Latent Fault Metric (LFm)
Not all hardware failures immediately impact vehicle behavior. Some failures remain dormant, hiding within the system until a second independent failure occurs. The combination of these two faults can then lead to a hazardous event. The LFm ensures these hidden vulnerabilities are detected through periodic testing or continuous background diagnostics. By calculating the LFm, engineers prove that dormant failures are identified and mitigated before they can combine into dangerous dual-point faults.
Probabilistic Metric for Random Hardware Failures (PMHF)
While SPFm and LFm focus on diagnostic coverage percentages, the PMHF quantifies the absolute residual risk over time. It represents the average probability of a failure per hour over the operational lifetime of the vehicle. Measured in FIT (Failures in Time, or failures per 10^9 hours), the PMHF budget dictates how reliable the physical components must be. It acts as the overarching threshold that the hardware design must not exceed, factoring in component failure rates, diagnostic effectiveness, and mission profiles.
The three pillars work in unison. PMHF provides the total allowable risk budget, while SPFm and LFm ensure the architecture possesses the necessary diagnostic coverage to detect and control faults before they escalate.
Defining Boundaries for Hardware Metrics Calculations
Flowchart showing the decision process for including or excluding hardware components from metric calculations.
One of the most critical steps in calculating hardware metrics is defining the scope of the analysis. A common pitfall in safety engineering is incorrectly categorizing components, which can severely skew the resulting PMHF, SPFm, and LFm numbers.
Hardware metrics apply exclusively to safety-related elements. These are the specific components that can either cause a violation of a safety goal or are explicitly designed to prevent one. If an element has no direct or indirect path to a hazard, it must be excluded from the mathematical calculations.
Consider the following distinctions when setting your calculation boundaries:
- Included (Safety-Related): Sensor integrated circuits processing critical signals, microcontrollers executing safety algorithms, motor drivers, and the power supply components feeding these critical circuits.
- Excluded (Non-Safety-Related): Debugging interfaces, status display LEDs, unused microcontroller pins, and components dedicated purely to cabin comfort functions.
Including non-safety-related elements artificially inflates both the numerator and denominator of your equations, potentially masking dangerous vulnerabilities. Conversely, improperly excluding safety-related elements leads to overly optimistic metrics. The boundary must be strictly justified through a thorough safety analysis.
Practical Application: Hardware Metrics in an EPS System
Bar chart illustrating the scaling of hardware metric targets (SPFm and LFm) across different ASIL levels.
To understand how these standards influence design, consider an Electronic Power Steering (EPS) system. A sudden, uncommanded steering intervention at highway speeds is a catastrophic hazard, typically resulting in an ASIL D classification, the highest level of risk reduction required.
Because the safety goal is ASIL D, the hardware metrics targets are exceptionally stringent. The architecture must achieve an SPFm of at least 99 percent, an LFm of at least 90 percent, and a PMHF of less than 10^-8 per hour (10 FIT). To meet these numbers, a simple single-channel microcontroller is vastly insufficient.
To calculate passing metrics for this EPS system, the hardware engineer must implement advanced architectural patterns:
- Lockstep Processing: Utilizing dual-core microcontrollers running in lockstep to immediately detect computational errors, drastically improving the SPFm.
- Redundant Sensors: Deploying diverse steering angle sensors to ensure that a single sensor failure does not lead to a loss of control.
- Continuous Memory Scrubbing: Implementing background memory checks to detect and correct bit-flips, thereby satisfying the rigorous LFm requirements.
Interestingly, if the engineering team decides to use ASIL Decomposition to split the ASIL D requirement into two independent ASIL B(D) elements, the hardware metric targets do not change. The overall system must still meet the original ASIL D targets for PMHF, SPFm, and LFm. Decomposition only reduces the systematic development rigor for each individual element, not the mathematical hardware safety targets.
Taking Your Hardware Safety Knowledge Further
Calculating hardware metrics is a complex but necessary discipline for proving the safety of modern automotive systems. By understanding the distinct roles of PMHF, SPFm, and LFm, engineers can make informed architectural decisions that balance cost, performance, and safety.
While this overview provides the conceptual foundation, executing these calculations on a real-world Bill of Materials requires a deep understanding of failure rates, diagnostic coverage models, and fault classifications. If you are ready to master the mathematics and practical application behind these standards, dive deeper with our comprehensive Everything About Hardware Metrics concept on the ISO 26262 Academy platform. Equip yourself with the exact methodologies needed to build compliant, life-saving architectures.
Abbreviations & Key Definitions
- ADAS - Advanced Driver Assistance Systems, electronic technologies that assist drivers in driving and parking functions.
- ASIL - Automotive Safety Integrity Level, a risk classification scheme defined by ISO 26262 ranging from A to D.
- ECU - Electronic Control Unit, an embedded system in automotive electronics that controls one or more of the electrical systems or subsystems in a vehicle.
- EPS - Electronic Power Steering, a system that uses an electric motor to assist the driver in steering the vehicle.
- FIT - Failures in Time, a measure of failure rate expressed as the number of failures expected in one billion (10^9) device-hours of operation.
- HPC - High-Performance Computer, a centralized, powerful computing unit used in modern vehicle architectures to handle complex software tasks.
- LFm - Latent Fault Metric, a hardware metric that measures the robustness of a system against hidden, dormant failures.
- PMHF - Probabilistic Metric for random Hardware Failures, a hardware metric that quantifies the average probability of a safety goal violation per hour.
- SDV - Software-Defined Vehicle, a vehicle whose features and functions are primarily enabled through software rather than mechanical hardware.
- SoC - System-on-Chip, an integrated circuit that integrates all or most components of a computer or other electronic system.
- SPFm - Single Point Fault Metric, a hardware metric that measures the robustness of a system against single-point and residual faults.


