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

AF 447 Search to resume (part2)

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

AF 447 Search to resume (part2)

Old 24th May 2011, 10:00
  #2241 (permalink)  
 
Join Date: Apr 2009
Location: Melbourne, Australia
Age: 36
Posts: 73
Originally Posted by regularjo
Tip: If you don't like it, don't read it....
Yes, but this thread is about the "Search" not about speculation and other rubbish. Pages of crap with only some few updates about media releases etc.

Keep the thread about the actual progress of recovery. This isn't the "AF447 Speculation on cause" thread.
Bobman84 is offline  
Old 24th May 2011, 10:22
  #2242 (permalink)  
 
Join Date: Jun 2009
Location: Brussels
Age: 48
Posts: 2
@bobman84

Yes, but this thread is about the "Search" not about speculation and other rubbish. Pages of crap with only some few updates about media releases etc.

Keep the thread about the actual progress of recovery. This isn't the "AF447 Speculation on cause" thread.
As you like sir, I however enjoy the contributions from the regular posters on here while we wait for more actual information from the BEA.

Mr Amos is entitled to his opinion of course but this isn't the first time he has expressed it (badly).......
regularjo is offline  
Old 24th May 2011, 10:56
  #2243 (permalink)  
 
Join Date: Aug 2009
Location: Germany
Age: 64
Posts: 1,809
Cool

Hi,

Now the key issue looking forward is how to address that in order to improve on safety in the future. I see three scenarios:
My first scenario is:
Find a means to avoid blocked pitot tube and so avoid a unsafe condition.
this will eliminate the other scenarios you suggest.
jcjeant is offline  
Old 24th May 2011, 11:22
  #2244 (permalink)  
 
Join Date: Jun 2010
Location: On the ground too often
Age: 45
Posts: 129
Given the availability of technologies such as GPS, Inertial navigation, radio navigation, radar, AOA sensors - is it possible to build an avionics package which could automatically control (and provide pilots with information to manually control) the flight throughout all phases without requiring a pitot-static system at all?

Given the current low cost of electronic pressure tranducers - would it not make sense to have multiple static pressure transducers spread throughout the airframe (e.g. on the wings, horizontal stabiliser) to monitor the actual aerodynamic performance of the aerofoils and adjust thrust/pitch based on this?

In the event of multiple pitot probe failure/icing - would it not make sense to lower the RAT and calculate airspeed based on RAT power output/rpm?

In the event of multiple pitot probe failure/icing - would it not make sense for the flight control system to execute minute movements of the control surfaces (spoilers/elevator, rudder) and estimate airspeed based on the force required to move the control?

It seems there are a lot of readily available alternative sources of airspeed information - it's just that the rate of adoption of new software technology to take advantage of these is very slow.
Golf-Sierra is offline  
Old 24th May 2011, 12:00
  #2245 (permalink)  
 
Join Date: May 2008
Location: Belgium
Posts: 26
Dozy Wannabe,

You make some good points about software testing. Having worked in the field of research (Best part of 30 years ago) that was looking at how to prove programs correct for life critical systems (A320 included), one of the facinating topics was how to add the extra dimension of time to unit and regression testing.

If all expected (unexpected and down right surprising) inputs to a function (should say object but let's keep this in layman's terms) produce expected output, then you have a function that works in isolation. The problem with any "real-time" system is that you do not know when such inputs will occur and what else will be happening at the time. I no longer work in this field but the probelm of how to test for an acceptably comprehensive set of time related inputs is something that was not solved at the time.

Keep testing until you are satisfied that nothing new will occur was the method. This can take a while in a system as complicated as that flying the A330. There is no doubt that the "two teams" approach that you describe for the A320 helped bring a lot of confidence to the testing teams.
badgerh is offline  
Old 24th May 2011, 12:47
  #2246 (permalink)  
 
Join Date: Jan 2008
Location: Croydon
Age: 65
Posts: 52
RE Takata’s post #2233

Assuming that image is from a genuine Airbus publication, I really do hope that their ability to find bugs in software is somewhat more effective than their proof reading of what must surely be extremely critical documentation!





Witches in the ADIRU’s!
Could that be the explanaton everyone is seeking?
johngreen is offline  
Old 24th May 2011, 12:50
  #2247 (permalink)  
 
Join Date: Jun 2009
Location: Oxford, England
Posts: 297
deSitter, #2217

syseng68k gave us a nice lecture on some IT stuff.
Well, someone else did ask

