Chapters

27 Automotive Qualification: Evidence Gates

design-methodology
spec
sheet
automotive

27.1 Start With the Decision

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 is part 2 of 2. Review Automotive Qualification: Mission Profiles for the preceding evidence.

27.3 Learning Objectives

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

27.4 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

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.

1. Vehicle claimName the sensing function, action, user warning, control loop, or diagnostic decision.
2. Safety contextRecord whether the function is comfort, advisory, control, or safety-relevant.
3. Mission profileDefine temperature, voltage, vibration, humidity, EMC, lifetime, and installation exposure.
4. Component qualificationCheck AEC-Q status, grade, package, reliability, diagnostics, and supplier documentation.
5. Integration evidenceVerify schematic, interface, timing, current, diagnostics, EMC, HIL, and vehicle behavior.
6. Release packetPackage decisions, evidence artifacts, residual risks, waivers, and owners.

27.6 Extract the Automotive Evidence Rows

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

Evidence Area
What to Look For
Design Question
Release Artifact
Qualification
AEC-Q status, temperature grade, package, reliability notes, product status, and change-control path.
Is the component qualified for the intended automotive location and lifetime?
Supplier datasheet, qualification declaration, grade note, and approved vendor record.
Safety context
Diagnostics, self-test, fault flags, redundancy support, plausibility paths, and failure modes.
Can the component support the system safety concept assigned by the project?
Safety concept reference, FMEA/FMEDA input, diagnostic test log, and residual-risk note.
Environment
Operating temperature, storage temperature, vibration, shock, humidity, chemical, and mechanical limits.
Does the mission profile stay inside the recommended operating conditions?
Mission profile, derating decision, environmental test plan, and bench/vehicle evidence.
Electrical
Supply range, transient tolerance, reverse protection needs, current modes, I/O thresholds, and startup timing.
Will the board rails, sleep states, reset behavior, and load events stay valid?
Schematic review, rail capture, current log, reset test, and power-state register dump.
EMC
Emissions/immunity guidance, filtering, layout constraints, shield recommendations, and automotive test references.
Can the sensor and interface survive the vehicle electromagnetic environment?
EMC design review, pre-scan result, and mitigation record.
Interface
CAN, LIN, SENT, PSI5, SPI, I2C, UART, Automotive Ethernet, timing, diagnostics, and data validity rules.
Can the host read, validate, time-stamp, and diagnose the signal correctly?
Bus trace, timing budget, diagnostic coverage check, and integration log.
Lifecycle
Product lifecycle status, traceability, supplier notification, PPAP path, and second-source strategy.
Can the product be built and serviced for the expected program life?
Supplier evidence, part approval record, and change-control owner.

Do not start by asking whether a part is “automotive grade.” Start by recording the installation location and mission profile. Cabin, dashboard, wheel, chassis, bumper, and under-hood locations can have different temperature, vibration, moisture, EMC, and service assumptions.

27.7 Four Application Patterns

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

Make Four Application Patterns traceable: inspect Figure 27.1 for Automotive Sensor Categories. Focus next on sensors, the companion label anchoring Automotive sensor categories carry different evidence burdens: safety systems demand redundancy and response-time proof, while comfort, performance monitoring, and ADAS add their own power, lifetime, and processing constraints.

Automotive sensor categories across safety systems, comfort features, performance monitoring, and ADAS, with different reliability, response-time, power, and processing burdens.
Figure 27.1: Automotive sensor categories carry different evidence burdens: safety systems demand redundancy and response-time proof, while comfort, performance monitoring, and ADAS add their own power, lifetime, and processing constraints.

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.

