I hate to only blog about the FAA, but as I’ve been busy with outdoor home projects as the weather has improved and not geeking out otherwise, it’s one of the topics that seems appropriate for here, and it’s also a way to get some of the frustration I experience working for the FAA out of my system.
That, and I just wrote about the FAA’s preoccupation with the appearance of safety instead of any real approach to safety within the aviation and air traffic industry and within a week I experienced firsthand another example of that approach.
Then last week I went to another of the mandatory all hands briefings that the management team gives all air traffic controllers at my facility every few weeks.
Part of the briefing was given by the facility Quality Assurance (QA) Manager, giving an overview of the ATSAP (Air Traffic Safety Action Program) program that will soon go into use at our facility. The program is already in use at some facilities across the country.
In the briefing the expressions “just culture” and “safety culture” were repeated over and over. According to the ATSAP website:
“While an exact definition of a safety culture does not exist, a recurring theme in the literature is that organizations with effective safety cultures share a constant commitment to safety as a toplevel priority, which permeates the entire organization.”
In general ATSAP is supposed to be a non-punitive safety reporting system for air traffic controllers where the reports go to the ATSAP office for collection and storage. Then the reports are reviewed by a three member board who “will review and analyze reports submitted in order to identify actual or potential safety problems, and propose solutions”.
So we’re led to believe now, that once the FAA flips the “ATSAP switch” at our facility next month, that our facility will magically morph into a “safety culture”. And once the entire FAA is involved in ATSAP, the entire FAA will become a “just culture”/”safety culture.”
Talk is cheap.
This is the same FAA that routinely ignores safety recommendations by the NTSB. This is the same FAA that ignores safety concerns from all its employees (including its own managers). This is the same FAA that favors “workaround” approaches to safety problems instead of actually fixing the problem itself.
But next month all that is supposed to change with ATSAP…
The problem is regardless of where the safety recommendations come from, the FAA will simply ignore the problems they don’t want to fix or otherwise address, just like they always have. ATSAP won’t fix that “cultural” mindset within the FAA.
A few weeks ago our facility made some significant changes to procedures we use to pass altitude information assigned to aircraft between adjacent facilities.
Our data block on the radar scope (data tag associated with an aircraft) contains the aircraft call sign, altitude information, airspeed and a computer generated ID number. It can also contain a “fourth-line” of data which is text data that can indicate assigned airspeeds, headings, or other information pertaining to the aircraft.
The altitude information includes both the mode C altitude (actual altitude) of the aircraft obtained from the aircraft’s transponder, and the air traffic assigned altitude for the aircraft. If the aircraft is at the assigned altitude, then the altitude is a single number.
If the actual altitude is different from the assigned altitude (the aircraft is climbing or descending to the assigned altitude) there are two numbers in the data block corresponding to both the actual altitude, and the assigned altitude.
And the altitude the aircraft has been assigned/cleared to can be represented by the controller in one of two different ways. There is an assigned altitude function/entry, and an interim altitude function/entry. Both represent the altitude assigned to the aircraft but have slightly different uses.
According to the 7110.65:
5-14-3. COMPUTER ENTRY OF ASSIGNED ALTITUDE
The data block shall always reflect the current status of the aircraft unless otherwise specified in a facility directive. Whenever an aircraft is cleared to maintain an altitude different from that in the flight plan database, enter into the computer one of the following:
A facility directive may be published deleting the interim altitude computer entry requirements of subpara b. The directive would apply to those conditions where heavy traffic or sector complexity preclude meeting these entry requirements.
FAAO JO 7210.3, Para 8-2-7, Waiver to Interim Altitude Requirements.
a. The new assigned altitude if the aircraft will (climb or descend to and) maintain the new altitude, or
b. An interim altitude if the aircraft will (climb or descend to and) maintain the new altitude for a short period of time and subsequently be recleared to the altitude in the flight plan database or a new altitude or a new interim altitude.
Use of the interim altitude function will ensure that the data block reflects the actual status of the aircraft and eliminate superfluous altitude updates.
So the interim altitude entry is made for aircraft that are assigned an altitude for a “short period of time.” Otherwise the assigned altitude entry is used/made.
Additionally, before that they added a rule (the “data block coordination rule”) where if a controller accepted an automated handoff from another controller, it was approval for the aircraft to climb to the altitude shown in the data block without further coordination. Before that controllers would have to verbally “appreq” or request approval from the next controller to climb an aircraft into the next controller’s airspace.
Now that I’ve explained the difference between interim altitudes and assigned altitudes from an automation/computer perspective, what happened is that a few weeks ago our facility started using interim altitudes between different facilities. Previously this function was restricted to use within our facility and shut off/tied off between different facilities.
The problem is that there are limitations on when and how the different facilities’ HOST computers transfer that data to each other. With assigned altitude and route data, if one computer fails to transfer that information successfully to the next facility’s computer, the controller receives a UTM (Unsuccessful Transmission Message) from the computer that mandates the controller call the next controller and verbally ensure that the receiving controller’s flight plan information is correct.
There is no such computer warning if an interim altitude (or the removal of an interim altitude) fails to pass to the next controller. In fact, there is no indication whatsoever on either end that the information is erroneous.
So the situation is that when using interim altitudes, during a handoff (computer transfer of a data block) the transferring controller’s data block may have one altitude in it, and the receiving controller’s data block might have a different altitude in it. Yet the other rule says that by taking the handoff the receiving controller has approved a climb to the altitude reflected in the data block.
That in spite of the fact that the information might not be the same as the transferring controller has in his data block!
In other words, the transferring controller will believe the receiving controller has implicitly approved a climb to the altitude reflected in his data block, when in fact the receiving controller has a different altitude in his data block and believes he is approving a climb to that altitude.
Both controllers believe different things because they’re looking at different altitude data in the data block.
Sound safe to you?
So I went to talk to the office (Requirements, Airspace and Procedures) that came up with these procedures the week they instituted them to express my concerns about this potentially unsafe procedure. (Remember, I’m the thorn in their sides.)
It turns out they decided to “interpret” a paragraph in the 7110.65 to mean something other than what it says so that they could transfer responsibility for this computer problem/questionable procedure to the controllers.
7110.65 Paragraph 5-4-5b states (my emphasis):
Verbally obtain the receiving controller’s approval prior to making any changes to an aircraft’s flight path, altitude, or data block information while the handoff is being initiated or after acceptance, unless otherwise specified by a LOA or a facility directive.
But the way they interpreted this paragraph in a document titled, “FAQS – DATA BLOCK COORDINATION” is (my emphasis):
“Once you start a handoff (or the computer auto flashes a data block), you cannot change the altitude or anything else in the data block without coordination.”
Now call me crazy, but I’m pretty sure the words “while” and “after” have totally different meanings if you look in the dictionary. The 7110.65 says “while the handoff is being initiated” but the interpretation is anytime “after” the handoff is initiated the first time.
Once a computer handoff is started, it can be stopped (taken back), changes made; then started again. To me and my fellow controllers, “while” means during the time the handoff is actually flashing at the next controller; if the handoff is stopped, it’s no longer “while” since there is no handoff occurring at all.
The new interpretation also means we’ve been doing this wrong within our facility for as long as I can remember. So by “fixing” the automation problem with interim altitudes, they now invalidate how we use the same procedure elsewhere within our facility.
Well, it’s no surprise that they admitted that this “interpretation” is specifically designed to prevent the interim altitude information from not transferring properly to the controller in the next facility. It’s a typical FAA “workaround” procedure; ignore the root of the problem.
They also admitted that the change was in preparation for the new computer software/system being developed called ERAM, which handles the transfer of altitude data between facilities completely differently than our current HOST computer system (and which is probably some time away from being deployed due to the many software bugs within ERAM).
So there is a known automation/computer shortcoming that doesn’t allow for computerized notification should both controllers have different altitude information, and the FAA’s fix is to simply interpret an order and dump the problem onto the controller. Forget about changing the computer program, or shutting this function off altogether (or not even starting it for that matter).
Part of the problem within the FAA is that controllers make these (and other bad) procedures work, in spite of the fact that they either don’t make sense, or are downright dangerous. I’m as guilty of it as the next guy.
Controllers know what’s important and they’ll do everything they can to keep the airplanes apart, in spite of the bad procedures and equipment they”re forced to work with. It’s ultimately easier to just do that than contest the FAA’s bad policies.
And controllers try to make the best of it and provide safety and the best service they can to the users in spite of the aged or faulty equipment and errant policies and direction. I’ve always asserted that the air traffic system works in spite of FAA management; not because of it.
But by “cheating”, not only do controllers put themselves at additional risk (if something goes wrong and the controller didn’t follow the orders and procedures, he’s going to fry for it), but we also degrade the extra margins of safety that are supposed to be part of the air traffic system. Shave those safety margins down, and it doesn’t take as much for something to go bad.
Tolerating and working around bad FAA policies and procedures ultimately doesn’t do favors to anyone involved (but it’s definitely easier). And that’s the real “safety (sub)culture” in the FAA: safety is always the controllers’ problem in spite of everything else within the system.
Managers in the FAA have no problem instituting policies they know are flawed, because they know controllers will likely work around them and make the system work regardless (as best they can). Those managers know that the only real accountability in the FAA is with air traffic controllers. They get to pawn off their bad policies on someone else and blame them when things go awry.
Controllers all accept that; that responsibility is part of our job: being willing to make real-time decisions that have the potential to do serious harm to people and/or property.
But it all ultimately shows that the leadership/management within the FAA doesn’t choose to do the right thing in regard to safety, in spite of what they say. Their actions always speak louder than words.
Rolling the dice while telling the public how safe the aviation system is the current “safety culture” within FAA management.
After the ATSAP briefing I raised my concerns with the QA manager since I had made no progress with the originators of the procedure. I mistakenly believed that he might have some influence in the situation, but in the last few years Quality Assurance doesn’t seem to have much influence or involvement in “assuring quality”; I’m not sure what their function of late is.
Not that it’s any surprise that the office tasked with assuring quality within the FAA does nothing of the sort. But it gives the public the appearance that the FAA is committed to assuring quality, not unlike the FAA’s other alleged safety commitments.
The QA Manager told me I needed to talk to that same office again, which I did without success. All they did was defend their dangerous procedure.
Currently the only formal safety documentation/reporting system within the FAA is the Unsatisfactory Condition Report (UCR). In the instructions on the back of the UCR form it says:
“The Unsatisfactory Condition Report (UCR) System is open to all employees of the FAA, and provides the employee a direct means of communicating to top management conditions or practices which, in his judgement, are hazardous, ineffective, or inefficient.”
So I’ve filed a UCR form with the FAA on the interim altitude automation shortcoming, but in the last few years every single one of the UCRs I filed was returned to me marked as “not a UCR-able item”. There is no evidence that the FAA even investigated many of them.
Coincidentally the office that now responds to almost all (if not all) of the UCRs is the same office that comes up with the interpretations/procedures to begin with; the same office I was talking to (the Requirements, Airspace and Procedures office). So what do you think the odds are that they would ever admit a procedure they instigated was inefficient or dangerous?
This is a blatant conflict of interest when it comes to safety concerns and a deliberate/conscious decision by the FAA within the last few years to “streamline” air traffic operations policy creation. Now there is no office within the FAA that oversees/audits the office that creates and interprets policies to ensure the policies that office creates are safe.
Controllers would be more than happy to work for an organization that had a “safety culture”. It would make their jobs easier and absolve them of some of the responsibility they currently shoulder for making the system safe. But a “safety culture” system would make management more accountable for safety within the system, and none of them are interested in that at all.
So call me skeptical. I don’t see ATSAP changing anything.
From what I’ve seen those in FAA management aren’t really interested in a “safety culture” at all, but they sure like how it looks and sounds to the flying public. Another program to make it look like they really care.
I said it before; I’ll say it again. Talk is cheap. And it’s going to take more than an ATSAP program to make the FAA into a “safety culture”, and that change needs to take place from the top down.
And the FAA’s attitude towards safety (or rather covering up and ignoring safety issues) has a long and storied history.