Ignoring the Rules

With the arrival of summer and convective weather air traffic controllers have to separate aircraft in the chaos resulting from aircraft deviating around weather.

Normally aircraft are all on filed routes, so controllers know exactly where they’re going. They keep the airplanes apart based on those routings.

Once aircraft start turning off course to avoid cells of weather, the controllers’ task of keeping all the airplanes apart becomes much more complex. When aircraft are deviating for weather controllers no longer know exactly where the aircraft are going. Pilot requests to deviate and for turbulence reports also increase the controllers’ workload dramatically.

A sector that can handle a certain number of aircraft safely and efficiently under normal conditions can only handle a fraction of the aircraft safely and efficiently if they’re deviating around weather because of the added workload and complexity that occurs.

Since it’s important that air traffic flow efficiently (and safely) through the sectors, the FAA has orders regarding sector loading and efficiency that are contained in its Facility Operations Manual 7210.3. (Note: Even though I intertwine efficiency and safety because an efficient sector is a safe sector, for the record FAA managers claim there’s no correlation between the two.)

The enroute centers’ respective Traffic Management Units (TMU, overseen by the Air Traffic System Central Command Center, ATCSCC) are tasked with monitoring monitor traffic flow in sectors and ensuring that traffic flows smoothly.

One of TMU’s tasks, as outlined in the 7210.3, is to oversee the Monitor Alert Program (MAP). As stated in that order:

Section 7. Monitor Alert Parameter
17-7-1.PURPOSE

The Monitor Alert Parameter (MAP) establishes a numerical trigger value to provide notification to facility personnel, through the MA function of the ETMS, that sector /airport efficiency may be degraded during specific periods of time. The efficiency of a functional position or airport in providing air traffic services is a shared responsibility of the TM team. That team consists of the ATCS(s), OS(s), and the TMU. These entities must monitor, assess and act on sector/airport loading issues to ensure that these NAS elements operate efficiently.

As specified in the same order, each enroute air traffic sector is assigned a numerical value that denotes the total number of aircraft it can work efficiently. In the event traffic is predicted to approach or exceed that number, the order also specifies what action is supposed to be taken.

Our Front Line Managers (FLMs) monitor the MAP number continuously in the operational areas as well.

One of the many problems with the program is according to the order, the “TM team” is supposed to include the OS (Operations Supervisor), the TMU (Traffic Managment Unit) and the ATCS(s) (Air Traffic Control Specialists). However, controllers are never briefed on the 7210.3; don’t read it; and most don’t generally even know the details of that particular order.

However, the order reads: “These entities must monitor, assess and act on sector/airport loading issues to ensure that these NAS elements operate efficiently.” And who better to know the efficiency of a given sector at any point in time than the air traffic controller working it?

Unfortunately, at least at my facility, the ATCS(s) are effectively left out of the equation when it comes to the Monitor Alert.

If a sector goes “red”, or exceeds its efficient traffic loading index, the order also specifies what’s supposed to happen, albeit vaguely. It says:

2. For red alerts – notify the affected area of the alert, indicating the expected impact and recommended action.
3. For yellow alerts – notify the affected area of the alert when analysis indicates that the ability of the sector to provide efficient air traffic services will be degraded due to abnormal operations.

What happens at my facility is that TMU calls the area supervisor and simply notifies them of the alert. As far as I know they rarely if ever recommend any action.

In response to the notification sometimes the supervisor tells the controllers in the sector they’re going to get busy, or assigns additional controllers to work the sector, but rarely is anything else done. If the MAP number exceeds the sector MAP by a large margin, or if the supervisor tells the controller and the controller objects strongly enough they may reroute some aircraft around the busy sector. And then again they may not…

I would think it’s implied that some action would be taken when sectors went red or exceeded their peak efficiency volume, but TMU and FAA managers treat the Monitor Alert as mostly just an advisory program. The order does say if a sector routinely goes red they’re supposed to examine what is causing that, but on a daily basis TMU and the FAA just treat it as an informational: i.e. “Just FYI, you’re going to get busy.”

