Data Communications Implementation Team (DCIT) Departure Clearance Service (DCL) Trials. Phase 1

Transcription

1 Data Communications Implementation Team (DCIT) Departure Clearance Service (DCL) Trials Phase 1 Systems Integration Description Document Version 3.0 August 21, 2014 DCP INTEGRATION PLAN Table of Contents Page 1 of 49

2 DOCUMENT CHANGE HISTORY Revision Author Change Date Change Summary 0.1 DCIT SI work group 02/08/2012 Initial draft 0.2 DCIT SI work group 04/24/2012 Revised draft to include end-to-end system architecture, and system description information 0.3 DCIT SI work group 05/07/2012 Revised draft to include Courtesy Copy material 0.4 DCIT SI work group 05/14/2012 Revised draft to include updated system level threads 0.5 DCIT SI work group 05/30/2012 Revised draft to include protocol stack, TDLS and ERAM description 0.6 DCIT SI work group 06/14/2012 Revised draft to include updated diagrams and text to describe the threads; update to assumptions 0.7 DCIT SI work group 07/11/2012 Revised draft to include updated diagrams and text based on reviews and feedbacks 0.8 DCIT SI work group 08/22/2012 Revised draft to include updated diagrams and text based on reviews and feedbacks 1.0 DCIT SI work group 08/28/ DCIT SI work group 10/16/2012 Revised to include Gate Request message and acknowledgement 1.1 DCIT SI work group 11/7/2012 Revised to include corrections to issues discovered in initial implementation. 1.2 DCIT SI work group 2/21/2013 Revised to include current approach to trials, updates to the CCI and CCR formats, removed Gate request and ack messages. 2 DCIT SI work group 3/19/2013 Final release of version 2 approved by DCIT plenary during DCIT / DCIT SI work group 7/18/2013 Addition of CLIMB VIA SID DCIT SI work group 7/18/2013 Addition of Pilot response dispatch message. DCP INTEGRATION PLAN Table of Contents Page 2 of 49

3 2.4 DCIT SI WG 8/2014 Comments from DCIT SI WG 2.5 DCIT SI WG 9/2014 Comments from DCIT SI WG 2.6 DCIT SI WG 1/3-/2014 Included final comments regarding CLIMB VIA/Pilot response 2.7 DCIT SI WG 7/15/2014 Comments on version DCIT 8/21/2014 Plenary approved release DCP INTEGRATION PLAN 2.4Table of Contents Page 3 of 49

4 Table of Contents 1 INTRODUCTION Scope Applicable Documents 8 2 SYSTEMS INTEGRATION APPROACH Assumptions 10 3 SYSTEM DESCRIPTION Overview Systems Descriptions and Interfaces Overview Data Comm Trials Automation Platform (DTAP) HOST Host ATM Data Distribution System (HADDS) Tower Data Link Services (TDLS) NAS Security Gateway CSP networks Aircraft Airline automation Airline Operations Center (AOC) 16 4 INTEGRATION AND SEQUENCE DATA FLOW Integration Approach Ground-Ground Integration Air-Ground Integration 18 5 End-to-End SEQUENCE DATA FLOW FLIGHT PLAN PRIOR TO DEPARTURE TIME Timeline: Pre-Conditions Logon and Session Establishment Departure Clearance (DCL) Revised Departure Clearance (Revised DCL) Session Termination 25 6 DISPATCH MESSAGE FORMATS 27 DCP INTEGRATION PLAN Table of Contents Page 4 of 49

5 7 TEST PROGRAM DESCRIPTION Approach and Concept Evaluation Approach Performance Thresholds Activities Leading To Test Test Environment Test Location Test and Analysis Tools Test and Evaluation Descriptions DCL Trials End-to-End System Testing Test Approach 47 APPENDIX D - Glossary 48 List of Tables Table 6-1 Initial Dispatch Message (CCI) Message Format Table 6-2 Dispatch Message (CCI&CCR) field descriptions Table 6-3 CLEARED AS FILED USAGE of CCI Table 6-4 ENTIRE ROUTE CLEARANCE USAGE of CCI Table 6-5 Revised Initial CLEARED TO POINT THEN AS FILED USAGE of CCI Table 6-6 Revised Dispatch Message (RC) message format Table 6-7 Non Route Revision Usage of CCR Table 6-8 CLEARED TO usage of CCR Table 6-9 AT position CLEARED usage of CCR Table 6-10 Full route revision usage of CCR Table 6-11 Revised Fields Table 6-12 Dispatch Message Acknowledgement Message Table 6-13 Dispatch Message Acknowledgement Field Descriptions Table 6-14 Dispatch Message Pilot response message Table 6-15 Dispatch Message Pilot response field descriptions List of Figures Figure 3-1 DCL Trials Architecture Figure 3-2 Protocol Stack View Figure 4-1 DCL Trials End-to-End System Test Architecture Figure 4-2 Ground-Ground Integration DCP INTEGRATION PLAN Table of Contents Page 5 of 49

6 Figure 4-3 Air-Ground Integration Figure 5-1 Parameters for FP-to-Logon Correlation Figure 5-2 Time Line: Pre-Conditions Figure 5-3 AFN Logon & Session Establishment Figure 5-4 Departure Clearance- WILCO Figure 5-5 Departure Clearance- STANDBY Figure 5-6 Revised Departure Clearance Figure 5-7 Session Termination Figure 7-1 DCL Trials End-to-End Test Process DCP INTEGRATION PLAN Table of Contents Page 6 of 49

7 1 INTRODUCTION This document describes the systems architecture and integration plan that enable the endto-end system underlying the Data Communications Program (DCP) Departure Clearance (DCL) Trials activities. The DCL Trials support pre-operational demonstrations of key aspects of the tower controller-pilot data link communication (CPDLC) services in field trials. The DCL trials will validate the concept of operation for the delivery of departure clearances and revised departure clearances through advanced automation and CPDLC. The trials will ensure procedures and training plans are appropriate, and will provide airspace users an opportunity to experience the benefits associated with Data Comm services. Operational trials will evaluate requirements in support of the fully-compliant automation system development and deployment. The DCL service provides automated assistance for requesting and delivering initial and revised departure clearances. DCL provides CPDLC messages for the following: Flight plan route, initial and requested altitude and departure frequency. When DCL is provided through the use of CPDLC, this information is exchanged using CPDLC messaging. For the trials, the messages will be selected from those already used in Future Air Navigation Services (FANS) equipped aircraft. The CPDLC message elements are defined in RTCA DO-258A that current FANS avionics already support. The DCL service is designed for use in surface operations and replaces the existing Pre-Departure Clearance (PDC) at trial sites for participating aircraft Scope This document describes the system integration characteristics and the overall end-to-end architecture of the Federal Aviation Administration s (FAA) DCL trials. This document describes the architecture for phase 1 of the DCL trials program. Phase 1 includes Memphis full scale trials and Newark initial trials. Additional features for phase 2 or later phases of the trials program will be covered in future releases of this document or a similar. The overall trials program will take place in the timeframe at various airports including Memphis, and Newark. The primary purpose of the trials is to validate the concept of use associated with delivery of Data Comm services to the tower environment. This document also provides an overall technical approach for integrating the DCL Trials end-to-end system components supportive of the ATS Facilities Notifications (AFN) Logon and DCL service implementation by way of FANS as an air / ground digital communication solution. The DCL Trials will validate the concept of operation for the delivery of departure clearances and revised departure clearances through advanced automation and CPDLC. Systems Integration Description Document INTRODUCTION Page 7 of 49

