• 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 

Plausible but incorrect output: RF degradation, calibration error, ADC/DSP fault or environmental effects create believable but wrong detections or measurements. 

Silent degradation or performance loss: Sensitivity, range, angle, timing or update rate degrades without a clear fault flag. 

Clock, synchronisation or latency error: Timestamp, scheduling or interface delay misaligns sensor data with other sources. 

Processing, memory or data-path fault: DSP, accelerator, memory or interconnect fault corrupts samples, detections or tracks. 

Calibration and configuration mismatch: Wrong antenna, vehicle variant, calibration or firmware parameters affect perception performance. 

Environmental and interference effects: Temperature, vibration, EMC, mutual interference or target characteristics alter performance. 

Misuse of diagnostic coverage claims: A silicon diagnostic is assumed to detect system-level perception insufficiency that is outside its fault model. 

IC architecture and operating context 

Define antenna/RF front end, transmit/receive chains, PLL/clock, ADC, DSP/accelerator, memory, sensor interface, calibration data, time synchronisation, data link to ECU, diagnostics, firmware, boot/configuration, power domains and external safety monitor. Identify whether the IC outputs raw samples, detections, tracks or higher-level features. State the boundary between silicon diagnostics, sensor-level plausibility and vehicle-level perception/decision logic. 

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, including relevant system, hardware and software parts; semiconductor guidance in ISO 26262-11. 

• ISO 21448 (SOTIF) may be relevant where hazards arise from functional insufficiencies or performance limitations rather than faults. 

• ISO/SAE 21434 may apply to sensor connectivity, firmware, interfaces and update paths. 

• AEC-Q100 may apply to IC qualification but is not a functional-safety assessment. 

• Applicable radar, radio-frequency, EMC, spectrum and vehicle regulations depend on product and market. 

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	Hazardous object or condition not detected	Downstream ADAS function may fail to respond as intended	Define performance limits, diagnostic status and system-level plausibility/monitoring.
H-02	False or mislocated detection accepted	Unintended braking, steering or driver warning	Specify data validity, confidence/status handling, timing and cross-sensor checks.
H-03	Latency or timestamp error	Incorrect fusion or delayed downstream action	Define timing budgets, synchronisation and stale-data response.
H-04	Calibration/configuration error	Perception performance differs from validated baseline	Control variant, calibration, firmware and production end-of-line checks.
H-05	Performance limitation not covered by fault diagnostics	Hazard arises in a nominally fault-free but insufficient scenario	Use SOTIF-style analysis where applicable alongside ISO 26262 fault analysis.

 

Safety requirements, architecture and implementation 

Specify measurement/data outputs, operating envelope, timing and latency, data validity and confidence semantics, fault/status reporting, diagnostic coverage boundaries, calibration and configuration integrity, startup and self-test, temperature/voltage/environmental limits, memory/data-path protection, interface freshness, sensor degradation indication and downstream reaction assumptions. Separate random hardware-fault controls from performance limitations and foreseeable sensor insufficiencies. Numeric detection/range/accuracy claims must be product-specific and validated under defined scenarios. 

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 

Combine semiconductor-level fault injection and diagnostic tests with sensor-level performance validation and ECU/perception integration tests. Cover RF and signal-chain faults where testable, clock and timing errors, memory/DSP faults, corrupted or stale data, calibration mismatch, power/temperature corners, EMC/interference scenarios and diagnostic reporting. Validate data quality over representative targets and environmental conditions; assess the downstream system’s response to degraded, missing and plausible-but-wrong outputs. Use scenario-based testing and document limitations of simulated scenes, targets and test tools. 

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
Treating ISO 26262 as the only relevant analysis	Consider SOTIF for performance limitations and ISO/SAE 21434 for cybersecurity where applicable.
Equating no fault flag with valid perception	Define operating envelope, performance indicators, plausibility checks and degradation handling.
Claiming full system diagnostic coverage from IC tests	Limit claims to the fault model and evidence; validate the downstream sensor/ECU behaviour.
Ignoring time synchronisation and latency	Test timestamps, scheduling, transport delay, data freshness and fusion assumptions.
Using only synthetic scenarios	Combine simulation with representative target, environment and integration evidence, justified by risk.
Failing to control calibration and variants	Link firmware, calibration, antenna/vehicle configuration and end-of-line checks to release records.

 

Relationship to adjacent disciplines 

ISO 26262 addresses faults and safety mechanisms; SOTIF addresses functional insufficiencies and performance limits; cybersecurity addresses intentional manipulation and access; RF/antenna engineering characterises sensor physics; perception software and sensor fusion evaluate system behaviour; EMC engineering covers disturbance and coexistence; configuration management controls calibration and variant integrity.

• ISO 26262 series and ISO 26262-11 — Road-vehicle functional safety and semiconductor guidance. 

• ISO 21448 — Road vehicles safety of the intended functionality (SOTIF); verify current edition and applicability. 

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

• AEC-Q100 — IC qualification; verify applicable revision. 

• Applicable RF, EMC, spectrum and vehicle requirements for the target market. 

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 radar and sensor-IC teams with semiconductor FMEDA, safety-manual review, dependent-failure analysis, diagnostic boundary assessment, fault-injection strategy and sensor-to-ECU V&V planning. Scope should identify the sensor modality, output abstraction, intended ADAS function, operating envelope and target-market requirements. 

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

• Does ISO 26262 cover missed objects caused by sensor limitations? ISO 26262 addresses malfunctions and faults within its scope. ISO 21448/SOTIF may be relevant for hazards caused by functional insufficiencies or performance limitations in the absence of a fault. 
• Can radar IC diagnostics prove the ADAS function is safe? No. IC diagnostics cover defined fault models. Sensor performance, data validity, fusion, downstream decision logic and vehicle-level response also require assessment. 
• Is AEC-Q100 enough for an automotive radar IC? No. It addresses IC stress-test qualification. Functional-safety and application-specific evidence are separate considerations.