From SKYbrary Wiki
|Category:||Loss of Separation|
This article describes typical actions done by air traffic controllers to detect conflicts in en-route environment.
Detecting conflicts between aicraft is an important part of the air traffic controller job and arguably the most complex one. Once a conflict is properly identified the resolution is relatively straightforward - the controller chooses an appropriate method (e.g. level change, vectoring, speed control, etc.), implements the plan and monitors aircraft compliance. If the situation remains undetected, however, this may result in loss of separation, late (and more abrupt) manoeuvres, STCA/TCAS activation or worse.
If all aircraft are assigned different levels, and are not expected to climb or descend, then there are no conflicts. Most commercial operations however take place in the RVSM layer which means that this situation is unlikely. Therefore, normally the first thing to be done in a surveillance environment, is a "same level scan", i.e. looking for aircraft that are maintaining the same level. This initial step identifies aircraft that need further examination. The second phase is to discard the pairs that are "obviously" non-conflicting, e.g. flying at the same speed to the same point with long distance between them, those whose paths do not cross, etc. After that, the minimum distance of the "suspicious" pairs is determined and, if necessary, a plan for solving the conflict is created.
Climbing and descending flights present a special challenge as they require more checks to be done, e.g.:
- Does the current level cause conflicts?
- Will the final level for the sector cause a conflict (within the sector or at the exit point)?
- Will any of the intermediate levels cause a conflict within the sector?
- Will the aircraft be able to reach its planned level before the exit point? If not, will this cause a conflict in the next sector?
These checks may become more complex if the aircraft climbs or descends through a high number of flight levels (e.g. climbing from FL 140 up to FL 360). This results in significant change in groundspeed (due to wind and IAS variations) which hinders precise calculations. The effect may be mitigated by system support tools based on aircraft performance data (as opposed to surveillance-derived data) and controllers are often able to make reasonably precise estimates based on experience. Nevertheless, such situations require much more attention than aircraft in level flight.
Factors that help controllers detect conflicts are:
- system support (see section below)
- discipline, i.e. performing structured scan of the aircraft that are, or will be under control and evaluation of the impact of each flight profile change
- fixed-route environment. This usually means that there are fixed "hotspots" (normally where airways cross). An experienced controller can often detect a conflict by knowing that when there is an aircraft at point A then if the other one is at point B they will be in conflict at point C.
- recurrent training for non-routine situations
Factors that may cause a conflict to be missed include:
- Strong winds (e.g. 50-100 kt or more). These may alter aircraft speeds in such a way that a BOEING 737-300 becomes faster than a AIRBUS A-380-800 in terms of groundspeed. Also, aircraft flying at different tracks will be affected differently. As a consequence, pairs that seem to be safely separated may be in conflict.
- Free route environment. This means that the "standard" hotspots are no longer relevant and a situation may arise anywhere. While free route generally reduces the number of conflicts it makes them harder to identify.
- "Irregular" aircraft, i.e. such that form a small fraction of the traffic flow and can be overlooked due to e.g. high workload or complacency. Examples of these are non-RVSM aircraft in RVSM space, slow-flying business jets, slow-flying aircraft at lower levels (interfering with arriving and departing aircraft), non-routine situations (e.g. aicraft dumping fuel, military interception), etc.
- Deviation from procedures, e.g. provision of ATS outside the area of responsibility, skipping "unnecessary" coordinations, etc.
- Aircraft avoiding weather are a special challenge, because their behaviour is less predictable and trajectory updates cause increased controller workload. If the controller does not update these, however, system support tools may be less useful.
- Airspace boundaries are areas where conflicts are sometimes detected late. This can be caused e.g. by poor coordination, improper colour representation, etc.
- Blind spots - a controller may examine the future path of an aircraft failing to notice the conflicting one which is just above (or below)
- Improper handover/takeover. The relieving controller normally expects all conflicts to be solved or at least detected and having a planned solution. If this is not the case, or if the controller being relieved fails to pass the information, it is possible that the new controller focuses on the medium and long-term situations and misses a near-term conflict.
A number of tools have been developed to assist controllers in determining and calculating conflicts, the most popular being:
- Range and bearing lines. These are simple elastic vectors used to measure distances and bearings between aircraft, or between an aircraft and a point in space. Their use is based on the assumption that a level flight will maintain its speed and therefore the determination of the separation at the crossing point (or at the CPA) is a matter of simple calculation.
- Tactical Controller Tool (TCT). This tool is part of some ATC systems and is often used to automate the calculation described above. It is normally activated by the controller to check an aircraft pair for a potential conflict. Additionally, it may include a suggestion for vectoring one (or both) aircraft.
- Medium Term Conflict Detection (MTCD). This tool examines the trajectories of aircraft and is activated automatically. If a situation is detected, a special warning (normally in the aircraft label) is presented to the controller.
- What-If (Probe). This is a tool that helps the controller evaluate a planned (but not issued) clearance.