Application
Primary Claim
Datasheet Focus
Evidence Beyond Datasheet
Seat occupancy
Classify occupancy state to support warnings or restraint decisions.
Range, accuracy, drift, response, diagnostics, mounting, and temperature limits.
Seat build variation, calibration, misuse cases, plausibility, HIL, and vehicle tests.
Crash sensing
Detect crash-relevant acceleration and support a restraint-system decision.
Range, bandwidth, latency, shock survival, self-test, diagnostics, and safety documentation.
System hazard analysis, redundant sensing, crash algorithm validation, HIL, and compliance evidence.
TPMS
Measure tire pressure and report warnings across the service life.
Pressure range, accuracy, temperature compensation, sleep current, RF behavior, package, and battery assumptions.
Mission-profile current, battery derating, RF link checks, wheel environment, and regulatory test evidence.
ADAS sensing
Support perception, warning, or control decisions outside the vehicle.
Range, field of view, update rate, latency, weather limits, diagnostics, synchronization, and interface.
Sensor fusion validation, scenario coverage, calibration, HIL, track/road tests, and safety case evidence.

27.8 Incremental Examples

27.8.1 Cabin Comfort Temp Sensor

A cabin HVAC sensor is a lower-risk starting point than a restraint or ADAS sensor, but it still needs automotive qualification discipline. The first review checks AEC-Q status where required by the program, operating temperature around the dashboard or duct location, supply and I/O tolerance, package airflow, startup time, diagnostics, LIN/CAN gateway expectations if applicable, and whether the reading only changes comfort behavior rather than a safety function.

27.8.2 Tire Pressure Monitoring

A TPMS review connects the pressure row to the wheel mission profile. The datasheet can support pressure range, temperature compensation, RF behavior, package sealing, sleep current, active current, wake strategy, and battery assumptions. The release claim still needs measured current by state, wheel-temperature exposure, RF reception checks, regional frequency and regulatory evidence, and warning-threshold behavior under realistic service conditions.

27.8.3 Front Radar for ADAS

A front radar module review cannot stop at range and update rate. The qualification thread should connect field of view, latency, diagnostics, synchronization, calibration state, bumper/radome material, contamination behavior, CAN FD or Automotive Ethernet transport, object-tracking confidence, HIL scenarios, track tests, and ISO 26262 safety work. The datasheet supports component capability; the perception and control claim requires system validation.

27.9 Seat Occupancy Example

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.

Claim

Classification

Name the required seat states and what each state allows the vehicle to do.

Rows

Accuracy and drift

Extract accuracy, hysteresis, temperature drift, response, overload, and diagnostic behavior.

Integration

Seat stack matters

Foam, upholstery, rails, mounting, vibration, and aging can shift the measured signal.

Evidence

Calibrated decision

Release needs calibration, classification logs, fault handling, and borderline-state review.

A strong review statement is: "The selected sensor range and accuracy support the classification thresholds under the stated seat build and temperature assumptions; bench and seat-buck tests verify calibration, diagnostic faults, and borderline cases."

27.10 Crash and Restraint Sensing Example

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.

Datasheet Row
What It Supports
What It Does Not Prove Alone
Measurement range
The sensor can represent expected acceleration without saturating under the target scenario.
The system will deploy correctly, avoid nuisance deployment, or classify crash severity correctly.
Bandwidth and latency
The component can produce data quickly enough for the integration timing budget.
The complete ECU, bus, filtering, and algorithm path meets the system response requirement.
Self-test and diagnostics
The component can expose some internal or interface faults.
The diagnostics cover all dangerous failures or meet the required safety concept by themselves.
Shock survival
The package and die have documented survival limits under specified conditions.
The final vehicle installation, mounting, and harness remain valid during the event.

“Sensor supports self-test” is not the same as “the restraint system is safe.” The system claim also needs diagnostics, redundancy or plausibility, timing, integration, software, verification, and safety-analysis evidence.

27.11 TPMS Example

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.

Review Topic
Datasheet Evidence
Integration Evidence
Release Risk
Pressure measurement
Range, accuracy, compensation, response, and overpressure limit.
Pressure bench test across the relevant operating profile.
Warning threshold error or drift under wheel conditions.
Battery life
Sleep current, active current, sampling modes, RF transmit behavior, and wake features.
Measured current by state, duty-cycle log, battery derating, and temperature profile.
Typical current assumptions fail over service life.
RF link
Frequency option, transmit mode, antenna guidance, and regulatory notes.
Wheel-to-vehicle reception test and coexistence review.
Missed messages or regional variant mismatch.
Wheel environment
Temperature, shock, vibration, package, sealing, and storage limits.
Environmental test plan and assembly review.
Mechanical damage, condensation, or battery degradation.

