Live data from Hacker News

A400M Airbus Flier crashed because of software issues

translate.google.com

41–50 of 129 posts

Re: A400M Airbus Flier crashed because of software issues

#41

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…

Is the code is available for review outside the operating constraints of the system that designed it - I.e. Is it open source?

Re: A400M Airbus Flier crashed because of software issues

#42

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…

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

Re: A400M Airbus Flier crashed because of software issues

#43
post #3

So basically the software bug happened, because there are quality problems in the manufacturing street? wtf!?!?

Perhaps a mental model abstracted from aerospace is you have a somewhat complicated PID controller and it was programmed to tolerate widgets with size of 0.01 to 0.02 because only those can physically fit on the assembly line, and within those limits it is proven and tested to be unconditionally stable and predictable and correct under all operating conditions.

Unfortunately manufacturing let a batch of 0.0201 size slip thru inspection, they just barely fit on the assembly line despite being out of spec too large, and the PID controller makes the system go into oscillation and explode because its outside its theoretical limits of whats possible.

The most insidious spec violations are "manufactured too well" if for example you rely on frictional damping to eliminate oscillations, then making and shipping better ball bearings than you'd ever shipped before, could ruin an overall system because one component is too good. Possibly the "error" is something is too smooth, too straight, too flat, or too low friction. No one ever expects those to cause a disaster, but it can happen.

That would be an example of a disaster involving software, that can be fixed in software, although it wasn't caused by the software, it was caused by bad control system engineering design work. Also this abstract example probably has nothing to do with the real problem, although the "widget" and "size" could very well be something line fuel line tubing inside diameter.

Re: A400M Airbus Flier crashed because of software issues

#44
post #21

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…

How does liability work, and do Airbus have access to the source code? I assume that if a "bug" was found in the architectural blueprint for a plane it would be the manufacturer who in the end is responsible for not finding it, but they would naturally have full access to the blueprint when making the plane. Is the same true when developing the custom software for the plane?

Well it's military airplane so it's a bit special here, usually it's the costumer (i.e. the army) which is liable if the plane has passed the final tests.

However it's a complete different matter for civil airplanes : it's the lead dev/project manager which is liable for life for what he has shipped. For example, a retired engineer from Airbus was heard in trial for the Concorde accident in France in 2000.

Re: A400M Airbus Flier crashed because of software issues

#45
From another report:

"Problems in developing the engines, and particularly in certifying the engine control software, contributed to three years of delays and a new cash injection by governments in 2010."

Seems like they had some issues. Surprising it's that difficult.

http://www.reuters.com/article/2015/05/19/airbus-a400m-idUSL...

Re: A400M Airbus Flier crashed because of software issues

#46

Earlier quoted context omitted.

Or it seems like the problem may have been a known (or suspected) issue with an old firmware, and the check is to make sure the firmware is above a certain version (which would also explain why the check would be necessary on any replacement ECUs).

The A400M that crashed was on its first test flight, so unless they've done something very odd with versioning, it's unlikely that all its ECUs had older firmware than planes that already shipped. Besides, with aircraft, all changes are logged with a ton of paperwork, so they shouldn't need to check the aircraft to know what firmware they're running.

It doesn't seem so unlikely to me. Supply chains are long and parts are bought in bulk. I think it's likely that the parts for the ECUs, including boards with chips containing the older firmware, are warehoused where the ECUs are assembled. The ECUs are probably then bought in bulk and warehoused where the planes are assembled. The paperwork for the plane probably includes the ECU serial numbers, but it probably doesn't include serial numbers for all of the components installed on all of the boards inside the ECU, especially if they didn't have the foresight to think that those numbers would matter. Afterall, it seems there's a way to get the firmware version by querying the ECU.

Re: A400M Airbus Flier crashed because of software issues

#47
post #42

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…

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?

Re: A400M Airbus Flier crashed because of software issues

#48

Earlier quoted context omitted.

I can confirm similar situations for other EU IT projects. Currently, I am a contractor working on the IT side for the Galileo Satellite System. Although the IT consulting company that I work for pays significantly better then the 18K mentioned (25K-30K range) the quality of the work that is delivered is terrible. The mentioned salary is for graduate engineers. The attrition rate is terrible and its impossible to kee…

Uh, there's a massive difference between contracting on satellite systems and contracting on civil aviation systems.

In America such things are more often done by DoD contractors and they are paid well and space systems are more tightly controlled than civil aviation.

Re: A400M Airbus Flier crashed because of software issues

#49
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…

What is there to lose? 0-Day attacks. Knowledge about bugs in aviation software is potentially more valuable to people who wish to do harm than to the people who would fix the bugs, so there's a concern that someone who finds a bug will sell that info rather than let the maintainers know about it.

The other problem is that the maintainers have to be set up to handle a potential avalanche of comments, criticisms, questions, and pull requests, mostly from people who don't know anything about software development processes and standards within the aviation community. If they're already too overloaded to find all of the bugs themselves, they certainly won't be able to effectively manage open-sourcing their code.

Re: A400M Airbus Flier crashed because of software issues

#50
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…

Percieved commercial advantage and pride.
Post reply on HN