Lyman

Doze...

You miss the point completely. Adding complexity (sic), is done by the ADRs, when they act on deviant raw data at the pitot aperture, then synthesize and report to the pilots a value that is already known to be false.

By the time the aircrew heard the Cavalry and Saw Master Caution, the computer had been stumped for ten seconds. Had the crew been privy to an amber caution the instant the ADR was evaluating, we may not be here three years later. Add to that a Law degrade that is annunciated after the fact, and the stage is set.

Basic cf at the interface....

RR_NDB

Hi,

Few days ago we celebrated the RTW in a PA46 (piston powered) of a friend (20) and my third son (23) both aviation students.

During the mission preparation, flying to met an aviation ace in Rio de Janeiro i emphasized to them on the limitations of the A/C instruments.

And when flying in russia (single pilot due ferry tank weight) the Capt. faced a serious engine oil issue, when overhead UEMO PSN bound to Yakutsk airport.

The plane landed there in emergency conditions and during the analysis of the incident discussing with the pilot we concluded on the convenience to have an oil level meter.

To learn on low oil level just by oil pressure indications is very dangerous.

So, what this relates to F-GZCP?

To learn on UAS by System output proved to be dangerous. You may just never understand the reason of System anomalies.

In both cases, the Signature analysis of the analog signals can provide to the crew a very useful information in order to allow a good crisis management, before worms could infect the scenario.

Some posters here worked with DSP (Digital Signal Processing) and know how feasible is a subsystem capable to help decisively at UAS onset.


In the carter oil Liquidometer case it seems in a first analysis you may have a pretty good signature by some temp. sensors installed in the carter. The splash is distinct at decaying oil levels during long flights.

RTW1

RTW2

RetiredF4

You should be very proud of your sun and his friend!
Congrats!

Lyman

"To learn on UAS by System output proved to be dangerous. You may just never understand the reason of System anomalies."

That is my point, exactly. It is more than that, it speaks of an ignorance at the most basic level of how things work, and how a pilot needs to assimilate data.

More than any other "improvement", the logic needs a laundering. Positioning a stick to a percentage, to gain a deflection, and waiting for the response of the airframe is lunacy.

At the most basic level, the airbus forestalls the decision a pilot must make immediately, or....Pay the consequences of starting behind, and having to catch up.

36 prior UAS? Nothing to exonerate the bus there, no specific procedure, mostly dumb luck...
How does a pilot stay ahead of the airbus?

DozyWannabe

I don't doubt for a second that it's technically feasible to do, but the level of reliability required to meet certification necessitated the use of simplistic logic.

I know it's a good-natured joke, but this is where the "HAL" references stop being funny and start being a serious barrier to understanding. The reason for this is that the fictitious HAL was a central computer that had very complex programming and sole control over the entire vessel. What you have in aircraft like the Airbus and Boeing FBW types is a network of computers that are constantly cross-checking each other. The subsystems within are essentially a collection of finite state machines - each one not much more complex than those you'd find in your washing machine, but interlinked together to build a complex interoperating system out of simple parts.

These parts had to be rigorously tested individually and gradually pieced together in a programme that took the best part of a year. My old prof's class started with tales of making safety-critical software reliable and the exciting stuff software could be used for, but most of it was spent poring over graphs from the various regression tests that were run during that programme in order to prove the technology and determining with algebraic functions whether they would meet the stringent reliability requirements imposed by the aviation system.

It's funny that you should mention Apollo, because I've been diving into that a lot recently - Apollo 14 in fact holds the distinction of being the first software patch applied to a mission-critical system on an aircraft, and they did it *in space*. But the Apollo crews were almost all engineering test pilots with the ability to call on 400,000 people to help them solve any issue that came up, and they all accepted a significant degree of risk in order to attempt the journey. That's a far cry from being a line pilot out over the ocean, responsible for a couple of hundred lives and some distance from technical assistance. And as such, the systems need to look after themselves to a greater degree in that situation.

To be honest, I'd be surprised if the A380 systems haven't had a significant upgrade in that area compared to the older types, and the A320NEO will probably have systems derived from that work. But the original FBW series will still be using hardware of a mid-80s vintage, and I doubt it would have excess process bandwidth to cope with such a function - which is why Airbus produced the BUSS option (which can be retrofitted) as a stopgap.

infrequentflyer789

I haven't had time to be on here for a while, looks like it's got interesting and informative again, but the magic "DSP" solution is getting a bit silly.


Exactly what misleading info was displayed prior to the stall ?

As far as I can see the only misleading info at that point would have been speeds which were briefly too low before they disappeared. Why would seeing a suddenly low speed lead PF to stick the nose 15deg up ? If, prior to close of monitoring window, the indicated speed had been M1.5 then I could see a point, but it wasn't.

What proven DSP techniques would this be ? You keep mentioning DSP as if it were some kind of magic that Airbus engineers have never heard of. It's not magic, and of course they have.

