JO 7210.55G Operational Data Reporting Requirements

06/01/17 JO 7210.55G 7. General.

a. OPSNET includes daily delay reporting, as well as airport traffic counts and instrument operations.

b. Facilities must submit daily OPSNET reports for a 24-hour period or the operational period if less than 24 hours. Facilities must transmit daily OPSNET reports by 0200 local of the following reporting day. Each OPSNET report must cover the preceding 24 hours or operational period. The standard 24-hour time period is from 0000 (midnight) local to 2359 local; however, ATO service centers may approve a different standard start and stop time to facilitate local staffing. In such cases, this time may be no earlier than 2200 local and no later than 0000 local for facilities open 24 hours, or no earlier than 30 minutes before closure for facilities that operate less than 24 hours.

c. All delay times are recorded in OPSNET as coordinated universal time (UTC).

8. System Description. There are four types of OPSNET activities: a. Data entry. ATC facilities, except FSSs, record and transmit traffic count and air traffic delay data to OPSNET daily.

b. Data processing and storing. The TFMS Production Center personnel process the data from facilities and store them in the OPSNET database.

c. Report preparation and distribution. The ATO System Operations Services, Office of Performance Analysis personnel produce reports on NAS performance. These reports are distributed electronically to headquarters managers and are available for facilities to retrieve electronically from https://aspm.faa.gov .

d. Data use. Headquarters personnel, ATO service center offices, and ATC facilities analyze the OPSNET data to determine ways to improve NAS performance.

9. Responsibilities .

a. The Office of Performance Analysis personnel are responsible for: (1) Oversight of OPSNET reporting and policies.

(2) Providing support which will enable facilities to meet the OPSNET reporting requirements.

(3) Establishing and amending, as necessary, OPSNET submission and transmission times.

(4) Providing quality assurance by contacting facilities when no data have been received or contacting ATO service centers to clarify or amend data.

(5) Analyzing OPSNET data for trends in system performance.

(6) Responding to congressionally-mandated reporting requirements using OPSNET data to produce and distribute reports internally that analyze the performance of the ATO service

06/01/17 center’s ATC facilities.

b. ATO Service Centers are responsible for: (1) Providing quality assurance by ensuring that facilities meet OPSNET reporting responsibilities, report data accurately, and amend reports as necessary.

(2) Providing facilities with guidance and assistance in meeting reporting requirements.

(3) Designating one person and an alternate at each OPSNET reporting facility as having the overall responsibility for meeting OPSNET requirements.

c. ATC reporting facilities are responsible for: (1) Recording and reporting the facility’s daily data in the OPSNET system.

(2) Providing a copy of the OPSNET data to the Office of Performance Analysis contact by facsimile or telephone if an automated connection cannot be completed.

(3) Providing an explanation to the OPSNET ATO service center contact, as requested, by close of business the next administrative day for the inability to report by the designated time.

(4) Submitting recommended changes to OPSNET through their ATO service center for submission to the Office of Performance Analysis.

(5) Editing and amending, as necessary, previously submitted reports.

d. TFMS Production Center (TPC) is responsible for: (1) Maintaining the official OPSNET database.

(2) Maintaining an OPSNET hotline, through the Program Office, designed to provide OPSNET support and instruction to facilities by telephone.

(3) Making OPSNET data available electronically to other FAA programs, as appropriate.

(4) Producing and distributing daily and monthly reports.

10. Procedures.

a. Reporting traffic/operations counts and delays. OPSNET is the official data reporting system for the FAA.

b. Submitting traffic/operations counts.

(1) All air traffic facilities, except FSSs, must report daily traffic information through OPSNET following FAA Order JO 7210.3.

c. Submitting delay reports.

06/01/17 JO 7210.55G (1) All air traffic facilities, except FSSs, must submit OPSNET delay reports daily.

(2) Reportable delays. Delays to instrument flight rules (IFR) traffic of 15 minutes or more, which result from the ATC system detaining an aircraft at the gate, short of the runway, on the runway, on a taxiway, or in a holding configuration anywhere en route must be reported.

The IFR controlling facility must ensure delay reports are received and entered into OPSNET.

