View Full Version : NAS Rethink....

19th Jan 2004, 14:11
I think this deserves its own thread.

After the release of the Launny incident report they came out with this...

Recommendation 20040013/14
The ATSB recommends that the Civil Aviation Safety Authority/AirServices Australia, in consultation with Airservices Australia/Civil Aviation Safety Authority and the NAS Implementation Group, review NAS procedures and communications requirements for operations in Class E airspace, with particular emphasis on air transport operations during climb and descent in non-radar airspace, with a view to enhancing situational awareness of pilots operating in that airspace.
The review should include examination of, and where necessary revision and updating of, education, training and chart frequency material.

To make it easy for the brains trust, what do you think should be the changes. Keeping in mind that the investigation also identified that as NAS as a whole is not yet in, wholesale change will not be made, I ask for specifics.

I'll Start

- Class C steps from Class A into C Terminal areas.
- Frequencies and boundaries on Charts
- Class C steps into D towers. Tell me all you want about moving the resource to the risk but this allows extra protection that is lacking and has already caused stuff ups.

Cowboys can go kill themselves elsewhere. Lets not allow it to occur taking 100 odd punters up the back of a jet with them.

20th Jan 2004, 03:37
Get rid of VFR on Top, This must be the most useless procedure ever conceived.

20th Jan 2004, 05:09
On another thread (here (http://www.pprune.org/forums/showthread.php?threadid=92263)), 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.


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.

20th Jan 2004, 06:21
I realise you are trying to be positive, but the non-radar E stuff wouldn't work.
Trying to reproduce what FS used to do with TAAATS just has too many holes. The task of trying to predict where VFR aircraft might be is just unworkable. It still doesn't solve the problem of unalerted see and avoid (tracks are not radar paints- 10 nm isn't much on the screen, but it's a HUGE amount in real life). Radio traffic would go thru the roof. How often are VFR's supposed to update? It would be simpler and more precise to reintroduce the old FS full reporting VFR.
ADSB will be perfect for solving non-radar E. Why not keep the old system until it's available? Allowing (and encouraging) VFRs to self announce goes part of the way. Giving VFRs the option of flight following (note- AS IN THE US!!!! NAS is the US system, right?) is another way to encourage participation. At the end of the day, the system (in whatever form) needs to be inclusive. Dick's ideal for more freedom (with more responsibility) is a pipe-dream- without something like ADSB the VFR pilot, thru no fault of his own, CANNOT meet his requirement for that extra responsibility ie. how does he KNOW his transponder is working, or working correctly, how does he avoid a jet in a slow single, how does he SEE a jet approaching him from behind, how does he avoid instrument approaches etc etc.?

20th Jan 2004, 07:27
ShiTsu maybe a sector could be created along the lines of the YMMM and YBBB for cross boundary handoffs. When the tag is created you fill in the csec box with say YVFR or somesuch and it make it balck to everybody and 'post' ie associate code and name to all partitions and remotes related to the FDP (flight data processor).

20th Jan 2004, 07:52

I reckon that's brilliant - simple sensible and safe. Mode S transponders would make it even simpler ? but much more expensive I fear..

VFR in class E without radar is a big hole in NAS - if that Tobago had a dodgey transponder or had not operated it correctly, let's face it neither of which is uncommon, (Yes, I know that's 2 ifs and probably in risk management terms not that great - but still a risk!), one dreads to think of the possible consequences.

VFR in class E is fine - IF TCAS, transponders and pilots all do as they are supposed. .......... but there is no failsafe, other than mk 1 eyeballs, in NAS if they don't.

20th Jan 2004, 09:01
Ah, a positive outlook topic for a change.

My thoughts on what should be done to improve NAS:

1. All VFR aircraft operating in Class E should:

(a) have appropriate ATS VHF frequencies
(b) be radar idenitified where applicable and also be required to maintain a listening watch on ATS frequencies whilst operating in E;
(c) in non-radar E airspace, VFR aircraft should be required to operate full reporting communication procedures to ATS (or on a broadcast basis when outside of VHF coverage) whilst operating in E (note full reporting not required for radar E).

2. VFR aircraft operating in E would be provided with DTI by ATS to the extent that workload and equipment capability allows. Pilot is still encouraged and ultimately responsibile for "see and avoid".

3. VFR aircraft should be PERMITTED and ENCOURAGED to participate in the ATS system, whilst operating in G airspace, if they so desire (I'm even prepared to pay AsA for the extra service). These aircraft would receive the same level of service eg flight following, DTI etc as applicable to VFR aircraft operating in (my) E airspace.

4. VFR requests to ATS for traffic advisories when in G airspace should state whether the pilot requires a "snapshot" traffic advisory or an ongoing (route/sector) traffic advisory service. ATS to provide on a workload and equipment capability basis.

5. Return ATS frequencies and associated boundaries to all VFR and IFR charts (Can someone tell me where Mt Tassie is as I cannot locate it on either my WAC or VNC chart?)

I hope that someone who really matters takes note of my comments, and the valuable contributions from others, and amends the national airspace system accordingly.