A400M Airbus Flier crashed because of software issues • Hacker News Board

Re: A400M Airbus Flier crashed because of software issues

#101

Post by sokoloff » Tue, May 19, 2015, 5:36 PM UTC

VLM wrote: post #34

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…

"but what would happen if one engine were at 0% and another 100%" Part of earning your multi-engine cert is memorizing all manner of different airspeed limits for that kind of situation. If you want to maintain yaw control with one engine feathered (er, shutdown) and the other at full throttle you must be going faster than X knots or whatever. Below that indicated airspeed you pull back on the throttle or you're goin…

In fact, there is a light blue radial line painted (or displayed) on the airspeed indicator for exactly this situation, so the crew doesn't have to remember the value in a high-stress situation.

Re: A400M Airbus Flier crashed because of software issues

#102

Post by minwcnt5 » Tue, May 19, 2015, 5:39 PM UTC

madez wrote: post #9

rurounijones wrote: post #5

Watching too many air-crash investigation episodes had lead me to believe 0% of media reported "facts" surrounding plane crashes. I will wait for the official accident investigation report.

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.

Related: the Gell-Mann Amnesia effect.

Re: A400M Airbus Flier crashed because of software issues

#103

Post by tormeh » Tue, May 19, 2015, 5:46 PM UTC

lambdaelite wrote: post #89

tormeh wrote: post #86

Earlier quoted context omitted.

Using C/C++ on these projects is idiotic. If Airbus used C/C++ then they deserve all the financial loss in the world. They have blood on their hands.

Keep in mind they don't use C/C++. They use C/C++ with a coding standard (like MISRA), static analysis tools, validated compilers, development processes incorporating change control, documentation, verification and validation, etc. What alternative are you suggesting?

Ada, of course. Are you saying it wasn't at the forefront of your mind? If I sound patronizing it's because I am.

Re: A400M Airbus Flier crashed because of software issues

#104

Post by nraynaud » Tue, May 19, 2015, 6:02 PM UTC

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…

I agree with your conclusion, but not exactly for the same reason. Those projects are huge, there is never really small group of people working on something, it's often spread upon contractors over sub-contractors, with people leaving and coming, over many years, so in the end the information is quite spread. Plus there is a lot of documentation (which might also be a downside, because there is a hunt for relevant information). But what I would fear is that people would feel good about it being open source, and never go to have an actual look at it. Or go for a little bit in the beginning and then never again.

Re: A400M Airbus Flier crashed because of software issues

#105

Post by crististm » Tue, May 19, 2015, 6:11 PM UTC

Jtsummers wrote: post #78

calebm wrote: post #74

Earlier quoted context omitted.

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 is just a glorified database with a text editor and schema for tracking change requirements. I found it lacking even at this.

Re: A400M Airbus Flier crashed because of software issues

#106

Post by lambdaelite » Tue, May 19, 2015, 6:13 PM UTC

tormeh wrote: post #103

lambdaelite wrote: post #89

Earlier quoted context omitted.

Keep in mind they don't use C/C++. They use C/C++ with a coding standard (like MISRA), static analysis tools, validated compilers, development processes incorporating change control, documentation, verification and validation, etc. What alternative are you suggesting?

Ada, of course. Are you saying it wasn't at the forefront of your mind? If I sound patronizing it's because I am.

As I said elsewhere, Ada does have some very nice built-in advantages, but I think my point stands: the language is a small part of the entire SDLC, and I don't think it's the most important part.

The focus on languages instead of the SDLC is telling, I think.

Re: A400M Airbus Flier crashed because of software issues

#107

Post by Jtsummers » Tue, May 19, 2015, 6:16 PM UTC

crististm wrote: post #105

Jtsummers wrote: post #78

Earlier quoted context omitted.

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 is just a glorified database with a text editor and schema for tracking change requirements. I found it lacking even at this.

Not saying it was great, but it was a hell of a lot better than Word + Excel. Probably a lot of better tools out there, but it's been a while since I've needed to use them so I'm no longer familiar with what's available.

What made it better:

Concurrent editing. Only one person at a time was modifying any section, but two or more sections could be edited by a group of people.

Version control baked in. VC is awesome, reducing friction means that it actually gets used. Checking in/out sections was just part of the process.

Automatic traceability matrices. These are not easy to make by hand. That way is error prone and tedious. It's also hard to verify. With DOORS we were able to generate these automatically. Verifying them was relatively painless because we weren't flipping through several 1k page documents to make sure things actually matched, we could easily skip to only the applicable parts of any document. The main error that it didn't reduce was when a requirement didn't get linked to every test case or design feature that it should've been linked to.

Again, probably better tools out there than DOORS (at the time, or hopefully by now). But it's a lot better than what most offices do with either post hoc document generation or ad hoc generation with Word + Excel.

Re: A400M Airbus Flier crashed because of software issues

#108

Post by madez » Tue, May 19, 2015, 6:25 PM UTC

minwcnt5 wrote: post #102

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.

Related: the Gell-Mann Amnesia effect.

The Gell-Mann Amnesia effect seems to be a specific version of something more general: cognitive dissonance. The fact that the media is not to trust is not forgotten, it is simply not evaluated and acted upon. It sits there in your brain until you sceptically reflect on what you think to know and how you act. Some people do that to some degree, most less so.

We have had a long time to recognize that our brains don't work well. It is time to accept the facts.

Re: A400M Airbus Flier crashed because of software issues

#109

Post by emp_zealoth » Tue, May 19, 2015, 6:31 PM UTC

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…

Every time i read about stuff like that i get mad. Attitude regarding software is just criminal. You wouldn't let internt/inexperienced people design mechanical parts of the plane. Engineers are bound by standards regarding everything. Materials, mechanical couplings, documentation. when i design a machine, i can't scribble it on a napkin and ship it. Why is it acceptable for idiots to write messy, unintelligible code? When i create a mechanical drawing, i am bound by rules how to draw it. With coding everyone has their own ideas. When i design a machine i have to make sure it will work, period. Calculations to be done no matter how i don't have to spend thousand of man-hours fiddling with it to see if it works as intended

the apologetic attitude needs to stop. programs are just complicated machines and should be treated as such not some mystical voodo that will be broken no matter what

Re: A400M Airbus Flier crashed because of software issues

#110

Post by nradov » Tue, May 19, 2015, 6:35 PM UTC

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…

This is a military aircraft. By opening up their software, Airbus would lose by enabling their foreign competitors and enemies to copy parts of it thus reducing their R&D costs and gaining a competitive and strategic advantage.