(3) Non reportable delays. These are delays which are incurred by IFR traffic, but which should not be reported in OPSNET. Non reportable delays are as follows: (a) Delays initiated by the aircraft operator/company. These delays include, but are not limited to, the following: mechanical problems, pilot refusal to depart when weather conditions are below category I/II minima, pilot requests for a nonstandard departure operation, and pilot refusal to accept an available route.

(b) Taxi time spent under the control of non-FAA entities (for example, company/airport ramp towers).

(c) Delays attributed to special traffic management programs.

(d) Delays incurred because of initiatives imposed by non-FAA facilities. Since implementation of AutoOPSNET phase 1 on October 22, 2007, delays resulting from initiatives imposed by non-FAA facilities are no longer reported in OPSNET.

NOTE- All EDCT and GS delays incurred for non-FAA facilities will be retained in the flight schedule analyzer database and available for analysis. Future enhancements to AutoOPSNET will allow for retention of additional TMIs and en route and arrival delays for non-FAA facilities to be used for analysis purposes only.

(4) Record delay entries as follows: (a) Delay start time. The reportable delay starts when an aircraft is delayed 15 minutes or more. For example, an aircraft is at the runway ready to depart at 1500 UTC and is delayed. Fifteen minutes later, that aircraft has reached the reportable delay threshold (1515 UTC); 1500 UTC is entered in OPSNET as the delay start time.

NOTE- In situations where a departing aircraft is delayed before taxiing, facilities should subtract the average taxi time for their airport from the delay start time.

(b) Delay end time. The delay ends when an aircraft with a reportable delay departs the airport. If a delay occurs and the delay has extended beyond midnight local, continue the delay until it terminates. If the report must be completed because of the OPSNET reporting deadline, a corrected report must be submitted the following day.

(c) Aircraft category. The aircraft category—air carrier, air taxi, general aviation, or military—must be designated when entering delay data.

(d) Impacting condition. The impacting condition is the circumstance that causes a reduction in capacity or otherwise restricts the flow of traffic. Such conditions are temporary in 06/01/17 nature and do not include permanent restrictions to capacity such as ATC separation standards.

(e) TMI. The delay must be identified as a TMI if it is a result of national or local traffic management imposed restrictions. Such initiatives include departure spacing (DSP), en route spacing (ESP), arrival spacing (ASP), miles-in-trail (MIT), minutes-in-trail (MINIT), severe weather avoidance plan (SWAP), Departure Stop, and Metering.

(f) Individual/group delays.

(i) Individual delays. Delays may be entered individually by aircraft identification. When delays are entered individually, the software will automatically calculate the delay time. This method is preferred in that it gives more detailed data for later analysis.

(ii) Group delays. Delays may be entered and grouped by either destination or departure airport. Groups must be consistent by aircraft category and impacting condition. If delays are entered as groups, the delay time must be manually calculated and entered. After 15 minutes without delays attributed to the group, the group must be concluded.

(g) Charge to. TMI delays must be charged to the facility that bears the originating cause of the delay. The facility may be an airport, terminal radar approach control, or en route center and is identified by the facility's official three-character identifier. For example, if a departure delay is incurred because of an MIT restriction due to sector volume within Kansas City Air Route Traffic Control Center (ZKC), then ZKC is to be entered into the "Charge to" field.

(h) Aircraft delay type. Effective October 1, 2008, facilities can only report departure delays. Departure delays occur when an aircraft is delayed at the origination airport before departure, regardless of where the impacting condition originates.

(i) Remarks. The “Remarks” field should be used when additional comments would be helpful to explain the conditions or causes associated with the delay. The “Remarks” field becomes mandatory when "other" is selected as an impacting condition.

d. Amended delay reports. When necessary, submit an amended delay report. Personnel from the Office of Performance Analysis review OPSNET data daily. Facilities may be contacted by their ATO service center contact for discrepancies or for verification purposes. When corrections are believed necessary, they must be entered in the OPSNET system by the 15th day of the following reporting month. For detailed instructions, refer to the OPSNET User’s Guide found at the following link: http://opsnetweb.atcscc.faa.gov/opsnet/jsp/login.jsp or contact the TPC Helpdesk for assistance.

e. How to determine a reportable departure delay.