8 1.2. Applicable Documents The following documents are considered applicable to the integration activities. Some of these documents provide the requirements baseline for the components being integrated while others are provided so their contents can be used as guidelines. Doc ID/Number RTCA DO-258A ARINC SPECIFICATION Document Title Revision Date Originating Organization Interoperability Requirements for ATS Applications Using ARINC 622 Data Communications (FANS 1/A Interop Standard) ATS Data Link Applications over ACARS Air-Ground Network (Supersede s DO-258) 04/07/05 RTCA Rev -4 10/12/01 AEEC/ARINC ARINC SPECIFICATION DATALINK GRIOUND SYSTEM AND INTERFACE SPECIFICATION 6 11/15/07 AEEC NAS-IC RFC 2351 ICAO Doc 9776 ARINC Specification ARINC Specification ARINC Specification RFC 791 Interfaces Between the Enroute Data Distribution System (EDDS), EAS Air Traffic Management (ATM) Data Distribution System (HADDS)/Store And Forward Application (SAFA) & Their Client Applications (Host Version?) Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP Manual on VHF Digital Link (VDL) Mode 2 AIR/GROUND CHARACTER-ORIENTED PROTOCOL SPECIFICATION VHF DIGITAL Link (VDL) MODE 2 IMPLEMENTATION PROVISIONS ATS DATA LINK APPLICATIONS OVER Internet Protocol Specification May 1998 IETF November ICAO /16/06 AEEC 4 8/31/05 AEEC 4 10/12/01 AEEC September 1981 IETF Systems Integration Description Document Applicable Documents Page 8 of 49

9 Doc ID/Number Document Title Revision Date Originating Organization IATA Systems Type B Application to 3.1 January IATA and Communication s Reference, Volume 3, Migration Strategies, Part III Application Protocol (BATAP), 1998 System Segment A June 6, Thales ATM Inc. Specification for DTAP 2012 FAA Data 1.0 April FAA Communications Trials Automation Platform (DTAP) Concept Document 20,2012 NAS-IC HADDS Client ICD C November FAA 25, 2009 DCL End to End Phase 1 v February 7, 2013 DCIT Systems Integration Description Document Applicable Documents Page 9 of 49

10 2 SYSTEMS INTEGRATION APPROACH The DCL Trials system is comprised of a number of major sub-systems, which by way of well-defined standard interfaces, integrate and communicate to form an end-to-end environment providing an infrastructure for the DCL Trials. The system components are described in detail in Section 3. The fully integrated system for the Logon and DCL service will include ground automation platform, the Host ATM (Air Traffic Management) Data Distribution System (HADDS), and the FAA s Telecommunications Infrastructure (FTI) Operational IP (OPS-IP). The HADDS, a flight data system, uses the OPS-IP for network connectivity between facilities and for ground connectivity with the DCL Trials Communications Service Providers (CSPs). The CSPs provide a ground communication routing mechanism and an air / ground network to reach participating DCL trials aircraft. 2.1 Assumptions The assumptions that provide context for the integration approach are included in this section. These assumptions are subject to change, as certain aspects of the system architecture are still being detailed. Any changes that impact the integration approach will be addressed in future revisions of this document. Following are the current assumptions: 1. The trial system will either interface with the Host Computer or En Route Automation Modernization (ERAM) through HADDS o Depends on the trial site and the system operating in the En Route Center that has jurisdiction over the airport 2. PDC capability will be part of the operational environment during the trials for aircraft that are not participating in the trials 3. DTAP platform o The same DTAP baseline will be used at the MEM and EWR phase 1 trial sites. DCP INTEGRATION PLAN SYSTEMS INTEGRATION APPROACH Page 10 of 49

11 3 SYSTEM DESCRIPTION This section provides an overview of the DCL Trials end-to-end system. Figure 3-1 below presents an end-to-end architecture for the DCL Trials system. 3.1 Overview Figure 3-1 DCL Trials Architecture The DCL Trials will validate the concept of operation for the delivery of departure clearances and revised departure clearances through advanced automation and CPDLC. The Data Communications Trials Automation Platform (DTAP) will provide the FAA with the controller user interface, processing and National Airspace System (NAS) connectivity necessary to generate, deliver and track departure clearances utilizing Radio Technical Commission for Aeronautics (RTCA) Special Committee 214 (SC-214) standards to Future Air Navigation Services version 1/A+ (FANS-1/A+) equipped aircraft. The RTCA DO- 258(A) provides the description of operations of FANS equipped aircraft and ground system. The DTAP will be used in operational towers alongside the current Tower Data Link Services (TDLS) platform, to augment rather than replace the current PDC process. DCP INTEGRATION PLAN SYSTEM DESCRIPTION Page 11 of 49

12 The DTAP will provide the FAA with the controller user interface, processing and NAS connectivity necessary to generate, and deliver departure clearances to FANS equipped aircraft. The aircraft operator provides Flight Plan information to the Air Route Traffic Control Center (ARTCC) associated with the departure airport via the ground-to-ground communications system. The ARTCC automation processes the flight plan providing modifications to conform to established routes. The ARTCC transmits the processed flight plan to the Air Traffic Control Tower (ATCT) via ground-to-ground communications. The Flight Crew prepares the aircraft for the flight and activates the data link system, by sending an AFN logon via the CSP Network to the ground system. Ground acceptance of the logon and correlation of the logon information with a flight plan initiates a network connection between the aircraft and ground system. After network connection, the Flight Crew requests a departure clearance from the DCL Service automation. The service responds by transmitting a DCL to the aircraft via the CSP network. DTAP automation creates a DCL by presenting to the controller for review, a proposed DCL that was created using flight data from the ARTCC flight data processing system. The controller may modify the DCL with local data and approves the DCL. After controller approval, DTAP makes the DCL available for a flight crew request. Upon transmission of the corresponding clearance to the aircraft, the automation system forwards a copy of the DCL to the Airline Operations Center (AOC). When changes in tower or en route conditions occur for weather or other reasons, the tower or the ARTCC will amend the clearance information. After amended data is processed, the controller will take action to transmit a revised DCL to the flight crew. 3.2 Systems Descriptions and Interfaces Overview Interface testing will be performed for the DTAP to ensure connectivity and addressing characteristics are met. DTAP system interfaces will be tested to ensure that it can effectively connect and extract information from the NAS. This includes routing and forwarding testing with failover conditional testing. Interface testing will evaluate the DTAP requirements for the Flight Deck Interface through the CSP and the HADDS. Multiple systems will be utilized in the end-to-end environment during the testing at the WJHTC, including the DTAP, the FTI National Test Bed (FNTB), CSP, HADDS, and FANS- 1/A Aircraft Avionics. Communication capabilities will be tested to ensure satisfactory performance across relevant systems as shown in Figure 3-1. DCP INTEGRATION PLAN SYSTEM DESCRIPTION Page 12 of 49

