5 ms·

Depends on the company in my experience. I've seen some suppliers that basically just wire up the diagram in Matlab/simulink and hit Autocode. No humans actua

Depends on the company in my experience. I've seen some suppliers that basically just wire up the diagram in Matlab/simulink and hit Autocode. No humans actually touch the C that comes out. Honestly I think that's probably the correct way to write high reliability code.

garyfirestorm 10mo ago
You’re joking right? That autogenerated code is generally garbage and spaghetti code. It was probably the reason for Toyotas unintended acceleration glitch.
- AnimalMuppet 10mo ago
  > It was probably the reason for Toyotas unintended acceleration glitch. Do you have any evidence for "probably"?
  - garyfirestorm 10mo ago
    I know for the fact simulink generates spaghetti and spaghetti code was partially blamed for Toyotas problems. Hence the inference See https://www.safetyresearch.net/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/ https://www.safetyresearch.net/toyota-unintended-acceleratio...
    - CamouflagedKiwi 10mo ago
      That's a nonsensical connection. "Spaghetti code" is a very general term, that's nowhere near specific enough for the two to be related. "I know for a fact that Italian cooks generate spaghetti, and the deceased's last meal contained spaghetti, therefore an Italian chef must have poisoned him"
    - stackghost 10mo ago
      SRS is a for-profit corporation whose income comes from lawsuits, so their reports/investigations are tainted by their financial incentive to overstate the significance of their findings.
- vodou 10mo ago
  Modern autogenerated C code from Simulink is rather effective. It is neither garbage nor spaghetti, it is just... peculiar.
  - addaon 10mo ago
    It’s also much, much more resource intensive (both compute and memory) than what a human would right for the same requirements.
    - stackghost 10mo ago
      For control systems like avionics it either passes the suite of tests for certification, or it doesn't. Whether a human could write code that uses less memory is simply not important. In the event the autocode isn't performant enough to run on the box you just spec a faster chip or more memory.
      - addaon 10mo ago
        I’m sorry, but I disagree. Building these real-time safety-critical systems is what I do for a living. Once the system is designed and hardware is selected, I agree that if the required tasks fit in the hardware, it’s good to go — there’s no bonus points for leaving memory empty. But the sizing of the system, and even the decomposition of the system to multiple ECUs and the level of integration, depends on how efficient the code is. And there are step functions here — even a decade ago it wasn’t possible to get safety processors with sufficient performance for eVTOL control loops (there’s no “just spec a faster chip”), so the system design needed to deal with lower-ASIL capable hardware and achieve reliability, at the cost of system complexity, at a higher level. Today doing that in a safety processors is possible for hand-written code, but still marginal for autogen code, meaning that if you want to allow for the bloat of code gen you’ll pay for it at the system level.
        stackghost 10mo ago
        >And there are step functions here — even a decade ago it wasn’t possible to get safety processors with sufficient performance for eVTOL control loops (there’s no “just spec a faster chip”) The idea that processors from the last decade were slower than those available today isn't a novel or interesting revelation. All that means is that 10 years ago you had to rely on humans to write the code that today can be done more safely with auto generation. 50+ years of off by ones and use after frees should have disabused us of the hubristic notion that humans can write safe code. We demonstrably can't. In any other problem domain, if our bodies can't do something we use a tool. This is why we invented axes, screwdrivers, and forklifts. But for some reason in software there are people who, despite all evidence to the contrary, cling to the absurd notion that people can write safe code.
