From: Michael Jackson Date: Mon Mar 11, 2002 11:54:37 AM US/Eastern To: Heinz Erzberger , tsafe Subject: Detecting Violations of Intent Reply-To: jacksonma@acm.org Dear Heinz, Since we talked on the telephone last November, I have been working further with Daniel, thinking about some aspects of TSAFE and participating in discussions with John Hansman, Tom Reynolds, Greg Dennis and others. One point you mention in your email of 7 March raises a question in my mind. My question is about detecting violation of intent. Is this done by comparing the actual behaviour of the aircraft with some 4D volume of non-violating behaviours? If so, how does this volume differ from the 4D volume used to calculate potential conflicts? Is it computed independently, or is it derived from the 4D volume for conflict by some systematic transformation such as peeling off an outer layer? Best regards, -- Michael Jackson jacksonma@acm.org http://dspace.dial.pipex.com/jacksonma/ ======================================================================== Heinz Erzberger wrote: Michael, In an ultimate design, long time-horizon conflict probing and short time-horizon conflict detection, such as in TSAFE, would be seamlessly integrated. But we don't know how to do this yet. So we break the problem apart. Form 0 to about 3 minutes or so, 4D trajectories based primarily on projecting the current velocity vector (dead reckoning) dominate. Beyond about 4 minutes, the 4D trajectories are based on flight plan intent, aircraft performance models and atmospheric models. One of the problems on my "to do" list is to come up with a unifying theory that avoids the arbitrariness of switching from one to the other at some particular time to go, as we are doing now. In our current operational software, the conflict search algorithm checks for separation at discrete times in ten second intervals, starting at the current positions of all pairs of aircraft and continuing for twenty minutes into the future. Between the discrete time instants, we may interpolate if necessary to accurately determine the minimum separations. In general, we want to check 4D trajectories and not 4D volumes, if I understand your use of the term correctly, in order to reduce the false alert rate. However, as I discussed in my paper, using an envelope of 4D trajectories ( perhaps that is what you refer to as 4D volumes) may be required for very short time horizons, say less than 2 minutes, in order not to miss a potential near term conflict. Here the tradeoff between false alerts and missed alerts will determine how large a 4D volume can be tolerated. As I mentioned in my previous email, even for short term conflict detection we have to modify the dead reckoning-based 4D trajectories by incorporating intent information, such as the planned leveling out altitude, in order to avoid false alerts. Thank you for your continuing interest in this problem. Perhaps, we should plan another telecon to help resolve other questions you and Daniel may have. Heinz P.S. My colleague Russ Paielli has gotten me to start reading your famous book on software specifications. I actually found it very interesting, even though I am not accustomed to studying software design texts. ======================================================================== From: Russ Paielli Date: Mon Mar 11, 2002 09:37:27 pm US/Eastern To: jacksonma@acm.org Cc: Heinz Erzberger , dnj@mit.edu Subject: Re: Detecting Violations of Intent Dear Prof. Michael Jackson, As Heinz mentioned, I had obtained a copy of your book "Software Requirements and Specifications" several months ago, before I even realized that you were Daniel's father and would be involved with TSAFE. I must say that I am very happy to have such world-class brainpower unleashed on our problem! I would like to add to what Heinz wrote and try to clarify the "big picture." My apologies if you already know some or all of what I am about to tell you. First, I would like to reiterate that TSAFE will have two major phases. In the first phase, TSAFE will be used as a tool to help controllers avoid "operational errors" (breaches of minimum required separation), but the controllers will still maintain primary responsibility for separation. We hope to be able to field test something on this within a couple of years. In the second phase, the goal is to actually relieve controllers of the responsibility for separation. Although that goal seems simple enough, it is actually a huge step, and it is considered a key to the automated airspace concept. My understanding is that your concern is mainly this second phase. For the first phase, we are simply adapting the existing CTAS conflict probe. The conflict-probe software (written in C) is getting rather large and messy, but we decided that we could "hit the ground running" by revising existing code rather than starting from scratch. We hope to supplant an existing mechanism called "Conflict Alert," which is written in Jovial in the FAA host computer at each Center. Conflict Alert basically performs a variation of dead reckoning for 3 minutes, and notifies the controller if a conflict is detected within that time. A large part of the challenge in phase 1 is due to sloppy piloting, lack of knowledge of pilot intent, and radar tracking error. A controller will often "vector" an airplane to avoid a conflict or a weather cell, but they do not normally amend the official flight plan, so CTAS has no way of knowing the intent. Also, "discretionary descents" allow pilots discretion as to when to actually start a descent so long as they cross the arrival meter fix at a specified altitude. Also, the radar tracking can be fairly inaccurate, particularly the velocity estimates, which are obviously critical for trajectory prediction. The automated airspace concept is projected for several years down the road, when ADS-B will provide position and velocity estimates based on GPS that are something like two orders of magnitude more accurate than those based on radar today. At the same time, decision support tools and datalink technology will automate the recording of almost all controller commands, so that intent will be unknown far less often than it is today. Also, the sloppy piloting should be reduced substantially by the increased use of FMS and also, possibly, stricter conformance rules. When you put all that together, the problem of detecting a deviation from an assigned trajectory becomes much more manageable. In the current system, however, you need all sorts of heuristics and it remains to be seen how aggressively we can detect potential conflicts without creating an unacceptable rate of false alerts. As Heinz said, we need a strategy in which we get more cautious or "paranoid" the closer the potential conflict gets. That same basic strategy will apply even in the future automated airspace scenario, but the parameters will be such that we will be able to detect problems much more reliably without creating a lot of false alerts. I personally think that trajectories need to eventually be specified and flown precisely. State-of-the-art FMSs can fly remarkably precise enroute tracks and descents, and I think that the automated airspace should take advantage of that capability. Whether the trajectory is assigned from the ground or proposed from the flight deck and approved on the ground, I think precisely prescribed trajectories can eventually do wonders for automated air traffic control. Heinz may have a different view on that, however. Regards, Russ Paielli ======================================================================== From: Michael Jackson Date: Tue Mar 12, 2002 12:37:05 pm US/Eastern To: Heinz Erzberger Cc: Rpaielli@mail.arc.nasa.gov, Daniel Jackson Subject: Re: Detecting Violations of Intent Reply-To: jacksonma@acm.org Dear Heinz, Many thanks for your very helpful reply. I am still unsure about one matter. Once intent -- for example, a planned levelling-out altitude -- has been incorporated into a 4D trajectory (or envelope of 4D trajectories) for purposes of detecting conflict, it is necessary to detect violation of that intent. Because some degree of deviation must be permissible (if only because position reporting by radar is not perfectly precise), it seems that violation can be thought of as moving outside some permitted envelope of non-violating trajctories. My question is about the calculation of this permitted envelope. It is obviously related in some ways to the envelope used for conflict detection, but is not identical to it. Am I right about this? Another telcon in the reasonably near future would be a very good idea. Best regards, -- Michael ======================================================================== From: Michael Jackson Date: Tue Mar 12, 2002 01:17:41 pm US/Eastern To: Russ Paielli Cc: Heinz Erzberger , dnj@mit.edu Subject: Re: Detecting Violations of Intent Reply-To: jacksonma@acm.org Dear Russ, ... Although I had already read some documents about TSAFE, including Heinz's paper "The Automated Airspace Concept", your overview of the project, and your insights into its goals, are very helpful. The ultimate goal of relieving controllers of responsibility for maintaining separation doesn't seem at all simple! It's certainly a goal that is intensely interesting from a software point of view; but the shorter-term goal of providing highly reliable conflict prediction with today's very imperfect technology is also interesting to us. At first sight it seemed to us that it might be essentially an algorithmic problem in which the primary concerns are purely computational rather than structural; but we now believe that there are also important structuring concerns. These structural concerns center around the relationships among the different ways of predicting aircaft movement -- dead reckoning, pure flight plan intent, and flight plan intent modified to accommodate pilot discretion -- and the different ways of detecting deviation from assumed pilot intent. You explain that to a great extent the fundamental problems must remain unsolved until better technology is available. But we are working on the assumption that, even so, the right problem and implementation structures can help to separate and clarify distinct aspects of the software and its specification, and so to make better use of both existing and future technologies. Regards, -- Michael Jackson ======================================================================== Heinz Erzberger wrote: Michael, I should have included in my last message that detection of violation of intent is indeed a key function of TSAFE. There are essentially two categories of intent violation. A benign violation is one that does not immediately result in a conflict. Most violations fall in this category. A critical violation is one that would immediately produce a conflict. That is the maneuver-critical condition I referred to previously. For example, the failure to level out at an assigned altitude when another aircraft is directly in the path of the violating aircraft's trajectory is a maneuver-critical violation. We are designing an algorithm that identifies all potential maneuver-critical violation and an algorithm for the rapid detection of the actual violation. Here the accuracy and observation rate of the tracking data will determine how quickly we can detect a violation of this kind. The parameters that define an intent violation will depend on the accuracy of the measured data and other factors. Heinz ======================================================================== From: Michael Jackson Date: Wed Mar 13, 2002 11:03:14 AM US/Eastern To: Heinz Erzberger Cc: Rpaielli@mail.arc.nasa.gov, tsafe Subject: Re: Detecting Violations of Intent Reply-To: jacksonma@acm.org Heinz, Thank you for your message. It's very helpful indeed. I hope I am not pestering you with too many amateurish enquiries, but I am still trying to understand a further issue. This is whether it is possible to separate out the following questions for one aircraft:- (1) Expectation: What is this aircraft currently expected to do in the near future? The weakest answer to this question is "it may do anything that is physically possible". The strongest answer is "it is expected to adhere to this flight plan with the greatest precision". (2) Potential conflict: If this aircraft does what it is currently expected to do, and that other aircraft also does what it is currently expected to do, can they breach separation in the near future? (3) Expectation failure: Is this aircraft doing anything now that violates its current expectation? If the violation is maneuver-critical then a conflict alert must be produced. But regardless of maneuver-criticality, the expectation must presumably be revised. I can imagine that these questions may not be separated in practice, and perhaps that they are not clearly separable even in principle. Also, if expectations are not stored over a number of successive cycles of conflict detection, but are recalculated afresh on each cycle on the basis of the aircraft's current position, heading etc, then perhaps question (3) has no meaning. -- Michael ======================================================================== From: Russ Paielli Date: Thu Mar 14, 2002 10:10:10 PM US/Eastern To: jacksonma@acm.org Cc: Heinz Erzberger , tsafe Subject: Re: Detecting Violations of Intent Michael Jackson wrote: > Heinz, > > Thank you for your message. It's very helpful indeed. > > I hope I am not pestering you with too many amateurish enquiries, > but I am still trying to understand a further issue. This is > whether it is possible to separate out the following questions > for one aircraft:- > Don't worry about asking "amateurish" questions. Sometimes they're the only kind I can answer! > > (1) Expectation: What is this aircraft currently expected to do > in the near future? The weakest answer to this question is "it > may do anything that is physically possible". The strongest > answer is "it is expected to adhere to this flight plan with the > greatest precision". > > (2) Potential conflict: If this aircraft does what it is > currently expected to do, and that other aircraft also does what > it is currently expected to do, can they breach separation in the > near future? > > (3) Expectation failure: Is this aircraft doing anything now that > violates its current expectation? If the violation is > maneuver-critical then a conflict alert must be produced. But > regardless of maneuver-criticality, the expectation must > presumably be revised. > > I can imagine that these questions may not be separated in > practice, and perhaps that they are not clearly separable even in > principle. Also, if expectations are not stored over a number of > successive cycles of conflict detection, but are recalculated > afresh on each cycle on the basis of the aircraft's current > position, heading etc, then perhaps question (3) has no meaning. I'm not sure exactly what you mean by "separating" these questions, but I'll take a shot at it. As I explained in my previous message, we can avoid a lot of confusion by first specifying whether we are discussing a near-term or a far-term ATM system. And even in a future ATM system 10 or 15 years from now, we need to distinguish between aircraft that are equipped for the automated airspace and those that are not. I suppose you can think of the current system as a special case of automated airspace in which none of the aircraft (nor the ground) is "equipped." As technology advances, more and more of the aircraft will be "equipped." For the sake of discussion, we can drop the time frame and simply talk in terms of equipped and unequipped aircraft. Also, just for background, Heinz likes to distinguish between what he calls "tactical" and "strategic" conflict resolution. Tactical conflict resolution is initiated within about 5-8 minutes of the predicted conflict, whereas strategic resolution is initiated anywhere from about 5 to 20 minutes out. Human controllers mostly address the tactical case, but decision support tools are in development to help them deal efficiently with the strategic case. TSAFE will address only the tactical case. Here's how I like to think TSAFE will eventually work for equipped aircraft. As Heinz said, it will essentially be an independent monitor of the CTAS conflict probe. CTAS generates trajectory predictions for the next 20 minutes or so and checks them for conflicts. The first 4 or 5 minutes of those trajectories will be sent to TSAFE. TSAFE will then independently verify that those trajectories are indeed free of conflicts. If it finds a conflict in the predicted trajectories, it will initiate a resolution advisory. If TSAFE finds that the predicted trajectories are free of conflicts, it's next job is then to monitor the conformance of each airplane to its assigned trajectory. If it detects non-conformance, it raises a flag. If the non-conformance is determined to lead into an immediate conflict, TSAFE will generate a resolution advisory for the controller and/or the pilot. So TSAFE will verify that all predicted or asigned trajectories are conflict free and that each aircraft conforms to its predicted or assigned trajectory. I use the terms "predicted" and "assigned" interchangably. In the automated airspace, they would be the same. The assigned trajectory is nominally specified in the flight plan, but it could be revised along the way, and the terminal segment will have to be determined in real time to coordinate with other traffic, of course. Trajectory assignment updates could come from the ground (CTAS itself, perhaps) via datalink, or in "free flight" it could be requested by the pilot and approved on the ground, also via datalink. In addition to detecting trajectory non-conformance, another function of TSAFE could be to try to anticipate non-conformance at critical times. For example, if an climbing airplane is scheduled to level off at a particular altitude within a minute or so, and failure to do so could cause an immediate conflict, a warning could be automatically sent to the pilot to remind him to level off at the correct altitude. For "equipped" airplanes, the determination of non-conformance will be much easier than for non-equipped, of course. Non-equipped airplanes suffer from all those problems I mentioned in my previous message: lack of intent information, sloppy piloting, and radar tracking error and low update rates (once per 12 seconds). That's where your questions above come into play (no I haven't forgot about them!). That's where things get messy and you have to play guessing games. Heinz thrives on that sort of thing, but it's really more of a black art than a science. As an example, consider an airplane that is flying level but heading 30 to the left of where it should be heading. Well, you really have no choice but to try to guess what it will do next. So you basically need to check for all possible conflicts assuming that it will either (1) continue turning by some additional angle (unless it has clearly stopped turning), (2) continue to fly straight ahead ("dead-reckoning"), or (3) start turning back to its assigned heading. Don't forget, of course, that separation of non-equipped aircraft will remain the responsibility of human controllers. I hope that helps. Please don't hesitate to let me know if anything is unclear. Regards, Russ Paielli