Ethiopian airliner down in Africa

[EDLB]

Originally Posted by GordonR_Cape

High order bit correction is mostly used in noisy transmission neworks, such as phones and satellites. If you have interference on the data lines in your brand new aircraft, then there are much more serious things to worry about.

Thats valid only if there is no fault in the harness, connection and in all receiving devices. With a single parity bit for 32 bits it’s as good as no protection at all. What if your data line signal noise level becomes marginal because of one failed receiver or a harness problem? You will process false data which are still valid and look as good data. In automotive CAN for example there is a more robust CRC protection and the same as your above argument for the system can be made. Troubleshooting of intermittent problems is much easier if you can get a fault statistic in the devices and you have a robust method to detect communication errors.

[Grummaniser]

Parity bits

Originally Posted by EDLB

Can you verify this? This would be very crude early 1970th technology and with a Haming distance of 1 only protect against single bit failures. A two bit failure would create the next valid data. And there is no guarantee that any interference will only disturb 1 bit. Equaly likely is, that a sequence of bits are disturbed.
I still wonder where the 20 degrees constant offset in the Lion Air AOA sensor came from. See preliminary report. That’s not a stuck sensor.
If the Ethiopian will show a similar offset then there is another problem burried in their flight control system.

It doesn't take a double bit error to lose one bit of data - somewhere in the system between the RDVT fixed to the AoA vane and the bus, is an analogue to digital converter chip (or array of them) which will not itself be creating any error checking. The error checking will be added further downstream (quite possibly by the chip next to the A-D). A fault in the actual A-D chip could produce single bit errors which could only be identified by duplicating the A-D process.

[Cows getting bigger]

Originally Posted by Lake1952

As has been repeatedly pointed out , it is not an unstable airplane.

Err, the reason for the inclusion of MCAS is to address a certification issue regarding static stability. The issue is wholly to do with reduced static stability which appears to be erring towards static neutrality. In other words, in certification terms, without MCAS the aircraft is not stable enough.

[FGD135]

This one will pitch up more than most; again a consequence of the design. If the crew are made aware of this, is it really beyond the power of the human mind to be ready and correct the pitch? In other words, no need for this system at all.

Actually, with the thrust line higher than previous versions, and the jet outlet further forward, the pitch-up on thrust increase will be less.

But, the MCAS is not there for the pitch-up. It is there to improve the handling qualities at high angles of attack. What Boeing were after was a steadily increasing nose-down stick force as the alpha increased.

Can someone explain to a non-pilot: In what common circumstances would an aircraft actually need to pitch up close to the stall angle, while flying with flaps up? High altitude turbulence avoidance or maneuvering? Tight turns at high bank angle?

There is no circumstance where the aircraft would need to pitch up when close to the stall angle. Such behaviour is considered undesirable. The MAX has a tendency for this, hence the MCAS system to "tame" it.

[edmundronald]

Possible data corruption opens a real can of worms.

If there really was a data transmission error, and Boeing designed in a single point of failure with no serious data integrity checking on the digital transmission (each packet with a serial number and with a CRC so none can get lost or corrupted), and no software filtering to see whether values make sense,and restore sanity, it would be literally unbelievable. (You can do that in a lab, not in a transportation machine). But then ALL of the DIGITAL avionics on this plane will be similar, and the whole type becomes suspect, and in fact will need at least a fundamental software refactoring with a bunch of software crosschecks and filtering on all sensors that feed into mission-critical automation - it's not at all obvious that MCAS is the only such novelty on this plane, there may be more stuff hidden away.

I may not be the most competent engineer in the world but I have a Master's in Electronics/Telecoms and a PhD. This is my professional opinion. Feel free to call me incompetent but there needs to be an adult in the room. I am sure there are a bunch of pilots out there who are engineers and can chime in.


Edmund

Originally Posted by Grummaniser

It doesn't take a double bit error to lose one bit of data - somewhere in the system between the RDVT fixed to the AoA vane and the bus, is an analogue to digital converter chip (or array of them) which will not itself be creating any error checking. The error checking will be added further downstream (quite possibly by the chip next to the A-D). A fault in the actual A-D chip could produce single bit errors which could only be identified by duplicating the A-D process.

[SteinarN]

Originally Posted by Cows getting bigger

Err, the reason for the inclusion of MCAS is to address a certification issue regarding static stability. The issue is wholly to do with reduced static stability which appears to be erring towards static neutrality. In other words, in certification terms, without MCAS the aircraft is not stable enough.