Having spent of lot of time trying to make money in the IT world (there
being no honorable way to make it in physics), I should point out the
other side - IT abstractions always fail, most IT projects fail, period:
on a team of 10 programmers, 1 is productive, 2 are helpful, 4 are a
waste of office chairs, and 3 are probably faking it. and have a resume
full of "exaggerations". No single discipline (such as it is) has
generated so much hot air. The current programming idioms are byzantine
beyond description, and have morphed eventually into "ends in
themselves". Every problem of any sort is bent around the idiom, and bad
performing bloatware is tolerated because "you can always throw more
hardware at it". There are more IT fads than Paris fashions. Keep that
in mind when you imagine a computer confusing your crew in a critical
situation.
I think you are being overly pessimistic, even bordering on alarmist in
that many people reading this thread won't understand that commercial IT
does not equal software engineering. The whole tone is embittered and
disparaging and does you no credit. Sorry to be blunt, but standards in
software engineering, when done right, are just as rigorous as any other
branch of engineering. It looks like you came into IT out of desperation
and just for the money, but many people, believe it or not, really are
dedicated and come to work every day with the intention of doing the very
best that they are capable of. Sure, a lot of companies have inept
management, but you can always move on, or like myself, work freelance
to get more variety, interesting challenges and more experience.

I do agree up to a point about "methodologies" and fashion, but many such
ideas are nothing more at root than formalisation of common sense and
methods used informally / ad hoc for decades. Such tools and techniques
can be very usefull, used intelligently, but are only ever part of the overall
development process.

There are more IT fads than Paris fashions. Keep that
in mind when you imagine a computer confusing your crew in a critical
situation.
Sorry, irresponsible alarmist nonsense. No other way to describe
the allusion that Paris fashion is in some way connected to aircraft
safety ...
syseng68k is offline  
Old 24th May 2011, 13:06
  #2248 (permalink)  
 
Join Date: Jun 2009
Location: Paris
Posts: 691
Originally Posted by johngreen
Witches in the ADIRU’s!
They only cast a spell of "Proof Reading" aimed at such documentation piled up, nothing more. But it actually never worked as expected due to some bugs induced by German-French accents: finally, there is plenty of such typos in many parts of the manuals. (more seriously, it comes certainly from OCR bugs during pdf transfer).
takata is offline  
Old 24th May 2011, 13:26
  #2249 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,183
Originally Posted by deSitter View Post
On the contrary, I started doing flat plate radar cross sections for the DoD on a project that turned out the be related to That Black Airplane. Remember Ada? Nope, gone down the ShopVac of IT ideas. I've seen BS across the board in IT, whose universal motto is "Failure is always an option. A stock option."
syseng68k has already addressed the last point. Ada was indeed included in my Software Engineering course for those that wanted to study realtime systems (class of 2001).

As to the first point, military work is one thing, where there is more likely to be use of bleeding-edge technology and the assumption of a reasonable degree of risk is acceptable. However to design a system intended for commercial operations, which could theoretically kill hundreds of taxpayers at a time if things are not done correctly (including many in first class whose families can afford extremely good lawyers) is an entirely different ballgame.
DozyWannabe is offline  
Old 24th May 2011, 13:51
  #2250 (permalink)  
 
Join Date: Mar 2010
Location: Sweden
Age: 84
Posts: 67
BUSS

GolfSierra:

"Given the availability of technologies such as GPS, Inertial navigation, radio navigation, radar, AOA sensors - is it possible to build an avionics package which could automatically control (and provide pilots with information to manually control) the flight throughout all phases without requiring a pitot-static system at all?"

Apparently at least one such system exists for the A330. Cited text:

"The BUSS or "Backup Speed Scale" Air France - Corporate : The BUSS or "Backup Speed Scale"
The "Backup Speed Scale" or BUSS is a tool which pilots use when speed indications cannot be used.
To use the BUSS, the crew must first disconnect the three ADRs (air data reference - anemometric stations). Once these have been disconnected, the crew can no longer use them during the flight.
With the BUSS system, speed is no longer calculated by the Pitot probes, but by the aircraft's incidence probes. The speed indication, which is less precise, is presented in the form of green, ambre and red stripes. In a high turbulence situation at high altitude, the speed indication given is very unstable and difficult to use.
On its A330s and A340s, Air France considered installing the BUSS system offered by Airbus and carried out tests on its flight simulators These tests did not lead Air France to adopt this system.
This is because it has the incovenience of depriving the crew of anemometric data during the flight once the BUSS system is activated, whereas experience has shown that the loss of speed indication is generally for a short time only. Moreover, the system is difficult to use at high altitude.
This has been confirmed by Airbus which recommends in a FOT (Flight Operations Telex) dated 9 September 2009 not to use this system at an altitude higher than 250, i.e. 7,600 metres (25,000 feet)."


