1. Hardware Safety Requirements Engineering 

What: Hardware requirements must be derived from the Technical Safety Concept and system-level safety requirements. 

How: Define safety mechanisms, fault detection, diagnostic behavior, fault reaction, timing constraints, safe states, hardware interfaces and verification criteria. Maintain bidirectional traceability from TSR → HSR → architecture → implementation → verification. 

2. Hardware Safety Architecture 

What: The architecture must achieve the required safety behavior while controlling single-point and latent fault exposure. 

How: Evaluate redundancy, monitoring, supervision, watchdogs, lockstep or diverse processing, memory protection, power supervision, communication monitoring, sensor plausibility and actuator shutdown concepts. Perform architecture-level dependent-failure and common-cause analysis where applicable. 

3. FMEDA and Quantitative Hardware Safety Analysis 

What: Hardware failure modes need to be evaluated against the applicable safety targets and diagnostic mechanisms. 

How: Build the FMEDA from the hardware architecture and component data; classify failure modes, identify safety mechanisms, assess diagnostic coverage and calculate the applicable hardware safety metrics. For ISO 26262, this includes SPFM, LFM and PMHF; for IEC 61508, applicable probability-of-failure metrics such as PFH/PFDavg are used according to the safety function and operating mode. 

4. Safety Mechanism and Diagnostic Coverage 

What: Safety metrics depend heavily on whether safety mechanisms detect relevant faults within the required time. 

How: Specify detection principles, thresholds, diagnostic intervals, fault reaction paths and fault containment. Validate assumptions through analysis and fault-injection testing rather than relying only on nominal behavior. 

5. Hardware Architectural Metrics 

What: A design may function correctly under nominal conditions but still fail to satisfy its hardware safety target. 

How: Evaluate the applicable architectural and probabilistic metrics, identify dominant contributors, perform sensitivity analysis and propose architecture or diagnostic improvements. For ISO 26262 this includes SPFM, LFM and PMHF; ISO 13849 uses a different framework centered on PL, Category, MTTFd, DCavg and CCF. 

6. Dependent Failure and Common-Cause Analysis 

What: Redundant channels do not automatically provide independence if they share a common vulnerability. 

How: Analyze shared power, clock, reset, communication, thermal, physical, environmental and software-controlled dependencies. Identify common-cause and dependent-failure paths and introduce appropriate architectural or physical mitigation. 

7. Hardware Design and Simulation 

What: Safety requirements must survive the transition from architecture to actual schematic, PCB and component implementation. 

How: Support mixed-signal, power-electronics, multi-processor and high-speed hardware design; use schematic review, derating, worst-case circuit analysis, SPICE simulation, signal/power integrity and thermal analysis to identify implementation risks early. 

8. Hardware Verification and Fault Injection 

What: Safety mechanisms need objective evidence that faults are detected and handled as intended. 

How: Define hardware verification strategies, safety mechanism tests, fault-injection scenarios, diagnostic coverage evidence, integration tests and traceability to safety requirements. Verification is planned across the lifecycle rather than added at the end.

Need support with an Functional Safety project? Contact our Functional Safety experts

Functional Safety Hardware Requirements 

• Derivation of Hardware Safety Requirements from TSR/TSC 
• Safety mechanism requirements and diagnostic behavior 
• Fault detection and fault reaction requirements 
• FTTI and safety reaction timing requirements 
• Safe-state and degradation requirements 
• Hardware-software interface (HSI) safety requirements 
• Traceability and verification criteria 

 Hardware Safety Architecture 

• Safety-oriented hardware architecture development 
• Redundancy and monitoring concepts 
• Watchdog, reset, clock and power supervision 
• Memory and communication diagnostics 
• Sensor and actuator monitoring 
• Fail-safe and fail-operational architecture concepts 
• Hardware-software partitioning and safety interface definition 
• ASIL/SIL-oriented architecture analysis 

 FMEDA & Hardware Safety Analysis 

• FMEDA development and review 
• Failure-mode classification and safety-effect analysis 
• SPFM, LFM and PMHF analysis for applicable ISO 26262 programs 
• PFH/PFDavg-oriented analysis for applicable IEC 61508 programs 
• Diagnostic coverage assessment 
• Single-point, residual, latent and multiple-point fault analysis 
• FMEA and hardware safety analysis 
• Dependent Failure Analysis (DFA) 
• Common-cause failure analysis 
• Fault-injection planning and analysis 

 Hardware Safety Design & Development 

