|
|
|
|
Conflict Solving Assistance |
|
 |
|
|
|
The PHARE tools concept was built upon the capability of aircraft to follow an agreed 4D trajectory with a high degree of accuracy. The trajectory in the ground system would be identical to the trajectory in the aircraft flight management system, thus providing greater confidence in conflict detection (by the Conflict Probe) and resolution (by the Problem Solver), and greatly increasing flight safety.
|
|
|
|
The 4D ATM Philosophy stated that:
“If the 4D planned flight paths of different airframes are conflict-free and the actual positions and the evolution of the positions of these airframes comply within certain monitored limits with their planned flight paths, then the actual positions and their evolutions are conflict-free also.”
Based on this philosophy controllers were provided with tools to assist in planning conflict-free trajectories.
|
|
|
|
| |  |
| | Conflict Detection (Click for larger image) |
|
In PHARE the Conflict Probe operated every time a new trajectory was generated, searching the flight database to see if any other trajectory conflicted. If any conflict was found the Conflict Probe passed the details of the conflict to the controller display or to the other automated tools supporting the controller.
There was a debate on whether there should be a new definition of a conflict. Normally geometric methods are used for specifying conflicts based on rule-of-thumb separation standards. An alternative method would be to develop a conflict probe that used collision risk.
The initial Conflict Probe in PHARE Demonstration 1 used the more common geometric approach. In development for PHARE Demonstration 3 the probabilistic Conflict Probe was assessed.
It appeared, however, that controllers wanted a clear indication of infringement of the separation standards rather than probabilities of collision. With the current ATC rules probability of collision is not a useable approach.
Conflict detectors assume that all aircraft follow their trajectories within a specified margin of accuracy. The PHARE concept was based on feedback loops to ensure that aircraft actually were following the trajectory that they had agreed with the ATM System. This allowed the Conflict Probe to operate with a long look-ahead. Any limitation on the look-ahead is due to uncertainty rather than potential inaccuracy.
|
|
|
|
|
|
 | |
| Co-operative Tools in PHARE Demonstration 3 (Click for larger image) | |
|
Conflicts would be displayed to the controller by the Co-operative Tools on an agenda of problems to solve. For each conflict the Co-operative Tools not only displayed the conflicting aircraft but also aircraft that were close enough to the conflict for the controller to consider.
The major concept of the Co-operative Tools was that of filtering the information for the controller to allow rapid assimilation of the air traffic situation. The difference in approach of the Co-operative Tools was that of identifying areas of ‘interactions’ these were areas that would be of interest to a controller where for example there was a risk of a conflict although there was no actual loss of separation. The tool then put these ‘interactions’ and the conflicts into PROblem SITuations (PROSITS) which were displayed on an agenda time line with levels of seriousness indicated. This approach allows the work of the controller, or controller team, to be more efficiently managed.
The Co-operative Tools approach was geared to the 2 controllers for a sector working as a team rather than the hard temporal split that was envisaged in the layered planning concept of the PHARE Medium Term Scenario.
The Co-operative Tools were to some extent self contained and had within them a problem solving system based on the ability to provide look-ahead along modified trajectories.
|
|
| |
 |
Further details of Co-operative Tools |
|
|
|
|
| |  |
| | Part of the PHARE Demonstration 1 HIPS Display (Click for larger image) |
|
To solve a conflict the controller would use the Problem Solver which had a display that showed 'avoidance zones' as red areas on the screen. The Problem Solver display allowed the controller to use a mouse pointer to alter the trajectories of the aircraft involved on the screen by 'dragging' their constraint points until the trajectories no longer penetrated any avoidance zones. The Problem Solver then generated constraints which would be passed to the Trajectory Predictor and the deconfliction solution would be assessed.
The Problem Solver developed in the PATs did not provide solutions independent of the controller. Instead it provided an entirely novel interactive graphical interface that allowed controllers to model deconflictions and then issue the trajectory constraints to apply them. The graphical interface allowed the controller to display a trajectory graphically then amend the trajectory by dragging its constraints with a mouse pointer. Conflicts are shown as ‘avoidance zones’ on the screen and as the trajectory is interactively amended the conflicts are updated in almost real-time to show the affect on the conflicts of the amendment to the trajectory. Controllers found the use of the Problem Solver was intuitive and it rapidly became the tool by which PHARE was known.
The Problem Solver was a developed in PHARE as a totally new concept. Understandably, there were some conceptual and usability issues that required more explanation to the controllers. These were:
|
|
- Constraint Editing not Trajectory Editing.
- Conflict Detection Algorithm.
- Trajectory Validation.
- Amendments affecting Other Sectors.
|
|
|
The PHARE Conflict Probe is documented in:
| | | |