27.12 ADAS Sensor Example

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.

Radar

Range and velocity

Review field of view, range bins, velocity measurement, update rate, diagnostics, and mounting constraints.

Camera

Classification context

Review sensor format, exposure, dynamic range, optics, temperature, synchronization, and cleaning assumptions.

Fusion

Timing and calibration

Review synchronization, latency, coordinate frames, calibration, confidence, and degradation modes.

Validation

Scenario evidence

HIL, track, fleet, weather, and edge-case evidence are needed before release claims are credible.

27.13 Release Evidence Gate

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.

Automotive release evidence gate combining datasheet rows, qualification evidence, safety analysis, environmental and EMC checks, integration tests, and release decision.
Figure 27.2: Automotive release review combines datasheet evidence with qualification, safety, environmental, EMC, integration, and residual-risk evidence.

For Release Evidence Gate, the visual sequence in Figure 27.2 opens with Datasheet Rows, where it highlights Datasheet Rows. Qualification follows to show how it highlights Qualification; AEC and supplier evidence then uses AEC and supplier evidence to hold review evidence. That progression connects Automotive release review combines datasheet evidence with qualification, safety, environmental, EMC, integration, and residual-risk evidence to the next Release Evidence Gate check.

Release Packet Section
Include
Reviewer Question
Selection rationale
Selected sensor, alternatives rejected, vehicle function, installation location, and mission profile.
Is the component being judged against the right vehicle claim?
Datasheet evidence
Rows for range, accuracy, temperature, electrical limits, interface, diagnostics, package, and lifetime.
Are values copied with their conditions and limits?
Qualification evidence
AEC-Q grade, supplier documents, lifecycle status, traceability, and change-control path.
Is the component controlled for automotive production?
Safety evidence
Hazard context, safety mechanism assumptions, diagnostic coverage inputs, and fault handling.
Are component claims kept separate from system safety claims?
Integration evidence
Schematic review, bus trace, power-state log, EMC pre-scan, HIL, bench, and vehicle checks.
Did the assembled system behave as assumed?
Residual risk
Open limits, waivers, owners, mitigations, pilot monitoring, and release decision.
Is every unproven claim owned or blocked?

27.14 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

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

Label the Automotive Qualification Route

27.17 Common Pitfalls

Check grade, temperature range, qualification scope, package, lifecycle status, supplier evidence, and installation location. “Automotive” without a mission profile is too vague.

Use maximum, minimum, temperature, aging, tolerance, and test-condition rows for release decisions. Typical values can support estimates but should not carry safety or lifetime claims alone.

Automotive sensors operate near motors, radios, switching supplies, harnesses, and high-current events. EMC design review and pre-scan evidence should happen before formal testing.

A self-test bit is useful, but release evidence must show how firmware reads it, reacts to it, logs it, and handles faults in the complete system.

Automotive programs need traceability and change control. A technically good sensor can still be unsuitable if availability, process evidence, or notification paths are weak.

27.18 Summary

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

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

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

If you want to…Read this
Review component datasheet basicsSpecification Sheet Fundamentals
Practice with an accelerometer exampleAccelerometer Datasheet Case Study
Compare candidate sensors systematicallySensor Selection Process
Turn selected parts into release testsEnd-to-End Test Strategy
Connect validation evidence to simulation and HILSimulation-Driven Testing and Validation
PreviousCurrentNext
Accelerometer Datasheet Case StudyAutomotive Datasheet QualificationSpecification Sheet Fundamentals

27.22 Key Takeaway

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 final part closes the route from Bound Datasheet Claims through Key Takeaway. Return to Automotive Qualification: Mission Profiles or continue from the design-methodology module index.