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