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

Opportunities, Challenges, and Limits of Automation in Aircraft

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

Opportunities, Challenges, and Limits of Automation in Aircraft

Old 8th Jan 2015, 23:37
  #21 (permalink)  
 
Join Date: Feb 2009
Location: Seattle
Posts: 379
Likes: 0
Received 0 Likes on 0 Posts
Car without cruise control and GPS

I think a better analogy is an auto driver whose GPS navigation system and cruise control fail. Many would have a hard time these days with a paper map and having to control speed on the highway, but all should be able to.
FCeng84 is offline  
Old 9th Jan 2015, 02:30
  #22 (permalink)  
 
Join Date: Sep 2002
Location: La Belle Province
Posts: 2,179
Likes: 0
Received 0 Likes on 0 Posts
To extend the car analogy, though - should someone who has only ever driven an automatic (and maybe only passed whatever test they passed on one) be allowed to drive a manual?

What if the automatic has provision for operation as a manual?
Mad (Flt) Scientist is offline  
Old 9th Jan 2015, 03:47
  #23 (permalink)  
 
Join Date: May 2007
Location: Western Pacific
Posts: 721
Likes: 0
Received 0 Likes on 0 Posts
ROUTINE vs rare, you are talking about one in a million event.
We are talking about the military, or experimental aircraft, or aviation theory here. We are talking about passenger carrying commercial aviation. A one in a million event would be quite frequent these days & I don't believe that the industry could sustain a weekly fatal hull loss. The traveling public would just not accept it.

Tweeting aircraft to get maximum performance at the detriment of a fall back position where the pilot can get it home when the automatics fail, combined with less & less pilot training due to cost, is pushing the boundaries of what the customer will find acceptable. The never ending quest for lower fares & more profit has a dark side. Try telling the customer that they are in a lottery & bad luck - your number just came up. Worse still, try telling that to the family members left behind.

Things cost. Safety & reliability cost. And the sooner people wake up to the cost of flying around the world at speed in comfort, with safety in mind, the better! Constant downward pressure on costs, combined with constant demand for more profit isn't sustainable. And that applies to all aspects of business.
Oakape is offline  
Old 9th Jan 2015, 04:10
  #24 (permalink)  

Freight God
 
Join Date: Sep 2000
Location: LS-R54A
Posts: 307
Likes: 0
Received 0 Likes on 0 Posts
All commercial FBW aircraft are first and foremost very nice flying maschines. They have to fulfill the same flight dynamic capabilities than any conventional aircraft. The FBW part concerns only the way the pilot input gets to the control surfaces. This as such is NOT automation.

Otto is the additional stuff commonly referred to as the 'autopilot'. And there is that famous dependency on the magenta line, regardless of manufacturer and type. All manufacturers and regulative authorities operate on the basic principle that the crew is consisting of PILOTS and not some system administrators punching buttons.

We may, however, have a problem that some Airlines have forgotten the latter part of the basics of aviation. Which those airlines are is not visible by their business model. Last time I checked Air France was not a low frill/cost carrier...
Hunter58 is offline  
Old 9th Jan 2015, 05:13
  #25 (permalink)  
 
Join Date: Jul 2013
Location: Maryland USA
Posts: 133
Likes: 0
Received 0 Likes on 0 Posts
The better analogy would be drivers so used to lane assist and adaptive cruise control they hit the car ahead of them or drive right off the road if the system goes offline.
(having grown up with an ancient Porsche with carbs and no power assist auto ANYTHING, I wonder if my son could even get such a car started when he turns 16. ABS, DSC, and EFI will be all he has ever seen)

@Mad (Flt) Scientist
To extend the car analogy, though - should someone who has only ever driven an automatic (and maybe only passed whatever test they passed on one) be allowed to drive a manual?

What if the automatic has provision for operation as a manual?
island_airphoto is offline  
Old 9th Jan 2015, 07:06
  #26 (permalink)  
 
Join Date: Jul 2013
Location: Maryland USA
Posts: 133
Likes: 0
Received 0 Likes on 0 Posts
Please let us know what you fly.
island_airphoto is offline  
Old 9th Jan 2015, 08:15
  #27 (permalink)  
 