(1) Aircraft not included in a GDP, AFP, or GS. Start the clock when the aircraft enters FAA jurisdiction (calls ready); stop the clock on takeoff. Subtract normal taxi time for the runway configuration in use. If the result is 15 minutes or more, a reportable delay has occurred. The number of minutes an aircraft is held by ATC (for example, gate hold, interim taxi hold, departure sequencing, etc.) is factored into the delay calculation. Each facility must determine how to calculate accurate ATC hold times based on procedures used at that facility. The calculated time is the number of minutes between when the aircraft enters FAA jurisdiction and the actual departure time.

06/01/17 JO 7210.55G EXAMPLE- Aircraft calls ready, but is held at the gate because of DSP 2000 UTC Aircraft began taxiing 2020 UTC Takeoff time 2030 UTC Normal taxi time 5 minutes (example) Minutes of delay 25 minutes NOTE- Facilities may determine normal ramp times for aircraft that push back on non-FAA controlled ramps. The ramp time should not be calculated as part of an ATC-imposed delay.

(2) Aircraft included in a GDP, AFP, or GS. The ATCSCC will be the reporting facility for aircraft delayed in a GDP, AFP, or GS. These delays will be reported and entered in OPSNET through automation.

f. Determining the impacting condition. Whenever there is a constraint to the flow of traffic, whether at an airport or within an en route facility, the cause of the constraint is referred to as an impacting condition. An impacting condition must be identified for each delay reported through the OPSNET system. The OPSNET software has been developed to automatically route each impacting condition to one of five output categories: weather, equipment, runway/taxiway, volume, or other.

These five categories are for end use only, and are not part of the delay reporting or input process.

It is the responsibility of the facility experiencing an adverse condition or imposing a restriction that impedes the flow of traffic to notify the ATCSCC and adjacent facilities of the cause.

Below is a list of impacting conditions available when entering delays into OPSNET. For information purposes, the list is grouped by the output categories, although in OPSNET it appears in alphabetical order.

(1) Weather. The presence of adverse weather such as: (a) Fog.

(b) Lightning strike.

(c) Low ceilings. Cloud conditions—at or below takeoff, landing, or visual flight rules (VFR) requirements—which adversely affect operations.

(d) Low visibility. Reduced visibility—at or below takeoff, landing, or VFR requirements—which adversely affect operations.

(e) Poor or nil braking action.

(f) Rain. The presence of rain affecting the operating condition of the runways/taxiways.

(g) Runway treatment. Snow/ice removal operations or treatment to the runways/taxiways to prevent snow and ice buildup.

(h) Snow/ice. The presence of snow or ice affecting the operating condition of the runways/taxiways, or otherwise impacting operations at the airport or en route.

(i) Thunderstorms. The presence or direct consequence of a thunderstorm.

06/01/17 (j) Tornado/hurricane. The presence or direct consequence of a tornado or hurricane.

(k) Wind. Wind that causes less than an optimum runway configuration, wind shear, or other adverse condition.

(2) Equipment.

(a) FAA. An equipment failure or outage, which causes a reduced capacity at the facility, whether at an airport or en route. This refers to FAA-owned and maintained NAS equipment only.

(b) Non-FAA. A failure or outage related to equipment owned by entities other than the FAA. This would include foreign, state, municipal, or military-owned and maintained equipment.

NOTE- If the equipment failure or outage is the result of a weather event, such as a lightning strike, the impacting condition should be identified as the weather event (for example, lightning strike).

(3) Runway/taxiway. A reduction in facility capacity because of runway/taxiway limits.

(a) Noise abatement. Reduced capacity because of procedures restricting use of certain runways/routes during specified hours in an attempt to reduce noise in communities near airports.

(b) Runway change - operational advantage. In a multiple airport terminal area, less than optimum capacity caused by a runway configuration change that will allow for increased airport capacity at secondary airports.

(c) Runway change - operational necessity. A condition whereby less than an optimum runway configuration is required for overall traffic flow benefits to neighboring facilities.

(d) Runway construction.

(e) Runway maintenance.

(f) Runway obstruction.

(g) Disabled aircraft. Disabled aircraft impeding the optimal use of runways/taxiways.

NOTE- When runway changes are a result of weather conditions or equipment failures/outages, the associated impacting condition should be identified as the weather condition or equipment failure/outage, rather than runway change.

