Narrative:

Several radar terminal locations providing approach control service using stars terminal display workstations (tdw) have been using a coordination procedure generally known as 'silent inbounds.' the procedure is a process where the approach control transfers communication for an arriving IFR/VFR aircraft to a non-approach control VFR tower (in my case) without advance verbal notification of the aircraft's location or intentions/request other than a code used in the radar data block. The receiving controller has to recognize the aircraft on the radar display and determine from the data block entry code what the aircraft will do. My location requires the local controller to: 1) visually acquire a perspective arriving aircraft on the tdw. 2) read and then determine the meaning of a three-letter code on the second line of the aircraft's data block (first letter denotes destination airport; second letter denotes approach type; third letter denotes landing type). 3) determine how the aircraft will enter the pattern from a diverse direction of entries possibilities and its approximate point of intersection with other aircraft currently in that pattern. 4) if a conflict is possible; determine a means to resolve the conflict; which usually means re-sequencing or re-directing current pattern traffic. 5) once communication is transferred to tower; which differs based on the type of approach and the traffic that the approach controller has; the receiving controller can then take action to resolve traffic situations which may impact a safe transition into the control tower environment. My concern is that the local controller is not required to constantly monitor the tdw to determine if there is an arrival in-bound and there's a question of operational focus when they have other traffic concerns. The local controller; when busy with multiple aircraft in its VFR pattern; regularly may not notice that there is an in-bound aircraft until communication has been transferred. Based on the traffic congestion at the time of that transfer; the controller may not physically have adequate time to communicate a transfer back to radar for re-sequencing or time to coordinate flight path adjustments. This process has (at times) placed a significant additional burden on the local controllers ability to visually scan the runway and simultaneously provide other visually significant services such as separation of aircraft in the VFR pattern; watching for bird migrations and other concerns like ensuring they see a coyote crossing the runway at the last minute. This procedure should only be authorized if there is a designated coordinator to manage the flow of arriving aircraft when the local controller has other traffic. And since that occasion is too dynamic to correlate; I would suggest that the procedure be avoided unless a full time coordinator position is manned prior to its use. This avoids a systematic flaw; which may over-extent the ability of the local controller to provide consistent safe services. To date I have experienced several conflicts that could have had a significantly worse outcome if not for the controllers immediate responsiveness. This procedure is being widely used at numerous locations servicing non-approach control VFR towers. Some of these towers have high performance jet aircraft regularly operating in the VFR patterns. The workload of the local controller is significantly increased by this procedure and; for someone which generally has the least amount of airspace; a transfer of communication made without prior verbal coordination may not allow for adequate traffic management time to afford the safe entry of the aircraft into the established traffic flow; if there are other aircraft involved. Couple that with the controllers possible inability to recognize the arrivals entry prior to communications transfer (due possibly to their attention to higher priority duties) and their requirement to coordinate any control actions done to aircraft outside of their assigned airspace prior to taking that action; the time constraints may/could/and have placed them in a position whereas they have to choose which procedure to violate in an effort to insure flight safety. This procedure has been repeatedly brought to the attention of numerous approach control managers without resolution. The overall viewpoint of the managers in question is that the FAA is moving toward a greater use of technology and anything to the otherwise would be a step in the wrong direction. Generally; I agree with that concept; but each advance should be weighed and progress based on safety not expedience nor the lessening of workload for one controller while significantly increasing the workload for another controller. This is especially when that controller has less ability to resolve conflictions. Technology is a wonderfully innovative enhancement to air traffic; its use however; should be governed first by safety not by convenience. In this instance; the safety depends on the ability of the local controller to recognize a code; read it and understand its intent and affect; then take time critical actions to ensure it can be done safely. To read that coded information takes time and that luxury isn't always available in enough time to assure operations are safe. Should technological capability alone deem that it's safe?

Related reports:

Google
 

Original NASA ASRS Text

Title: Tower Controller expressed concern regarding 'silent inbound' procedure utilizing STARS TDW displays that require local controllers to divert their attention from visual airport observations and note STARS TDW information regarding inbounds; claiming increased safety concerns for airport operations.

