Use Case: Communicate with ZAB Controller by voice to plan flow of arrivals into DFW

Summary: The planning controller is responsible for setting up a good flow of arrival aircraft to DFW. There will probably be a planner for each corner post. The planner does not contact aircraft directly, but contacts the controller responsible for the sector of airspace in which the plane is currently flying. Because the planner will have the greatest need to communicate effectively with other controllers, he should be the primary actor in designing a controller to controller voice communication tool. Primary communication between controllers will be by data link, but should response be slow or should negotiations be required, voice will be used.

Context of Use: Atypical method of communication between controllers, for negotiating with other controllers by voice to setup flow or handle emergencies.

Scope: System under Design is a voice-over-IP communications tool with a GUI on the controller’s display. The buttons will be configured for whomever the controller may need to contact (i.e. other sectors).

Level: User

Primary Actor: Planning Controller

Other actors in main success scenario: ZAB Controller.
also potentially: Falls High Controller, Transition Controller, Bowie, etc.

Stakeholders & Interests: Planner: setup good flow for meter fix at BAMBE.ZAB: monitor and maintain separation of en route traffic, provide good flow.
Falls High: monitor and maintain separation of arriving traffic, ensure good sequencing to BAMBE, give descent clearances into Bowie.
Transition: establish positive control of aircraft on arrivals to DFW, maintain separation if necessary at holding areas.
Flight Crews: fly a smooth and safe arrival to DFW on schedule.

Preconditions: Data link communication was ineffective for the immediate situation and voice communication is required to coordinate air traffic.

Trigger: Planner data links a sequence related request to ZAB, which ZAB cannot accommodate, and negotiation is necessary via voice.

Minimal Guarantees: Controllers are able to call, talk, and hangup.(one to one communication).

Success Guarantees: Controllers can call as many others as they need to negotiate with.(partyline).

Main Success Scenario(example):

  1. Planner sees the need to speed up AAL 123 to .82 mach in order to ensure good flow into Falls High.
  2. Planner data links request to ZAB.
  3. ZAB sees a conflict of requested change with traffic inbound to ZKC.
  4. ZAB contacts Planner via Voice-over-IP.
  5. Planner accepts connection.
  6. Planner and ZAB negotiate, contacting ZKC if necessary, and resolve.
  7. ZAB and Planner end communication.

Extensions:

  1. Planner is busy negotiating with Falls High when ZAB “calls”
  2. Flight crew does not accept change??
  3. Planner contacts Falls High with RTAs for inbound aircraft??

First Draft of GUI:

Connect with other controllers by pushing the appropriate button.
Click again to release the button and terminate the connection.

The button "depresses" to give feedback that you have clicked on it, calling that sector.
The text becomes green when when the other controller accepts the connection.

The Communications Window can be minimized* and restored through use of the "minimize" button in the title bar.

*The window may not look exactly like this when minimized, but it will be reduced in some manner so as not to block the controller's view of the display when not in active use.

If the window is minimized when someone "calls", the window will pop up, chime, and the button of the controller calling will flash (once per second) to alert the user of an incoming call. It flashes until the call is "picked up" by clicking the button.

Maria Romera