PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Tech Log (https://www.pprune.org/tech-log-15/)
-   -   Opportunities, Challenges, and Limits of Automation in Aircraft (https://www.pprune.org/tech-log/553856-opportunities-challenges-limits-automation-aircraft.html)

FCeng84 8th Jan 2015 23:37

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.

Mad (Flt) Scientist 9th Jan 2015 02:30

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?

Oakape 9th Jan 2015 03:47


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.

Hunter58 9th Jan 2015 04:10

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...

island_airphoto 9th Jan 2015 05:13

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 9th Jan 2015 07:06

Please let us know what you fly.

island_airphoto 9th Jan 2015 08:15

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 ;)

FCeng84 9th Jan 2015 16:03

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 9th Jan 2015 16:31

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.

island_airphoto 11th Jan 2015 15:56

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 ;)

FCeng84 12th Jan 2015 19:18

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.

island_airphoto 12th Jan 2015 19:48

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.

john_tullamarine 12th Jan 2015 21:07

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 ?

climber314 4th Dec 2018 18:03


Originally Posted by FCeng84 (Post 8822388)
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.

megan 4th Dec 2018 22:59

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

underfire 5th Dec 2018 12:28

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.

climber314 5th Dec 2018 20:03

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.

Atlas Shrugged 6th Dec 2018 02:00

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.

Vessbot 6th Dec 2018 02:16


Originally Posted by Atlas Shrugged (Post 10329038)
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.

Atlas Shrugged 6th Dec 2018 02:57

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.


All times are GMT. The time now is 12:53.


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