27 Automotive Qualification: Evidence Gates

27.1 Start With the Decision

This section: Start With the Decision — A datasheet row is evidence only inside its stated limit and test.

A datasheet row is evidence only inside its stated limit and test. The release gate must retain the risks it cannot settle.

27.2 Route Overview

This section: Route Overview — This is part 2 of 2.

This is part 2 of 2. Review Automotive Qualification: Mission Profiles for the preceding evidence.

27.3 Learning Objectives

This section: Learning Objectives

• Extract bounded automotive claims from datasheet rows.
• Build evidence gates for TPMS, restraint, and ADAS cases.

27.4 Chapter Roadmap

This section: Chapter Roadmap

• Bound Datasheet Claims
• Extract the Automotive Evidence Rows
• Mission Profile Before Part Number
• Four Application Patterns
• Incremental Examples
• Seat Occupancy Example
• Crash and Restraint Sensing Example
• Keep Component Claims From System
• TPMS Example
• ADAS Sensor Example
• Release Evidence Gate
• Try It Now
• Choose the Evidence Layer
• Practice Checks
• Match Automotive Evidence to Need
• Order Automotive Datasheet Review
• Label the Automotive Qualification Route
• Knowledge Check: AEC-Q Scope
• Knowledge Check: TPMS Service Life
• Common Pitfalls
• 1. Automotive Grade Is Not One Box
• 2. Typical Values Are Not Claims
• 3. Ignoring EMC Until the End
• 4. Component vs System Diagnostics
• 5. Missing Supplier Lifecycle Proof
• Summary
• References
• See Also
• What’s Next
• Key Takeaway

27.5 Bound Datasheet Claims

This section: Bound Datasheet Claims — Use the datasheet to qualify a bounded vehicle claim, then hand unresolved risk to the correct system evidence.

Use the datasheet to qualify a bounded vehicle claim, then hand unresolved risk to the correct system evidence.

First: Name the vehicle function. State whether the sensor supports comfort, advisory warning, diagnostic reporting, control, or a safety-relevant decision.

Next: Map the mission profile. Tie datasheet rows to installation location, temperature, supply events, vibration, moisture, EMC exposure, lifetime, service access, and interface timing.

Then: Separate evidence layers. Treat AEC-Q status, diagnostics, and package ratings as component evidence; use schematic captures, bus traces, HIL runs, EMC pre-scans, vehicle tests, and ISO 26262 work for integration and vehicle claims.

27.6 Extract the Automotive Evidence Rows

This section: Extract the Automotive Evidence Rows — The first pass should produce a compact evidence table.

The first pass should produce a compact evidence table. Avoid copying the datasheet into the design record.

27.7 Four Application Patterns

This section: Four Application Patterns — Automotive examples are useful when they show different evidence needs.

Automotive examples are useful when they show different evidence needs. Treat the examples below as patterns, not as universal part recommendations.

The four application panels in Figure 27.1 ask for different proof. Seat occupancy starts with a classification claim; its datasheet rows include accuracy, drift, response, and mounting, but seat variation and misuse still need tests. Crash sensing adds range, bandwidth, latency, and diagnostic needs, then requires hazard analysis and system validation beyond the part sheet. TPMS adds sleep current and battery assumptions because warnings must work across service life. ADAS brings field of view, weather limits, and timing into the review, followed by scenario and track or road evidence. Choose checks from the application claim before treating any sensor specification as enough.

+

Read the four application panels in Figure 27.1, moving from each primary claim to its evidence beyond the datasheet. Compare the required checks across applications; they change with the sensing task. A part specification alone cannot establish that the application works.

27.8 Incremental Examples

This section: Incremental Examples

27.9 Seat Occupancy Example

This section: Seat Occupancy Example — Seat sensing is a good example of why accuracy rows cannot be read in isolation.

Seat sensing is a good example of why accuracy rows cannot be read in isolation. The datasheet may state range and error, but the system must classify occupants under seat foam variation, temperature, mounting tolerance, aging, electrical noise, and unusual loads.

27.10 Crash and Restraint Sensing Example

This section: Crash and Restraint Sensing Example — Crash sensing cannot be reduced to a high acceleration range.

Crash sensing cannot be reduced to a high acceleration range. The review needs latency, bandwidth, shock survival, self-test, diagnostics, redundancy, plausibility checks, and algorithm evidence.

27.11 TPMS Example

This section: TPMS Example — TPMS is a useful low-power automotive IoT pattern.

TPMS is a useful low-power automotive IoT pattern. The datasheet rows for pressure range, temperature compensation, current, wake behavior, RF interface, and package must be evaluated against a wheel mission profile, not a room-temperature demo.

