[adhesive_wombat]

Open to scrutiny, absolutely. Anything safety-critical should be freely available to those it can harm. Cars, trains, planes, nuclear reactors, lathes, the lot. I hope your code and schematics is fully provided to worker relying on it being correct. I indeed don't have faith in regulators auditing it properly.

That said I still don't want someone to plonk some GitHub code into the brake controllers, take it for a spin and turn me and mine into meat salsa.

On private land, surrounded by informed and consenting people, sure, go nuts.

[jacquesm]

> That said I still don't want someone to plonk some GitHub code into the brake controllers, take it for a spin and turn me and mine into meat salsa.

The chances of that happening, versus brake fluid contamination, bad lines, seized rotors, rusted rotors, rotors and pads with grease on them and a thousand other mechanical failures are nil. Because brake controllers are always backed up by a mechanical system and the worst thing about a brake is that it could fail.

The bigger problem is that manufacturers that could barely create functional entertainment systems are now actually creating software and hardware combos that can override driver input to the steering wheel and the brakes and in my own experience they are absolutely not qualified to do this. Car software is crap, you can take my word on that. Very, very few manufacturers have software as a core competency.

[elzbardico]

Please define car software.

You have user facing functions, and you have engine control functions, ABS, transmission, and so on.

The first one, I agree, is generally crap.

For the second one, in a lot of models, your manufacturer haven't even written the code, because they buy it from some OEM manufacturer like Bosch.

And I am pretty sure that Bosch is pretty good at writing this kind of software.

[jacquesm]

> Please define car software.

The totality of all code running on a particular vehicle that was part of that vehicle when it was sold to the end user.

> You have user facing functions, and you have engine control functions, ABS, transmission, and so on.

Yes.

> The first one, I agree, is generally crap.

Ok.

> For the second one, in a lot of models, your manufacturer haven't even written the code, because they buy it from some OEM manufacturer like Bosch.

That depends. If they buy a whole unit there is a chance it is 'stock', there is a chance that the firmware was modified by the manufacturer or there is a chance that development of the software is insourced. All of that depends on volume, cost, licensing, purpose.

> And I am pretty sure that Bosch is pretty good at writing this kind of software.

Based on what evidence?

[elzbardico]

The fact that I've been driving cars with ECUs since I was a teenager and never got stranded in the road because of a firmware bug, neither nobody else I know.

Compared with Amazon/Google/MSFT, this is a remarkable feat.

[jacquesm]

That's fair, embedded developers are a notch above the CRUD folks. Mostly because the hardware people tend to keep them sharp and won't accept any finger pointing unless there is a solid reason for it. But don't overestimate it either, without the watchdog timers embedded usually won't live long.

In general what keeps you safe is assumptions about failure modes that work out as long as everything stays within the set of parameters that define the working envelope of the device. But any combination of inputs that was unforeseen (and therefore not tested) is a possible source of surprises and if and when that happens embedded stuff has very little resilience.

The one piece of code that I wrote myself that had to pass certification for non-flying software that had the potential to crash aircraft and potentially kill people cost me 10x in time from what it would have cost if that were a non-regulated industry. And I'm the first to admit that this was the most humbling experience ever in terms of the number of issues found based on a very simple trick: dual development of the same software by a different set of programmers at some point in the past. Mine was the 'upgrade'. That old software was battle tested but on a platform that was EOL. Before I got mine to the same level of reliability the changelog was many, many pages long compared to my first attempt that I thought would pass the tests. Not so. Not by a long shot.

As for ECU's, they are relatively simple devices in terms of inputs and outputs, they are required to be utterly reliable because when you press the accelerator to cross an intersection those ponies had better be there. But that's mostly a result of many years of work on the software cores and just like any other old piece of code by now we've found most of the bugs.

The older - pre software - engine control units were massive chunks of hardware, look on the right hand side inside the passenger seat of 80's and late 70's era Mercedes and other German vehicles with fuel injection (and some Volvo and Citroen cars) for the kind of control unit that went into these cars. Just the component count and the number of adjustable parameters alone is enough to make you wonder how reliable that stuff is. And yet, work it did. But the modern ones are far more reliable, not because of software, but in spite of software. And even though they generally work the question I would like to see answered is how much of that is because of duct-tape and how much of it is because of solid engineering? Some people in the embedded world are of the opinion that it doesn't matter. But I think it does and I care enough that I'd like to see what makes this stuff tick. On the off-chance that there is a real bug or some unintended acceleration condition or a way to get the hardware to lock up lurking there that we simply haven't uncovered yet.

Given how prone car manufacturers are to stonewalling on this stuff my guess is: plenty of chance that that's the case.

[elzbardico]

Yes, now I can see your point. Haven't considered this in depth before. Maybe because we have so low expectations in software, when something mostly works without visible manifestations of failure we tend to consider it better quality than actually it was.

But, yes, the absence of failures should not be taken as proof of absence of bugs.