Ops Management Meeting

DCIT 26

Ops Management Meeting

August 21, 2013; 8:30 am – 11:30 am

Harris Corp – 600 Maryland Ave., SW Suite 850E

Washington, DC 20024

The following notes and presentations mentioned within can be viewed on the DCIT website under the respective DCIT number at www.faa.gov/go/d-cit. Click on DCIT Meetings and locate the DCIT number, where all DCIT materials will be stored and maintained.

Attendees:

Matt Maki started the Ops Management Working Group discussion with a presentation of MEM/EWR Trials Ops Status. This presentation can be viewed on the DCIT website. www.faa.gov/go/d-cit, under Meetings – DCIT 26.

·  MEM Ops – Continue to work towards September 3rd full ops. The CMO letter is being reviewed and processed, and the plan is to have 777 full ops and MD11s CAF only in MEM until Patch 5 is deployed. (Patch 5 includes fixes to four items: Dual Contacts, Double TO point, No SID, and No Maintain Altitude.)

o  Patch 5 is under development and expected around the end of September. October is the time frame to expect SAT. There will be a training/SAT discussion to schedule these activities.

·  EWR limited trials

o  United confirmed paperwork is issued and they are planning on 4-5 per day ops on Sept 3rd.

o  Scandinavian Air is still standing down due to avionics issue (CLR7 software). Following DM25request, when the first response uplink (e.g. STANDBY) message embeds the acknowledgement for DM25, then the dialogue is wrongly closed by the aircraft. Any subsequent response uplink message (which could be a clearance) will be rejected and an error message “Unrecognized MRN” will be downlinked. The teams are investigating and working towards solutions, as the DCIT team would prefer to keep Scandinavian Air in trials participation.

o  Jerome Condis has an action to determine the solution in an upcoming software release.

§  The DTAP has an ack that is different from the CSP ack. Rob Mead suggests to verify the solution because there is a possibility this solution could cause the same issue. This situation has been seen only on auto standby, but it could possibly happen with CAF, as well.

o  Other possible workarounds – Scandinavian’s Flight Deck to make later DM25 requests to bypass the automatic Standby. This proposed solution has been sent to Scandinavian but we have not received a response.

·  Build 7 – There are still discussions with FAA to determine which of the requirements for Build 7 will be implemented. There are currently 20 requirements, but the FAA is planning to approve only a sub-set of those requirements.

·  Reporting – Rob Mead is working on how reporting be automated, and has requested to formalize this process with Harris and start collecting CPDLC data and automatically produce logs. Will take 4-6 weeks to get the reporting automated once data is turned on and the process should start to provide automatic logs.

·  Questionnaires for Flight Deck, ATC and AOC were originally intended to have crews, AOC, and Controllers complete the questionnaires. The team concluded that it is not realistic to have full participation with questionnaire responses unless there are negative comments. While the team will not rely on the data since it may not be comprehensive, they decided the participation that is submitted could be helpful for determining problems. The DCIT will continue with the questionnaires as planned.

Elvan McMillen presented a report for establishing test interface with AOC to test the new dispatch message and subscriber database. Elvan works on the Data Comm Program and supports the System Engineering group and test. FAA will do extensive integration testing in FY 2014. This is a plan to reduce risk while establishing the interfaces. Elvan’s discussion followed the points in the presentation, and any discussions with the group are captured below. This presentation can be viewed on the DCIT website. www.faa.gov/go/d-cit, under Meetings – DCIT 26.

·  There are two ways for the airline to connect.

o  Today all PDC messages are routed over the CSP. That connection will continue for the Data Comm Program; however, there will need to be some application changes.

o  New interface through the TDLS Information Management System (TIMS)

·  While there are some internal interface changes that will occur internal to the FAA, the testing priority with the operator will be around the message differences between current TDLS and Production DCL system.

·  To prepare the operators, Chris Collings has prepared a guide and associated technical documents for the DCIT Plenary meeting on day two of the DCIT. Chris and the Harris team are also working on obtaining a list of contacts at the airlines to ensure the right people at airlines are aware of the documents. Harris is working with the airlines, as well as with IFCET through the DCIT to ensure timelines and testing coincides.

o  It is encouraged that AOC-TDLS testing be incorporated into operator’s schedule for DCL.

Matt Maki led a discussion about Arrival Processing within DTAP and the current logic. There was a failure in the DTAP discovered in a flight last night into EWR into the FQM3 arrival. This discussion to understand what happened and how DTAP handles situations like this. The Williamsport Three Arrival graph/outline was presented during the discussion. For the chart, please go to http://www.airnav.com/airport/KEWR and scroll down to the STAR section, Williamsport Three.

·  The route that caused the failure was: KMEM CRSON2 HUMMS PXV J29 DORET J584 FQM FQM3 KEWR

·  A 777 received a CAF and WILCO’d. A revision came through, which then caused a failure in DTAP.

·  The Williamsport Three arrival can be executed in two ways: By joining the arrival at a transition point or with no transition where a join is made at Williamsport.

o  Craig Morris explained that the database has been checked and no issues were determined. He also explained the “ALL” set of entries (always executed). In this particular case, the ALL procedure entry is FQM and it proceeded with data associated with different waypoints. The naming conventions are named transitions and valid arrival transition fixes. When a route SLT.FQM3 is filed, the uplink should be a valid uplink with the last route element containing SLT.

