Narrative:

Aircraft X was en route from bhm to cvg, and had been routed over vxv SWEED6 arrival due to WX over and west of bna. Cruise altitude was FL250. Since the majority of traffic between ZTL sector 39 and ZID sector 84 is 'north-south' the usual 'right altitude for direction' rules are modified by LOA between the 2 ctrs. Consequently, northbound aircraft are to be cleared at 'wbound' altitudes while sbound aircraft are given 'eastbound' altitudes. To comply with the requirement I cleared aircraft X from FL250 to FL240 and entered the change into the computer. Normally the computer forwards this information to ZID automatically, but in this case it did not do so. The computer 'tells' us that information has not been forwarded by sending a message to a CRT at our work station, and activating a ringing sound (briefly). If there is already a message waiting to be received the ringer will not sound until the previous message(south) have been acknowledged. I do not know if this was the case in this situation or not, but I did not see or hear the computer's message. After a time (2 or 3 mins?), if the message has not yet been acknowledged by a controller, it is printed out along with flight progress strips for that sector. From time to time someone will come by the printer to collect the strips (and messages) and deliver them to the sector. In our area this happens between (about) once a min and every few mins (3-5 mins between 'collections' would not be unusual). By the time the message was delivered to me (and I became aware that the revised altitude information was not coordinated) the aircraft had already entered ZID sector 84's airspace. Consequently, I had cleared the aircraft to an altitude (FL240) which was not the altitude that ZID 84 expected the aircraft to be using (which was FL250). Several items come to mind in terms of 'what caused the error:' 1) there was a considerable amount of chop and turbulence at all altitudes, so I loath to change an aircraft's altitude until I had to. Consequently, I waited until the aircraft was only 15 or 20 mi from the sector boundary before changing the altitude assignment. This meant that I only had 2-3 mins to determine that the computer had not coordinated the changed altitude and complete manual coordination. 2) there were numerous other aircraft and several 'other duties' which I was completing at this time. In trail spacing of aircraft to iah, deviation and reroute of aircraft due to WX. Multiple requests for information about rides, and of course, all the usual duties of the sector. If I had been less busy, or if I had some help with the sector I think that the computer's failure to complete the coordination of the altitude change would have been detected early enough to keep the aircraft from entering ZID 84 at an uncoordinated altitude. Callback conversation with reporter revealed the following information: reporter stated part of the problem was that he was the radar controller and combined with the handoff and associate position. He said the radar position became busy and he did not have time to make a land line call regarding the altitude of flight entering ZID airspace. He said staffing was a problem but admitted, it was near shift change and he had expected some help at the sector sooner.

Google
 

Original NASA ASRS Text

Title: ZTL CTLR CLAIMS HE COMPLIED WITH LOA ALT TO ZID BUT ASSIGNED INFO WAS NOT RECEIVED BY THE ZID CTLR BECAUSE OF A COMPUTER PROB.