13 3.2.2 Data Comm Trials Automation Platform (DTAP) The DTAP provides Departure Clearance messaging from within the selected tower(s) to participating aircraft. The DTAP interfaces with many other parts of the DCL Trials Architecture. At the physical and network layers the DTAP interfaces with FTI to obtain IP network service. The DTAP interfaces with HADDS and the CSP network(s) using FTI. The DTAP interfaces with HADDS to obtain flight plan information. DTAP uses the flight plan information to aid in its creation and revision of departure clearances. The DTAP interfaces with the CSP network(s) through the FTI National Enterprise Security Gateway (NESG). The DTAP uses the CSP interface to exchange messages with aircraft and airline automation systems. These messages are 620 formatted messages using Type B Application to Application Protocol (BATAP) over Mapping Airline Traffic over IP (MATIP). These 620 messages are received by the CSP network, processed and forwarded to the appropriate next destination. Figure 3-2 below presents the end-to-end protocol stack view of DTAP, CSP and the avionics system. Figure 3-2 Protocol Stack View DCP INTEGRATION PLAN SYSTEM DESCRIPTION Page 13 of 49

14 3.2.3 HOST The Host Computer System is FAA's key information processing system for its 20 en route centers, which control aircraft in transit over continental United States and during approaches to some airports. It processes radar surveillance data and flight plans, links filed flight plans with actual aircraft flight tracks, provides alerts of projected aircraft separation violations, and processes weather data. The Host provides flight plan information for the DTAP (via HADDS) as part of the FAA s DCL Trials Host ATM Data Distribution System (HADDS) The HADDS provides the interface to DTAP for flight plan information as part of the FAA s DCL Trials system. ERAM provides the flight plan data to the DTAP system through the HADDS interface Tower Data Link Services (TDLS) TDLS is included in the trial to provide services to the Controller independent of any additional automation being added for the Trials program. There is no interface between TDLS and new automation system(s). The TDLS system supports tower-to-aoc message exchanges via data link communications. The clearance received from TDLS by AOC is provided to the aircraft. The TDLS system is comprised of three applications; PDC, the Flight Data Input/Output (FDIO) Emulation and Digital Automatic Terminal Information Service (D-ATIS). The PDC application displays clearances received from the ARTCC. The TDLS operator can append information about departing aircraft at the airport and transmit the clearance using a data link to a participating airline/user computer. Users deliver the final clearance directly to equipped aircraft or to a departure gate printer for distribution to the aircraft not equipped with display capability. FDIO Emulation is an application that displays flight plan data, weather information, and general information messages from the ARTCCs. TDLS operators use the application to obtain flight plan information and input, request, and revise flight plan data via the TDLS processor NAS Security Gateway FAA s FTI provides ground to ground network connectivity using an IP backbone between FAA networked systems. The NESG provides a secure interface between the private FAA DCP INTEGRATION PLAN SYSTEM DESCRIPTION Page 14 of 49

15 network and external systems. For the DCL Trials the external system(s) being connected is/are the CSP networks of ARINC and SITA CSP networks The CSP network subsystem(s) provide air/ground connectivity between the FAA s network and aircraft. This connectivity is in the form of ACARS messaging and is used to transport FANS messages. Ground-to-ground messages between the DTAP and the CSP network(s) are defined in DO-258A, ARINC 622 and ARINC 620. Air-to-ground messages between the CSP network(s) and aircraft are defined in DO-258A, ARINC 622, ARINC 631, and ARINC 618. The CSP network interfaces with aircraft at the physical and network levels. The CSP network interfaces with FTI/Security Gateway at the physical and network layers. The CSP network(s) interface with DTAP to exchange inputs destined for both aircraft and airline automation systems and send outputs received from aircraft and/or airline automation systems. The trials program intends to use multiple means to interface to aircraft at the physical level depending upon aircraft configuration and current capability. VHF Digital Link (VDL) Mode 0 ACARS VHF VDL Mode 2 VDL Mode 2 or ACARS over AVLC (AOA) At the network layer the air/ground communications protocol is ACARS (ARINC specification 618). More specifically using messages defined in ARINC 622 and RTCA s DO-258A Aircraft Participating aircraft will have messaging capability to support the DCL trials program s needs. These needs include a Flight Management system (FMS) with FANS communications capability and VHF Digital Link (VDL) (Mode 0 or Mode 2) capable radios and Communications Management Units (CMUs) Airline automation The Airline automation system will receive a separate dispatch message for each departure clearance from the DTAP using an ARINC 620 formatted message. This dispatch message will be a separately created and sent message based upon the contents of the DO- 258(A) formatted message sent to the aircraft and other flight plan information available to DCP INTEGRATION PLAN SYSTEM DESCRIPTION Page 15 of 49

16 the DTAP. The airline automation system must acknowledge the dispatch message with an acknowledgement message. The acknowledgement has a field for gate information for the associated flight that may optionally be filled out by the airline automation Airline Operations Center (AOC) AOCs are responsible for airline operations and related interactions with the FAA. The AOCs communicate with the FAA to ensure that initiation, continuation, diversion or termination of flights for safety and efficiency reasons are also compliant with other regulations with which the airlines need to comply. DCP INTEGRATION PLAN SYSTEM DESCRIPTION Page 16 of 49

17 4 INTEGRATION AND SEQUENCE DATA FLOW 4.1 Integration Approach Technical integration for the DCL Trials system is addressed in two parts: 1) Ground- Ground System Integration, and 2) Air-Ground System Integration. Such integration approaches are further divided into system threads based on major ground-ground and air-ground system components in Section 4.2. The architecture that will be utilized to conduct end-to-end system testing of the DTAP system at the WJHTC in Atlantic City, NJ is depicted below in Figure 4-1. Figure 4-1 DCL Trials End-to-End System Test Architecture Ground-Ground Integration To enable exchange of flight, logon and session information between end system components, the flight data hosted on HADDS, the AFN capability hosted on DTAP, and the CDPLC DCL capability hosted on DTAP will utilize the following integrated elements as a means of ground communications across the interfaces: DTAP AFN Application DTAP CPDLC Application HADDS NESG DCP INTEGRATION PLAN INTEGRATION AND SEQUENCE DATA FLOW Page 17 of 49