o  A route with FQM.FQM3 should have generated an uplink. That is how it is designed to work, but it did not function as expected. The current plan for Build 7 is to be able to generate loadable routes when joining the transitions at named transitions or at base arrival transition fix.

§  There are two potential fixes this – file changes to ensure the transitions work; or fix the DTAP so that it has only one rule. If the rule is entered incorrectly, it simply won’t load.

·  Rob added that any aircraft will have a problem if the transition is not loaded correctly. Some aircraft will give a partial load, and the older aircraft will simply reject.

o  The current rules of the DTAP for all arrival and departure transition fixes will need to be investigated. Rob Mead has been working with on the details for arrival and departure fixes for all possible combinations of filing to determine how it is mapped to be loaded. Through these investigations, requirements were prioritized for a Pre-Build 7.

§  Lockheed Martin and various engineering/operational members who work with the production system discussed this issue. The take-away was to fix the arrival procedure by adding the two requirements. Changes had been made to the ERAM baseline. Due to the late nature and difficulty of the problem, the requirements would be considered for another upgrade. The group recognized the critical nature of having this requirement added to P2, since the routes sent in Enroute will have these issues.

§  The proposed rules for trial and production stated there were two methods to join the Williamsport arrival. The system is confusing elements of the route with the arrival transition, depending on how it is formatted.

·  Rob Mead acknowledged that the discussion was focused on two areas, with Intercepting Arrivals as the topic that was getting the most discussion. He went through an “Intercepting Arrivals and Transitions Part Way In” presentation on the screen and led the discussion for that topic. This presentation can be viewed on the DCIT website. www.faa.gov/go/d-cit, under Meetings – DCIT 26.

o  Craig Morris discussed the transition and arrivals rules that will no longer be added. Making the ground blank is a requirement for the Production System. Without this requirement, the route transition will not be loadable. It will have to be fixed in the aircraft. (Production)

§  File as close to loadable as possible upon filing, and understand that some files will not be loadable despite a clean entry.

§  If the flight crew will need to fix the transition, there will need to be more verification and this should be vetted more thoroughly. The flight crew should not have to fix something that will be a normal everyday operation.

§  Gregg Kastman added that if loading FMC data, it is new and should be entered correctly from the beginning.

·  In addition to the downstream issue, if the system in use will work with known transition fixes only, why can’t the addition of a known transition fix be added? (In reference to FQM and the ALL transition)

·  Craig Morris added that there are thousands of procedures. There would be monumental coding required to make the changes that would be required to change the points.

·  Gregg Kastman presented a UM80 .docx file with photos regarding the filing the new STAR transition and the way discons are processed.

o  Logon and UM80 clearance worked as expected, and clearance printed without errors. The issue was an arrival issue on a UM80 to DARBY4 arrival. The uplink flight plan loaded fine to SEC F-PLN, however DARBY4 arrival did not connect to UNCKL, which is a known name. It seems the problem is not only with the base point, but also with an airway into a STAR. This was a NY Center re-route, which does not recognize the rules).

§  Andy Fry claims this is a known issue that was determined in Long Beach. It was accepted as a normal discontinuity. It is accepted because it can be seen. There is concern about routes in an aircraft that cannot be seen because they can’t see what’s missing.

o  Paul Debenedittis asked about the scope of the problem from a Production DCL perspective. He expressed this will be a big problem in P1 (and trials) if not solved.

§  Build 7 originally had 20 requirements, with this being one of them. Initial proposals were streamlined down from the 20 original to a smaller list of requirements. The DCIT will have to review the refined selection of the requirements and get this back on the list. During this process, the team will need to coordinate a meeting to address the Production requirements.

§  Actions from this discussion – Determine if this requirement should be added back to Build 7, and if Production will reconsider it. If Production does NOT accept it, determine if the all or nothing scenario would be accepted.

§  A decision recap –ERAM is in the process of creating the CPDCL service, while arrival processing requirements will also be ERAM requirements. These two would not be included in the initial release because of the limitations with resources, time and development.

·  This decision will need to be reviewed and discussed again. A working group will write a paper on this issue to be reviewed by the DCIT. The paper will then be routed through the Data Comm Program, primarily Gregg Anderson (Operations) and Kevin Grimm (with Systems Engineering) to evaluate how it impacts the program.

Action - DCIT to determine if the transitions part way in needs to be added back to Build 7.

Action – If transitions part way in is added back in, ask if Production would be reconsidered.

Action – If Production cannot add this, to consider the all or nothing scenario.

Action – The DCIT to create a paper that maps out the impact of always doing a transition vs. never doing a transition.

The group adjourned for lunch and will return for the All-Working Group Meeting.

NEXT DCIT MEETINGS

·  DCIT 27 – September 25-26 at Harris Corp, Washington DC

·  DCIT 28 – October 30-31 at ARINC, Annapolis

·  DCIT 29 – December 4-5 at Harris Corp, Washington DC

·  DCIT 30 – January 29-30 at Harris Corp, Washington DC

Respectfully Submitted,

Tracey Gibson, DCIT Secretariat

Data Communications Program Support

CGH Technologies, Inc.

600 Maryland Ave SW, Suite 800W

Washington, DC 20024

6