Use of QAR data in maintenance

[MurphyWasRight]

This question came to mind from the Lion air 737 MAX/MCAS sequence where a faulty AOA sensor caused problems on the penultimate flight but the AOA sensor was not considered since the problems were logged as air speed disagree and 'sts running backward' with no mention of the continuous stick shaker on takeoff.

The maintenance performed did not fix the root cause and the crew of fatal flight were not as lucky.

1: Would the raw AOA readings (one was high by 20 degrees) and/or stick shaker activation be in QAR data.
2: Is QAR data routinely used as an aid in diagnosis, are there tools to make this available for line maintenance?

As a HW/SW engineer I find having logs of raw data is invaluable compared to relying on user reports that often attempt to diagnose rather than report symptoms as clearly as possible.

[Tom Sawyer]

In general, we do not have the facility to access the raw QAR data on the line. In my previous experience, if we have an on-going fault that the troubleshooting is not rectifying, we may pull the QAR card or download the SAR file data, send it off to Tech Services who will review and advise of any action to be taken. The QAR is more there for reviewing flight incidents, than as a troubleshooting tool.

[Golden Rivet]

I don't see why not

We already use WQAR data for triggering reports on specific events.

[MurphyWasRight]

In general, we do not have the facility to access the raw QAR data on the line. In my previous experience, if we have an on-going fault that the troubleshooting is not rectifying, we may pull the QAR card or download the SAR file data, send it off to Tech Services who will review and advise of any action to be taken. The QAR is more there for reviewing flight incidents, than as a troubleshooting tool.
Thanks,
So appears there is no way to access the data in a timely/useful way for routine troubleshooting or to confirm an initial diagnoses.
Any notion of how often this would actually be helpful?

BTW: I suspect that access to raw data would not be useful, at a minimum some sort of analysis and filtering SW would be needed.
Ideally this could be automatically run after each flight to detect unnoticed/unreported glitches.

[Gibson9]

QAR cards are are often pulled and analysed by Engineers, if crew don’t provide enough information for a reported fault. In my experience at Gatwick and Heathrow the QAR card can be taken into the line office where the card can be read. I haven’t seen one that had AOA vane reading. They are commonly give Engine parameters, Flap and flying control position, airspeed and acceleration etc. A common reason would be crew often report an overspeed warning but cannot give the level and duration of the the overspeed. So to help in deciding what inspections are need the QAR would be taken into the line office where they can read the data.

[MurphyWasRight]

QAR cards are are often pulled and analysed by Engineers, if crew don’t provide enough information for a reported fault. In my experience at Gatwick and Heathrow the QAR card can be taken into the line office where the card can be read. I haven’t seen one that had AOA vane reading. They are commonly give Engine parameters, Flap and flying control position, airspeed and acceleration etc. A common reason would be crew often report an overspeed warning but cannot give the level and duration of the the overspeed. So to help in deciding what inspections are need the QAR would be taken into the line office where they can read the data.
Thank, makes sense to use it that way, although does seem to be case that the data is focused on performance/crew rather than defect root cause analysis.

Anyone know if parameters such as AOA are just not displayed or are they not recorded at all?

[lobby]

Hi Murphy. What is recorded depends on the Logical Frame Layout/Data Frame.