Chapters

26 Automotive Qualification: Mission Profiles

design-methodology
spec
sheet
automotive

26.1 Start With the Decision

A part may pass an automotive test and still fail in its exact place in a car. Start with the vehicle job and its mission profile.

26.2 Route Overview

This is part 1 of 2. Continue with Automotive Qualification: Evidence Gates.

26.3 Part Objectives

  • Separate component qualification from a vehicle safety claim.
  • Map heat, shock, power, and service life to the mission profile.

26.4 Chapter Roadmap

  • Start With the Vehicle Claim
  • Phoebe’s Field Notes: What a TPMS Pressure Row Is Actually Inverting
  • Qualify Vehicle Claim, Not Part
  • Build Automotive Qualification
  • Why Datasheet Rows Fail in Cars
  • In 60 Seconds
  • Prerequisites
  • What This Chapter Adds
  • Component Qual Is Not Safety Case
  • Automotive Datasheet Qualification Route

26.5 Start With the Vehicle Claim

Picture one sensor sold for use in a car. A table may say it can bear heat and shock. That does not prove a warning or brake system is safe. The team must link each part claim to the real place, task, and harm.

A datasheet is the maker’s list of part limits and test facts. Qualification is proof that a part passed a named set of tests. AEC-Q is one set used for car parts. Qualification helps the case, but it does not test the whole vehicle feature.

Start with the vehicle job. Name where the part sits, how long it must last, what it must sense, and what a bad value could cause. Then check heat, cold, water, dust, shock, vibration, power spikes, radio noise, timing, and built-in fault reports.

Keep maker proof and team proof apart. The maker may prove a chip at a set heat range. The team must still prove its board, case, wires, code, mounting, and full vehicle path. A pass for a cabin comfort sensor is not a pass for a crash sensor.

Seat sensing, tyre pressure, radar, and crash sensing each need a different record. Trace the input, part output, software check, warning or action, fault state, and safe response. Record which claim comes from a table, supplier file, bench test, hardware-in-the-loop test, vehicle test, or safety review.

Parts can change while a product is sold. Track the exact part grade and maker. Check how long it will be supplied. Retest after a part, factory, package, board, code, or mission changes.

This Overview uses clear pass limits for one part in one vehicle job. Real safety work also needs system analysis, standards, and tests run by the right experts. The Practitioner section builds the release pack. Under the Hood checks timing, power, faults, supply change, and safety limits.

Try a seat sensor case. The part must tell an empty seat from a person and from a heavy bag. Test heat, cold, wet clothes, seat trim, body size, and a broken wire. Keep wrong alerts and missed alerts. State who decides the safe warning rule.

Try a tyre sensor case. The unit spins, heats, cools, shakes, and runs from a small cell. Check its range at each wheel. Check pressure against a known tool. Lose one message path. Show how the driver can tell a lost unit from a sound tyre.

Try a radar case. Rain, dirt, another vehicle, mounting angle, and a changed bumper can alter the view. A chip range in a table does not prove the full view. Save the target, place, speed, weather, software build, and result for each test.

Try a crash sensor case. The time path is short and the harm is high. Trace the sensor, wires, power, code, decision, and safe fault state. Use expert safety work for the full claim. Do not infer it from a part mark alone.

For each case, start with the maker’s limits. Then add board and case tests. Add tests with the real code. Add a rig or hardware-in-the-loop test when it fits. End with the real vehicle and site cases needed by the claim.

Keep each source of proof named. A datasheet row is not a bench result. A bench result is not a road result. A supplier note is not a safety sign-off. This makes gaps plain before the release meeting.

Check the supply path too. Ask who made the part, where it was built, how long it will be sold, and what notice comes before a change. A replacement with the same short name may have a new die, package, test, or build.

End with a one-page part record. Name the vehicle job, part, grade, limits, source files, tests, faults, open gaps, owner, and change rule. Link each claim to the proof that supports it. Mark the claims that still need expert review.

