Why the Cheapest Sensor Is Rarely the Cheapest Sensor: BOM Decisions That Haunt Programs

Every ADAS program eventually has the meeting where a sensor decision comes down to a spreadsheet, and the spreadsheet has one column everyone can read: piece price. I’ve sat in that meeting from both sides, as the systems owner defending a more expensive sensor, and as the person running BOM and cost optimization initiatives with Tier-1 suppliers to drive that number down. Here is what fifteen years of building perception algorithms, and then sourcing, qualifying, and shipping the sensors they run on, has taught me. The unit price on the BOM line is the most visible number in the decision and often the least meaningful one, because the real cost of a sensor is paid at end-of-line, in the qualification lab, in the thermal design of the module next to it, and in year six of production, and almost none of that appears in the quote.

To be clear about what I’m arguing, this is not a case against cost discipline. Cost discipline is how vehicles stay affordable and how ADAS features reach mid-trim cars instead of staying flagship toys. It’s a case against measuring cost in one column. When a program picks the cheapest quote without pricing calibration time, qualification risk, integration burden, supply longevity, and performance margin, it hasn’t saved money. It has moved the spend somewhere less visible, later in the program, where it’s more expensive to pay.

Why piece price wins arguments it shouldn’t

Piece price dominates sensor decisions because of how programs are organized, not because anyone is careless. It is the one cost that is legible to everyone in the room: purchasing can benchmark it, finance can multiply it by volume, and program management can report the delta in the next cost review. A ten-dollar saving on a sensor across half a million vehicles is five million dollars, and that number fits on a slide.

The competing costs don’t fit on a slide. Calibration time is owned by manufacturing engineering. Requalification risk is owned by the component engineer. Thermal and packaging consequences are owned by whoever integrates the module. Software compensation for a marginal sensor is owned by the perception team, two organizations away. Each of these costs is real, but each is diffuse, deferred, and charged to someone else’s budget line. So the RFQ scoring rewards the one number that is concentrated, immediate, and charged to the line everyone is staring at.

The implication is blunt. If your sourcing process scores piece price explicitly and everything else implicitly, you have already decided to buy the cheapest sensor. The rest of the evaluation is theater. Fixing that isn’t a purchasing problem. It’s a systems engineering problem, and it’s why sensor sourcing belongs partly in engineering hands, not handed over the wall.

Calibration is a per-vehicle tax, forever

Of all the hidden costs, end-of-line calibration surprises programs most, because it converts a sensor property into a manufacturing property. A perception sensor doesn’t ship when it’s mounted; it ships when it’s calibrated: intrinsics, extrinsics, alignment to the vehicle frame. How long that takes, what fixtures and targets it needs, how often it fails and sends a vehicle to rework, all of that is determined largely by choices made at sensor selection, and all of it is paid on every single vehicle for the life of the program.

Do the arithmetic that rarely makes it into the RFQ. If sensor A needs an extra thirty seconds of station time per vehicle compared to sensor B, then at any serious line rate you are eventually buying floor space, fixtures, possibly a parallel station, and takt-time margin, a recurring manufacturing cost that can quietly rival the piece-price delta you celebrated. And that’s the good case, where calibration succeeds. First-pass yield at the calibration station is the number I’d ask about before I’d ask about price, because every failed calibration is a vehicle off the line and a technician investigating.

I’ve also seen the inverse, which is the point. On one program, redesigning the calibration process and altering the manufacturing-line procedure for a new radar platform produced approximately six figures in savings, not by touching the sensor’s piece price at all, but by cutting manufacturing complexity and time. The savings were sitting in the process, invisible to a BOM review, larger than most piece-price negotiations ever yield. The piece price never moved, yet the program’s real cost did.

So make calibration a quoted item. Ask suppliers for the end-of-line procedure, station time, target and fixture requirements, and expected first-pass yield, and score them. A supplier who can’t answer those questions is telling you something important about how production-ready their sensor is.

Qualification failures are schedule, and schedule is money

Automotive sensors live in an environment that consumer parts never see, and the qualification regime reflects it: temperature cycling across the −40 °C to +85 °C range and beyond depending on mounting location, vibration profiles, humidity exposure, EMC/EMI. This is the territory covered by frameworks like the ISO 16750 series for environmental conditions and testing of E/E equipment, and at component level by AEC qualification standards such as AEC-Q100 and AEC-Q104 for ICs and multichip modules. On a robotaxi program I defined these environmental qualification and reliability requirements for imaging radars, and the experience left me with a firm opinion. The cheapest sensor is disproportionately likely to be the one that has never been through this gauntlet, and finding that out late is one of the most expensive discoveries a program can make.

