DISCUSSING ROBOLANDER (ATA Forum)

PAGE  2 of 2

[mailto: 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?

Rainman

Non ATA

JF

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.
 
John  S
-----Original Message-----
From: Johnffarley@aol.com [mailto:Johnffarley@aol.com]
Sent: Wednesday, 3 October 2001 6:59 PM
To: safety@iasa-intl.com; sampson@iinet.net.au
Subject: Pilot not needed for RoboLander

John S

Reading some of the comments from those who see the RoboLander concept as  " not on "  (for their various reasons) I am left with the feeling that many do not understand the world of UAVs

UAVs come in many types and the earliest were REMOTELY PILOTED vehicles. This is not what you are on about. The latest UAVs are autonomous and do not need to be PILOTED. (as I know you appreciate) They may, indeed most do, require to be commanded to do something, but only in the sense that humans are in charge of them. But being in charge of them in no way involves any need to PILOT them. That piloting function is built into the airborne or ground-borne operating system. Just as it is with autoland modes.

Perhaps these systems will not need to be certificated in the full and normal sense of that word (like auto-lands are)  -  after all they are only going to be invoked when all is lost and death for all on board is a given anyway. I would be happy to accept any lifeline in those circumstances and would not say "Don't throw me that lifeline unless you can guarantee it will save me"

John Farley
Here's what Boeing's spokesman John Dern said concerning a remote, auto landing system in yesterday's Associated Press wire:

"the company is waiting to hear from the task forces (what task forces?)

assembled by Mineta before trying to integrate such technology into

commercial airliners." And, "Translating that into the commercial world and

certifying such a system would pose big challenges," he said. "For safety

and reliability and redundancy, we'd certainly want to be sure that anything

we do enhances safety".

 

Benny wrote:

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

Rainman

Subject: [ATA] Re: Safety, Risk, Design & Certification

Chris wrote:

> The human pilot is a system that is very different from the ones that we are discussing here.

True. Indeed, the concept of MTBF, as strictly defined and applied in systems reliability, is not compatible with the human...for with the human, all internal states are not visible nor testable to confirm failure.

> MTBF is very, very long - how many times do you hear of a pilot being totally incapacitated?

Again, I have to be a purist for definitions here. The above is, essentially, the same error that Peter Ladkin is making. If we were trying to classify the MTBF of a pilot as we do for system equipment, then ANY failure he/she makes would be counted against his/her MTBF, not simply those that lead to incapacitation. An example would be a "fat finger" of punching in the wrong Loc frequency for the approach. If you entered the freq wrong (even if it did not result in hull loss) that would be counted as a "functional failure" of the pilot, and included in the MTBF. Thus, the MTBF of a pilot (if you could view and test internal thought states) would be quite low indeed.

Mean Time Between Failure =/= (is not equal to) the Mean Time Between Catastrophic Failure. One implies any failure, independent of the system's result. The other is dependent only upon the system as a whole, not one component thereof. (The pilot is part of the entire airplane system)

Gary had the right idea about MTBF when he said:

>Hi Reid ...I know of no instance (historical database) where human operational error is quantified as an MTBF Mean Time Between Failure... This mil-std acronym is primarily used for induced and inherent failure of parts and systems...

Just Rainman, being the purist! :-)

R

I have no argument that it is technically feasible to make this RoboLander autoland/remote control system work. (I flew an A-4 in 1969 that was controlled from a ground station. We never used the system operationally.)

However, please try to understand the fiscal realities of developing and integrating such a system into the existing and future fleet of the commercial airlines, which are trying to make a profit from carriage of passengers and cargo, not demonstration of technology.

As a developer/manufacturer you must go to the airlines and tell them that you can make all of their aircraft autoland/remote control capable, so that in the event of a hijack, with someone in the cockpit, who is capable of flying, someone in the FAA/Homeland Defense arena can take over the aircraft and keep it from crashing into a nationally prominent building (or anyplace else).

Then the airline must agree that they will spend X Dollars times the number of aircraft in their fleet to make sure that no hijacker is able to fly one of their aircraft into a nationally prominent building. This produces no revenue for the company. However, it is so important that the FAA has mandated that it be developed and installed on at least a significant percentage of the fleet.