Read every limit with its test terms. A top heat value may apply for a short time or only at low load. A time value may depend on power, mode, or bus speed. Keep those terms beside the number.

Check the fault words too. “Detects a fault” does not say what the full system does next. Name how the fault is sent, how fast it is found, what the user sees, and which safe state follows.

Do not hide a gap with a broad phrase such as “car grade.” Name the exact grade, test set, and part. Then name the extra board, code, vehicle, and safety proof still needed.

Ask a second reviewer to trace one claim. They should find the limit, test terms, source file, full-system check, owner, and open gap. If the trail breaks, the part is not ready for that claim.

Keep the trail short. Use links to the real files. Mark old proof. Run the needed test again after a change.

Picture a sensor proposed for a vehicle environment where heat, vibration, EMC, diagnostics, supply variation, and lifetime all matter. Automotive datasheet review starts with the vehicle claim and mission profile, then checks which rows support qualification, integration, supplier evidence, bench tests, and the release decision. The datasheet helps the case; it is not the whole case.

The mathematical gist. A catalog-typical 3.00 bar TPMS case bends a 25.0 µm silicon diaphragm by 1.22 µm and produces 488 µε edge strain. With gauge factor 100 and 3.0 V excitation, the simplified bridge gives 146 mV. Separately, a 220 mAh, 3.0 V cell stores 0.660 Wh and retains 86.0% after ten years at 1.5% annual self-discharge.

Math Bridge · guided foundationsHow does tyre pressure become a voltage and a ten-year claim?Let Blueprint Bina follow diaphragm strain, bridge output, cell energy, and self-discharge without mixing the two chains.

26.6 Learning Objectives

By the end of this chapter, you will be able to:

  • Read an automotive sensor datasheet as evidence for a specific vehicle function, not as a generic feature list.
  • Distinguish component qualification evidence from system safety evidence.
  • Check AEC-Q qualification, temperature grade, lifetime, EMC, environmental, interface, and diagnostic claims.
  • Build a release packet for seat, crash, TPMS, and ADAS sensing examples without relying on unsupported cost or performance shortcuts.
  • Identify residual risks that require bench, HIL, vehicle, supplier, or certification evidence beyond the datasheet.

26.7 Qualify Vehicle Claim, Not Part

An automotive sensor datasheet answers a narrower question than the release meeting asks. It can show component limits, interface timing, package ratings, diagnostics, operating temperature, and qualification status. It cannot prove that a seat-occupancy warning, crash decision, TPMS warning, or ADAS feature is safe in the vehicle.

Read the datasheet through the vehicle claim. A cabin comfort sensor, wheel-mounted TPMS module, bumper radar, and restraint-system accelerometer live in different mission profiles. The same row can be acceptable in one location and unacceptable in another because temperature, vibration, moisture, electromagnetic exposure, lifetime, mounting, and service access change the interpretation.

Inspect the figure Figure 26.1 before carrying Qualify Vehicle Claim, Not Part forward. Vehicle Claim and Safety Context identify the evidence boundary implicit in Automotive datasheet review turns component rows into qualification evidence only when they are tied to a vehicle claim and integration evidence.

Six-stage automotive datasheet qualification route from vehicle claim through safety context, mission profile, component qualification, integration evidence, and release packet.
Figure 26.1: Automotive datasheet review turns component rows into qualification evidence only when they are tied to a vehicle claim and integration evidence.

For Qualify Vehicle Claim, Not Part, the visual sequence in Figure 26.1 opens with Vehicle Claim, where it uses Vehicle Claim to state a required condition. Safety Context follows to show how it highlights Safety Context; Mission Profile then highlights Mission Profile. That progression connects Automotive datasheet review turns component rows into qualification evidence only when they are tied to a vehicle claim and integration evidence to the next Qualify Vehicle Claim, Not Part check.