So it’s not as if anyone is actually going to take any action when traffic exceeds the number a sector can work efficiently, as per the order, but it’s supposed to be noted (and logged) at the very least.

The reason I bring this all up now is because when it comes to summer weather and deviating air traffic, the Monitor Alert Order says (my emphasis):

The ability of a functional position or airport to provide air traffic services may be affected by a variety of factors (i.e., NAVAIDs, meteorological conditions, communications capabilities, etc.); therefore MAP is a dynamic value which will be adjusted to reflect the capabilities of the functional position or airport.

and

The MAP value will be dynamically adjusted to reflect the ability of the functional position to provide air traffic service . During periods of reduced efficiency the MAP will be dynamically adjusted downward and conversely, when efficiency is improved, the MAP will be adjusted upward, but not to exceed the baseline or documented, adjusted value.

So based on that order, it’s pretty clear that when sectors have weather and deviating aircraft, the sector efficiency is reduced and the Monitor Alert number is supposed to be adjusted downwards to reflect that fact.

Note that the 7210.3 isn’t a “suggestion” manual. It contains orders. That would make one believe that it’s not optional, but mandatory. It’s an order after all.

However, the FAA ignores that part of the Monitor Alert Order.

The FAA is quick to tell anyone who points out to them that they’re ignoring this part of the order that the Monitor Alert Order only concerns sector efficiency; not sector safety.

However, any controller will tell you that working too many airplanes at one time reduces the margins of safety; work too many airplanes and efficiency drops, as well as the controllers ability to work those airplanes safely. There is only so much a controller can watch.

The National Transportation Safety Board (NTSB) agreed when they issued this Safety Recommendation A00_23-27 dated April 7, 2000, concerning a day when several operational errors occurred on a day there was weather impacting sectors in Cleveland Center. They ignored the Monitor Alert Order then and many sectors got overloaded and resulted in several airplanes getting too close together.

At the time of the incident, the sector’s ability to handle traffic was degraded by weather and holding aircraft; therefore, the MAP should have been reduced to a number (significantly lower than 18) determined on the basis of these conditions, but it was not.

So the FAA has been ignoring that part of the Monitor Alert Order for over ten years!

At that time no Monitor Alert occurred at all, but even though alerts are generated now a vast number of them are simply ignored.

Additionally the report states (my emphasis):

The Safety Board’s investigation revealed that the Cleveland ARTCC has no procedure to ensure the necessary adjustment of sector MAP numbers; this lack of procedure degrades the system’s ability to issue appropriate monitor alert warnings. During visits to other ARTCCs, Board investigators found that other traffic management units also did not adjust MAPs as required. Therefore, the Safety Board believes that the FAA should direct ATC facilities using ETMS monitor alert software to establish procedures to ensure compliance with the dynamic MAP adjustment requirements contained in FAA Order 7210.3, “Facility Operation and Administration.”

Ten years ago and the FAA is still ignoring its own orders, in spite of the fact that the NTSB called them out on it.

Remember when I mentioned earlier that FAA management states time and time again that the Monitor Alert Order concerns sector efficiency and not safety?

“the sector’s ability to handle traffic was degraded…”

The NTSB made a direct correlation between the MAP number being exceeded and getting aircraft too close together. It’s simple math, but apparently the FAA can’t (or chooses not to) count.

The excessive traffic level in the Bradford sector was discovered only as a consequence of the subsequent operational error investigations and would possibly not have been discovered or received management attention if the error had not occurred. The FAA appears to have no formal process for the identification and investigation of situations in which a sector is subjected to excessive traffic demand when no otherwise reportable event takes place.

See no evil, hear no evil I guess…

The reality is that during the summer especially, when there is weather affecting sectors, the Monitor Alert Program isn’t implemented according to the FAA’s own orders in the 7210.3. But that’s OK apparently because we haven’t killed anyone ignoring that particular order.

