Airbus A400M - Atlas C1

RIP


Hopefully those who survived the initial crash can pull through.

Michel Van said:
about those parallel burn marks on right of wreckage (see Picture in Deino post)
According latest news the A400M hit High voltage lines prior the crash
I was wondering about that as well. It definitely catches one's eye. Possibly scorch marks from fuel that spilled from the wreckage into the furrows in the field and burned? :-\
 
According the german New Magazine "Der Spiegel"
had the A400M multiple engine failure direct after take off


The French military gave short stamen that that there A400M fleet stay operational
despite the accident and grounding at german Britain and turkey


http://www.spiegel.de/wirtschaft/unternehmen/a400m-ueberlebender-berichtet-von-triebwerkschaden-a-1033103.html
 
http://www.telegraph.co.uk/news/worldnews/europe/spain/11595899/Heroic-Spanish-farmer-dragged-survivors-out-of-Seville-plane-crash.html
 
According to the German news site DER SPIEGEL, the A400M crash was caused by software malfunction which led to failure of three engines after take-off. Apparently three engines received contradictory orders from the computers.
Link: http://www.spiegel.de/politik/ausland/airbus-a400m-militaermaschine-stuerzte-wegen-software-problemen-ab-a-1034421.html
 
If that holds up I'm pretty concerned about France choosing to continue flying their aircraft. Unless the Turks were going to get their own software, or it was a known bug that was already being scrubbed out, it would seem at first glance prudent that all aircraft with that software build should be grounded.
 
Es gebe einen Test, mit dem man zweifelsfrei klären könne, ob die Steuerungseinheit der Triebwerke den gleichen Fehler habe wie der Unglücksflieger, so ein Airbus-Sprecher zu SPIEGEL ONLINE


According to the article there is an unambiguous test available to check if a specific aircraft is affected or not by the software issue.
 
Thanks for the translation, that would certainly resolve the question of which aircraft are effected.
 
LONDON – Incorrectly installed engine control software caused the fatal crash of an A400M airlifter in Spain on May 9, a senior Airbus Group official says. In an interview with the German financial newspaper Handelsblatt, Airbus Chief Strategy Officer Marwan Lahoud said the incorrect installation took place during final assembly of the aircraft, which led to engine failure and the resulting crash. Lahoud said that data extracted from the flight data recorder this week and seen by ...From Aviation Week
 
It is unbelievable,how could 3 engines fail like this,isn't there any safeguards on the software to prevent this from happening,isn't the pilot suppose to be immediately warn on the failure of one engine?




regards


Pedro
 
Airbus and their software


http://www.economist.com/blogs/gulliver/2011/12/air-france-flight-447


"...Over the decades, airliners have been built with increasingly automated flight-control functions. These have the potential to remove a great deal of uncertainty and danger from aviation. But they also remove important information from the attention of the flight crew..."
 
From the comments section of that article, a very pertinent comment:
I've noticed that enthusiasm for automated control occurs most often among people who are outside the IT industry.

I am put in mind of the comment of a colleague many years ago. It has application far broader than the specifics he points to:
All of American [now world] business is critically dependent on millions of lines of computer code . . . written by people with no visible qualification to have done so.

Apply that to aircraft controls, or any other automated system, and you see the problem.

No offense to the people who write the computer code. But their priorities are, in every case I have seen in 4 decades in the business, focused primarily on other things: First, on completing something by the deadline (set, generally, with no reference to how complex the task is). And secondarily on including all of the functions demanded. Robustness, performance, allowing for unlikely combinations of inputs -- the folks writing the code are often professional enough to want to address those. But their management demands other priorities of them.
 
pedrospe said:
It is unbelievable,how could 3 engines fail like this,isn't there any safeguards on the software to prevent this from happening,isn't the pilot suppose to be immediately warn on the failure of one engine
regards
Pedro
its systemic, the three shut downs would not be independently caused.
 
late news on case

It said the focus of the inquiry was a theory that files known as "torque calibration parameters" had been accidentally deleted during a software installation process ahead of the plane's first flight.
this was now confirmed to the BBC.

Those parameter files are used by the Electronic Control Units to interpret sensor readings about the turning force generated by each engine.
which is used to make the attached propellers spin, now without the files, the ECUs cannot make sense of this data.
That explain why three of the plane's four engines did not react to the crew's attempts to adjust their power settings shortly after take-off.


Source
http://www.bbc.com/news/technology-33078767
 
Who was responsible for the badly written software that caused the crash in the first place? Heads should roll in Airbus. :mad: :eek:
 
From what I've read, a software installation fault was at the heart of the matter. This would mean there are procedures to be fixed, not necessarily the software itself.
 