The route starts by naming the function: comfort control, advisory warning, diagnostic reporting, closed-loop control, or safety-relevant decision. That choice changes the evidence burden. A cabin temperature reading may need supply tolerance, airflow, response time, and user-comfort checks. A TPMS pressure reading adds battery derating, wheel-temperature exposure, RF link evidence, regional frequency variants, and missed-message behavior. A radar or crash-sensing path adds latency, synchronization, diagnostics, plausibility, redundancy, scenario evidence, and a safety-analysis boundary.

The practical habit is to separate proof layers before the team chooses a part. The datasheet may support a component claim such as range, grade, package, diagnostic flag, or interface timing. The assembled ECU and harness must then prove power sequencing, bus timing, timestamping, fault reactions, current draw, EMC behavior, and mechanical mounting. The vehicle program must decide hazard context, release risk, service strategy, monitoring, and supplier-change response. Keeping those layers separate prevents a qualified component from being promoted into a full vehicle claim.

  • Component claim: AEC-Q status, grade, package, operating limits, diagnostics, and supplier controls support the selected component.
  • Integration claim: The ECU, harness, connector, supply, bus timing, firmware diagnostics, and mechanical mount preserve the datasheet assumptions.
  • Vehicle claim: ISO 26262 work, scenario validation, HIL, EMC, environmental testing, and release governance decide whether the function can ship.

26.8 Build Automotive Qualification

Start the review with a one-line claim such as “wheel module reports under-inflation for the regulatory warning” or “front radar supports adaptive-cruise object tracking.” Then attach the datasheet rows that either support or block that claim. Useful rows include recommended operating conditions, absolute maximum ratings, accuracy across temperature, supply range, startup timing, current modes, interface timing, diagnostic flags, package notes, lifetime notes, and product-change controls.

Use real automotive evidence names. AEC-Q100, AEC-Q101, AEC-Q103, AEC-Q104, or AEC-Q200 can matter depending on the component family. ISO 26262 introduces hazard analysis, ASIL allocation, safety mechanisms, FMEA, FMEDA, and verification responsibilities. ISO 16750 covers vehicle environmental and electrical-load context; ISO 11452 and CISPR 25 shape EMC immunity and emissions discussions. IATF 16949, PPAP, approved vendor lists, and supplier change notifications may shape production control. None of those labels replaces measured behavior on the final board.

Write the qualification thread as an evidence table, not as a copied datasheet. For each row, record the condition attached to the number. A pressure accuracy row without temperature, compensation, and calibration conditions is not enough for a TPMS claim. A radar range row without target assumptions, field of view, mounting, radome material, weather limits, update rate, and timestamp behavior is not enough for ADAS. A self-test row without ECU fault reaction, diagnostic trouble code behavior, degraded-mode policy, and fault-injection evidence is not enough for a safety mechanism.

The release packet should be reproducible. Name the supplier document revision, component orderable part, ECU hardware revision, firmware commit, bus configuration, calibration file, bench setup, HIL scenario set, EMC pre-scan result, environmental profile, waiver owner, and retest trigger. If a claim depends on a typical value, mark it as a risk unless the final board measurement proves the margin. If a claim depends on a supplier declaration, link the declaration and name who checks product-change notices before the next build.

  1. Map the location. Cabin, seat, wheel, under-hood, bumper, and windshield locations imply different thermal, vibration, moisture, chemical, and EMC assumptions.
  2. Map the interface. CAN FD, LIN, SENT, PSI5, SPI, I2C, UART, and Automotive Ethernet have different timing, diagnostic, connector, harness, and logging consequences.
  3. Map the release evidence. Pair the datasheet row with schematic review, rail capture, bus trace, self-test log, fault-injection result, EMC pre-scan, HIL scenario, vehicle test, supplier document, or waiver owner.

26.9 Why Datasheet Rows Fail in Cars