Regards
Diversification is offline  
Old 24th May 2011, 14:20
  #2251 (permalink)  
 
Join Date: Dec 2005
Location: Finland
Posts: 242
Diversification:

To use the BUSS, the crew must first disconnect the three ADRs ...... With the BUSS system, speed is no longer calculated by the Pitot probes, but by the aircraft's incidence probes.
This sounds contradictory to the description given by takata here. The manual says that if the ADR is disconnected, it turns off both the pitot probes and the AoA probes ("incidence probes"). So something is inaccurate here?

GolfSierra:
Potentially, one solution to an air-data-independent flight control system might be based on the inertial and acceleration sensors, see my suggestion here.

The big challenge, however, is that an airplane flies in the local air which is moving around affected by local wind and turbulence, and must remain within its flight envelope in relation to that local airmass. Some sort of airspeed sensor (as opposed to groundspeed, as provided by GPS and inertial) therefore seems fairly indispensable, at least for critical flight regimes at high altitudes and approach/landing phases where the local wind needs to be considered.
snowfalcon2 is offline  
Old 24th May 2011, 14:27
  #2252 (permalink)  
 
Join Date: Jul 2009
Location: spain
Posts: 7
I recall reading in the forum, and I then asked for confirmation without any answer, that A330 SOP for unreliable air speed called for CT and 5degrees up nose.
Can anyone confirm that? (if i´am wrong sorry for introducing noise in the forum)
if above is yes: aren´t those settings prone to induce a stall when flying at 37thousand feet at max cruise speed?

If i´m asking a non sense, disregard my chopper flyer questions

Last edited by sirgawain123; 24th May 2011 at 14:31. Reason: i found my old post: 5 deg up nose, not ten
sirgawain123 is offline  
Old 24th May 2011, 14:32
  #2253 (permalink)  
Per Ardua ad Astraeus
 
Join Date: Mar 2000
Location: UK
Posts: 18,581
sf2 - IF, and that is a very big 'IF', it is insisted that an automatic system should fly pitch and power in that situation, then a database of settings for weights and atmospheric conditions etc is easily do-able, and a 'take-me down' button easy to install in the system. Why bother? Back to pilot training. We can also do that. We SHOULD be trained to do it (some are). It should be instinctive - revised every time we level off in the cruise. Why add yet another system with potential software f-u's and failure modes? Ah! Good! More ECAM actions.

Regarding an 'inertial airspeed reading' - be very careful - How would the system interpret a change in wind component of 10 kts in a storm area? Greater than the margin between stall and overspeed sometimes! Deceleration/acceleration away from 'datum', yes, but now - was that a speed change or a wind change? How will Hal know?

Originally Posted by sirgaw
at max cruise speed?
no. Did you mean min? (With 10 up you could probably loop it)
BOAC is offline  
Old 24th May 2011, 14:46
  #2254 (permalink)  
 
Join Date: Mar 2010
Location: Sweden
Age: 84
Posts: 67
BUSS again

SnowFalcon2 wrote:
"This sounds contradictory to the description given by takata here. The manual says that if the ADR is disconnected, it turns off both the pitot probes and the AoA probes ("incidence probes"). So something is inaccurate here?"

Please use the link in my previous post and read. There is also a pdf-file from Airbus which argues for the installation and use of BUSS in case of unreliable airspeed.

What I don't understand is why it would not be possible to revert back again to normal sytstem functions.

Regards
Diversification is offline  
Old 24th May 2011, 14:47
  #2255 (permalink)  
 
Join Date: Aug 2009
Location: Germany
Age: 64
Posts: 1,809
Cool

Hi,

I recall reading in the forum, and I then asked for confirmation without any answer, that A330 SOP for unreliable air speed called for CT and 5degrees up nose.
jcjeant is offline  
Old 24th May 2011, 14:51
  #2256 (permalink)  
 
Join Date: Feb 2001
Location: right here inside my head
Age: 61
Posts: 178
Originally Posted by Diversification
What I don't understand is why it would not be possible to revert back again to normal sytstem functions.
I think because you can't align the ADIRUS while in motion...?
3holelover is offline  
Old 24th May 2011, 15:14
  #2257 (permalink)  
 