Join Date: Jul 2013
Location: Maryland USA
Posts: 133
Likes: 0
Received 0 Likes on 0 Posts
It is relevant. If you have never had to fight weather AND some crazy autopilot at the same time, you have no frame of reference for what we are talking about. Kind of like how a a GPS map coupled to an engine governor that will never allow a car to exceed the speed limit makes perfect sense to a bicycle rider from Bermuda who has never driven a car or seen a highway
island_airphoto is offline  
Old 9th Jan 2015, 16:03
  #28 (permalink)  
 
Join Date: Feb 2009
Location: Seattle
Posts: 379
Likes: 0
Received 0 Likes on 0 Posts
Hunter58 has the following paragraph in an entry above:

"All commercial FBW aircraft are first and foremost very nice flying maschines. They have to fulfill the same flight dynamic capabilities than any conventional aircraft. The FBW part concerns only the way the pilot input gets to the control surfaces. This as such is NOT automation."

I agree completely with the first, second, and fourth sentences above. My issue is with the third sentence. FBW concerns both the way that the pilot input gets to the control surfaces and how feedback of sensed airplane response also factors into the surface commands to achieve the desired response characteristics. Connecting the elevator directly to the pilots controller without any feedback augmentation will not necessarily (and need not) result in acceptable response characteristics. Careful design of the combination of pilot to surface and feedback control paths results in an integrated system that defines the augmented handling qualities that the pilot experiences.
FCeng84 is offline  
Old 9th Jan 2015, 16:31
  #29 (permalink)  
 
Join Date: Feb 2009
Location: Seattle
Posts: 379
Likes: 0
Received 0 Likes on 0 Posts
Jockey69 - Your line of thinking seems to suggest throwing out the baby along with the bath water. With that perspective we would not be flying at all.

Technology advancement has involved taking risks to explore new horizons. We all owe a debt of gratitude to those how have been pioneers in these areas. Our challenge now is to take the knowledge available and apply it to design and operation of commercial transport systems in such a manner that the risk imposed on the travelling public is reduced to an acceptable level - far below that encountered by the pioneers. We cannot push that risk to zero, but we can make it very small.

Part of our challenge is also to make commercial air transport as affordable as possible without increasing risk above an acceptable threshold. FBW control system technology is playing a major role in that evolution. With this comes dependency on feedback augmentation to provide acceptable handling qualities while enabling performance optimization.

As long as there are failure scenarios that can disable or corrupt data vital to performance of the flight control system in its full up configuration, there will be need for means of recognizing that corruption and gracefully transition to reversionary control system modes employing a smaller, more robust set of feedback signals.

Pilots must be capable of continuing safe flight and landing in all control system modes to which they may be exposed. Training should be defined with consideration for control system mode reversion so that flight crews have both the confidence and skills needed for the task.
FCeng84 is offline  
Old 11th Jan 2015, 15:56
  #30 (permalink)  
 
Join Date: Jul 2013
Location: Maryland USA
Posts: 133
Likes: 0
Received 0 Likes on 0 Posts
Hey - now the thread is cleaned up we can continue on.
Basic Problem:
If you make the plane able to overrule the pilot, you can prevent many accidents. You can also cause them when the HAL gets wrong data or when a new situation arises that HAL has no idea how to handle and doesn't allow the pilot to make the needed input.
IMHO humans would rather be killed by human error than a stupid computer that can't be stopped
island_airphoto is offline  
Old 12th Jan 2015, 19:18
  #31 (permalink)  
 
Join Date: Feb 2009
Location: Seattle
Posts: 379
Likes: 0
Received 0 Likes on 0 Posts
Examples of Hal not letting a pilot save the day?

I agree with the opinion that people would rather tilt the scale in the direction of allowing a pilot to screw it up vs. allowing the system to end the day by not permiting the crew to take over. I would like to know about examples of when the pilot's inability to take over has been a major contributor to an accident - I can't think of any right off hand.

I think the bigger problem is that crews have all too often lost situational awareness and have either blindly followed errant displays or simply persisted with pilot inputs that were not appropriate (e.g., nose up command when at high AOA and descending due to stall or simply insufficient lift resulting from very low speed). I would put erroneous air data high on that list. The air data technology we have on commercial transports today is not sufficient to ignor the need to recognize when it has failed and to respond accordingly. Both Hal and the carbon units up front have a role to play in this one.