18 Figure 4-2 shows the approach for integrating the ground-ground system elements from a system s threads point of view. The focus of this integration step will be on ensuring DTAP is able to receive and process flight data from HADDS, and ensuring that the DTAP can communicate with Front End Processor proxy located in the external DMZ of the NESG Air-Ground Integration Figure 4-2 Ground-Ground Integration To enable exchange of end-to-end AFN logon and CPDLC communication between end system components, the following integrated elements (across the ground-ground and airground interfaces) allow for the end-to-end service for the DCL Trials system: DTAP AFN Application DTAP CPDLC Application HADDS NESG CSP Aircraft AFN Application Aircraft CPDLC Application AOC Figure 4-3 shows the approach for integrating the air-ground system elements from a system s threads point of view. The focus of this integration step will be to ensure that the DCP INTEGRATION PLAN INTEGRATION AND SEQUENCE DATA FLOW Page 18 of 49

19 DTAP Data Comm applications; AFN and CPDLC; can communicate with the Aircraft Data Comm applications; AFN and CPDLC respectively; through the CSP s air/ground network. Figure 4-3 Air-Ground Integration DCP INTEGRATION PLAN INTEGRATION AND SEQUENCE DATA FLOW Page 19 of 49

20 5 End-to-End SEQUENCE DATA FLOW This section identifies the logical sequence of data flows within the end-to-end environment. Such sequences account for the ground-ground and air-ground message flow for end-to-end communications between ATC controller and Pilot. Prior to actual sequence data flows, below you will find relevant information about Flight Plan Prior to Departure Time, Parameters for FP-to-Logon Correlation, and a Timeline: Pre-conditions. The sequence flow diagrams are shown on Figures 5-3, 5-4 and 5-5 respectively. 5.1 FLIGHT PLAN PRIOR TO DEPARTURE TIME The following description provides background on flight plan processing, mostly in advance of the flight plan reaching the DTAP for processing. It is provided for context and introduction to understanding the systems involved in providing the operational context in which the trials are performed. Flight Plans (FPs) are filed by FOC/AOC no later than 45 minutes prior to proposed departure time (P-Time) o Flight plan must have the Flight Identification, the departure airport, and registration number/tail number o For flights that will participate in the DCL trials, airlines will include FRC DCL in the first 22 characters of the Remarks field of the FP o When FPs are received and processed by enroute automation they are assigned Computer Identification (CID) o FPs are distributed to TDLS when the tower strip is printed o Once processed by enroute automation, FPs are distributed to DTAP by HADDS o FOC/AOC will receive a response for filed FPs (Accepted / Rejected ) based on key fields such as Aircraft ID o FPs can be updated or deleted o Flight Plans are either Proposed (Pending) or Active (when aircraft takes off and is detected by the radars) o Multiple proposed FPs per flight can exist; and are resolved by a controller Figure 5-1 below shows the parameters that are used for FP-to-logon correlation. The FP is filed by the AOC/FOC and the logon information is obtained from the aircraft. DCP INTEGRATION PLAN End-to-End SEQUENCE DATA FLOW Page 20 of 49

21 5.2 Timeline: Pre-Conditions Figure 5-1 Parameters for FP-to-Logon Correlation The timeline below shows the sequence of events and the major events that are involved for successful deliverance of departure clearance. In Figure 5-2, the purple bubbles on the right show the major events, the lavender bars are occurrences corresponding to the bubbles, the purple triangles indicate time barriers and the arrows emanating from one occurrence to another show flow of events. Time progression is assumed to be from left to right Dependences are indicated by the curved arrows o For example the first curved arrow starts from the bar that corresponds to the FP is Filed and ends at the bar corresponding to FP is Forwarded to DTAP ; this means the first event is a predecessor for the later event and the second event cannot happen unless the first event occurs The location of the purple bubbles is not indicative of the flow of process flow. The dependencies lines provides context for which events are predicated by other events. DCP INTEGRATION PLAN End-to-End SEQUENCE DATA FLOW Page 21 of 49

22 Figure 5-2 Time Line: Pre-Conditions 5.3 Logon and Session Establishment At the appropriate time, and while still at the gate, the aircrew logs-on to DTAP using the local DTAP Tower address. This can be done any time; however a logon will be rejected unless the aircraft logs on after the airline has filed the FP with the FAA. DTAP will accept valid logons, provided that logon can be correlated with an FP containing the same registration number/tail number and Flight Identification. Once DTAP accepts the logon, it will attempt to establish a CPDLC connection with aircraft. In order for the DCL service to be enabled for an aircraft the flight plan must contain FRC DCL in the Remarks field to receive DCL. Note: The inclusion of the FRC DCL as part of correlation is an outstanding issue in the End-to-End. DCP INTEGRATION PLAN End-to-End SEQUENCE DATA FLOW Page 22 of 49

23 5.4 Departure Clearance (DCL) Figure 5-3 AFN Logon & Session Establishment This section describes the nominal cases for DCL message delivery. The general case is that the DCL message is approved by a controller. When a pilot is ready to request their DCL they send a request which results in the DTAP sending their DCL message. Additional messaging to and from the airline s AOC is also depicted. There is a timing issue associated with the pilot s request occurring before or after the controller s approval that leads to two nominal cases. At the appropriate time, and after establishment of CPDLC connection, the aircrew requests DCL. DTAP then delivers the DCL to the aircraft using FANS-1/A message elements. When the DCL is sent to the aircraft the DTAP sends a corresponding dispatch message to the appropriate AOC system. The pilot responds with a WILCO (this flows assume normal condition) to the DTAP. DCP INTEGRATION PLAN End-to-End SEQUENCE DATA FLOW Page 23 of 49

24 Figure 5-4 Departure Clearance- WILCO After establishment of CPDLC connection, the aircrew requests DCL. Figure 5-5 shows a scenario where a DCL request arrives before the approval of the corresponding DCL. In this case DTAP responds with STANDBY and then delivers the DCL when it is approved. This scenario is considered to be a normal condition. DCP INTEGRATION PLAN End-to-End SEQUENCE DATA FLOW Page 24 of 49

25 Figure 5-5 Departure Clearance- STANDBY 5.5 Revised Departure Clearance (Revised DCL) One or more Revised DCLs may be sent by ATC prior to aircraft takeoff. These clearances will contain some or all of the same information as the initial Departure clearance. 5.6 Session Termination Figure 5-6 Revised Departure Clearance There are multiple automatic or manual triggers for session termination such as when flight departs, the flight plan times out, the flight deck disconnects the service, a controller manually terminates the session, or the system automatically terminates the session as a result of error processing. This section addresses session termination due to flight departure. DTAP has a site adaptable time out parameter that is used in the termination process. DTAP terminates the connection with the avionics an adapted time parameter after receiving a fight departure message from enroute automation. When DTAP receives CPDLC_END Response, it terminates the session and indicates to the controller that session has terminated. DCP INTEGRATION PLAN End-to-End SEQUENCE DATA FLOW Page 25 of 49

