Go Back  PPRuNe Forums > Flight Deck Forums > Tech Log
Reload this Page >

AF 447 Thread No. 8

Wikiposts
Search
Tech Log The very best in practical technical discussion on the web

AF 447 Thread No. 8

Thread Tools
 
Search this Thread
 
Old 15th Apr 2012, 01:15
  #61 (permalink)  
 
Join Date: Jul 2009
Location: The land of the Rising Sun
Posts: 187
Likes: 0
Received 0 Likes on 0 Posts
Organfreak

The significant Pan Am flight numbers were PA217 (1968), PA816 (1971), PA806 (1974), PA812 (1974). A series of reports was produced by Pan Am and the FAA detailing the major problems with the airline but these were kept confidential. I would hesitate to use the word blame though. As PJ2 points out blame is a legal concept and a bit out of place. Of course like everyone I have been guilty of using value loaded terms like this because it is often easier to write. It is not a matter of blame as such but an inability to cope with the situation in hand. I detail what I think was missing but I do not believe that the aircraft was a factor in this. One can argue that if things have been different in design or warning features then the accident would haven't have happened. Unfortunately this is what I would characterise as a wish state. Other accidents have demonstrated that where these features were present they didn't necessarily prevent an accident. The question why comes down to the people flying the aircraft and their background. To try and evade that and attribute the accident to a machine fault is to my mind dangerous as it assumes that we can further design the pilot out of the loop.
Old Carthusian is offline  
Old 15th Apr 2012, 03:50
  #62 (permalink)  
 
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 81
Posts: 1,454
Likes: 0
Received 0 Likes on 0 Posts
OC
One can argue that if things have been different in design or warning features then the accident would haven't have happened. Unfortunately this is what I would characterise as a wish state.
Nothing wrong with a "wish list" to prevent the next accident. You just might get the wished for item in time to save your posterior.

Other accidents have demonstrated that where these features were present they didn't necessarily prevent an accident.
I'm not sure this is valid. What about the accidents that were prevented because of "these features"? Did anyone keep a record? Sort of like saying the new stop light didn't prevent having another accident at the intersection. Perhaps the circumstances are different.?

The question why comes down to the people flying the aircraft and their background. To try and evade that and attribute the accident to a machine fault is to my mind dangerous as it assumes that we can further design the pilot out of the loop.
When all else fails, it is the people flying whose job it is to prevent accidents. Sometimes they fail too.

Have you ever been taken in by a con man? This happens through mis-direction. You are looking for a problem in one direction, and it sneaks in through the opposite direction. Not very different from aviation actually.
Machinbird is offline  
Old 15th Apr 2012, 04:58
  #63 (permalink)  
 
Join Date: Jul 2009
Location: The land of the Rising Sun
Posts: 187
Likes: 0
Received 0 Likes on 0 Posts
A wish state not a wish list - the terms differ in their meaning and useage.

Some are advocating that the side stick was a factor in the accident because it was unobservable for example. But there are examples of where an accident has happened despite the yoke position being visible. We have to be careful in advocating a solution as a pancea to an issue.

'When all else fails, it is the people flying whose job it is to prevent accidents. Sometimes they fail too.'

Exactly this is what I have been saying all along.
Old Carthusian is offline  
Old 15th Apr 2012, 06:57
  #64 (permalink)  
PJ2
 
Join Date: Mar 2003
Location: BC
Age: 76
Posts: 2,484
Received 0 Likes on 0 Posts
CONF iture;

