Indonesian aircraft missing off Jakarta

[CONSO]

Originally Posted by MickG0105

50 rotations would be required to manually trim back to 5.0 units of trim from the full nose down position (0 units). Time to accomplish that would be dependent on the effort required.
The NG FCOM notes:

The NG FCTM notes:


With full nose down trim and full nose up elevator at 300 knots at 5000 feet you'd expect that there would be a significant air load on the stabiliser.

AND AT 5000 FT and 300 plus mph and at least a 45 degree dive angle- they would have perhaps 20 to 30 seconds to impact. IF ( big assumed IF ) they trimmed to nose up in 10 seconds, IMO its doubtful the resultant flight path would have
avoided impact.

And thats without a WTF startle factor . .

[birdspeed]

Perhaps, the sudden dive can be explained by a loss of elevator effectiveness. I speculate that they exceeded the breakout force on the control wheels. Suddenly they would lose a good percentage of elevator control and the aircraft would bunt over. The sudden shock/negative g stopped their sustained NU trimming allowing the MCAS to apply full ND!

The FDR trace seems to show a difference of control force just before the dive.

[ROW_BOT]

Originally Posted by Rated De

We are aware that as the 'airline business' became more a business and less an airline.
The slowed but continued march towards a financial reason (hence cost) for everything eventually brings with it consequences..
Captain Sullenberger, recites a story he read in an aviation magazine which sums it up.

The retiring airline Captain reflecting on his career stated "We used to be selected and assessed on our judgement. Now we are selected and assessed on our (corporate) compliance."

'Commercial pressures' and all that....

Indeed - but it’s even more true for Flight Ops Management, who have become the Bean Counters enforcers.

i recently had one such fool encourage me to operate unsafely with the comment that “a ship that stays in harbour is safe, but that’s not what ships are for”.

Now think about that mentality in terms of this Lion Air flight and you’ll understand why all those people are dead.

[Rated De]

Originally Posted by ROW_BOT

Indeed - but it’s even more true for Flight Ops Management, who have become the Bean Counters enforcers.

i recently had one such fool encourage me to operate unsafely with the comment that “a ship that stays in harbour is safe, but that’s not what ships are for”.

Now think about that mentality in terms of this Lion Air flight and you’ll understand why all those people are dead.

That is precisely the inference.

[Derfred]

Which is why I posted this a week ago:

Originally Posted by Derfred

The only thing that has been released in the media is the Boeing AD regarding MCAS. It hasn’t been concluded that MCAS was the primary cause of the accident, however, given the publication of the AD, it has been the main subject of conjecture on this forum as a “contributing factor” (thank you lakedude).

Most accidents prove to have several “contributing factors”, and I’m sure this will be one of them.

I would suggest that the eventual analysis will include other contributing factors, including the quality of maintenance (given the evidence of the previous 3 sectors), and the quality of training (given that this event should have been survivable if indeed it was only an air data problem).

I don’t work for Boeing, but given the track record of this operator, I am really surprised at the outburst against Boeing on this thread. Boeing is not in charge of maintenance standards or training standards at customer airlines. If you want to buy a ticket to fly on a low cost airline, you carry a risk. Until the planes start crashing, low cost operators will continue to reduce standards. Eventually they will reach a point where the planes start crashing, and tragically, people will die. I will leave it to the community to decide when that point has been reached.

[bsieker]

Originally Posted by Derfred

Which is why I posted this a week ago:

I don’t work for Boeing, but given the track record of this operator, I am really surprised at the outburst against Boeing on this thread. Boeing is not in charge of maintenance standards or training standards at customer airlines. If you want to buy a ticket to fly on a low cost airline, you carry a risk. Until the planes start crashing, low cost operators will continue to reduce standards. Eventually they will reach a point where the planes start crashing, and tragically, people will die. I will leave it to the community to decide when that point has been reached.

