[15155]

Expounding further - what government agency has the time or money to actually sift through mountains of source code?

From a pure financial standpoint, there's no possible way that it isn't cheaper to just measure real emissions than attempt some kind of software analysis for every version of every vehicle on the market.

Furthermore, an agency inspecting source code has absolutely no way to tell whether or not that the source they've been given is actually what's running on a car.

[lafay]

Just as a counterpoint: the Nevada Gaming Commission has plenty of time and money to sift through the source code of every gaming device that gets deployed in NV.

[ptaipale]

Compared to any car ECU and related software, gaming machine software is rather simple. Not exactly trivial, but much simpler, and the state can afford to set rather arbitrary behavioural restrictions.

Similar restrictions would severely cripple innovation in cars. Just consider Tesla's autopilot software.

[15155]

If I write the software for those devices in ASM, do/can they still look through it?

Is there some kind of formal engineering practice they require manufacturers to adhere to?

How are their staff qualified to read the vast variety of languages out there?

I cite these as immediate, obvious roadblocks to verification, regulation, because they're easy and many PLs are something that the vast majority of the software industry are not used to.

[stickfigure]

Do we have specific evidence that they actually do sift through the source code? They demand its submission, but how do we know they actually do anything with it? I'm asking this as a serious question.

[wfo]

It doesn't really matter if they sift through every one so long as they have them on record. If there's ever an allegation of misconduct, the code can be examined in full by any large variety of experts.

[granos]

If you have source code then you can tell whether a particular executable was built from said source code. Pull the executable out of the car and also build the source code yourself as instructed by the manufacturer, compare the two binaries.

If the binaries don't match, then whatever certification the device needs automatically fails and it cannot be sold.

What that means is that later on, if "Something Bad" happens, you are in a position to be certain of what code was running. This makes investigation much easier as there is no chance that the original source code cannot be found when needed later. This does get a bit more complicated with software updates, especially OTA updates.

[15155]

To me, this seems like a relatively difficult feat.

- Are governments and other regulatory agents going to formally verify compilers?

- Are these agencies going to prevent software from being written that doesn't conform to their rigid standards?

- Many compilers, technologies in use today aren't perfectly deterministic. Optimizations, flags, etc. can all dramatically affect an emitted binary.

- What if I want to use a completely different architecture than a regulatory agency is used to? Am I just not allowed to?

And as you mentioned, updates.

With the ability to do OTA or any other updates, software becomes almost impossible to identify or deal with.

[granos]

The point isn't for regulators to have to sift through code line by line or do something complicated like verifying compilers. I'd propose that the industry can pretty much do whatever they like in terms of technology, so long as it's inspectable and meets other regulations of course. If they can't provide repeatable instructions for building their code then they should not be working on something safety critical anyway.

I'm not familiar with exactly what software regulations exist today for the auto industry, but certifications for repeatable software processes (including build and deploy) are nothing new.

The point is that we should trust the industry to do the right thing, but also maintain our ability to double check. Until something like the VW defeat scandal happens it doesn't make sense to invest the resources needed to really dig in.

Updates and cheating can be detected by requiring service stations to pull software from randomly chosen vehicles during annual inspections. In the US we could use the standard highway funding threats to require states to enact such laws.

[structural]

In a similar vein, what government agency has the time or money to actually review every single diagram for a building to be constructed?

It's actually the same problem: an extremely complex object is being constructed, a critical failure within which could leave many people nearby injured or dead.

The solution is actually somewhat ingenious: License a small group of people to go analyze such things, let them organize themselves independently, but require them to sign off on the design. It turns out that with their license and livelihood on the line, enough people aren't willing to sign off on terrible, shoddy crap that the system mostly works.

Perhaps it's time that software grew up and became something closer to a real engineering discipline?

[15155]

> Perhaps it's time that software grew up and became something closer to a real engineering discipline?

Filled with red tape, inaccessibility, limitations?

No thanks. I think we've done a very decent job of self-regulation, licensure and review have fared well for most* life-threatening software systems.

[IshKebab]

You not only have to sift through the code, but compile and flash it yourself.