re, "There must be a trace somewhere to tell about the ECAM selections ...", (Post #59)

No, there almost certainly isn't.

As is frustratingly known, many parameters are simply not recorded, the Right-side PFD/ND displays being the most memorable losses.

It is my experience that ECAM actual text displays (what the crew sees/reads) are almost never recorded. This is because such detailed information is not mandated.

The actual legal requirements for what is mandated to be recorded are tiny in comparison with what is actually available on the SSFDR.

As I have offered a number of times now, the QAR, tradtionally employed for FOQA/FDM/FDA Programs records far more parameters and at higher sample rates. All it takes is money, first to pay for the design, create, execute the logical frame layout for the QAR and the aircraft installation and second to pay for the STCs/certification information either from the manufacturer of the specific dataframe layout in the installed DFDAUs or for a generic one which may be type-specific but not airline specific and so may not record some parameters which have different frame layout structures.

There is no legal guidance as to what must be recorded by QARs.

A data frame resembles an Excel spreadsheet. The frame layout is designed to expect very specific information from a specific source in a very specific format in exactly one row of cells, normally 4 columns wide and 256 or 512 rows long. If it doesn't get the specific "words", (usually 12-bit words), garbage results. There are many, many frame layouts even for one type of aircraft. They are tailored to each airline's specifications and aircraft configurations.

Frame layouts are explained in a number of places. I've quoted CAP731 many times. CAP 739 on FDM Programs is also helpful.

Your arguments regarding the unavailability of data, and the unavailability of data for parties outside the "official process" may not be with the manufacturer, who is not precisely responsible for the structure of the actual data frame layout on the SSDFR beyond what is mandated by the JARS/FARS/CARS etc, nor would it necessarily be with the BEA (or the TSB or the NTSB etc).

Your argument, one which I would support, is, I believe, for vastly enhanced recording capability as well as open sharing of such data, (which is doubtful for a number of reasons which need not detain us here). The first point requires an (optimistic!) freeing up of the frustrating proprietary nature of such data frames so that others who do not have rich data frame layouts may take advantage of designs that are more sophisticated, (meaning, they provide more data from a larger number of systems).

Data frame layouts are software designs and as such are almost always proprietary and for QARs, require an STC.

The time-consuming appropriation of such logical data frame layouts by others for general use can cost hundreds of thousands of dollars and still be quite incomplete due to the vastly different airline configurations of even one type. As described, these are tailored documents and software.

Specifically, it is not possible to obtain from the manufacturer of a DFDAU a specific data frame for your type of aircraft without paying significant licence fees and STCs for such installations. The appearance of a "reluctance to share" is not always a reluctance to share. The unavailability of data which all of a sudden is deemed important but once was not, is nothing more than someone's decision to not spend the money to record everything possible.

In fact, some airlines just choose a "sampling" of their fleet for FDA Programs, believing that statistics from a few types or a few airplanes may be reasonably extrapolated to the larger fleet population. A reasonable notion from a bean-counter's perspective but when a serious event occurs on one airplane that doesn't have an FDA QAR on it, the airline has blinded itself and the statistical model falls over. Again, another question entirely.

Last edited by PJ2; 15th Apr 2012 at 07:33.
PJ2 is offline  
Old 15th Apr 2012, 09:30
  #65 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
Shared responsibilities in an accident

You may have crew error(s) and a design related (the interface between the crew PF+PM) issue that contributed given the circumstances (rare).

I don't remember any post that put the A/C (or it's interface) as the only or even major cause of the accident.

I myself raised the importance of a good interface specially when dealing with unpredictable issues.

And in A330 at that time, obsolete sensors failing simultaneously in a "non redundant design" was a PREDICTABLE issue.

Despite being predictable nor the System nor the crew were able to promote the survivability. And the "effective aircraft" felt in "near terminal speed" very near the LKP (surprising everybody).

The rare circumstances led to the end in just 4 minutes just by PF (+PM) error?

An analysis normally is not "sharply digital", Yes or No. Normally there are "gradients" to be considered. Real world is not digital. It's a little bit more complex.

And is in interest of pilots to improve the interface. Or this is absolutely not necessary?

Improvements on the interface, not necessarily put the pilots further out the loop.
The idea is the opposite: To allow pilots to act easily and safer when (for any reason) they are required to enter the the loop.

And a good i(intuitive) interface even SIMPLIFIES training and allows a better (closer) interaction with her (A/C) .
RR_NDB is offline  
Old 15th Apr 2012, 12:37
  #66 (permalink)  
 
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 81
Posts: 1,454
Likes: 0
Received 0 Likes on 0 Posts
A wish state not a wish list - the terms differ in their meaning and useage.
OC, please expand. A state would imply a temporary or ephemeral condition, whereas a list would imply more permanence.

Some are advocating that the side stick was a factor in the accident because it was unobservable for example. But there are examples of where an accident has happened despite the yoke position being visible. We have to be careful in advocating a solution as a pancea to an issue.
"Panacea" is a value judgement by you. Let me restate my point.

