Theory of the Maneuver Space

Motivation for developing the theory

It is inherently hard to keep aircraft properly separated using conventional technology. This is one reason why the average U.S. air traffic controller currently makes about $170,000 a year.

At the root of the problem is the old-fashioned, veridical display of traffic information. Veridical displays are based on a representation of physical reality. They are maps. And the root problem (in our opinion) is that maps are not necessarily the best way to approach aircraft conflict resolution because they require the user to solve both the conflict detection and the conflict solution problems, both of which are hard problems.

Naturally, there have been serious attempts to solve conflict detection and resolution with technology. Right now, the world's best veridical CDTIs are arguably the NASA Ames displays (shown at left). They certainly are a standard by which all other cutting-edge systems are judged. These calculate a resolution cone for lateral maneuver. Currently, there is even a 3D veridical version.

Nonetheless, while maps are the standard approach, research data indicate they have trouble optimally representing the full range of maneuver solutions across heading, speed, and altitude. You can get a good lateral OR a vertical maneuver, but it is still extremely hard to get a combination maneuver in manual selection mode.

 

 

My own first attempt at a map display also centered around solving the conflict detection problem. Given the cylindrical geometry of the en-route protected zone ( 5 nm radius, 1000 ft vertical half-height), I wrote a conflict probe to determine if and when one aircraft would enter another's protected zone. This time-to-separation loss was used to color-code the aircraft icons on a map display. The screenshot at left is a 40%-scale view of the actual display we tested with commercial airline pilots. It gave the pilot a way to (1) identify problem aircraft and (2) know how much time there was to resolve the conflict.

While this did solve the conflict detection problem, our research discovered that conflict resolution was the tougher problem to solve. Even when you know which aircraft are threats, you still have to select a maneuver that will solve the conflict. That is the hard part, especially when the intended resolution is either in the lateral (x-y) plane, or involves multiple aircraft.

Several individuals and teams have proposed elegant mathematical algorithms for automatic conflict resolution (the super-autopilot). However, we still feel that strong psychological and political considerations point to having manual conflict-resolution capability--now, and from now on. Pilots want to fly, controllers want to control, and passengers feel comfortable having a pilot onboard. The concept of hurtling through the air in a completely computer-controlled vehicle--while appealing to engineers--is one we feel the public will only accept as a backup system to human guidance.

So, while we know other developers are going to argue vehemently against our position, the issue will be settled in the marketplace. Meanwhile, the job of MST is to explore what we feel is viable technology, and to accurately report on the results.

The problem is the representation

In our opinion, the basic problem with veridical displays is the actual information representation they are based upon, namely physical, geographic reality. As it turns out, while this is the best way to describe the static world, it is not necessarily the best way to describe the dynamic world. This is particularly true when trying to calculate trajectory solutions for multiple objects moving at different speeds, altitudes, and headings.

The need for a new kind of information representation is what motivates the theory of the maneuver space.

To the rest of the world (especially the military), "maneuver space" is defined as the amount of physical space, within which an object can maneuver, given a certain amount of time.

However, it is also possible to define maneuver space as being a conceptual space, namely a space of possible aircraft maneuvers, given a predetermined time period.

The key to this new representation lies in the way we define the word "maneuver." In the simplest sense, any given aircraft maneuver can be defined as one unique setting of the aircraft autopilot. This unique setting consists of 3 numbers, one for heading, one for altitude, one for speed. This defines stable flight (disregarding change from one setting to another, i.e. the actual time it takes to execute a given maneuver--we will discuss that issue presently).

Defined this way, it is possible to construct a 3D volume--a conceptual state space--determined by 3 coordinate axes of heading, altitude, and speed. Individual aircraft maneuvers can then be defined as unique points within that space.

 

Next, it is possible to parse this space into two basic regions--safe maneuvers versus unsafe maneuvers.

Standard mathematical algorithms (the conflict probe--see Footnote) can determine which H,S,A triplets are problematic, as well as the time when separation loss will both occur and end. Any problematic maneuvers can then be color-coded according to time-to-conflict (available maneuver time).

This binary state space now becomes equivalent to answering a set of logical questions: "Suppose I were flying straight and level at heading H, speed S, and altitude A. Would I encounter any conflict with any type of object?" Theoretically, an "object," can be any static or dynamic entity, including traffic, terrain, weather, and/or special-use airspace.

Finally, a pilot can graphically rotate this 3D maneuver space to understand its geometry, and then quickly select a safe, efficient maneuver by simply moving a 3D cursor to a conflict-free region that avoids all conflict regions.