Here’s why the cost asymmetry is so brutal. A qualification failure isn’t a line item; it’s a loop. The supplier root-causes, redesigns (a connector, a conformal coating, a board layout), and then you don’t just retest the fix, you restart the affected qualification sequence, because that’s what the evidence for your safety case and your production release requires. That loop is measured in months. If it lands in the wrong part of the program, it doesn’t cost you a requal budget; it costs you a launch date, and everything downstream of a launch date.

The tell, in my experience, is in the RFQ responses. Suppliers who have shipped automotive volume answer environmental qualification questions with data: test reports, DFMEA history, field return rates. Suppliers whose price looks too good to be true answer with intentions. Part of the price difference between them is exactly that. One of them has already paid for the failures you would otherwise pay for. When I benchmark candidate sensors in the field (rain, fog, snow, the conditions that separate a datasheet from a product), I’m not only testing detection performance. I’m testing whether the engineering culture behind the sensor has ever met the real world.

Watts, millimeters, and degrees are somebody else’s BOM

A sensor’s price sits on one BOM line, but its physical properties spend money across the whole vehicle. Power consumption becomes heat, and heat becomes heatsinking, airflow provisions, or derating strategy. Module size becomes bracket design, fascia accommodation, and constraints on mounting position, which for a perception sensor is not cosmetic, because mounting position is field of view, and field of view is system performance. A sensor that’s cheap because it’s big, hot, and power-hungry is a sensor whose true cost is scattered across the thermal, mechanical, and electrical budgets of everyone around it.

I spent a stretch of my career running this trade at an EV OEM, where the wins came as reductions in module size, power consumption, and thermal footprint. The lesson from that work is that these parameters aren’t secondary specs. They are what determines whether a sensor scales across vehicle architectures or has to be re-engineered for each one. A module that integrates cleanly into three vehicle programs amortizes its engineering three ways. A cheaper module that needs bespoke thermal and packaging work per program un-amortizes itself immediately. On an EV specifically, sustained power draw is also range, and range is money the customer can see.

The rule I take from this is to evaluate sensors at the module-in-vehicle level, not the component level. The question worth asking is not “what does this sensor cost?” but “what does the vehicle cost with this sensor in it?”

The sensor has to outlive its own silicon

A vehicle program is a long relationship. Production runs for years; service and warranty obligations run for a decade or more after that. Meanwhile, much of the electronics industry turns over its products on consumer timescales, which is exactly why automotive semiconductor vendors maintain formal longevity commitments, such as NXP’s product longevity program guaranteeing 15 years of availability for automotive products. A sensor built on short-lifecycle silicon, from a supplier without those commitments, is a sensor with an end-of-life notice already in the mail. And an EOL on a qualified, calibrated, safety-relevant sensor lands as far more than a purchasing inconvenience: a redesign, a requalification, potentially a recalibration procedure change, and a change-management exercise through your entire traceability chain.

The 2021–2022 semiconductor shortage made the supply side of this impossible to ignore. AlixPartners estimated the shortage cost the auto industry $210 billion in lost revenue in 2021 alone, with some 7.7 million vehicles unbuilt. Programs discovered that a supplier’s allocation position, second-source strategy, and component lifecycle policy were worth more than any piece-price concession. The cheapest quote from a supplier with a fragile supply chain isn’t a price; it’s a bet.

So put longevity in the contract, not in the hope: component lifecycle disclosures, PCN and EOL notice terms, last-time-buy provisions, and a stated position on second sourcing. These clauses cost nothing at signing and everything if they’re missing.

Margin you don’t buy in hardware, you pay for in software

The subtlest cost is performance margin. Two sensors can both “meet spec” while being very different products. One meets it with headroom across temperature, aging, and unit-to-unit variation; the other meets it on a bench at room temperature with a golden sample. The datasheet won’t tell you which one you’re buying. Field testing will, which is why I’ve never signed off a sensor selection on datasheet numbers alone.

