AF 447 Search to resume (part2)
Join Date: Apr 2009
Location: Melbourne, Australia
Age: 40
Posts: 73
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by regularjo
Tip: If you don't like it, don't read it....
Keep the thread about the actual progress of recovery. This isn't the "AF447 Speculation on cause" thread.
Join Date: Jun 2009
Location: Brussels
Age: 51
Posts: 2
Likes: 0
Received 0 Likes
on
0 Posts
@bobman84
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).......
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.
Keep the thread about the actual progress of recovery. This isn't the "AF447 Speculation on cause" thread.
Mr Amos is entitled to his opinion of course but this isn't the first time he has expressed it (badly).......
Join Date: Aug 2009
Location: Germany
Age: 67
Posts: 1,777
Likes: 0
Received 0 Likes
on
0 Posts
Hi,
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.
Now the key issue looking forward is how to address that in order to improve on safety in the future. I see three scenarios:
Find a means to avoid blocked pitot tube and so avoid a unsafe condition.
this will eliminate the other scenarios you suggest.
Join Date: Jun 2010
Location: On the ground too often
Age: 49
Posts: 127
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: May 2008
Location: Belgium
Posts: 26
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Jan 2008
Location: Frome - where we do as Fromans do.
Age: 68
Posts: 57
Likes: 0
Received 0 Likes
on
0 Posts
RE Takatas 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 ADIRUs!
Could that be the explanaton everyone is seeking?
Witches in the ADIRUs!
Could that be the explanaton everyone is seeking?
deSitter, #2217
Well, someone else did ask 
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.
Sorry, irresponsible alarmist nonsense. No other way to describe
the allusion that Paris fashion is in some way connected to aircraft
safety
...
syseng68k gave us a nice lecture on some IT stuff.
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.
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.
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.
in mind when you imagine a computer confusing your crew in a critical
situation.
the allusion that Paris fashion is in some way connected to aircraft
safety
...
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by johngreen
Witches in the ADIRUs!
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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."
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.
Join Date: Mar 2010
Location: Sweden
Age: 87
Posts: 67
Likes: 0
Received 0 Likes
on
0 Posts
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
"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
Join Date: Dec 2005
Location: At home
Posts: 244
Likes: 0
Received 0 Likes
on
0 Posts
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?
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.
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.
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.
Join Date: Jul 2009
Location: spain
Posts: 7
Likes: 0
Received 0 Likes
on
0 Posts
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
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 13:31. Reason: i found my old post: 5 deg up nose, not ten
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
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?
no. Did you mean min? (With 10 up you could probably loop it
)
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?
)
Join Date: Mar 2010
Location: Sweden
Age: 87
Posts: 67
Likes: 0
Received 0 Likes
on
0 Posts
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
"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
Join Date: Feb 2001
Location: right here inside my head
Age: 65
Posts: 178
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Diversification
What I don't understand is why it would not be possible to revert back again to normal sytstem functions.
Join Date: Dec 2005
Location: At home
Posts: 244
Likes: 0
Received 0 Likes
on
0 Posts
Diversification:
I think I found the error, reading this interesting writeup about handling of unreliable airspeed. Quote:
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.
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?
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.
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.
Join Date: Jan 2008
Location: Atlanta, GA, USA
Posts: 349
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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"
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.
they don't. Safety-critical real-time software uses a completely different paradigm to any other software development methodology you care to name.