26 Automotive Qualification: Mission Profiles
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.
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.
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.
- Map the location. Cabin, seat, wheel, under-hood, bumper, and windshield locations imply different thermal, vibration, moisture, chemical, and EMC assumptions.
- Map the interface. CAN FD, LIN, SENT, PSI5, SPI, I2C, UART, and Automotive Ethernet have different timing, diagnostic, connector, harness, and logging consequences.
- 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.
26.10 Prerequisites
You should already be comfortable with:
- Specification Sheet Fundamentals: extracting limits, conditions, and assumptions from datasheets.
- Accelerometer Datasheet Case Study: turning one sensor datasheet into a decision packet.
- Sensor Selection Process: comparing candidate components against requirements.
- End-to-End Test Strategy: release gates, evidence records, and residual-risk handling.
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?”
Start from the vehicle claim
Seat occupancy, crash detection, TPMS, radar, or camera support different evidence needs.
Check automotive status
AEC-Q qualification, temperature grade, package, and supplier controls support component use, not the full safety case.
Use a mission profile
Temperature, vibration, humidity, supply transients, EMC, and lifetime must match where the sensor is installed.
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.