26 Figure 5-7 Session Termination DCP INTEGRATION PLAN End-to-End SEQUENCE DATA FLOW Page 26 of 49

27 6 DISPATCH MESSAGE FORMATS This Section describes the initial and revised dispatch messages to be provided by the tower automation system to the airline host (or proxy). The format of the dispatch messages, as shown in Table 6-1 (Initial Dispatch Message), 6-6 (Revised Dispatch Message) and Table 6-12 (Dispatch Message Acknowledgement Message) are intended to be similar to the existing PDC messages the airline systems receive from TDLS today. The formatting is intended to be as close as possible to the formatting used by TDLS today to minimize the costs associated with updating airline automation systems to receive process and respond to the dispatch message set. This formatting concept extends to the inclusion of such elements as the CID, equipment and departure time information in the dispatch message that are in today s PDC sent by TDLS but not included in a FANS DCL. All message lines are limited to 70 characters or less, including control codes. If a line exceeds this limit then the line should be split into multiple lines. No words/labels/elements should be split between lines. The Initial Dispatch message is sent to the appropriate AOC system. This message is intended to be similar to the PDC message sent today by TDLS. The initial dispatch message is intended to be used as a means to inform the AOC of the clearance issued to the aircraft. Table 6-1 provides the message format for the ground/ground message sent from the DTAP to the AOC system. There are three known usages, described later for how to apply this format. These usages include a cleared as filed message implementation, and two messages implementations that cover different modifications to the route information prior to the delivery of the initial clearance to the aircraft. The following paragraph describes how to read the message format tables. Optional values are surrounded by [brackets]. If there is no value or the field is not used in a message then no text from that set of brackets is included in the dispatch message. Field values represent variable information and are marked with {braces}. Notes are marked with an * followed by an alphanumeric tag that can be looked up in the bottom of Table 6-1. Table 6-1 Initial Dispatch Message (CCI) Message Format LINE Format 1 QU {IATA address TO } 2.{IATA address FROM} {DDHHMM} 3 CCI 4 { Sequence Number} DCL DISPATCH MESSAGE NOT AN ATC CLEARANCE 5 {Flight ID *A} {AIRPORT DEPARTURE}[ MODIFIED RTE*B] 6 {Equipment *C} P{Departure time *D} 7 {Computer Identifier *E} {Expected Level} DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 27 of 49

28 LINE Format 8 [CLEARED TO [{AIRPORT DESTINATION} AIRPORT {SID}.{TRANSITION FIX} {CLIMBOUT}][{position} VIA ]]{Route Information *F} 9 [{SID}.{TRANSITION FIX} {CLIMBOUT }][AFTER {position} CLEARED TO {AIRPORT DESTINATION} ARPT][THEN][ AS FILED] 10 [{climbviatext}] [MAINT {initial altitude}[ft]] *H 11 EDCT {EDCT} 12 DEP FREQ {FREQ} 13 [{AIRPORT DEPARTURE}[ {SID}][.{TRANSITION FIX}][ ] {route info}[ {TRANSITION FIX}][.{STAR}] {AIRPORT DESTINATION}] *G 14 [CONTACT {contactinfo}][,][{localinfo}]*i NOTES: A: Flight ID is not in the FANS uplink message, it will be derived from other DTAP information. B: The MODIFIED RTE tag is only included if the initial DCL is not sent CLEARED AS FILED. C: Equipment type is not in the FANS message; it will be derived from other DTAP information. D: Departure time is not in the FANS message; it will be derived from other DTAP or airline information. E: Computer Identifier is not in the FANS message; it will be derived from other DTAP information. F: Route information contains the waypoints, navaids and airways that make up the cleared route of flight after the transition fix to the element before the arrival fix but does not include the LAT/LONG information that is uplinked to the aircraft with each waypoint. Fixed radial distance route elements are sent as they were filed. G: This line in a dispatch message, if it is a route clearance, indicates the route of flight as filed. This is only used in the Cleared as Filed usage. Local adaptation is used to determine usage of FT or FL. H: {climbviatext} is a direct copy of the {climbviatext} variable from the corresponding uplink. The MAINT text is included if there is no {climbviatext} variable from the corresponding uplink. I: The comma is only included if conactinfo and localinfo are both included. There are three known usages of the Initial Dispatch Message. Each of these usages is uses a unique set of optional fields from the message format to convey information from the DTAP to the AOC system: 1. Cleared as Filed This is used when the aircraft is sent a clearance that is THEN AS FILED for the initial clearance delivery. The equivalent message uplinked to an aircraft will typically be a FANS UM169. This usage is shown in Table Full route change from filed flight plan This is used when the filed flight plan does not match the cleared flight plan for the initial clearance delivery. The equivalent message uplinked to an aircraft will typically be a FANS UM80. This usage is shown in Table First part of the route is changed, remainder of route remains cleared to destination as filed This is used when the initial portion of the filed route is changed but the latter portion remains unchanged for the initial clearance delivery. The equivalent DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 28 of 49

29 message uplinked to an aircraft will typically be a FANS UM79. This usage is shown in Table 6-5. DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 29 of 49

30 The following table defined the source of the information for the various data fields of the DCL initial and revised dispatch messages. Table 6-2 Dispatch Message (CCI&CCR) field descriptions Field name IATA address TO IATA address FROM DDHHMM CCI CCR Sequence Number Flight ID AIRPORT DEPARTURE AIRPORT DESTINATION Equipment Departure time Computer Identifier Expected Level SID TRANSITION FIX CLIMBOUT contactinfo Initial Altitude EDCT FREQ localinfo position Field Explanation and origin Address of airline host DTAP System address Timestamp Dispatch Copy Initial Dispatch Copy Revised Message Sequence Number Aircraft Identification (Callsign) from FDR Departure airport from the DCL message Destination airport from the DCL message Includes Special Indicator, Aircraft type, and Equipment suffix from FDR Estimated Time of Departure Computer Identifier from the FDR Requested Altitude from the FDR Departure procedure from the DCL message Departure Transition Fix from the DCL message Climb Out procedure from the DCL message Predefined contact message and/or frequency Initial altitude from the DCL message Estimated Departure Clearance Time from FDR Departure Frequency or SEE SID from the DCL message Predefined local information Converging/Diverging point from the DCL message DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 30 of 49