Yet.

The Tombstone Agency strikes again…

But it’s all fine with FAA management because they know full well that if something goes wrong they can (and will) simply blame it all on the controller(s) in the sector.

Here’s a response to a Unsatisfactory Condition Report (UCR)/safety report filed in my facility on a sector that went red on an overnight shift (a midshift) without any action taken to alleviate the amount of traffic in the sector at the time (my emphasis again):

UCR #521725, filed on May 3, 2006, alleges that FAA Management:

• Failed to provide adequate staffing on the mid-shift
• The Monitor Alert Program (MAP) displayed a yellow and then, a red alert status. The OMIC’s attempt to re-route some flights was not successful because the aircraft re-entered the sector at a later time and distance
• Supervision does not meet the same level as the day shifts. (Reference FAA Order 7210.3, section 2-6-2a),
• MAP values were not adjusted as stated in FAA Order 7210.3, section 17-7-1, and
• NTSB recommendations, dated 4/7/00, (A-00-23 through A-00-27), the FAA did not comply with dynamic MAP adjustments or implement a reporting vehicle of sectors that became overloaded.

All the aforementioned issues are subject to management’s interpretation and implementation. This would include the recommendations offered by NTSB. Because the concerns are related to staffing and the interpretation of FAA Orders, including the MAP, these items are not subject to the UCR process. Therefore, “we consider this UCR is closed.”

Amazingly, the above response shows that not only does the FAA choose/”cherry-pick” which orders they actually implement, but in addition they feel free to “interpret” orders and simply ignore NTSB recommendations.

Keep in mind that at the time the above UCR was filed, the UCR program was the only formal safety reporting process within the FAA. And it’s pretty clear that the FAA was more than willing to simply dismiss UCRs (at least when the subject of the UCR highlighted the fact that the FAA was intentionally violating its own orders).

As the response states, the FAA chose to ignore the substance of the safety concerns in the report by simply claiming that the UCR process didn’t cover this sort of problem.

Lest you believe that malarkey, read the first section of the instructions for the UCR form:

2. CONDITIONS TO BE REPORTED. A UCR (FAA Form 1800-1) should be prepared for situations involving safety or efficiency of equipment and operations and when any of the following conditions exist. UCR is not a substitute for an existing report.
a. Situations which may cause or contribute to accidents, incidents, or present a hazard to personnel and equipment.

What the FAA was really saying in the response was: “We can’t and won’t reply substantively to the safety concerns you raised because we were cheating. But we made the rules so we can break the rules. Now go away.”

That’s the real safety culture of FAA management.

Not unlike our managers who chose to ignore the orders regarding the handling of a Northwest flight that lost communications with air traffic control (went NORDO) and overflew its destination aircraft last fall, FAA management obviously believes they’re above the rules (most of which they made), and that allegedly exist to make the air traffic system safe.

But by ignoring their own rules they’re rolling the dice with the safety of the air traffic system.

And the manager that wrote the above response that ignored/dismissed that safety complaint (UCR) four years ago?

He’s now in charge of our entire facility.

Post navigation

One comment

The MAP program is a later version of the 1980″s EnRoute Load Program AKA ELOD. Problem was MAP like ELOD uses a static route not the filed one. So if you are flying from say BOS to LAX MAP puts everyone on the same route. There was suppose to be some route conversion logic put into MAP but the contractor screwed that up. So basically ETMS has no clue what load a sector has at anyone point in time.

We had a basic version of MAP running that used boundary crossing messages and TZ updates to at least attempt to provide somewhat accurate numbers. But since we the FAA wrote the code and it conflicted with the MAP program (Washington)we got investigated for misuse of funds. Even though our charter was to develop and improve EnRoute software. We’re not allowed anymore because it doesn’t generate a performance kickback err, bonus to FAA Washington.

When tracks go FREE from FLAT you guys should be getting double time! Good write up and job well done! Cheer up next summer you’ll be using ERAM without the HOST tools developed over the last 30 year!