The software could use some checks to make sure the software and data files on board are valid and complete before relying on them.
 
When I started testing FADECs on helicopters in 1990 the engine control system had a manual reversion mode that allowed direct mechanical manipulation of the fuel control if the FADEC froze or dropped off line. I guess this may not possible on a fixed wing, on the helicopter you assumed that at least one FADEC remained functional to control and limit things like rotor RPM and torque. Still, I'm thinking the Airbus crew would have gladly over-torqued or over-temped an engine or three to soften the landing.
 
Hobbes said:
The software could use some checks to make sure the software and data files on board are valid and complete before relying on them.

On systems I'm familiar with there is a QA check to make sure the loaded software is a complete and accurate copy of a master file. But this assumes the master file is correct. This may be a QA failure further up the chain than the aircraft or the flight line.
 
Grey Havoc said:
From the comments section of that article, a very pertinent comment:
No offense to the people who write the computer code. But their priorities are, in every case I have seen in 4 decades in the business, focused primarily on other things: First, on completing something by the deadline (set, generally, with no reference to how complex the task is). And secondarily on including all of the functions demanded. Robustness, performance, allowing for unlikely combinations of inputs -- the folks writing the code are often professional enough to want to address those. But their management demands other priorities of them.
Clearly the correspondent never worked on a flight controls team (and I've no reason to assume FADEC teams are any different, the quality requirements for safety critical software we work to are industry wide). We usually had more people trying to break the software than writing it. Every module of code had one set of people turning requirements into code, and another set of people turning that same requirement into a test harness to either confirm the requirement had been correctly implemented, or show it hasn't. And then another set of people working to demonstrate that module A and module B both still worked when combined together. We really don't work like the rest of the software industry, especially the non-real time, non-safety critical parts. By the time we've finished, every decision point in the code should have been tested at boundary values (decision coverage), every line of code confirmed to act correctly (code coverage). We even construct mathematical proofs of the software requirements and have that compiled and checked as an integral part of the development process - see 'design by contract'.
And then we had customer QA, and National Airworthiness Authority QA coming in and staring over your shoulder while we worked - I regularly had to take them through things like 'show me how requirement X was implemented from initial receipt' and I'd be able to show them who had signed off on incorporating it, who had done the design work, who did the coding, who checked the coding, who updated the test harness, who checked the test harness, who ran the test harness, and ditto for integration testing.
Note also that the correspondent calls for testing vs 'unlikely combinations of input', yet it is not possible to cover all possible combinations of inputs within the lifetime of the universe for software of the complexity we are discussing here. Picking any random sample of inputs has zero value.
As for that 'no visible qualification' snark, the only qualification that matters is being able to get your code through testing. There simply aren't specialist training programmes for this kind of stuff outside of the manufacturers.
What all of this can't protect us against are errors in the original requirements, or operator errors that somehow invalidate the assumptions made in those requirements.
 
Bill Walker said:
On systems I'm familiar with there is a QA check to make sure the loaded software is a complete and accurate copy of a master file. But this assumes the master file is correct. This may be a QA failure further up the chain than the aircraft or the flight line.
The installation process should include a checksum calculation that confirms the software and data files installed on the aircraft are complete and as originally generated during the build and release process (I've done builds and releases across multiple projects). What that can't protect you against is someone loading the wrong data file. If you want the software to work with updateable data files, because you're using them to fine-tune performance without actually changing the software design, then you have to take it on trust that the data file being installed is correct for the current build of software and the current engine configuration (it was an error in matching software build and engine configuration that resulted in the loss of Eurofighter prototype DA6, IIRC). This sounds like an error on the flightline to me, though this kind of developmental installation might still be done by someone on the software team.
The idea that they managed to delete the config files seems bizarre to me, installation is typically an overwriting process, not something where you would delete the file as one step and then re-write it as a separate process where you could forget the second half, though I could see overwriting the previous code with a fixed pattern to wipe it as part of the installation programme, but then immediately followed by the update with the new code as a single process (this isn't like updating a file on a PC, typically you're writing directly onto memory chips with no operating system in between - flashing a BIOS should be a close analogy). It's the idea they did one and not the other that seems bizarre, together with the idea that they then got through checksum checking without it flagging the error (and I don't see WTD 61 or its UK equivalent letting them get away with not having checksum checking as part of the install process). Installing an incompatible version of the data file sounds much more likely to me than simply deleting the file, but the reports we're hearing are potentially the result of some PR hack trying to translate a software installation process into something the layman would understand, so the jury is out. I'm going to be fascinated to hear the precise failure mechanism.
 
"It was not foreseen that three propellers would be affected simultaneously, making it impossible to keep the plane airborne." (from the BBC report)
Common mode failures - the same fault happening at the same time on multiple pieces of equipment because they're all running identical software - are one of the standard failure modes your risk management safety case should address. I've worked on systems with multiple different processors and software builds to minimise the risk, but ultimately you have one common set of requirements, which mean you can't eliminate it (and that the multiple different processor/software approach isn't particularly valued by the airworthiness authorities). One of the things that means is that you should have a safety case for what happens when everything fails. In this case it looks like Airbus's decision was keep everything at flight idle, which prevents nasty stuff like overspeeds causing fires in the engine, or worst case stuff like blade separation into the fuselage or wing. Even if you lose all four engines to flight idle as a result that doesn't mean the decision is wrong, it may be the correct decision in more scenarios than it is the wrong one, and this being the wrong one doesn't invalidate that. Even with all four engines powered down to flight idle you still have a glider, admittedly a big, ungainly one, and a chance to put it down on a field somewhere ahead of you.
We're possibly getting into areas where there is a philosophical difference between Airbus and Boeing, Airbus feels the software should have the final word in envelope protection, Boeing thinks the pilot should*, my feeling is they're both right, and that in about 50% of cases you'll be better off with the Airbus philosophy, and in about 50% of cases you'll be better off with Boeing, but you don't know which it is until after the event.
* It's important to note that the most common cause of aircraft hull losses is Controlled Flight Into Terrain as the result of pilot error, giving the last word to the pilot doesn't necessarily agree with what the accident stats tell us.
 