Join Date: Dec 2005
Location: Finland
Posts: 242
Diversification:

This sounds contradictory to the description given by takata here. The manual says that if the ADR is disconnected, it turns off both the pitot probes and the AoA probes ("incidence probes"). So something is inaccurate here?
I think I found the error, reading this interesting writeup about handling of unreliable airspeed. Quote:
The BUSS comes with a new ADIUR standar (among other new system standards), where the AOA information is provided through the IRs and not through the ADRs. This enables selecting all ADRs off without losing the STALL WARNING PROTECTION.
The AOA information provides a guidance area in place of the speed scale. When the crew selects all ADRs OFF, then:

- The Back-Up Speed Scale replaces the PFD speed scale on both PFDs,
- GPS Altitude replaces the Altitude Scale on both PFDs.

The Back-Up Speed Scale then enables to fly at a safe speed, i. e. above stall speeds, by adjusting thrust and pitch.
So based on this, the BUSS system in fact uses inertial data based AoA information, and not the AoA probe data. This is now consistent with the information provided by takata.
snowfalcon2 is offline  
Old 24th May 2011, 15:18
  #2258 (permalink)  
 
Join Date: Jan 2008
Location: Atlanta, GA, USA
Posts: 349
Dozy and syseng68k, I am not trying to be alarmist - but I do find it very telling of the entire world of developing software, that tools like APL, FORTH, and Smalltalk, which are purpose-built for solving specific problems, are universally scorned in favor of bloated "software development universes" that operate according to internal laws that make string theory look sane. The problems get lost in the process of development and the software becomes an end in itself. The effects are most obvious when things go south, and one is presented with blizzards of useless information. It may be OK to wade through such dross while sitting in the data center, but pilots with a troubled airplane don't have time to think about such things.
deSitter is offline  
Old 24th May 2011, 15:25
  #2259 (permalink)  
bearfoil
Guest
 
Posts: n/a
3holelover

As an addendum to your reply to Diversification, I would say that in an earlier discussion it was determined that once in ALTLAW2, Normal Law is inop for the rest of the flight, until the system can be re-indexed.

My recall of the B-2 Guam crash is that in re-indexing the computers in the evening prior to launch, the ground crew neglected to dry out the sensors, and the data loaded was bunk for TO. GIGO. The pilot's of the Liberty had no mystery, when the Computers yack, Adios amigo. Not so pretty clear with AB.

Re 447, a transport of conventional airframe architecture, one could start a train of thought that included, "If not in Normal Law, then straight to direct." The B-2 cannot be flown in any fashion by hand, so its experience is suggestive only. One gets the notion in following this (AB) discussion that in the stink, one needs to know how to fly at least four different a/c.

One cannot wish to hire BoxMonitors and also expect a "Four-in-one Type Rating." Aviation will NEVER be so predictable that one can expect pilots under normal circumstances to revert to "golden arms"* on a milsec's notice.

Machinbird

I think it fair at this point to say "Raise the Nose Up". There is precedent, and neither can be supported by the information at hand, at least not conclusively. Finally getting the nose down, the crew may have succeeded too well, and could not raise it once again. It fits into what happened at Perpignan (loosely).

There was a Pitch problem by definition. Considering the RoD, why not at least consider more than one "recovery" of Pitch authority?

aside. BUSS was one of two systems discussed earlier, along with the unselected AH at the upper left of Captain's Panel. Bean counting can bite.
 
Old 24th May 2011, 15:35
  #2260 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,183
Originally Posted by deSitter View Post
Dozy and syseng68k, I am not trying to be alarmist - but I do find it very telling of the entire world of developing software, that tools like APL, FORTH, and Smalltalk, which are purpose-built for solving specific problems, are universally scorned in favor of bloated "software development universes"
There's your first problem - Smalltalk took a while to catch on in the commercial world, but it has set the stage for languages like Haskell, which are general-purpose, but with very clearly-defined functional properties. They still have to be compiled into machine-readable instructions though...

It may be OK to wade through such dross while sitting in the data center, but pilots with a troubled airplane don't have time to think about such things.
I don't know how many more times we can say this before it sinks in, but:

they don't. Safety-critical real-time software uses a completely different paradigm to any other software development methodology you care to name.
DozyWannabe is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service - Do Not Sell My Personal Information -

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