You have no evidence that having linked controls does not improve safety in dual piloted aircraft.. No one has recorded the accidents prevented by using linked controls, therefore there is no data. All you are stating is that accidents have happened in both non-linked side stick and linked control system aircraft. All we have are statistics showing that both linked and non linked control systems have a very good safety record.

Linking controls gives one the opportunity to monitor control inputs by tactile means, and if necessary, to assist or out vote the other guy. How is this additional capability a disadvantage?
Machinbird is offline  
Old 15th Apr 2012, 17:54
  #67 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
Organizational culture not adapting fast?

May we think PAA was not able to adapt to the new environment from the old culture?

The carrier adaptability (not re engineering fast enough) to a different environment was a factor? The confidential report had some leaks indicating the probable reasons of the issue you pointed?
RR_NDB is offline  
Old 15th Apr 2012, 20:45
  #68 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
Interaction of crew with the machine

Hi,

Which are the most important characteristics of the resources crew have "to fly" the A/C:

1) Deliver "inputs" to the machine (Yoke, SS, pedals, etc.)

2) Receive "outputs" from the machine (through System)

3) Receive any other inputs (visual, aural, sensations, etc.)

4) Deal with unpredicted situations (of any reason)

In complex machines we may say this is the resource called "man machine interface".

In the above thread we are starting to discuss some issues on this fundamental resource.

I suspect many incidents and accidents could be avoided with a better interface not necessarily more complex. Just better. Simple, highly sophisticated in the sense Leonardo da Vinci put: Simplicity is the ultimate sophistication.

Is this possible in advanced FBW planes? I think so. Current Interfaces are sophisticated enough to be simple, reliable and carefully designed to the safest operation of the advanced FBW planes?

The characteristics i consider important i listed in this post on "Basic requirements of the Interface"

Last edited by RR_NDB; 15th Apr 2012 at 21:23.
RR_NDB is offline  
Old 15th Apr 2012, 22:23
  #69 (permalink)  
 
Join Date: Aug 2009
Location: Germany
Age: 67
Posts: 1,777
Likes: 0
Received 0 Likes on 0 Posts
To read .. interesting ....
http://www.aaib.gov.uk/cms_resources...PO%2004-12.pdf
jcjeant is offline  
Old 15th Apr 2012, 22:35
  #70 (permalink)  
 
Join Date: Jun 2009
Location: Germany
Age: 71
Posts: 776
Received 3 Likes on 1 Post
Interface

There are some interace features in modern FBW aircraft still like in the ages before.

- the gearhandle is formed like a little wheel, to put the gear down you have to put that little wheel in the down position

-the flaphandle, formed like a little flap

- the speed brakes formed like a little handbrake lever

- the throttles, formed like little engines

- the trim wheel, formed like in former times when you turned mechanical cables and pulleys with this wheel

Those switches (they are nothing else in these days) are neither cheap (a pushbutton or toggle switch would be cheaper) nor ergonomic (They use a lot of space), but they tell you something when you grab them: You got the right one mate!




OC
Some are advocating that the side stick was a factor in the accident because it was unobservable for example. But there are examples of where an accident has happened despite the yoke position being visible. We have to be careful in advocating a solution as a pancea to an issue.
@ OC: Despite this fact, gear, flaps, speedbrakes and trim has been mishandeled by young and old, expierienced and less expierienced pilots. Would that fact prove, that this feedback is not necessary and we should change to simple and cheaper pushbuttons or into a command line in some display?

'When all else fails, it is the people flying whose job it is to prevent accidents. Sometimes they fail too.'

Exactly this is what I have been saying all along.
I would like to rephrase a bit:

The industry (manufacturer, operator, crew) has to plan, design and train for situations, when all else failses, that the people flying are most probably able to prevent accidents. That needs an interface and training not only optimized for costs and normal operations, but also for the worst case of the life.

I therefore follow this discussion (and take part a bit) about possible factors influencing the outcome of this tragic accident with great interest, not to blame the aircraft or to absolve the crew, but in the hope, that the industry will learn its lesson in order to minimize future events with similar causes.

With the attitude "the machine behaved like it was designed......." we can shorten any accident investigation big time. In the end its always the pilot.
RetiredF4 is offline  
Old 16th Apr 2012, 00:05
  #71 (permalink)  
 