Read the Airbus text properly - it states that one human cannot explain to another the set of rules for determining UAS, because it is too complex [it seems so complex that some humans cannot write a coherent procedure for dealing with it either]. Yet with your "proven DSP techniques" the machine can solve a decision problem that humans can't.

That's not DSP, it's AI, and it doesn't exist (at least that we know of). I doubt very much that we will have it any time soon either (I may have been out of DSP research for 20 odd years but I know people still in the field, and in machine learning / AI).

It's not a beancounter problem that we don't have this kind of tech either - the amount of money and brain power thrown at it is enormous - it is hard (and maybe impossible).

And how exactly does that stop the crew stalling the a/c when so informed ? How deterministic ? What level of false alarms ? How would crew reaction to a false UAS alarm be different to crew reaction to a real one [i.e. how many 447s are you going to cause] ?

What exactly is the rest of the a/c system going to do when it gets your DSP warning / alarm ?

- drop the a/p (you can't keep it in on suspected-invalid speeds) ?
- drop the protections (ditto) ?
- change control law (you aren't proposing a new FCC, just a new UAS detection, right) ?

And is that not exactly what happened ? And what did the crew do as a result ?


If only repeating it made it right, or made it that simple.

Let's try some real info shall we ?

https://data.epo.org/publication-ser...45&ki=A1&cc=EP

Note that:

1. It's a patent so it's a PITA to read - but it gives us the benefit that its contents are legally stated under penalty of perjury (I think - may vary a bit with jurisdiction).

2. Note the filing date. This is state of the art, and post-447.

3. From the background statements on P3:
4. The technical detail clearly states at least one reason why the suggestions you've made and linked to above are somewhat over-simplistic (being kind).

5. The proposed solution is not DSP (it might use it but it is so insignificant that DSP is not mentioned). It's about the sensors and the physics. Always assuming this idea even works at all and at an acceptable error rate [neither of which is a requirement for filing a patent]



Finally, this crew knew they had UAS - "we’ve lost the speeds". That isn't the problem.

To what level of conciousness that knowledge penetrated at that time of night may be relevant - neither pilot seems to have processed "15degrees up at MAX ALT".

More relevant, however, is that when correct speed information came back (30s) and needed to be acted upon (in the window before they went so far out of the envelope that all airdata was bunk), it was (probably) not believed.

Detecting and alerting UAS is only (or less than) half the problem - you also need to detect and inform when the UAS event has ceased.

Feel free to post your patent number when you file :-)

RR_NDB

Hi,

infrequentflyer789:

Quote:

...but the magic "DSP" solution is getting a bit silly.

I am here looking for aviation safety and motivated to discuss concepts, etc. related to it. I am a R&D professional always motivated to look for solutions. Your comment sounds a little bit "non motivating" for me to reply in detail on the improvement that IMO can be made to the important UAS issue. Anyway i will try to explain something feasible.

You need to process the analog signals before entering the System. Doing that you may have an information very useful mostly if System degrades the A/C and (currently) not present properly the reason for. The idea is to have an analog signal processing helping the crew with a redundant information. False positives would not cause problems and the sensitivity could be adjusted.

I dont´t like the approach to just rely on System output to diagnose what´s going on.

The UAS processor would not be there to solve anything. The machine would be an extra (IMO important early warning) resource to help the diagnose.

I mentioned the Airbus SAS paper but the other companies could also benefit from this approach, for the crew decision making. (The subsystem just presenting information to the crew)

Nothing automatically.

No method?

The concept is simple: Process the analog signals and present it to the crew, immediately. How? There are simple and effective ways to do.

A "half" that triggered a cascade of events

No problem

Some ideas an R&D professional could publicly with the sole intent to a faster implementation. (IBM PC x Mac, as an example).

Not magic, just a powerful processing to help the crew. This can be implemented!

I am not in this business. And no intentions to invest in it, currently.

On the "misleading", this is to be covered in another Thread. Will do it ASAP.

RR_NDB

Hi,

infrequentflyer789:

Quote:

Finally, this crew knew they had UAS - "we’ve lost the speeds". That isn't the problem.

IMO, problem is When you lost confidence in the machine you are operating.

If you bury (or not present assertively) an information of this magnitude you may have a situation when a non properly trained crew could be confused. I commented in an early post on the Albert Schweitzer quote. "Confidence is the greatest asset of any successful enterprise..."

gums

Gotta admit, but detecting the pitot-staic failures due to icing and bugs or tape over the ports is different than detecting an electrical failure to the probes.

Only incident I had was a static freeze as I descended thru icing conditions ( heaters had failed). Was a no-brainer, as altitude on the steam gauges froze and IAS increased as I descended at a constant pitch. The HUD flight path marker stayed where it was supposed to, so very obvious what the problem was.

With AF447, a convenient flight path marker( derived from inertial data) on a HUD or some other display might have saved the day.

Comparing inertial/GPS data with the pitot-static measurements is hard in the cruise mode. The inertial data is noisy with altitude, and GPS altitude data is worse. The best display for we pilots is a flight path marker that shows what we are doing WRT the local horizontal. Don't even need AOA.

No comment/critique on PF actions, especially after comment "lost speeds".

RR_NDB

Hi,

gums:

Quote:

With AF447, a convenient flight path marker( derived from inertial data) on a HUD or some other display might have saved the day.

Hunter58

Following procedures from the start certainly would have as well...

BOAC

Hunter is absolutely right. Round and round we go trying to produce the foolproof system, and we need to remember what they say about those.

As I said on 27 Aug here - all jolly good stuff, but we have - as 'standard' - 2 pilots and triple sets of instruments to allow us to try and determine the 'valid' indication, using Human intelligence. Trying to present yet another 'AI' system which will 'solve' the problem is asking for trouble, and also assuming that the human part of the system is:-
a) Going to notice
b) Going to understand
c) Do the right thing.