31 Table 6-3 CLEARED AS FILED USAGE of CCI LINE FORMAT EXAMPLE 1 QU {IATA address TO } QU ANPOCWN 2.{IATA address FROM} {DDHHMM}.OKCTWXA CCI CCI 4 { Sequence Number} DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE 5 { Flight ID } { AIRPORT DESTINATION } 001 DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE SWA9999 KMEM 6 { Equipment } P{Departure time} H/B744/Q P { Computer Identifier} {Expected Level } 01D CLEARED TO {AIRPORT DESTINATION} AIRPORT {SID}.{ TRANSITION FIX} {CLIMBOUT} CLEARED TO KOAK AIRPORT JERLE1.JERLE CLIMBOUT1 9 THEN AS FILED THEN AS FILED 10 {climbviatext}maint {initial altitude}ft CLIMB VIA SID EXCEPT MAINT 10000FT 11 EDCT {EDCT} EDCT DEP FREQ { FREQ} DEP FREQ {AIRPORT DEPARTURE} {SID}.{TRANS FIX} {route info} {TRANS FIX}.{STAR} { AIRPORT DESTINATION}} KMEM JERLE1.JERLE ARG RZC PER KA39Y MADN5 KOAK 14 CONTACT {contactinfo}[,]{localinfo} CONTACT , North departure procedures DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 31 of 49

32 Table 6-4 ENTIRE ROUTE CLEARANCE USAGE of CCI LINE FORMAT EXAMPLE 1 QU {IATA address TO } QU ANPOCWN 2.{IATA address FROM} {DDHHMM}.OKCTWXA CCI CCI 4 { Sequence Number} DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE 5 { Flight ID } { AIRPORT DESTINATION } MODIFIED RTE 001 DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE SWA9999 KMEM MODIFIED RTE 6 { Equipment } P{Departure time} H/B744/Q P { Computer Identifier} {Expected Level } 01D {Route Information} KMEM ARG RZC PER KA39Y MADN5 KOAK 9 {SID.TRANSITION} {CLIMBOUT} JERLE1.JERLE CLIMBOUT1 10 MAINT {initial altitude}ft MAINT 5000FT 11* EDCT {EDCT} EDCT DEP FREQ { FREQ} DEP FREQ CONTACT {contactinfo},{localinfo} CONTACT DEICE ON , North departure procedures DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 32 of 49

33 Table 6-5 Revised Initial CLEARED TO POINT THEN AS FILED USAGE of CCI LINE FORMAT EXAMPLE 1 QU {IATA address TO } QU ANPOCWN 2.{IATA address FROM} {DDHHMM} 3 CCI CCI 4 { Sequence Number} DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE 5 { Flight ID } {AIRPORT DESTINATION} MODIFIED RTE.OKCTWXA DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE SWA9999 KMEM MODIFIED RTE 6 { Equipment } P{Departure time} H/B744/Q P { Computer Identifier} {Expected Level } 8 CLEARED TO {position} VIA {Route Information} 9 {SID}.{ TRANSITION FIX} {CLIMBOUT} AFTER {position} CLEARED TO { AIRPORT DESTINATION }[ARPT] AS FILED 01D {climbviatext} CLIMB VIA SID 11* EDCT {EDCT} EDCT 1630 CLEARED TO ARG VIA JERLE RZC PER JERLE1.JERLE CLIMBOUT1 AFTER ARG CLEARED TO KOAK ARPT AS FILED 12 DEP FREQ { FREQ} DEP FREQ CONTACT {contactinfo},{localinfo} CONTACT , Taxiway H narrow, Use Caution DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 33 of 49

34 Table 6-6 contains the format for the Revised Dispatch Message. The first 7 lines (from Start of Message through Computer Identifier) are required in each Revised Dispatch Message. The field (REVISED [ RTE][ DPP][ EDCT][ EXP ALT][ ALT][ DEPFREQ][CONTACT][LOCALINFO] } on the fifth line of the message contains the list of fields that have been changed from the last clearance sent and have corresponding values included in the rest of the message. The changed portion of the associated FANS DCL message will be included in the remainder of the Revised Dispatch Message in the same order as in an Initial Dispatch Message. This is indicated below as Route Information, Free Text or Free Text Additional. Fields start with the word REVISED for each revised field followed by the field tag from table 6-5 followed by the field information from table 6-4. LINE FORMAT Table 6-6 Revised Dispatch Message (RC) message format 1 QU {IATA address TO } 2.{IATA address FROM} {DDHHMM} 3 CCR 4 { Sequence Number} DCL DISPATCH MESSAGE NOT AN ATC CLEARANCE 5 {Flight ID *A} {AIRPORT DESTINATION} {REVISED[ RTE][ DPP][ ALT][ EXP ALT][ DEPFREQ][ EDCT][ CONTACT][ LCLINFO]*B} 6 {Equipment *C} P{Departure time *D} 7 {Computer Identifier *E} [REVISED EXP ALT FL]{expected level}*f 8 [REVISED RTE[CLEARED TO {position} VIA ][AT {position} CLEARED]{ route information *G}] 9 [REVISED DPP {SID}[.{TRANSITION FIX}][{ CLIMBOUT}]][ AFTER {position} REST OF ROUTE UNCHANGED]] 10 [REVISED ALT [{climbviatext}][ MAINT {initial altitude}[ft]]]*h 11 [REVISED EDCT {EDCT}] 12 [REVISED DEPFREQ {FREQ}] 13 [REVISED CONTACT {contactinfo}] 14 [REVISED LOCALINFO {localinfo}] DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 34 of 49

35 LINE FORMAT NOTES: A: Flight ID is not in the FANS uplink message, it will be derived from other DTAP information. B: The REVISED set of tags are used as follows: Each tag is included if the corresponding parameter has been changed since the last clearance sent to the aircraft. Each tag, if it appears, must appear in the order as shown. These tags are also documented in Table 6-11 Revised Fields C: Equipment type is not in the FANS message; it will be derived from other DTAP information. D: Departure time is not in the FANS message; it will be derived from other DTAP or airline information. E: Computer Identifier is not in the FANS message; it will be derived from other DTAP information. F: The expected level parameter appears in every revised dispatch message. The REVISED EXP ALT FL tag only appears if the parameter has changed since the last clearance sent to the aircraft. G: Route information consists of the waypoints, navaids and airways that make up the cleared route of flight but does not include the LAT/LONG information that is uplinked to the aircraft with each waypoint. H: {climbviatext} is a direct copy of the {climbviatext} variable from the corresponding uplink. The MAINT text is included if there is no {climbviatext} variable from the corresponding uplink. DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 35 of 49

36 There are four know usages of the Revised Dispatch Message: Non route revision This is used when the non-route elements of the initial departure clearance are changed. The equivalent message uplinked to an aircraft will typically be a FANS UM169. This usage is shown in Table 6-7. First part of the route is changed, remainder of route remains cleared to destination as filed This is used when the initial portion of the previously cleared route is changed but the latter portion remains unchanged. The other non-route portions of the clearance may also be modified with this usage. The corresponding message uplinked to an aircraft will typically be a FANS UM79. This usage is shown in table 6-8. Last portion of the route has changed, initial portion of the route remains as previously cleared This is used when the initial portion of the previously cleared route is unchanged but a portion from a fix to the destination has been changed. The other non-route portions of the clearance may also be modified with this usage. The corresponding message uplinked to an aircraft will typically be a FANS UM83. This usage is shown in Table 6-9. Full route revision This is used when the entire route of flight has changed since the last clearance. The corresponding message uplinked to an aircraft will typically be a FANS UM80. This usage is shown in table DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 36 of 49