- stackghost 10mo ago
  No I'm not joking at all. The Autocode feature generates code that has high fidelity to the model in simulink, and is immensely more reliable than a human. It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0`, for example. Any human who tells you they have not made this mistake is a liar. Unless there was a second uncommanded acceleration problem with Toyotas, my understanding is that it was caused by poor mechanical design of the accelerator pedal that caused it to get stuck on floor mats. In any case, when we're talking about safety critical control systems like avionics, it's better to abstract away the actual act of typing code into an editor, because it eliminates a potential source of errors. You verify the model at a higher level, and the code is produced in a deterministic manner.
  - fl7305 10mo ago
    > It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0` The Simulink Coder tool is a piece of software. It is designed and implemented by humans. It will have bugs. Autogenerated code is different from human written code. It hits soft spots in the C/C++ compilers. For example, autogenerated code can have really huge switch statements. You know, larger than the 15-bit branch offset the compiler implementer thought was big enough to handle any switch-statement any sane human would ever write? So now the switch jumps backwards instead when trying to get the the correct case-statement. I'm not saying that Simulink Coder + a C/C++ compiler is bad. It might be better than the "manual coding" options available. But it's not 100% bug free either.
    - stackghost 10mo ago
      >But it's not 100% bug free either. Nobody said it was bug free, and this is a straw man argument of your own construction. Using Autocode completely eliminates certain types of errors that human C programmers have continued to make for more than half a century.
  - mmooss 10mo ago
    > It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0` That's a classic bias: Comparing A and B, show that B doesn't have some A flaws. If they are different systems, of course that's true. But it's also true that A doesn't have some B flaws. That is, what flaws does Autocode have that humans don't? The fantasy that machines are infallible - another (implicit) argument in this thread - is just ignorance for any professional in technology.
- cpgxiii 10mo ago
  In the case of the Toyota/Denso mess, the code in question had both auto-generated and hand-written elements, including places where the autogenerated code had been modified by hand later. That is the worst place to be, where you no longer have whatever structure and/or guarantees the code gen might provide, but you also don't have the structure and choices that a good SWE team would have to develop that level of complexity by hand.
  - superxpro12 10mo ago
    The toyota code was a case of truly abysmal software development methodology. The resultant code they released was so bad that neither NASA, nor Barr, nor Koopman could successfully decipher. (Although Barr posited that the issue was VERY LIKELY in one of a few places with complex multithreaded interactions). Which therein lies the clue. They wrote software that was simply unmaintainable. Autogenerated code isnt any better.
- fluorinerocket 10mo ago
  Rockets have flown to orbit on auto coded simulink, seen it myself
- creato 10mo ago
  This isn't necessarily a problem if you don't consider the output to be "source" code. Assembly is also garbage spaghetti code but that doesn't stop you from using a compiler does it?
superxpro12 10mo ago
I just vomited in my mouth a little. Please god no.

garyfirestorm 10mo ago

You’re joking right? That autogenerated code is generally garbage and spaghetti code. It was probably the reason for Toyotas unintended acceleration glitch.

AnimalMuppet 10mo ago
> It was probably the reason for Toyotas unintended acceleration glitch. Do you have any evidence for "probably"?
- garyfirestorm 10mo ago
  I know for the fact simulink generates spaghetti and spaghetti code was partially blamed for Toyotas problems. Hence the inference See https://www.safetyresearch.net/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/ https://www.safetyresearch.net/toyota-unintended-acceleratio...
  - CamouflagedKiwi 10mo ago
    That's a nonsensical connection. "Spaghetti code" is a very general term, that's nowhere near specific enough for the two to be related. "I know for a fact that Italian cooks generate spaghetti, and the deceased's last meal contained spaghetti, therefore an Italian chef must have poisoned him"
  - stackghost 10mo ago
    SRS is a for-profit corporation whose income comes from lawsuits, so their reports/investigations are tainted by their financial incentive to overstate the significance of their findings.