Another issue is pilots being unfamiliar with flying without the autopilot and/or autothrottle. Closely coupled is lack of awareness of the current automation mode(s) and thus not recognizing what pilot inputs are needed to fly the intended path/speed. The B777 clipping the seawall on the way into SFO is a prime example of the crew not recognizing the need to monitor and control speed. For that event it seems that the crew may have assumed that the autothrottle was minding speed while they made an attempt (all be in not a very good one) to manually control path.

I would sure be a supporter of simulator training where starting at cruise an engine is failed and both the autopilot and authrottle are disengaged and the crew has the task of landing at an alternate. As SLF I would be more comfortable in back if I knew that the team up front had that practice on a regular basis.
FCeng84 is offline  
Old 12th Jan 2015, 19:48
  #32 (permalink)  
 
Join Date: Jul 2013
Location: Maryland USA
Posts: 133
Likes: 0
Received 0 Likes on 0 Posts
The Air Force lost some F-16s early in the program when HAL would not let the pilots pull up hard enough to avoid solid ground.
Autothrottles are a prime example of where automation fails us by making humans complacent. It apparently makes flying a lot easier - never had a plane with this myself - but absent autothrottles forgetting about power and airspeed on final would be like forgetting how to walk. Now - maybe not so much because the airplane does it for you for so much of the time. Of course if you try and take them away the 99.9% of pilots that didn't forget how to use them correctly would be screaming.
island_airphoto is offline  
Old 12th Jan 2015, 21:07
  #33 (permalink)  
Moderator
 
Join Date: Apr 2001
Location: various places .....
Posts: 7,178
Received 92 Likes on 61 Posts
First, my apologies as I had not been monitoring this thread as routinely as I should have done ... otherwise it would have been brought to heel a bit quicker ..

Some comments -

(a) if one has a disagreement with the thrust of the conversation, by all means put your disagreement but, please, don't restate the point ad infinitum .. it gets terribly distracting and boring

(b) the rational person accepts that the automatics are here to stay for all the right reasons. There is no realistic view which suggests that we can (or should) reverse the trend.

(c) whether an individual pilot prefers stick and rudder or automatics largely is irrelevant to the discussion

(d) clearly, if an unrecoverable catastrophic event occurs, the pilot is along for the ride .. eg wing separation

(e) however, depending on the individual pilot's knowledge base, skill set and determination .. a varying range of significant failures can result in a variety of outcomes .. some more successful than others. While there are a few in the records, my favourite is UA 232. By rights none on board should have had any chance of survival .. yet Haynes and his crew pulled off a miracle .. albeit with some peripheral bits of good fortune to help out along the way. If the phugoid hadn't caught them out at the last moment, they may have pulled off the miracle of the century .. but the gremlins have to get a foot in the door.

(f) it should be a reasonable view that the typical competent pilot can address minor, but initially confusing or improbable, JB failures and reversions

(e) the question is, regardless of the presumed probability of an undesirable event outcome, do we want pilots who have no/little chance of rising to the occasion on the day (ie the button pushers) - in which case we should look to UAVs ... or folk who have sufficient training and exposure to have a reasonable chance of saving the day (ie those who use the buttons intelligently but retain a sufficient basic skill competence to operate) following intentional/unintentional use of the O-F-F button ?
john_tullamarine is offline  
Old 4th Dec 2018, 18:03
  #34 (permalink)  
 
Join Date: Jun 2014
Location: Chocolatetown
Age: 63
Posts: 83
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by FCeng84
Examples of Hal not letting a pilot save the day?

I agree with the opinion that people would rather tilt the scale in the direction of allowing a pilot to screw it up vs. allowing the system to end the day by not permitting the crew to take over. I would like to know about examples of when the pilot's inability to take over has been a major contributor to an accident - I can't think of any right off hand.
Looks like we have one now... JT610.
climber314 is offline  
Old 4th Dec 2018, 22:59
  #35 (permalink)  
 