True, maintenance and operations will most likely be found to be causal factors in this one, but so will the possible lack of adequate briefing for a new system and also the engineering design of said system, including the (possible lack of appropriate) hazard assessment for possible failure modes including the handling of erroneous input data. System engineers cannot simply say "our system always works perfectly given correct input data." Designing the system to expect and handle totally wrong, missing, delayed, corrupted, slightly wrong and all sorts of other less-than-perfect input data is part of due diligence. This includes estimates of the probability of such wrong data, and thorough analyses of what could possibly go wrong in the worst case.

This was supposed to be a system to prevent accidents, but it is quite clear that in this case it was a causal factor of an accident. It is hard, or maybe impossible to say how many accidents it has prevented (plausibly: none). Given the law of small numbers one cannot yet say that the MAX would be better off without the system altogether, and some system was also arguably required to fulfill certification criteria for longitudinal stability. Such systems have a long tradition, often in the form of stick pushers, to mitigate adverse aerodynamic effects. Using hardware already available is a "cheap" solution, compared to the complexities of an actual pusher, but in terms of certification, "just good enough" is good enough.

And despite your protestations, Boeing does have a word to say about maintenance standards and training standards at an airline wishing to operate their hardware.

Bernd

[Derfred]

Partly agreed, and probably Boeing needs to accept some culpability with MCAS redundancy/fault tolerance, but with good maintenance and training it’s likely this thread wouldn’t exist.

Unlike many posters here, I seriously doubt that a crew that couldn’t handle this event would have behaved any differently if an MCAS description had been included in the B737MAX FCOM. I suspect that this aircraft did not crash due to lack of pilot system knowledge regarding MCAS.

Is it a coincidence that a low cost carrier such as this one was the first to discover that MCAS+AOA FAULT+PILOT FAULT= CRASH?

Of course, they didn’t discover it at first, they had to keep putting the aircraft up there with different pilots until they found pilots who couldn’t handle it.

Despite a report not yet being published, the information available indicates that the aircraft had a fault which thankfully, due to good pilots, returned to earth safely. The airline returned the aircraft to the air not once but three times with the fault not verified to be resolved. The pilots of flight number 4 were not able to fly it back safely. You can point at Boeing for system design, but you can’t point at them for this sequence of events. This would not happen in any decent airline.

And despite your protestations, Boeing does have a word to say about maintenance standards and training standards at an airline wishing to operate their hardware.

Not to the the extent that prevents a low-cost carrier from operating a poorly maintained jet with a poorly trained crew. That is not Boeing’s job. That role rests with the Airline and the local regulatory authority .

I maintain my point.

[glad rag]

Which was?

Did Boeing include the operation of the suspect systems in the manuals available to the crew of the accident aircraft?

[Derfred]

Originally Posted by glad rag

Which was?
Did Boeing include the operation of the suspect systems in the manuals available to the crew of the accident aircraft?

I thought I made my opinion on that subject clear: (edit: I did edit my post, you may have responded before this, sorry)

Unlike many posters here, I seriously doubt that a crew that couldn’t handle this event would have behaved any differently if an MCAS description had been included in the B737MAX FCOM. I suspect that this aircraft did not crash due to lack of pilot system knowledge regarding MCAS.

[Ian W]

Originally Posted by bsieker

This was supposed to be a system to prevent accidents, but it is quite clear that in this case it was a causal factor of an accident. It is hard, or maybe impossible to say how many accidents it has prevented (plausibly: none). Given the law of small numbers one cannot yet say that the MAX would be better off without the system altogether, and some system was also arguably required to fulfill certification criteria for longitudinal stability. Such systems have a long tradition, often in the form of stick pushers, to mitigate adverse aerodynamic effects. Using hardware already available is a "cheap" solution, compared to the complexities of an actual pusher, but in terms of certification, "just good enough" is good enough.
Bernd

