← Back to context

Comment by brk

3 years ago

It is clear that automakers are utterly failing at technology.

In-vehicle control systems are typically garbage.

Several hacks have been shown where vehicle data is exposed over cellular links, in some cases with remote attackers being able to actually control elements of the vehicle (eg: Jeep).

Software updates are rare, with manufacturers often trying to charge exorbitant amounts for basic updates.

Data breaches of various customer data, credentials, PII, etc. are repeated.

IMO we are at the point where in-vehice technology is a thing that is never going away. Auto manufacturers need to become bona-fide software developers and take development, QA, cyber security, etc. far more serious than they have so far.

So I don't work in automotive domain, but I work in Controls Engineering. Basically everything you just said relates to my work as well, and based on tidbits of anecdotal info I've picked up through various technical forums it sounds like automotive & controls are quite similar in that regard.

The dirty truth is often times these domains were designed and chiefly operated by non-software people. Not to say a mechanical engineer or electrical engineer can't program, it's just that their focus is on their work, and the software is but a tool to accomplish those means. So the world of software has leapfrogged over PLC and automotive design and gone to run laps around it several times since the 90s. It's only in say the last 5 years or so that I've seen a cultural shift in controls towards embracing the modern realities of software, networking, security, version control, databases, etc.etc.etc.

I'm not going to go too much further into this, but this is why Software Engineering as a regulated profession is going to be a necessity as much as civil engineering or electrical engineering has been. The digital world is just too vast and complex now with so many pitfalls for those who only ride the edges can handle. And people's lives are starting to matter. It is no longer safe to treat security as secondary with an "oopsy" anymore. We don't tolerate bridge collapse or electrical design that can destroy livelihoods, why do we still tolerate hacks governing data and safety of public?

  • > Software Engineering as a regulated profession is going to be a necessity as much as civil engineering or electrical engineering has been

    Wouldn’t it be easier to regulate the quality of software used in critical products?

    AFAIK similar regulatory standards and certifications exist for aerospace software.

    • It technically exists:

      ISO26262 - "Road vehicles – Functional safety"

      But it's not nearly as prescriptive as what you have in DO-178C for example.

      Nevertheless most of these telematics systems are not "considered" safety-critical in a hazard analysis unless you have OTA updates or something similar so large chunks of of 26262 would also not be applicable.

    • >Wouldn’t it be easier to regulate the quality of software used in critical products?

      Sure, but who is responsible/accountable?

      Often times I bring this topic up to have a bunch of people looking for gotchas in my overly broad wishful thinking. I don't want Engineers to be a requirement to work in software as a whole. I don't even think being an "Engineer" makes you better in any functional way than your peers. But I do believe in ideas of accountability, responsibility, ownership, and all the legalese involved with taking that seriously.

      If the software is holding people's personal info, say to the point where a leak would constitute real risk, I want a Software Engineer stamping the security design to show they follow best practices and the company isn't taking shortcuts. If the software is controlling a robot that could maim someone, I want to know that some intern wasn't the one signing off to say its safe.

      We aren't there yet. And there's lots of work that needs to be done to get us there. I recognize that. But I want to keep putting the bug in people's ears to have that thought for the years that come as we watch more software glitches cause harm to people, to the environment.

  • this is why Software Engineering as a regulated profession is going to be a necessity as much as civil engineering or electrical engineering has been

    Unfortunately the challenge with this is still the same as always: do we even know how to engineer software, in the sense that established engineering disciplines use the term, yet?

    If we started permitting only “qualified” software engineers to make the big technical decisions, who would decide on the required qualifications? Would it be the few experts who really have spent whole careers successfully developing genuinely high-reliability software in industry or researching innovative techniques for improving quality in academia? Or would it be people like career consultants who write popular books on “best practices” and give keynote speeches at conferences with big name sponsors?

    The dominant trend in the software industry for years has been towards short-termism and ad-hoc everything. That often makes sense as a business strategy, at least given the current financial incentives, but it’s not necessarily the best way to promote robustness, predictability and longevity. Prematurely trying to codify accepted practices for engineering software might end up entrenching the status quo, when what is really needed as software eats the world is disruption by people who have demonstrably figured out better ways to do it.

    So while I strongly agree that we need to raise standards in parts of the industry where Very Bad Things can happen when software fails, I don’t think regulating software engineering in the same way as more established engineering disciplines is a viable way to do that. Not yet, at least.

> Auto manufacturers need to become bona-fide software developers and take development, QA, cyber security, etc. far more serious than they have so far.

Follow the money.

Their core business depends on the sale of a manufactured good, software is not the product. Software in Automotive is a cost centre.

They will absolutely contract out to the lowest bidder (coincidently probably the least capable). Cost downs in BOMs/features are trimmed to the cent because they are manufacturing in volume so manufacturing cost per unit is King.

What we define as sane Software best practices™ is a result of an industry were Software or services via software are in fact the product.

Also people won't vote with their wallet because we absolutely post-rationalize features and UX in a car. Most people don't realize or won't admit how reptilian their decision process goes in buying a car it's 80% "do I like the looks of it" and 20% the price tag.