(4) Volume. Delays must only be reported as volume when the airport is in its optimum configuration and no impacting conditions have been reported when the delays were incurred.

(a) Compacted demand.

(b) Multi-taxi. Congestion caused by many aircraft trying to taxi at once.

06/01/17 JO 7210.55G NOTE- Before October 1, 2008, multi-taxi delays were categorized as runway/taxiway delays. This should be considered when using the OPSNET data for analysis purposes.

(c) Volume.

(5) Other. Includes all impacting conditions that are not otherwise attributed to weather, equipment, runway/taxiway, or volume.

(a) Airshow.

(b) Aircraft emergency.

(c) Aircraft radio.

(d) Aircraft stuck mike.

(e) Bird strike.

(f) Bomb threat.

(g) External radio frequency interference.

(h) Fire.

(i) Flight check.

(j) Military operations.

(k) Non radar procedures.

(l) Precision runway monitor (PRM) non-equipage. Facilities which use PRM procedures may incur airborne arrival delays for aircraft that are not suitably equipped to accept PRM services.

(m) Aircraft/pilot unable to perform land and hold short operations (LAHSO).

NOTE- When the airport cannot support LAHSO because of any weather condition, the associated impacting condition should be identified as the weather condition.

(n) Security. This would include delays attributed to preserving safe air travel.

(o) Very important person movement.

(p) Line up and wait.

(q) Other. This is a "catch all" heading and must be used only when the impacting condition does not fall into any of the other categories. When this is selected, an explanatory comment must be entered in the remarks section.

(6) Multiple impacting conditions. There are times when a delay can be associated with more than one impacting condition. At such times, the original cause of the delay should initially be selected as the impacting condition. The remarks section should be used to further define the multiple causes.

(a) As an example, assume the instrument landing system at an airport is out of service and local weather is IFR. Each situation independently would cause a reduction in capacity,

06/01/17 JO 7210.55G but neither on its own would create a need for initiatives or cause delays. However, together, the two events result in reportable delays. In this case, either equipment or weather should be identified as the impacting condition, the remarks section should be used to identify the secondary condition.

(b) If an aircraft controlled by a GDP is delayed beyond EDCT or GDP cancellation time, the additional delay is not reportable by field facilities. The delay will be reported by the ATCSCC through AutoOPSNET with an impacting condition of TMI/EDCT. The same would apply in an AFP/GS situation.

g. Identifying TMI delays. Once the impacting condition has been identified, it must be determined if the delay was a result of a TMI. When so determined, the type of TMI must be identified. TMI delays must be charged to the airport or facility where the restriction to the traffic flow originates. The following is a list of TMI options available in OPSNET.

(1) DSP. Assigns a departure time to achieve a constant flow of traffic over a common point. Normally, this involves departures from multiple airports.

(2) ESP. Assigns a departure time that will facilitate integration in the en route stream.

(3) ASP. Assigns fix crossing times to aircraft destined to the same airport.

(4) Metering. Assigns a departure time to meet a fix/arc crossing time used to manage airport arrival demand; for example, adjacent center metering or time based metering.

(5) MIT. The number of miles required between aircraft that meet a specific criteria.

The criteria may be separation, airport, fix, altitude, sector, or route specific. MIT are used to apportion traffic into manageable flows, as well as to provide space for additional traffic (merging or departing) to enter the flow of traffic.

(6) MINIT. The number of minutes required between successive aircraft. It is normally used in a nonradar environment, or when transitioning to a nonradar environment or additional spacing is required due to aircraft deviating around weather.

(7) SWAP. A formalized program, of considerable value, in areas which are particularly susceptible to severe weather. SWAP includes coded departure routes, playbook routes, flow evaluation areas/flow constrained areas, capping/tunneling, AFPs, and any other TMIs that are being used to manage airspace constraints due to severe weather.

(8) Departure Stop. Assigns a departure stop for a specific NAS element other than a destination airport, such as an airway, fix, departure gate, or sector.

h. Examples. Several examples of possible delay scenarios have been set forth in appendix A.

11. Related Publications .