vodou 10mo ago
Modern autogenerated C code from Simulink is rather effective. It is neither garbage nor spaghetti, it is just... peculiar.
- addaon 10mo ago
  It’s also much, much more resource intensive (both compute and memory) than what a human would right for the same requirements.
  - stackghost 10mo ago
    For control systems like avionics it either passes the suite of tests for certification, or it doesn't. Whether a human could write code that uses less memory is simply not important. In the event the autocode isn't performant enough to run on the box you just spec a faster chip or more memory.
    - addaon 10mo ago
      I’m sorry, but I disagree. Building these real-time safety-critical systems is what I do for a living. Once the system is designed and hardware is selected, I agree that if the required tasks fit in the hardware, it’s good to go — there’s no bonus points for leaving memory empty. But the sizing of the system, and even the decomposition of the system to multiple ECUs and the level of integration, depends on how efficient the code is. And there are step functions here — even a decade ago it wasn’t possible to get safety processors with sufficient performance for eVTOL control loops (there’s no “just spec a faster chip”), so the system design needed to deal with lower-ASIL capable hardware and achieve reliability, at the cost of system complexity, at a higher level. Today doing that in a safety processors is possible for hand-written code, but still marginal for autogen code, meaning that if you want to allow for the bloat of code gen you’ll pay for it at the system level.
      - stackghost 10mo ago
        >And there are step functions here — even a decade ago it wasn’t possible to get safety processors with sufficient performance for eVTOL control loops (there’s no “just spec a faster chip”) The idea that processors from the last decade were slower than those available today isn't a novel or interesting revelation. All that means is that 10 years ago you had to rely on humans to write the code that today can be done more safely with auto generation. 50+ years of off by ones and use after frees should have disabused us of the hubristic notion that humans can write safe code. We demonstrably can't. In any other problem domain, if our bodies can't do something we use a tool. This is why we invented axes, screwdrivers, and forklifts. But for some reason in software there are people who, despite all evidence to the contrary, cling to the absurd notion that people can write safe code.
stackghost 10mo ago
No I'm not joking at all. The Autocode feature generates code that has high fidelity to the model in simulink, and is immensely more reliable than a human. It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0`, for example. Any human who tells you they have not made this mistake is a liar. Unless there was a second uncommanded acceleration problem with Toyotas, my understanding is that it was caused by poor mechanical design of the accelerator pedal that caused it to get stuck on floor mats. In any case, when we're talking about safety critical control systems like avionics, it's better to abstract away the actual act of typing code into an editor, because it eliminates a potential source of errors. You verify the model at a higher level, and the code is produced in a deterministic manner.
- fl7305 10mo ago
  > It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0` The Simulink Coder tool is a piece of software. It is designed and implemented by humans. It will have bugs. Autogenerated code is different from human written code. It hits soft spots in the C/C++ compilers. For example, autogenerated code can have really huge switch statements. You know, larger than the 15-bit branch offset the compiler implementer thought was big enough to handle any switch-statement any sane human would ever write? So now the switch jumps backwards instead when trying to get the the correct case-statement. I'm not saying that Simulink Coder + a C/C++ compiler is bad. It might be better than the "manual coding" options available. But it's not 100% bug free either.
  - stackghost 10mo ago
    >But it's not 100% bug free either. Nobody said it was bug free, and this is a straw man argument of your own construction. Using Autocode completely eliminates certain types of errors that human C programmers have continued to make for more than half a century.
- mmooss 10mo ago
  > It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0` That's a classic bias: Comparing A and B, show that B doesn't have some A flaws. If they are different systems, of course that's true. But it's also true that A doesn't have some B flaws. That is, what flaws does Autocode have that humans don't? The fantasy that machines are infallible - another (implicit) argument in this thread - is just ignorance for any professional in technology.
cpgxiii 10mo ago
In the case of the Toyota/Denso mess, the code in question had both auto-generated and hand-written elements, including places where the autogenerated code had been modified by hand later. That is the worst place to be, where you no longer have whatever structure and/or guarantees the code gen might provide, but you also don't have the structure and choices that a good SWE team would have to develop that level of complexity by hand.
- superxpro12 10mo ago
  The toyota code was a case of truly abysmal software development methodology. The resultant code they released was so bad that neither NASA, nor Barr, nor Koopman could successfully decipher. (Although Barr posited that the issue was VERY LIKELY in one of a few places with complex multithreaded interactions). Which therein lies the clue. They wrote software that was simply unmaintainable. Autogenerated code isnt any better.
fluorinerocket 10mo ago
Rockets have flown to orbit on auto coded simulink, seen it myself
creato 10mo ago
This isn't necessarily a problem if you don't consider the output to be "source" code. Assembly is also garbage spaghetti code but that doesn't stop you from using a compiler does it?

superxpro12 10mo ago

I just vomited in my mouth a little. Please god no.