DISCUSSING ROBOLANDER (ATA Forum)
PAGE 2 of 2
On Behalf Of Rainman
Sent: Wednesday, 3 October 2001 9:56 AM
Subject: [ATA] Re: Safety, Risk, Design & Certification
Peter wrote: >As the Air Transat incident shows yet again, no amount of CSECLCF can take into account the likelihood of improper maintenance, because there are no techniques to estimate such a likelihood reliably. Indeed, as you know, CSECLCF does not take such phenomena into account. But maintenance is not perfect, and never will be.
Now you are trying to lure me into a discussion of how the process can be made better. And I already addressed this. I do not claim the "acceptable means" to demonstrate compliance to the FAA are perfect. They can, and should, certainly be improved as we go along. Suggestions?
Yes, what you call CSECLCF does not take into account maintenance. There may be no techniques used to estimate those likelihoods, but that does not mean none are viable. Indeed, design potential can again come to the rescue. I have been part of too many design efforts that (due to cost and schedule) did not consider design from a maintenance standpoint. If a system employs sealed connectors with different "keyways" to prevent cross-connections, then this aspect of the design can mitigate the probability of certain maintenance errors. Not make it vanish, of course, but can mitigate it.
Another design aspect is the breadth of "return-to-service" testing that verifies functionality after maintenance activities. Micro-processors have brought us a long way towards much better post-maintenance verification than what existed 30-40 years ago. Yes, they have introduced problems as well, but the net result is (by far) a "gain" not an "attenuation".
> There have actually been two such incidents of failure of supposedly > highly-reliable systems this year. The other was the mis-wired PFCS on the Lufthansa A320.
Any AD's written? That is what is supposed to happen. All operational findings need to be fed-back in the design process (but of course, the finance
types don't believe in life-cycle design for safety!)
> I don't know what to make of an argument which suggests I am misunderstanding something, but then suggests that maybe I really do know what I am talking about.
It is called being polite and giving you the opportunity to admit that you are not familiar with the precise definition and usage of the term you quote in the operational aviation industry. I could have just said "you are wrong to use MTBF in this manner, for the manner you use it in is not in accordance with the definition accepted in the operational industry."
> In any case, complaining about my use of terminology in this case is just sophistry.
No it's not, Peter. Of all people, a scientist such as yourself should understand that precision of definitions, and their use, in any subject domain is critical. Your use of MTBF does not match that used every day in the airline and aviation certification industry, as I will now demonstrate:
>We were talking about systems whose failure to perform *any* required function is potentially catastrophic.
No, we are not, and I must tell you that the FAA (or at least what they deem "acceptable means") would not agree with you here. My auto-land system uses a Flight Control Computer. One totally non-essential (to safe flight) design feature is its ability to interact with a maintenance CDU. If the transmitter that services the CDU fails, will the plane crash? No, because of spatial partitioning and failure containment (design). HOWEVER, that failure (which would NOT contribute to an in-flight hazard) is counted as a "hit" against the MTBF of the FCC. It is NOT potentially catastrophic if that non-essential maintenance bus dies in the middle of an auto-land. In fact, we demonstrated that to the FAA on MD-11 and 717. This definition and use of MTBF by the industry is what drives MTBF to be VERY different from the probabilities you see on a Fault Tree.
> MTBF and CSECLCF are thus the same for such systems. So it is quite accurate for me to use MTBF when talking about such systems, if I want to.
No, I am sorry, you are wrong, Peter. You will not likely admit it, but you are. I would suggest you take a sabbatical and go work with the Airbus avionics design engineers for the duration of the A380 program (if it lasts). You will likely learn that the definition interchangeability that you claim is "quite accurate" above is "quite inaccurate", and as such leads to inaccurate conclusions.
"My" FCC on the MD-11 and 717 has an MTBF on the order of about 2000 hours. By your definition of equivalence between MTBF and CSECLCF, then we should have had many catastrophes due to such failures. Control surface actuators have MTBFs in the 60,000-80,000 hour range. You are simply trying to compare apples and oranges if you say MTBF and CSECLCF are the same for such systems. One is clearly a reliability FOM of a single component, and the other is a probability of encountering a hazard.
> It follows that a claim, such as yours lower down, which I will not quote here, that CSECLCF and MTBF are different for these systems, is mistaken.
No, it is not mistaken. And if it were mistaken, the FAA would have never certified *any* autoland system. You clearly do not understand how these terms are used and how they are significantly different in both reliability and safety analyses.
> > [...]I would hazard to guess [.....] that there IS indeed quite a bit of operational service data to support a <10^-9 probability of catastrophic failure during autoland. I don't know quite what to make of this claim either. It seems flatly to contradict basic results in the field (Littlewood-Strigini, Butler-Finelli) of which I would have assumed you were aware.
I would ask you to make of this claim just what is says. It is a guess, based on my operational experience and exposure to monitoring the performance of these systems for FedEx. I am not aware of all studies and literature that may contradict my experienced-based guess, but I would be willing to check it out to see what they have to say. It may be pertinent, it may not. Your quoting of names, without citing their conclusions, is what I would call sophistry!
> > [Peter] I happen to agree with Charlie's sentiment that automatic landing systems on plane-fulls of people without human control looks like a significant risk, given current standards and practices. Not that I have done the required analyses, though.
That's fine, that is your opinion, and thank you for clarifying that you don't have supporting data.
> Well, that may be persuasive rhetoric, but it makes a poor argument.
It is not intended as an argument, but as a restatement of the fact that it is just as much a guess on your part as the guess I made above. It is the same argument used to support the Challenger launch in the face of the Thiokol engineers' concerns that the low temperatures expected during launch would not allow the amount of beyond-design distortion of the O-rings they had seen on some previous launches.
No, it's not the same argument. In the Challenger case, a defacto design already existed, and the data was unknown for that fixed design. For such a case, ethics would call for you to analyze the design (at least) or test the design (at best). In the case of a "Robolander" the design is not yet fixed, therefore, since it does not yet exist, a thorough analysis of its probability of exposure to hazards is unknown. They are very different cases.
> Similarly, although we know that maintenance snafus cannot be taken into account during a CSECLCF calculation, it helps to have an Air Transat incident to convince people that, despite all that clever engineering, single points of failure of thrust originating with the engines are still possible.
We "know" that maintenance snafus CANNOT be taken into account? I don't know that. I know that they are not at present, but I do not yet know that they cannot be taken into account in the future. That is an awfully big leap.
With all due respect, Peter, you are an awfully intelligent person, and you are very good at "after the fact" analysis.....but I would like to see what you would come up with as a designer, who is forced to produce, not just criticize. There is a "whole new world" out there that it is abundantly clear that you have not been exposed to. I'd say you need to be a little less arrogant about the things you are not that well-versed on. I will admit when I am wrong....will you?
Thanks for making that not too fine a distinction - and as usual you are quite correct. Not sure whether anyone is getting beyond the end of their noses with this one.
But it's a good stir anyway.... gets people thinking.
Sorta reminds me of the "get up and innovate" attitude that prevailed in the run-up to the Falklands War. If the West doesn't use technology wisely to defeat the terrorists, the fact is that each act of Western reprisal is likely to give birth to "n" times the number of enemy KIA in the form of new terrorist martyrs. That's just how this Middle Eastern equation is set up. So it's really a case of "thinking caps on lads, we lost the first round but ye shall have no more clean and easy kills."
You could do me a favour John and give me another day to get this concept cleaned up a little more and you could simply disseminate it (URL below) around all your Test Pilot Mates, Farnborough, MoD, CAA etc (even including the Aviation Press) and let people judge for themselves (i.e. no need to endorse, repudiate or source). Feel free to post appropriate comments (as per the observations below) ON pPRUNE.
I'm not going to bother with Bluecoat for the moment. They're discussing it but are presently far too busy with sophistry, MTBF and other similar inventions of the moment in an endeavour to prove that it's always the engineering MTBF and FEMA that is the prime determinant of social acceptability. Human Factors and the terrorist element have been "factored out" for the present.
what Boeing's spokesman John Dern said concerning a remote, auto landing
system in yesterday's Associated Press wire:
> This does not work for a number of reasons. However, one of the reasons, > that is applicable to this automated system which will take over and safely return the aircraft, is that such a system must work all the time.
And who's design requirement is this, that it must work all the time? Just as important as the functional capability it provides is the deterrent capability it engenders. If a hijacker knows the capability it "out there" and exists in most (if not all) jets he is thinking of using, then he is taking a big risk in failing his mission if he banks on the system being on the MEL.
The requirement that it must work at all times is not a given.
>First, it has to be installed and retrofitted on all aircraft, which is impossible and highly cost prohibitive.
Again, who says it has to be installed on ALL aircraft? Perhaps one of the mitigating factors if you DON'T have it installed on a particular aircraft is that you must now fly with at least 1 (pref. 2) skymarshals.
Same could be true if the system is on the MEL.
>Next, on those aircraft where it is installed, it has to work. It cannot be deferred. ...If any component or function does not work then the aircraft (or possibly all aircraft involved) cannot fly.
You are again assuming this as a design requirement which cannot be yielded in any situation, and I claim that is not true. You are also ignoring the deterrent benefit, as I mentioned above.
> Does anyone really think such a system will ever be built or installed in either commercial aircraft
It is more than just me "thinking" it will be done. I guarantee you that it will be done, as a minimum as a Proof Of Concept. Remember the NASA Propulsion-Controlled Airplane (which used an MD-11, BTW) which demonstrated a landing with NO hydraulic flight controls? Now even I would admit that such a thing is risky, yet it was shown that the design was viable.
While many on this list may be poo-pooing what I am talking about, I can tell you that I am talking with folks right now about the concepts, and they are pursuing go-forward funding for such a Proof Of Concept. As so many engineers have said "don't tell me I can't do something, because I will go out and prove you wrong."
Let's see if ATA is still around (and I am still on) in about 3-4 years time. Then let's revisit this discussion in the reality of that future. I think you might be surprised not only at what we accomplish, but where this technology goes.
Subject: [ATA] Re: Safety, Risk, Design & Certification
Now let's look at two possible worlds under this situation:
> World #1 - No "hijack-proof" technology exists on the airplane (what some are calling "Robolander"). The ONLY remaining option here is to shoot down the airplane, and sacrifice the souls on board to prevent greater loss of life elsewhere.
> World #2 - In this world the "Robolander" was developed, and it is one more option (one more weapon) to be used to thwart the murderous terrorists.
> Which of these two worlds would you rather craft for our future?
The second is tempting, except it also means any number of terrorists can work on getting access to the commands for the same function at no risk to themselves. It would require security at the avionics supplier comparable to that for nuke secrets.
Also in most FBW types, the FBW can be disabled by pulling breakers, leaving more than enough control authority to hit a building.
Charles Hamilton Sundstrand [ ffalke@@pweh.com ]
8-011-33-6-18-52-21-92 (portable in Toulouse)
"One test result is worth one thousand expert opinions" -- Wernher Von Braun 0 N4003M
"Imagination is more important than knowledge" -- Albert Einstein
====== ATA Mailing-list : ATA@@ATA.org ===================
[mailto:ATA-bounce@@ATA.org]On Behalf Of Todd M.
Sent: Wednesday, 3 October 2001 10:56 PM
Subject: [ATA] Re: Roboland
Ray - doing fine! Thanks for asking!
Re: Robolander...tens of millions = somewhere between 10M and too darned much. I'd say that $10M is basement price for retrofit, given the costs we've been developing on other systems. Look at the bright side - what a lever to revise the cert procedures! Level A++ software? DO 160Z for REAL bulletproof avionics..finally!
Timeline to implement? I'm guessing two years for RDTE and another three to five for mods to be completed on all aircraft - only 7500 aircraft or so...$75B from our more stable carriers should be down in the noise...
El AL (as qouted in the press) says about $15K to provide a door for the cockpit that will slow the Tangos down enough to make them seek easier targets. Even ten times that amount to beef up the entire bulkhead (where you'll spend lots of time getting to a place to land) is probably less than the final fixes (changes to control heads, breaker panels, wiring, etc.) necessary to prevent the transponder from being disabled.
KISS...tackle the basics (hire retired cops for passenger/baggage screening, take the cockpit keys away from the FAs, train/arm flight crews, and provide enough air marshals to keep everyone guessing); then we can talk about autoland, sleepy gas, and (my fav)...mind control.
> Todd wrote: (how's it going at MITRE these days?)
> > The issue is not whether this capability can be developed - it's been done already - but rather whether the tens of millions of dollars per aircraft that such a system would cost....
> Whoops! Gotta bring you (and your numbers) back to reality here, Todd. I think you are at least an order of magnitude too expensive in your guesstimate. I am quite sure that the modifications required to make an existing autoland aircraft capable of being "hijack-proofed" would be below even $10 million per copy. Especially if you were able to amortize the development Non-Recurring Engineering costs over a large number of airframes (like ALL of them).
>> Here is a good barometer for judging mod costs these days (and I need to be careful here so some folks don't get ticked-off at me for telling too much):
> A certain operator was able to purchase an entirely new (glass) cockpit for their older, analog airplanes. Said mod included most of the big "bells and whistles" (CAT III, FMS, GPS, etc.). The unit cost of such a mod has less than 7 zeros on the left side of the decimal. (And this cost was obviously not amortized over the worldwide fleet).
> That is all I will say.,
|with respect John surely you're describing
APALS (Autonomous Precision
Approach and Landing System as I recall) - the concept that the then-Martin
Marietta tried very hard to get accepted in the 1994-1998 timeframe. Part of
their strategy, evangelised by the omnipresent Otto Dieffenbach, was to win
what became the DoD's JPALS competition.
I don't follow the military side so much these days but I believe
APALS was a great idea - unfortunately the first 'A' wasn't quite
I have to agree. They are proposing a complex, expensive system with
new avionics and ATS infrastructure that could take at least
It is all based on a very debatable assumption, i.e. that the pilot won't reveal the passivation code if someone has a gun at his head and is about to pull the trigger. - I doubt if I would have the courage to refuse.
Also if the terrorists could grab the pilot before the plane was
locked out they would have 20 minutes to fly the aircraft
And surely there must always be some maintenance backdoor that bypasses
the passivation system. If they could find
On the other hand, it creates new opportunities for suicide attacks
e.g. suicide passenger issues threat. pilot locks out aircraft
I suggest that they have got too focused on a high-tech scheme. Why not do the obvious, i.e. what El Al do now?
- Lock the cockpit door
Low tech I grant you, but as effective as the high tech solution
in fact better as the terrorist cannot point the gun at the pilot's
Also being low tech we can do it right now, to all aircraft, and cheaply - although a bullet-proof door would be a desirable upgrade.
|J W wrote:
> FWIW, a number of years ago, I went to ABQ and flew a Gulfstream equipped with the JPALS system.
I think you are talking about "APALS" (Autonomous Precision Approach and Landing System). APALS does not use GPS or any other space or ground based navigation system, hence the "Autonomous". Everything you need is carried on-board the aircraft.
> As it was explained to me, the guts ofthe system, at that time, was taken from a Pershing missle.
The Pershing used a concept of "radar scene matching" which was enhanced considerably and incorporated into APALS as "Radar Pilotage".
Essentially a collection of radar scenes are produced, along and to the sides of the approach paths. These recorded or mapped scenes are then compared with real time scenes as the aircraft is flying the approach. The correlation of the scenes occurs just as a human would correlate the scene information on a sectional or wac to the view out the window. The difference is that the computer is dumb enough and fast enough to do extensive correlations and verifications that humans just wouldn't tolerate. The result is a very high degree of integrity (>1E-9) and position accuracies within 2 meters laterally and vertically with respect to the runway.
While there are no physical nav-aids used (APALS
likes, but doesn't require, something like GPS or INS or FMS best-estimate
to "kick-start" the APALS correlation), the basic APALS
system creates a complete set of "virtual" nav- aid signals
on-board the airplane, including LOC, GS, OM, IM, and LOM, so that
existing aircraft can utilize all of their avionics approach and land
capabilities. APALS is thus able to be fully used in an existing Cat
IIIb/c airplane as well as classics with very simple LOC / GS couplers
to a flight
In a follow-up posting Air transport Intelligence stated:
Technology wasn't the problem. Every model conducted of APALS integrity indicated that it substantially exceeds the requirement. These were made using assumptions that scene matching would fail in a hazardous way in 1-out- of-10 matches. In reality, APALS has had only one "raw" scene mis-match in its entire developmental history (including the very first flights) and has never had a scene mis-match failure propagate through any of its three layers of validation. The design requires at least three consecutive scene match "worst case" failures to bring the navigaton error outside Cat III requirements. Attempts to deliberately corrupt or sabatoge the scene database have all been detected. APALS can get lost (defined to be roughly 3 meters of error), but it always knows that it is lost and can alert the crew to go-around and use the alternate.
Stuart Law voice 979-567-6370