37 Table 6-7 Non Route Revision Usage of CCR LINE FORMAT EXAMPLE 1 QU {IATA address TO } QU ANPOCWN 2.{IATA address FROM} {DDHHMM}.OKCTWXA CCR CCR 4 { Sequence Number} DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE 5 {Flight ID } { AIRPORT DESTINATION} REVISED DPP ALT EXP ALT DEPFREQ EDCT CONTACT LCLINFO 001 DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE SWA9999 KMEM REVISED DPP ALT EXP ALT DEPFREQ EDCT CONTACT LCLINFO 6 {Equipment} P{Departure time} H/B744/Q P { Computer Identifier} REVISED EXP ALT FL{Expected Level} 8 REVISED DPP {SID}{.TRANSITION FIX} {CLIMBOUT} 01D REVISED EXP ALT FL320 REVISED DPP JERLE1.JERLE CLIMBOUT1 9 REVISED EDCT {EDCT} REVISED EDCT REVISED ALT MAINT {initial altitude}ft REVISED ALT MAINT 5000FT 11 REVISED DEPFREQ { FREQ} REVISED DEPFREQ REVISED CONTACT {contactinfo} REVISED CONTACT DEICE ON REVISED LOCALINFO REVISED LOCALINFO North operations now in use DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 37 of 49

38 Table 6-8 CLEARED TO usage of CCR LINE FORMAT EXAMPLE 1 QU {IATA address TO } QU ANPOCWN 2.{IATA address FROM} {DDHHMM} 3 CCR CCR 4 { Sequence Number} DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE 5 {Flight ID } {AIRPORT DESTINATION} REVISED RTE DPP ALT EXP ALT DEPFREQ EDCT CONTACT LCLINFO.OKCTWXA {Equipment} P{Departure time} H/B744/Q P DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE SWA9999 KMEM REVISED RTE DPP ALT EXP ALT DEPFREQ EDCT CONTACT LCLINFO 7 { Computer Identifier} REVISED EXP ALT FL{Expected Level} 8 REVISED RTE CLEARED TO {position} VIA {route information} 01D REVISED EXP ALT FL320 REVISED RTE CLEARED TO KA39Y VIA JERLE CASLN ARG RZC PER 9 REVISED DPP {SID}{.TRANSITION FIX} {CLIMBOUT} AFTER {position} REST OF ROUTE UNCHANGED REVISED DPP JERLE1.JERLE CLIMBOUT1 AFTER KA39Y REST OF ROUTE UNCHANGED 10 REVISED ALT {climbviatext} REVISED ALT CLIMB VIA SID 11 REVISED EDCT {EDCT} REVISED EDCT REVISED DEPFREQ { FREQ} REVISED DEPFREQ REVISED CONTACT {contactinfo} REVISED CONTACT REVISED LOCALINFO {localinfo} REVISED LOCALINFO North departure procedures DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 38 of 49

39 Table 6-9 AT position CLEARED usage of CCR LINE FORMAT EXAMPLE 1 QU {IATA address TO } QU ANPOCWN 2.{IATA address FROM} {DDHHMM} 3 CCR CCR 4 { Sequence Number} DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE 5 {Flight ID } {AIRPORT DESTINATION} REVISED RTE EXP ALT DEPFREQ EDCT CONTACT LOCALINFO.OKCTWXA {Equipment} P{Departure time} H/B744/Q P DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE SWA9999 KMEM REVISED RTE EXP ALT DEPFREQ EDCT CONTACT LOCALINFO 7 { Computer Identifier} REVISED EXP ALT FL{Expected Level} 8 REVISED RTE AT {position} CLEARED {route information} 01D REVISED EXP ALT FL320 REVISED RTE AT ILC CLEARED ILC MVA MADN5 KOAK 9 REVISED EDCT {EDCT} REVISED EDCT REVISED DEPFREQ { FREQ} REVISED DEPFREQ REVISED CONTACT {contactinfo} REVISED CONTACT REVISED LOCALINFO {localinfo} REVISED LOCALINFO North departure procedures DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 39 of 49

40 Table 6-10 Full route revision usage of CCR LINE FORMAT EXAMPLE 1 QU {IATA address TO } QU ANPOCWN 2.{IATA address FROM} {DDHHMM} 3 CCR CCR 4 { Sequence Number} DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE 5 {ACID} {ADEP} REVISED RTE DPP ALT EXP ALT DEPFREQ EDCT CONTACT LCLINFO.OKCTWXA {Equipment} P{Departure time} H/B744/Q P DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE SWA9999 KMEM REVISED RTE DPP ALT EXP ALT DEPFREQ EDCT CONTACT LCLINFO 7 { Computer Identifier} REVISED EXP ALT FL{Expected Level} 01D REVISED EXP ALT 320FL 8 REVISED RTE {route information} REVISED RTE KMEM ARG RZC PER KA39Y MADN5 KOAK 9 REVISED DPP {SID.TRANSITION}{ CLIMBOUT} REVISED DPP JERLE1.JERLE CLIMBOUT1 10 REVISED ALT {climbviatext} REVISED ALT CLIMB VIA SID 11 REVISED EDCT {EDCT} REVISED EDCT REVISED DEPFREQ { FREQ} REVISED DEPFREQ REVISED CONTACT {contactinfo} REVISED CONTACT REVISED LOCALINFO {localinfo} REVISED LOCALINFO North departure procedures DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 40 of 49

41 Table 6-11 Revised Fields Tag Meaning Example RTE Route Information, minus any departure procedure HUMMS PXV BIGXX MZZ DPP Departure procedure CRSON1.HUMMS ALT Initial Altitude 5000FT EXP ALT Expected altitude, this field can have more information based on local procedures FL390 DEPFREQ Departure frequency EDCT Estimated departure clearance time 1525 CONTACT Frequency to contact with optional reason DEICE ON LOCALINFO Local information North departure procedures Table 6-12 provides the format for the dispatch message Acknowledgment Message and Table 6-13 provides the Field Descriptions for the dispatch acknowledgement message. Table 6-12 Dispatch Message Acknowledgement Message LINE Format 1 QU {IATA address TO } 2.{IATA address FROM} {DDHHMM} 3 CCA 4 {Flight ID *A} { Sequence Number} {Tail Number} {Departure time} {Gate Assignment} DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 41 of 49

