Wow!!!
Maybe it's not the dose, perhaps it's the medicine itself?

Looks like the MRO B1 put 60 kilos of Kathon in the aircraft instead of less than 2 kilos...........................

Possibly, but no more than he did with his comment.
APPL jelly has also caused damage in the past too.

Ttfn

Well, according to the AAIB Preliminary report; the LGW engineer did not even have access to the newer AirnavX.
Perhaps Airbus should only have the latest version available for use!

A reactive and unhelpful post. Now whilst the engineer may have been at fault I'm sure they did not go out of the way to make an error, no matter how serious.

Now whilst I agree that maybe the engineer did not have sufficient, knowledge and training to prevent this incident what was the root cause?

It's my opinion and only mine that gaining a B1 EASA licence is really just an matter of jumping through the right hoops and paying your money. The NCAA's within EASA are not to the same standard as each other with regards to acceptance, training and experience for engineer licencing.

The individual(s) obviously have to take some responsibility for thier actions or lack of but demanding an instant lynching is at best unhelpful.

The problem more and more nowadays is of licences being issued without sufficient experience in some NAA's, but proves the removal of a technical oral exam before licence issue was a great mistake when JAA then EASA took over from Section L.
Engineers who do not understand simple matters of how to use an AMM or what ppm is then should not be allowed anywhere near an aircraft. Days have gone when there were plenty of engineers around in hangars or on the Line, Operators have cut numbers to cut costs. However that is no excuse for not understanding how to carry out a basic task IAW AMM!

fully agree, also no mention of the MRO 145 organisation or the AMM having a procedure in place to carry out this procedure? Quality depts and EASA audits not doing their jobs. Despite all the engine start issues that preceded this there is no mention of a tech log entry. As these operators generally rely on a crew pre-flight and only log defects at end of days flying to save paying for engineering!

There's some pretty unhelpful posts here. What good does public lynching do?

There are many worrying questions that result from this incident however. Mx staff not understanding procedures and terminology, no monitoring/check of work done, competency questions, haste in getting the job done without checking if its correct first, flight crews not logging previous issues and hence lack of investigation/follow-up... yes the engineer is responsible but the wider procedural, competency and quality procedures raise many more worrying questions and there are clearly gaping holes here.

Thankfully a good ending this time but it could easily have been very different. I hope lessons are not just learned but acted upon to stop this happening again.

Charlie's Angel, thanks. Google often helps but often in these cases it descends into a labyrinth of acronym soup. From my mil career I was fully aware of flameout and surge, but only aerodynamic stall, which is why I asked.

BVCU I am not a pilot or engineer but I have to call you out on this, either you have not read the report or you have chosen to ignore the report to make a point.

Flight 1 ~ Stansted to Gatwick, Engine number 1 required more than one attempt to start, there is no mention in the report about a tech long entry.

Flight 2 ~ Gatwick to Krakow ~ the report says there were no issues and therefore no requirement for a tech log entry

Flight 3 ~ Krakow to Gatwick, ~ Page 3 of the report line 3 states the commander recorded the defect in the tech log and paragraph 2 line 4 that the engineer signed the certificate of release to service.

Flight 4 ~ Gatwick to Stansted ~ there is no mention of a tech log entry and the report does not cover the actions after landing but I would think the call to the AAIB would have been a reasonable substitute for a tech log entry in any case.

read the report but only the LGW bit was highlighted , no mention of any AMM procedure carried out for the other start faults? Have heard through the grapevine that the LGW guy is being hung out to dry allegedly.

I've always thought that specifying quantities in terms of ppm is potentially confusing. Percentage is much more easily understood or for very small percentages like this case, specifying litres per 1000 litres might be better.

Or, millilitres per litre - which comes to the same thing, but may be a bit more intuitive. Those are the units quoted in the FAA bulletin.

We can also start with selection of maintenance contractors nowadays, whether line or overhaul, with the prime consideration being who is bottom bidder.

Maintenance choices: Good, Fast, Cheap.

You only get to pick one and the airline execs always seem to pick cheap, while pretending the other 2 will magically also happen....

There is more than a little truth in that. Perhaps ‘execs’, like the travelling public, believe that all the massively costly and inconvenient ‘regulation’ they are subjected to, should mean that the ‘cheap’ ones are also ‘good’ enough.

Having seen how profoundly some maintainers have sunk, and the deep and broad coping strategies applied by some flight ops departments, including check flights conducted completely outside the applicable regulations to cover up errors, I can only conclude that the necessary wake-up call will be truly shocking. With luck, the death toll will be minimal.

Pay peanuts, get monkeys. Seeing it across all areas of the industry. Costs/expenditure cut to the bone. Exceptional demands on service yet conversely the incessant demand for reduced cost; both cannot happen, one happens at the expense of the other. Meanwhile, shareholder dividends grow and grow. All great until the inevitable smoking hole occurs with hundreds of perished souls. Things no doubt going to get even worse considering the state the industry is in right now - if there is an industry left, that is.

I'm not convinced this necessarily applies here. Ratio calculations are notoriously easy to get wrong. Even the very best people make simple mistakes when dealing with parts per million (because it adds an extra step to a calculation) and this is likely exacerbated when working at night, tired, and under time pressure. There are some simple and obvious steps that can be taken to prevent this happening again:

1. Provide a worked example of the calculation in the maintenance manual.
2. Provide an electronic calculation in the maintenance manual (input contamination, biocide, fuel quantity and it spits out the required dose).
3. Supply the biocide in smaller containers. Even the person who's absolutely confident of their calculation will think again if they realise they have to log, open and pour (for example) 60 bottles of the stuff into the aircraft.

Surely any ongoing competency assessment/training would account for this? As I previously said, many uncomfortable questions opening a can of worms, all too easy to blame the individual and not the organisational and procedural failings.

I do agree that stipulating a heavy engineering operational instruction in ppm is almost deliberately making things difficult. But we can extend our discussion of "cheap" to the maintenance manual production, where once upon a time a professional in house technical documentation author would never have simplistically written it like that. Instead outsource the production, again to the low bidder, and they will just whack in the product manufacturer's spec sheet without consideration.

Steve Jobs, when he led Apple Computers, had a "thing" about simple and straightforward. The first demonstration of any major new product was to him. If there even one ambiguous or surplus operation (in his mind) he used to blow up the team members there and then, who thus knew to take infinite care to get it all the best that could be done. This additive instruction would absolutely fail the Jobs test - complex calculation not explained, technical abbreviation not explained, abbreviation not commonly used elsewhere (otherwise the operative would be familiar with it), abbreviation of something not in the operative's own language, etc.