In the early days when we did so, Airbus was not the least bit interested in our input and critique, and actively so.
Really? It's a bit at odds with what my late prof discovered when visiting Toulouse:
Originally Posted by Peter Mellor
The EFCS life cycle involves requirements capture resulting in an equipment specification, including hardware, software, and functional specifications. The pilot is very definitely "in the loop'' for requirements capture, which is an iterative process using rapid prototyping and flight tests. Emphasis is placed on validation of functional requirements, which is clearly distinguished from verification.
But much has changed since the 90s.
True, but Prof Mellor's visit was in 1993, and the implication is that pilots have been in the requirements-gathering loop since the start of the A320 project.
Now, if you're saying that they weren't interested in input outside the pilots that defined their requirements-gathering group, I don't know. But I do remember the hyperbole that was flying around back then - not helped by the Habsheim clusterfunk, so it's understandable that AI (as they were then) were probably on the defensive. Sorting out the wheat from the chaff when it came to line pilot feedback must have been an unforgiving task.
It's complicated. For a greater foundation regarding the notions of automation one perhaps has to return first to the military where FBW was not about "protection", it was about capability, clearly a very different motivation than airline flying!
As I said earlier, I'm not sure. I really think it was an honest look at where the state of the art was in aerospace technology and seeing if that couldn't be turned towards making line pilots' lives easier. "Protections" and safety enhancements were just a way of selling the idea to the public - remember that the A320's development passed through the year 1985, which was the worst year on record for jet-era civil aviation in terms of fatal accidents. Even the quadruple-failsafe 747, arguably the safest design flying at the time, was discovered to have a single point of failure in the case of rear pressure bulkhead damage blowing out the tailcone and ripping out all four hydraulic systems. If the mass of cables and hydraulics could be reduced to a failsafe electronically-controlled system and save a significant amount of all-up mass at the same time, the design decision is a no-brainer.
An airline managements' greatest mistake as automation developed, is buying into the (manufacturer's) notion that aircraft automation was all about saving money in training, reducing crew complement costs and 'easing' hiring practises, (not paying for 'expensive' experience because "experience was in the software" kind of idea).
I'm not sure that was ever the case, certainly not after the Mt. St. Odile accident - the saving that Airbus were pushing to airlines came not from reducing training in terms of aircraft handling, but from the fact that with the A32/3/40 series, the conversion training was completely minimal - almost a case of simply changing the numbers the pilots had to work with.
2-crew aircraft had been a fact of life on short-haul since the days of the One-Eleven, DC-9 and Jurassic 737, and the A300 made it possible on long-haul operations as well (shortly followed by the mighty 747-400). I think that's very important to remember.
The L1011, being a design from a primarily military designer, incorporated some wonderful notions of early automation, (while it's contemporary competitor's design remained a bread-and-butter, pedantic conventional design, very successful commercially and 'nice-to-fly' I believe but ordinary). The L1011 was a dream to learn and to fly. It came out of the chute CATIIIc-ready; the -500 series came with a brilliant FMC system.
The "contemporary competitor's" tale is in fact a classic case of cutting corners in design to attain a commercial goal, in this case beating a competitor to market. I've heard many tales of pilots waxing lyrical about how good the DC-10 felt to fly - and this also illustrates the point you make about what constitutes "Normal". In the case of the DC-10, the designers were so confident that what they were doing stuck to tried-and-true methodology that they suffered a failure of imagination - specifically regarding what happens in the case of explosive decompression in an aircraft of that size.
Boeing advanced the notion of "automation" through integration of the FMC and autopilot system. While it was Airbus that took automation into new territory with FBW, Boeing's triple-seven incorporated a deeper level of automation than the B767, (but not nearly as much as the new A320)
Hmm... not sure. What Boeing did with the 777 was very similar to what the "q-feel" engineers did in the '40s and '50s, which was take the new technology and implement it, but then use that technology to provide a facsimile of what came before. It always puzzled me in the days of the early AvB flamewars that those who said they were suspicious of the Airbus technology simply because of the fact that they did not trust computers were perfectly happy with the B777, which had all the requisite feel of the older airliners - provided by computer-driven force feedback.
The problems are not of technology but of psychology, perception, expectation and the strong tendency to "normalization" as a way of viewing the world.
This is true, and AI certainly managed to make a rod for their own backs in terms of their relationship with the piloting community based on their product evangelism and sales tactics in the early days. I like to think that they recognised that was a mistake and have learned from it.
Automation does not interfere with this error/threat management process but the "veil of automation", which has been greatly lifted over the past twenty years or so, must continue to be lifted
IMO it should never have been allowed to fall in the first place. The industry as a whole reacted to the advent of second-generation automation in a completely dysfunctional way. Not to blow my own trumpet, but I've had some really kind and supportive PMs over the last few weeks we've been discussing this subject, and the common thread has always been "Thanks for explaining it in a way I can understand". Understanding it is not difficult - I'm a layman when it comes to aviation, and until I got hold of a copy of HTBJ recently, a lot of the AoA discussion went right over my head, but when it comes to modern FBW systems in general and the Airbus model in particular, I firmly believe that all the dry language and engineering talk in the books can be boiled down to simple rules of logic by anyone of average intelligence.
In this case it's simply:
Normal Law -> All systems go, you can rely upon the protections
Alternate Law -> There's something wrong - protections will try to help you but if you need full authority it's there.
Alternate Law 2 -> You're missing data required for the protections to work, but you've got full pitch and trim authority via your sidestick and thrust authority via the levers.
Direct Law -> Exactly what it says on the tin.
Originally Posted by
BOAC
PJ - it was not really 'facetious' but a genuine caution against DW's suggestion of putting the a/c straight into Direct when things go awry
I didn't intend to suggest that, so maybe I miscommunicated. What I was saying is that as part of recurrent training, pilots should be taught how to deal with controlling the aircraft in Alternate Law and Direct Law reversions so that if it happens on the line itwon't come as a shock.