I don't think that you can say that anymore than you can say that the ADIRUs that gave UAS indications due to the same AOA vane fault and caused the FMS to remain unengaged were a causal factor., Had the crew cut off the stab trim when it repeatedly re-trimmed ND for them - this crash would not have happened. The causal factor if any was the AOA disagree that was allowed to propagate errors through the system, all errors that could be and were handled by the crews on the previous flights. If there was a reasonableness check of AOA using other non-pressure instrument indications then a grossly misreading AOA vane could be identified and disabled. The organizational fault is that an aircraft with a fault that repeats over several fights should be grounded for a full maintenance check and then given a test flight without pax by a crew that have been fully briefed on the fault and symptoms and self briefed on the actions to be taken if those symptoms recur.

[bsieker]

Originally Posted by Derfred

This would not happen in any decent airline.

Perhaps. But it is much better to have an aircraft where this cannot happen at any airline.

There are always multiple factors, and if either of them can be fixed, it reduces the total risk of a similar accident. Saying, "Oh, the system was ok, a good pilot and a could airline would not have had any problems" is not helpful. Neither is saying "There was a flight crew who could handle it, so just these bad pilots couldn't."

There are two points to make:

1. I seem to recall that on the first flight with divergent AoA values, the Flight Control Computer operated the MCAS based on the correct AoA sensor, so there was no problem for the pilots (except the stick shaker: continuing with that is also a very ... interesting decision), whereas on the accident flight, the MCAS used the faulty AoA sensor so continued to trim nose-down. It did not do so on the previous flight. So yes, in this case the airline not rectifying the problem was a causal factor, but it is just as credible that this could have happened on the first flight on which the fault appeared, and then the airline would have no part in this.
2. Pilots without exceptional skills must be able to handle an aircraft with a single technical fault. That is a certification requirement, which one may argue was violated by this design.

Cheers,
Bernd

[lomapaseo]

And despite your protestations, Boeing does have a word to say about maintenance standards and training standards at an airline wishing to operate their hardware.

agree BTDT.
but not as a pre-review process, which is a regulator function (unless requested), but data based afterwards they have a duty to warn

[wiedehopf]

Originally Posted by bsieker

1. I seem to recall that on the first flight with divergent AoA values, the Flight Control Computer operated the MCAS based on the correct AoA sensor, so there was no problem for the pilots (except the stick shaker: continuing with that is also a very ... interesting decision), whereas on the accident flight, the MCAS used the faulty AoA sensor so continued to trim nose-down. It did not do so on the previous flight. So yes, in this case the airline not rectifying the problem was a causal factor, but it is just as credible that this could have happened on the first flight on which the fault appeared, and then the airline would have no part in this

That's not true. Look at the FDR, it is quite clear MCAS operated on the previous flight.
They used the cutout and trim wheel:





As we are unsure of the MCAS system architecture it seems the other FCC being active doesn't mean MCAS only triggers for one of the FCCs when one AoA is high.
Also didn't i read somewhere both FCCs get both AoA values as an input?

The 2 flights before that were not plagued by the incorrect AoA but some other problem, at least that's how i read the various news reports.
(Edit: There are no news reports to that effect my memory tricked me. But looking at the FR24 data and the altitude excursion MCAS produced on the last two flights it is reasonable to assume that an AoA problem that severe did not exist on the flights before the sensor replacement)
The vastly wrong AoA value was most likely introduced due to the replacement of the AoA sensor in Denpasar.
(Be it due to a defective / wrong part or some unbelievable hackery no one knows)


If you want to look at the FDR graphs yourself please check out the pdf in the attachment:

[PEI_3721]

infrequentflyer789, #1637. Interesting; very useful descriptions and analysis in the link at #1634, and to other web pages. Also from Tech Log discussion.
These points address previous questions re the EFIS display of erroneous AoA (if fitted), possibly misleading low speed awareness, and obviously stick shake, all before MCAS became active. (Hazards and mind-shaping problems before MCAS cycles the trim).

The suppositions about flap selection are pertinent. If the crew were managing the false stick shake (low airspeed indication from takeoff onwards), then the subsequent flap cycle could be a logical response to the additional MCAS trimming.

