• Define intended application, safety goals, IC function, system boundary, operating conditions and external assumptions. 

• Identify relevant sector standards and separate component qualification from functional-safety evidence. 

• Develop or review failure-mode analysis, FMEDA and dependent/common-cause failure analysis as appropriate. 

• Convert safety-manual assumptions and diagnostic expectations into allocated, testable system requirements. 

• Plan silicon, board, ECU and system-level verification with fault injection and configuration traceability. 

• Maintain errata, part/stepping, software, calibration and change-control records throughout the product lifecycle. 

Application-specific challenges 

Random hardware faults and latent faults: A fault in a processing, memory, interconnect or control element may escape detection or remain latent until combined with another fault. 

Dependent and common-cause failures: Redundant channels share clocks, power, reset, physical layout, interconnect or environmental exposure. 

Safety mechanism assumptions: A safety manual may assume a specific test interval, software reaction, external monitor or fault response that the integrator does not implement. 

Diagnostic coverage claims: FMEDA assumptions, failure-rate sources, fault models and diagnostic coverage may not represent the actual silicon or application. 

Startup, reset and power-domain sequencing: Reset release, clock failure, brownout or partial-power states produce invalid outputs or bypass expected diagnostics. 

Complex SoC integration and configuration: Caches, accelerators, NoC/interconnect, firmware, memory protection and third-party IP create interactions not covered by block-level checks. 

Debug, test and lifecycle modes: Test modes, scan access, boot configuration or debug interfaces can alter safety mechanisms or expose latent faults. 

IC architecture and operating context 

Map CPU cores, lockstep or redundant processing if present, caches, SRAM/flash, interconnect, DMA, clock/reset, power domains, safety islands, watchdogs, error-correcting codes, memory protection, safety monitors, debug/test access, boot chain, external memories and peripherals. Document which safety mechanisms are on-chip, which are external, their fault models, assumptions of use, diagnostic intervals and dependencies on the SoC’s power, clock, reset and software configuration. 

The architecture review should distinguish the IC’s internal safety mechanisms from external measures and application-level reactions. Document dependencies on supply, clock, reset, external sensing, host software, PCB layout, test access and operating conditions. For each assumption, identify the owner and the evidence that demonstrates it is satisfied in the intended product. 

Applicable standards and boundaries 

• ISO 26262 series: road vehicles functional safety, including hardware, software, system integration and supporting processes as applicable. 

• ISO 26262-5: hardware-level product development; relevant to semiconductor hardware safety analyses and metrics where applicable. 

• ISO 26262-8: supporting processes such as configuration management, change management, verification and documentation. 

• ISO 26262-11: guidance on application of ISO 26262 to semiconductors; verify current edition and scope. 

• AEC-Q100 may be relevant for automotive IC qualification, but qualification is not equivalent to functional-safety compliance. 

• ISO/SAE 21434 may be relevant for cybersecurity engineering; cybersecurity and functional safety are related but distinct. 

Applicability note: this is a preliminary screening list, not a declaration that every listed standard applies. Confirm current editions, amendments, product scope, target market and contractual requirements. ISO 26262 is specific to road vehicles; industrial, medical, railway and other applications may require different sector standards. AEC-Q100 qualification, where applicable, does not by itself establish functional-safety compliance. 

Functional-safety lifecycle 

1. Use-case and boundary definition: establish intended application, safety function, operating environment, interfaces and assumptions of use. 
2. Hazard and failure analysis: identify IC failure modes, system effects, dependent failures and relevant safety mechanisms. 
3. Safety requirements and allocation: specify detection, reaction, diagnostic interval, fault reporting and integration obligations. 
4. Architecture and implementation: define independence, partitioning, safe outputs, reset/power behaviour and configuration controls. 
5. Verification planning: define silicon, simulation, emulation, board, ECU and system-level evidence with test conditions and acceptance criteria. 
6. Integration validation: confirm safety-manual assumptions, host response and external protective measures in the target application. 
7. Lifecycle control: manage silicon revisions, errata, production test, changes, field feedback and ongoing validity of safety evidence. 

Hazards, failure scenarios and safety objectives 

The scenarios below are illustrative and are not a completed FMEDA, quantitative risk assessment or declaration of a safety integrity level. Failure rates, diagnostic coverage, hardware metrics and safety targets must be derived from the actual device data, fault model, intended application and governing standard. 

ID	Illustrative hazardous scenario	Potential consequence	Example engineering objective
H-01	Safety-relevant computation or data corrupted	Vehicle-level safety goal may be violated	Define fault detection, containment, safe reaction and assumptions for CPU, memory and interconnect faults.
H-02	Redundant safety channels fail dependently	Expected fault tolerance is lost	Analyse shared resources, physical dependencies, systematic coupling and common-cause scenarios.
H-03	Safety mechanism not effective in target integration	Fault remains undetected or reaction is late	Validate safety-manual assumptions, diagnostic intervals, external monitors and software response.
H-04	Unsafe outputs during startup/reset/power fault	Unexpected actuation or loss of monitoring	Specify reset, power sequencing, clock supervision and output validity requirements.
H-05	Debug or test mode weakens protection	Safety function or configuration integrity compromised	Control mode entry, access, production configuration, lifecycle state and evidence of closure.

 