It would have been really interesting to know what the stability margin actually is at high AoA. If the full 2,5 deg stabilizer travel really is needed to give the Max a sufficient positive stability/stick force gradient when going from about 10 deg AoA up to about 14 deg AoA, it would seem that a large part of the positive stability in this region is lost without MCAS?

[EDLB]

Originally Posted by Grummaniser

It doesn't take a double bit error to lose one bit of data - somewhere in the system between the RDVT fixed to the AoA vane and the bus, is an analogue to digital converter chip (or array of them) which will not itself be creating any error checking. The error checking will be added further downstream (quite possibly by the chip next to the A-D). A fault in the actual A-D chip could produce single bit errors which could only be identified by duplicating the A-D process.

In automotive acceleration pedals the duplicate sensor (potentiometer and/or magnetic angle sensor) and duplicate A/D conversion is standard. But all that effort would be mute if the communication channel is not error protected. So at least there is a robust CRC or even duplicate signalling channels.

As far as I understand in the AoA sensor and data bus neither is done so at any point errornous data could be created.
That would not even muster for an automotive acceleration pedal let alone more safety critical systems like brakes.

The only chance I see that that passes any functional safety analysis is at least two independent sensor data, and if they differ then either a safe system state is commanded or if this can’t be achieved, then a third input data (like in this case from the inertial system generated) will be needed.

[Capn Bloggs]

Originally Posted by Takwis

Where I disagree is with Boeing. "Elevator Control is sufficient to safely land the aircraft regardless of stabilizer position" is both a false statement, and extremely misleading.

Read it in the context of the QRH item it's in. Boeing is talking about LANDING, not flying at Vmo. It might be misleading to deskjockeys, but it makes sense to me.

[zzuf]

For those keen on quoting the longitudinal static stability requirements of FAR 25.175, Should note that the device in question is MCAS, ie manoeuvre, not static.
It is clear from the early descriptions of the MCAS it was about stick forces during manoeuvre when approaching the flaps up stall.
I suggest you look closely at the approach to the stall requirements of FAR 25.203(a). The STS system looks after any static stability problems.
The problem is in interpretation of these certification standards.
Many years ago stick force lightening, on the stall approach, was accepted by the FAA, provided the stall characteristics were otherwise found to be compliant The British ARB had a different view at the time. Hence stick nudgers were required in some British certificated aircraft which were not required in FAA certiicated aircraft.
It now seems any tendency towards stick force lightening is unacceptable to the FAA. I haven't looked recently but don't think the written rule (concerning longitudinal control approaching the stall) has actually changed from CAR 4B circa 1953.
At no stage during this thread has there been any force value given to the extent of the manoeuvre stability non-compliance of the B737 MAX 8. Don't forget that as little as 1lbf would be a non-compliance and would require a "fix".

[Loose rivets]

Herod:

I stopped reading this thread a long time ago, but can someone explain a point to an old, retired 737 driver? All 737s pitch up with the application of power; it's a consequence of the design. This one will pitch up more than most; again a consequence of the design. If the crew are made aware of this, is it really beyond the power of the human mind to be ready and correct the pitch? In other words, no need for this system at all.

Further to jantar99's answer, there is a huge difference between the rotation caused by thrust, and the aerodynamic flight of the cowling. Having said this, it's hard to visualise this rotational force's causal airflow only being derived from the pre-stalling greatly increased AoA. But I can think of no other reason than that which jantar99 described. It's almost a parachute effect when you consider the vertical vector alone.

I can see the need to counter it, and do it automatically, but I suppose Boeing thought it would not come into play in the real world and the prime reason for MCAS was the technicality of certification. No need to mention it to anybody.

It's hard to believe there was a time when the same type, IIRC, 727, needed a stick push on one side of the Atlantic, but not the other.
.
.
.

[FGD135]

If there really was a data transmission error, and Boeing designed in a single point of failure with no serious data integrity checking on the digital transmission (each packet with a serial number and with a CRC so none can get lost or corrupted), and no software filtering to see whether values make sense,and restore sanity, it would be literally unbelievable. (You can do that in a lab, not in a transportation machine).

Don't know about the data protocol(s), edmundronald, but can tell you that both Boeing and Airbus flight computers act on unfiltered data.

Take the incident of QF72, for example. Airbus A330, 7 October, 2008. During cruise, the angle of attack data suddenly indicated a very high value. The computer suddenly thought the plane was stalled and pushed the nose down. Passengers and Flight Attendants were thrown into the ceiling and there were several serious injuries.