Narrative: Several radar terminal locations providing approach control service using STARS Terminal Display Workstations (TDW) have been using a coordination procedure generally known as 'silent inbounds.' The procedure is a process where the Approach Control transfers communication for an arriving IFR/VFR aircraft to a Non-Approach Control VFR Tower (in my case) without advance verbal notification of the aircraft's location or intentions/request other than a code used in the radar data block. The receiving Controller has to recognize the aircraft on the radar display and determine from the data block entry code what the aircraft will do. My location requires the Local Controller to: 1) Visually acquire a perspective arriving aircraft on the TDW. 2) Read and then determine the meaning of a three-letter code on the second line of the aircraft's data block (First letter denotes destination airport; second letter denotes approach type; third letter denotes landing type). 3) Determine how the aircraft will enter the pattern from a diverse direction of entries possibilities and its approximate point of intersection with other aircraft currently in that pattern. 4) If a conflict is possible; determine a means to resolve the conflict; which usually means re-sequencing or re-directing current pattern traffic. 5) Once communication is transferred to Tower; which differs based on the type of approach and the traffic that the Approach Controller has; the receiving Controller can then take action to resolve traffic situations which may impact a safe transition into the Control Tower environment. My concern is that the Local Controller is not required to constantly monitor the TDW to determine if there is an arrival in-bound and there's a question of operational focus when they have other traffic concerns. The Local Controller; when busy with multiple aircraft in its VFR pattern; regularly may not notice that there is an in-bound aircraft until communication has been transferred. Based on the traffic congestion at the time of that transfer; the Controller may not physically have adequate time to communicate a transfer back to radar for re-sequencing or time to coordinate flight path adjustments. This process has (at times) placed a significant additional burden on the Local Controllers ability to visually scan the runway and simultaneously provide other visually significant services such as separation of aircraft in the VFR pattern; watching for bird migrations and other concerns like ensuring they see a coyote crossing the runway at the last minute. This procedure should only be authorized if there is a designated coordinator to manage the flow of arriving aircraft when the Local Controller has other traffic. And since that occasion is too dynamic to correlate; I would suggest that the procedure be avoided unless a full time coordinator position is manned prior to its use. This avoids a systematic flaw; which may over-extent the ability of the Local Controller to provide consistent safe services. To date I have experienced several conflicts that could have had a significantly worse outcome if not for the Controllers immediate responsiveness. This procedure is being widely used at numerous locations servicing Non-Approach Control VFR Towers. Some of these Towers have high performance jet aircraft regularly operating in the VFR patterns. The workload of the Local Controller is significantly increased by this procedure and; for someone which generally has the least amount of airspace; a transfer of communication made without prior verbal coordination may not allow for adequate traffic management time to afford the safe entry of the aircraft into the established traffic flow; if there are other aircraft involved. Couple that with the Controllers possible inability to recognize the arrivals entry prior to communications transfer (due possibly to their attention to higher priority duties) and their requirement to coordinate any control actions done to aircraft outside of their assigned airspace prior to taking that action; the time constraints may/could/and have placed them in a position whereas they have to choose which procedure to violate in an effort to insure flight safety. This procedure has been repeatedly brought to the attention of numerous Approach Control Managers without resolution. The overall viewpoint of the managers in question is that the FAA is moving toward a greater use of technology and anything to the otherwise would be a step in the wrong direction. Generally; I agree with that concept; but each advance should be weighed and progress based on safety not expedience nor the lessening of workload for one Controller while significantly increasing the workload for another Controller. This is especially when that Controller has less ability to resolve conflictions. Technology is a wonderfully innovative enhancement to air traffic; its use however; should be governed first by safety not by convenience. In this instance; the safety depends on the ability of the Local Controller to recognize a code; read it and understand its intent and affect; then take time critical actions to ensure it can be done safely. To read that coded information takes time and that luxury isn't always available in enough time to assure operations are safe. Should technological capability alone deem that it's safe?

Data retrieved from NASA's ASRS site as of April 2012 and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.