Ethiopian airliner down in Africa
Join Date: Oct 2018
Location: London
Posts: 2
Likes: 0
Received 0 Likes
on
0 Posts
I concur. I live in Indonesia and there is almost zero safety culture. That's not to say this contributed in any way to the Lion crash. But some of the things you see here in regards to basic safety and risk analysis would certainly shock you.
Join Date: Jan 2001
Location: Dunstable, Beds UK
Posts: 545
Likes: 0
Received 0 Likes
on
0 Posts
Dave, Have you ever worked in Indonesia ?
I have and I agree with the guys above. Its known as the midnight parts store !!
and contra to what you might think some of these guys are technically quite smart
We are not saying it happened but we are saying it can !!
I have and I agree with the guys above. Its known as the midnight parts store !!
and contra to what you might think some of these guys are technically quite smart
We are not saying it happened but we are saying it can !!
Join Date: Nov 2018
Location: madrid
Posts: 47
Likes: 0
Received 0 Likes
on
0 Posts
Consistency with data trace
I have read with interest all possible explanations suggested here fot the incorrect AOA readings.
My humble contribution would be to ask to all future posters to make any theory somehow match with the data trace.
It has a very specific behaviour: 10 or 12 degrees offset, higher on the left at power - up, fairly stable on both sides, then during taxi hardly any real movement at any side, but several (6 or 8) short instances of left AOA vane reading ramping up a few degrees at a time, not vertically (cliff) but at a slope, increasing the offset to about 25 deg, then at rotation the right one increases (normal) the left one decreases (abnormal) and then both set at 22 degrees offset and seem to measure quite faithfully to each other (apart from the offset) for the rest of the flight.
(numbers are very rough guess, trends are right though)
To me the only two explanations that so far match (loosely) are:
- a slipping shaft that slips with the bumps but sticks with aero forces (but two sensors in a row, I don't think so)
- a intermittent electrical connection outside of the probe somewhere in a encoder-like signal which is disturbed by the bumps of taxi and creates an offset. Perhaps at the control module or power to the probe.
I don't think any of them is very probable, though. There must be a better explanation. Although bit corruption or software bug doesn't fit any better to me.
edit: another plausible but quite crazy scenario would be a voltage reference for analog signals drifting up and the electronic box going for the higher value of the sin cos signals instead of simply ruling them unsuitable because the plausibility check failed.
My humble contribution would be to ask to all future posters to make any theory somehow match with the data trace.
It has a very specific behaviour: 10 or 12 degrees offset, higher on the left at power - up, fairly stable on both sides, then during taxi hardly any real movement at any side, but several (6 or 8) short instances of left AOA vane reading ramping up a few degrees at a time, not vertically (cliff) but at a slope, increasing the offset to about 25 deg, then at rotation the right one increases (normal) the left one decreases (abnormal) and then both set at 22 degrees offset and seem to measure quite faithfully to each other (apart from the offset) for the rest of the flight.
(numbers are very rough guess, trends are right though)
To me the only two explanations that so far match (loosely) are:
- a slipping shaft that slips with the bumps but sticks with aero forces (but two sensors in a row, I don't think so)
- a intermittent electrical connection outside of the probe somewhere in a encoder-like signal which is disturbed by the bumps of taxi and creates an offset. Perhaps at the control module or power to the probe.
I don't think any of them is very probable, though. There must be a better explanation. Although bit corruption or software bug doesn't fit any better to me.
edit: another plausible but quite crazy scenario would be a voltage reference for analog signals drifting up and the electronic box going for the higher value of the sin cos signals instead of simply ruling them unsuitable because the plausibility check failed.
Don't you think that the investigation would have established that at an early stage ? In fact, the report states the exact opposite.
...............
It has a very specific behaviour: 10 or 12 degrees offset, higher on the left at power - up, fairly stable on both sides, then during taxi hardly any real movement at any side, but several (6 or 8) short instances of left AOA vane reading ramping up a few degrees at a time, not vertically (cliff) but at a slope, increasing the offset to about 25 deg, then at rotation the right one increases (normal) the left one decreases (abnormal) and then both set at 22 degrees offset and seem to measure quite faithfully to each other (apart from the offset) for the rest of the flight.
............
To me the only two explanations that so far match (loosely) are:
- a slipping shaft that slips with the bumps but sticks with aero forces (but two sensors in a row, I don't think so)
- a intermittent electrical connection outside of the probe somewhere in a encoder-like signal which is disturbed by the bumps of taxi and creates an offset. Perhaps at the control module or power to the probe.
I don't think any of them is very probable, though. There must be a better explanation. Although bit corruption or software bug doesn't fit any better to me.
It has a very specific behaviour: 10 or 12 degrees offset, higher on the left at power - up, fairly stable on both sides, then during taxi hardly any real movement at any side, but several (6 or 8) short instances of left AOA vane reading ramping up a few degrees at a time, not vertically (cliff) but at a slope, increasing the offset to about 25 deg, then at rotation the right one increases (normal) the left one decreases (abnormal) and then both set at 22 degrees offset and seem to measure quite faithfully to each other (apart from the offset) for the rest of the flight.
............
To me the only two explanations that so far match (loosely) are:
- a slipping shaft that slips with the bumps but sticks with aero forces (but two sensors in a row, I don't think so)
- a intermittent electrical connection outside of the probe somewhere in a encoder-like signal which is disturbed by the bumps of taxi and creates an offset. Perhaps at the control module or power to the probe.
I don't think any of them is very probable, though. There must be a better explanation. Although bit corruption or software bug doesn't fit any better to me.
The technician cleansed the Air Data Module (ADM) pitot and the left static port to repair the IAS and ALT disagree along with operational tests on land with no results. Then the Technician cleaning the electrical connection at the Elevator Feel Computer is accompanied by an operational test with good results.
Are there any such, approved operational tests?
What approved operational tests might have been carried out that could have shown "no fault" when a fault still existed?
If the "replaced" AoA sensor at Denpasar had in fact been the same one that was removed, following an illicit repair, then by definition there would not be a U/S sensor on its way back to the manufacturer, nor any paperwork to show that a serviceable one had been drawn from stores.
Don't you think that the investigation would have established that at an early stage ? In fact, the report states the exact opposite.
Don't you think that the investigation would have established that at an early stage ? In fact, the report states the exact opposite.
I'm talking about Jakarta.
Dave can you point me to the JT incident report please. I just can't find a link.
FYI - "Cleaning a connector...." is a really dangerous euphemism in Indonesia.
Dave can you point me to the JT incident report please. I just can't find a link.
Join Date: Oct 2008
Location: Melbourne, ɐıןɐɹʇsn∀
Age: 74
Posts: 81
Likes: 0
Received 0 Likes
on
0 Posts
Join Date: Nov 2018
Location: Vancouver
Posts: 68
Likes: 0
Received 0 Likes
on
0 Posts
From pp. 7-9 Preliminary Accident Report of Lion Air PK-LQP
AOA was not touched in Jakarta, as MX suspected problem(s) laid elsewhere in the system. He fixed other things as mentioned by the CAPT of JT043: "IAS disagree & ALT disagree and Feel Diff Press Light".Well, his fixes neither cured the problems nor made things any better for the pilots of the next sector. The rest is history.
Join Date: Jan 2008
Location: Wintermute
Posts: 76
Likes: 0
Received 0 Likes
on
0 Posts
With the caveat that I have no inside knowledge of Boeing's programs and so could be talking though my hat, I would be surprised if there were anything as complex as a 'process' in this control system. Even the most simple and minimal operating system introduces a heck of a lot of unnecessary complexity. It is likely that everything runs in the same memory space (especially if it is a 286) and looks like one large interrupt driven program. They probably have some sort of minimal 'frame' so they can compile together the various developer's work, but it is probably quite small and simple compared to the millions of lines of code (literally) that you will see in an operating system.
How many safety critical software systems have you designed, had approved, and put in the field ?
Join Date: Jan 2008
Location: Herts, UK
Posts: 748
Likes: 0
Received 0 Likes
on
0 Posts
From Bjorn Fehrm of Leeham today:
This week Boeing presented how they plan to get the 737 MAX back in the air again. MCAS has a fix.We look at what the fix tells us about the first implementation and the rationale behind its implementation.
Figure 1. The improved Pilot’s Primary Flight Display presented Wednesday. Source: Boeing.
The 737 has only two Angle of Attack sensors, so no voting can be set up between them. Instead, the system relying on the sensors can be switched off if the sensors disagree and the pilot informed about the missing function.
This is the route chosen for the improved MCAS. It will now be disconnected when the sensed Angle of Attack difference is beyond 5.5 degrees when MCAS activates and over 10 degrees for over 10s when the system is in use.
The wide allowed difference shows what I have written about before. The aerodynamics around these sensor vanes, placed at the nose sides, is dependent on how the aircraft is flown. If there is a sideslip the airflow passing the sensors will be affected and the sensor values will differ.
The actual sensor value is also higher than the wing Angle of Attack (the airflow around a fuselage nose is curving upward), therefore a correction table is used to calculate the wing’s Angle of Attack. It’s the wing’s Angle of Attack which determines how close to stall the aircraft is.
Was the use of only one signal OK to trigger the original MCAS? No, it wasn’t. But at least there was a rationale for this decision, whatever one might think about the rationale. A deactivation of MCAS was not an acceptable solution as it would trigger a need for an MCAS not available signal and this would mean more difference training for the Pilots migrating from 737ng to MAX.
If you have a flight control function which is triggered by a single sensor, it means the likelihood it being incorrectly activated is there. Then you implement a nonhazardous augmentation function!
You make sure it only injects the minimum correction necessary and you limit its total authority to not jeopardize the safe flight of the aircraft.
Where others focus on a single trigger signal, my biggest problem is with the function itself. If you have a weak trigger architecture, you limit the authority of what you trigger!
There was no need for the authority MCAS got. We know this today as the software fix only trims once for each elevated Angle of Attack event and limits the total trim amount to a safe level. This is regardless of the sensors being wrong or the function running wild.
It was just a very, very bad function design, and there was no need for it.
In the life of a commercial 737 MAX pilot he should never experience an MCAS augmentation, its use case was so remote. Instead, it became the most known and explained function of all on the 737 MAX. And for the wrong, very sad reasons.
There are only a few airliner OEMs in the world. There is a reason for this. It’s a challenging product to get right and the stakes are very high for any mistakes. In today’s very safe air transport system mistakes of this scale are non-acceptable.
This week Boeing presented how they plan to get the 737 MAX back in the air again. MCAS has a fix.We look at what the fix tells us about the first implementation and the rationale behind its implementation.
Figure 1. The improved Pilot’s Primary Flight Display presented Wednesday. Source: Boeing.
Boeing’s MCAS fix casts light on the original implementation
Boeing presented its fix for the MCAS problems Wednesday. By it, it spotlights what was wrong with the original implementation.The reliance on a single triggering signal for MCAS
A lot has been written about the MCAS system relying on a single Angle of Attack input. This is unusual for systems involved in the flight control of aircraft. Normally you have three inputs so a voting procedure can sort out one of them if it has a problem (two singling out the third as faulty).The 737 has only two Angle of Attack sensors, so no voting can be set up between them. Instead, the system relying on the sensors can be switched off if the sensors disagree and the pilot informed about the missing function.
This is the route chosen for the improved MCAS. It will now be disconnected when the sensed Angle of Attack difference is beyond 5.5 degrees when MCAS activates and over 10 degrees for over 10s when the system is in use.
The wide allowed difference shows what I have written about before. The aerodynamics around these sensor vanes, placed at the nose sides, is dependent on how the aircraft is flown. If there is a sideslip the airflow passing the sensors will be affected and the sensor values will differ.
The actual sensor value is also higher than the wing Angle of Attack (the airflow around a fuselage nose is curving upward), therefore a correction table is used to calculate the wing’s Angle of Attack. It’s the wing’s Angle of Attack which determines how close to stall the aircraft is.
Was the use of only one signal OK to trigger the original MCAS? No, it wasn’t. But at least there was a rationale for this decision, whatever one might think about the rationale. A deactivation of MCAS was not an acceptable solution as it would trigger a need for an MCAS not available signal and this would mean more difference training for the Pilots migrating from 737ng to MAX.
The design of the original MCAS function
While the reliance on a single sensor is highly questionable, the architecture and implementation of the original MCAS function in inexcusable.If you have a flight control function which is triggered by a single sensor, it means the likelihood it being incorrectly activated is there. Then you implement a nonhazardous augmentation function!
You make sure it only injects the minimum correction necessary and you limit its total authority to not jeopardize the safe flight of the aircraft.
Where others focus on a single trigger signal, my biggest problem is with the function itself. If you have a weak trigger architecture, you limit the authority of what you trigger!
There was no need for the authority MCAS got. We know this today as the software fix only trims once for each elevated Angle of Attack event and limits the total trim amount to a safe level. This is regardless of the sensors being wrong or the function running wild.
It was just a very, very bad function design, and there was no need for it.
Designed to not show, it became the centerpiece of attention
MCAS was a function put there to cater for a very remote case. The pilot needs to maneuver close to the limits of the aircraft and way beyond normal flying practice, to save the aircraft from some emergency. Then MCAS kicked in to make the aircraft easy to fly close to its limits.In the life of a commercial 737 MAX pilot he should never experience an MCAS augmentation, its use case was so remote. Instead, it became the most known and explained function of all on the 737 MAX. And for the wrong, very sad reasons.
There are only a few airliner OEMs in the world. There is a reason for this. It’s a challenging product to get right and the stakes are very high for any mistakes. In today’s very safe air transport system mistakes of this scale are non-acceptable.
Join Date: Nov 2018
Location: Vancouver
Posts: 68
Likes: 0
Received 0 Likes
on
0 Posts
Incident: Sunwing B38M near Washington on Nov 14th 2018, multiple system failures
By Simon Hradecky, created Tuesday, Nov 20th 2018 20:04Z, last updated Tuesday, Nov 20th 2018 20:04ZASunwing Airlines Boeing 737 MAX 8, registration C-GMXB performing flight WG-439 from Punta Cana (Dominican Republic) to Toronto,ON (Canada) with 176 passengers and 6 crew, was enroute at FL350 about 50nm northwest of Washington Dulles Airport,DC (USA) when the captain's instruments began to show erroneous indications. The first officer was handed control of the aircraft as his instruments and the standby instruments remained in agreement. The crew decided to descend out of IMC into VMC as a precaution and descended the aircraft to FL250. Descending through FL280 the weather radar and TCAS failed. The crew declared PAN and worked the related checklists. The left IRS fault light illuminated. The flight continued to Toronto for a safe landing without further incident.
The Canadian TSB reported the left ADIRU was replaced.
=====
I have a suspicion that in Boeing 737 Max 8 [B38M] perhaps the LEFT/CAPT ADIRU is constantly being overwhelmed by new routines [i.e. MCAS/AOA related programmings] which may from time to time corrupt the system.
- Incident: Sunwing B38M near Washington on Nov 14th 2018, multiple system failures
Join Date: Oct 2007
Location: Germany
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
With the caveat that I have no inside knowledge of Boeing's programs and so could be talking though my hat, I would be surprised if there were anything as complex as a 'process' in this control system. Even the most simple and minimal operating system introduces a heck of a lot of unnecessary complexity. It is likely that everything runs in the same memory space (especially if it is a 286) and looks like one large interrupt driven program. They probably have some sort of minimal 'frame' so they can compile together the various developer's work, but it is probably quite small and simple compared to the millions of lines of code (literally) that you will see in an operating system.
Thanks Dave, et al for links.
Correct.
After reading top to tail, nothing to indicate that anything either useful or otherwise untoward was carried out in JKT.
AOA was not touched in Jakarta, as MX suspected problem(s) laid elsewhere in the system. He fixed other things as mentioned by the CAPT of JT043: "IAS disagree & ALT disagree and Feel Diff Press Light".
Well, his fixes neither cured the problems nor made things any better for the pilots of the next sector. The rest is history.
Well, his fixes neither cured the problems nor made things any better for the pilots of the next sector. The rest is history.
After reading top to tail, nothing to indicate that anything either useful or otherwise untoward was carried out in JKT.
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 62
Posts: 424
Likes: 0
Received 0 Likes
on
0 Posts
ecto
Your analysis is fundamentally flawed because AOA is not valid before takeoff, and any data points prior to that must be ignored. The AOA sensor relies on significant forward speed to align the vane with the airflow, and this is not possible while taxiing.
It has a very specific behaviour: 10 or 12 degrees offset, higher on the left at power - up, fairly stable on both sides, then during taxi hardly any real movement at any side, but several (6 or 8) short instances of left AOA vane reading ramping up a few degrees at a time, not vertically (cliff) but at a slope, increasing the offset to about 25 deg, then at rotation the right one increases (normal) the left one decreases (abnormal) and then both set at 22 degrees offset and seem to measure quite faithfully to each other (apart from the offset) for the rest of the flight.
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 62
Posts: 424
Likes: 0
Received 0 Likes
on
0 Posts
Something of interest perhaps...
By Simon Hradecky, created Tuesday, Nov 20th 2018 20:04Z, last updated Tuesday, Nov 20th 2018 20:04ZA
Sunwing Airlines Boeing 737 MAX 8, registration C-GMXB performing flight WG-439 from Punta Cana (Dominican Republic) to Toronto,ON (Canada) with 176 passengers and 6 crew, was enroute at FL350 about 50nm northwest of Washington Dulles Airport,DC (USA) when the captain's instruments began to show erroneous indications. The first officer was handed control of the aircraft as his instruments and the standby instruments remained in agreement. The crew decided to descend out of IMC into VMC as a precaution and descended the aircraft to FL250. Descending through FL280 the weather radar and TCAS failed. The crew declared PAN and worked the related checklists. The left IRS fault light illuminated. The flight continued to Toronto for a safe landing without further incident.
The Canadian TSB reported the left ADIRU was replaced.
I have a suspicion that in Boeing 737 Max 8 [B38M] perhaps the LEFT/CAPT ADIRU is constantly being overwhelmed by new routines [i.e. MCAS/AOA related programmings] which may from time to time corrupt the system.
- Incident: Sunwing B38M near Washington on Nov 14th 2018, multiple system failures
Incident: Sunwing B38M near Washington on Nov 14th 2018, multiple system failures
By Simon Hradecky, created Tuesday, Nov 20th 2018 20:04Z, last updated Tuesday, Nov 20th 2018 20:04ZA
Sunwing Airlines Boeing 737 MAX 8, registration C-GMXB performing flight WG-439 from Punta Cana (Dominican Republic) to Toronto,ON (Canada) with 176 passengers and 6 crew, was enroute at FL350 about 50nm northwest of Washington Dulles Airport,DC (USA) when the captain's instruments began to show erroneous indications. The first officer was handed control of the aircraft as his instruments and the standby instruments remained in agreement. The crew decided to descend out of IMC into VMC as a precaution and descended the aircraft to FL250. Descending through FL280 the weather radar and TCAS failed. The crew declared PAN and worked the related checklists. The left IRS fault light illuminated. The flight continued to Toronto for a safe landing without further incident.
The Canadian TSB reported the left ADIRU was replaced.
=====
I have a suspicion that in Boeing 737 Max 8 [B38M] perhaps the LEFT/CAPT ADIRU is constantly being overwhelmed by new routines [i.e. MCAS/AOA related programmings] which may from time to time corrupt the system.
- Incident: Sunwing B38M near Washington on Nov 14th 2018, multiple system failures
My first question is why did MCAS not activate, unlike the other two cases?
I would speculate 3 possible answers to that:
1. The flight was in autopilot at the time (inhibiting MCAS), and/or FCC was subsequently turned off by crew, or kept on till flaps down.
2. The AOA fault on captain's side may have been nose down (not nose up), so that stick shaker and MCAS were not triggered.
3. On that flight MCAS was active on the co-pilot's flight computer (not captain's side).
They may have survived purely by these chance factors (or good CRM...)
Edit: A question about what happened to the faulty ADIRU: Was it kept and repaired, sent back to the manufacturer, or perhaps handed over to the Canadian TSB? Was this a reportable event, or purely a maintenance issue?
Join Date: Jun 2009
Location: Tewksbury Mass USA
Age: 80
Posts: 43
Likes: 0
Received 0 Likes
on
0 Posts
That EASA Link
https://www.easa.europa.eu/sites/def...20ISS%2010.pdf REF TO PAGE 15 OF THIS DOCUMENT > Explanatory Note to TCDS IM.A.120 – Boeing 737
Very interesting information, but raises more questions than answers!
My first question is why did MCAS not activate, unlike the other two cases?
I would speculate 3 possible answers to that:
1. The flight was in autopilot at the time (inhibiting MCAS), and/or FCC was subsequently turned off by crew, or kept on till flaps down.
2. The AOA fault on captain's side may have been nose down (not nose up), so that stick shaker and MCAS were not triggered.
3. On that flight MCAS was active on the co-pilot's flight computer (not captain's side).
They may have survived purely by these chance factors (or good CRM...)
Edit: A question about what happened to the faulty ADIRU: Was it kept and repaired, sent back to the manufacturer, or perhaps handed over to the Canadian TSB? Was this a reportable event, or purely a maintenance issue?
My first question is why did MCAS not activate, unlike the other two cases?
I would speculate 3 possible answers to that:
1. The flight was in autopilot at the time (inhibiting MCAS), and/or FCC was subsequently turned off by crew, or kept on till flaps down.
2. The AOA fault on captain's side may have been nose down (not nose up), so that stick shaker and MCAS were not triggered.
3. On that flight MCAS was active on the co-pilot's flight computer (not captain's side).
They may have survived purely by these chance factors (or good CRM...)
Edit: A question about what happened to the faulty ADIRU: Was it kept and repaired, sent back to the manufacturer, or perhaps handed over to the Canadian TSB? Was this a reportable event, or purely a maintenance issue?
The weather radar depends on accurate IRU pitch and roll data for stabilization, and IRU data is also used by the TCAS.
Because of the two crashes, now ANY in-flight technical failure on a 737-8 MAX aircraft is going to draw immediate media attention - as we saw just a few days ago with the engine problem on the SWA ferry flight departing MCO.
Join Date: Apr 2015
Location: Under the radar, over the rainbow
Posts: 788
Likes: 0
Received 0 Likes
on
0 Posts
RE: EASA Explanatory Note
https://www.easa.europa.eu/sites/def...20ISS%2010.pdf REF TO PAGE 15 OF THIS DOCUMENT > Explanatory Note to TCDS IM.A.120 – Boeing 737
The aisle stand trim switches can be used to trim the airplane throughout the flight envelope and fully complies with the reference regulation Simulation has demonstrated that the thumb switch trim does not have enough authority to completely trim the aircraft longitudinally in certain corners of the flight envelope, e.g. gear up/flaps up, aft center of gravity, near Vmo/Mmo corner, and gear down/flaps up, at speeds above 230 kts.In those cases, longitudinal trim is achieved by using the manual stabilizer trim wheel to position the stabilizer. The trim wheel can be used to trim the airplane throughout the entire flight envelope.In addition, the autopilot has the authority to trim the airplane in these conditions.
[. . .]
Furthermore, the additional crew procedures and training material will clearly explain to pilots the situations where use of the trim wheel may be needed due to lack of trim authority with the wheel mounted switches.
[. . .]
Furthermore, the additional crew procedures and training material will clearly explain to pilots the situations where use of the trim wheel may be needed due to lack of trim authority with the wheel mounted switches.