When you buy the marginal sensor, the missing margin doesn’t disappear. It moves into your perception stack. The fusion layer grows compensation logic. Tracking thresholds get tuned per corner case. The validation team spends cycles characterizing behavior that a better sensor simply wouldn’t exhibit. And when you build the safety case, every one of those compensations is a branch in the argument you now have to defend with evidence. Engineers’ time spent absorbing a sensor’s weaknesses is the least visible and one of the largest costs on this whole list; it just gets booked as “software development” instead of being attributed to the sourcing decision that caused it.

None of which makes software compensation wrong. Buying cheaper sensors and spending the difference on compute and better algorithms is a legitimate architecture, and on some programs it is the economically correct one. The distinction I care about is whether that trade was chosen or inherited. A team that decides up front to carry a sensor’s limitations in software budgets the compute, staffs the work, and defends it in the safety case deliberately. A team that discovers after sourcing that it now owns a compensation problem is doing the same engineering without having priced it. Same code, very different program.

”But piece price is the cost that scales”

The strongest objection to everything above goes like this. At automotive volume, piece price is the cost that scales. Hidden costs are mostly fixed or one-time. A requal loop hurts once; a piece-price delta hurts on every vehicle, forever. A disciplined program should therefore optimize the recurring number and manage the one-time risks. That objection is right about the math, and it deserves a real answer.

It also deserves a concession first, because purchasing has heard this argument before and has watched it be abused. Engineers overspecify, myself included. We argue for detection range no feature ends up using, for temperature grades the mounting location’s thermal profile does not call for, and for resolution that matters on a test track and nowhere a customer would notice. “The expensive part is safer” is sometimes engineering judgment and sometimes a preference wearing a risk argument as a costume, and the people across the table are usually better at telling the difference than we credit them for. So the case I’m making is not that engineering should win the sourcing argument. Lifecycle cost is the referee, and it calls fouls on both sides: the sensor that looks cheap only until its costs surface three departments away, and the specification that looks rigorous only until someone asks which requirement it serves.

The answer has two parts, and they should be kept separate, because the costs on my list are not all the same kind of number. Some are as deterministic as piece price. Calibration station time is per-vehicle, forever, and you can quote it to the second. Power draw is per-vehicle, forever. Module size and thermal load convert into fixed engineering at a known rate. These belong in the recurring column alongside piece price, measured the same way. Most RFQs simply leave them out, which is an arithmetic error and fixable as one.

The rest are probabilistic: qualification failures, EOL notices, allocation shortfalls, warranty events. These deserve risk-adjusted treatment, not the same column, and I’d rather see a program estimate them explicitly and badly than carry them as an unpriced assumption. A ten percent chance of a six-month requal loop is a real number even when it is a rough one.

Where price enters is in the correlation, and I want to state it carefully because it is easy to overclaim. A low quote is not evidence of a weak sensor. Suppliers are cheaper for entirely sound reasons: scale, vertical integration, platform reuse, a simpler architecture, thinner margins, regional cost structure. I have seen enough of them, though, to treat an unusually low quote as a question rather than a bargain, because often enough it arrives with immature validation, thin engineering support, or short-lifecycle components attached. That correlation is worth pricing rather than assuming away. The recurring-versus-one-time frame holds up fine. It just gets applied with the recurring column half empty and the risk column blank.

What I’d put in the RFQ instead

The practical fix keeps price at the center of the decision and changes what price means: make the RFQ compute the cost per qualified, calibrated, integrated sensor over the program’s life. Each hidden cost above becomes a quoted, weighted line item, scored rather than assumed, instead of a surprise that lands after sourcing. Having run RFI/RFQ processes for radars on programs from EV platforms to robotaxis, I can say the suppliers worth having welcome this. It lets them compete on the value they’ve actually built instead of being dragged into a price war against sensors that will fail you later.

Three takeaways, one per audience level. For engineers, fight for calibration, qualification, and margin data during selection, because you are the one who will pay for their absence, in your own hours. For program managers, any cost comparison that fits on one slide is missing most of the cost; ask what the per-vehicle manufacturing and integration deltas are before approving the “cheap” option. And for the executives who own the sourcing gate, the cheapest sensor and the lowest-cost sensor are different parts. Programs that learn this in the RFQ phase learn it for the price of a longer spreadsheet. Programs that learn it at end-of-line, in the qual lab, or in an EOL notice pay full freight, and I’ve watched that invoice arrive too many times to believe the piece-price column again.