Good news must be "broadcasted" ASAP or IMMEDIATELY
 

Hi,

The System could also provide good news to the crew. :)

May be (the System) should ASSERTIVELY inform to a hard working crew submitted to uncertainties (as in Thiells B727 and AF447) IMMEDIATELY when the Air Speed (and related indications) became reliable again.

IMO UAS and Reliable Air Speed (RAS :) ) should not be programmed by Designers as a System "inside information". Better to communicate BOTH.

The anomaly came from just the sensors (OBSOLETE). Not even (caused) from ADM, etc.

The confidence in the System (of great importance) MUST BE PRESERVED!

("Good news" in Easter day :8 :) )

"Guarantee?" Yes, you'll want marketing, down the Hall, but they're out golfing.

:p

@ RR_NDB:
While I agree that the system could also provide good news to the crew, I don't think your example is pertinent.
Indeed, the system has to be sure of itself to provide news (particularly good news such as: you now can rely on...)
The current logic is: The fact that the 3 airspeed sources give ~ the same value is an indication that this value is correct as long as no error occured.

As soon as an error occured (and until a system reset on the ground, with a check of its sources), the system is no more able to determine if what it "senses" is true or not.
You can easily imagine that 3 frozen/clogged pitots will at some time indicate ~ the same (incorrect) airspeed value. It would be very dangerous to rely on that (incorrect) value.
I know that ice eventually melt, but ice is not the only potential problem encountered by the pitots. What about volcanic ashes, for example?

Hence it's far safer IMO to let the crew do its job, as pilots: Assess the failure, eventually see that the values ​​seem correct again and decide to give them (or not) (limited) confidence. In the mean time, fly pitch&power, which can be done without relying on airspeed indications.

Regards.

Stunning discussion by some very smart people. Puts me in mind of "Dark Star".

"No, no, Doolittle, you talk to it.
Teach it Phenomenology, Doolittle."

As you know ... I sincerely disagree here, the sidestick vs control column argument is a serious one and cannot be discarded from the equation that helped to the final result.
I would agree the argument is not making a difference regarding the initial pitch up as the displacement of the sidestick was limited as would have been such displacement of a control column, but the difference is later on especially when the cpt came back.

t
 

When he was telling Bonin (PF) CLIMB!, what was the other pilot seeing? BECAUSE, as we know, BONIN was holding NOSE UP, he said so. He was PF, and yet the other pilot said CLIMB? Didn't HE SEE THE DISPLAYS?

"But I have been holding NOSE UP". Tell us again the displays were working?

Why did PF have to TELL anyone he was commanding NU?

This tells us Number One: No one knew (except RHS!) RHS STICK POSITION.

NUMBER TWO, with the a/c commanded NU, how did the others not see this on the displays?

NO ONE knew the attitude. For THREE, BEA stays quiet after ""I have no displays" (When Captian enters). We must assume NO DISPLAYS came back, ever.....

PILOT A: "Climb, Climb"

PILOT B: "NO, Do Not Climb"

PILOT C: "But I have been holding NOSE UP for some while"

None knew attitude. What display?

These are discussions of what they should do with the CONTROLS. And they are clraerly confused. FOR ONE, they know they are plummeting down, For Two, they are guessing at which way to cammand the NOSE. How can PNF tell "CLIMB", if he know the a/c is PITCHED UP at 17 degrees? The displays are not working, and they are trying to suss anything that will stop the descent, without knowledge of NU, clearly.

Homage in aerospace HMI
 

AT THE TOP OF THE EVEREST OF MAN-MACHINE INTERFACE :suspect:, I pay tribute to TEST-PILOTS :\, and TEST-INGINEERS :\ who offer their lifes to improve Air Safety, and I also pay homage to TEST-PARACHUTISTS :\ WHO TEST THEIR ZERO-ZERO EJECTABLE SEATS at price of their own health.

Maybe it is the worst fault of Airbus to have used airline pilots to test A330 also killing the test-pilot Nick Warner, and passengers confronting stall in AF447.

1994 A330 test flight crash - Wikipedia, the free encyclopedia

roulishollandais,

I cannot distinguish many similarities between the crash of 1994 and AF447. Care to elaborate?

I sincerely hope I misunderstood your point, and that this is not (airbus) bashing disguised as a tribute (to test crews). :bored:

PS: Do humans still test (0/0) seats? Last time I checked, dummies ruled. :confused:

Quote:

---

I don't think your example is pertinent.

---

I will comment reasons to mention these flights in the example:

1) PF's stalled their planes

2) Pitot's issue triggered the sequence of events

3) Stall caused LOC or (non recoverable situations)

4) They didn't identified AS issue (due icing)

5) Redundant indications were not enough. Result: Confusion and misleading

(In Thiells case a misleading was obvious. In AF447 "lack of minimum understanding" seems a fact. (based in what we have) Confusion seems to be resulted. When you are fed with REDUNDANT erratic indications a "misleading" occur: Reduce (or destroy) your confidence in the System you is operating. And open new :E possibilities. :}

Yes, there are some (imo minor) differences, i agree: 727 heater off, 447 obsolete Pitot's, 727 stall then LOC, 447 full stall: net result, an amazing* LOC. :{ This 2 crashes has IMO more commonalities than other possible examples. Yes, every accident is unique.

AZR, i am "technically oriented". But, this "non technical value" (confidence) is of extreme importance. I don't like the scenario of a crew with no confidence on the "interface" (even partially). This is very dangerous and can led to "dramatic" possibilities.:E:E:E

It would be very interesting to understand the current approach in "detail" (algorithm). Can be in "managerial" level. An outline. Maybe A33Zab could also help on this.

I may ask: Why? Frankly, IMO there are better approaches. This "long latch" (long outage) and "reset on ground" tells me: Room for improvement.

DSP techniques (very common) and good algorithms solve this easily. Typical engineering problem that instrumentation (industrial) engineers has full capability to deliver "State of the art" implementation. No problem! Remember, you process the signal (normal), the onset of "garbage generation :) and the recover of the Pitot's normal operation. (447 case). In Thiells 727 perhaps plane crashed with 3 tubes frozen. (we don't know). An interface probably never would provide "good news".

Good question. Before clogging (i mean, during transitory) DSP easily detect. Probably tubes will be no longer operational, thus creating a more serious scenario. Fortunately NOTAM's solve this. ;) There is no "instant" ash. :) like 447 crew faced after entered WX. So, ash, no problem: Same DSP, same approach. (long latch for other reason) :)