Narrative: ACFT X WAS ENRTE FROM BHM TO CVG, AND HAD BEEN ROUTED OVER VXV SWEED6 ARR DUE TO WX OVER AND W OF BNA. CRUISE ALT WAS FL250. SINCE THE MAJORITY OF TFC BTWN ZTL SECTOR 39 AND ZID SECTOR 84 IS 'N-S' THE USUAL 'RIGHT ALT FOR DIRECTION' RULES ARE MODIFIED BY LOA BTWN THE 2 CTRS. CONSEQUENTLY, NBOUND ACFT ARE TO BE CLRED AT 'WBOUND' ALTS WHILE SBOUND ACFT ARE GIVEN 'EBOUND' ALTS. TO COMPLY WITH THE REQUIREMENT I CLRED ACFT X FROM FL250 TO FL240 AND ENTERED THE CHANGE INTO THE COMPUTER. NORMALLY THE COMPUTER FORWARDS THIS INFO TO ZID AUTOMATICALLY, BUT IN THIS CASE IT DID NOT DO SO. THE COMPUTER 'TELLS' US THAT INFO HAS NOT BEEN FORWARDED BY SENDING A MESSAGE TO A CRT AT OUR WORK STATION, AND ACTIVATING A RINGING SOUND (BRIEFLY). IF THERE IS ALREADY A MESSAGE WAITING TO BE RECEIVED THE RINGER WILL NOT SOUND UNTIL THE PREVIOUS MESSAGE(S) HAVE BEEN ACKNOWLEDGED. I DO NOT KNOW IF THIS WAS THE CASE IN THIS SIT OR NOT, BUT I DID NOT SEE OR HEAR THE COMPUTER'S MESSAGE. AFTER A TIME (2 OR 3 MINS?), IF THE MESSAGE HAS NOT YET BEEN ACKNOWLEDGED BY A CTLR, IT IS PRINTED OUT ALONG WITH FLT PROGRESS STRIPS FOR THAT SECTOR. FROM TIME TO TIME SOMEONE WILL COME BY THE PRINTER TO COLLECT THE STRIPS (AND MESSAGES) AND DELIVER THEM TO THE SECTOR. IN OUR AREA THIS HAPPENS BTWN (ABOUT) ONCE A MIN AND EVERY FEW MINS (3-5 MINS BTWN 'COLLECTIONS' WOULD NOT BE UNUSUAL). BY THE TIME THE MESSAGE WAS DELIVERED TO ME (AND I BECAME AWARE THAT THE REVISED ALT INFO WAS NOT COORDINATED) THE ACFT HAD ALREADY ENTERED ZID SECTOR 84'S AIRSPACE. CONSEQUENTLY, I HAD CLRED THE ACFT TO AN ALT (FL240) WHICH WAS NOT THE ALT THAT ZID 84 EXPECTED THE ACFT TO BE USING (WHICH WAS FL250). SEVERAL ITEMS COME TO MIND IN TERMS OF 'WHAT CAUSED THE ERROR:' 1) THERE WAS A CONSIDERABLE AMOUNT OF CHOP AND TURB AT ALL ALTS, SO I LOATH TO CHANGE AN ACFT'S ALT UNTIL I HAD TO. CONSEQUENTLY, I WAITED UNTIL THE ACFT WAS ONLY 15 OR 20 MI FROM THE SECTOR BOUNDARY BEFORE CHANGING THE ALT ASSIGNMENT. THIS MEANT THAT I ONLY HAD 2-3 MINS TO DETERMINE THAT THE COMPUTER HAD NOT COORDINATED THE CHANGED ALT AND COMPLETE MANUAL COORD. 2) THERE WERE NUMEROUS OTHER ACFT AND SEVERAL 'OTHER DUTIES' WHICH I WAS COMPLETING AT THIS TIME. IN TRAIL SPACING OF ACFT TO IAH, DEV AND REROUTE OF ACFT DUE TO WX. MULTIPLE REQUESTS FOR INFO ABOUT RIDES, AND OF COURSE, ALL THE USUAL DUTIES OF THE SECTOR. IF I HAD BEEN LESS BUSY, OR IF I HAD SOME HELP WITH THE SECTOR I THINK THAT THE COMPUTER'S FAILURE TO COMPLETE THE COORD OF THE ALT CHANGE WOULD HAVE BEEN DETECTED EARLY ENOUGH TO KEEP THE ACFT FROM ENTERING ZID 84 AT AN UNCOORDINATED ALT. CALLBACK CONVERSATION WITH RPTR REVEALED THE FOLLOWING INFO: RPTR STATED PART OF THE PROB WAS THAT HE WAS THE RADAR CTLR AND COMBINED WITH THE HDOF AND ASSOCIATE POS. HE SAID THE RADAR POS BECAME BUSY AND HE DID NOT HAVE TIME TO MAKE A LAND LINE CALL REGARDING THE ALT OF FLT ENTERING ZID AIRSPACE. HE SAID STAFFING WAS A PROB BUT ADMITTED, IT WAS NEAR SHIFT CHANGE AND HE HAD EXPECTED SOME HELP AT THE SECTOR SOONER.

Data retrieved from NASA's ASRS site as of July 2007 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.