42 Table 6-13 Dispatch Message Acknowledgement Field Descriptions Field name {IATA address TO }.{IATA address FROM} {DDHHMM} Flight ID Sequence Number {Tail Number} {Departure time } Gate Assignment Field Explanation Address of DTAP at destination tower Address of airline host sending the ACK Time message was sent to DTAP 2 or 3-char customer ID plus numerals This should match the sequence number of the CCI or CCR that this acknowledges If known, default if unknown is single period. Format is 2 characters of hours followed by 2 characters of minutes (HHMM) Format is G[XXXXX], default if gate information is not available is G Table 6-14 Dispatch Message Pilot response message FORMAT 1 QU {IATA address TO } 2.{IATA address FROM} {DDHHMM} 3 CCP 4 { Sequence Number} 5 {Flight ID *A} {AIRPORT DEPARTURE} 6 PILOT RESPONSE [WILCO][STANDBY][UNABLE][ROGER] 7-17 Repeat Lines 4 through the end of the corresponding Dispatch Message DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 42 of 49

43 Table 6-15 Dispatch Message Pilot response field descriptions Field name {IATA address TO } Field Explanation Address of DTAP at destination tower.{iata address FROM} {DDHHMM} Flight ID Sequence Number {Tail Number} {Departure time } {Clearance Sequence number} Address of airline host sending the ACK Time message was sent to DTAP 2 or 3-char customer ID plus numerals Message Sequence Number If known, default if unknown is single period. Format is 2 characters of hours followed by 2 characters of minutes (HHMM) Sequence number from the DTAP for the corresponding CCI/CCR DCP INTEGRATION PLAN DISPATCH MESSAGE FORMATS Page 43 of 49

44 7 TEST PROGRAM DESCRIPTION This section provides a summary of the Test Program, focusing on the test and evaluation approach, summary of test requirements, activities leading to test, test environment, test location, test tools, and an overview of the types of testing to be conducted in order to evaluate the DTAP requirements laid out in the Program Requirements for DTAP. 7.1 Approach and Concept The objective of the test activities is to evaluate the operational effectiveness and suitability of the DTAP system using a systematic approach, under simulated operational end-to-end conditions in the lab environment, including aircraft in the loop conditions that are representative of those found between Air Traffic Control sites and aircraft avionics in the field. Hardware and software will be evaluated. All findings will be submitted in a test report that will provide recommendations of acceptance or non-acceptance of the DTAP system. A preliminary test report will be delivered following the test conduct at the WJHTC, with a final report being delivered after SAT at each DCL Trials location Evaluation Approach The evaluation will be based on the degree to which the DTAP system satisfies the program requirements for DTAP under operationally realistic conditions. The evaluation and assessment of the DTAP will include a period of test procedure checkout and dry run testing before the formal test. This allows test personnel the opportunity to refine test procedures and to develop familiarization with the end-to-end system Performance Thresholds Relevant thresholds for the testing are included in the individual test procedures as required Activities Leading To Test The following activities must be accomplished prior to start of the formal DTAP test at the WJHTC: Completion of DTAP contractor Developmental Testing (DT) Development of the Test Plan Development of the Test Procedures Conduct of Test dry runs DCP INTEGRATION PLAN TEST PROGRAM DESCRIPTION Page 44 of 49

45 7.2 Test Environment To test the DTAP requirements, the WJHTC will allocate the necessary environment to perform the test procedures. The initial test environment will be a self-contained environment in the Data Comm Prototype and Integration Lab, and will consist of the DTAP and a HADDS stand-alone system. This will provide system functionality to test application and interface DTAP requirements in the lab bench environment. The final test environment will be an end-to-end system that will closely mimic the operational field environment, and will provide an end-to-end system to run the test procedures that will closely mimic the real field DCL Trials architecture. This end-to-end system test environment will consist of the DTAP in the Data Comm Prototype and Integration Lab, FTI National Test Bed (FNTB), HADDS, DCP CSPs, and FANS equipped aircraft avionics. Refer to Figure 4-1 for the test environment architecture. SAT will be performed at each DCL Trials location prior to the start of the Trials at that site, and will utilize the trials architecture environment shown in Figure Test Location End-to-end system testing will be conducted at the FAA WJHTC at the Atlantic City International Airport in Atlantic City, NJ. SAT will take place at each DCL Trials location prior to the start of that Trial period. FedEx, United Airlines, and Delta Airlines have offered FANS equipped aircraft at field locations to support testing. 7.3 Test and Analysis Tools Test tools are meant to be utilized in a lab environment in an effort to emulate specific system components in the absence of real software and hardware end-to-end system elements. For the laboratory environment test phase, such test tools are categorized as shown: FANS Avionics Tool Set HADDS in a box TESTOPIA BUGZILLA FNTB DCP INTEGRATION PLAN TEST PROGRAM DESCRIPTION Page 45 of 49

46 Verification that the test tools perform properly with no anomalies and/or discrepancies will be performed as part of the environment. 7.4 Test and Evaluation Descriptions The test program for end-to-end system testing at the WJHTC encompasses four main areas of formal test as listed below: 1. DTAP Functionality 2. Data analysis on all of the DTAP functionality to verify their pass/fail status 3. Document any Program Trouble Reports (PTRs) 4. Flight Deck Avionics DCL Trials End-to-End System Testing The William J. Hughes Tech Center (WJHTC) will jointly develop individual test procedures with the DCL Trials team to be executed at the WJHTC Data Comm Lab, in accordance with the test descriptions for the DTAP functionality requirements and must successfully verify that the DTAP meets or exceeds all requirements, as documented in the approved VRTM. This testing at the WJHTC will include application interface testing, CSP interface testing, and end-to-end system testing. Application interface level testing will be performed, which includes the DTAP application communicating and interfacing with ground-ground components as part of the end-to-end chain. CSP interface testing will be performed with the DTAP system ground infrastructure to ensure connectivity and addressing characteristics are met. This also includes routing and forwarding testing with failover conditional testing. End-to-end lab testing will be performed and will include testing with FANS-1/A avionics with aircraft in the loop scenarios. This end-to-end aircraft acceptance testing will be performed to validate and verify the proper function and operation of the DTAP. SAT will be conducted at each DCL Trials location prior to the beginning of the Trials. SAT has two parts: Functional, which is a subset of OT functional, and Operational, which is a mix of a subset of OT Ops testing and site specific testing. Test procedures will be utilized Test Objectives The objective of the Test will be to evaluate whether the DTAP requirements were implemented as designed and operationally suitable as outlined in the FAA Data Communications Trials Automation Platform (DTAP) Concept Document and documented in the VRTM. DCP INTEGRATION PLAN TEST PROGRAM DESCRIPTION Page 46 of 49

47 Once the formal test has been completed, data analysis will be conducted for those requirements assigned as Verify by Test Test Criteria The evaluation/success criteria for the DTAP functionality are found in the individual test procedures. 7.5 Test Approach The test approach used for each DTAP Functionality is listed in the individual test case/procedures. They include descriptions of specific tasks, activities, test conditions, scenarios and operational situations. The Test Process is depicted in Figure 7-1 below. Figure 7-1 DCL Trials End-to-End Test Process DCP INTEGRATION PLAN TEST PROGRAM DESCRIPTION Page 47 of 49