• Safety-compliant schematic and architecture development 
• MCU/MPU/SoC/ASIC/FPGA/PLD safety architecture support 
• PMIC and power-supply supervision 
• Power electronics and protection circuit design 
• BMS and battery safety electronics 
• Inverter and DC-DC converter safety hardware 
• Mixed-signal and high-speed hardware 
• Multi-layer PCB design support 
• Hardware-software interface definition 
• Design reviews and safety-oriented design improvement 

 Hardware Simulation, Reliability & Design Analysis 

• Worst-Case Circuit Analysis (WCCA) 
• Component derating and stress analysis 
• SPICE/LTspice simulation 
• Signal Integrity (SI) 
• Power Integrity (PI) 
• Thermal analysis 
• Failure-mode-oriented simulation 
• Design margin and robustness analysis 
• EMC/EMI-related hardware design considerations 

 Hardware Verification & Validation 

• Hardware safety verification planning 
• Safety mechanism verification 
• Fault injection and fault reaction testing 
• Hardware integration testing 
• Diagnostic coverage evidence 
• Requirements-to-test traceability 
• Verification gap analysis 
• Regression and change-impact analysis 
• Assessment evidence preparation 

 Component, Tool & Reuse Assessment 

• Safety assessment of COTS components 
• Component data and failure-rate evaluation 
• Evaluation of existing hardware elements for reuse 
• Tool confidence/qualification support where applicable 
• Safety evidence review for third-party ICs and IP 
• SEooC-oriented hardware safety evidence support 

Typical deliverables can include Hardware Safety Requirements Specifications, safety architecture diagrams, HSI specifications, FMEDA, FMEA, DFA, hardware safety analyses, safety mechanism specifications, fault-injection specifications, hardware verification plans, traceability matrices, metric reports and assessment evidence packages. 

Need support with an Functional Safety project? Contact our Functional Safety experts

• ASIL-D / SIL3 Electric Power Steering & Vehicle Control 
• VerveTronics supported a European Tier-1 program involving ISO 26262 / IEC 61508 ASIL-D / SIL3 safety engineering from concept through assessment/certification support. The work included safety and technical concepts, HARA, hardware FMEDA, software and mechanical FMEA, safety-compliant hardware specifications, hardware design and development, validation/assessment activities and process improvements. 
• ASIL-B DC Power Converter 
• VerveTronics supported a European Tier-1 supplier on an ASIL-B DC power converter program. Activities included safety/technical concept and specifications, hardware FMEDA, software and mechanical FMEA, safety-compliant hardware specifications and assessment support. 
• ASIL-C Electronics DC Protection System 
• VerveTronics supported a US Tier-1 supplier on an ASIL-C electronics DC protection system. The scope included end-to-end ISO 26262 support, safety/technical concept and specifications, hardware FMEDA, software and mechanical FMEA, safety-compliant hardware specifications, assessment support and process improvement. 
• These case studies are based on the existing VerveTronics service-page content and are retained here as representative experience rather than as a claim that every listed activity applies to every engagement. 

Need support with an Functional Safety project? Contact our Functional Safety experts

• Automotive: EV, BMS, EPS, braking, steering, powertrain, ADAS, domain/zonal controllers, body controllers, telematics and vehicle control ECUs. 
• Industrial: safety controllers, motor drives, industrial control, power electronics, machine control and critical monitoring. 
• Robotics & AMR/AGV: safety controllers, drive electronics, sensing, protection and safety-related embedded hardware. 
• Energy & Electrification: BMS, battery protection, inverters, DC-DC converters, charge controllers and energy-storage electronics. 
• Semiconductors: MCU/MPU, SoC, ASIC, FPGA, PMIC, safety IP and semiconductor safety evidence. 
• Off-Highway & Agricultural: safety-related electronic control systems and electrified machinery. 
• Aerospace & Defence: safety-critical electronics and hardware engineering within applicable system and development assurance frameworks. 
• Medical & Other Safety-Critical Electronics: safety-oriented electronic hardware development within the applicable product and regulatory framework. 

Need support with an Functional Safety project? Contact our Functional Safety experts

• Fixed-Scope Safety Work Package – FMEDA, DFA, hardware safety requirements, architecture review or metric analysis. 

• Hardware Safety Engineering Team – dedicated engineers integrated with the customer hardware organization. 

• End-to-End Hardware Safety Engineering – requirements → architecture → analysis → design → verification → assessment readiness. 