Vehicle installations break generic assumptions because the sensor is part of a distributed electromechanical system. A TPMS pressure sensor may meet its pressure and current rows at room temperature, but the service-life claim still depends on RF transmit current, sleep leakage, battery chemistry, wheel temperature, wake strategy, LF trigger behavior, regional 315 MHz or 433 MHz variants, and missed-message handling. A radar module may meet range and update-rate rows, while the feature still depends on bumper material, radome contamination, calibration, time synchronization, object tracking, and fusion confidence.

The hidden boundary is usually state ownership. The component owns some internal measurement and diagnostic state. The ECU owns power sequencing, register configuration, bus scheduling, DTC handling, timestamping, plausibility, and degraded-mode behavior. The vehicle program owns hazard analysis, PPAP or part-approval flow, supplier change notification, service strategy, cybersecurity assumptions, and release acceptance. A credible datasheet review keeps those owners separate.

Electrical and timing margins are another common failure path. A sensor can satisfy its recommended operating conditions while the assembled board violates startup sequencing, ground offset, pullup sizing, bus loading, interrupt polarity, sample timestamping, or reset recovery. A LIN or CAN FD message that looks correct on a bench trace may still miss the diagnostic timing budget after gateway load, sleep transitions, clock drift, or fault handling. A SENT or PSI5 path may need different capture evidence from a register-based SPI or I2C sensor because the diagnostic and timing information is carried differently.

Environmental and EMC evidence also changes the meaning of a row. Temperature range does not prove calibration drift in the installed package. Shock survival does not prove mounting integrity after a vehicle event. EMC immunity guidance does not prove the harness, connector, filtering, shielding, and software recovery path. A datasheet note about diagnostics does not prove diagnostic coverage against the system hazard unless the fault is injected and the ECU reaction is observed.

That separation prevents two common failures: promoting an AEC-Q component into a system-safety claim, and treating a typical-value lab demo as a vehicle lifetime claim. The correct output is a bounded selection rationale with unresolved assumptions named before release pressure makes them invisible. The strongest reviews preserve the negative space: claims not made by the datasheet, measurements not yet taken, supplier evidence not yet received, and vehicle behavior still waiting for HIL, EMC, environmental, track, road, or fleet evidence.

In 60 Seconds

Automotive sensor selection is a qualification workflow. A datasheet can support claims about component limits, interface timing, temperature grade, diagnostics, package, and qualification status. It does not by itself prove a whole vehicle function is safe. For automotive work, connect each datasheet row to the vehicle claim, safety context, environmental mission profile, EMC exposure, interface requirements, bench evidence, supplier evidence, and final release decision.

26.10 Prerequisites

You should already be comfortable with:

26.11 What This Chapter Adds

Automotive datasheet review adds qualification pressure. The question is not only “does the sensor measure the value?” The question is “can this component support this vehicle function under the required safety, environmental, electrical, EMC, lifetime, diagnostic, and supplier-control assumptions?”

Function

Start from the vehicle claim

Seat occupancy, crash detection, TPMS, radar, or camera support different evidence needs.

Qualification

Check automotive status

AEC-Q qualification, temperature grade, package, and supplier controls support component use, not the full safety case.

Environment

Use a mission profile

Temperature, vibration, humidity, supply transients, EMC, and lifetime must match where the sensor is installed.

Release

Record residual risk

The release packet should name what the datasheet proves and what bench, HIL, vehicle, or supplier evidence still covers.

An AEC-Q qualified device can still be misused. ISO 26262 safety work depends on the vehicle function, hazard analysis, diagnostics, software, integration, failure handling, and verification evidence. The datasheet is one input to that evidence record.

26.12 Automotive Datasheet Qualification Route

Use the qualification route introduced in the overview as the chapter’s evidence spine: vehicle claim, safety context, mission profile, component qualification, integration evidence, and release packet.

26.13 Continue to the Next Part

Carry this evidence into Automotive Qualification: Evidence Gates, which begins with Bound Datasheet Claims.