PPRuNe Forums - View Single Post - AF 447 Thread No. 7
View Single Post
Old 10th Apr 2012, 01:06
  #1329 (permalink)  
RR_NDB
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
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 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.

Indeed, the system has to be sure of itself to provide news (particularly good news such as: you now can rely on...)
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.

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.

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.
I may ask: Why? Frankly, IMO there are better approaches. This "long latch" (long outage) and "reset on ground" tells me: Room for improvement.

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.
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".

I know that ice eventually melt, but ice is not the only potential problem encountered by the pitots. What about volcanic ashes, for example?
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)

Hence it's far safer IMO to let the crew do its job, as pilots: Assess the failure, eventually see that the values
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 )

Last edited by RR_NDB; 10th Apr 2012 at 18:29. Reason: Text impvmt
RR_NDB is offline