From: Daniel Jackson Date: Wed Mar 06, 2002 12:27:51 PM US/Eastern To: tsafe@geyer.lcs.mit.edu Cc: Ilya Shlyakhter , Michael Jackson Subject: thoughts about TSAFE dear all, following yesterday's lunchtime meeting and an afternoon discussion with martin and butler lampson, i've tentatively come to these conclusions. 1. the aspects of TSAFE that john hansman and his group work on are probably beyond what we can currently handle. the value we bring to TSAFE, however, is mainly in showing how to make a device like TSAFE that is dependable. that means having a very small TCB (trusted computing base), and using new techniques to establish its conformance to the specification. we should continue on our plan to build a sample TSAFE and develop these techniques using algorithms that are much simpler than those that tom is developing. and we should certainly keep a separation from the nominal trajectory computations that CTAS does (and which rely on weather, aircraft type, standard operating procedures and other complex things). at a later point, we can consider extending our TSAFE to incorporate these notions, but even demonstrating a small and dependable TSAFE for limited notions of intent and prediction would be a major step forward (from a software engineering if not aero/astro perspective). 2. so our plan should be: -- develop a precise and complete requirements document for the simplified TSAFE (daniel and michael); -- complete the initial TSAFE prototype, with flight plan parsing, and simple conflict detection based on dead reckoning (cristian, tudor and greg). display should show aircraft positions and headings, FPs, dead reckoning trajectories, conflict points, all imposed on map of US; -- try this out for ETMS, in an extended time horizon, and see if it's plausible: are detected conflicts resolved? -- revisit the prototype and do a careful design using alloy; -- refactor the prototype as necessary to conform to the new design; -- check conformance using our code analysis techniques. michael and i have spent the morning thinking about the simplified requirements. here are our current thoughts. comments on the parts starred are very welcome (esp from tom and john). a. use the flight plan as the conformance basis. no nominal trajectory computation; just check heading and position against the FP directly. b. ignore vertical intent, but use altitude in computing conflicts. ***is this right? if a plane is climbing, what altitude do we use in its projected behaviour? c. the outcome of the conformance test is boolean: either conforming or not. ignore differing degrees of deviation. d. if not conforming, using dead reckoning AND the FP as predictors of future behaviour. if conforming, just use FP. use 4D volume approach (flying hockey puck getting fatter over time). ignore weather and ac type. ignore inferring more complex intents (such as intent to rejoin flight plan). ***two tricky issues came up that we're not sure about. first, perhaps in the short term something more conservative than dead reckoning should be used: the volume might actually be fatter initially, to account for the greater risks associated with prediction errors in the short term. this is in a sense an unimportant issue, since the tool will presumably allow different volume generators to be inserted easily. ***second, what guarantee exactly does TSAFE make. consider these two: (i) warns of conflicts that are likely in the next 3 mins (ii) warns of likely conflicts in the future; always gives 3 mins warning at least. (ii) seems more appealing, but it's probably unattainable. it's quite possible that in some step we predict a conflict 4 minutes away for 2 a/c, and in the next step (10 seconds later), we predict a conflict 2 minutes away. is this just a risk that's there in ATC anyway? after all, separation alone doesn't offer these guarantees: 1000 feet of vertical separation and a climb rate of 3500 feet/minute can result in conflict in less than 10 seconds! /daniel ======================================================================== From: Tom Reynolds Date: Thu Mar 07, 2002 01:14:50 PM US/Eastern To: Daniel Jackson Cc: tsafe@geyer.lcs.mit.edu, jacksonma@acm.org, ilya_shl@MIT.EDU Subject: Re: thoughts about TSAFE Daniel My comments on requested parts below: > >a. use the flight plan as the conformance basis. no nominal trajectory >computation; just check heading and position against the FP directly. Sounds like a good idea. > >b. ignore vertical intent, but use altitude in computing conflicts. >***is this right? if a plane is climbing, what altitude do we use in its >projected behaviour? If you really want to simplify the situation, you could just look at the horizontal siutation and filter out all aircraft in ETMS that are not at (or going to be at) a given altitude over TSAFE's lookahead time. If this makes it too unrealistic, the assigned altitude is nominally available from ETMS Flight Plan (FZ) message, which could be used as a simple basis for vertical intent if you didn't want to ignore it altogether. However, controllers don't always enter the assigned altitude into the system so it may not be reliable. In terms of projecting vertical behavior, I think there are two main options to consider initially: i. use a dead-reckoning vertical speed (e.g. based on observed altitude changes reported in previous 2 or 3 ETMS update (TZ) messages)--hence need for historical data ii. consider that simple vertical intent will be followed (e.g. climb and level off at assigned altitude). As we discussed, there are many other possible trajectories that could be followed, but in this inital study these two seem most sensible. > >c. the outcome of the conformance test is boolean: either conforming or >not. ignore differing degrees of deviation. I agree. >d. if not conforming, using dead reckoning AND the FP as predictors of >future behaviour. if conforming, just use FP. use 4D volume approach >(flying hockey puck getting fatter over time). ignore weather and ac >type. ignore inferring more complex intents (such as intent to rejoin >flight plan). > >***two tricky issues came up that we're not sure about. first, perhaps >in the short term something more conservative than dead reckoning should >be used: the volume might actually be fatter initially, to account for >the greater risks associated with prediction errors in the short term. >this is in a sense an unimportant issue, since the tool will presumably >allow different volume generators to be inserted easily. Do you consider TSAFE's few-minute lookahead time short-term? Or were you thinking of using a different conflict detection strategy in, say, the first minute versus later times? If by 'more conservative than dead reckoning' you mean you also want to consider other possible trajectories in the time frame of interest, there are a number of different approaches. Proababilistic approaches which assign higher probability to dead-reckoning and/or intent trajectories but non-zero probabilities to other 'possible' trajectories is one way to go. Another approach uses a 'worst case' approach where a uniform pdf of trajectories within a zone of airspace that the aircraft could feasible get to within the time frame of interest is also possible. Another involves Monte Carlo simulation. All of these approaches may get rather complex...I suggest the simpler the better at this stage, i.e. just use the FP and dead-reckoning trajectories (consistent with the vertical discussion above). > >***second, what guarantee exactly does TSAFE make. consider these two: >(i) warns of conflicts that are likely in the next 3 mins >(ii) warns of likely conflicts in the future; always gives 3 mins >warning at least. > >(ii) seems more appealing, but it's probably unattainable. it's quite >possible that in some step we predict a conflict 4 minutes away for 2 >a/c, and in the next step (10 seconds later), we predict a conflict 2 >minutes away. is this just a risk that's there in ATC anyway? after all, >separation alone doesn't offer these guarantees: 1000 feet of vertical >separation and a climb rate of 3500 feet/minute can result in conflict >in less than 10 seconds! This is something we have been struggling with when trying to define the role of separation standards. My take is that if everyone follows intent, TSAFE should do ii). If aircraft deviate from intent, you hope it does i)! Regards Tom ======================================================================== From: Daniel Jackson Date: Thu Mar 07, 2002 01:31:01 PM US/Eastern To: Tom Reynolds Cc: tsafe@geyer.lcs.mit.edu Subject: Re: thoughts about TSAFE on Thursday, March 7, 2002, at 01:14 pm, Tom Reynolds wrote: > > Daniel > > My comments on requested parts below: > >> >> a. use the flight plan as the conformance basis. no nominal trajectory >> computation; just check heading and position against the FP directly. > > Sounds like a good idea. > >> >> b. ignore vertical intent, but use altitude in computing conflicts. >> ***is this right? if a plane is climbing, what altitude do we use in >> its >> projected behaviour? > > If you really want to simplify the situation, you could just look at the > horizontal siutation and filter out all aircraft in ETMS that are not at > (or going to be at) a given altitude over TSAFE's lookahead time. you mean by looking at what altitudes are physically possible? > > If this makes it too unrealistic, the assigned altitude is nominally > available from ETMS Flight Plan (FZ) message, which could be used as a > simple basis for vertical intent if you didn't want to ignore it > altogether. However, controllers don't always enter the assigned > altitude > into the system so it may not be reliable. > > In terms of projecting vertical behavior, I think there are two main > options to consider initially: > > i. use a dead-reckoning vertical speed (e.g. based on observed altitude > changes reported in previous 2 or 3 ETMS update (TZ) messages)--hence > need > for historical data by vertical speed you mean just climb rate? > > ii. consider that simple vertical intent will be followed (e.g. climb > and > level off at assigned altitude). but you don't know where the level off happens, right? > > As we discussed, there are many other possible trajectories that could > be > followed, but in this inital study these two seem most sensible. > >> >> c. the outcome of the conformance test is boolean: either conforming or >> not. ignore differing degrees of deviation. > > I agree. > >> d. if not conforming, using dead reckoning AND the FP as predictors of >> future behaviour. if conforming, just use FP. use 4D volume approach >> (flying hockey puck getting fatter over time). ignore weather and ac >> type. ignore inferring more complex intents (such as intent to rejoin >> flight plan). >> >> ***two tricky issues came up that we're not sure about. first, perhaps >> in the short term something more conservative than dead reckoning >> should >> be used: the volume might actually be fatter initially, to account for >> the greater risks associated with prediction errors in the short term. >> this is in a sense an unimportant issue, since the tool will presumably >> allow different volume generators to be inserted easily. > > Do you consider TSAFE's few-minute lookahead time short-term? Or were > you > thinking of using a different conflict detection strategy in, say, the > first minute versus later times? no, we were thinking of just using one strategy and testing it over the longer term just as a very crude plausibility check. > > If by 'more conservative than dead reckoning' you mean you also want to > consider other possible trajectories in the time frame of interest, > there > are a number of different approaches. Proababilistic approaches which > assign higher probability to dead-reckoning and/or intent trajectories > but > non-zero probabilities to other 'possible' trajectories is one way to > go. > Another approach uses a 'worst case' approach where a uniform pdf of > trajectories within a zone of airspace that the aircraft could feasible > get > to within the time frame of interest is also possible. Another involves > Monte Carlo simulation. that sounds reasonable. the worst case approach does sound much more readily implementable than an approach that involves a probability field. > > All of these approaches may get rather complex...I suggest the simpler > the > better at this stage, i.e. just use the FP and dead-reckoning > trajectories > (consistent with the vertical discussion above). > >> >> ***second, what guarantee exactly does TSAFE make. consider these two: >> (i) warns of conflicts that are likely in the next 3 mins >> (ii) warns of likely conflicts in the future; always gives 3 mins >> warning at least. >> >> (ii) seems more appealing, but it's probably unattainable. it's quite >> possible that in some step we predict a conflict 4 minutes away for 2 >> a/c, and in the next step (10 seconds later), we predict a conflict 2 >> minutes away. is this just a risk that's there in ATC anyway? after >> all, >> separation alone doesn't offer these guarantees: 1000 feet of vertical >> separation and a climb rate of 3500 feet/minute can result in conflict >> in less than 10 seconds! > > This is something we have been struggling with when trying to define the > role of separation standards. My take is that if everyone follows > intent, > TSAFE should do ii). If aircraft deviate from intent, you hope it does > i)! not sure our point was clear. (ii) is the hard case to implement; we don't think it's possible (without too many false alarms). (i) is the easy one, but gives no useful guarantees of bounded time to conflict. /daniel & michael