Computers in the cockpit and the safety of aviation
Moderator
The sim doesnt give you the physiological difficulties of disorientation
Then my hat's off to you, good sir. I've certainly had the "leans" in the sim myself and I've seen numerous students get well and truly totally disorientated until they get on top of the box's quirky sensations.
Then my hat's off to you, good sir. I've certainly had the "leans" in the sim myself and I've seen numerous students get well and truly totally disorientated until they get on top of the box's quirky sensations.
Join Date: Jul 2000
Location: London
Posts: 1,256
Likes: 0
Received 0 Likes
on
0 Posts
Its the g forces added in that intensify these sensations. This cannot be simulated in the standard airline simulators. Curiously the only time I am aware that some people felt disoriented was when one of our early 767 sims used to go sideways on the ground!
Per Ardua ad Astraeus
Thread Starter
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
4Greens - all sim based - I cannot see any operators allowing their precious airframes to be taken off line to do mini-aeros!
I agree with you about the sim, and the point is, JT, that yes, you can get disorientated but you cannot get the g forces and motion which can and do cause spatial disorientation. However, as para 1, I'm sure that is all we are going to get.
Linking back to previous on the 'recent' TK 737 at AMS, the PGF A320 and the Thomsonfly 737 at BOH I would, as others, press hard for some formal sim training in low speed out-of-trim full power g/a handling for low-slung beasties at least for starters.
I agree with you about the sim, and the point is, JT, that yes, you can get disorientated but you cannot get the g forces and motion which can and do cause spatial disorientation. However, as para 1, I'm sure that is all we are going to get.
Linking back to previous on the 'recent' TK 737 at AMS, the PGF A320 and the Thomsonfly 737 at BOH I would, as others, press hard for some formal sim training in low speed out-of-trim full power g/a handling for low-slung beasties at least for starters.
Join Date: Jul 2007
Location: France
Posts: 610
Likes: 0
Received 0 Likes
on
0 Posts
Sideways moving Simulator
4 Greens:
Your post #82 reminds me of an L382 Hercules Simulator that on an ILS approach to Denver USA, used to get a quirk and transfer itself (display) due north at a great rate of knots straight through a mountain. It was a hell of a relief as you came out the other side!
This was quite awhile ago and certainly made an impression.
Tmb
Your post #82 reminds me of an L382 Hercules Simulator that on an ILS approach to Denver USA, used to get a quirk and transfer itself (display) due north at a great rate of knots straight through a mountain. It was a hell of a relief as you came out the other side!
This was quite awhile ago and certainly made an impression.
Tmb
Join Date: Jun 2006
Location: Australia
Posts: 1,186
Likes: 0
Received 0 Likes
on
0 Posts
Linking back to previous on the 'recent' TK 737 at AMS, the PGF A320 and the Thomsonfly 737 at BOH I would, as others, press hard for some formal sim training in low speed out-of-trim full power g/a handling for low-slung beasties at least for starters
I must say, it takes very concise handling to get optimum pitch attitudes during the go around. If flaps were immediately selected to Flap 15 on GA (normal GA procedure) but at speeds well below Vref, a stall can occur. There is no question that you must leave the gear and flaps until reaching Vref when Flap 15 can now be set. Conducted in IMC, this exercise is one of the best pure flying skill practice I can recommend. The danger is blind chasing of the flight director pitch bar which reacts to overcontrolling in pitch. Because of this some pilots elect to switch off the FD until a stabilised climb is attained.
We already include this low speed low altitude out of trim handling during type rating and recurrent training. It certainly gives pilots vital practice at rapid flight instrument scan in IMC - especially if ground contact is imminent.
Last edited by Tee Emm; 19th Aug 2009 at 13:44.
Join Date: Jul 2000
Location: London
Posts: 1,256
Likes: 0
Received 0 Likes
on
0 Posts
Just a quote from Flight International of 18-24th August. Article headed 'Need for upset recovery training drives FAA update':
"Calspan plans to certificate two of its four variable stability Bombardier Learjets under the new category for anticipated pilot training programmes according to a company official".
"Calspan plans to certificate two of its four variable stability Bombardier Learjets under the new category for anticipated pilot training programmes according to a company official".
Per Ardua ad Astraeus
Thread Starter
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
Definitely time to dig this one up again and hopefully bring the esoteric (and off-topic) discussions on the Tripoli thread across.
What has triggered this 'revival'? The comments on the BA 056 report (kindly linked by 'sooperfrank')
4.2.3 The apparent increase in the number of software related incidents involving various type certificated aircraft is becoming a cause of concern.
There is also a common thread through many recent accidents and it is time to
train for a new type of emergency that addresses the failure modes in highly
automated aircraft. The interface between pilots and aircraft automation, as well as how this should be incorporated into aviation training, requires a review. This includes addressing how automation fails, how pilots should cope with it and how to get through the failures. New phrases for automation failures that were similar to "dead foot, dead engine" slogans that helped them identify which engine had quit are now needed.
It is therefore recommended that:
The Regulatory and certificating authorities of all States of Design and
States of Manufacture should introduce requirements to:
• Review all software control and hardware control logics and
combinations thereof to ensure that all probable defect possibilities
are identified;
• Review the processes used to introduce modifications to control
software since issuance of the original type certification, e.g. consider
a recertification process; and
• Verify that appropriate resolutions for such occurrences have been
developed and are in place to prevent un-commanded actions that
can result in an accident.
• Improve the robustness of the software/hardware logic through the
introduction of additional parameters to consider prior to an automatic
change is critical control surfaces.
• Introduction of a flight deck crew “alert/approval/override” facility prior
to an inadvertent change to critical control surfaces.
• Account for spurious mechanical and electrical failures and their
impact on the software and hardware logic system.
• Operators should provide flight crews with more basic hand flying and
simulator flight training on new generation aircraft to address the
technological developments in aviation, inclusive of effective stall
training.
How about that? On topic or what?
What has triggered this 'revival'? The comments on the BA 056 report (kindly linked by 'sooperfrank')
4.2.3 The apparent increase in the number of software related incidents involving various type certificated aircraft is becoming a cause of concern.
There is also a common thread through many recent accidents and it is time to
train for a new type of emergency that addresses the failure modes in highly
automated aircraft. The interface between pilots and aircraft automation, as well as how this should be incorporated into aviation training, requires a review. This includes addressing how automation fails, how pilots should cope with it and how to get through the failures. New phrases for automation failures that were similar to "dead foot, dead engine" slogans that helped them identify which engine had quit are now needed.
It is therefore recommended that:
The Regulatory and certificating authorities of all States of Design and
States of Manufacture should introduce requirements to:
• Review all software control and hardware control logics and
combinations thereof to ensure that all probable defect possibilities
are identified;
• Review the processes used to introduce modifications to control
software since issuance of the original type certification, e.g. consider
a recertification process; and
• Verify that appropriate resolutions for such occurrences have been
developed and are in place to prevent un-commanded actions that
can result in an accident.
• Improve the robustness of the software/hardware logic through the
introduction of additional parameters to consider prior to an automatic
change is critical control surfaces.
• Introduction of a flight deck crew “alert/approval/override” facility prior
to an inadvertent change to critical control surfaces.
• Account for spurious mechanical and electrical failures and their
impact on the software and hardware logic system.
• Operators should provide flight crews with more basic hand flying and
simulator flight training on new generation aircraft to address the
technological developments in aviation, inclusive of effective stall
training.
How about that? On topic or what?
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
Hey BOAC,
I'm jumping in here and want to start by saying that as a long-term lurker and occasional poster I have a deep and abiding respect for you and your opinions. Alas I haven't had the joy of being at the controls of an aircraft since my AEF days (I ended up with long hair, pacifism and rock music in short measure around the age of 14
, but I do know a fair bit about the process of software development. And while I didn't end up having the skill to work in the kind of real-time software development that backs up FBW technology, I was fortunate enough to be taught by someone who was.
While I agree substantively with the point that pilots be trained in identification of automation failures and correct responses to same, I feel that the quote you posted betrays some misunderstanding of the processes involved.
I was privileged enough to be shown examples of the processes that Airbus went through to define potential system failure points, and I have to say that "exhaustive" doesn't even begin to describe the tiniest fraction of the detail they went into (I suspect that Boeing were every bit as stringent). Software engineering at its purest is a discipline that is the equal of any more traditional mode of engineering one can think of. The problem is that as with any engineering discipline, the scope of failure testing is limited by the imagination of the engineers concerned. Mistakes were made, and compounded with bullish sales techniques, when the first failures occurred there was a sense of falling to hubris. But the same could also be said of transitioning from props to jet transports, or from mechanical to hydraulic controls.
Again, not something limited to software-based automation, and resolution of such should be treated as any other AD. Every software modification that I've heard of being applied to flight control systems - even those considered major in terms of importance - have tended to be very minor in terms of the actual physical effect produced. Having said that I do agree that any such changes, and any alterations to piloting technique prior to those changes being applied, should be communicated to pilots at the first opportunity.
Here I come back to engineering. In software, as in mechanical or any other engineering discipline, added complexity tends to increase potential points of failure. As such, any engineer worth their salt will be very careful about introducing an increase in complexity. In the case of BA056, armed with the information from that incident one could make a good case that extra input parameters would be helpful. However, it is a decision that should be made in a logical manner, and certainly not in the heat of the moment.
An understandable reaction in the circumstances, but again one must be wary or added complexity (and like it or not, an override does introduce further complexity).
We're back to the limits of engineering experience and imagination. There's absolutely nothing wrong with the statement - but again you'd be amazed how many failures are accounted for in the design of such systems. It is, alas, impossible to account for all of them. In the case of BA056 we're talking about a dual engine failure at a hot and high airfield caused by a side-effect of a maintenance procedure that only affects a single type of engine. I think in this case the oversight should be forgiven.
I'd call that stating the bleedin' obvious, and that any air transport operator using advances in automation as an excuse to skimp on training should have the book thrown at them. Regardless of how easy automation makes things when the winds are fair, preparation for and understanding of how things can go wrong should be paramount in pilot training before graduating from single-engine circuit-bashing. But the firms doing the training at the early stages must take responsibility too.
Getting down to the fundamentals, the fact is that advances in aviation have come at the price of painfully-learned lessons before and after the introduction of digital technology in the flight deck. The killer is and always has been human complacency.
I'm jumping in here and want to start by saying that as a long-term lurker and occasional poster I have a deep and abiding respect for you and your opinions. Alas I haven't had the joy of being at the controls of an aircraft since my AEF days (I ended up with long hair, pacifism and rock music in short measure around the age of 14
, but I do know a fair bit about the process of software development. And while I didn't end up having the skill to work in the kind of real-time software development that backs up FBW technology, I was fortunate enough to be taught by someone who was.While I agree substantively with the point that pilots be trained in identification of automation failures and correct responses to same, I feel that the quote you posted betrays some misunderstanding of the processes involved.
• Review all software control and hardware control logics and
combinations thereof to ensure that all probable defect possibilities
are identified
combinations thereof to ensure that all probable defect possibilities
are identified
• Review the processes used to introduce modifications to control
software since issuance of the original type certification, e.g. consider
a recertification process; and
• Verify that appropriate resolutions for such occurrences have been
developed and are in place to prevent un-commanded actions that
can result in an accident.
software since issuance of the original type certification, e.g. consider
a recertification process; and
• Verify that appropriate resolutions for such occurrences have been
developed and are in place to prevent un-commanded actions that
can result in an accident.
• Improve the robustness of the software/hardware logic through the
introduction of additional parameters to consider prior to an automatic
change is critical control surfaces.
introduction of additional parameters to consider prior to an automatic
change is critical control surfaces.
• Introduction of a flight deck crew “alert/approval/override” facility prior to an inadvertent change to critical control surfaces.
• Account for spurious mechanical and electrical failures and their
impact on the software and hardware logic system.
impact on the software and hardware logic system.
• Operators should provide flight crews with more basic hand flying and simulator flight training on new generation aircraft to address the
technological developments in aviation, inclusive of effective stall
training.
technological developments in aviation, inclusive of effective stall
training.
Getting down to the fundamentals, the fact is that advances in aviation have come at the price of painfully-learned lessons before and after the introduction of digital technology in the flight deck. The killer is and always has been human complacency.
Per Ardua ad Astraeus
Thread Starter
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
DW- welcome to the thread (and flattery, as always will........................
) Heaven knows, I may even have flogged you round in a Chippie before your hair (and other bits) grew
To me the point here is that it appears that the 'automatic' retraction of LEdge devices with reverse deployment (neat and practical) was not thought through, in as much as in the wrong situation with 'average' flying skill at the front, it would have caused a hull loss. (All kudos to the handling pilot and PIC for keeping their cool in rather exciting circumstances). I have not read all the tech details, but a 'safety link' ie was reverse actually selected and were we on the ground would appear to have been useful.
I am not clear about your reference to "a dual engine failure at a hot and high airfield"?
) Heaven knows, I may even have flogged you round in a Chippie before your hair (and other bits) grewTo me the point here is that it appears that the 'automatic' retraction of LEdge devices with reverse deployment (neat and practical) was not thought through, in as much as in the wrong situation with 'average' flying skill at the front, it would have caused a hull loss. (All kudos to the handling pilot and PIC for keeping their cool in rather exciting circumstances). I have not read all the tech details, but a 'safety link' ie was reverse actually selected and were we on the ground would appear to have been useful.
I am not clear about your reference to "a dual engine failure at a hot and high airfield"?
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
As I understood the incident, two engines suffered a partial thrust reverser unlock/deploy situation*, which caused the automatics to stow the L/E lift devices, possibly only until the gear left the ground, but enough to seriously reduce the lift generated. This was resolved by "firewalling" the throttles to keep her in the air long enough for a circuit.
This is only from reading the 2009 thread though - any further details would be good to know.
This kind of thing isn't limited to digital automation though - it can happen mechanically as well. The infamous 737 rudder PCU issue was a result of a combination of wear to the valve and very low temperatures causing an uncommanded reversal, and the AA191 DC-10 crash was a result of uncommanded slat retraction as a consequence of engine pylon failure.
* - so maybe "failure" was the wrong word
This is only from reading the 2009 thread though - any further details would be good to know.
This kind of thing isn't limited to digital automation though - it can happen mechanically as well. The infamous 737 rudder PCU issue was a result of a combination of wear to the valve and very low temperatures causing an uncommanded reversal, and the AA191 DC-10 crash was a result of uncommanded slat retraction as a consequence of engine pylon failure.
* - so maybe "failure" was the wrong word
Last edited by DozyWannabe; 26th Jun 2010 at 10:54.
Guest
Join Date: Apr 2009
Location: On the Beach
Posts: 3,336
Likes: 0
Received 0 Likes
on
0 Posts
Link to two papers concerning the AAL 965 December, 1995 CFIT near Cali, Colombia.
One is the NTSB ATC chairman's factual report. The other is an article I wrote for the April, 1996 ALPA Magazine about the crash and related issues.
Index of /cali
One is the NTSB ATC chairman's factual report. The other is an article I wrote for the April, 1996 ALPA Magazine about the crash and related issues.
Index of /cali
Join Date: Jun 2010
Location: USA
Posts: 245
Likes: 0
Received 0 Likes
on
0 Posts
Invitation
At BOAC invitation I will respond here to bearfoil's comments in the Islamabad thread.
In one sense I agree with FlightSaftey and others that the historical trend towards fully automated planes must run its course.Where I disagree (perhaps) is that I think that:
(1) this trend deserves to be followed to it's logical conclusion because it has earned the opportunity to do so by factually demonstrating it can improve safety. I have no inherent love for a machine over man (usually quite the opposite).
(2) that this trend should run its course by real world experimentation. By that I mean you take fully automated commercial flights, with real passengers in them, and let them fly their routes, and see if they crash or not.
(3) That the results of this experimentation should dictate whether the human being has any future on the flight deck.
In his last comment bearfoil wondered if I have bias. I most certainly do. But my bias isn't toward the result but towards the process. I don't care whether human beings are or are not in the cockpit 100 years from now. But I do believe that this decision should be made based upon factual data rather than appeals to emotion ("consider the tradition of the pilot!" or "machines rob humanity of dignity!") or philosophical paeans to "balance". If balance causes more death than unbalance, balance can take a hike.
In one sense I agree with FlightSaftey and others that the historical trend towards fully automated planes must run its course.Where I disagree (perhaps) is that I think that:
(1) this trend deserves to be followed to it's logical conclusion because it has earned the opportunity to do so by factually demonstrating it can improve safety. I have no inherent love for a machine over man (usually quite the opposite).
(2) that this trend should run its course by real world experimentation. By that I mean you take fully automated commercial flights, with real passengers in them, and let them fly their routes, and see if they crash or not.
(3) That the results of this experimentation should dictate whether the human being has any future on the flight deck.
In his last comment bearfoil wondered if I have bias. I most certainly do. But my bias isn't toward the result but towards the process. I don't care whether human beings are or are not in the cockpit 100 years from now. But I do believe that this decision should be made based upon factual data rather than appeals to emotion ("consider the tradition of the pilot!" or "machines rob humanity of dignity!") or philosophical paeans to "balance". If balance causes more death than unbalance, balance can take a hike.
Per Ardua ad Astraeus
Thread Starter
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
Thanks MB - a balanced view. Despite your views in the last para, I suspect that 'emotions' will be high on the list of decisive factors here. I have no doubt that we have the technology to reliably automate a large part of the process.
It will take a generation or two of 'pilots' to grow out the idea of 'being there', and a major deciding factor will be the media-led public reaction. Which is more headline-grabbing?
"Pilot gets lost and flies xxx passengers into a hill" or
"Terrified passengers fly around for 3 hours before crashing into a school for disabled orphans in the middle of YYY after automatic plane control is lost."
OK, just a little bias there
It will take a generation or two of 'pilots' to grow out the idea of 'being there', and a major deciding factor will be the media-led public reaction. Which is more headline-grabbing?
"Pilot gets lost and flies xxx passengers into a hill" or
"Terrified passengers fly around for 3 hours before crashing into a school for disabled orphans in the middle of YYY after automatic plane control is lost."
OK, just a little bias there
Join Date: May 2005
Location: In some Marriott
Posts: 49
Likes: 0
Received 0 Likes
on
0 Posts
BOAC, thanks for the link to this thread from the Islamabad one; good reading here. Its a worthwhile and important topic. However, I fear the pilots who should read it will not...
Automatics addiction is a very real problem that is not limited to the younger generation. I have watched older, more experienced pilots go heads-down at the most inappropriate times. One in particular could talk-the-talk on the pitfalls of automation, yet when push came to shove he stopped flying and started typing.
My perception is automatics addiction is not a function of age, intelligence or education. Unfortunately, automatics addiction does not equal automatics mastery.
My limited experience with automatics training (I say limited because most instructors are addicts not masters) encourages "gee-whiz, look at that." The emphasis is what the jet can do without me rather than what it can do for me. It is a subtle yet important difference in perspective.
Finally, two pet-peeves: I dislike referring to the FMS/FMC as "Captain Honeywell" (fill in the blank on manufacturer) as it indicates an abdication of control to the boxes. Also, the notion that we can automate the human out of the cockpit. We are the most capable, flexible and powerful computer aboard any aircraft. So much talk about pilot error and so little about those everday things we do that make aviation as safe as it is.
Before I get flamed for asserting how good humans are, I know we are fallible. But I also know Sparky is fallible too. One quick example: My last two trips across the International Dateline made all three FMS's go goofy. ETA's were so bad I actually broke out a CR-3 and figured them manually. Thus far, Honeywell has no explanation. By the way, nothing special about breaking out a CR-3; just doing my job.
Not sure I contributed anything to this topic, but thanks for starting it BOAC.
Best,
GC
Automatics addiction is a very real problem that is not limited to the younger generation. I have watched older, more experienced pilots go heads-down at the most inappropriate times. One in particular could talk-the-talk on the pitfalls of automation, yet when push came to shove he stopped flying and started typing.
My perception is automatics addiction is not a function of age, intelligence or education. Unfortunately, automatics addiction does not equal automatics mastery.
My limited experience with automatics training (I say limited because most instructors are addicts not masters) encourages "gee-whiz, look at that." The emphasis is what the jet can do without me rather than what it can do for me. It is a subtle yet important difference in perspective.
Finally, two pet-peeves: I dislike referring to the FMS/FMC as "Captain Honeywell" (fill in the blank on manufacturer) as it indicates an abdication of control to the boxes. Also, the notion that we can automate the human out of the cockpit. We are the most capable, flexible and powerful computer aboard any aircraft. So much talk about pilot error and so little about those everday things we do that make aviation as safe as it is.
Before I get flamed for asserting how good humans are, I know we are fallible. But I also know Sparky is fallible too. One quick example: My last two trips across the International Dateline made all three FMS's go goofy. ETA's were so bad I actually broke out a CR-3 and figured them manually. Thus far, Honeywell has no explanation. By the way, nothing special about breaking out a CR-3; just doing my job.
Not sure I contributed anything to this topic, but thanks for starting it BOAC.
Best,
GC
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes
on
0 Posts
Just to put the cat truly amongst the pigeons, how about this, which I just wrote? Fully-Automatic Execution of Critical Manoeuvres in Airline Flying
PBL
PBL
Per Ardua ad Astraeus
Thread Starter
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
I can see no obstacles to what you propose other than emotive ones.
However, taking your 4) (Airblue Islamabad) - with the technology that would permit an 'automatic' CTL, surely it would be more logical to simply produce an 'automatic' approach to R12? The only time a CTL would then be required would be in the event of a very late runway change since there would otherwise be no need for an approach at all on R30.
However, taking your 4) (Airblue Islamabad) - with the technology that would permit an 'automatic' CTL, surely it would be more logical to simply produce an 'automatic' approach to R12? The only time a CTL would then be required would be in the event of a very late runway change since there would otherwise be no need for an approach at all on R30.
Join Date: Jun 2006
Location: Australia
Posts: 1,186
Likes: 0
Received 0 Likes
on
0 Posts
I would, as others, press hard for some formal sim training in low speed out-of-trim full power g/a handling for low-slung beasties at least for starters
The reply from the chief regulator was short and not sweet. He said that the Australian regulations covering proficiency and instrument rating tests already legally ensured pilot skills were up to scratch an that on the contrary more emphasis should be placed on automatics skills.
In my view automation complacency is so well entrenched in aviation that it is a lost cause to hope that manual flying practice will be actively pursued by todays airline pilots.
Per Ardua ad Astraeus
Thread Starter
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
Alarming!
Tee Emm's post is a reminder that we need to focus on the here and now and what should be done in training and skill development to avoid the sorts of accidents we are seeing more of now. PBL's concept stuff is worthy of attention, but will takes years to get through the design and regulatory gates.
Tee Emm's post is a reminder that we need to focus on the here and now and what should be done in training and skill development to avoid the sorts of accidents we are seeing more of now. PBL's concept stuff is worthy of attention, but will takes years to get through the design and regulatory gates.
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes
on
0 Posts
I am not sure if I was proposing the concept in the sense of suggesting commercial aviation should go in that direction. I was noting that there is a clear argument for 4 out of the 6 accidents I mentioned that the state of the art in control systems can do, now, what those airplanes apparently did not do under pilot control. And maybe for all 6, depending on what we find out. I suspect this argument will be supported if one looks further back as well. And if the argument is out there to be made, then someone will use it to say we should go that route. I don't know if that someone would be me.
I see not only significant regulatory hindrances to realisation, but also significant technical and procedural hindrances.
First, technical. Such aircraft control systems must be shown to be reliable and fail-safe, and current kit is not so designed. Think of Turkish, whose AT was fed data from just one RA, and RAs are known to fail relatively often, compared with other avionics. We are a ways away from thorough fail-safe design through and through. And that is a prerequisite. No more map-shifts. And so on.
Second, procedural. In busy TMAs, the entire traffic control is predicated on flexibility, in heading, altitude, and airspeed when sequenced on final. Switching to pre-programmed full automation will require a massive system requirements change, and I am not sure anyone yet knows how it could be done, even the theory of it.
I don't know which of these would prove the bigger challenge.
I agree that it might make more sense to devise an appropriate approach to RWY 12 at Islamabad rather than CTL from RWY 30. If one wishes to turn that into a general argument that one doesn't do CTL's on full automatics, that might well be a negotiating point in a step change to full automatics. But if the response to that by some parties is to continue to allow hand-flown CTL's, then we would not have advanced from the current situation. If one switches to full automatics, one wants to do so especially for the demonstrably more risky procedures, I would think.
There are a lot of details, and it will take a lot of work and a lot of time, if we go that route.
PBL
I see not only significant regulatory hindrances to realisation, but also significant technical and procedural hindrances.
First, technical. Such aircraft control systems must be shown to be reliable and fail-safe, and current kit is not so designed. Think of Turkish, whose AT was fed data from just one RA, and RAs are known to fail relatively often, compared with other avionics. We are a ways away from thorough fail-safe design through and through. And that is a prerequisite. No more map-shifts. And so on.
Second, procedural. In busy TMAs, the entire traffic control is predicated on flexibility, in heading, altitude, and airspeed when sequenced on final. Switching to pre-programmed full automation will require a massive system requirements change, and I am not sure anyone yet knows how it could be done, even the theory of it.
I don't know which of these would prove the bigger challenge.
I agree that it might make more sense to devise an appropriate approach to RWY 12 at Islamabad rather than CTL from RWY 30. If one wishes to turn that into a general argument that one doesn't do CTL's on full automatics, that might well be a negotiating point in a step change to full automatics. But if the response to that by some parties is to continue to allow hand-flown CTL's, then we would not have advanced from the current situation. If one switches to full automatics, one wants to do so especially for the demonstrably more risky procedures, I would think.
There are a lot of details, and it will take a lot of work and a lot of time, if we go that route.
PBL
Peter, your provocative article #95, argues for improving safety by replacing the human with automation. For the moment, the human aspects in design and maintenance are put aside.
Technically, full automation might be possible, but as discussed in http://www.pprune.org/safety-crm-qa-...ml#post5889774 this would involve constraint.
The example military operations are constrained to specific airfields, tasks, and I suspect weather conditions. Would such constraints be acceptable to civil operations, or if not, what costs (practicality) will the industry / travelling public tolerate to achieve such idealised safety?
Accepting constraints might well improve safety; no precision guidance, no autolanding, no flights to that airport = safety. This theoretical argument concludes that is safer to stay on the ground than fly, or use other means of transport (which may not be as safe as aviation).
I would argue that when discussing automation, practicality has to be the foremost view. By all means consider academic theories, but don’t loose sight of the practicalities.
Perfect safety may only exist in theory; in practice it involves managing risk – “safety is the avoidance of unnecessary risk” - safety is a compromise.
Practical solutions for improving safety should come from identifying and avoiding risk, both strategically and tactically, and in planning and practice.
We have to define ‘unnecessary’, which is undoubtedly connected with the situation, both now and future, what is the goal, or objective; how do these change with time and task.
Automation (technology) I suggest, is not better than the human in these tasks, even with human weaknesses resulting in error. The currently accepted judgement is that the human (with current automation) meets the requirements for safety – the public perception (TM #97 !!!).
For the accidents cited, assuming human involvement, we need to understand why the human performance did not meet the requirements of safety, whereas the vast majority of similar operations have done – why are these accidents or apparently the human behaviour in them, different from daily operations.
With such understanding, from accident reports (not always forthcoming or of sufficient depth), then it might be possible to pursue a combination of man and machine, e.g. technology aided decision making, situation awareness, EGPWS like systems and auto pull-up, and LOC auto recovery, as a stepping stone to increased automation.
Perhaps a practical study of the human and the man-machine interface would be more worthwhile.
Technically, full automation might be possible, but as discussed in http://www.pprune.org/safety-crm-qa-...ml#post5889774 this would involve constraint.
The example military operations are constrained to specific airfields, tasks, and I suspect weather conditions. Would such constraints be acceptable to civil operations, or if not, what costs (practicality) will the industry / travelling public tolerate to achieve such idealised safety?
Accepting constraints might well improve safety; no precision guidance, no autolanding, no flights to that airport = safety. This theoretical argument concludes that is safer to stay on the ground than fly, or use other means of transport (which may not be as safe as aviation).
I would argue that when discussing automation, practicality has to be the foremost view. By all means consider academic theories, but don’t loose sight of the practicalities.
Perfect safety may only exist in theory; in practice it involves managing risk – “safety is the avoidance of unnecessary risk” - safety is a compromise.
Practical solutions for improving safety should come from identifying and avoiding risk, both strategically and tactically, and in planning and practice.
We have to define ‘unnecessary’, which is undoubtedly connected with the situation, both now and future, what is the goal, or objective; how do these change with time and task.
Automation (technology) I suggest, is not better than the human in these tasks, even with human weaknesses resulting in error. The currently accepted judgement is that the human (with current automation) meets the requirements for safety – the public perception (TM #97 !!!).
For the accidents cited, assuming human involvement, we need to understand why the human performance did not meet the requirements of safety, whereas the vast majority of similar operations have done – why are these accidents or apparently the human behaviour in them, different from daily operations.
With such understanding, from accident reports (not always forthcoming or of sufficient depth), then it might be possible to pursue a combination of man and machine, e.g. technology aided decision making, situation awareness, EGPWS like systems and auto pull-up, and LOC auto recovery, as a stepping stone to increased automation.
Perhaps a practical study of the human and the man-machine interface would be more worthwhile.