• Independent Technical Review – architecture, FMEDA, safety mechanisms, hardware metrics, design evidence and verification review. 

• Gap Assessment & Remediation – identify gaps against the applicable safety standard and develop an actionable closure plan. 

• Assessment Readiness Support – organize technical evidence, traceability, safety analyses and verification artifacts for independent assessment. 

Need support with an Functional Safety project? Contact our Functional Safety experts

• What is Functional Safety Hardware Engineering? – Functional Safety Hardware Engineering is the discipline of translating system and technical safety requirements into hardware requirements, safety architecture, safety mechanisms, quantitative safety analysis, implementation and verification evidence for safety-related electronic systems. 
• What does ISO 26262 require at the hardware level? – ISO 26262 Part 5 addresses automotive hardware development, including hardware safety requirements, hardware design, hardware architectural metrics, evaluation of safety-goal violations caused by random hardware failures, and hardware integration and verification. 
• What is FMEDA? – FMEDA is a structured quantitative hardware safety analysis technique used to evaluate failure modes, diagnostic mechanisms and relevant safety metrics. It is commonly used to support ISO 26262 and IEC 61508 hardware safety analysis. 
• What are SPFM, LFM and PMHF? – SPFM and LFM are ISO 26262 hardware architectural metrics addressing different classes of hardware faults. PMHF is a probabilistic metric for the contribution of random hardware failures to safety-goal violations. The applicable targets depend on the safety integrity level and project assumptions. 
• Can VerveTronics perform FMEDA? – Yes. FMEDA is one of the hardware safety analysis services offered by VerveTronics, together with FMEA, DFA, diagnostic coverage assessment, hardware metrics analysis and fault-injection support. 
• Can you design the hardware as well as perform the safety analysis? – Yes. The existing VerveTronics service scope combines hardware safety requirements, architecture, hardware design support, simulation/analysis, FMEDA and hardware verification. The exact scope can be tailored to customer-owned design activities. 
• Does Functional Safety Hardware Engineering include PCB design? – It can. The existing service page includes mixed-signal, power-electronics and multi-processor schematic design, multi-layer PCB layout support, DRC, WCCA/SPICE, signal integrity, power integrity and thermal analysis. 
• Can you support ASIL C and ASIL D hardware programs? – Yes. VerveTronics’ existing service material describes experience supporting ASIL-C and ASIL-D automotive projects, including hardware safety analysis and development activities.
• Do you support IEC 61508 hardware safety? – Yes. Hardware safety engineering can be performed within IEC 61508 projects, with the applicable SIL, hardware architecture and probabilistic safety measures defined according to the safety function and operating mode. 
• Do you support ISO 13849 hardware safety? – Yes. For machinery applications, hardware safety engineering can support the applicable ISO 13849 architecture and performance-level objectives. ISO 13849 uses its own framework, including PL, Category, MTTFd, DCavg and CCF; it should not be treated as interchangeable with ISO 26262 SPFM/LFM/PMHF. 
• Can you assess an existing hardware design? – Yes. A review can cover hardware safety requirements, architecture, safety mechanisms, FMEDA assumptions, diagnostic coverage, dependent failures, component data, design evidence, verification coverage and gaps against the applicable project safety target. 
• Can you support ASIC, FPGA and complex IC safety? – 
• Yes. ISO 26262 Part 5 covers hardware elements including ASICs, FPGAs and PLDs. VerveTronics can support hardware safety requirements, architecture, safety analysis and verification evidence for such elements within the applicable project scope. 
• Do you provide Functional Safety certification? – VerveTronics provides consulting, engineering, gap assessment, evidence preparation and assessment-readiness support. Formal certification or independent assessment, where required, is performed by the applicable independent/accredited or recognized organization. 
• What inputs are required to start an FMEDA or hardware safety assessment? – Typical inputs include the hardware architecture, schematics/block diagrams, BOM, component failure-rate data where available, safety requirements, safety mechanisms, diagnostic assumptions, operating conditions, interfaces and existing verification evidence. The exact input set depends on the product and applicable standard. 
• Can you work with our existing hardware team? – Yes. Engagements can be structured as an integrated safety engineering team, targeted expert work package, independent review or end-to-end hardware safety engineering support. 
• Which standards can the hardware team support? – The core positioning of this page is Functional Safety Hardware Engineering, with services applicable to ISO 26262, IEC 61508 and ISO 13849. Sector-specific standards may also apply depending on the product, industry and regulatory context.