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

[jacquesm]

I read a lot of closed source code and quite a bit of it embedded and some of the stuff you find is enough to make you question just about anything.

Here is a nice picture of a pre-digital ECU:

https://www.benzworld.org/attachments/75-djetecu_3-jpg.16183...

It's essentially a hardwired analog computer (note the lack of adjustment points other than 'idle RPM'), as long as the external contacts are clean, the components are good and within tolerance the unit should work. There is nothing to adjust.

Modern ECU's have many more sensors to deal with, so higher data rates and many, many more fault conditions that have to do with emissions and preventing engine damage, these old D-Jetronic units were very impressive for their time, plenty of them are still running today which given the parts count is a small miracle.

In a way they are so reliable because of what they can't do, as long as the input parameters are roughly where they should be and the crank position input is accurate the engine will run. But whether it will run efficiently or not is a different matter and accurately setting these up without the right gear and manuals is next to impossible. So most parties that repair these will do a 'so-so' job, good enough to get the car back on the road but far from optimal. But the old battle-axes that you'll find these units in never were models of fuel efficiency. In contrast to this a modern ECU has exactly zero analog processing beyond digitization, it's all software. And where at all possible that software is not engine (beyond type and pre-set config) or drivetrain specific (though they do tend to talk to the transmission to get more information about the driving conditions) because that would require a lot of extra work per engine.

The most that you'll find is that the ECU has some knowledge of the serial numbers of key components (for instance the drivetrain) to give some anti-theft protection. Other than that it's all auto-configuration until some parameter goes out of spec and then that expensive check engine light comes on.