¶ Primary radar separation principles
¶ Approach level
Separation between two traffics must never go below 1000ft vertically and 5nm laterally (outside the approach axis). Below these minima, the situation is no longer considered safe; this is referred to as an airprox situation.
Occasionally, under very specific conditions, the lateral separation minima can be reduced below 5 nm.
¶ En-route level
¶ Detecting conflicts
¶ Detection tools
¶ Time estimate over FIXes
This feature allows us to have an estimate of a traffic's arrival time over a given point, so we can see whether two traffics passing over the same point will arrive there at the same time or whether they will already be separated.
Warning, this is not a precise measurement tool and the results are only estimated values.
¶ CoFrance's separation measurement and monitoring tool
CoFrance simulates ERATO's separation system; to display it, simply click on the trail (comet) of the two traffics for which we wish to measure the separation.
The minimum distance appears in Yellow when it is less than 10nm. However, this distance is only reliable when the two traffics have a fully converging track and in short- to medium-term situations (approximately 5 mins).
¶ Evaluating the minimum separation between two traffics at a crossing point
The distance between a traffic A and a traffic B at a given point varies depending on the angle formed by the two traffics as they approach this point.
There are two simple techniques for mentally calculating an approximate value of the minimum separation between two traffics at a crossing:
¶ Visual conflict detection
¶ The right questions to ask yourself
¶ Knowledge and mastery of the sector's traffic flows
In order to be able to detect conflicts more easily, it is necessary to know the traffic flows existing within the airspace we control. It is also necessary to know the parity of the routes mainly used, in order to limit the area to scan for conflict detection. When we have a traffic en-route at an even level, we therefore only need to look at the even flows to detect a conflict (for traffics already at their cruising level), which reduces by half the number of flows to scan. Moreover, large flows cross at specific points, and particular attention must be paid to these points since they have a high probability of generating conflicts.
Above sector map is outdated, it just serves as an example.
¶ Conflicts at sector boundaries / at the interface with an adjacent sector
Conflicts at a sector boundary are the responsibility of both controllers. To avoid such situations, it is important to keep traffic more than 2.5nm (laterally) and 1000 ft (vertically) from the boundary of the adjacent airspace, to be certain of not creating conflicts.
¶ Conflict groups
When you find potentially conflicting traffics, it is possible to flag them in order to monitor the situation; for this, "Conflict Groups" will be used.
¶ Resolving conflicts
Once a conflict has been identified, half the work is already done; however, the right actions still need to be taken to avoid this conflict without generating new ones.
¶ Vertical evolution
¶ Level changes
The first method for avoiding a conflict is changing the level of one of the two traffics. This change can be temporary (climbing to the level above for the duration of the crossing, then descending again afterward) or permanent, by asking the traffic if it can use the level above as its new cruising level:
However, this solution is only viable if no traffic is crossing above at FL380, or we would risk creating a new conflict. If another traffic is following the same route at FL390, care must be taken not to create a catch-up situation.
¶ Early descent
When one of the two traffics is close to its TOD, it is preferable to have it descend early, even if this means leveling it off for a while.
¶ Rate of evolution (climb / descent)
¶ Notion of rate
When one or both traffics are in vertical evolution, it is possible to assign climb or descent rate restrictions in order to guarantee that one of the traffics passes a level before a certain time.
In the video example, EZY78J will be 1000ft above AFR45M 2 min before crossing it, thanks to the climb rate.
¶ Expedite
In cases of imminent conflict, it is also possible to ask the pilot to expedite (speed up) their climb or descent. Upon receiving this instruction, the pilot must then adopt the best rate possible, even if it means losing / gaining speed.
However, it must be kept in mind that not all aircraft have the same climb performance, so the aircraft type is an element to take into account for rate-based separation.
For more information on aircraft performance, a table is available on the following sheet: Climb/descent management
¶ Track change
¶ Radar vectoring
If the conflict cannot be avoided vertically, lateral separation must be created. Radar vectoring will therefore make it possible to deviate one or both traffics in order to increase the distance between them. In this situation, the earlier the vectoring is anticipated, the less impact it will have on the pilots. It is therefore preferable to give a small heading change well in advance rather than an aggressive heading at the last minute.
For more information: Radar vectoring
¶ Using direct routings
Radar vectoring can be replaced by a direct routing if it allows the conflict to be avoided. This solution should be prioritized since, unlike radar vectoring, it also shortens the traffic's flight time.
¶ Restrictions
¶ Altitude
If none of the other options mentioned previously can be used, it is also possible to level off the traffic during its climb/descent. This solution is less optimal but should not be overlooked if it allows a conflict to be resolved.
¶ Speed
A conflict may be avoided at a given instant, but the situation must be monitored since the traffics' speed has an influence on resolving or worsening the conflict. Traffics must then be restricted to a specific speed to be certain that separation will be maintained.
When applying restrictions to pilots, it is necessary to inform them of the reason for them. In our case, "Due to traffic" ("Pour cause trafic") must be added at the end of our transmission.