Join Date: Mar 2005
Location: N/A
Posts: 5,880
Received 362 Likes on 192 Posts
I'm surprised that the Qantas A330 upset has not gained a mention thus far. Synopsis,
On 7 October 2008, an Airbus A330-303 aircraft, registered VH-QPA and operated as Qantas flight 72, departed Singapore on a scheduled passenger transport service to Perth, Western Australia. While the aircraft was in cruise at 37,000 ft, one of the aircraft's three air data inertial reference units (ADIRUs) started outputting intermittent, incorrect values (spikes) on all flight parameters to other aircraft systems. Two minutes later, in response to spikes in angle of attack (AOA) data, the aircraft's flight control primary computers (FCPCs) commanded the aircraft to pitch down. At least 110 of the 303 passengers and nine of the 12 crew members were injured; 12 of the occupants were seriously injured and another 39 received hospital medical treatment.Although the FCPC algorithm for processing AOA data was generally very effective, it could not manage a scenario where there were multiple spikes in AOA from one ADIRU that were 1.2 seconds apart. The occurrence was the only known example where this design limitation led to a pitch-down command in over 28 million flight hours on A330/A340 aircraft, and the aircraft manufacturer subsequently redesigned the AOA algorithm to prevent the same type of accident from occurring again.Each of the intermittent data spikes was probably generated when the LTN-101 ADIRU's central processor unit (CPU) module combined the data value from one parameter with the label for another parameter. The failure mode was probably initiated by a single, rare type of internal or external trigger event combined with a marginal susceptibility to that type of event within a hardware component. There were only three known occasions of the failure mode in over 128 million hours of unit operation. At the aircraft manufacturer's request, the ADIRU manufacturer has modified the LTN-101 ADIRU to improve its ability to detect data transmission failures.At least 60 of the aircraft's passengers were seated without their seat belts fastened at the time of the first pitch-down. The injury rate and injury severity was substantially greater for those who were not seated or seated without their seat belts fastened. The investigation identified several lessons or reminders for the manufacturers of complex, safety‑critical systems.
The worrying part is the highlighted portion, and the reason this SLF wants a human upfront, he/she may not be perfect and prone to their own failures, but they represent the final get out of jail card when the folk/designers on the ground have boo booed on coding/design/architecture. Post event the Captain retired with PTSD. Page 191 of the link for analysis. It is perhaps pertinent to this thread to post a portion of the analysis.
Limitations of simulation and testing activities
Another means of detecting a design problem is through the use of the simulation and testing activities conducted during the verification and validation processes. However, the selection of the simulations and tests needs to be prioritised based on an identified need, and this will usually focus on confirming that the design meets the specified requirements, and that it effectively manages identified failure modes or specific types of incorrect inputs. Any activities beyond the scope of verifying the explicitly defined design requirements must rely on the expertise of those involved, which is as fallible as any other human activity.
Due to the wide range of potential inputs into a complex system such as the EFCS, simulation and testing programs cannot exhaustively examine all the possible patterns of inputs. In the case of the FCPC algorithm for processing AOA, the simulation and testing activities examined the new design’s ability to handle the situation that led to the redesign. They also included previously identified tests to ensure there were no regression problems with the system design. However, they would not realistically have included a scenario involving multiple AOA data spikes 1.2 seconds apart unless the potential problem had previously been identified.
https://www.atsb.gov.au/media/3532398/ao2008070.pdf
megan is online now  
Old 5th Dec 2018, 12:28
  #36 (permalink)  
 
Join Date: Aug 2013
Location: PA
Age: 59
Posts: 30
Likes: 0
Received 0 Likes on 0 Posts
Personally, the certification process needs to be rethought. The latest version of the FMS is based on what, a 486 processor. The avionics software, instead of certifying a new version with new, up to date electronics, and software, is bastardized by the process. Version upon version is dogpiled on, because a revision is easy to certify, while a new system certification would take forever.
Thus we are constrained by legacy avionics, even on brand new variants. We are all well aware that there is far more computer power in our watches and phones, than what is installed on the flightdeck, and that is a sad result of the certification process.

