Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A400M Airbus Flier crashed because of software issues

translate.google.com

Post reply on HN
Print view View original

71–80 of 129 posts

Re: A400M Airbus Flier crashed because of software issues

#71

Post by bglazer »

TeeWEE wrote: post #60
alandarev wrote: post #18

Software contractor for Airbus and Rolls-royce here. All safety critical software (every piece of code ran on-board is safety critical the least) in aerospace needs to pass the DO-178 standard [1]. That is far more serious than standard unit tests you are used to in node.js applications. Generally speaking, to develop a piece of code under that standard it takes 20% of time to write the code, and 80% to testing, and…

I'm quite baffled at the fact that this standard does not include formal verification of the software models used. Formal verification and state space analysis can prove that the software "model" will not fail. State space exploration of the actual implementation is actually often not feasible due to the enourmous amount of states. So my question: Are you doing formal analysis of the software models/designs? I know t…

The seL4 mircrokernel is comprehensively formally verified and is marketed towards aerospace applications.

https://sel4.systems/

Re: A400M Airbus Flier crashed because of software issues

#72

Post by jonnycowboy »

tim333 wrote: post #38
lucaspiller wrote: post #8

Earlier quoted context omitted.

> So, not much information why the computers sent conflicting commands and also why the engines power down in such a situation. I think shutting down the engines is probably the safest option when this sort of thing happens. You could argue they should stay in the present setting, but what would happen if one engine were at 0% and another 100%? Most aircraft are pretty good at gliding even without power, and I'd assu…

>what would happen if one engine were at 0% and another 100% Planes are designed to fly fine in that situation - it's what you get if one engine breaks down. Now landing the thing with one engine stuck on 100% would be interesting. I guess you could kill the engine somehow - turn off the fuel or pull the fuses.

Planes with four engines are certainly not designed to fly with 3 of 4 engines out...

Re: A400M Airbus Flier crashed because of software issues

#73

Post by pfortuny »

driverdan wrote: post #20
tirant wrote: post #7

I am not surprised at all. There are a lot of contractors involved in the development of the software for the A400M, and they are basically competing for price and employing undergraduates making below €18K/year, which they replace every few months due to burnouts and bad working conditions. Projects get continuously delayed, and key people barely stay more than a couple of years.

Source?

Looks like the source is himself.

Re: A400M Airbus Flier crashed because of software issues

#74

Post by calebm »

alandarev wrote: post #18

Software contractor for Airbus and Rolls-royce here. All safety critical software (every piece of code ran on-board is safety critical the least) in aerospace needs to pass the DO-178 standard [1]. That is far more serious than standard unit tests you are used to in node.js applications. Generally speaking, to develop a piece of code under that standard it takes 20% of time to write the code, and 80% to testing, and…

I wrote (non-critical) software for the A400M. I don't think that standards like DO-178B necessarily lead to higher quality code; my experience was that 80-90% of time was spent doing documentation, testing, and in general, trying to prove that the software was going to work right, leaving the engineers with very little time to write the actual software...

Re: A400M Airbus Flier crashed because of software issues

#75

Post by Jayschwa »

[deleted] wrote: post #55
alandarev wrote: post #18

Software contractor for Airbus and Rolls-royce here. All safety critical software (every piece of code ran on-board is safety critical the least) in aerospace needs to pass the DO-178 standard [1]. That is far more serious than standard unit tests you are used to in node.js applications. Generally speaking, to develop a piece of code under that standard it takes 20% of time to write the code, and 80% to testing, and…

[deleted]

I worked at an avionics contractor for a number of years and that mirrors my experience as well. On Level A projects, the process was at least followed, but it was often under tight stressful deadlines. Testing was frequently off-shored to save money, but often resulted in low quality tests that had to be reworked at the last minute by in-house engineers.

The state on a later Level C & D project was in worse shape: bloated architecture, lots of requirements churn, little to no peer review, one unrealistic deadline after another, and mandatory overtime for large periods. It was not an environment conducive to thoughtfulness or quality. I finally got fed up and quit.

Re: A400M Airbus Flier crashed because of software issues

#76

Post by madez »

sleeping_pills wrote: post #59
mrmondo wrote: post #37

I wonder if this is the time to argue that it may be worth open sourcing the controlling software for hackers to start criticising and contributing pull requests to. I'm willing to bet that the competence of the collective community far outweighs that of those specially trained to write the software at present. What is there to lose by opening up the software to criticism other than better aviation safety? We know th…

While I agree with your statement that open sourcing code can help with improving it's quality, how exactly do you envision (paraphrasing) "hackers contributing pull requests" to code that controls engines on an airplane? Here you have an extremely specialized codebase which can perhaps be understood by a tiny group of professionals and it can actually be tested by an absolutely vanishingly small group of individuals…

You sound exactly like my current boss, who says that Linux is just a hobby project that you can put no trust in.

I mean, who would fix problems if it's just a hobby? And if it's open, it must be a hobby. Surely, that can't possibly work!

Re: A400M Airbus Flier crashed because of software issues

#77

Post by randomname2 »

rkangel wrote: post #23
madez wrote: post #9

Earlier quoted context omitted.

This is a very sound decision. The media is infamous for not getting facts straight. They much rather write an opinion based on suspicion. Well, no, thank you. Give me facts, get them straight, then I will make up my opinion.

Then stick with a news agency rather than journalists. The information from somewhere like Reuters is carefully presented as pure content, no opinion, and probably has a greater chance of being true.

This is laughably false. While staying away from outright lying, Reuters very often adds their own spin to their reporting.

Re: A400M Airbus Flier crashed because of software issues

#78

Post by Jtsummers »

calebm wrote: post #74
alandarev wrote: post #18

Software contractor for Airbus and Rolls-royce here. All safety critical software (every piece of code ran on-board is safety critical the least) in aerospace needs to pass the DO-178 standard [1]. That is far more serious than standard unit tests you are used to in node.js applications. Generally speaking, to develop a piece of code under that standard it takes 20% of time to write the code, and 80% to testing, and…

I wrote (non-critical) software for the A400M. I don't think that standards like DO-178B necessarily lead to higher quality code; my experience was that 80-90% of time was spent doing documentation, testing, and in general, trying to prove that the software was going to work right, leaving the engineers with very little time to write the actual software...

What processes did you and your coworkers use for writing up your requirements, design, test procedures, etc. (Basically, the DO-178B/C artifacts.) IME, too many times groups use Word and Excel, and collaborate via email. Version control is, "I think CM has received my latest revision". Using better tools (requirements management software) would eliminate a lot of this overhead. At a former employer we were moving to DOORS on all new projects. They were able to spend much more time on development and analysis and less time on documenting and checking documentation because the process was smoother. They weren't editing 1k page documents, they were editing a collaborative document backed by a database, not unlike a wiki. I could edit one section, and you could edit another at the same time. No risk of merge conflicts, no risk of your update replacing mine.

Re: A400M Airbus Flier crashed because of software issues

#80

Post by TheLoneWolfling »

lamby wrote: post #47
castell wrote: post #42

Earlier quoted context omitted.

Which programming language is commonly used there? Ada, C, C++, JOVIAL, Asm?

With that kind of coding-to-testing-and-documentation ratio, does it even matter?

Yes, definitely.

For a quick example, there are many languages where you cannot accidentally run off the end/start of an array, barring a compiler error.

With a language like C / C++, it's possible. Not probable, given that sort of testing. But possible nonetheless.

Some languages are also easier to test than others, partially because of this, partially because of other issues. For instance, in some languages you can guarantee at the language level (again, barring compiler errors) that something won't be modified. (Like const, but actually working.)

Post reply on HN