Naturally, this logic has two implicit assumptions (1) a limited conflict probe lookahead time, and (2) instantaneous change from the current H0, S0, A0 to any new point H1, S1, A1 in the state space. Assumption 1 is no special problem because no one can predict reliably into the distant future. All conflict probes assume limited lookahead time anyway.

Assumption 2 is non-trivial, but surmountable, particularly if changes in H,S,A are kept limited in size. First, it is logical to assume that pilots and air traffic controllers prefer efficient maneuvers, defined as those requiring the smallest deviation from current H,S,A. The smaller the deviation, the quicker the maneuver can be executed. Hence, any error due to physical execution time is reduced to manageable limits. Second, future versions of the algorithm will use a more sophisticated conflict probe, eliminating this problem altogether. But, for now, a relatively simple probe should be sufficient to scientifically establish proof-of-concept.

4CAS

What you see at left is an annotated version of the actual prototype display I coded, starting in the summer of 2001.

4CAS--4-Dimensional Collision Avoidance System--is NOT designed as a replacement for the CDTI. Rather, it is an adjunct to the CDTI, and would perfectly complement a display such as NASA's.

In 4CAS, the aircraft's current heading, speed, and altitude always comprise the exact center of the maneuver space (Cartesian coordinates 0,0,0). Therefore, maneuver is always relative to whatever heading, speed, and altitude your aircraft happens to have at any given instant. This much is nothing new. Moving maps act the same way.

The display can be rotated in 3 dimensions, either by mouse or trackball (this is the Flash movie you saw on the home page). Click-and-drag is faster and can be used in Emergency Mode. The "MS rotate" panel is used in Standard Mode. Rotation allows you to quickly inspect the complete geometry of the maneuver space and any conflict regions.