Join Date: Jul 2009
Location: The land of the Rising Sun
Posts: 187
Likes: 0
Received 0 Likes on 0 Posts
RR NDB
With Pan Am the issue was pilots lacking certain piloting skills continuing to fly. The culture of the airline allowed for these individuals to be passed by their check captains who either ignored the signs or were ignored. Pan Am also had a casual attitude to training and some information was outdated. This is a very brief summary but it was a cultural issue.
Air France may have also developed a similar lack of attention - the recent series of incidents does point that way and the Safety Audit also highlights issues in this direction. If this is so it would be unlikely that an interface change will have the effect you desire (and there is no indication that the current A330 interface is necessarily deficient). That is not to argue that things cannot be improved - far from it but it is important to locate the reason for the accident accurately and given the information we have we do not need to move beyond the crew in this case.
Machinbird
A wish state is a situation that you want to be a certain way. A wish list is a series of items you want to have. The latter is often achievable but the former is not. The term wish state indicates a desire that reality were not the way it is. I hope this helps. We all wish the flight crew of AF447 had been able to handle the situation they found themselves in adequately but they were not. Where the evidence points is that this was due to the flight crew and not the machine. Those suggesting that the machine was to some extent the cause of the situation are in a wish state. A panacea has to be understood in the context of a universal solution - as you note that does not exist. The side stick works - some pilots don't like it, some do. Some prefer the yoke but remember the yoke will not necessarily guarantee safety. Given that this is the case then one cannot criticize the side stick on the grounds it is less safe. One can say I prefer the yoke because it has this factor which is important for me but that is all. The important point here, I feel, is this - it frequently comes down to the flight crew and how they are trained. Well trained and aware flight crew following procedures should be able to deal with almost any situation they could encounter. This is what seems to have been lacking in this situation.
Old Carthusian is offline  
Old 16th Apr 2012, 13:06
  #72 (permalink)  
 
Join Date: Mar 2010
Location: Sweden
Age: 87
Posts: 67
Likes: 0
Received 0 Likes on 0 Posts
ADIRU-ND signals and software

Hi all!

After following this discussion for some years, I am still wondering about some things.
Why has BEA not released the current software versions used on the computers, e.g. ADIRU:s, Prim:s and Sec:s? These data may perhaps be more important than e.g. engine numbers.

Let me cite the following from ao2008070-final.pdf, §3.5.3 Software versions:
"The ADIRU software was changed from time to time as updates and improvements were incorporated. At the time of manufacture, units 4167 and 4122 had software version -0312 installed. Updated versions were usually promulgated as optional service bulletins140, and operators could decide whether the advantages of installing an updated version of the software were sufficient to justify the logistics of upgrading each aircraft (three ADIRUs per aircraft). The operator of QPA elected not to load software versions -0313 and -0314 in any of their ADIRUs. Software version -0315 was loaded on unit 4167 on 20 July 2005 and was the version installed at the time of the 12 September 2006 occurrence. Software version -0316 was released in August 2008; it was the version installed on unit 4167 at the time of the 7 October 2008 occurrence and it was also installed on unit 4122 at the time of the 27 December 2008 occurrence. As far as could be determined, most of the LTN-101 ADIRUs had software versions -0315 and/or -0316 installed."

Thus apparently at least one case is known where an update in the software apparently de-masked a hidden old software bug in an ADIRU unit.

Some food for thoughts: We are faced with a small number of UAS cases which may have increased in frequency with time. That could perhaps point not only to increasing icing but also to new software revisions making the UAS events more probable. Secondly the difference in probe type behavior might also be connected to ADIRU software and its sensitivity to e.g. noise and flutter on the signal from the probes - not necessarily only to sensitivity of probes to icing conditions.

A final remark is about redundancy and diversification. Redundancy is normally a repetition using the same equipment and systems which seldom helps to avoid problems which are due to a common cause. Diversification means that different methods and equipment are used as parts in several separate and parallel channels of a system. This reduces the risk of common mode failures.

I am not a pilot and these comments are only a few thoughts from one who has spent a long life writing real-time software and also directing/overseeing national research on nuclear power safety,

Best regards to all. Keep this interesting thread going!
Diversification is offline  
Old 16th Apr 2012, 16:10
  #73 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
Important data we expect



We expect (hope) all relevant data to be published. So far the most important information is: The plane was OK. Published in a timing incompatible with a deep analysis of the issue. (before Paris Air show).