"Airbus Mulls Bringing A400M To US"
By Colin Clark
on June 15, 2015 at 7:42 AM

Source:
http://breakingdefense.com/2015/06/airbus-mulls-bringing-a400m-to-us/

UPDATED: Air Force Acquisition Head LaPlante Leaves Door Open For Airbus

PARIS AIR SHOW: The A400M can do things no C-130 can. It’s much bigger than a C-130. The air platform is reportedly incredibly stable in flight, raising the possibility of launching rockets from it or putting high accuracy guns on it.

But it’s got a few problems. First, it’s European. Second, much of the senior Airbus leadership remains deeply scarred by their experience with their last big American sales effort, the failed attempt to sell the Air Force the A330 tanker, first with Northrop Grumman and then through their American subsidiary, then called EADS, now known as Airbus Americas.

UPDATE BEGINS The door for a visit was — encouragingly — left wide open this afternoon by the head of Air Force acquisition, Bill LaPlante. “In general, when we talk to Airbus, we think the more the merrier in terms of getting industry to think about our missions,” he said. “We understand there’s the history with the tanker.” He noted that, “we’ve been trying to bring Airbus in to our CEO roundtables.” UPDATE ENDS

I heard last year that Airbus was hopeful of beginning the briefing process in the Pentagon, catching the ear of some Air Force or Special Operations Command leaders.

But few American fliers know anything about the A400M Grizzly. It’s much bigger than the C-130 since it was designed to give Europeans something they didn’t have: strategic lift. It can carry big loads a long way. For example, the French military can now fly a helicopter to the fight aboard an A400M instead of shipping it in pieces and reassembling it.

But an A400M crashed in May, killing four crew members. Incorrectly installed flight software was found to be the cause. This morning, with French President Francoise Hollande watching. an A400M soared over the field at Le Bourget Airport, completing some combat climbs and sharp turns to demonstrate the plane is back and remains safe.

Now the company must decide the benefits and risks of bringing an A400M or two to the United States to show off its impressive capabilities. Will American lawmakers reflexively oppose a European plane, even one from an ally as staunch as France has been since 9/11? The Army is buying the Lakota helicopter from Airbus Military. In fact, the Lakota is on display in the American corral here at the show.

If I were an Airbus executive and wanted to test the market, I couldn’t think of a better way to do it than bringing the A400M to America for a week or two and showing off its capabilities — especially to SOCOM. We’ll see what they decide.
 
"Airbus says US to be biggest customer for A400M military plane"
June 12, 2015

Source:
http://news.yahoo.com/airbus-says-us-biggest-customer-a400m-military-plane-103700613.html


Frankfurt (AFP) - European aircraft maker Airbus believes the United States will be the biggest customer for its A400M military transport plane, despite a fatal crash involving one of them during a test flight last month.

"By the next decade at the latest, the US armed forces will be the biggest customer for the aircraft," Airbus chief executive Tom Enders told the weekly magazine WirtschaftsWoche in an interview.

Despite its current technical problems, there was no other rival product at the moment, Enders argued.

Boeing's C-17 was larger and Lockheed Martin's C-130 was smaller.