The airlines will say that it is too expensive and difficult for them to put on their aircraft and since it is a federal mandate to protect nationally prominent buildings, the federal government must pay for it. Let's continue with the fantasy just a bit further. Let's say that Congress and the taxpayers say that it is so important that commercial airliners never again fly into nationally prominent buildings that they agree to fund the development and installation of the system. (We still have all of those other nation airplanes out there that may not have the same mandate, but let's not worry about that trivial issue for the moment.)

The FAA administrator is a political appointee. The Master Mechanical Equipment Lists (MMEL) are developed and maintained by the FAA.

Do you really think that this system that has been mandated by the FAA and funded specifically by Congress to prevent commercial aircraft from flying into nationally prominent buildings could be deferred for maintenance for the convenience of the carrier?

Such an autoland/remote control system would require at least an equivalent capability that would be required for every commercial aircraft to have CAT III capability. (I suspect that the complexity of actually making such a system work is exponentially more difficult.) Why is CAT III capability deferrable? Because it is impossible for the airlines to maintain all of their aircraft to CAT III capability all of the time. To do so would be financially crippling and impractical and possibly impossible from a logistical standpoint.

It is great to dream of all the things we could possibly do. However, why don't we focus on doing the things that will have some positive effect?

Benny W

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

> Rainman

Ray,

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 ]

FADEC specialist

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

Ray,

You seem to have accepted my main point:

Yes, what you call CSECLCF does not take into account maintenance.

from which it follows that the numbers game you were advocating is not an infallible guide to failure rates, and that your claims of certifying systems to failure rates of one in a billion hours are misleading.

Given that, I'm not sure what more I can usefully contribute, other than to correct some misunderstandings. I claimed that MTBF and CSECLCF were the same for systems, such as flight control systems, for which any failure of function is potentially catastrophic. You say I am wrong. Well, there are two things here that you could be denying. First, you could be denying that MTBF and CSECLCF are the same for systems for which any failure of function is potentially catastrophic. Second, you could be denying that DFCS's are such systems. Concerning the first, I can't figure out from your note whether you wish to deny it. One coherent way to do so is to deny that the mean time to an event can ever be determined when dealing with events of the rarity of one in a billion hours. Such a response could be plausible based upon a frequentist interpretation, but I don't know that it could be substantiated for a Laplacian or a Bayesian interpretation.

However, the frequentist is also unable, for exactly the same reasons, to determine CSECLCF in these circumstances. So I don't see any argument yet for denying the first claim in circumstances in which either term has meaning.

Concerning the second, you do indeed deny that DFCS's are such systems.

DFCS's are teleological systems; they have functional requirements to which they are supposed to conform. In addition, there are usually design requirements: e.g., you want it colored red, you want it striped orange and black, you want a plate attached specifying the type of thing it is, its part number and its serial number, and (your example)

One totally non-essential (to safe flight) design feature is its ability to interact with a maintenance CDU.

Now, when I said:

We were talking about systems whose failure to perform *any* required function is potentially catastrophic I assumed that my use of the word "function" sufficed to indicate that I was talking about failure to conform to functional requirements. However, you want to interpret the word "failure" in MTBF to include any non-conformance to any requirement, including design requirements (otherwise your example would not be a counterexample to my assertion).

This misunderstanding is partly a consequence of the deplorable state of engineering terminology in this area. My interpretation is supported by IEC 61508-4, IEC 50-191, IEC 902, ISO 2382-14, IEEE Std-500, IEEE Std-610.12, IEEE Std-982.1, IEEE Std-729 BS 4778-3.2, and by the IFIP WG 10.4 definitions of dependability as well as by texts in software safety engineering, amongst others. Yours is supported by NATO ARMP-7, MIL-Std-109C, MIL-Std-721C, amongst others. There are also those standards, such as UK MoD Def Stans 00-55, 00-56 and 00-58, as well as DO178B, in which it is not clear which is meant.

In any case, I hope it is now both clear what I meant, and clear that your putative counterexample to my claim, that DFCS's are systems for which any failure of function is potentially catastrophic, falls through.

So I don't see that you have provided any argument yet for your claim that I am wrong.

On to other matters: [...] 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."

My view is that terminology is used in different parts of safety-critical systems industries in mutually inconsistent, and sometimes incoherent ways, as I hope my list above of standards citing different definitions of the basic concept of failure might show.

The concept of mean time between failure has a couple of ambiguities.

