5 ms·

I don't think "more smart = less reliable" is inevitable. The goal should be designing it in a way that failure of the more smart features does not spill to cr

I don't think "more smart = less reliable" is inevitable. The goal should be designing it in a way that failure of the more smart features does not spill to critical functionality. Or that you can use it in a degraded state sort of like fly by wire planes do. I have no car design experience, but here is my 5-minute idea: For starters, you build a basic car. It drives, it has basic indicators, it has ABS, etc. It has some APIs that can be connected to but there is limited ability to break the basic car through those APIs. Then you build your smart car around it by adding to the basic car. You add on more computers, electronics, etc. But any time you rip off the smart car functionality, you still have the basic car working. If there is a need to update software, this should really only be needed for the smart car part. But even if it fails completely, the basic car underneath should be functional and you should be able to use the car albeit without infotainment and navigation and other "stuff". You should be able to do whatever you need to do, call your mechanic and limp there to get them to sort the problem out for you.

AlotOfReading 3y ago
That's not how vehicles are designed for many reasons. For one, there's no option where critical components aren't designed with updateability in mind. It's simply a fact of life that code has bugs, and the only way to fix those bugs is updates. It's valid to feel that that those updates should applied at a dealership where the system can be tested afterwards, but that has a lot of implications of its own.
- onetimeuse92304 3y ago
  You simply do not understand the point of extracting "basic car" from "smart car". The point isn't that the software will have no bugs. The point is that the basic car will have much less software and much more basic software and that it is much easier to test and ensure this software is in working condition. Also, it is absolutely not true that the basic software has to be updateable. With care, basic functionality can absolutely be completely finished. Imagine you have been in the market with ABS controller for a decade or more. It has really simple functionality, it should be possible to just bake it and never touch it again. Or maybe a controller that takes care of basic battery protection. Or motor ESC. When the components are simple enough and well defined enough, it should be possible to "finish" the software to a state where it never again needs to be updated. Or updated only in exceptional circumstances.
  - AlotOfReading 3y ago
    I have a very deep appreciation for simpler automotive components. Please don't take anything I'm saying as discounting those very real benefits. What I'm saying is that no practical amount of testing and verification can eliminate the need for updates. Let me give some practical examples I've seen: a bug in the silicon vendor BSP that prevented programs from accessing half of the physical memory. In another case the vendor provided optimistic battery curves that caused safety issues in certain conditions, so changes were needed after units were already in the field. In another case, a factory was taking the stuff we were giving them and using it to build weird Frankenstein images from various binary blobs, so nothing that had been produced for those weeks corresponded to anything that had been tested.
    - shiroiuma 3y ago
      Cars have been built for decades without needing any updates at all. Microcontrollers were first put in cars in the 1970s, for fuel injection control, and later for ABS and SRS. No one ever got a software update for their ABS controller in the 1990s. They've been happily running non-updateable code for many decades now, and all of a sudden you think it's normal to update embedded software? No, it really isn't. If there was a real problem, there was a manufacturer recall and they replaced parts.
      - ryandrake 3y ago
        Yes, this fatalistic "all software inevitably has bugs" attitude is corrosive and self-reinforcing. How about we replace it with "the more complex the software, the faster it's built, the more likely it will have bugs". At least then, there's a solution. Simplify. Slow down. Test. Remove software. Don't use software when it's not required. The current free-for-all where we must put complex software into everything is killing us.
      - AlotOfReading 3y ago
        Those systems had bugs like anything else, they were just never addressed if the customer didn't bring their vehicle back to a dealership. Have you dealt with code from the 70s-90s before? The codebases I've worked with from that time period were rife with bugs and quality issues we wouldn't consider remotely acceptable today.
aendruk 3y ago
This sounds like the concept of progressive enhancement.

AlotOfReading 3y ago

That's not how vehicles are designed for many reasons. For one, there's no option where critical components aren't designed with updateability in mind. It's simply a fact of life that code has bugs, and the only way to fix those bugs is updates. It's valid to feel that that those updates should applied at a dealership where the system can be tested afterwards, but that has a lot of implications of its own.

onetimeuse92304 3y ago
You simply do not understand the point of extracting "basic car" from "smart car". The point isn't that the software will have no bugs. The point is that the basic car will have much less software and much more basic software and that it is much easier to test and ensure this software is in working condition. Also, it is absolutely not true that the basic software has to be updateable. With care, basic functionality can absolutely be completely finished. Imagine you have been in the market with ABS controller for a decade or more. It has really simple functionality, it should be possible to just bake it and never touch it again. Or maybe a controller that takes care of basic battery protection. Or motor ESC. When the components are simple enough and well defined enough, it should be possible to "finish" the software to a state where it never again needs to be updated. Or updated only in exceptional circumstances.
- AlotOfReading 3y ago
  I have a very deep appreciation for simpler automotive components. Please don't take anything I'm saying as discounting those very real benefits. What I'm saying is that no practical amount of testing and verification can eliminate the need for updates. Let me give some practical examples I've seen: a bug in the silicon vendor BSP that prevented programs from accessing half of the physical memory. In another case the vendor provided optimistic battery curves that caused safety issues in certain conditions, so changes were needed after units were already in the field. In another case, a factory was taking the stuff we were giving them and using it to build weird Frankenstein images from various binary blobs, so nothing that had been produced for those weeks corresponded to anything that had been tested.
  - shiroiuma 3y ago
    Cars have been built for decades without needing any updates at all. Microcontrollers were first put in cars in the 1970s, for fuel injection control, and later for ABS and SRS. No one ever got a software update for their ABS controller in the 1990s. They've been happily running non-updateable code for many decades now, and all of a sudden you think it's normal to update embedded software? No, it really isn't. If there was a real problem, there was a manufacturer recall and they replaced parts.
    - ryandrake 3y ago
      Yes, this fatalistic "all software inevitably has bugs" attitude is corrosive and self-reinforcing. How about we replace it with "the more complex the software, the faster it's built, the more likely it will have bugs". At least then, there's a solution. Simplify. Slow down. Test. Remove software. Don't use software when it's not required. The current free-for-all where we must put complex software into everything is killing us.
    - AlotOfReading 3y ago
      Those systems had bugs like anything else, they were just never addressed if the customer didn't bring their vehicle back to a dealership. Have you dealt with code from the 70s-90s before? The codebases I've worked with from that time period were rife with bugs and quality issues we wouldn't consider remotely acceptable today.

aendruk 3y ago

This sounds like the concept of progressive enhancement.