5 ms·

Various sources put the current SLOC count in modern vehicles in the hundred-million range: https://skeptics.stackexchange.com/questions/39559/does-the-source-c

Various sources put the current SLOC count in modern vehicles in the hundred-million range: https://skeptics.stackexchange.com/questions/39559/does-the-source-code-of-the-software-for-a-high-end-car-contain-on-average-aroun https://skeptics.stackexchange.com/questions/39559/does-the-... A lot of that is for the infotainment systems, but regardless, we're probably going to be seeing automakers struggle more and more with all of the problems that have plagued the software industry for its entire history. On the one hand, I want to say that situations like this Tesla crash and your minivan example get so much attention because that's rare, so the manufacturers are mostly getting it right and we'll all be fine. On the other, knowing what I know of the software industry plus my past experience as a shadetree, the prospect of that much code running in 65-mile-an-hour murder machines gives me the shivers.

bri3d 9y ago
As many of the comments (but none of the top-level answers) in that Stack Exchange thread note, most of the code in critical control systems like ECUs isn't written, it's generated from verifiable models. While this doesn't lend complete confidence by any means, I think it can be expected that the defects/SLOC will be much lower and of a very different variety in this type of code than code that's written.
- phkahler 9y ago
  >> most of the code in critical control systems like ECUs isn't written, it's generated from verifiable models. I'm not sure what "verifiable models" means here. There are a bunch of people using Simulink to "auto-generate" code for some ECUs. I've used it with great results, and I've seen others do that as well. And yet some people still create horrible things with it just like regular code. But not once did I see anything that sounded like formal verification. That doesn't mean it never happens but the way The Mathworks markets their tools, you'd think some kind of magic is done automatically. On a related note, I always laugh when Mathworks promotes the ability to compare "simulation" results to that of the "generated code". They call it "software in the loop" testing. This is actually getting their customers to verify that the tools they provide work as advertised. For that kind of development I'd actually prefer to just shut the simulator off always generate code. Simulation should only ever be for plant models, not control systems you want to actually implement in software.
  - sveme 9y ago
    Isn‘t it possible to formally check Simulink autogenerated code using Polyspace? Or are you thinking of something else?
    - phkahler 9y ago
      Oh god. You can check any C-code with Polyspace, I've done that. Most of the warnings Polyspace generates (at the time I did it) are not more significant than style - like checking for MISRA compliance doesn't guarantee a lack of bugs. To me formal verification has always meant proving correctness in a mathematical sense against some sort of formal specification. None of that really matters though because AFAIK you can't prove a neural net has been trained "correctly" and doesn't contain errors.
      - makintunde 9y ago
        "None of that really matters though because AFAIK you can't prove a neural net has been trained "correctly" and doesn't contain errors." Progress is being made in this area. Here is an "old" paper: https://arxiv.org/abs/1702.01135 https://arxiv.org/abs/1702.01135
      - naveen99 9y ago
        Halting problem is even more general.
ploxiln 9y ago
I think this is a key point. SLOC is going way up. It's sort of natural - it's "why not". We can afford to have more SLOC than ever before. Why bother to try to reduce it, that's not a priority, our priorities are features and fixes. It becomes too much to really understand and manage, and then it's all automated checks and automated tests. It's very hard to get the average/common developer to spend time thinking about how we can remove stuff, clean stuff up. And managers don't want to pay them to do that. In some places it eventually becomes a big problem, and then it's time for a big rewrite. Most software is throw-away. Website front-ends, mobile device drivers, etc ... mostly thrown-away roughly every year. It's the relatively rare and stodgy classic open-source stuff that's re-used (with minor updates) for decades. OK, I'm getting off-topic ...
- richardknop 9y ago
  Exactly my thoughts. You have explained in words what I have been thinking for a very long time.

bri3d 9y ago

As many of the comments (but none of the top-level answers) in that Stack Exchange thread note, most of the code in critical control systems like ECUs isn't written, it's generated from verifiable models. While this doesn't lend complete confidence by any means, I think it can be expected that the defects/SLOC will be much lower and of a very different variety in this type of code than code that's written.

phkahler 9y ago
>> most of the code in critical control systems like ECUs isn't written, it's generated from verifiable models. I'm not sure what "verifiable models" means here. There are a bunch of people using Simulink to "auto-generate" code for some ECUs. I've used it with great results, and I've seen others do that as well. And yet some people still create horrible things with it just like regular code. But not once did I see anything that sounded like formal verification. That doesn't mean it never happens but the way The Mathworks markets their tools, you'd think some kind of magic is done automatically. On a related note, I always laugh when Mathworks promotes the ability to compare "simulation" results to that of the "generated code". They call it "software in the loop" testing. This is actually getting their customers to verify that the tools they provide work as advertised. For that kind of development I'd actually prefer to just shut the simulator off always generate code. Simulation should only ever be for plant models, not control systems you want to actually implement in software.
- sveme 9y ago
  Isn‘t it possible to formally check Simulink autogenerated code using Polyspace? Or are you thinking of something else?
  - phkahler 9y ago
    Oh god. You can check any C-code with Polyspace, I've done that. Most of the warnings Polyspace generates (at the time I did it) are not more significant than style - like checking for MISRA compliance doesn't guarantee a lack of bugs. To me formal verification has always meant proving correctness in a mathematical sense against some sort of formal specification. None of that really matters though because AFAIK you can't prove a neural net has been trained "correctly" and doesn't contain errors.
    - makintunde 9y ago
      "None of that really matters though because AFAIK you can't prove a neural net has been trained "correctly" and doesn't contain errors." Progress is being made in this area. Here is an "old" paper: https://arxiv.org/abs/1702.01135 https://arxiv.org/abs/1702.01135
    - naveen99 9y ago
      Halting problem is even more general.

ploxiln 9y ago

I think this is a key point. SLOC is going way up. It's sort of natural - it's "why not". We can afford to have more SLOC than ever before. Why bother to try to reduce it, that's not a priority, our priorities are features and fixes. It becomes too much to really understand and manage, and then it's all automated checks and automated tests. It's very hard to get the average/common developer to spend time thinking about how we can remove stuff, clean stuff up. And managers don't want to pay them to do that. In some places it eventually becomes a big problem, and then it's time for a big rewrite. Most software is throw-away. Website front-ends, mobile device drivers, etc ... mostly thrown-away roughly every year. It's the relatively rare and stodgy classic open-source stuff that's re-used (with minor updates) for decades. OK, I'm getting off-topic ...

richardknop 9y ago
Exactly my thoughts. You have explained in words what I have been thinking for a very long time.