3 ms·

> That would be a bug-free system, which is impossible. Why? If the rest of the car can function within design specifications for years, why can't the firmware

by v9v 1y ago

> That would be a bug-free system, which is impossible. Why? If the rest of the car can function within design specifications for years, why can't the firmware? I'm fine with updates to add compatibility with new protocols and such, but to me a bug implies there's a standing problem with the current system that's not due to some sort of wear/changing standard/component damage etc. While one can point to examples of cars with defective mechanical designs, I don't think anyone considers it impossible to create designs without such defects (where defects are defined wrt. specifications), why is this the view in software engineering?

AlotOfReading 1y ago
The rest of the car doesn't function within specifications for years. That's what recalls are fixing. These days, a lot of software recalls are being issued to work around physical design "bugs". The Tesla cybertruck frunk pinching issues are a well-publicized example. But, do you have an example of a software project anywhere that's bug-free? I'd include the space shuttle code, but even that famously high quality development process produced a (low) number of bugs.
- jmb99 1y ago
  Not open source but mostly reverse engineered, and automotive: the PCM code for GM’s LT1 engines. The only thing that could be considered a bug is the behaviour of wide-open throttle fuelling, which was completely acceptable from the factory but made aftermarket tuning a bit tricky. Specifically, the fuel calculation routine would use the most recent BLM (short- and mid-term air-fuel ratio correction factory as measured by the O2 sensors) when calculating fuel delivery when wide-open, rather than locking it to a constant; the “most recent BLM” may be for a completely different area of the tune (like mid-RPM low throttle), where things like vacuum leaks or even just intake runner inefficiencies have a much greater affect on AFRs than when wide-open. This can result in either too much or too little fuel being injected, and under- or over-shooting the target AFR. The reason for this is a physical limitation: the cars weren’t shipped with wideband O2 sensors, so there’s no way to measure the AFR when wide-open (since it’s targeting a significantly richer mixture, and narrowband O2 sensors can only signal whether a the combustion is stoichiometric, or rich or lean relative to stoichiometric, with no further info). The implantation is probably not a bug but rather a compromise; in an ideal world, the “most recent” BLM will hopefully be from an “almost wide open” part of the map, and the general rich/lean characteristics will be close enough. And, the fuel table in the factory tune is quite safely rich when wide-open, so even with a leaking injector causing the idle BLMs to be way off, the fuel being pulled when wide open will still be completely safe. Aside from that, 128k of bug-free code.

by v9v 1y ago

AlotOfReading 1y ago

The rest of the car doesn't function within specifications for years. That's what recalls are fixing. These days, a lot of software recalls are being issued to work around physical design "bugs". The Tesla cybertruck frunk pinching issues are a well-publicized example. But, do you have an example of a software project anywhere that's bug-free? I'd include the space shuttle code, but even that famously high quality development process produced a (low) number of bugs.

jmb99 1y ago
Not open source but mostly reverse engineered, and automotive: the PCM code for GM’s LT1 engines. The only thing that could be considered a bug is the behaviour of wide-open throttle fuelling, which was completely acceptable from the factory but made aftermarket tuning a bit tricky. Specifically, the fuel calculation routine would use the most recent BLM (short- and mid-term air-fuel ratio correction factory as measured by the O2 sensors) when calculating fuel delivery when wide-open, rather than locking it to a constant; the “most recent BLM” may be for a completely different area of the tune (like mid-RPM low throttle), where things like vacuum leaks or even just intake runner inefficiencies have a much greater affect on AFRs than when wide-open. This can result in either too much or too little fuel being injected, and under- or over-shooting the target AFR. The reason for this is a physical limitation: the cars weren’t shipped with wideband O2 sensors, so there’s no way to measure the AFR when wide-open (since it’s targeting a significantly richer mixture, and narrowband O2 sensors can only signal whether a the combustion is stoichiometric, or rich or lean relative to stoichiometric, with no further info). The implantation is probably not a bug but rather a compromise; in an ideal world, the “most recent” BLM will hopefully be from an “almost wide open” part of the map, and the general rich/lean characteristics will be close enough. And, the fuel table in the factory tune is quite safely rich when wide-open, so even with a leaking injector causing the idle BLMs to be way off, the fuel being pulled when wide open will still be completely safe. Aside from that, 128k of bug-free code.