One is what "mean" means. As I pointed out, a frequentist would likely deny that this notion has any practical use when one is talking about events with a frequency of one in a billion hours, but a Bayesian or Laplacian could nonetheless give it meaning. Another ambiguity is what "failure" means, and I have dealt with that above.

So now the only issue to be decided in what I might mean by MTBF is whether I would use a Laplacian, Bayesian, or frequentist interpretion of the concept of "mean". I can't understand, though, why you would want to tell me I can't use this expression. Would you let me use its German translation instead?

You also suggested that one may collect operational data to support claims of reliability of one in a billion hours. Robert Dorsett pointed out first that you were likely to get into trouble with such a claim.

I pointed out more specifically that this assertion contradicted basic results in the field of system reliability. Nevertheless, you seem to want to continue to assert it. I cannot see that that position is in any way coherent.

PBLadkun

-----Original Message-----

From: ATA-bounce@@ATA.org

[mailto:ATA-bounce@@ATA.org]On Behalf Of Todd M.

Sent: Wednesday, 3 October 2001 10:56 PM

To: ATA@@ATA.org

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

Rainman wrote:

>

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

> Rainman

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 JPALS is
now pretty much a variant of 'conventional' DGPS-guided precision
approaches, more or less like the FAA's LAAS. That is why Raytheon had to do
the demo - to show that their DGPS ground station for JPALS is essentially
the same thing as they would use in their offering for LAAS, also up for
grabs.

APALS was a great idea - unfortunately the first 'A' wasn't quite as
'autonomous' as hoped to hit the ten to the minus whatever that was
required.
Air Transport Intelligence

-----Original Message-----
From: john
Sent: 03 October 2001 21:54
To:
Subject: Re: Hope for secure GPS?


FWIW, a number of years ago, I went to ABQ and flew a Gulfstream equipped
with the JPALS system. As it was explained to me, the guts of the system, at
that time, was taken from a Pershing missle. The missle had a "picture" of
the target and it had a fast scan radar. It knew certain points from its
navigation system. It then overlaid the picture with what it saw and kept
modifying its flight until the two pictures were the same. The Pershing did
all this at about Mach Much... <G>

The idea of the JPALS was to take a runway anywhere, get the nav points, get
a picture (via satellite or other sources) and data link the info to an
airplane. It could be encrypted, obviously. This way Bongo 51 could be
dispatched to a runway in the middle of the night, shoot a precision
approach to a runway with NO navaids. This would allow the planners and
fliers to go into a runway, disperse personnel, leave immediately and then
rendezvous again at another airfield, again with no ground nav aids. As the
system was completely contained within the airplane, there was nothing to
alert anyone on the ground as to the arrival or departure.

I thought of JPALS when the forces went into Bosnia and had to have forces
survey the field, install the system, fly and certify it and then publish
it.. JPALS avoids all this and after flying about 10 approaches, mixing the
ILS with JPALS info, it was hard to define which was which.

Wiley
----- Original Message -----
From:
To:
Sent: Wednesday, October 03, 2001 1:53 PM
Subject: Hope for secure GPS?


> News clip!
>
> Civil aircraft makes first approach using military GPS, Raytheon says
>
> The first precision approach by a civil aircraft using a military GPS
> landing system occurred Aug. 25 at Holloman AFB, N.M., Raytheon
> announced Oct. 1. A FedEx Express 727 equipped with a
> Rockwell-Collins multi-mode receiver landed using a
> Raytheon-developed military ground station, Aerospace Daily affiliate
> Aviation Daily reported.
>
> Raytheon designed and developed the differential GPS ground station
> under an Air Force contract for the Joint Precision Approach and
> Landings System (JPALS) program. The JPALS program is being developed
> to meet the Department of Defense's need for an anti-jam, secure,
> all-weather Category 2 and 3 aircraft landing system that is to be
> interoperable with planned civil systems using the same technology.
>
> The 727 successfully conducted 16 Category 1 approaches guided by
> differential GPS corrections, integrity information and precision
> approach path points transmitted from the Raytheon-developed JPALS
> ground station.
> The company said that while the approaches were restricted to
> Category 1, "accuracies sufficient to meet Cat 2/3 requirements were
> observed."

> The world is going insane (from the Bluecoat list). Totally completely whacko ka ka nutso:
>
> > Anyone interested in the original 12 Sep 01 RoboLander Concept can find it
> > via the menu at:
> >
> > http://www.iasa.com.au/folders/RoboLander_files/RoboLander.htm which will take you (via the first menu)

