6 ms·

Wow, how can something like this happen? I thought airplanes had triple redundant software systems using 3-version programming [1] in order to avoid such bugs/p

Wow, how can something like this happen? I thought airplanes had triple redundant software systems using 3-version programming [1] in order to avoid such bugs/problems. Can anyone familiar with flight technology shed some light on this? [1]http://en.wikipedia.org/wiki/N-version_programming http://en.wikipedia.org/wiki/N-version_programming

CHY872 11y ago
Not an airplane programmer, but I seem to remember that the literature says that it's not generally a cost-effective way of finding bugs. In particular, you multiply the cost of development by (say) 3x (which is fine, on its own) but also the places where bugs are inserted are typically the hard parts; so you don't reduce the number of bugs as much as you'd like; it can easily be more cost effective to invest the few million in static analysis etc. As much as we'd like plane manufacturers to test things to death, it'd become too expensive too quickly. For all we know, this software could be written by a contractor, or the firmware for a third party part. As far as I know, N-version programming was effective when software systems were small (shuttle ran on 50k lines of code) and where poring over every single line was possible, because the hard part was coming up with the spec. Nowadays a big plane like the A380 might be expected to have 100M lines of code in its subsystems, and it's simply too expensive.
- hello_there 11y ago
  > Nowadays a big plane like the A380 might be expected to have 100M lines of code in its subsystems, Why does an airplane require 100M lines of code?
  - mschuster91 11y ago
    Linux kernel alone comes in at 15m SLOC. Now add an userland subsystem and you're at 20-30M just for one device. Multiply by all the little and big subsystems, the embedded chips, in-flight entertainment, network gear... 100m SLOC is too low, I think.
    - CHY872 11y ago
      Erm, the article I got my numbers from is: http://www.aerospacelab-journal.org/sites/www.aerospacelab-journal.org/files/AL04-10_1.pdf http://www.aerospacelab-journal.org/sites/www.aerospacelab-j... where it states that the airbus A380 has more than 100 million lines of code in its avionics systems.
    - georgerobinson 11y ago
      Sorry if this is incredibly ignorant, but I can't believe flight control systems are running Linux? Do these systems not have hard real-time requirements about the execution time and periodicity of tasks which can't be guaranteed by the time-sharing scheduling algorithms in Linux?
      - komaromy 11y ago
        There are several real-time Linux variants.
        jacquesm 11y ago
        There are - to my knowledge, feel free to correct me - no real time linux versions (or even any version of linux) that are currently certified for avionics (DO-178B certification is required for that, there are multiple levels and I don't know of any linux distro (or just the kernel) with that certification).
        komaromy 11y ago
        Avionics certifications are well past the extent of my knowledge and I will gladly accept your point. I was generally addressing the idea that the need for preemptive scheduling precludes the use of a Linux-like kernel.
        anderspitman 11y ago
        I've never heard of anyone getting Linux running under hard real time constraints. You can get it pretty good (excellent for real time audio, for example), but can never be 100% sure you're going to meet the deadline. The people I've talked to who tried said by the time you strip out enough of the kernel to approach hard real time, you've lost enough of the advantage of using Linux that you may as well switch to an RTOS.
  - deleted 11y ago
    [deleted]
  - icegreentea 11y ago
    Because each discrete component that you can eliminate (and replace with code) is a weight saving. Because once you tip over a point in complexity, you just keep adding more code to guard against more edge cases - edge cases you can't avoid because they involve crashing into mountains. Because you want to offload as much possible effort from the cockpit crew, while still allowing them full control over the automated feature All of these things just add more and more code.
userbinator 11y ago
"independently generated from the same initial specifications" For all we know, if the spec required a counter of 100ms intervals, all N implementations could contain the same bug. N-version avoids random, but not systematic bugs.
deleted 11y ago
[deleted]
firethief 11y ago
The complexity of the software that manages the N versions seems terrifying, and decision-by-committee in the implementation seems problematic. 3 implementations could select different sequences of responses to a situation, each of which individually is correct, but which are disastrous when combined by vote. E.g. say they're voting on 3 different numbers that have to add to 1; proposals are (1 0 0) (0 1 0) (0 0 1). Consensus is (0 0 0), oops there goes a billion kilowatt dam.

CHY872 11y ago

Not an airplane programmer, but I seem to remember that the literature says that it's not generally a cost-effective way of finding bugs. In particular, you multiply the cost of development by (say) 3x (which is fine, on its own) but also the places where bugs are inserted are typically the hard parts; so you don't reduce the number of bugs as much as you'd like; it can easily be more cost effective to invest the few million in static analysis etc. As much as we'd like plane manufacturers to test things to death, it'd become too expensive too quickly. For all we know, this software could be written by a contractor, or the firmware for a third party part. As far as I know, N-version programming was effective when software systems were small (shuttle ran on 50k lines of code) and where poring over every single line was possible, because the hard part was coming up with the spec. Nowadays a big plane like the A380 might be expected to have 100M lines of code in its subsystems, and it's simply too expensive.

hello_there 11y ago
> Nowadays a big plane like the A380 might be expected to have 100M lines of code in its subsystems, Why does an airplane require 100M lines of code?
- mschuster91 11y ago
  Linux kernel alone comes in at 15m SLOC. Now add an userland subsystem and you're at 20-30M just for one device. Multiply by all the little and big subsystems, the embedded chips, in-flight entertainment, network gear... 100m SLOC is too low, I think.
  - CHY872 11y ago
    Erm, the article I got my numbers from is: http://www.aerospacelab-journal.org/sites/www.aerospacelab-journal.org/files/AL04-10_1.pdf http://www.aerospacelab-journal.org/sites/www.aerospacelab-j... where it states that the airbus A380 has more than 100 million lines of code in its avionics systems.
  - georgerobinson 11y ago
    Sorry if this is incredibly ignorant, but I can't believe flight control systems are running Linux? Do these systems not have hard real-time requirements about the execution time and periodicity of tasks which can't be guaranteed by the time-sharing scheduling algorithms in Linux?
    - komaromy 11y ago
      There are several real-time Linux variants.
      - jacquesm 11y ago
        There are - to my knowledge, feel free to correct me - no real time linux versions (or even any version of linux) that are currently certified for avionics (DO-178B certification is required for that, there are multiple levels and I don't know of any linux distro (or just the kernel) with that certification).
        komaromy 11y ago
        Avionics certifications are well past the extent of my knowledge and I will gladly accept your point. I was generally addressing the idea that the need for preemptive scheduling precludes the use of a Linux-like kernel.
        anderspitman 11y ago
        I've never heard of anyone getting Linux running under hard real time constraints. You can get it pretty good (excellent for real time audio, for example), but can never be 100% sure you're going to meet the deadline. The people I've talked to who tried said by the time you strip out enough of the kernel to approach hard real time, you've lost enough of the advantage of using Linux that you may as well switch to an RTOS.
- deleted 11y ago
  [deleted]
- icegreentea 11y ago
  Because each discrete component that you can eliminate (and replace with code) is a weight saving. Because once you tip over a point in complexity, you just keep adding more code to guard against more edge cases - edge cases you can't avoid because they involve crashing into mountains. Because you want to offload as much possible effort from the cockpit crew, while still allowing them full control over the automated feature All of these things just add more and more code.

userbinator 11y ago

"independently generated from the same initial specifications" For all we know, if the spec required a counter of 100ms intervals, all N implementations could contain the same bug. N-version avoids random, but not systematic bugs.

deleted 11y ago

[deleted]

firethief 11y ago

The complexity of the software that manages the N versions seems terrifying, and decision-by-committee in the implementation seems problematic. 3 implementations could select different sequences of responses to a situation, each of which individually is correct, but which are disastrous when combined by vote. E.g. say they're voting on 3 different numbers that have to add to 1; proposals are (1 0 0) (0 1 0) (0 0 1). Consensus is (0 0 0), oops there goes a billion kilowatt dam.