"But a lot of countries don't want either extreme. For the next few years, there will only be one alternative, the A400M, which is also a lot more fuel-efficient and more versatile," he said.

An A400M plane crashed during a test on May 9 near Seville in Spain, killing four of the six people on board and seriously injuring the two others.

The A400M, a large, propeller-driven transport aircraft, was launched in 2003 and is assembled in Seville. But Britain, Germany, Turkey, Malaysia and Spain grounded their A400M planes after the crash.

An initial analysis of the black boxes revealed that three of the aircraft's four engines failed, Airbus has said.

Enders said Airbus was sticking to its sales and earnings targets for this year, despite the crash.

"We're on the right path to achieve our published goals for 2015," the CEO said.

Airbus is looking to increase both sales and earnings this year.

"In 2014, our operating profit was four billion euros on sales of 60 billion euros," he said. Cash flow was positive, at 88 million euros, compared with a negative cash flow of around one billion euros in 2013.

Turning to the possibility of upgrading its super jumbo A380, Enders said a decision would be reached by the end of this year.

"The administrative board will need until the end of the year to get a full picture of the situation and to reach a decision," Enders said.

"It is one of the most difficult product decisions of the last few years. But it's clear: there won't be an A380 with new engines for just one customer."

Dubai's Emirates Airline in particular is pushing for a more fuel-efficient variant of the superjumbo.

Enders said Airbus had succeeded in reducing fuel consumption of the A380 by several percent even without the engines.

"One option I'm concretely thinking about would be innovations in the cabin," he said, adding that new engines would be one of a number of possible engines.
 
http://www.wsj.com/articles/airbus-profit-falls-50-in-first-quarter-1461821681 (Registration may be required)

The company, which has struggled for years with the development and production of the A400M program, has suffered new problems with a component of the plane’s engine. Mr. Enders said the issue was “a serious challenge” and called it “very frustrating.”

The program’s problems have ranged from the aircraft’s large turbo-propeller engine to some of its complex systems, having put the program years behind schedule and billions of dollars over cost. Airbus last year booked a €290 million charge on the project following the first crash of an A400M in Spain, which killed four of six company employees on board. The company previously had reshuffled management to right the project.

Mr. Wilhelm said the situation with the A400M is less severe now than several years ago when there was a risk the program could be abandoned. He said the chance of plane cancellations by customers was “very remote.”

The company had targeted at least 20 deliveries of the planes this year, but Mr. Wilhelm said the figure was currently uncertain.

The European plane maker has secured 174 orders for the A400M, with Malaysia the only customer beyond a group of six European countries and Turkey backing its development. Without additional deals, Airbus will lose money on the project, the company has said.
 
Airbus takes new €1.3bn hit on A400M troop carrier

Airbus has written off another €1.3bn (£1.2bn) on its troubled A400M military transport plane, bringing total losses on the project to more than €8bn.

http://www.bbc.co.uk/news/business-43069630
 
What comes next ? Airbus buying back its client's orders?

8b€ (10b$) and not a single head rolling down the gutter...

French MoD lately was screaming after the Eu industry lack of orders but what is the urgence when there is ample airbags to soften the fall from even the most stupid mishap?

(feeling nauseous)
 
They are of course trying to put the best spin on things at Farnborough:


 
Last edited by a moderator:
(Registration may be required)
 
Around time of my birthday in Sept last year I popped to RAF Mildenhall so here are my photos of Ejercitio del Aire A400M laughinfly helping out Aviano based 31st FW by moving their kit from UK deployment at RAF Lakenheath back to Aviano.

cheers
 

Attachments

  • 3F72AFC9-47FF-4311-B667-F37EB568B16C.jpeg
    3F72AFC9-47FF-4311-B667-F37EB568B16C.jpeg
    56.1 KB · Views: 53
  • 850536CE-60C1-4302-AFA3-707855D716D0.jpeg
    850536CE-60C1-4302-AFA3-707855D716D0.jpeg
    66.7 KB · Views: 26
  • D8DC7255-D6E3-4570-BD76-93E942E6072E.jpeg
    D8DC7255-D6E3-4570-BD76-93E942E6072E.jpeg
    63.5 KB · Views: 26
  • D9BA0CD9-7832-4824-8E54-C6F2D549C023.jpeg
    D9BA0CD9-7832-4824-8E54-C6F2D549C023.jpeg
    75.4 KB · Views: 25
  • D70B7CB0-C890-4A95-99D7-5BFFF3DEB351.jpeg
    D70B7CB0-C890-4A95-99D7-5BFFF3DEB351.jpeg
    66.7 KB · Views: 47

Similar threads

Please donate to support the forum.

Back
Top Bottom