Safety requirements, architecture and implementation 

Define the safety concept and intended semiconductor use; hardware safety requirements; fault models; safety mechanism behaviour; diagnostic coverage assumptions; fault detection and reaction times; startup/reset/power-domain behaviour; memory and interconnect protection; clock and voltage supervision; safety manual assumptions of use; configuration and lifecycle controls; and evidence required from silicon validation. Trace semiconductor-level assumptions to the ECU/system safety requirements. Avoid presenting an IC as universally “ASIL compliant” without stating the component scope, assumptions, safety documentation and integration conditions. 

Maintain traceability from system safety goals and hazards to IC safety requirements, safety mechanisms, assumptions of use, external measures, verification results and integration evidence. Clearly identify what is demonstrated by the semiconductor supplier and what remains the integrator’s responsibility. 

Verification, validation and safety evidence 

Use FMEDA and dependent-failure analysis supported by documented failure-rate sources and fault models. Verify safety mechanisms through fault injection, simulation, emulation, silicon tests and system-level tests as appropriate. Cover CPU lockstep/error detection, ECC/parity, watchdogs, clock/reset monitors, voltage monitors, memory protection, startup diagnostics, latent-fault test intervals, diagnostic reporting and safe reaction. Validate safety-manual assumptions at the intended ECU integration and assess the effect of configuration, compiler, firmware, debug/test modes and third-party IP. Record coverage rationale, exclusions, tool limitations and silicon revision. 

Typical evidence may include the safety plan, safety manual, FMEDA and failure-rate basis, dependent-failure analysis, requirements and traceability, fault-injection protocols/results, silicon revision and errata records, diagnostic coverage rationale, test-tool limitations, integration test results, anomalies and closure, and documented assumptions of use. The appropriate evidence package depends on the safety lifecycle and product role. 

Common pitfalls and recommended prevention 

Pitfall	Recommended prevention / detection
Equating AEC-Q100 qualification with functional safety	Treat reliability qualification and ISO 26262 safety evidence as separate, complementary workstreams.
Using safety-manual assumptions without checking them	Convert each assumption of use into an integrator requirement and verify it in the target architecture.
Relying on block-level FMEDA alone	Analyse shared resources, interfaces, system interactions, dependent failures and integration-specific effects.
Treating redundancy as independence	Evaluate common clocks, power, reset, layout, thermal exposure, interconnect and shared software.
Ignoring silicon revision and errata	Maintain traceability to part number, stepping, errata, configuration and applicable safety documentation.
Reporting metrics without transparent assumptions	Document failure rates, fault classifications, diagnostic coverage basis, exclusions and uncertainty.

 

Relationship to adjacent disciplines 

ISO 26262 system and ECU engineering allocates safety requirements and validates assumptions of use; semiconductor reliability addresses lifetime and qualification; cybersecurity engineering protects boot, debug, update and configuration; software assurance verifies the firmware and drivers; dependent-failure analysis examines shared resources; production test and change management preserve the approved silicon baseline.

• ISO 26262 series — Road vehicles functional safety; confirm current edition and applicable parts. 

• ISO 26262-11 — Guidelines on application of ISO 26262 to semiconductors; verify current edition. 

• AEC-Q100 — Failure mechanism based stress test qualification for integrated circuits; confirm applicable revision. 

• ISO/SAE 21434 — Road vehicles cybersecurity engineering, where in scope. 

Currency note — Draft prepared 29 October 2026. Verify current standard editions, amendments, applicability and target-market requirements before publication or project use. This article is engineering information, not a declaration of conformity, certification, or guarantee that a particular IC is suitable for a safety-related application.

• Confirm semiconductor and functional-safety technical reviewer approval. 

• Verify standards editions, product scope, clauses and target-market requirements. 

• Confirm all internal service links resolve and the keyword map avoids cannibalisation. 

• Prepare an original architecture visual with descriptive alt text. 

• Avoid unsupported ASIL, SIL, diagnostic-coverage or compliance claims. 

• Check title/H1 alignment, metadata, canonical URL, visible FAQs, references and proofreading. 

VerveTronics can support semiconductor and automotive teams with ISO 26262 semiconductor safety analyses, FMEDA review, dependent-failure analysis, safety-manual assumption reviews, fault-injection strategy and ECU integration evidence planning. Scope should define the IC function, safety concept, silicon revision, documentation available and intended vehicle-level integration. 

Suggested CTA: Request a semiconductor functional-safety, FMEDA or integration-evidence review. 

• Does an automotive-qualified MCU automatically meet ISO 26262? No. Automotive qualification and functional-safety evidence address different objectives. Suitability depends on the device documentation, safety mechanisms, development evidence and assumptions of use in the target application. 
• Can semiconductor FMEDA be reused for every ECU? Only where the assumptions and integration conditions remain valid. External safety mechanisms, diagnostic intervals, software response, configuration and application-specific failure effects must be checked. 
• Why is dependent-failure analysis important for SoCs? Complex SoCs can share power, clock, reset, interconnect, physical layout and software resources. These dependencies may undermine the independence assumed by redundant channels.