4 ms·

Software engineering needs some significant improvements if we would like to keep using critical systems like aircrafts. It is getting to the point where seriou

Software engineering needs some significant improvements if we would like to keep using critical systems like aircrafts. It is getting to the point where serious software problems are impacting everyday life, not in a good sense.

greatpatton 7y ago
Airbus is already using formal method for creation and validation of the code which are the ultimate version of testing.
- deleted 7y ago
  [deleted]
- StreamBright 7y ago
  Whatever method prevents buffer overflows. AFAIK that is what happens here. "The CPIOM is effectively a mini computer; in the A350 CPIOMs run discrete avionics "applications", in the sense of apps. CRDCs themselves do not host or run applications, suggesting that the failure condition detailed in the EASA AD may mean loss of a particular app on a CPIOM after a buffer overflow."
  - AnimalMuppet 7y ago
    s/AFAIK/I'm guessing/ Or do you have any objective basis for suspecting that this is a buffer overflow?
tjr 7y ago
What kind of improvements do you have in mind? Any specific examples?
- StreamBright 7y ago
  Having systems that are not prone to buffer overflows? Having workarounds? Not sure. As far as specific examples: https://www.sciencedirect.com/science/article/pii/S1877050916303039 https://www.sciencedirect.com/science/article/pii/S187705091...
Zigurd 7y ago
That's a very broad statement. Focusing on specifics would be more helpful. For example, 149 hours isn't that long, especially for aircraft which have high duty cycle percentages. Why didn't the original test plan estimate how long it would take to find a certain percentage of [insert-bug-type-here], and find this issue? Would re-testing the code-base pro-actively find related latent issues? But none of these kinds of observations are fundamental. There's no general conclusion regarding software engineering to be drawn.
- StreamBright 7y ago
  Is it too broad to expect software working properly? 149 hours mean time between failures (MTBF) is extremely low. Comparing that to hard drives (1000 000) or anything that has complex electronics and mechanics is laughable.

greatpatton 7y ago

Airbus is already using formal method for creation and validation of the code which are the ultimate version of testing.

deleted 7y ago
[deleted]
StreamBright 7y ago
Whatever method prevents buffer overflows. AFAIK that is what happens here. "The CPIOM is effectively a mini computer; in the A350 CPIOMs run discrete avionics "applications", in the sense of apps. CRDCs themselves do not host or run applications, suggesting that the failure condition detailed in the EASA AD may mean loss of a particular app on a CPIOM after a buffer overflow."
- AnimalMuppet 7y ago
  s/AFAIK/I'm guessing/ Or do you have any objective basis for suspecting that this is a buffer overflow?

tjr 7y ago

What kind of improvements do you have in mind? Any specific examples?

StreamBright 7y ago
Having systems that are not prone to buffer overflows? Having workarounds? Not sure. As far as specific examples: https://www.sciencedirect.com/science/article/pii/S1877050916303039 https://www.sciencedirect.com/science/article/pii/S187705091...

Zigurd 7y ago

That's a very broad statement. Focusing on specifics would be more helpful. For example, 149 hours isn't that long, especially for aircraft which have high duty cycle percentages. Why didn't the original test plan estimate how long it would take to find a certain percentage of [insert-bug-type-here], and find this issue? Would re-testing the code-base pro-actively find related latent issues? But none of these kinds of observations are fundamental. There's no general conclusion regarding software engineering to be drawn.

StreamBright 7y ago
Is it too broad to expect software working properly? 149 hours mean time between failures (MTBF) is extremely low. Comparing that to hard drives (1000 000) or anything that has complex electronics and mechanics is laughable.