On another thread (
here), I proposed the following:
The ‘problem’
At the moment, a large number of VFR aircraft fly around in class G and E airspace, squawking 1200, and are visible on radar. They generally don’t talk to us (ATC) but can often be heard making broadcasts.
When providing a radar service, the best we can do is “traffic is unidentified , at unverified level” We sometimes see unidentified aircraft enter restricted areas, but don’t know who it is.
Background
TAAATS has a ‘rad-tag’ function, which allows a controller to very quickly assign a code to an aircraft which does not have a plan in the system. This attaches a call-sign label to the track and provides Mode C data where available. The ‘tag’ is visible to all controllers within the same ‘partition’ (i.e. it is not visible to a TMA controller when it is an enroute tag and vice versa, nor is it visible to a Melbourne controller when it is a Brisbane tag. They will just see the SSR code.)
Suggested procedure
1. VFR aircraft in class E or G call centre once with a phrase such as “ABC request SSR Code.” No broadcasts of positions reports etc. would be required.
2. With very few modifications (to software or procedures) this code could be made available pre-departure by phone, SMS, e-mail or other means.
3. “Skin” codes might be a viable option, but I am not sure if this could be done at the moment.
Note: The viability of ‘skin codes’ was discussed at length in the thread.
4. The controller rad-tags the aircraft and uses a phrase which means “identified but no radar service is being provided”.
5. The VFR aircraft monitors whichever area frequency is appropriate for their location.
6. From then on, if the VFR aircraft becomes traffic to an IFR or another VFR, or appears to be about to enter a restricted area or needs to be told anything, the controller knows who it is and can make a directed call. The IFR aircraft can be told not only where the traffic is, but also who it is. The two aircraft would then be able to talk to each other to sort out any confliction.
7. Another benefit would be in the case of a VFR with an expired SARtime. A quick search of the ‘tag’ list would identify if they are still flying and where they are.
This proposal should cost next to nothing, would add an extra layer of safety, would allow us to provide a better, more specific service and would increase everyone’s situational awareness. Of course, it is limited to radar coverage, but it’s a start.
I believe that if we are to make Class E airspace safer, immediate implementation of the above would help – at least in
radar E.
Non-radar E
If we have to have non radar Class E (and I think we should not), then more thought is required.
A longer term fix for non-radar E would require some amendments to TAAATS. I propose that a simple, quick method be devised to allow controllers to display the disposition of VFR traffic upon receipt of a VFR call. (The current method of entering a full “Flight Data Record” is too cumbersome and would not work for ‘pop ups’.) A simple action such as entering a call-sign and level, plus a graphic tool to depict the route would suffice.
An immediate
short term fix might be to require VFR aircraft in class E to:
a) File a flight plan; and
b) Call ATC as above to activate that plan
c) Advise of any changes to the plan.
Whilst that may seem prescriptive, it would impose no other obligations on the VFR pilot. They would still operate VFR (i.e. no clearance) in Class E. No broadcasts would be required. Importantly, however, the non-radar controller would be able to alert IFR aircraft to their presence (i.e.
alerted see and avoid, even in non-radar airspace).
The above changes (both for radar and non-radar) would require frequencies to be published on charts. There would be no unnecessary calls or ‘chatter’, just the initial call and the VFR aircraft responding where required.
Other improvements
1) Scrap VFR on top, IFR pick-up and VFR climb and descent. Replace them all with one procedure (e.g. ‘suspend IFR’) which allows an IFR to do whatever a VFR can do, but still receive SAR alerting and any other required ‘IFR’ services (Perhaps even DTI in E). ‘Suspended IFR’ would continue until the pilot says ‘request resume IFR’ and a new clearance is issued.
Advantages: Simple, safe, efficient and allows the
pilot to make the decisions about the safety of the aircraft, whilst still receiving a service.
(If desired, of course, the pilot could ‘cancel IFR’ and become a ‘real’ VFR, thus cancelling
all IFR services.)
2) Encourage all aircraft to ‘participate’ in the system, by filing flight plans etc.
Advantages: The more traffic is ‘known’, the more chance there is of ‘alerted’ see and avoid.
3) Publish frequencies and their boundaries on charts available to VFR pilots.
Advantages: It doesn’t really matter
what frequency aircraft are on, provided that conflicting aircraft are on the
same frequency when they need to be.
4) Publish sector and ATC unit boundaries on charts.
Advantages: Situational aewareness of pilots would be enhanced. It makes no sense for a VFR aircraft to be on a tower frequency when the overlying airspace is owned by the centre.
5) Publish ‘high traffic areas’ (such as IFR holding points, instrument approaches, major IFR routes) on VFR charts in a simplified, easy to read format.
Advantages: This will allow VFR pilots to make good airmanship decisions to avoid these areas without having to be able to read an approach chart or obtaining a verbal briefing from a local IFR pilot. During flight, the chart can be referred to, rather than relying on memory.
(Note: I am not talking about reproducing every IFR route on the VFR charts. What I am proposing is that 'high density' routes etc. be assessed and published)
6) Reclassify higher density enroute areas as Class C or B. This would include those areas where high numbers of RPT aircraft operate.
That's all so far.