Hacker News new | past | comments | ask | show | jobs | submit login

Well there is no indication about the severity of these ~800 bugs, but ~800 non-severe bugs in a system this complex is actually pretty good in my opinion.



>but ~800 non-severe bugs in a system this complex is actually pretty good in my opinion.

"The fly-by-wire flight software for the Saab Gripen (a lightweight fighter) went a step further. It disallowed both subroutine calls and backward branches, except for the one at the bottom of the main loop. Control flow went forward only. Sometimes one piece of code had to leave a note for a later piece telling it what to do, but this worked out well for testing: all data was allocated statically, and monitoring those variables gave a clear picture of most everything the software was doing. The software did only the bare essentials, and of course, they were serious about thorough ground testing.

No bug has ever been found in the “released for flight” versions of that code.

                                                     Henry Spencer
                                                  henry@spsystems.net"
Courtesy of John Carmack


Two crashes of Gripens during development led to changes in the flight control software.

Now you could argue as to whether those were bugs or requirements deficiencies, but in neither case were the faults caught in preflight testing.


> during development

Wasn't the above comment in reply to there being no bugs found in software released for flight?


Either, the Saab "released for flight" claim only applies to fully operational flights, in which case the F-35 is still in development and we haven't seen the "released for flight" version of its software, or test-flight crashes leading to changes in flight software are very strong evidence that the claim is incorrect.


I've worked in a closely related field. The fly-by-wire software is comparatively very small, compared to all software in a modern fighter jet like the F35. Just from the top of my head, you've got, Flight controls, Radar, Comms, NAV, Ident, Electronic warfare, Sensor fusion, Weapons management, mission recording, cockpit avionics, helmet mgmet, etc.


Why no subroutines? Isn't any function call a subroutine?

In any event, I'd love to take a look at that source code. I try my best to keep forward-only control flow, at least at the conceptual level (I.e., I don't eschew loops, but I try to keep data flowing from A to B to C to D without having it go back and check a preceding component for what to do in a given case).


I think they are lumping subroutine and function calls into the same bucket. Basically, avoid anything that pushes stuff on the stack?


Interesting. That’s a different world from the business, or development tool, projects I have ever worked on.

Never worked on any real time stuff. Looks like they are very big on using a flat finite state machine model. At least at Saab. I’m guessing they didn’t use C++, either, but who knows.


Looks like another argument in favor of Ada:

https://www.sigada.org/conf/sa98/papers/frisberg.pdf


Yes...this is a big reason why Ada exists.


Nope...definitely not C++. Check out Jovial, Coral-66, MISRA C & sometimes Fortran. More recently, Ada & SPARK.

The F-35? C++.


Yes, but the flight control software is just a tiny part of all of the software in the F-35. You have radars, datalinks, targeting, navigation, optical, sensor fusion, maintenance, weapons, propulsion, and cockpit displays, among others.


I wonder if there is any javascript or python anywhere in the F35 software


I believe the vast majority (if not all) of the code is in C++. They stopped using Ada because it was too hard to find programmers that already knew it




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: