Car companies are in a billion-dollar software war

Original Article ↗ Hacker News Discussion ↗

Embedded expertise & industry culture

  • Many comments argue embedded-systems engineering isn’t widely taught or properly valued; training is rare, much work is outsourced to low‑cost vendors with weak C/RTOS skills.
  • Knowledge is trapped behind NDAs, proprietary chips and toolchains; people describe automotive and embedded as a “shadowland” with poor knowledge transfer compared to open-source web/software culture.
  • Pay and career incentives push capable engineers toward web/backend roles; some embedded engineers report good pay, but others say long‑term embedded careers usually lose financially vs JS/web work.

Legacy architectures vs “software-defined vehicles”

  • Traditional OEMs built cars as collections of 50–150+ ECUs from many suppliers; each ships its own firmware, protocols, and tools. Changing anything means negotiating with multiple vendors.
  • This fragmentation makes consistent behavior, fast updates, and good UX very hard; even “simple” features like windows, locks or lights can involve opaque, brittle interactions.
  • Newer players (Tesla, Chinese EVs, Rivian) and a few legacy OEMs are moving toward zonal architectures and a small number of powerful controllers, aiming to centralize logic and reduce wiring and supplier complexity.
  • Some commenters see “software-defined vehicle” as mostly a buzzword on top of this architectural shift; others think the architecture change is genuinely beneficial but way behind schedule at legacy firms.

OTA updates, reliability & safety

  • Strong disagreement on whether cars should ever need software updates:
    • One camp: bug‑free (or bug‑minimal) fixed firmware is achievable if you keep complexity down; older cars and some 80s–00s ECUs are cited as examples.
    • Another camp: modern vehicles are too complex; recalls and software workarounds for physical design flaws already exist, so updates are inevitable; OTA is cheaper, faster, and regulator‑friendly.
  • Some argue OTA encourages shipping unfinished products (“fix it later”), even for safety‑critical functions (e.g., braking calibration).
  • Others note OTA saves billions vs dealer reflashes, improves recall completion rates, and lets “small” bugs get fixed that previously would linger.

Connectivity, security & privacy

  • Many question why cars need full‑time internet at all; they prefer OBD-II or dealer-only updates and fear large-scale remote compromise of vehicles.
  • A recurring example is CAN-bus access via headlights or other external points allowing easy theft; some argue this proves the need for stronger internal security, others say the overall real‑world theft rate of “simple” cars stayed manageable without network firewalls.
  • EU eCall mandates LTE modules in new cars; critics see this as built-in tracking. Defenders say the SIM is dormant and only activates in a severe crash, but skeptics don’t trust unverifiable claims.
  • Overall, there’s deep distrust of OEM data collection and resale, and of remote-control capabilities (door unlock, start, etc.) being poorly secured.

UX, infotainment & driver distraction

  • Strong preference for physical buttons/knobs for HVAC, lights, seat heaters, etc. Touchscreen-only controls are widely called dangerous, especially when buried in menus or laggy.
  • Many want a minimal center screen that mostly runs CarPlay/Android Auto plus backup camera and basic config; everything else should be hard controls.
  • OEM infotainment software is seen as universally bad: slow, buggy, ugly, and quickly obsolete. Apple/Google projection is widely preferred; some refuse to buy cars without it.
  • ADAS and safety aids get mixed reviews:
    • Automated emergency braking, adaptive cruise, and lane-keeping are cited as statistically helpful and sometimes personally useful.
    • Others report phantom braking, misinterpreted obstacles, aggressive interventions on rural roads, and alert fatigue; several disable lane assist and sometimes front assist where possible.
  • Some fear integrated “drive-by-software” for steering/braking, arguing edge cases and unexpected interactions are not handled with aviation-level rigor.

Economics, talent, and outsourcing

  • Legacy automakers historically treat software as a cost center and are culturally uncomfortable paying market rates; core US operations reportedly offer ~mid‑100k to seniors while creating coastal “software hubs” with different pay bands.
  • Strategy often favors poaching high‑profile execs from tech companies instead of building strong engineering organizations; commenters say this is cheaper but ineffective.
  • Procurement culture optimizes BOM cost at cent‑level granularity (e.g., cutting RAM/flash on ECUs), pushing underpowered hardware that makes already‑bloated stacks intolerably slow.
  • Tier‑1 supplier layering (each with sub‑suppliers) leads to labyrinthine, overlapping proprietary stacks and protocols (AUTOSAR, custom CAN schemes, etc.), making integration and fixes expensive and slow.

Regulation, safety standards & right-to-repair

  • ISO 26262 is cited as the standard for safety-critical automotive software; commenters note steering/braking code is generally high quality and developed separately from infotainment.
  • Others push back: standards are just “pieces of paper” and don’t by themselves ensure trustworthy implementation; regulators mostly test against minimum FMVSS-like benchmarks, not best-in-class behavior.
  • OTA and centralized architectures raise questions about how updates interact with type approval and homologation, especially under UN/ECE-style regimes; several say this is under-addressed.
  • Strong sentiment in favor of right-to-repair and even open-source stacks for non‑safety‑critical systems (infotainment, HVAC, body controls). People want:
    • Access to firmware and tools,
    • The ability to replace locked-down modules (telematics, head units),
    • Clear separation between safety-critical domains and everything else.

Consumer preferences and “analog” backlash

  • A substantial subset explicitly wants:
    • No permanent connectivity,
    • No big touchscreens,
    • Analog dials and physical keys,
    • Simple, long-lived, user‑serviceable mechanical and electrical designs.
  • Some point to older cars, basic brands, or new “minimalist” concepts (like small EVs or stripped‑down trucks) as more appealing than heavily “software-defined” vehicles.
  • Others accept complex software but want improvement: better, coherent UX; faster hardware; strong sandboxing between infotainment and safety; and clear owner control over software and data.