Later supposition is reasonable based on the systems descriptions and MCAS logic. With the trim issue apparently under control, but still cycling, the focus of fault finding may have reverted to stick shake and low speed awareness - UAS (was that written up in previous tech-log entries). This may have involved change of control and concluding a misidentified stall (cf reversed AF 447 mentality) thus thrust addition, allowing the nose to lower and speed increase, before the trim, stick force, increasing airspeed prevented recovery.

The views on dual architecture (link) are similarly interesting. IIRC in the THY accident the aircraft did not have the FCC software mod which would have disconnected the AP AT with RA Failure (other aircraft did), no RA disagree alert due to lack of dual architecture.
Perhaps a similar design issue with a single AoA input to FCC / MCAS, in what is an essentially dual aircraft.

previous link https://www.satcom.guru/2018/11/firs...ight-data.html

[Derfred]

The 2 flights before that were not plagued by the incorrect AoA but some other problem, at least that's how i read the various news reports.

I don’t share your memory. I have not seen any reports from the 2 flights before.

I’m sure the investigators are looking at those flights, but so far, no leaks to my knowledge.

There is a big question of course, due to the knowledge that an AoA vane was swapped out during the transit between flights 2 and 3 (if we can number them 1-4, 4 being the accident flight).

That AoA vane was swapped out for a reason, but we don’t exactly know the reason. It is reasonable to assume it was swapped out as a troubleshooting attempt from a pilot report of an air data problem from the incoming flight, Now this is where it gets interesting, and this is where we need information that we simply don’t have.

So, I try to keep my comments relevant to Professional Pilots.

Technical discussions can be carried on in the Tech Log forum, and there is one regarding MCAS.

[Derfred]

Originally Posted by PEI_3721

Later supposition is reasonable based on the systems descriptions and MCAS logic. With the trim issue apparently under control, but still cycling, the focus of fault finding may have reverted to stick shake and low speed awareness - UAS (was that written up in previous tech-log entries). This may have involved change of control and concluding a misidentified stall (cf reversed AF 447 mentality) thus thrust addition, allowing the nose to lower and speed increase, before the trim, stick force, increasing airspeed prevented recovery.

This crew wasn’t doing UAS, that’s clear from the data.

But change of control is certainly one hypothetical, which could explain the sudden plunge after maintaining control for several minutes... eg one pilot says “handing over, I need to find the circuit breaker for this stick shaker....” - if so it would sound disturbingly like the Air Asia Indonesia fatality.

[b1lanc]

Originally Posted by Derfred

I don’t share your memory. I have not seen any reports from the 2 flights before.

Source Reuters and many other media outlets Nov. 5th
"Safety Committee (KNKT) said on Monday an airspeed indicator of a Boeing Co. 737 MAX plane that crashed last week killing all 189 people on board was damaged for its last four flights.The damage was revealed after data had been downloaded from the plane's flight data recorder, KNKT chief Soerjanto Tjahjono told reporters, adding that it was asking Boeing and U.S. authorities what action to take to prevent similar problems on this type of plane around the world."

[Airbubba]

The New York Times has posted this update on the crash:

Black Box Data Reveals Pilots’ Struggle to Regain Control of Doomed Jet

By James Glanz, Muktita Suhartono and Hannah Beech

Nov. 27, 2018

Data from the jetliner that crashed into the Java Sea last month shows the pilots fought to save the plane almost from the moment it took off, as the Boeing 737’s nose was repeatedly forced down, apparently by an automatic system receiving incorrect sensor readings.

The information from the flight data recorder, contained in a preliminary report prepared by Indonesian crash investigators and scheduled to be released Wednesday, documents a fatal tug-of-war between man and machine, with the plane’s nose forced dangerously downward more than two dozen times during the 11-minute flight. The pilots managed to pull the nose back up over and over until finally losing control, leaving the plane, Lion Air Flight 610, to plummet into the ocean at 450 miles per hour, killing all 189 people on board.