a. FAA Order JO 7210.3, Facility Operation and Administration. FAA Order JO 7210.3 provides direction and guidance for the day-to-day operation of facilities, including maintaining statistical data and reports.

b. The Air Traffic OPSNET Data Reporting System User Manual. This user manual also referred to as the OPSNET User's Guide found at the following link: http://opsnet.faa.gov/opsnet/jsp/login.jsp , provides procedures for entering operational data in the OPSNET database using the Internet.

06/01/17 JO 7210.55G

Appendix A. Examples of Possible Delay Scenarios

1. SCENARIO : There has been a radar failure in Albuquerque Air Route Traffic Control Center (ARTCC) (ZAB) impacting the flow of traffic through ZAB23. As a result, ZAB and the David J. Hurley Air Traffic Control System Command Center (ATCSCC) implemented a miles-in-trail (MIT) restriction for Fort Worth ARTCC (ZFW) traffic entering ZAB23. To meet the MIT requirements, ZFW initiates en route spacing (ESP) for its internal departures. An aircraft at Abilene Regional Airport has a proposed time (P-time) of 1815 universal coordinated time (UTC), but is affected by the ESP. As a result, the aircraft is assigned a departure time of 1830 UTC and gets airborne at 1835 UTC. For Air Traffic Operations Network (OPSNET) reporting purposes, this would be a departure delay; the impacting condition would be equipment-FAA; the delay would further be categorized as a traffic management initiative (TMI)/ESP and charged to ZAB.

2. SCENARIO : An aircraft at Phoenix Sky Harbor International Airport (PHX ) has a P-time of 2115 UTC. The aircraft has a maintenance problem and is delayed until the problem can be fixed. The aircraft departs PHX at 2205 UTC. This is not considered a reportable delay as it is not attributable to air traffic control .

3. SCENARIO : There are thunderstorms throughout the Southwest United States impacting flights filed along J29/J101. A departure at George Bush Intercontinental/Houston Airport, originally filed along this route, is being delayed as a result. A reroute is offered to the aircraft, which, if accepted, will let the aircraft get airborne at its original P-time. The aircraft operator declines the reroute, opting instead to take the delay. This is not considered a reportable delay for OPSNET purposes.

4. SCENARIO : There is a ground delay program (GDP) in place for traffic destined to Chicago O’Hare International Airport (ORD). An aircraft departing PHX has an expect departure clearance time (EDCT) of 1850 UTC. Due to MIT restrictions, the aircraft does not depart PHX until 1910 UTC. The excess delay incurred due to the MIT restriction should not be reported. This delay will be reported by the ATCSCC through automation and will include the delay time past the EDCT.

5. SCENARIO : Denver International Airport (DEN) lost runway lights on runway 35L. As a result, the ATCSCC needed to implement a second tier ground stop (GS) for DEN. Several flights departing ORD were delayed 15 minutes or more. These delays will be reported by the ATCSCC through automation.

6. SCENARIO : There are thunderstorms throughout Washington ARTCC (ZDC) airspace and various initiatives are in place to manage the flow of traffic through the area. Several airborne aircraft destined to Ronald Reagan Washington National Airport are held for more than 15 minutes by Boston ARTCC. These delays will be reported by the ATCSCC through automation.

7. SCENARIO : Atlanta Terminal Radar Approach Control (TRACON) incurs a frequency outage and subsequently requests Atlanta Tower to stop all departures. After 10 minutes, the frequency is returned to service; however, due to the number of flights waiting to depart, several aircraft incur departure delays of 15 minutes or more. Departure delays for these flights should be reported as TMI type Departure Stop, excluding all flights that have an EDCT or are captured in a GS for a destination airport. Flights controlled by a GDP/airspace flow program (AFP) or GS will be reported by the ATCSCC through automation 8. SCENARIO : Thunderstorms in Indiana ARTCC (ZID) and ZDC airspace are impacting flights on J134 and J6. Due to numerous weather deviations, ZID advises they can no longer take traffic on J6 or J134. ZDC requests Potomac TRACON to stop all departures on J6 and J134.

Departure delays for these flights should be reported as TMI type Departure Stop, excluding all flights that have an EDCT or are captured in a GS for a destination airport. Flights controlled by a GDP/AFP or GS will be reported by the ATCSCC through automation.

A-1