The 25,000+ posts here in PPRuNe indicates this accident is unique with respect to public interest.

Thus apparently at least one case is known where an update in the software apparently de-masked a hidden old software bug in an ADIRU unit.


A final remark is about redundancy and diversification. Redundancy is normally a repetition using the same equipment and systems which seldom helps to avoid problems which are due to a common cause.
There is no Redundancy currently in the ENTIRE FLEET of A/C with respect to Air Speed meaurements. I consider this an ABSURD!

The current Pitot's are just OBSOLETE. Airbus SAS filed a patent on Laser based AS measurements.

Redundancy works when the diversified elements don't fail simultaneously.

In F-GZCP they (same type no longer being used) "failed" near simultaneously.

In editing later this post i could provide (mine) earlier posts dealing with the RIDICULOUS design, as i unfortunately had to classify it.(WRT to AS)

There is a trend (solid one due important reasons) for this crash to be remembered as "pilot error".

As engineer with a family closely connected to aviation (father, sun, cousins, etc.) i am keeping ON the suspicion on several facts that may indicate important "accident contributions."

We are starting to address anomalies (your post fits in a possible type) in thread:


Last edited by RR_NDB; 16th Apr 2012 at 16:34.
RR_NDB is offline  
Old 17th Apr 2012, 12:34
  #74 (permalink)  
 
Join Date: Jun 2011
Location: Devonshire
Age: 96
Posts: 297
Likes: 0
Received 0 Likes on 0 Posts
Human factors and PanAm

O. C.
I believe that PanAm latterly used Flight Engineers on most of their aircraft, relieving their pilots of some of their responsibilities, although the Captain remained ultimately responsible. On three of the four types of four-engined aircraft that I flew, it was usual for the F/E to handle the power settings, other than when it was necessary for a pilot to cut the power for an aborted T/O, prior to V1. ( I do not know what PanAm did.)