27.12 ADAS Sensor Example

This section: ADAS Sensor Example — ADAS sensing usually requires multiple sensors and a scenario-based validation plan.

ADAS sensing usually requires multiple sensors and a scenario-based validation plan. A radar, camera, lidar, or ultrasonic datasheet can support range, field of view, latency, update rate, environmental limits, diagnostics, and interface assumptions. It cannot prove the perception stack is safe across traffic scenarios.

27.13 Release Evidence Gate

This section: Release Evidence Gate — Evidence for Release Evidence Gate starts at the figure Figure 27.2 with Datasheet Rows.

Evidence for Release Evidence Gate starts at the figure Figure 27.2 with Datasheet Rows. Contrast Qualification against it before joining safety, environmental, EMC, integration, and residual-risk evidence in the release review.

+

The gate in Figure 27.2 links part data to release proof; check what is missing.

27.14 Try It Now

This section: Try It Now

Rewrite this weak release statement into a bounded automotive review note:

“The sensor is AEC-Q qualified, so it is safe to use for the warning function.”

A stronger answer should name the vehicle function, safety context, installation location, mission profile, interface, diagnostics, component qualification evidence, integration checks, and the remaining system evidence owner.

27.15 Choose the Evidence Layer

This section: Choose the Evidence Layer — First: A seat sensor’s datasheet lists a self-test feature, but the ECU fault reaction has not been checked.

For each claim, write whether the next evidence should be component, integration, or vehicle-level evidence:

First: A seat sensor’s datasheet lists a self-test feature, but the ECU fault reaction has not been checked.

Next: A TPMS module has low typical sleep current, but no final-board current trace exists.

Then: A radar module reports object range in a bench setup, but no scenario coverage exists for degraded weather.

27.16 Practice Checks

This section: Practice Checks

27.17 Common Pitfalls

This section: Common Pitfalls

27.18 Summary

This section: Summary — Automotive sensor datasheet review is a qualification workflow.

Automotive sensor datasheet review is a qualification workflow. Start with the vehicle claim, record the safety context and mission profile, extract only the relevant datasheet rows, check component qualification and supplier evidence, verify integration on the bench and in system tests, and package the release decision with residual risks. The datasheet supports the decision, but it is never the complete safety, lifetime, EMC, or vehicle-validation case.

27.19 References

This section: References — First: Automotive Electronics Council Documents - official AEC document portal for component qualification standards such as AEC-Q100 (the council currently serves this portal over HTTP).

First: Automotive Electronics Council Documents - official AEC document portal for component qualification standards such as AEC-Q100 (the council currently serves this portal over HTTP).

Next: ISO 26262 Road Vehicles Functional Safety - official ISO overview of the road-vehicle functional safety standard series.

Then: ISO 16750-2:2023 Road Vehicles Environmental Conditions and Testing - official ISO page for electrical-load context for vehicle electronic equipment.

After that: ISO 11452-1:2025 Road Vehicles Component Test Methods for Electrical Disturbances - official ISO page for component-level electromagnetic immunity context.

Also inspect: IEC CISPR 25:2021 Vehicle Radio Disturbance Characteristics - official IEC page for automotive emissions context.

Finally: NHTSA FMVSS 138 TPMS Laboratory Test Procedure - official NHTSA test-procedure page for tire-pressure monitoring systems.

27.20 See Also

This section: See Also — First: Specification Sheet Fundamentals: review how limits, typical values, and conditions become design assumptions.

First: Specification Sheet Fundamentals: review how limits, typical values, and conditions become design assumptions.

Next: Sensor Selection Process: compare candidate sensors before adding automotive mission-profile evidence.

Then: Accelerometer Datasheet Case Study: practice one concrete motion-sensor datasheet review.

After that: End-to-End Test Strategy: turn qualification gaps into release-gate evidence.

Also inspect: Simulation-Driven Testing and Validation: connect bench, HIL, and scenario evidence to automotive release decisions.

27.21 What’s Next

This section: What’s Next

27.22 Key Takeaway

This section: Key Takeaway — Automotive IoT specifications must account for temperature, vibration, safety, qualification, supply lifetime, and electrical transients.

Automotive IoT specifications must account for temperature, vibration, safety, qualification, supply lifetime, and electrical transients. Consumer-grade assumptions rarely survive automotive environments.

27.23 Continue Your Route

This section: Continue Your Route — This is the last part of this chapter.

This is the last part of this chapter. Return to Automotive Qualification: Mission Profiles or continue from the design-methodology module index.