←back to thread

327 points AareyBaba | 4 comments | | HN request time: 0s | source
Show context
barfoure ◴[] No.46183842[source]
Do avionics in general subscribe to MISRA C/C++ or do they go even further with an additional (or different) approach?
replies(3): >>46183870 #>>46184021 #>>46184148 #
stackghost ◴[] No.46184148[source]
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.

replies(2): >>46184199 #>>46192932 #
garyfirestorm ◴[] No.46184199[source]
You’re joking right? That autogenerated code is generally garbage and spaghetti code. It was probably the reason for Toyotas unintended acceleration glitch.
replies(6): >>46184323 #>>46184469 #>>46184508 #>>46184621 #>>46185898 #>>46186758 #
stackghost ◴[] No.46184508[source]
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.

replies(2): >>46186155 #>>46186978 #
mmooss ◴[] No.46186978{3}[source]
> 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.

replies(1): >>46188130 #
1. coderenegade ◴[] No.46188130{4}[source]
What's the difference between autogenerated C code and compiling to assembly or machine code? Seems academic to me.

The main flaw of autocode is that a human can't easily read and validate it, so you can't really use it as source code. In my experience, this is one of the biggest flaws of these types of systems. You have to version control the file for whatever proprietary graphical programming software generated the code in the first place, and as much as we like to complain about git, it looks like a miracle by comparison.

replies(1): >>46188263 #
2. mmooss ◴[] No.46188263[source]
> What's the difference between autogenerated C code and compiling to assembly or machine code? Seems academic to me.

It's an interesting question and point, but those are two different things and there is no reason to think you'll get the same results. Why not compile from natural language, if that theory is true?

replies(1): >>46189091 #
3. _flux ◴[] No.46189091[source]
Natural language does not have a specification, while both C and assembly do.
replies(1): >>46189238 #
4. mmooss ◴[] No.46189238{3}[source]
The C specification is orders of magnitude more complex and is much less defined than assembly. Arguably, the same could be said comparing natural language with C.

I admit that's mostly philosphical. But I think saying 'C can autogenerate reliable assembly, therefore a specification can autogenerate reliable C' is also about two different problems.