A Check Captain might well have flown as First Officer with this same Captain, years ago. ( As a 400 hour Pilot I has to "sign out" my then Chief Pilot, who was also my employer, on a type of aircraft which I had on my Commercial Pilots' Licence and he lacked on his ALTP - and he actually owned the aircraft... Could I have failed him ? He PASSED ! ( Even by my standards !) He usually flew the DC3, one with a Starboard passenger door, not many on the Register.)
Linktrained is offline  
Old 17th Apr 2012, 17:10
  #75 (permalink)  
 
Join Date: Jun 2011
Location: france
Posts: 760
Likes: 0
Received 0 Likes on 0 Posts
Snoop

Originally Posted by Diversification
After following this discussion for some years, I am still wondering about some things.
Why has BEA not released the current software versions used on the computers, e.g. ADIRU:s, Prim:s and Sec:s? These data may perhaps be more important than e.g. engine numbers.

Let me cite the following from ao2008070-final.pdf, §3.5.3 Software versions:
"The ADIRU software was changed from time to time as updates and improvements were incorporated. At the time of manufacture, units 4167 and 4122 had software version -0312 installed. Updated versions were usually promulgated as optional service bulletins140, and operators could decide whether the advantages of installing an updated version of the software were sufficient to justify the logistics of upgrading each aircraft (three ADIRUs per aircraft). The operator of QPA elected not to load software versions -0313 and -0314 in any of their ADIRUs. Software version -0315 was loaded on unit 4167 on 20 July 2005 and was the version installed at the time of the 12 September 2006 occurrence. Software version -0316 was released in August 2008; it was the version installed on unit 4167 at the time of the 7 October 2008 occurrence and it was also installed on unit 4122 at the time of the 27 December 2008 occurrence. As far as could be determined, most of the LTN-101 ADIRUs had software versions -0315 and/or -0316 installed."

Thus apparently at least one case is known where an update in the software apparently de-masked a hidden old software bug in an ADIRU unit.
Since the HABSHEIM flare in the forest (AF, 1988) Nobody (BEA, Lawyers, Judges, Experts, Pilots, aso) understood nor wanted to understand how much these points are important, how real-time flying softwares work very different of traditional systems. Only one BIT 0/1 is generally false and the whole system fails... Nice exemple the ARIANE V (V501 Jun 4. 1996) where the false carry costed 8 billion FF.


Originally Posted by Diversification
We are faced with a small number of UAS cases which may have increased in frequency with time. That could perhaps point not only to increasing icing but also to new software revisions making the UAS events more probable. Secondly the difference in probe type behavior might also be connected to ADIRU software and its sensitivity to e.g. noise and flutter on the signal from the probes - not necessarily only to sensitivity of probes to icing conditions
Flutter ?

Originally Posted by Diversification
A final remark is about redundancy and diversification. Redundancy is normally a repetition using the same equipment and systems which seldom helps to avoid problems which are due to a common cause. Diversification means that different methods and equipment are used as parts in several separate and parallel channels of a system. This reduces the risk of common mode failures
We will do ! Thank you. Vocabulary is important.

Originally Posted by Diversification
I am not a pilot and these comments are only a few thoughts from one who has spent a long life writing real-time software and also directing/overseeing national research on nuclear power safety,

Best regards to all. Keep this interesting thread going
Thank you for your science pages crosscheck ! This thread is interesting due to the many differences of all of us.
roulishollandais is offline  
Old 17th Apr 2012, 18:09
  #76 (permalink)  
 
Join Date: Jun 2011
Location: Devonshire
Age: 96
Posts: 297
Likes: 0
Received 0 Likes on 0 Posts
AoA and High Mach

" The Log" of Apr/May 2012 has some stuff about AoA and High Mach Numbers on pages24 and 25. Some of this may be new to people... Talking about Pitch Limit Indicators...
Whilst they specify Brand "B", surely they are all aircraft flying through similar aerodynamic laws... I think.
( I was a Mach .5 man, some 40 odd years ago.... A bit out of touch.)
Linktrained is offline  
Old 17th Apr 2012, 18:19
  #77 (permalink)  

Dog Tired
 
Join Date: Oct 2001
Location: uk
Posts: 1,688
Likes: 0
Received 1 Like on 1 Post
With the attitude "the machine behaved like it was designed......." we can shorten any accident investigation big time. In the end its always the pilot.
I am not the only one here with many years 320/330.

Let's go back to the start.

Given those pitot probes in that part of a Cb (perhaps) in that part of the world I really doubt I could have done any better.

Cut the clever stuff and agree: s**t happens.

Best regards to RetiredF4.

Last edited by fantom; 17th Apr 2012 at 19:21.
fantom is offline  
Old 17th Apr 2012, 19:07
  #78 (permalink)  
 
Join Date: Aug 2011
Location: Grassy Valley
Posts: 2,074
Likes: 0
Received 0 Likes on 0 Posts
@fantom

Cut the clever stuff and agree: s**t happens.

It is always true, but not always accurate. To the extent man designs, builds, and uses wonderful things, the shrug comes only after all bridges are crossed. I know that's what you meant.

cheers Captain
Lyman is offline  
Old 17th Apr 2012, 21:27
  #79 (permalink)  
 
Join Date: Aug 2009
Location: Germany
Age: 67
Posts: 1,777
Likes: 0
Received 0 Likes on 0 Posts
Cut the clever stuff and agree: s**t happens.
Rummaging in my old books on the Titanic and after everything I've read and heard about AF447 ... I can not help but that this is a similitude on certain aspects .. from the urban legend (unsinkable) "a concierge can fly it" .. "he can't stall" .. to the bottom of the sea ...
Lesson not yet learned ?
jcjeant is offline  
Old 18th Apr 2012, 00:32
  #80 (permalink)  
PJ2
 
Join Date: Mar 2003
Location: BC
Age: 76
Posts: 2,484
Received 0 Likes on 0 Posts
Feynman has been quoted on this human characteristic (hubris and arrogance in the face of summarily-dismissed non-equivocating odds), numerous times here and elsewhere:


"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.Off the top of my head, I wonder if there is a strong relationship between "it can't sink" and "it can't stall"?

I wonder, because the certain and specific knowledge exists in which there are distinct and standard, trained circumstances where the airplane will stall and so all Airbus crews should be aware of this. However, metallurgical knowledge could not conclude at the time that the cold Atlantic would make those particular rivets brittle.

I think there is a vast hubris behind the first statement because technological "miracles" and an entire supporting social belief system were the order of the day, but just plain ignorance is behind the second.

Last edited by PJ2; 18th Apr 2012 at 00:47.
PJ2 is offline  


Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.