There was a single spike in the data. That the readings immediately before were normal was not checked for. That the aircraft could have pitched from normal cruise AoA up to and beyond the stalling AoA instantly was not checked for. And if that wasn't amateurish enough, there was then the flight computers, thinking that a sudden pitch down whilst going at 450 knots was a good idea.

[Derfred]

Originally Posted by bill fly

... But that’s the 737, even the auto land on the 300 required a massive stabiliser up input at 400 feet to enable the flare.

It’s off topic, but I don’t think that’s the reason for the nose up pitch trim at 400RA.

I think the reason is to allow the aircraft to pitch up gently rather than crashing onto the runway in the event of a autoland flare failure (given that it is only dual autopilot) if there is no pilot input after autopilot dropout during the flare.

And it’s not a massive trim input, it’s a small trim input easily handled by a pilot.

[JRBarrett]

Originally Posted by EDLB

Can you verify this? This would be very crude early 1970th technology and with a Haming distance of 1 only protect against single bit failures. A two bit failure would create the next valid data. And there is no guarantee that any interference will only disturb 1 bit. Equaly likely is, that a sequence of bits are disturbed.
I still wonder where the 20 degrees constant offset in the Lion Air AOA sensor came from. See preliminary report. That’s not a stuck sensor.
If the Ethiopian will show a similar offset then there is another problem burried in their flight control system.

It may not be a case where the Arinc 429 data label is being corrupted in transit (which would be detected by the CRC check). More likely that the A/D converter that receives the analog AC voltage from the AOA vane is, under certain circumstances, generating an incorrect binary representation of the voltage.

Every modern aircraft contains multiple A/D converters for various system parameters. For instance, all of the engine data originates as analog signals. The N1 and N2 sensors on the engine produce a pulsed waveform whose frequency varies with the rotational speed of the spools. The EGT probes directly generate a DC voltage which is proportional to measured temperature. The oil pressure transducer resistance varies with pressure, which also produces a variable DC output voltage. The fuel flow transducer produces an AC sine wave the frequency of which is proportional to flow rate.

All of these analog signals have to be converted to digital values to drive the displays in the flight deck, and to supply other systems like the FMS.

I have seen many cases of A/D converter failures causing loss of engine indications. If I had a squawk that there was no oil pressure reading, I would suspect the transducer on the engine, but if the squawk related to a loss of N1 or N2, I would suspect the A/D conversion, because the engine-mounted speed transducers are so simple and rugged in design that failure would be almost impossible.

USUALLY if an A/D converter fails, it will simply produce no output at all. But, I have seen two instances where the conversion did not fail outright, but resulted in garbage data. In one case, an aircraft was showing exactly half the expected fuel flow rate at any given power setting. This could very well be a case of failure of one specific binary bit in the digital representation of the analog fuel flow transducer voltage. In another case, An aircraft was showing 50 psi oil pressure when the engine was completely shut down, and the pressure rolled backwards to zero when the engine was running.

Both of these instances were caused by a “one-off” failure of the DAU (data acquisition unit), which was permanently corrected by installing a replacement DAU. In both cases, the faulty DAU had been in service for many years.

But if the false AOA reading in the two Max incidents was indeed caused by an incorrect A/D conversion, it is a more serious problem. Both aircraft were almost brand new. If the FDR readout from the Ethiopian flight also shows an exact 22 degree AOA reading on one side, it points to an inherent latent software or hardware bug in the AOA A/D channel that could very well happen again on other aircraft.

I’m sure that Boeing engineers will be looking very closely at the AOA system on the Max in addition to their modifications to MCAS.

[MungoP]

Way back at the beginning of this thread I asked the following question of someone QUALIFIED to give me a definitive answer, maybe it was too early to be asking the question so now I'll post it again and please only respond if you ARE qualified to answer, that's to say have experience with the 737 MAX systems in the real world.

We have no ideas beyond some possibly educated guess-work as to what happened here but I do have a question that can be answered by someone with the relevant experience. As a 10,000 + hr career pilot I'm not exactly a newbie but have not had any experience with the latest sophisticated systems being introduced on modern aircraft.
Q. Is there something preventing pilots of these aircraft from simply hitting an autopilot 'disconnect' button, and then getting on with flying manually ? Not suggesting that this is relevant to this accident.

So, what I'm asking is, does modern technology prevent/resist/over-ride a pilot from flying an aircraft in the most basic sense once the autopilot system has been disconnected ? And I say again: I'm not suggesting that this is relevant to this particular accident.