The data from the so-called black box is consistent with the theory that investigators have been most focused on: that a computerized system Boeing installed on its latest generation of 737 to prevent the plane’s nose from getting too high and causing a stall instead forced the nose down because of incorrect information it was receiving from sensors on the fuselage.

Details of the black box data were contained in a briefing for the Indonesian Parliament and were first disclosed publicly in the Indonesian media. The data was subsequently posted and analyzed in a blog post by Peter Lemme, a satellite communications expert and former Boeing engineer.

Despite Boeing’s insistence that the proper procedures were in the handbook, also called the emergency checklist, pilots have said since the accident that Boeing had not been clear about one potentially vital difference between the system on the new 737s and the older models. In the older versions, pilots could help address the problem of the nose being forced down improperly — a situation known as “runaway stabilizer trim” — by pulling back on the control column in front of them, the pilots say.

In the latest 737 generation, called the Max, that measure does not work, they said, citing information they have received since the crash. The pilots on Lion Air Flight 610 appear to have forcefully pulled back on their control columns to no avail, before the final dive, according to the information from the flight data recorder.

Capt. Dennis Tajer, spokesman for the American Airlines pilot union and a 737 pilot, said he could not comment on any aspect of the investigation. But, he said, “in the previous model of the 737, pulling back on the control column, Boeing says will stop a stabilizer runaway.”

Information provided to American Airlines from Boeing since the crash, Captain Tajer said, “specifically says that pulling back on the control column in the Max will not stop the runaway if M.C.A.S. is triggered. That is an important difference to know.”

The futile struggle by the pilots to regain control can be seen in colorful jagged lines in graphs contained in the report to the Indonesian Parliament, documenting the seesaw motion of the nose as the system pushed it down at least two dozen before the plane’s fatal nose-dive.

From the moment Flight 610 took off just after dawn from the airport in Jakarta, the Indonesian capital, the Max 8 jet was recording errant data from one of the two angle-of-attack sensors on the nose of the plane that records the pitch at which a plane is climbing or descending.

https://www.nytimes.com/2018/11/27/w...ir-crash-.html

[Rated De]

Capt. Dennis Tajer, spokesman for the American Airlines pilot union and a 737 pilot, said he could not comment on any aspect of the investigation. But, he said, “in the previous model of the 737, pulling back on the control column, Boeing says will stop a stabilizer runaway.” Information provided to American Airlines from Boeing since the crash, Captain Tajer said, “specifically says that pulling back on the control column in the Max will not stop the runaway if M.C.A.S. is triggered. That is an important difference to know.”

Would seem a little simplistic to let the manufacturer off the hook just yet.

[threemiles]

Digital world

I still wonder how the MCAS trim down logic was certified based on a single AOA input. Even if this has a reason that is buried somewhere between FAA and Boeing, there are plenty of other sensors/data available that could help the MCAS computer to determine it shall better not trim down, like pitch, roll, radio height, gps vertical rate, ground speed, you name it.

We build autonomously driving cars with amazing intelligence identifying objects and doing some kind of plausbile action. But we cannot program a simple logic for a commercial aircraft that carries 200 people that says: when pitch is normal AND there is no excessive bank AND at 5000 ft radio height AND at 300 kts ground speed, this MCAS system better does not push, but presents a caution about implausible sensor data? No, we can't, because of certification grandfather rights thinking. Just touch what's absolutely necessary.

This fits perfectly into the picture that an AOA disagree indicator is sold as an option, i.e. Boeing tries making money by upselling a safety feature, and the FAA grants them doing so.

​​​​A trim runaway is always a serious incident. Just saying, there is the pilot as a backup, he just needs to run the memory items and all is good, is too easy. This thinking is out of time. The age of analog heros is over, we live in a digital world. Hundreds of complex rules of ANDs and ORs and IFs on a digital flight deck are overwhelming human beings. The digital system must help itself, at least to some extent.