Comment by TheCapn

3 years ago

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?

6 comments

TheCapn

Reply
spacebanana7  3 years ago

> 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.

  • DoingIsLearning  3 years ago

    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.

  • TheCapn  3 years ago

    >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.

Chris_Newton  3 years ago

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.