I will continue (editing) in few minutes. But i anticipate: "Globally speaking" i.e. looking to all factors (reliability, crew "workability" on the issue (assessment, cross checking (as mentioned paper put) my feeling is: Better to review current approach.

As lomapaseo IIRC well put (as i understood his post). WE could, should (quasi must) post our engineering POV. Safety is our ultimate goal. (It's my agenda, my reason to think, to analyze, to read, etc. here in PPRuNe)

* The AF447, LOC seems unique in (commercial airliner) aviation history. No abnormal attitude, and only a long and slow RH turn. (Even "G protected" during the zoom climb), Indeed unique? I don't remember nothing similar. (Unless the ROD is considered an abnormal attitude, may be of a new type :})

Further Details of Test Flight Crash
 

This link shows much more detail about what went wrong. Draw your own conclusions as to what Mr. Hollandaise had in mind:

ASN Aircraft accident Airbus A330-321 F-WWKH Toulouse-Blagnac Airport (TLS)

Hi,

Mac the Knife

"Dark Star"

:O

:eek:

Thanks for your PM Lyman.
I can't tell there was an issue with the attitude indicator(s) but it is a possibility there was one or they thought there was one as they choose to manipulate the ATT HDG switch or is it the way it is teached at airfrance to turn simultaneously both AIR DATA and ATT HDG switches ...
For sure there was confusion, big time, and those invisible sidesticks just contributed to that confusion.

http://i45.servimg.com/u/f45/11/75/17/84/af447_29.png


It has been suggested by the BEA that On n’a pas une bonne annonce de… et … de vitesse were going together but most probably they don't as they are separated by 4 seconds and the translation made is incorrect : Usually une annonce is not a display but an announcement made through a public aural system.

Annonce furtive ou persistante "STALL" (Appendix 3 in IR3)

IMO the PF was telling that the STALL WRN that came up one second earlier was a false one.


http://i45.servimg.com/u/f45/11/75/17/84/af447_30.png

Hi,

This is not the first time differences (significant) were detected between the versions (English and French) in the preliminary report No. 3 and cause confusions
Announcing and displaying are two different things with different meanings
So .. what is the true word ? the one in the french version or the one in the english version ?
It does not add anything positive to the professionalism of BEA when it comes to communicating
It seems amazing that BEA can't ensure the service of a translator familiar with the aeronautics language as they have sufficient funds
It will be interesting to scrutinize carefully the two versions of the final report (if it is translated into English)
BTW .. stay that the BEA is french and so the original publishing (in french) must be considered like official release

Confidence is the greatest asset of any successful enterprise...*
 

Hi,

CONF iture:

I will comment on that (well observed and likely) probable fact on:

Man-machine interface and anomalies thread, on the ramp "being fueled".

Mac

I hope the improvement of "interface" crew currently use in "advanced planes" (all types) in the aftermath of AF447 HOW, WHY, analysis and subsequent "works".

* Albert Schweitzer

CONF iture, jcjeant,

"On n'a pas une bonne annonce ... de vitesse" cannot imply anything else than a display AFAIK. What do you have in mind, regarding an "announcement" ??

I agree that the term is not the more common in french ("on n'a pas une bonne indication" seems better suited) but remember it was the middle of the night and the beginning of troubles. Using "une annonce" in place of "une indication" doesn't surprise me that much (french is my native language).

I really don't think the BEA is to blame, here, unless wanting to quibble about everything it writes.
I insist on here, because sometime translation issues are real, and may lead to misunderstanding and/or nonsenses.

Man machine interface
 

I hope this is being addressed by BEA with the right* emphasis.

"but the difference is later on especially when the cpt came back."

:ok:


* right means, IMO relevant

May be they no more do. I thought in the 90's it was already the case., But I had to wonder one of my friend, CLAUDE JOHARY, had to test a Mark-IV (type to be confirmed) from the ground. After what I had some problems with his back, and could no more apply as astronaut. He died in 1995 as passenger.
MS.760 Paris 11 Octobre 1995 - Uzech - Arostles

The ONLY similaritie I want to point out is the non adequate man on the non adequate place ; and that concerns HMI.

RR_NDB:
 

If i understand your question correctly,

'Good news' is if ECAM message/action is properly handled, understood and cleared by crew.

VERY good news is if ECAM message or FLAG is cleared by the system itself because that means the anomaly is not present anymore.

For the speed indication it is more difficult:
but they are in view (ADR 3 standy/isis and selectable to show on any PFD)
so if they are consistent again after anomaly the crew will know UAS is not present anymore.

An 'annonce' can be in writing, e.g. the small ads in a newspaper. Good point, nevertheless.
Found this in the "Lexique-bilingue" on the Dassault-Aviation website:

ANNONCIATEUR DE MODE DE VOL: FLIGHT MODE ANNONCIATOR (FMA)

ACARS could be used for UAS characterization?
 

On indications i would suggest: FLASHING (or warning by other suitable means) when TWO are different. If THREE are different better to not be presented to crew: Likely just GARBAGE with "MISLEADING CAPABILITIES" like occurred in the Thiells 727 ferry flight.

Will comment further your recent posts on this, IMHO very important issue:


Preventing loss of CONFIDENCE, CONFUSION and (potential) MISLEADING.

ACARS (currently) can be programmed to report UAS not observed (or observable) by crews?

Beacause AFAIK UAS is being kept by the System as an "INSIDER INFORMATION". A privilege of the System. (as per mentioned Airbus SAS paper crew must scan...)

This IMO could even be considered A Design Flaw*: Simply because at reduced cost (negligible cost) you can do better:

1) System PROACTIVELY helping crew (informing UAS onset) and

2) system CLEARING the issue (for a likely busy crew: scanning, trying to correlate, etc.)

Remark:

A DSP (Digital Signal Processing) on ANALOG (raw) air data (before ADM) can seems as miraculous (even for us, EE's) :)

*

Or lack of an important AID to help crews yet submitted to dozens of Air Speed anomalies closely related to the sensors being used.

In the Thales (now formally obsolete) equipped A/C an effort (Review or upgrade) would be essential.

The mere replacement to the US probes ("BF") IMHO is not enough. Wait to the final report (and it's consequences) shows how slow the bureaucracy is.

In the meantime pilots are at risk in not detecting timely a sensor limitation in a design with no redundancy.

RR_NDB:
 

IMO this is posted before by several posters:

Crew must scan because system has limited pre-programmed parameters to make logic decision to decide which ADRs are wrong (if dual or more ADRs are wrong and different).
In such a case a single good source can be rejected by the system.

Human (and Crew in specific) can add or skip parameters to make a - better! - logic decision on wrong and different information.
They have to isolate the faulty sources to prevent the system for rejecting the only good source and using the wrong sources.

Nothing to do with 'INSIDER INFORMATION', unfortunate during the fase 1 (as determind by BEA) the UAS of 2 or more sources lasted not long enough to trigger the ADR DISAGREE ECAM message (needs 10s to prevent spurious warnings).

in fase 2 (Continued Stall warning fase) all the speeds returned to consistent values.

In the start of fase 3 - when AoA became invalid due to hi AoA (resulting in CAS NCD) the ADR DISAGREE triggered because the UAS lasted more than 10s.

A33Zab

"In the start of fase 3 - when AoA became invalid due to hi AoA (resulting in CAS NCD) the ADR DISAGREE triggered because the UAS lasted more than 10s."

The Pitots do not pivot, and what caused the AoA vanes to read high, caused the airflow to glance across the aperture of the sensors, dropping the pressure within. Are you saying that at remarkably high values of AoA, the speeds can be trusted regardless of UAS? And not be falsely quite low, together?

?

Doesn't BUSS moot this arduous thread?

Time required to "help the System"
 

Hi,

AZR:

So, crew must help the System in this situation?

With good DSP processing of THREE sources (that always must be considered suspect) the crew could instead be "helped" by the System.

Sometimes (even on A/C) you use 5 redundant elements. E.G. in Airbus SAS design.

This could be improved
 

[/quote]the UAS of 2 or more sources lasted not long enough to trigger the ADR DISAGREE ECAM message (needs 10s to prevent spurious warnings).[/quote]

There is room for improvement. Time duration is ONE of the information a good DSP can use to generate reliable output.

And an spurious warning (threshold can be "digitally calibrated") is not a problem. The scan could verify easily is a "false positive".

I prefer a rare "false positive" than not being informed on UAS happening in the background. And worse: Generating DECISIONS for short duration anomalies.

What i don't agree:

A short duration anomaly be capable to reconfigure the A/C without ever telling what was happening. This sounds "opacity" capable to difficult crew operation. There are reasons for that? Let's work in the details and pilots could benefit from "state of the art" resources.

rapid TAT increase
 

Please forgive my off the track intervention, here but a A-330 pilot just told me that his company had some rapid TAT increases , one of which in they lost 4000 feet.

Rapid TAT increase while in cruise ?could someone explain this ? ?


" total temperature, which occurs on the wing leading or nose of your aircraft. The total temperature depends on the local, atmospheric, static temperature and on the velocity of the aircraft"


Please excuse if addressed earlier no time to read all the posts.

While we are debating the 'minutiae' associated with the AF447 accident, I have been doing some work on a Search Engine that will selectively search the individual PPRuNe Rumour and News / Tech Log threads on the subject.

At the time of this post, there have been 13 substantive threads on the AF447 event, involving 25,184 posts. That doesn't include those posts deleted by the moderators, e.g. 949 were deleted form the first thread - Air France A330-200 Missing.

The BEA's Final Report will no doubt attract many many more posts!http://images.ibsrv.net/ibsrv/res/sr...ns/mpangel.gif

Impressive figures
 

:eek:

Quote:

---

The BEA's Final Report will no doubt attract many many more posts!

---

:confused:

Administrators should prepare for DOS like (traffic exceeding thresholds)

So, this will continue for years?

:confused:

Another reason for a case study :)

Hi RR_NDB,
Apparently the Air France A330-200 Missing thread recorded its maximum server traffic of 11,419 visitors at 14:46 UTC on 1st June 2009.

I wouldn't worry.:ok:

Not too sure about that ... so too many to comment in the early days following a crash, but so little to read a final report.

Perhaps you may be right - time will tell.

The link you gave I think was in relation to the A320 down on the Hudson??

Hi,

http://www.pprune.org/rumours-news/3...ml#post4653807

The obvious reason is that the local static temperature increases. As the thrust at an RPM as well as the maximum thrust decreases with increasing ambient temperature, it could become insufficient to maintain speed and altitude.

Another possible cause is ice accretion on the TAT sensors. Depending on what sensors the engine control system uses, that can also result in a thrust loss.

Thread #8 starts starts here.