The conflict regions themselves are translucent, so you can see through them. Their color corresponds to your available maneuver time (currently 0-6 minutes, easily configurable). This lookahead time was chosen because research shows that 3 minutes is typically sufficient to execute nearly any reasonable maneuver (recall that a standard large-aircraft's rate of turn is 3 minutes).

To use 4CAS, you normally don't have to do anything until a conflict region obscures the center of the display. The presence of any conflict region is an alerting device, but a central conflict means maneuver is necessary. It's the signal that your current autopilot settings are going to result in a problem.

When that happens, finding a resolution is extremely simple: Just move the 3D cursor to a free (black) region of maneuver space and hit the green "EXECUTE" button. This automatically resets the aircraft's autopilot to whatever heading, speed, and altitude was selected. As the aircraft executes the actual maneuver, the 3D cursor automatically creeps back toward the center until, when finished, it reassumes dead center. At that point, all physical conflicts are resolved.

4CAS first "flew" during the summer of 2004. This was an exciting, historical moment. Microsoft Flight Simulator 2002 formed the testbed. It generated the ownship and traffic, and FSUIPC allowed the two programs to talk. The current version of 4CAS drives Microsoft Flight Simulator 2004.

With this platform, we find we can routinely identify conflicts and initiate resolutions in Emergency Mode in 5-10 seconds, regardless of traffic density and complexity. This level of performance is unparalleled in the history of manual CAS technology.

Proof-of-concept

As all good developers know, just because the inventors of a system can stoke it to high performance doesn't mean the average user can easily do the same. So, we've started taking the system on the road, first in Sweden for shakedown testing with GA pilots. On the basis of those results, we redesigned the interface, and now are making arrangements for independent university testing. For more on that as it develops, see the proof-of-concept section. We will keep this updated as those research results come in.

Other applications

The theory of maneuver space is extensible to other domains. For instance, it is not hard to imagine an air traffic control variant, or a variant for submarines or surface ships. One of the first spinoffs we developed was a maneuver space-based metric of sector congestion for ATC.

Footnote

The conflict probe we are currently using will be of interest to professionals. Right now, 4CAS uses a deterministic probe. Deterministic probes act as if the positions, velocities, and intent of all involved objects are known fully. In cases where this assumption is not made, standard operating procedure is to use a probabilistic probe. Probabilistic probes start with a set of assumptions about the behavior of each involved object and calculate a probability density function, future position = f(time, assumptions). This forces the estimation of future conflict to assume a probability map, with a mean and pdf for each point on the path of the ship-of-interest.

In practice, the calculation of these probability maps in veridical displays is extremely complex. However, in the maneuver space representation, the relation (while equally complex in theory) is extremely simple in practice. The centroid of each full conflict region in the maneuver space represents the maximum likelihood conflict estimator, and has an associated H,S,A triplet. Because of smoothness constraints in the mathematics, the farther away from the centroid, the lower the probability of conflict. So, to convert to a probabilistic representation, all one has to do is to "blur the edge" of the overall conflict region, treating it as a pdf rather than a hard limit.

This has the practical effect of making it extremely easy to accommodate differing levels of trust in the automation. Liberal users can simply move the 3D cursor to the sharp edge of a conflict region. Conservative users can simply select a maneuver slightly farther away.

©2006 Maneuver Space Technologies, LLC

<body> <h2 id="pageName">Theory of the Maneuver Space </h2> <div class="feature"> <h3 align="left">Motivation for developing the theory </h3> <p> It is inherently hard to keep aircraft properly separated using conventional technology. This is one reason why the average U.S. air traffic controller currently makes about $170,000 a year. </p> <p>At the root of the problem is the old-fashioned, veridical display of traffic information. Veridical displays are based on a representation of physical reality. They are maps. And the root problem (in our opinion) is that maps are not necessarily the best way to approach aircraft conflict resolution because they require the user to solve both the conflict detection and the conflict solution problems, both of which are hard problems. </p> <p><img src="Graphics/NASACDTI2.jpg" width="256" height="205" hspace="8" align="left">Naturally, there have been serious attempts to solve conflict detection and resolution with technology. Right now, the world's best veridical CDTIs are arguably the <span class="style4"><a href="http://humanfactors.arc.nasa.gov/" target="_blank">NASA Ames displays</a></span> (shown at left). They certainly are a standard by which all other cutting-edge systems are judged. These calculate a resolution cone for lateral maneuver. Currently, there is even a 3D veridical version.</p> <p>Nonetheless, while maps are the standard approach, <span class="style4"><a href="Publications/Knecht%20Sepn%20Maint%20in%20FF.pdf">research data</a></span> indicate they have trouble optimally representing the full range of maneuver solutions across heading, speed, and altitude. You can get a good lateral OR a vertical maneuver, but it is still extremely hard to get a combination maneuver in manual selection mode. </p> <p>&nbsp;</p> <p>&nbsp;</p> <p><img src="Graphics/snap135.jpg" width="259" height="186" hspace="8" align="left">My own first attempt at a map display also centered around solving the conflict detection problem. Given the cylindrical geometry of the en-route protected zone ( 5 nm radius, 1000 ft vertical half-height), I wrote a conflict probe to determine if and when one aircraft would enter another's protected zone. This time-to-separation loss was used to color-code the aircraft icons on a map display. The screenshot at left is a 40%-scale view of the actual display we tested with commercial airline pilots. It gave the pilot a way to (1) identify problem aircraft and (2) know how much time there was to resolve the conflict. </p> <p>While <a href="Publications/Knecht%20Sepn%20Maint%20in%20FF.pdf" target="_blank"><strong>this</strong></a> did solve the conflict <em>detection</em> problem, our research discovered that conflict <u>resolution</u> was the tougher problem to solve. Even when you know which aircraft are threats, you still have to select a maneuver that will solve the conflict. That is the hard part, especially when the intended resolution is either in the lateral (x-y) plane, or involves multiple aircraft.</p> <p>Several individuals and teams have proposed elegant mathematical algorithms for <strong><a href="Publications/HF%20%2798%20Paper.doc" target="_blank">automatic</a></strong><strong><a href="Publications/HF%20%2798%20Paper.doc"> conflict resolution</a></strong> (the <em>super-autopilot</em>). However, we still feel that strong psychological and political considerations point to having manual conflict-resolution capability--now, and from now on. Pilots want to fly, controllers want to control, and passengers feel comfortable having a pilot onboard. The concept of hurtling through the air in a completely computer-controlled vehicle--while appealing to engineers--is one we feel the public will only accept as a backup system to human guidance.</p> <p> So, while we know other developers are going to argue vehemently against our position, the issue will be settled in the marketplace. Meanwhile, the job of MST is to explore what we feel is viable technology, and to accurately report on the results. </p> <h3>The problem is the representation </h3> <p>In our opinion, the basic problem with veridical displays is the actual information representation they are based upon, namely physical, geographic reality. As it turns out, while this is the best way to describe the static world, it is not necessarily the best way to describe the dynamic world. This is particularly true when trying to calculate trajectory solutions for multiple objects moving at different speeds, altitudes, and headings. </p> <p>The need for a new kind of information representation is what motivates the theory of the <strong>maneuver space</strong>. </p> <p>To the rest of the world (especially the military), &quot;maneuver space&quot; is defined as the amount of <em>physical</em> space, within which an object can maneuver, given a certain amount of time. </p> <p>However, it is also possible to define maneuver space as being a <em>conceptual</em> space, namely a <em><strong>space of possible aircraft maneuvers, given a predetermined time period</strong></em>.</p> <p>The key to this new representation lies in the way we define the word &quot;maneuver.&quot; In the simplest sense, any given aircraft <em>maneuver</em> can be defined as <em>one unique setting of the aircraft autopilot</em>. This unique setting consists of 3 numbers, one for heading, one for altitude, one for speed. This defines stable flight (disregarding change from one setting to another, i.e. the actual time it takes to execute a given maneuver--we will discuss that issue presently). </p> <p><img src="Graphics/B737%20autopilot.jpg" width="212" height="72" hspace="5" align="left"></p> <p>Defined this way, it is possible to construct a 3D volume--a conceptual <em>state space</em>--determined by 3 coordinate axes of <strong>heading</strong>, <strong>altitude</strong>, and <strong>speed</strong>. Individual aircraft maneuvers can then be defined as unique points within that space. </p> <p>&nbsp;</p> <p><img src="Graphics/MS%20w%20CR%20color.jpg" width="269" height="226" hspace="5" align="left">Next, it is possible to parse this space into two basic regions--<em><strong>safe maneuvers</strong></em> versus <em><strong>unsafe</strong></em> <strong><em>maneuvers</em></strong>. </p> <p>Standard mathematical algorithms (the conflict probe--see Footnote) can determine which H,S,A triplets are problematic, as well as the time when separation loss will both occur and end. Any problematic maneuvers can then be color-coded according to time-to-conflict (available maneuver time). </p> <p>This binary state space now becomes equivalent to answering a set of logical questions: <em>&quot;Suppose I were flying straight and level at heading H, speed S, and altitude A. Would I encounter any conflict with any type of object?&quot;</em> Theoretically, an &quot;object,&quot; can be any static or dynamic entity, including traffic, terrain, weather, and/or special-use airspace. </p> <p>Finally, a pilot can graphically rotate this 3D <em>maneuver space</em> to understand its geometry, and then quickly select a safe, efficient maneuver by simply moving a 3D cursor to a conflict-free region that avoids all <em>conflict regions</em>.</p> <p>Naturally, this logic has two implicit assumptions (1) a limited conflict probe lookahead time, and (2) instantaneous change from the current H0, S0, A0 to any new point H1, S1, A1 in the state space. Assumption 1 is no special problem because no one can predict reliably into the distant future. <u>All</u> conflict probes assume limited lookahead time anyway. </p> <p>Assumption 2 is non-trivial, but surmountable, particularly if changes in H,S,A are kept limited in size. First, it is logical to assume that pilots and air traffic controllers prefer <em><strong>efficient maneuvers</strong></em>, defined as those requiring the <em>smallest deviation from current H,S,A</em>. The smaller the deviation, the quicker the maneuver can be executed. Hence, any error due to physical execution time is reduced to manageable limits. Second, future versions of the algorithm will use a more sophisticated conflict probe, eliminating this problem altogether. But, for now, a relatively simple probe should be sufficient to scientifically establish <a href="MSTProofOfConceptText.htm"><strong>proof-of-concept</strong></a>.</p> <p><img src="Graphics/4CAS%20Screenshot%20new%20look%20annotated.jpg" width="398" height="474" hspace="10" align="left"></p> </div> <div class="story"> <h4>4CAS</h4> </div> <div class="story"> <p> What you see at left is an annotated version of the actual prototype display I coded, starting in the summer of 2001.</p> <p><strong>4CAS</strong>--<em>4-Dimensional Collision Avoidance System</em>--is NOT designed as a replacement for the CDTI. Rather, it is an <u>adjunct</u> to the CDTI, and would perfectly complement a display such as NASA's.</p> <p>In 4CAS, the aircraft's current heading, speed, and altitude always comprise the exact center of the maneuver space (Cartesian coordinates 0,0,0). Therefore, maneuver is always <em>relative</em> to whatever heading, speed, and altitude your aircraft happens to have at any given instant. This much is nothing new. Moving maps act the same way. </p> <p>The display can be rotated in 3 dimensions, either by mouse or trackball (this is the Flash movie you saw on the home page). Click-and-drag is faster and can be used in Emergency Mode. The &quot;MS rotate&quot; panel is used in Standard Mode. Rotation allows you to quickly inspect the complete geometry of the maneuver space and any conflict regions. </p> <p>The conflict regions themselves are translucent, so you can see through them. Their color corresponds to your available maneuver time (currently 0-6 minutes, easily configurable). This lookahead time was chosen because <span class="style4"><a href="Publications/Phase%20IV%20TRB%201997%20w%20Figs.doc" target="_blank">research shows</a></span> that 3 minutes is typically sufficient to execute nearly any reasonable maneuver (recall that a standard large-aircraft's rate of turn is 3 minutes). </p> <p>To use 4CAS, you normally don't have to do anything until a conflict region obscures the center of the display. The presence of <em>any</em> conflict region is an alerting device, but a central conflict means maneuver is necessary. It's the signal that your current autopilot settings are going to result in a problem. </p> <p>When that happens, finding a resolution is extremely simple: Just move the 3D cursor to a free (black) region of maneuver space and hit the green &quot;EXECUTE&quot; button. This automatically resets the aircraft's autopilot to whatever heading, speed, and altitude was selected. As the aircraft executes the actual maneuver, the 3D cursor automatically creeps back toward the center until, when finished, it reassumes dead center. At that point, all physical conflicts are resolved. </p> <p>4CAS first &quot;flew&quot; during the summer of 2004. This was an exciting, historical moment. Microsoft Flight Simulator 2002 formed the testbed. It generated the ownship and traffic, and <span class="style4"><a href="http://www.schiratti.com/index.html" target="_blank">FSUIPC</a></span> allowed the two programs to talk. The current version of 4CAS drives Microsoft Flight Simulator 2004.</p> <p>With this platform, we find we can routinely identify conflicts and initiate resolutions in Emergency Mode in 5-10 seconds, <u><strong>regardless of traffic density and complexity</strong></u>. This level of performance is unparalleled in the history of manual CAS technology.</p> <h3>Proof-of-concept</h3> <p>As all good developers know, just because the inventors of a system can stoke it to high performance doesn't mean the average user can easily do the same. So, we've started taking the system on the road, first in Sweden for shakedown testing with GA pilots. On the basis of those results, we redesigned the interface, and now are making arrangements for independent university testing. For more on that as it develops, see the <a href="MSTProofOfConceptText.htm"><strong>proof-of-concept</strong></a> section. We will keep this updated as those research results come in. </p> <h3>Other applications</h3> <p>The theory of maneuver space is extensible to other domains. For instance, it is not hard to imagine an air traffic control variant, or a variant for submarines or surface ships. One of the first spinoffs we developed was a <a href="Publications/SCAMP.pdf" target="_blank"><strong>maneuver space-based metric of sector congestion</strong></a> for ATC. </p> <h3>Footnote</h3> <p>The conflict probe we are currently using will be of interest to professionals. Right now, 4CAS uses a <em>deterministic</em> probe. Deterministic probes act as if the positions, velocities, and intent of all involved objects are known fully. In cases where this assumption is not made, standard operating procedure is to use a <em>probabilistic</em> probe. Probabilistic probes start with a set of assumptions about the behavior of each involved object and calculate a probability density function, <em>future position = f(time, assumptions</em>). This forces the estimation of future conflict to assume a probability map, with a mean and pdf for each point on the path of the ship-of-interest. </p> <p>In practice, the calculation of these probability maps in veridical displays is extremely complex. However, in the maneuver space representation, the relation (while equally complex in theory) is extremely simple in practice. The centroid of each full conflict region in the maneuver space represents the maximum likelihood conflict estimator, and has an associated H,S,A triplet. Because of smoothness constraints in the mathematics, the farther away from the centroid, the lower the probability of conflict. So, to convert to a probabilistic representation, all one has to do is to &quot;blur the edge&quot; of the overall conflict region, treating it as a pdf rather than a hard limit. </p> <p>This has the practical effect of making it extremely easy to accommodate differing levels of trust in the automation. Liberal users can simply move the 3D cursor to the sharp edge of a conflict region. Conservative users can simply select a maneuver slightly farther away. </p> <p><span class="style3">&copy;2006 Maneuver Space Technologies, LLC </span></p> </div> <p><a href="MSTAboutUsText.htm" title="History of Maneuver Space Technologies" target="_self">Maneuver Space Technologies History</a><br> <a href="MSTTheoryText.htm" title="Theory of the maneuver space" target="_self">Maneuver space theory</a> <br> <a href="MSTStaffText.htm" title="Maneuver Space Technologies Staff" target="_self">Maneuver Space Technologies Staff</a> <br> <a href="MSTKnechtCVText.htm" title="William Knecht CV" target="_self">William Knecht CV</a> <br> <a href="MSTProofOfConceptText.htm" title="Maneuver Space Proof of Concept" target="_self">Proof of Concept</a> <br> <a href="MSTFAQText.htm" title="Maneuver Space FAQ" target="_self">Maneuver space FAQ</a> </p> </body>