[EDLB]

Originally Posted by MungoP

So, what I'm asking is, does modern technology prevent/resist/over-ride a pilot from flying an aircraft in the most basic sense once the autopilot system has been disconnected ? And I say again: I'm not suggesting that this is relevant to this particular accident.

Read the Lion air preliminary report. The AP was not engaged during the flight. The MCAS system was interfering with the manual flight and kept for the most time triming nose down. The only thing that would have saved them where the trim cut out switches they did not switch off.

[FrequentSLF]

Originally Posted by FGD135

Don't know about the data protocol(s), edmundronald, but can tell you that both Boeing and Airbus flight computers act on unfiltered data.

Take the incident of QF72, for example. Airbus A330, 7 October, 2008. During cruise, the angle of attack data suddenly indicated a very high value. The computer suddenly thought the plane was stalled and pushed the nose down. Passengers and Flight Attendants were thrown into the ceiling and there were several serious injuries.

There was a single spike in the data. That the readings immediately before were normal was not checked for. That the aircraft could have pitched from normal cruise AoA up to and beyond the stalling AoA instantly was not checked for. And if that wasn't amateurish enough, there was then the flight computers, thinking that a sudden pitch down whilst going at 450 knots was a good idea.

There was not a single spike..from the report
Although the FCPC algorithm for processing AOA data was generally very effective, it could not manage a scenario where there were multiple spikes in AOA from one ADIRU that were 1.2 seconds apart. The occurrence was the only known example where this design limitation led to a pitch-down command in over 28 million flight hours on A330/A340 aircraft, and the aircraft manufacturer subsequently redesigned the AOA algorithm to prevent the same type of accident from occurring again.

[deltafox44]

Originally Posted by derjodel

If by horizontal you mean at AoA ~ 0 degrees, that is very, very incorrect

No.

I meant that airflow being equal and opposite to aircraft speed vector cannot be assumed as 'horizontal' as suggested in the post I was replying to, which thought AoA could be measured by inertial systems.

[JRBarrett]

Originally Posted by groundbum

will they be looking closely at this, whilst MAXs are back in revenue service having had the software fix rushed in?

Scary. G

I would certainly hope so. I don’t know if Boeing has been provided with any of the FDR data from the Ethiopian flight as of yet which might show a similar AOA error as experienced in the first incident.

I don’t know how the AOA sensor data is processed in a 737 specifically, or what differences may exist in the processing between an NG and a Max. I doubt that the AOA position comes off of the sensors in digital form - typically it is either a variable DC voltage or variable AC waveform, with conversion to digital at some point downstream.

[alf5071h]

MungoP, #2491

Q. Is there something preventing pilots of these aircraft from simply hitting an autopilot 'disconnect' button, and then getting on with flying manually ?

A. Being able to understand the situation which requires alternative action.

Thus for this accident (not autopilot related), how and when might the crew have identified the situation, linking control difficulties with trim - and the drill; given that the preceding situation (flaps down) which appeared to be related to erroneous airspeed / air data - stick shake, low speed awareness, ‘ASI and Alt disagree’ cautions.

An opposing view, seen throughout this thread, is the powerful effect of hindsight bias, and other human behaviours such as finding patterns where there are none, selecting data which confirms one’s existing thoughts.
The tendency is to ask ‘why didn't they’; yet the answer applies equally to the many people in design, regulation, training, and operations over several months, and to a crew who had to identify cause and solution in a few minutes of flight, without supporting information, relevant knowledge or experience.

Technology does not prevent us from flying, in most cases it helps; the difficulty is with our thinking about technology - designer or regular, and ourselves.

[deltafox44]

Originally Posted by EDLB

Can you verify this? This would be very crude early 1970th technology and with a Haming distance of 1 only protect against single bit failures. A two bit failure would create the next valid data. And there is no guarantee that any interference will only disturb 1 bit. Equaly likely is, that a sequence of bits are disturbed.
I still wonder where the 20 degrees constant offset in the Lion Air AOA sensor came from. See preliminary report. That’s not a stuck sensor.
If the Ethiopian will show a similar offset then there is another problem burried in their flight control system.

The 20 degrees offset shown by the graphs are between "angle of attack indicated left" and "angle of attack indicated right". If "angle of attack indicated" means the AoA value that would be indicated in the AoA display (optional), the offset between AoA sensors would be 1,5 to 2 times more (according to Boeing document linked above) thus closer to 40° than 20°.