AF447 blows that out of the equation. Here you all are looking presumably at yet another set of chimes/mail or female voice messages/ECAM indications/flashing lights whatever. I suspect all would have been wasted in AF447 and they would have hit the SA with even more warnings.

Icarus rules, in a way? Don't fly too high, son.

Lyman

BOAC

a) Going to notice
b) Going to understand
c) Do the right thing.

No new chimes, no new nuthin. 'Display the results from each Pitot head'* and let the pilot consider turbulence, Windshear, P-Heat, etc. for the cause of the discrepancies.

447 did NOT have a redundant air sampling system. It was repetitive, not redundant, there is a major blunder in merging data from three sources that use the same equipment in three different locations. Using different models would only be partially better. If all the computer is doing is averaging within parameters, that isn't Ai at all, it is not even modern computing.

Would you be happy with a common N1? An average heading? Listening to two radios on different freqs?

* displaying separate results to the pilots as well as the computer is redundancy.

BOAC

- think about that - these guys could not even read an AI or altimeter.. - you have lost me there - wtf is one of those?
I don't believe there was a problem with N1 (apart from 'too many') or heading? Radios - did it a lot of the time. Most pilots do. Lost me again!

BOAC

Lyman - I think I'm going to have to pass on your posts

HazelNuts39

Lyman,

sure you know the difference between the median and the mean?

TTex600

What told the AP and AT to disconnect?

DozyWannabe

The ADR fault detection consequent to the blocked pitot tubes. If there's an air data fault, AP and A/THR are automatically disconnected.

Chapter 10. Navigation

Lyman

TTex600


TTex600 What told the AP and AT to disconnect?


There's a civil question. My question from the beginning, since it is likely that the crew had more experience with autopilot loss due to exceeded control limits than
"UAS". "vitesse douteuse". At 447's date with fate, the abnormal was called

Unreliable speed.

Tex, I believe the crew did NOT know exactly what caused the loss of autopilot, not immediately. Immediately is the standard. It was referenced at 2:16.0, when the PNF said "lost the speeds". It was at 2:22.0 when the PNF said " Alternate Law".

Rather than repeat the propaganda that has most here believing the speeds problem was known right away, I will simply say that bit is not known except at those two indexed times, from the CVR.

So it occurs to me that a conference among computers should have extended an invitation to the flightcrew to be privy...

If, since the timing is not known except at 2:16:0, the PF may have thought the a/p quit due to its computed conclusion that it was unable to command sufficient controls deflection by its Parameters of operation. There was turbulence, and it would have been a possible determination. Possible.

A casual look at the graph of Vertical speeds and g shows a heavy moving around like a trainer, at least possibly. Possible.

PF could have missed the speeds issue on his PFD, he also could have missed the Law degrade, which is very important. It is important because when the a/p quits due handling in turbulence, on this aircraft, it remains in NORMAL LAW.

Was this possibly his foundation? Possible?

HazelNuts39

Final report:
1.16.3.1 Analysis of the initial sequence
Analysis of the FDR parameters and of the data contained in the two FMGECs’ nonvolatile memories showed that:
ˆˆ The ADR 2 speed fell between 2 h 10 min 03.5 et 2 h 10 min 05;
ˆˆ the ADR 1speed fell for less than one second from 2 h 10 min 04 s to 2 h 10 min 05, causing:
- the disconnection of the autopilot,
- the triggering of “PITOT PROBE” monitoring in the FCPC causing the transition to alternate 2B law;
ˆˆ The ADR 3 speed fell temporarily from 2 h 10 min 07 s to 2 h 10 min 10 s, causing, in the following second, the loss of autothrust and the disappearance of the Flight Directors; it then fell again at 2 h 10 min 14,
ˆˆ The speed on ADR 1 fell again at about 2 h 10 min 08 s, causing the loss of the autothrust and of the flight directors within the next second.