I have to agree. They are proposing a complex, expensive system with new avionics and ATS infrastructure that could take at least
a decade and billions of pounds to implement, only applies to some aircraft and probably won't work anyway.

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
- plenty of time to mount an attack in say 100 mile radius
- the WTC for instance.

And surely there must always be some maintenance backdoor that bypasses the passivation system. If they could find
out how to do that - again it is no use.

On the other hand, it creates new opportunities for suicide attacks e.g. suicide passenger issues threat. pilot locks out aircraft
terrorist on ground jams GPS and or ATS control frequencies - quite dangerous if the aircraft is close to landing

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
head (he could point the gun at someone else's head in the passenger cabin but this is easier to resist).

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.

Peter B

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.


The system has no need for straight-in approaches as it can use this navigation scheme from an upwind intial approach through the course reversal and a 3-D curved final approach, still achieving the same high degree of accuracy with respect to the runway.


> The idea of the JPALS was to take a runway anywhere, get the nav> points, get a picture (via satellite or other sources) and data linkthe info to an airplane.


The APALS military use is expected (not yet demonstrated) to use photo and/or radar intelligence to create the radar scenes (remember, none of them are located at the landing area, but along and to the side of the path to the landing area). These can then be used to provide an out-of-the-blue precision guidance to the landing area. A screw-up in the intelligence or processing errs on the side of safety since the "expected" scenes won't match up with the actual scenes obtained during the approach and the system annunciates that it is lost.


In civil use each airport area is explicitly surveyed with photo, radar, and ground truth which are combined to create the scenes. These are served up on a database much as your current FMS databases. One difference is that APALS is constantly testing its database against the real objects making up each scene on the ground. We download the results of those tests with each
database "exchange" and process them on the ground to maintain a constant validation of our database integrity.


The system has been validated in desert, metropolitan, wooded, snow/ice conditions. It doesn't work well at places like Johnston Island where there is nothing but water along and to the sides of the entire approach and landing area. Over water approaches to land areas generally work fine, just with a lower initial accuracy.


> This wayBongo 51 could be dispatched to a runway in the middle of the night and shoot a precision approach to a runway with NO navaids.

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
director / autopilot. This allows the addition of APALS to provide Cat I approaches on a Cat III quality "beam" at any runway, dependent only on satisfying the TERPs requirements for obstruction and terrain clearance. There are no requirements for "sterile" airport areas or extended holdback lines.


Since APALS knows where the airplane is with respect to the runway very accurately, it is easy to provide this data to HUD/HDD systems to create a virtual runway and approach environment that replaces the current runway and approach lighting. With this data and complemented with APALS high integrity, full zero/zero approaches to any runway are in the forseeable future. This can be a coupled approach on Cat III capable aircraft or a manually flown approach with HUD and maybe HDD (head down displays).


This would
> allow the planners and fliers to go into a runway, disperse personnel, leave immediately and then rendezvous again at another airfield, again with no ground nav aids.


In the military environment it doesn't even have to be an airfield. Any area capable of supporting the airplane can be used. APALS provides a complete ILS environment with any desired glideslope angle as well as all the situational awareness (via HUD/HDD) for manually flown flight-path-vector landings.


> As the system was completely contained within the airplane, there was nothing to alert anyone on the ground as to the arrival or departure. That includes detection of its radar signature.
>
> I thought of JPALS when the forces went into Bosnia and had to have forces survey the field, install the system, fly and certify it and then publish it. The current JPALS is a GPS based system and does not use APALS technology. Hopefully that will change.


JPALS avoids all this and after flying about 10 approaches, mixing the ILS with JPALS info, it was hard to define which was which.

In a follow-up posting Air transport Intelligence stated:


> APALS was a great idea - unfortunately the first 'A' wasn't quite as 'autonomous' as hoped to hit the ten to the minus whatever that was required.

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.


Winged Systems Corporation has purchased APALS and is continuing its development. The web site is set to be a lot fancier "real-soon-now" (probably a couple of weeks), but John's letter offered a nice opportunity to re-start APALS's public life. And what better forum than Bluecoat!


Stuart

Stuart Law voice 979-567-6370
Winged Systems Corp. fax 979-567-7439
1600 American Way stuart@wingsys.com
Caldwell, Texas 77836 www.wingsys.com