Due to the wide range of potential inputs into a complex system such as the EFCS, simulation and testing programs cannot exhaustively examine all the possible patterns of inputs. In the case of the FCPC algorithm for processing AOA, the simulation and testing activities examined the new design’s ability to handle the situation that led to the redesign.
Exactly, with a software version, built upon the legacy programming. This is, until somewhere in the million lines of code, a lookup feature finds some legacy variable, and it all falls apart.

Allow the streamlined certification process of a brand new system, built upon the capabilities of the brand new variants. The software and avionics follow a straight path in the programming, not a multi-threaded path of cascading possibilities, that many times, is not figured out until the ac is on revenue flights.
underfire is offline  
Old 5th Dec 2018, 20:03
  #37 (permalink)  
 
Join Date: Jun 2014
Location: Chocolatetown
Age: 63
Posts: 83
Likes: 0
Received 0 Likes on 0 Posts
With respect to JT610 and the 737 Max, does it matter if the technology is based on a 8086, 286 or some other older processor? It's not a full blown AI system we're talking about. If MCAS is limited to function only when AoA Agree = Yes, there is no crash. Assuming pilots can fly.

If we're talking autonomous flight, FBW or something similar then by all means more processing power is better and new code preferred.
climber314 is offline  
Old 6th Dec 2018, 02:00
  #38 (permalink)  
 
Join Date: Jan 2004
Location: Hiding..... in one hemisphere or another
Posts: 1,067
Received 1 Like on 1 Post
The biggest thing with automation at the moment is that it is not 'complete' automation. Partial automation is a huge issue - having a pilot who's supposed to take over when the system craps itself, but who otherwise does nothing............... he's only there for when the going gets really tough, but the automation won't always keep him in the loop, or keep him in practice, but will still expect him to go from brain dead to aviation hero in an instant.

At some point the technology will become reliable enough but it is nowhere even remotely near that right now. First, you have to assume that the programmers will make NO ERRORS (!), and second, that they will think of EVERYTHING (!!) or come up with an AI that can HANDLE EVERYTHING (!!!).

I expect they'll be working on it for many, many, years before it ever becomes viable.
Atlas Shrugged is offline  
Old 6th Dec 2018, 02:16
  #39 (permalink)  
 
Join Date: Sep 2016
Location: USA
Posts: 799
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Atlas Shrugged
The biggest thing with automation at the moment is that it is not 'complete' automation. Partial automation is a huge issue - having a pilot who's supposed to take over when the system craps itself, but who otherwise does nothing............... he's only there for when the going gets really tough, but the automation won't always keep him in the loop, or keep him in practice, but will still expect him to go from brain dead to aviation hero in an instant.

At some point the technology will become reliable enough but it is nowhere even remotely near that right now. First, you have to assume that the programmers will make NO ERRORS (!), and second, that they will think of EVERYTHING (!!) or come up with an AI that can HANDLE EVERYTHING (!!!).

I expect they'll be working on it for many, many, years before it ever becomes viable.
You're capturing something I've been trying to say for a while. To be even more succinct (something I'm not good at) -- right now we're in a gap, where the baton of ultimate responsibility is being passed from human pilots to the automation - but it's not a smooth pass, and there's no one to hold it in the interim.
Vessbot is offline  
Old 6th Dec 2018, 02:57
  #40 (permalink)  
 
Join Date: Jan 2004
Location: Hiding..... in one hemisphere or another
Posts: 1,067
Received 1 Like on 1 Post
Exactly Vessbot.

Another thing that I think about is that as the systems improve, which they will, the point at which they fail will be further and further into the areas that make the aircraft harder to fly with the system handing over a larger and larger pile of excrement as it progresses, QF32 a possible example.

It seems as if Airbus have tried to engineer pilots out as much as possible, and in doing so have made aircraft that are, in some situations, very much more difficult to fly than they need to be. They have taken a lot of the day-to-day things and automated them and this has had the effect of weakening pilot skills and when it does drop its bundle you'll need those very same now weakened skills to fix it. Every day there are possibly hundreds of events around the world where the automatics go haywire in one form or another, and it's fixed by the pilots, who simply tidy up and continue on their way. If you stopped those fixes, it would start raining aluminium.

There is no such thing as something that cannot fail..... at least not at the moment.
Atlas Shrugged is offline  

Thread Tools
Search this Thread

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.