May 2015 

NASA/CR–2015-218708

TASAR Certification and Operational Approval 

Requirements — Analyses and Results 

Stefan Koczo Jr. 

Rockwell Collins, Inc., Cedar Rapids, Iowa 
NASA STI Program . . . in Profile

Since its founding, NASA has been dedicated to the 

advancement of aeronautics and space science. The 

NASA scientific and technical information (STI) 

program plays a key part in helping NASA maintain 

this important role. 

The NASA STI program operates under the auspices 

of the Agency Chief Information Officer. It collects, 

organizes, provides for archiving, and disseminates 

NASA’s STI. The NASA STI program provides access 

to the NTRS Registered and its public interface, the 

NASA Technical Reports Server, thus providing one 

of the largest collections of aeronautical and space 

science STI in the world. Results are published in both 

non-NASA channels and by NASA in the NASA STI 

Report Series, which includes the following report 

types: 

• TECHNICAL PUBLICATION. Reports of 

completed research or a major significant phase of 

research that present the results of NASA 

Programs and include extensive data or theoretical 

analysis. Includes compilations of significant 

scientific and technical data and information 

deemed to be of continuing reference value. 

NASA counter-part of peer-reviewed formal 

professional papers but has less stringent 

limitations on manuscript length and extent of 

graphic presentations. 

• TECHNICAL MEMORANDUM. 

Scientific and technical findings that are 

preliminary or of specialized interest, 

e.g., quick release reports, working 

papers, and bibliographies that contain minimal 

annotation. Does not contain extensive analysis. 

• CONTRACTOR REPORT. Scientific and 

technical findings by NASA-sponsored 

contractors and grantees. 

• CONFERENCE PUBLICATION. 

Collected papers from scientific and technical 

conferences, symposia, seminars, or other 

meetings sponsored or 

co-sponsored by NASA. 

• SPECIAL PUBLICATION. Scientific, 

technical, or historical information from NASA 

programs, projects, and missions, often 

concerned with subjects having substantial 

public interest. 

• TECHNICAL TRANSLATION. 

English-language translations of foreign 

scientific and technical material pertinent to 

NASA’s mission. 

Specialized services also include organizing 

and publishing research results, distributing 

specialized research announcements and feeds, 

providing information desk and personal search 

support, and enabling data exchange services. 

For more information about the NASA STI program, 

see the following: 

• Access the NASA STI program home page at 

http://www.sti.nasa.gov 

• E-mail your question to help@sti.nasa.gov 

• Phone the NASA STI Information Desk at 

757-864-9658 

• Write to: 

NASA STI Information Desk 

Mail Stop 148 

NASA Langley Research Center 

Hampton, VA 23681-2199 
National Aeronautics and

Space Administration 

Langley Research Center Prepared for Langley Research Center 

Hampton, Virginia 23681-2199 under Contract NNL12AA11C 

May 2015 

NASA/CR–2015-218708

TASAR Certification and Operational Approval 

Requirements — Analyses and Results

Stefan Koczo Jr. 

Rockwell Collins, Inc., Cedar Rapids, Iowa 
Available from: 

NASA STI Program / Mail Stop 148 

NASA Langley Research Center 

Hampton, VA 23681-2199 

Fax: 757-864-6500 

The use of trademarks or names of manufacturers in this report is for accurate reporting and does not constitute an 

official endorsement, either expressed or implied, of such products or manufacturers by the National Aeronautics and 

Space Administration. 
iii

Table of Contents 

Acknowledgments........................................................................................................................ viii

1. Introduction ............................................................................................................................. 1

1.1 Background and Motivation for TASAR ......................................................................... 1

1.2 Contract Objectives .......................................................................................................... 2

1.3 Organization of this Report .............................................................................................. 2

2. TASAR Overview and High-Level Description ..................................................................... 2

3. Research Tasks and Activities ................................................................................................ 4

4. Research Program Description and Documentation of Results .............................................. 5

4.1 User Community Survey .................................................................................................. 6

4.1.1 TASAR User Survey Overview ............................................................................... 6

4.1.2 Survey Results, Findings, and Recommendations ................................................... 7

4.2 Certification and Operational Approval Requirements .................................................. 13

4.2.1 TASAR Operational Hazard and Safety Requirements Analysis ........................... 13

4.2.2 TASAR Requirements for Adherence to Industry Standards ................................. 25

4.2.3 FAA Guidelines and Regulatory Requirements for TASAR Approval .................. 28

4.2.4 DER “Dry Run” Review of Certification and Operational Approval Artifacts ...... 43

4.2.5 TAP HMI Version 4 Certification and Operational Approval Analysis................. 53

4.3 FAA Certification and Operational Approval Technical Interchange Meeting ............. 77

Appendix A TASAR User Survey Results, Findings and Recommendations......................... 79

A.1 Current & Planned Systems Supporting Potential Deployment of TASAR .................. 79

A.1.1 ADS-B OUT ........................................................................................................... 80

A.1.2 ADS-B IN ............................................................................................................... 81

A.1.3 Electronic Flight Bag (EFB) ................................................................................... 81

A.1.4 Data Connectivity ................................................................................................... 82

A.2 General Observations on Operator Operations and Demographics ............................... 83

A.3 Challenges and Disruptive Factors to Flight Operations ............................................... 84

A.3.1 Pilot Perspective...................................................................................................... 84

A.3.2 Dispatch Perspective ............................................................................................... 85

A.3.3 Flight Operations Perspective ................................................................................. 86

A.4 Change Requests ............................................................................................................ 88

A.4.1 Total Number of Change Requests per Flight ........................................................ 88
iv

A.4.2 Type of Change Requests ....................................................................................... 88

A.4.3 Coordination of Change Requests with Dispatcher ................................................ 88

A.4.4 ATC Response to Change Requests ....................................................................... 89

A.5 Tools ............................................................................................................................... 90

A.5.1 Dispatch Tools ........................................................................................................ 90

A.5.2 Pilot Tools ............................................................................................................... 91

A.6 Information Source Assessment – Dispatch ................................................................... 92

A.6.1 Dispatch Information Sources – Fundamental and Most Valuable Rating ............. 92

A.6.2 Importance of Information Sources for Dispatch ................................................... 92

A.6.3 Effectiveness of Information Sources for Dispatch ................................................ 93

A.6.4 Deficiencies of Information Sources ...................................................................... 93

A.6.5 Information that Would Significantly Improve the Flight Re-Planning Process .... 95

A.7 Flight Re-Planning Organizational Policies, Constraints, and Cost Factors .................. 96

A.7.1 Organizational Policies and Procedures for Flight Changes ................................... 96

A.7.2 Flight Optimization by Dispatchers ........................................................................ 96

A.7.3 Flight Planning Constraints ..................................................................................... 97

A.8 Survey Review and Assessment Results Summary ....................................................... 98

A.8.1 Equipage for TASAR .............................................................................................. 99

A.8.2 TASAR Cost Benefits, Usability, Synergy with Dispatch and ATC Processes ..... 99

Appendix B TASAR EFB Standards Adherence Requirements ........................................... 103

B.1 Determination of EFB “Class” Anticipated for TASAR ............................................. 103

B.2 Classes of EFB – Hardware Perspective ...................................................................... 104

B.3 Typical EFB System Components ............................................................................... 105

B.4 Class 2 EFB Approval Requirements ........................................................................... 106

B.4.1 High-Level Steps for Installation and Operational Approval of a Class 2 EFB ... 106

B.4.2 EFB Mounting Considerations ............................................................................. 107

B.5 EFB “Type” Considerations ......................................................................................... 108

B.6 Principal Operations Inspector (POI) Review Checklists ............................................ 110

Appendix C Certification and Operational Approval Guidelines and Regulatory Requirements 

for TASAR; Project Specific Certification Plan ......................................................................... 114

C.1 Phases of Certification Project ..................................................................................... 114
v

C.1.1 Conceptual Design (Phase 1) ................................................................................ 114

C.1.2 Requirements Definition (Phase 2) ....................................................................... 115

C.1.3 Compliance Planning (Phase 3) ............................................................................ 116

C.1.4 Implementation (Phase 4) ..................................................................................... 117

C.1.5 Post Certification (Phase 5) .................................................................................. 117

C.2 PSCP with TASAR Content ......................................................................................... 118

C.3 Compliance Check List ................................................................................................ 127

C.3.1 Cornerstone EFB Documents ............................................................................... 127

C.3.2 Compliance Check List – High-level Items .......................................................... 127

Appendix D DER “Dry Run” Review and Artifacts Details ................................................. 139

D.1 DO-178B Objectives Artifacts Requirements for Level D .......................................... 139

D.2 Tabletop EFB Evaluation (Detailed Check List #1) .................................................... 141

D.3 EFB Operational Evaluation (Detailed Check List #2) ................................................ 147

D.4 EFB Report Information Template .............................................................................. 155

D.5 EFB Line Evaluation Job Aid (Detailed Check List #4) .............................................. 157

Appendix E FAA Technical Interchange Meeting Details .................................................... 162

Acronyms .................................................................................................................................... 166

References ................................................................................................................................... 171
vi

List of Figures 

Figure 1 Acceptable Risk versus Potential Effects (Defined for Civil Aviation) ............... 18

Figure 2 Operational Safety Assessment Process – Method 2. ........................................... 20

Figure 3 ED78A/DO264 Based Hazard Classification Matrix ........................................... 21

Figure 4 TASAR Functional Diagram* .............................................................................. 23

Figure 5a TAP HMI V2 Initialization Screen ....................................................................... 61

Figure 5b TAP HMI V4 Startup Checklist Screen ................................................................ 62

Figure 6 TAP HMI V2 Standby Screen .............................................................................. 63

Figure 7 TAP HMI V2 Auto Mode Screen ......................................................................... 64

Figure 8 TAP HMI V2 Selected Optimization Screen of the Auto Mode .......................... 65

Figure 9 TAP HMI V4 Auto Mode Screen ......................................................................... 66

Figure 10 TAP HMI V2 Manual Mode Screen ..................................................................... 68

Figure 11 TAP HMI V2 Manual Mode Screen with Evaluation Results .............................. 68

Figure 12 TAP HMI V4 Manual Mode Screen ..................................................................... 69

Figure 13 TAP HMI V4 Manual Mode Screen – Preview Route Depiction ........................ 70

Figure 14 TAP HMI V4 Manual Mode Screen – Traffic Hazard Depiction ........................ 71

Figure 15 TAP HMI V4 Manual Mode Screen – Weather Hazard Depiction ...................... 71

Figure A-1 TASAR Functional Diagram ................................................................................ 80

Figure B-1 Typical EFB System Components ...................................................................... 105

Figure C-1 Typical Type Certification (TC) Process ............................................................ 120

Figure C-2 Implementation Phase of TC Process ................................................................. 121

Figure C-3 Approval/Acceptance Process Flow Diagram .................................................... 122

Figure C-4 TASAR Functional Diagram .............................................................................. 123

 
vii

List of Tables 

Table 1 Operator Survey Questions by Category – Operator Demographics ...................... 6

Table 2 Operator Survey Questions by Category – Pilots ................................................... 7

Table 3 Operator Survey Questions by Category – Dispatcher ........................................... 8

Table 4 Operator Survey Questions by Category – Flight Operations ................................ 9

Table 5 TASAR Operational Hazards and Mitigations ..................................................... 24

Table D-1 Summary of DO-178B Objectives Required per Design Assurance Level ........ 140
viii

Acknowledgments 

This report represents one of two Summary Reports documenting the culmination of effort by 

Rockwell Collins and the University of Iowa Operator Performance Laboratory (OPL) on NASA 

Contract NNL12AA11C supporting NASA’s development of the Traffic Aware Strategic Aircrew 

Requests (TASAR) Electronic Flight Bag (EFB) application. This report documents the analysis 

and assessment activities pertaining to Task 1 of this contract that determine certification and 

operational approval requirements for the TASAR EFB Application. The companion Task 2 

Summary Report not contained herein provides approval artifacts derived from two Human-inthe-Loop (HITL) simulation experiments [0]. Rockwell Collins and the University of Iowa OPL 

are pleased to have been part of the extended TASAR research team. While many contributed to 

the overall effort, we would like to acknowledge the roles and contributions of the following 

individuals for their valuable contributions throughout this program: 

• From NASA Langley Research Center: David Wing, the TASAR Program Principal 

Investigator and Technical Monitor of the research effort described in this report; Mark 

Ballin, strategic planner and visionary for advanced concepts such as TASAR; Dr. Kelly 

Burke for her leadership in the Human-in-the-Loop (HITL) simulation experiments and 

her Human Factors expertise; and Joey Ponthieux, for his support and collaboration with 

OPL on the development of the TASAR Computer Based Training Prototype. 

• From Engility Corporation: Sharon Woods, Bob Vivona, David Roscoe, and Brendan 

LeFebvre for their support on the integration and test effort of the Engility-developed 

TASAR EFB hardware and software into the University of Iowa OPL’s flight simulator 

that was used in the HITL simulation experiments.

• Advanced Aerospace Solutions, LLC: John Maris for his expertise and support in serving 

as a subject pilot for rehearsal in support of the initial HITL simulation experiment at the 

University of Iowa OPL flight deck simulator, and Mark Haynes for his support in 

providing valuable information exchanges, e.g., sharing results of Advanced Aerospace 

Solutions’ flight evaluation of TASAR to be factored into this analysis. 

• Captain Bill Cotton who served as our Pilot and Airspace Operations Subject Matter Expert 

on a number of occasions during the development of the TASAR User Survey and also 

provided support in the scenario development used in the HITL simulation experiments. 

Contributions of those mentioned and others working behind the scenes resulted in an effective 

collaboration of the extended TASAR team led by NASA throughout this research program. 
1

1. Introduction 

This report documents the results of research and development work performed by Rockwell 

Collins in addressing the Task 1 objectives under NASA Contract NNL12AA11C. Under this 

contract Rockwell Collins provided analytical support to the NASA Langley Research Center 

(LaRC) in NASA’s development of a Traffic Aware Strategic Aircrew Requests (TASAR) flight 

deck Electronic Flight Bag (EFB) application for technology transition into operational use. 

The two primary objectives of this contract were for Rockwell Collins and the University of Iowa 

OPL to 1) perform an implementation assessment of TASAR toward early certification and 

operational approval of TASAR as an EFB application (Task 1 of this contract), and 2) design, 

develop and conduct two Human-in-the-Loop (HITL) simulation experiments that evaluate 

TASAR and the associated Traffic Aware Planner (TAP) software application to determine the 

situational awareness and workload impacts of TASAR in the flight deck, while also assessing the 

level of comprehension, usefulness, and usability of the features of TAP (Task 2 of this contract). 

This report represents the Task 1 summary report. The Task 2 summary report is provided in [0]. 

1.1 Background and Motivation for TASAR 

The development of technologies such as TASAR support the objectives of the former NASA 

Airspace Systems Program (ASP) and its NextGen Concepts and Technology Development (CTD) 

Project, as well as the new NASA Airspace Operations and Safety Program (AOSP). The NextGen 

CTD Project developed innovative concepts and technologies to improve the efficiency, capacity, 

and safety of the National Airspace System. Research focus areas included traffic flow 

management, dynamic airspace configuration, separation assurance, super density operations, and 

airport surface operations. In the area of separation assurance, CTD research included the 

development of advanced concepts and technologies for aircraft to provide their own traffic 

separation services, i.e. airborne separation, using Automatic Dependent Surveillance Broadcast 

(ADS-B).

CTD research produced advanced algorithms for detecting and resolving traffic conflicts in the 

presence of weather and time constraints. Leveraging this far-term research, NASA envisions a 

near-term application of this advanced flight-deck technology to improve pilot-initiated requests 

for trajectory change(s) made to Air Traffic Control (ATC) in today’s operations. In a concept 

called “Traffic Aware Strategic Aircrew Requests” (TASAR), pilots would use onboard 

automation tools to identify trajectory improvement opportunities that are deconflicted from traffic 

aircraft, i.e., traffic aware, and also aware of environmental constraints, e.g., weather, winds, 

airspace constraints, that may adversely affect their flight route, prior to making the trajectorychange request to Air Traffic Control (ATC). 
2

The TASAR capability is anticipated to increase ATC approval frequency and therefore achieve 

benefits in areas such as flight efficiency, flight schedule compliance, passenger comfort, and pilot 

and controller workload. With TASAR, NASA intends to help accelerate the adoption of 

networked flight-deck automation systems and ADS-B equipage by the aircraft operator 

community.

1.2 Contract Objectives 

The objectives of this contract were to 1) analyze and assess the implementation requirements for 

certification and operational approval of TASAR (Task 1 of this contract and addressed by this 

report) and 2) to assess human factors including pilot workload and situational awareness 

associated with the TASAR flight-deck technology (Task 2 of this contract, but addressed in a 

separate summary report [0]). By analyzing the implementation requirements and assessing pilot 

use of the TASAR capability in simulation, the path to implementation for operational use can 

possibly be shortened. NASA Contract NNL12AA11C was awarded to Rockwell Collins and its 

subcontractor, the University of Iowa Operator Performance Laboratory (OPL), for these tasks 

under the NASA Headquarters Aeronautics Research Mission Directorate (ARMD) NASA 

Research Announcement (NRA) entitled “Research Opportunities in Aeronautics” – 2010, 

Amendment 7, NextGen CTD Project, Subtopic 5. 

1.3 Organization of this Report 

Section 1 of this report presents an introduction and context for the research. Section 2 provides 

an overview and high-level description of the TASAR EFB application and summarizes the highlevel results of this assessment. The research objectives for Task 1 of this contract and documented 

in this report are identified in Section 3 and the attendant research results are provided in Section 

4. Due to the expansive nature of regulatory documents that apply to EFB applications, a number 

of appendices are provided that capture the TASAR-specific certification and operational approval 

requirements and provide some artifacts that were developed that may be used in gaining early 

operational approval for TASAR. 

The certification and operational approval analyses included the development and analysis of a 

TASAR User Community Survey of end users, including pilots, dispatchers and flight operations 

personnel, to gain their perspectives and needs for the capabilities offered by TASAR. An 

operational hazard assessment of TASAR was made in order to determine the Failure Effects 

Classification (FEC) of TASAR, which plays a significant role in determining the extent of 

certification and operational approval requirements that must be addressed. EFB industry 

standards adherence requirements were identified for TASAR and a detailed review of FAA 

guidelines and regulatory requirements were made. A certification plan for TASAR was developed 

for future TASAR approval. Certification and operational approval requirements were identified 

and underwent review with in-house Designated Engineering Representatives (DERs) as part of 

an approval “Dry Run.” NASA and Rockwell Collins then met with key decision makers at FAA 

in a technical interchange which validated our analysis findings provided in Section 4. 

2. TASAR Overview and High-Level Description 

The TASAR EFB application is currently being developed by NASA in order to leverage emerging 

flight deck technologies for cost benefits to current flight operations. The TASAR operational 
3

concept is described in [1] and [2] with the TASAR application description found in [3]. Reference 

[4] describes NASA’s work in developing TASAR as a near-term, low-cost application. Reference 

[2] also provides a description of TASAR operational scenarios. A preliminary benefits assessment 

of TASAR is found in [5]. Screen shots of Version V2 of the TASAR Human Machine Interface 

(HMI) design are provided in [3]. An overview of the operational safety and certification 

assessment of TASAR is provided in [6] with a detailed operational hazards and safety 

requirements analysis of TASAR provided in [7]. 

Among the systems technologies that comprise or support TASAR are flight-optimizing software 

algorithms, a software hosting device such as a Portable Electronic Device (PED) EFB, ADS-B 

IN and other sources of traffic information, and additional airborne sensor data and ground-based 

information via data link, internet connectivity, etc. TASAR seeks to provide cost-beneficial 

optimization with respect to the current flight plan, taking traffic and other constraints into account. 

Using these information sources, the TASAR application has the ability to react in an agile manner 

to changes in the airspace environment (e.g., adverse weather, winds, airspace constraints, and / or 

improved timeliness and accuracy of information about factors that affect the aircraft’s execution 

of its flight plan). 

TASAR employs a flight deck-based application that seeks to identify and recommend trajectory 

improvement opportunities to the pilot that have a high probability of approval by ATC. Utilizing 

available information of own-ship flight status/plan and airspace environment (e.g., proximate 

traffic, weather, winds, ATC system status, etc.), the TASAR application seeks to identify and 

recommend candidate trajectories for consideration by the pilot that have higher probability of 

ATC approval. The pilot, at his or her discretion, can choose to issue a change request to ATC 

based on TASAR recommended trajectory change candidates. 

Prior to recommending trajectory change candidates to the pilot, TASAR uses available on-board 

traffic data to account for potential conflicts. It uses weather and restricted airspace data to avoid 

these hazards. It may also account for known ATC rules to increase likelihood of approval. Thus, 

recommended trajectory change request candidates from TASAR to the pilot are expected to have 

the following characteristics that will encourage increased pursuit of flight plan improvements by 

the pilot from ATC via change requests: 

1) Provide ongoing optimization of the flight plan in terms of time and / or fuel savings or 

other desired attributes such as passenger comfort. 

2) Meet operational goals for the flight, as provided by pilot preference inputs

3) Have a high potential for approval by ATC by considering ATC constraints in the 

identification process 

TASAR trajectory change request candidates are advisory-only to the pilot, and the pilot has full 

discretion on whether or not to select a TASAR-provided trajectory change for a subsequent 

change request to ATC. Pilot training ensures that the pilot’s priorities (aviate, navigate, and 

communicate) and proper coordination with ATC, (e.g., change requests) are followed as in 

today’s operations. The pilot has responsibility to evaluate TASAR-provided trajectory change 

candidates for operational acceptability before making a change request to ATC. 

As in today’s operations, ATC has separation responsibility and is authorized to deny change 

requests from the pilot that do not meet ATC constraints and requirements. TASAR makes no 

changes to the rules and procedures that govern the interactions between pilots and controllers. 
4

Summary of TASAR Research Results from this Contract 

As described below in the main body of this report, the TASAR EFB application was analyzed in 

detail against applicable FAA regulatory documents to determine certification and operational 

approval requirements that must be met to gain approval for use as an advisory decision support 

tool to the flight crew. Operational hazard analyses were conducted to determine the TASAR 

Failure Effects Classification (FEC) and associated safety requirements. The results of these 

analyses were presented to FAA certification (AIR) and operational approval (AFS) authorities by 

NASA and Rockwell Collins as part of an information meeting held at the FAA office. The FAA 

AIR and AFS authorities concurred with the findings of our certification and operational approval 

requirements analysis and confirmed that the TASAR EFB application would be considered for a 

Class 2 EFB and be representative of a Type B application. They also noted that the TASAR 

application would be approvable using a “Minor Effect” FEC due to potential workload 

considerations and would warrant a “No Effect” designation from a loss of function perspective. 

For software and hardware-specific approval requirements, FAA concurred that there are no 

software airworthiness approval requirements for TASAR as a standalone application. TASAR, as 

a standalone application, does not require DO-178B compliance in its development even for a 

Design Assurance Level D. Some software-specific requirements will need to be addressed if 

TASAR is hosted on a platform that is also hosting other certified applications. 

The majority of certification-related compliance requirements for the TASAR EFB system fall 

into the hardware domain. Airworthiness regulations apply to installed EFB components and do 

not apply to the portable EFB components, including internal components of the EFB. For TASAR 

this primarily involves the installed components related to mounting (size and weight), power 

(maximum electrical load, voltage, and current frequency), and data connectivity (input/output 

data specifications and security). Software and hardware-specific requirements are discussed in 

detail in the body of this report. 

In addition to the analyses of certification and operational approval requirements leading to future 

approval of the TASAR application by FAA, this contract also developed and performed two HITL 

human factors experiments using the TASAR EFB application integrated in the University of Iowa 

OPL Boeing 777 simulator. The goal of these HITL studies was to determine via objective and 

subjective measures the impact of TASAR on the conduct of flight operations (including nonnormal situations), as well as to evaluate the HMI at two stages in its design. The development, 

execution, and analyses of the two HITL simulation experiments represents Task 2 of this contract 

and are provided in a separate document [0]. 

3. Research Tasks and Activities 

This section identifies the specific research tasks and associated activities that were performed in 

Task 1 of this contract. The objectives of Task 1 were to perform analyses and assessment of the 

TASAR EFB application to support its near-term implementation, i.e., to gain early certification 

and operational approval of TASAR by FAA approval authorities.

The implementation assessment tasks and activities described in this report are intended to 

generate guidance that ensures that all preparatory research and development by the TASAR team 

(NASA, Rockwell Collins and OPL, and other TASAR contractors) have maximum applicability 
5

toward enabling the near term implementation of TASAR. The description and results of these 

activities are documented in Section 4. 

The analyses and assessments performed and documented herein identify the requirements for 

equipment certification, operational approval, and user / FAA acceptability for entering TASAR 

into operational service. They serve to refine the TASAR concept in collaboration with NASA 

and other TASAR contractors by engaging the user community and the FAA, subsequently lead 

to strategies and requirements for implementation of the TASAR concept. 

The following represent the research activities performed in support of Task 1 of this Contract: 

1. User Community Survey (see Section 4.1 for details) 

a. Design a User Community Survey on current aircraft-operator practices for 

improving trajectories while aircraft are en route (Section 4.1.1) 

b. Review results of NASA’s preliminary data analysis; provide additional findings and 

recommendations for the TASAR concept and implementation strategies that would 

accelerate user adoption of TASAR (Section 4.1.2) 

2. Certification and Operational Approval Requirements (see Section 4.2 for details) 

a. Analyze TASAR for comprehensive operational hazards. Define and document 

safety requirements to mitigate the operational hazards (Section 4.2.1) 

b. Determine TASAR requirements for adherence to industry standards for aircraft 

systems development and EFB devices; determine and document the specific design, 

development, test, validation, and approval requirements necessary for entering 

TASAR into operational service (Section 4.2.2) 

c. Analyze TASAR with respect to FAA guidelines and regulatory requirements for 

certification and operational approval; determine the most appropriate and efficient 

methods and processes for pursuing certification and operational approval, and 

produce a corresponding detailed plan (Section 4.2.3) 

d. Develop representative TASAR artifacts for certification and operational approval 

processes. “Dry run” these processes with in-house Designated Engineering 

Representatives (DER). Document the review process, the DER’s feedback, and the 

associated changes to the artifacts and processes (Section 4.2.4) 

e. Determine the additional certification and operational approval requirements, if they 

exist, of the TAP HMI Version 4 as a “delta” analysis to the findings of the 

certification and operational approval requirements analyses (Section 4.2.5). 

3. Engage the FAA community in coordination with NASA, including the directorates 

responsible for certification and operational approval, to research FAA guidance for 

entering TASAR into operational service (Section 4.3). 

4. Research Program Description and Documentation of Results 

This section provides a detailed description of the research activities conducted in Task 1 and the 

results of this research. Research results focus on the implementation assessment of TASAR and 

identify certification and operational approval requirements and artifacts that can be used toward 

gaining FAA approval. 
6

4.1 User Community Survey 

As part of its development of the TASAR application, NASA tasked Rockwell Collins to develop 

a user community survey of key stakeholders in order to gain insight into their operations to inform 

the development of the TASAR application. Rockwell Collins developed the initial draft survey 

and then worked jointly with NASA and a contractor subject matter expert to collaboratively refine 

and further develop the survey that was then used by NASA in engaging the operators. Three 

aircraft operators were surveyed representing 1) a major network carrier (i.e., global operator), 2) 

a domestic low-cost airline, and 3) a fractional operator of business aircraft. Surveyed within these 

operators were pilots, dispatchers, and flight operations personnel. The surveyed operators 

represent a relatively broad spectrum of potential users of TASAR. 

4.1.1 TASAR User Survey Overview 

The goal of the TASAR survey was to solicit information from potential end users of TASAR 

concerning their current flight operations, with specific focus on flight planning and re-planning 

in today’s airspace operations. The survey requested information on a notional flight in terms of 

“challenges” and their frequency of occurrence during flight operations and flight re-planning in 

the presence of changing conditions affecting the flight. The survey requested response on 

available support tools, information sources utilized, and their effectiveness (i.e., well-served or 

under-served) in achieving efficient flight operations. The survey also sought information on 

current and planned avionics equipage of operator fleets that are closely aligned with the type of 

capabilities associated with TASAR. 

The survey included questions directed at various stakeholders within each operator organization, 

including pilots, dispatchers, and flight operations personnel. Tables 1, 2, 3, and 4 summarize 

survey questions in tabular format. NASA provided a consolidated data set of survey results that 

integrated the individual responses from each stakeholder survey. Approximately 12 pilots and 12 

dispatchers responded from the three operators surveyed. It was this consolidated data set that was 

reviewed in order to provide the observations and recommendations that will be discussed in the 

next section (Section 4.1.2). 

The TASAR User Community Survey consisted of four sections. The initial section, summarized 

in Table 1, represents survey topics that focused on the demographics of the operator. Table 2 

represents survey topics requested from the pilot community of the operator. Table 3 summarizes 

the survey topics that pertained to dispatchers, and Table 4 lists survey topics addressed to the 

operator’s flight operations. 

Table 1 Operator Survey Questions by Category – Operator Demographics 

Survey Topic 

Operator 

Demographics 

Category Detail 

Type of Operator E.g. major air carrier, domestic airline, 

fractional operator, etc. 

Aircraft fleet size <10, 11-49, 50-99, 100-500,>500 aircraft 

Fleet mix Type / make of aircraft 

Stage Length Short haul (<2 hr. flight), medium haul (2 to 4 

hr.), long haul (greater than 4 hrs.) 

Typical flight departure and arrival 

airports Hub, non-hub airport 

Number of active pilots 

Peak airborne number of flight 
7

Number of dispatchers 

Number of dispatchers on duty during 

peak operations 

3rd party in-flight optimization Not for flight planning, but service support 

during flight 

Table 2 Operator Survey Questions by Category – Pilots 

Survey Topic 

Pilot Survey 

Questions

Category Detail 

Years of experience 

Flight categorization by level of 

challenge 

Percentage of flights viewed as minimally, 

moderately, or extremely challenged – level of 

disrupted operations due to environmental 

factors, e.g., weather, adverse winds, airspace 

disruptions, traffic delays, security event 

Estimated impact in terms of fuel burned 

and flight time of “actual” flight when 

compared to “original” pre-departure 

flight plan 

Under various challenge levels (minimally, 

moderately, extremely challenging flight 

conditions) 

Impact of ATC constraints on operational 

efficiency 

In-flight re-planning capabilities 

available to pilots 

E.g., Flight Management System (FMS), 

automation / manual cockpit tools, company 

provided, 3rd party provided, other 

Effectiveness of in-flight re-planning 

capabilities 

• Provided by dedicated company personnel – 

without tools; with tools 

• Provided by automated monitoring, advisory 

service–company resource; 3rd party 

• Achieved by pilot, with tools 

Typical number of change requests per 

flight Function of stage length 

Types of change requests during en-route 

operations 

E.g., change requests for altitude, heading, 

lateral route, speed, or combination 

Level of coordination of change requests 

with dispatcher 

Percentage of change requests coordinated 

with dispatcher 

Type of coordination of change requests 

with dispatcher 

Initiation and coordination of change request 

with/without dispatcher 

Type and Frequency of action by ATC in 

response of change request 

E.g., immediately approved, cleared after 

standby, etc. 

Reasons for denial of change request E.g., traffic, traffic congestion, weather 

routing, metering, controller workload, other 

4.1.2 Survey Results, Findings, and Recommendations 

This section provides an overview of the review and assessment of received TASAR survey 

responses and NASA’s preliminary consolidation and analysis of these responses. The objective 

of the analysis performed by Rockwell Collins was to determine findings and recommendations 

for the TASAR concept and implementation strategies that would accelerate user adoption of 

TASAR. Detailed results of the TASAR User Survey analysis are found in Appendix A. 

Recommendations and observations derived from the analysis of TASAR user survey responses 

fall into two categories as follows: 

1) Equipage for TASAR 
8

2) TASAR cost benefits, usability, and synergy with dispatch and ATC processes. 

Table 3 Operator Survey Questions by Category – Dispatcher 

Survey Topic 

Dispatcher Survey 

Questions

Category Detail 

Years of experience 

Average number of flights managed per 

dispatcher 

Peak number of flights managed per 

dispatcher 

Organizational policies and procedures With respect to level of empowerment for pilot 

to perform flight re-planning 

Automation tools for monitoring flight 

efficiencies Available automation tools 

Adverse factors affecting original flight 

plan Adverse weather, metering, etc. 

Constraint factors affecting flight replanning 

Connecting flight, fuel reserve, lack of 

sufficient information on flight or airspace 

status, lack of accurate and timely weather 

information, etc. 

Available flight planning capabilities 

Company provided with/without tools, 

company automated monitoring, 3rd party 

automated monitoring, etc.) 

Information sources for Dispatch support 

Accurate convective weather forecasts, wind 

speed / direction / temperature, airspace status, 

airport facility status / weather / traffic 

information 

Priority ranking of information sources 

for Dispatch support 

Effectiveness of information sources for 

Dispatch support 

Comments on areas lacking and 

insufficient information for dispatch 

Comments on areas of information 

source improvement 

Time spent on flight optimization 

Effectiveness of current flight 

optimization capabilities 

Under various levels of challenged flights 

(minimally, moderately, extremely challenged) 

Level of flight planning constraint 

impacts in being able to achieve desired 

(unconstrained) flight 

Reason for flight re-planning by dispatch In-flight emergency, equipment failure, low 

fuel reserve, significant weather, etc. 

Time savings threshold for initiating an 

en-route re-plan 

Fuel savings threshold for initiating an 

en-route re-plan 

4.1.2.1 Equipage for TASAR 

Based on survey responses from the three operators surveyed, a favorable finding is that from an 

equipage perspective, the operators surveyed in many cases are beginning to equip with the type 

of avionics systems and associated EFB and data communication capabilities needed to enable 
9

TASAR. ADS-B OUT (primarily 1090 MHz), EFB Class (1, 2 or 3), internet access (via terrestrial 

and/or satellite networks) and data communications (Aircraft Communications Addressing and 

Reporting System (ACARS), Controller Pilot Data Link Communications (CPDLC)) are already 

in their plans. ADS-B IN (1090 MHz and/or Universal Access Transceiver (UAT)) plans are 

considerably less certain. 

Ͷ Ȃ	

Survey Topic 

Flight Operations 

Survey Questions 

Category Detail 

Avionics equipage current and plans

(today, in 2 years, by 2020) 

• ADS-B Out 

• ADS-B IN 

• 1090 MHz, UAT 

• EFB Class (1, 2, and/or 3) 

• EFB Operating System (Windows, Linux, 

iOS

• Internet Access – terrestrial and / or satellite 

based 

• Data Communications via ACARS 

• Data Communications via CPDLC 

Priority rating of cost factors affecting 

flight path performance 

Fuel, flight time, schedule integrity, ride 

quality, other 

Level of costliness of cost factors 

Revenue impact sensitivity rating for 

operational factors 

E.g., on-time performance, fuel efficiency, ride 

quality, other 

Rating of level of disruptiveness of flight 

factors 

E.g., poor forecast of winds, airspace 

disruptions, etc. 

Assessment of actual versus original 

flight plan performance 

With respect to flight time, fuel burned, ontime arrival 

Factors that adversely affect performance Weather, metering, etc. 

Company constraints to be consider by 

pilots when initiating en route flight replanning. 

E.g., arrival sequence with other organization 

flights, gate availability, critical connections, 

requirement for fuel stop, etc. 

In this regard, the Fractional Operator, with its fleet of business and regional aircraft, is already 

well equipped with data connectivity to ground systems. The two airline (air transport) operators, 

particularly the Global Network Carrier, are more reliant on ACARS and data communications 

and are currently not as connected to internet data networks, but this is improving. It is 

recommended that data connectivity be strongly encouraged for all operators to provide the most 

effective information access for TASAR. While TASAR’s traffic awareness is highly desirable, a 

prolonged period of mixed ADS-B equipage (both ADS-B OUT and ADS-B IN) is likely a reality 

for several more years, with the ADS-B OUT mandate in the United States not becoming a 

requirement until 2020. Cost benefits that can be gained from TASAR may help with this, but 

these must be fairly significant to create the pull for ADS-B IN equipage on their own. More likely, 

additional beneficial ADS-B applications for NextGen will need to assist with this pull. 

The most significant and encouraging finding is that the operators surveyed, representing a 

significant cross-section of aircraft operators, are beginning to have avionics and associated EFB 

and data communications capabilities capable of supporting early introduction of TASAR. 

 
10

4.1.2.2 TASAR Cost Benefits, Usability, Synergy with Dispatch & ATC Processes 

In order to achieve a positive business case for TASAR, two key requirements must be achieved: 

1) Access to relevant, quality (i.e., accurate, timely {sufficient update rates, sufficient 

latency}) information sources (both ground-based and flight-deck based)

2) Synergistic integration of TASAR with available flight (re)planning tools and processes 

used by dispatchers and pilots, while also being consistent with Air Traffic Control 

processes (i.e., change requests, traffic flow management including arrival flows). 

Without sufficient quality and completeness of information, TASAR is unlikely to provide reliable 

cost benefits. Pilot acceptance of TASAR is likely dependent on TASAR providing consistent and 

believable trajectory change recommendations with the indicated savings in fuel and/or flight time 

being actually achieved. In the longer term, TASAR’s utility should be integrated in a consistent 

manner with other flight planning and flight optimization processes utilized by Dispatch and 

should be consistent with ATC processes and procedures. 

While initial studies indicate the benefits of TASAR [5], a thorough assessment of TASAR cost 

benefits is likely required. Current on-going and planned flight simulations (University of Iowa 

OPL pilot evaluations in the use of TASAR using a Boeing 777 simulator), flight trial (Advanced 

Aerospace Solutions, LLC flight evaluation of TASAR using their Piaggio Avanti P180 aircraft), 

and ongoing research by NASA can assist in development of the TASAR business case.

The following, in no particular order, represent the collection of general observations and 

comments identified regarding current flight planning and in-flight re-planning procedures, tools, 

information sources and their effectiveness (or lack thereof) as determined from survey responses 

from pilots, dispatchers, and flight operations personnel from the operators surveyed: 

1) From a Dispatch perspective, significant weather as observed by Dispatch or per notification from the pilot or ATC is the primary reason for re-planning of the flight. Airspace 

disruption notification from ATC follows weather as the next key factor for re-planning. 

2) Dispatchers rate the effectiveness of current flight optimization capabilities (and the 

available time to perform those duties) as moderately effective (4+ of 7, with 7 being most 

effective). These capabilities were slightly more effective for “minimally impacted” flights 

and slightly worse for “extremely impacted” flights due to adverse environmental factors. 

3) Weather is a primary consideration for dispatchers, with ATC constraints, airspace 

disruptions and constraints being a somewhat secondary factor (still important but not at 

the level of weather). Conversely, for pilots, ATC constraints and airspace disruptions are 

a larger factor, with en route weather being a secondary, less constraining factor in in-flight 

re-planning.

4) Tools provide a range of strategic and tactical capabilities with respect to monitoring flight 

efficiencies. Tactical tool capabilities seem to focus on Dispatch gaining access to a 

specific aircraft’s Flight Management Computer (FMC) for position reports and associated 

flight parameter data and do not appear to provide a tactically integrated view of flight 

operations. TASAR has the ability to provide a more integrated tactical view from the 

specific own ship’s perspective, factoring in environmental constraints with respect to the 

current flight path. 
11

5) Timeliness, accuracy, and breadth of information must continue to improve to enable effective flight re-planning. At the same time, information management is required to avoid 

dispatcher information overload of excessive information detail and rapidity of updates. 

This requires intelligent automation to support dispatchers to allow them to manage the 

planning and re-planning of flights while keeping workload at reasonable levels. 

6) It is evident that both dispatchers and the pilot can benefit from improved information, 

particularly related to weather. Airspace information seems to be less of a factor. TASAR 

likely plays a tactical role in re-planning of the flight, while the role of Dispatch is more 

strategic.

7) From pilot survey inputs concerning use of tools it is noted that tools are generally 

employed. Without tools, any support is not viewed as effective: 

a. Hands-on company support is used significantly (80+ %) and is moderately to very 

effective. Automated monitoring and advisory services are used less frequently but 

when used, are effective. Most pilots (80%) do not use 3rd-party automated 

monitoring and advisory service support. Effectiveness was rated best for the more 

impacted flights (extremely and moderately challenged) due to adverse 

environmental conditions. 

b. Pilot in-flight re-planning with tools is heavily used (90%) and very to moderately 

effective (used a bit less when extremely challenged – perhaps due to pilot 

workload). Without tools, pilots still attempt to try to consider re-planning, but only 

with somewhat effectiveness at best. 

c. Survey results and insight into the pilot tools used (except for the FMS, which is 

always used), are not very specific and would require further investigation and 

dialog with pilots. 

8) Pilots have considerable latitude for making flight changes, particularly for altitude and 

speed changes, guided by the company Operations Control Manual. Request for route 

changes are more likely to require dispatcher approval. Sufficient pilot empowerment is in 

place at the surveyed operators to allow utilization of TASAR capabilities to seek 

improvements to the current flight plan. 

9) From a Dispatch perspective pertaining to time spent on flight optimization, there is a tradeoff on time spent versus savings achieved; if airlines are not focused or motivated to spend 

additional time to improve the efficiency of flights, then they either do not have the means 

to do better (i.e., in the way of tools and available quality information), or it is not a big 

cost issue to be considered. It is unlikely that they are just not focused on seeking cost 

improvements due to lack of focus and is likely related tool availability. 

a. A follow-up question would be concerning which flights should Dispatch expend 

more effort on optimization – long haul and/or international flights? Also, once 

operators are able to operate in a more “free flight” airspace perhaps in NextGen, 

with fewer constraints imposed (versus the more rigid route structures of today’s 

operations), then more significant gains can be made, and greater focus on 

optimization by Dispatch may be warranted. 
12

10) Dispatcher can inquire position reports from the FMC and derive additional real-time 

information on current flight parameters, which is viewed as a very effective re-dispatch 

and re-evaluation tool. 

a. From survey responses, Dispatch tends to play a relatively limited role for in-flight 

re-planning. This is particularly the case for the Global Network Carrier surveyed, 

which only provides support services while the aircraft is in-flight when prompted 

by pilot requests. 

b. A potential area of research is to determine to what extent should Dispatch focus 

on in-flight re-planning, which is currently not their focus, or should this be 

delegated to flight-deck tools, e.g., TASAR. What is the proper balance of Dispatch 

versus aircraft-based in-flight re-planning to ensure synergy? In addition, to what 

extent can TASAR take on flight planning typically done by dispatch, particularly 

in future NextGen operations that support “free flight” capabilities? 

11) TASAR, with good (i.e., pertinent, accurate, and timely) information on ATC metering and 

flow management and weather information (especially en route and at the destination 

airport), has the potential to provide significant tactical re-planning capabilities for 

operational efficiency. With TASAR, the key issue is its usability, i.e., providing benefits 

while at the same time being streamlined with operator dispatch, own ship flight procedures 

using the FMS, and with ATC’s overall air traffic control paradigm (change request 

clearances, traffic flow management, arrival management, etc.). 

12) A number of improvement opportunities are identified as a result of survey responses. It 

would be beneficial to more closely evaluate the major aspects of flight planning and replanning processes and how they translate into successful conduct of the flight. Further 

analysis on which information elements and how improvements in information quality will 

provide improved flight planning and in-flight re-planning is warranted. 

13) Additionally, the roles of Dispatch in planning and in-flight re-planning, in conjunction 

with the role of the flight deck (applications and flight crew capabilities) in performing inflight re-planning using tools such as TASAR should be clearly delineated and allocated 

synergistically for maximum benefit. In addition, re-planning in the presence of changing 

environmental factors needs to be accomplished in a consistent way with current and future 

ATC processes and procedures. 

In summary from an aircraft equipage perspective, TASAR is poised to be readily achieved, with 

the possible exception of ADS-B IN. A positive cost benefit business case is a key requirement for 

operators to continue to equip and enhance their avionics, EFB and data communications level of 

equipage for their aircraft fleets. Perhaps the most significant challenge is the development of a 

more robust cost benefit assessment for TASAR that supports synergistic usability with Dispatch 

and ATC processes as part of the in-flight re-planning to achieve operational efficiencies in the 

presence of changing environmental conditions (e.g., weather and airspace disruptions). 

Note: While survey results were carefully reviewed, survey questions and corresponding 

responses are at times qualitative and subjective in nature. In addition some responses 

represent only a small sample and thus cannot be used to make fundamental conclusions 

and extrapolations. However, the three operators represented in the survey and the 

comprehensive questions and responses from the various stakeholders involved in flight 
13

planning and flight execution do allow reasonable conclusions to be drawn that were used 

to inform the TASAR research team in developing updates to the TASAR application. 

4.2 Certification and Operational Approval Requirements 

This section examines the certification and operational approval requirements for TASAR. The 

analysis begins with a comprehensive operational hazards analysis and defines and documents 

safety requirements that serve as mitigations to potential operational hazards (Section 4.2.1). 

Section 4.2.2 determines TASAR requirements for adherence to industry standards for aircraft 

systems development and EFB devices. Specific design, development, test, validation, and 

approval requirements needed for entering TASAR into operational service are also documented 

in this section. 

Section 4.2.3 provides an analysis of TASAR with respect to FAA guidelines and regulatory 

requirements for certification and operational approval and determines the most appropriate and 

efficient methods and processes for pursuing certification and operational approval. A 

corresponding detailed plan for approval is provided. 

TASAR artifacts for certification and operational approval processes were identified and 

underwent a “dry run” review with DERs at Rockwell Collins for feedback to determine if any 

changes to the artifacts and the approval processes were deemed necessary. These are documented 

in Section 4.2.4. 

The TAP HMI has undergone redesign by NASA to incorporate pilot feedback based on HITL 

simulation experiments and from actual flight trials. Section 4.2.5 documents the results of an 

analysis of NASA’s TAP HMI Version 4 to assess certification and operational approval 

requirements. Specific focus of this analysis is on the TAP HMI V4 graphical elements depicting 

aircraft navigation information (e.g., routes, heading), traffic information, weather and airspace 

information, and wind information. The analysis provides observations with respect to regulatory 

reference on specific HMI changes to reduce the threshold for certification and operational 

approval.

4.2.1 TASAR Operational Hazard and Safety Requirements Analysis 

This section provides the results of safety analyses performed to identify Operational Hazards and 

Safety Requirements for TASAR as an application that can be hosted on a PED / Portable EFB. 

Two safety assessment methodologies were used that are compliant with the FAA’s Safety 

Management System (SMS): 

Method 1 A traditional safety assessment identification of hazards for the intended function 

of the system being developed, determination of worst credible effect due to the 

hazard, and subsequent FEC using ARP 4761 [9], AC 23-1309 [10] and AC 25-

1309 [11] for Part 23 and Part 25 aircraft operations 

Method 2 RTCA DO-264 / EUROCAE ED 178A Operational Safety Analysis [12]. 

The full report of the Operational Hazard and Safety Requirements Analysis is found as a NASA 

Contractor Report [7]. 
14

4.2.1.1 Approach to Safety Assessment 

Two safety assessment approaches were used to determine the FEC for TASAR. FECs are based 

on Operational Hazards and available mitigations that were identified using these two methods. 

As presented below, the two safety analyses conclude that the worst case FEC for TASAR will 

likely be of “No Effect” and no higher than “Minor Effect.” This determination is subject to 

evaluation and approval by cognizant FAA certification and operational approval organizations 

responsible for authorization of EFB applications. Supporting rationale for the “No Effect” 

designation is provided in the safety analyses in 4.2.1.4 and 4.2.1.5 below. 

Note: NASA and Rockwell Collins met with FAA certification (AIR) and operational approval 

(AFS) authorities and presented the approval requirements described in this report to them. 

They indicated that TASAR would warrant a “Minor Effect” FEC due to workload 

considerations, but noted that from an operational failure perspective, the “No Effect” 

designation is justified. Section 4.3 discusses the results of the meeting with FAA. 

4.2.1.2 Safety Assessment Methodology High-Level Description 

ͶǤʹǤͳǤʹǤͳ ͳ

Method 1 (i.e., based on the analyses indicated by ARP-4761, AC 25-1309, AC 23-1309) 

represents the traditional system safety process for airborne systems and equipment, e.g., TASAR. 

This method performs the following steps relative to the intended function of the new system 

capability: 

1) Evaluate the intended function per phase of flight 

2) Identify failure events, e.g., loss of function; undetected, erroneous trajectory change 

request(s), etc. 

3) Examine the effect of the these failures on aircraft, pilot (or flight crew), and ATC 

4) Determine the Hazard Classification, e.g., Major, Minor, No Effect 

5) Determine frequency of occurrence, e.g., per flight hour, per operation 

6) Provide rationale for hazard assessment. 

ͶǤʹǤͳǤʹǤʹ ʹ

Method 2 (i.e., based on RTCA DO-164 / ED-78A) represents a system-of-systems analysis 

approach that is well-suited for allocating safety requirements across a multiple-system function. 

This allows a more balanced allocation of safety requirements across systems and sub-systems, 

which is particularly beneficial for higher criticality systems. While an excellent approach for 

systems analysis, it is not as well suited for lower criticality systems such as TASAR. This is 

particularly true in the realm of “Minor” criticality systems, where this approach puts excessive 

emphasis on formal analysis related to operational effects such as workload (pilots and air traffic 

controllers), which are often highly subjective and difficult to assess in a quantitative manner. 

Method 2 follows the following evaluation steps: 

1) Perform an Operational Hazard Assessment (OHA) 

a. Identify Operational Hazards 

b. Determine the worst credible outcome of the Operational Hazard, i.e., the 

Operational Effect, e.g., collision, loss of separation, workload, etc. 
15

c. Determine the Severity Classes for each Operational Effect, e.g., Catastrophic, 

Major, Minor, etc., and identify the maximum allowable probability of occurrence 

of the Operational Effect 

d. Determine the Effects Probabilities , which represent the probabilities of available 

mitigation(s) to the system to help reduce the probability of occurrence of the 

Operational Effect due to the Operational Hazard 

e. Assign Safety Objectives, which represent the probability of occurrence of each 

Operational Hazard that is allowable for ensuring the safety of the application 

f. Identify External Mitigation Means, i.e., barriers external to the application that 

reduce the adverse effects and impact to safety when Operational Hazards occur. 

2) Allocate Safety Objectives and Safety Requirements 

a. Identify Abnormal Events and Basic Causes internal to the applications that could 

lead to the occurrence of each Operational Hazard 

b. Identify Internal Mitigation Means, i.e., barriers internal to the application that 

reduce the probability of the Operational Hazard from occurring in order to achieve 

the required Safety Objective 

c. Allocate Safety Requirements to the sub-functions comprising the application. 

4.2.1.3 Trajectory Change Requests – Today’s Operations 

This section briefly describes the trajectory change request process in today’s operations between 

the pilot and ATC for making change requests to the current flight plan. As conditions change 

during flight, it is common for the pilot to request an amendment to the ATC-cleared trajectory, 

e.g., to meet some need for safety, efficiency, or ride quality / comfort for passengers. 

In today’s operations, pilot requests are often made with little or no awareness of the traffic 

situation or ATC sector considerations. Some of these change requests are denied by ATC for the 

following reasons: 

1) Change request conflicts with other traffic 

2) Change request conflicts with sector procedures in use by ATC 

3) Change request is requested too close to the next sector handoff 

The effects of denial of a change request by ATC to the pilot are: 

1) Unnecessary workload burden on ATC 

2) Discourages the pilot from making future requests to improve their flight 

3) Flight improvement opportunities are often unrealized because pilot may not be aware of 

requests that would improve efficiency and be ATC approvable. 

In general, the pilot seeking opportunities of improved safety, efficiency or ride quality has rather 

limited awareness of many of the factors that would adversely affect ATC acceptability of change 

requests to the current flight plan. This environment is not conducive for the pilot to seek 

operational efficiency improvements due to lack of situational awareness of the external 

environment that may constrain changes to the flight plan. 
16

The next section explores a new TASAR capability that serves as an advisory-only tool to the pilot, 

providing informed trajectory change request candidates for pilot consideration as possible change 

requests to ATC for operational benefit. 

4.2.1.4 TASAR “Intended Function” Description 

TASAR is a flight deck-based decision aid consisting of software automation algorithms and a 

primarily textual display and is intended as an advisory-only service to the pilot to seek trajectory 

improvement opportunities over the current flight plan. TASAR is expected to be a hosted software 

application on an EFB. A Class 2 EFB installation is anticipated, with TASAR becoming a future 

Type B software application, pending successful certification and operational approvals by FAA. 

The TASAR EFB will interface to avionics as read-only (i.e., it will not transmit to avionics) as 

defined in the current concept of operations. 

Note: A comprehensive assessment of FAA EFB regulations and guidance on PED / Portable 

EFB-based flight deck application was made under this contract and is presented in subsections of Section 4.2 below. Feedback from FAA approval authorities on the TASAR 

application is also provided below in Section 4.3 and in Appendix E of this report. 

Based on inputs provided by 1) the pilot (in the form of flight objectives and optimization criteria), 

2) on-board avionics systems, and 3) airborne internet data connectivity, the TASAR application 

computes available trajectory change request candidates that may improve the current flight plan. 

Trajectory change request candidates provided by TASAR are intended to have relatively high 

probability of ATC approval if requested by the pilot, as TASAR seeks to provide flightoptimizing, traffic-avoiding recommended trajectory candidates that anticipate ATC and airspace 

constraints.

The pilot has full discretion on the use of TASAR-provided trajectory change request information; 

they can choose to use TASAR-recommended trajectory change request candidates as part of a 

change request to ATC, or they can choose to ignore them. TASAR can be manually inhibited at 

any time, for any reason. Thus, in the event of observed spurious behavior of TASAR due to any 

system failure, inaccurate data obtained via network enabled information sources, or TASAR 

being a source of distraction to the flight crew, the pilot can simply inhibit or ignore TASAR. By 

following their training, the pilot can manage the use of TASAR in such away so that TASAR will 

not result in any workload increase in the flight deck. 

TASAR is a supplemental system intended to provide operational benefits, without adversely 

impacting safe operations, and it does not replace any aircraft system or procedure needed for 

flight operations. The TASAR display is passive without explicit display of traffic and own ship 

position nor audible alerting. Loss of the TASAR EFB application for any reason does not affect 

the Minimum Equipment List (MEL) and does not affect normal flight operations. 

TASAR information sources may include the following: 

1) Own ship systems (aircraft state, auto-flight settings, flight plan and performance 

information from FMS, etc.) 

2) Traffic data via ADS-B IN, Traffic Information Services Broadcast (TIS-B), or other 

sources via airborne internet 

3) Airspace system status and forecast (sector use and configuration, Traffic Management 

Initiatives, Special Use Airspace (SUA), etc.) 
17

4) Weather status / forecast 

5) Wind status / forecast 

6) Operator flight planning, preferences, and objectives. 

4.2.1.5 Method 1 Safety Analysis – Conventional Method 

This section addresses the safety assessment of TASAR using the traditional system safety process 

based on ARP 4761 [9], AC 23-1309 [10], and AC 25-1309 [11]. The key outcome of this safety 

assessment process is the determination of the FEC of the TASAR application. The FEC then 

drives the development and validation requirements and processes to be followed in integrating 

TASAR into the flight deck to gain certification and operational approval. 

Using this safety assessment process (i.e., Method 1), applicants and certification and operational 

authorities (i.e., FAA aircraft certification and flight standards organizations) follow the process 

of assessing the new application and attendant procedures for potential failure modes and their 

impact on safety. 

ͶǤʹǤͳǤͷǤͳ 		

The following list represents key factors that influence the determination of the FEC for TASAR: 

1) TASAR is a supplemental system and thus is not relied on by critical functions supporting 

flight deck operations 

2) TASAR use is optional, i.e., not a required system for flight operations. In the event of 

failures of the TASAR system, TASAR can be ignored or disabled without adversely 

affecting operations 

3) TASAR has no MEL requirement 

4) TASAR can be manually inhibited at any time, for any reason 

a. Detected failure of the TASAR application 

b. Detected failure of the host EFB 

c. Spurious or inconsistent performance of recommended trajectory change requests 

d. Distracting effects of TASAR to the pilot 

5) Presence or loss of TASAR does not change responsibilities of the pilot for flight 

operations

6) TASAR is an “advisory-only” system (i.e., does not provide guidance information) 

a. Pilot is not reliant on TASAR outputs to any extent to perform flight operations 

b. Pilot can choose to either utilize or ignore trajectory change candidate 

recommendations from TASAR as part of change requests to ATC 

7) Change request procedures are unchanged. 

a. Pilot must direct all change requests to ATC using conventional means 

b. ATC is responsible for reviewing request for acceptability, including separation 

from traffic 

c. ATC either 1) approves request and issues clearance, 2) provides an amended 

clearance, 3) defers request to next controller, or 4) denied request 

8) Undetected, misleading information associated with TASAR recommendations will have 

“No Effect” on the pilot, aircraft, and/or on ATC. Whether due to failure of one of the 
18

TASAR sub-systems and associated automation processing, or being the result of 

inaccurate data obtained from ground-based or flight deck systems, spurious change 

requests are mitigated by flight crew inspection of the recommended trajectory change and 

by mitigation associated with the existing change request process. 

ͶǤʹǤͳǤͷǤʹ 	ȋ	Ȍ

Figure 1 (from [11]) provides a mapping of the “Effects” due to failures and the allowable 

“Probability of Occurrence” that lead to the determination of the FEC of the planned application 

(i.e., TASAR). Based on the above noted factors alone, this safety analysis (Method 1) comes to 

the conclusion that TASAR can be safely developed and implemented with a “No Effect” 

designation. Potentially, in the worst case, TASAR could rise to a “Minor Effect” designation in 

event of inconsistent candidate trajectory change request recommendation(s), which could result 

in workload issues (for the pilot and / or ATC). However, workload issues are not anticipated to 

be an issue for the pilot’s use of TASAR, as the pilot can simply ignore TASAR for any reason. 

Through proper training in the use of TASAR, the pilot should not allow to be distracted or be 

adversely influenced in using TASAR while conducting flight operations. From an ATC 

perspective, controllers will continue to conduct the trajectory change request process as in today’s 

operation and are not expected to experience a workload issue due to TASAR. 

Note: Based on our Technical Interchange Meeting with FAA approval authorities, FAA noted 

that TASAR would be viewed as a “Minor Effect” EFB application due to pilot workload 

considerations. Refer to Section 4.3 and Appendix E for results of our meeting with FAA 

approval authorities on the TASAR EFB application. 

Figure 1 Acceptable Risk versus Potential Effects (Defined for Civil Aviation) 
19

ͶǤʹǤͳǤͷǤ͵ 

The TASAR application itself provides additional inherent capabilities that further reduce the 

possibility of unintended adverse effects and are expected to enhance the usability of the 

application. These further serve to strengthen and support the “No Effects” FEC for TASAR: 

1) In order to prevent lengthy, complex trajectory change requests from the pilot to ATC, 

TASAR utilizes standard navigation databases and places limits on excessive waypoints 

included in the recommended change requests it provides 

2) TASAR displays flight path change opportunities using standard phrasing to facilitate 

voice communications 

3) TASAR may include capabilities to assess sector complexity and own ship’s proximity 

to the sector boundary in order to only recommend change requests that have a high 

likelihood of being approved by ATC. 

ͶǤʹǤͳǤͷǤͶ 

1) An additional characteristic of TASAR is that there is no “recovery” time required for the 

flight crew associated with its use. In other words, in using TASAR, the pilot remains on 

an ATC-cleared trajectory at all times. In the event of a TASAR system fault, the pilot need 

only remain on the current clearance while disregarding the TASAR display. A simple 

reset of TASAR, or by simply choosing to ignore TASAR inputs (e.g., by not looking at 

the TASAR display) allows the pilot to continue to focus on primary tasks in conducting 

flight operations (whether during normal operations or in the event of abnormal or 

emergency situations) 

2) The pilot has responsibility to evaluate TASAR-provided trajectory change candidates

before making a change request to ATC, providing cross-check opportunities to detect 

spurious or false trajectory change candidates being offered by TASAR 

3) Aircraft systems, e.g., FMS, weather radar, serve as available, higher integrity information 

allowing quick check on acceptability and performance impacts of TASAR recommended 

trajectory change requests 

ͶǤʹǤͳǤͷǤͷ 	

1) From a phase of flight perspective, TASAR is intended for use primarily during en-route 

operations

a. Trajectory change request candidates are offered by TASAR during the later 

portion of climb, while en-route, and to a lesser extent, into the early portion of 

descent operations 

b. TASAR is thus used primarily during non-critical phases of flight, i.e., above 

10,000 ft. 

ͶǤʹǤͳǤͷǤ͸ 

1) Due to the “No Effect / Minor Effect” FEC anticipated for TASAR, TASAR information 

source quality and integrity must be commensurate to support this FEC. 

a. TASAR input information quality and integrity requirements are driven not by 

safety considerations but by operational use considerations. 
20

b. Low quality and/or misleading information can result in poor recommendations to 

the pilot for candidate trajectory change requests. The net effect is that TASAR will 

not be as effective in achieving envisioned operational benefits (e.g., time or fuel 

served). 

ͶǤʹǤͳǤͷǤ͹ 	Ȃ

1) From a TASAR Undetected Failure perspective, inefficient routing is the only adverse 

outcome. Existing mitigation of any safety hazards is provided by ATC, as already is done 

for trajectory change requests today.

Note: The Safety Analysis using Method 2 (based on the Operational Safety Assessment {OSA} 

of DO-264 / ED-78A) described in the next section takes a closer look at specific failure 

modes of TASAR. 

4.2.1.6 Method 2 Safety Analysis – Operational Safety Assessment Process 

This section provides the safety analysis of TASAR using the Operational Safety Assessment 

(OSA) process from RTCA DO-264 / EUROCAE ED-78A [12], referred to as Method 2 in this 

report. Figure 2 illustrates the process at a high-level using the ‘bow-tie’ model. 

Figure 2 Operational Safety Assessment Process – Method 2. 

In Figure 2, the system of interest, in this case the TASAR application, is represented in the lefthand side of the “bow-tie”. The external environment in which the application operates, including 

environmental conditions (e.g., airspace influences, weather, traffic) and the external systems that 

are part of the overall operational concept (e.g., aircraft systems and ATC systems), are represented 

by the right-hand side of the “bow-tie.” 

The OSA process consists of the following major sub-processes: 1) the Operational Hazard 

Assessment (OHA), and 2) Allocation of Safety Objectives and {Safety} Requirements (ASOR). 
21

In performing the OHA, the first step is to use operational experts from all stakeholder 

communities to identify potential Operational Hazards that may result from the application (e.g., 

TASAR). For each identified Operational Hazard, the next step is to determine the worst “credible” 

outcome, also referred to as the Operational Effect (OE). Examples are collision, loss of separation 

(major loss versus minor loss), workload, etc. 

For each Operational Hazard and associated Operational Effect, the Severity Class is determined. 

Severity Classes include catastrophic, severe major, major, minor, and no effect. For each 

Operational Effect and associated Severity Class, a “Probability of Occurrence” not to be exceeded 

to assure safety of operations are established, ranging from 10-9, 10-7, 10-5, 10-3, etc. for occurrence 

of the Operational Effect. The Operational Effects and Severity Classes are noted in Figure 2 on 

the right side of the bow-tie. 

Figure 3 provides a mapping of hazards to “the associated effects on operations due to each hazard 

class. The likely regions of applicability for the TASAR OSA process described in this section are 

highlighted in Figure 3. The highlighted regions represent “Minor” and “No Effects” FECs. 

Figure 3 ED78A/DO264 Based Hazard Classification Matrix 

From the OHA sub-process, each Operational Hazard is assigned a Safety Objective that it must 

meet in order to assure safe operations. It is the task of the ASOR to ensure that the Safety 

Objective is met. It is noted that for each Operational Hazard, there could be multiple Operational 

Effects, thus resulting in multiple Safety Objectives being assigned to each Operational Hazard. 

The ASOR must assure that all Safety Objectives are met for each Operational Hazard. 

In order to mitigate the effects of the Abnormal Events and Basic Causes identified as root causes 

of failures, it will be necessary to identify relevant mitigations internal to the application, denoted 

as Internal Mitigation Means. These mitigate the effects of Abnormal Events and Basic Causes to 
22

achieve the Safety Objectives for each Operational Hazard. This then also allows specifying Safety 

Requirements that are associated with sub-system elements internal to the application. The 

combination of Abnormal Events, Basic Causes, Internal Mitigation Means, Safety Objectives and 

Safety Requirements are illustrated by the left-side of the bow-tie. 

The OSA process in [12] is beginning to be widely used by EUROCONTROL and FAA in the 

development of Safety, Performance, and Interoperability Requirements for ADS-B IN 

applications. This process is well suited for higher criticality system-of-systems and allows a more 

formal analysis process using fault trees and event trees. Fault Trees are typically used to capture 

the left-hand side “bow-tie” process of the ASOR, while Event Trees are typically used to represent 

the OHA process characterizing the external environmental factors represented by the right-hand 

side of the bow-tie. 

Note: While the strength of the OSA process is that it is able to analyze complex, high-criticality 

system-of-systems and allows for a relatively balanced approach for allocating integrity 

requirements across all systems, the process may not be as well suited for lower-criticality systems, 

e.g., TASAR, as the fault tree and event tree methodologies and associated calculations begin to 

become onerous in terms of their ability to analyze the more qualitative and subjective aspects of 

these types of applications. It is also often quite difficult to quantitatively prove probabilities 

associated with workload factors and performance of the human to perform various functions. This 

often times becomes a significant and time consuming (and costly) issue in gaining approval for 

the safety requirements that result from using the methodology. 

Note: Considerable consideration has been given in this report to the identification of Operational 

Hazards potentially associated with TASAR. However, the report intentionally stops short of 

performing a quantitative analysis of the Safety Objectives and the probabilities of the barriers 

provided by the mitigations identified, since TASAR was determined to have a “No Effect” or in 

worst case a “Minor” FEC. The OSA presented is thus an abbreviated OSA relative to [12]. 

ͶǤʹǤͳǤ͸Ǥͳ 

Before commencing with the identification of Operational Hazards using the Method 2 OSA 

approach in this section, it is noted that the same high-level factors and mitigation already 

described in 4.2.1.4 (Method 1) also apply here. The next step takes a closer look at Operational 

Hazards that could occur using the TASAR application. 

As noted earlier, Operational Hazards result from Abnormal Events and Basic Causes , which 

represent errors and failures in actions associated with the human operator (e.g., the pilot), or 

systems functions (e.g., TASAR automation). Abnormal Events include both errors by the pilot in 

relation to TASAR use and in interactions with ATC as part of the change request procedure. 

To more closely examine potential sources of errors associated with actions by humans and 

TASAR automation processing, Figure 4 illustrates potential information flows within the NASA 

TASAR application, TAP. 

From Figure 4, the following information exchanges associated with human and automation 

processing actions represent potential sources for errors and misleading information that may 

result in Operational Hazards: 
23

Figure 4 TASAR Functional Diagram* 

*Note: The information elements identified in Figure 4 are notional at this point and are being 

refined as part of the detailed design of TASAR. 

ͶǤʹǤͳǤ͸Ǥʹ 

The following list identifies human actions that provide the opportunity for occurrence of 

Abnormal Events (i.e., when human actions are performed in error): 

1. Pilot, flight crew 

a. Enters TASAR configuration, objectives, and optimization criteria via the TASAR 

HMI

b. Receives and interprets TASAR data via the TASAR HMI 

i. e.g., recommended trajectories, conflict status, fuel reserve status, etc. 

c. Communicates change requests to ATC 

2. Air Traffic Controller (en-route) 

a. Provides separation assurance services 

b. Communicates change request clearances to pilots 

Note: As the detailed design for TASAR is being developed, there is a concern that some route 

and constraint data may not be readily accessible from onboard systems and that it may be 

necessary that some of this data be manually entered by the pilot. This raises the potential 

of increased pilot workload that may become a concern for usability of the TASAR 

applications and could factor into the OSA as a workload issue; it may also increase the 

possibility of false data entry by the pilot.
24

ͶǤʹǤͳǤ͸Ǥ͵ 

The following actions performed by TASAR (i.e., decision support algorithms) provide 

opportunity for occurrence of Basic Causes (i.e., when actions by automation are erroneous): 

• TASAR-related processing that could result in undetected misleading information. 

Any misleading information provided by information sources to TASAR, or errors and failures in 

TASAR automation processing, could potentially result in misleading trajectory change request 

candidates being recommended to the pilot for consideration. Such misleading information may 

detract from the usability of TASAR to achieve operational benefits. However, since the flight 

crew has no authority to deviate from their ATC clearance, regardless of the information provided 

by TASAR, any occurrence of misleading information from TASAR will be non-hazardous in 

nature and is completely mitigated by the ATC clearance procedure. 

Detailed assessment of Abnormal Events and Basic Causes associated with TASAR are discussed 

in [7]. 

Detailed List of Potential TASAR Operational Hazards 

Table 5 provides a list of the Operational Hazards identified using the OSA process described in 

this section. Associated mitigations, internal or external to TASAR, are also identified. 

ͷ 

Operational Hazard Description Mitigation

OH – 1: TASAR could provide one or more 

change request candidates that are not 

conflict free

This Operational Hazard is the result of poor 

information quality and/or mixed ADS-B Out equipage 

environment, where not all traffic is known

ATC provides separation assurance 

independent of TASAR

OH – 2: Pilot could misinterpret TASAR 

candidate change request and could 

unknowingly request a trajectory 

clearance that is not conflict free or could 

lead toward hazardous airspace

TASAR could “inadvertently” mislead or confuse the 

pilot who could then misrepresent the TASAR change 

request to ATC

ATC provides separation assurance 

independent of TASAR

Aircraft safety systems (e.g., Traffic Alert and 

Collision Avoidance System, weather radar, 

Terrain Awareness and Warning System) 

provide hazard detection and alerting

OH – 3: Pilot could follow the wrong 

trajectory clearance following receipt of 

amended clearance from ATC

Pilot could request a change recommended by the 

TASAR system, and although ATC amends the request, 

TASAR-induced confusion could lead the pilot to follow 

the request instead of the clearance

ATC monitors execution and intercedes 

(same as today)

Pilot training

Pilot crosschecks clearance with FMS

OH – 4: ATC, somehow being aware of 

TASAR capability for the aircraft / pilot 

requesting a change request to the flight 

plan, could be less vigilant to provide 

separation assurance

The concern is whether ATC could become complacent 

over time, when receiving TASAR requests 

(note that TASAR equipage is not specified on filed 

flight plans or included in pilot-request verbiage)

Existing ATC procedure to check all requests 

for separation

Note: This is not a credible Operational 

Hazard because separation assurance is 

ATC’s primary responsibility

OH – 5: TASAR could provide numerous 

spurious and/or inconsistent series of 

change request candidates leading to 

multiple requests

If change request recommendations are not reinforced 

from one request to the next, multiple counteracting 

requests could be issued

These requests could become a nuisance issue and 

potentially could lead to a workload issue for ATC

ATC denies user requests if workload is too 

high

OH – 6: TASAR could recommends a 

trajectory candidate with miscomputation 

of fuel burn

Pilot reliance on TASAR fuel burn estimates (presented 

to help pilots choose between multiple request 

options) could lead to greater fuel burn than expected

Pilot crosscheck of FMS prediction of fuel 

burn
25

Operational Hazard Description Mitigation

OH – 7: Unexpected weather could 

develop on TASAR recommended route 

after ATC approval

Unexpected weather could require additional change 

requests and therefore more fuel to be used

Normal procedures for responding to 

unexpected weather

Reviewing the above Operational Hazards, it is noted that due to the very strong and significant 

mitigations already provided by ATC separation assurance and pilot procedures in today’s very 

safe operations, the worst case safety effect could potentially be workload for pilot and/or 

controllers. Since TASAR is an advisory-only system and can be manually inhibited by the pilot 

at any time, for any reason, the most likely FEC for TASAR would be “No Effect”. With the “No 

Effect” or perhaps “Minor Effect” FEC, TASAR is amenable for integration as an EFB application. 

Note: Based on our Technical Interchange Meeting with FAA approval authorities, FAA noted 

that TASAR would be viewed as a “Minor Effect” EFB application due to pilot workload 

considerations. Refer to Section 4.3 and Appendix E for results of our meeting with FAA 

approval authorities on the TASAR EFB application. 

The safety analysis in this section strongly indicates that the TASAR EFB application at most 

warrants a “Minor Effect” FEC. The following subsections of Section 4.2 address EFB standards 

adherence requirements (Section 4.2.2), analyze TASAR with respect to FAA guidelines and 

regulatory requirements for certification and operational approval (Section 4.2.3), and develop 

representative TASAR artifacts for certification and operational approval processes (Section 

4.2.4).

4.2.2 TASAR Requirements for Adherence to Industry Standards 

This section documents the results of an analysis conducted to identify EFB standards adherence 

requirements for TASAR. While not yet directly providing the certification and operational 

approval artifacts for TASAR certification (discussed in Section 4.2.3), this section identifies the 

steps toward such approvals and makes observations as they apply to the TASAR application. This 

section focuses primarily on EFB hardware and software requirements, including installation 

considerations.

Note: The TASAR Operational Hazard and Safety Requirements Analysis in Section 4.2.1 above 

has already determined that TASAR will at most have a “Minor Effect” FEC which was 

confirmed in our meeting with FAA approval authorities (Section 4.3). 

4.2.2.1 Applicable FAA Regulatory and Guidance Documents 

This section summarizes key documents that are applicable as FAA regulatory or guidance 

documents for certification and operational approval of EFBs and their attendant applications. The 

following is among the list of documents reviewed or considered in assessing EFB standards 

adherence requirements for TASAR described herein: 

1. AC 120-76C, Guidelines for the Certification, Airworthiness, and Operational Approval 

of Electronic Flight Bag Computing Devices [13].

This document is intended for all operators conducting flight operations under Title 14 of 

the Code of Federal Regulations (14 CFR) part 121, 125, 135, or 91 subpart F (part 91F) 

and part 91 subpart K (part 91K). It is a key guidance document for EFB use with 

applicability to TASAR. 
26

2. Flight Standards Information System (FSIMS) – 8900.1 Change 47, Vol. 4, Chapter 15 – 

EFB Operational Authorization Process [14]. 

This document provides the FAA approval perspective, providing the Principal Operations 

Inspector (POI) checklists followed for EFB and associated applications approval, 

including approval considerations for TASAR. This is a key document that identifies the 

EFB authorization process and provides detailed guidance on the checklists that must be 

addressed with the POI. 

3. AC 91.21-1, Use of Portable Electronic Devices Aboard Aircraft [15].

This document addresses the use of PEDs, including their potential to hazardously affect 

aircraft communication and navigation equipment. It allows the use of non-transmitting 

PEDs during non-critical phases of flight (e.g., >10,000 ft., which is currently the intended 

use for TASAR). It is noted that it may be desirable to use TASAR in the later stages of 

climb, and early stages of descent, perhaps below 10,000 ft.; this should be allowable due 

to the low FEC expected for TASAR, pending FAA approval as TASAR undergoes 

certification and operational approval. Wireless connectivity for TASAR could be 

considered as a Transmit PED (T-PED) and may require the ability to demonstrate isolation 

of the T-PED from interfering with avionics (e.g., communications and navigation 

systems). 

4. AC 20-173, Installation of Electronic Flight Bag Components [16]. 

5. AC 21-16, RTCA Document DO-160 “Environmental Conditions and Test Procedures for 

Airborne Equipment” [17]. This document pertains to Electro-Magnetic Interference 

(EMI) requirements for read-only data interfaces to avionics and High Intensity Radiative 

Fields (HIRF) requirements for transmit data interfaces to avionics. TASAR requires only 

read-only access to avionics and thus will need to meet EMI requirements (or delegate this 

requirement to an Aircraft Interface Device through which the TASAR EFB may interface 

to the avionics systems. In addition TASAR wireless connectivity likely requires additional 

isolation testing (i.e., TASAR as a T-PED) to ensure non-interference to avionics systems. 

6. TSO-C195 (i.e., RTCA DO-317 – ASAS MOPS), Avionics Supporting Automatic 

Dependent Surveillance – Broadcast (ADS-B) Aircraft Surveillance Applications (ASA)

[18]. This document pertains to TASAR for ADS-B IN/OUT performance requirements, 

but not for traffic display purposes, which is not applicable for the TASAR HMI. 

7. SAE ARP 4761, Guidelines and Methods for Conducting the Safety Assessment Process 

on Civil Airborne Systems and Equipment [9]. Applicable for TASAR Safety Assessment 

of Operational Hazards. 

8. AC 23.1309-1, System Safety Analysis and Assessment for Part 23 Airplanes [10]. 

Applicable for TASAR Safety Assessment of Operational Hazards. 

9. AC 25.1309-1, System Design and Analysis [11]. Applicable to TASAR system design. 

10. SAE ARP 4754A, Guidelines for Development of Civil Aircraft and Systems [19].

Applicable to TASAR system design. 

11. AC 20-115, RTCA, Inc., Document RTCA/DO-178B [20]. This is not applicable to TASAR, 

as TASAR is expected to be at most a “Minor” failure effect classifcation. This document 

is primarily for Type C applications, e.g., applications that require depiction of own ship 

position and/or are of “Major” or higher FEC. 
27

12. AC 20-152, RTCA, Inc., Document RTCA/DO-254, Design Assurance Guidance for 

Airborne Electronic Hardware [21]. This is not required for “Minor” FECs, as a Class 2 

EFB FEC suffices; not applicable to TASAR. 

13. AC 20-159, Obtaining Design and Production Approval for Airport Moving Map [22].

This document pertains to the display of own ship position, e.g., display and airport surface 

situational awareness applications hosted in EFBs. This is not applicable to TASAR per 

current concept of operations and HMI design. 

14. AC 25-11A, Electronic Flight Deck Displays [23]. Applies to Class 3 EFBs, i.e., installed 

as part of flight deck and is not applicable for TASAR. 

15. AC 91-78, Use of Class 1 or Class 2 Electronic Flight Bag (EFB) [24]. This is not 

applicable to TASAR, as it relates to Type A applications that apply to replacement of 

paper and other documentation. 

16. TSO-C165, Electronic Map Display Equipment for Graphical Depiction of Aircraft 

Position [25]. Not applicable (NA) to TASAR as it related to display of own ship position; 

not part of TASAR concept of operations and HMI design. 

17. RTCA/DO-257A, Minimum Operation Performance Standards for the Depiction of 

Navigational Information on Electronic Maps [26]. Not applicable to TASAR; not part of 

TASAR concept of operations and HMI design. 

4.2.2.2 Summary of EFB Standards Adherence Requirements 

In establishing EFB standards adherence requirements, the EFB application’s intended function 

and associated FEC directly impact certification and approval requirements. The TASAR intended 

function was examined earlier in Section 4.2.1.3; TASAR is an optional, advisory-only decision 

support tool to recommend trajectory change improvement opportunities to the pilot / flight crew. 

As such, TASAR is supplemental equipment, does not replace any required avionics functions, 

and is not needed as part of the MEL for flight operations. Use of TASAR is at the discretion of 

the pilot, i.e., the pilot may choose to ignore TASAR or can manually inhibit its operation at any 

time for any reason. 

Analysis of TASAR operational hazards and safety requirements suggests that TASAR at most 

warrants a “Minor Effect” FEC, and may in fact be of “No Effect” in terms of safety impact. This 

makes TASAR amenable as an EFB application (refer to Section 4.2.1 and [7]). 

Note: Section 4.3 confirms the “Minor Effect” FEC designation based on feedback from FAA 

approval authorities (Section 4.3). 

While TASAR, as a new EFB application, does not map directly into already defined Type A or 

Type B applications, it has many of the characteristics of a Type B application. Thus TASAR is 

well aligned with Type B applications; yet it is somewhat less stringent than typical Type B 

applications in terms of FEC per its intended function. TASAR is viewed to be of Type B. 

Note: FAA approval authorities indicated that although not explicitly identified as a Type B 

application in AC 120-76, they consider TASAR to be of Type B (refer to Section 4.3). 

In addition, TASAR is expected to be implemented as a Class 2 PED / Portable EFB. The Class 2 

EFB requirement is due to the read-only interface needed by TASAR to on-board avionics systems 

and data link connectivity via installed antennas for accessible information sources, e.g., weather 

information. 
28

As a Class 2 EFB, a mounting device is required for TASAR with the following attendant 

requirements (for the installed mounting device): 

1) must have operational suitability in all ground and flight operations and conditions 

2) must not interfere with flight crew duties 

3) must be easily stowed when not in use 

4) must not obstruct primary or secondary fields of view, and 

5) must not obstruct egress. 

As the TASAR EFB is portable (i.e., not installed permanently as part of the flight deck), it must 

be easily removable, without tools, by the pilot / flight crew member. The EFB must be accessible 

to the pilot / flight crew. A cockpit mount is recommended / selected for TASAR as compared to 

a yoke mount to facilitate operational approval and for a more cost effective installation. 

Because TASAR is primarily utilized during en-route operations, generally above 10,000 ft., it is 

primarily used during non-critical phases of flight. However, due to its relatively low FEC, i.e., 

low-criticality of the TASAR application, it is expected to also be useable during the later portion 

of climb and early portion of descent operations and is not expected to adversely affect these more 

critical flight phases. 

The EFB standards adherence requirements examined are expansive and detailed in nature. 

Appendix B documents these results; specifically the roles and responsibilities of the operator, 

manufacturer, installer, avionics vender, and also of FAA certification and operational approvers 

of newly developed EFB applications, such as TASAR. 

4.2.2.3 FAA Principal Operations Inspector (POI) Checklists 

The following represent the checklists that are used by the POI as part of the EFB approval process 

and are found in [14]. They are addressed later in more detail in Appendix D but are provided here 

for initial reference: 

• Figure 4-79 represents Checklist 1, ”Tabletop Electronic Flight Bag Evaluation 

• Figure 4-80 represents Checklist 2, “Electronic Fight Bag Operational Evaluation” 

• Figure 4-81 represents the “Evaluation Report Information Template” 

• Figure 4-82 represents Checklist 4, “Electronic Flight Bag Line Evaluation Job Aid”. 

4.2.3 FAA Guidelines and Regulatory Requirements for TASAR Approval 

This section examines FAA guidelines and regulatory requirements needed for the certification 

and operational approval of the TASAR EFB flight-deck application. It provides a conceptual plan 

that identifies anticipated steps to be followed that are expected to lead to successful certification 

and operational approval of TASAR. This section and Appendix C lay out this path to achieving 

approval without going through the actual certification and operational approval process. This 

information is provided to support a future certification effort for TASAR. Specifically it offers a 

Certification Plan for TASAR. 

Note: In our meeting with FAA approval authorities (see Section 4.3), FAA did not see the need 

for a Project Specific Certification Plan (PSCP) for the TASAR software, just for the 

installation. If the applicant already has an existing EFB installation, then the operational 

approval process is for a user to go directly to their POI. 
29

The results documented in this section also served as the basis for providing 1) representative 

artifacts for a DER review dry run, and 2) an analysis of DER feedback from this dry run, which 

are documented in Section 4.2.4 below. 

4.2.3.1 FAA Certification and Operational Approval Process – High-level View 

The FAA certification and operational approval of aircraft functions involves many disciplines 

in a highly interactive and coordinated manner in order to achieve product approvals that ensure 

their safe use in flight operations. This section provides a brief overview. 

Addition of new avionics functions or updates to existing functions typically involves issuance 

of one of the following: Type Certificate (TC), Amended Type Certificate (ATC), Supplemental 

Type Certificate (STC), Amended Supplemental Type Certificate (ASTC), Production 

Certification (PC) or other means. 

Key FAA organizations involved in this process of supporting and assessing the applicant’s data 

submittals for approval are the Aircraft Certification Office (ACO), Flight Standards Services 

(AFS), and the Aircraft Evaluation Groups (AEG). 

In order to achieve product approval requires multiple disciplines to be vetted and assured: 1) 

safety to demonstrate airworthiness, 2) manufacturing, 3) maintenance, 4) operations, etc. FAA 

ACO is responsible for assuring safety of new and updated avionics products and issues design 

approval via the approval process and guidelines for TC, STC, ATC, ASTC, PC, and other 

means. 

In addition to the safety assurance processes of proving the integrity of the product design, 

another key aspect of the approval process involves the manufacturing of the avionics product 

itself. Manufacturing regulations and guidelines involve additional processes, including assuring 

that parts are manufactured according to Technical Standard Order (TSO), Parts Manufacturer 

Approval (PMA), or using Conformity inspections. FAA Manufacturing Inspection District 

Offices (MIDOs) are responsible for assuring the correctness and quality assurance of the 

manufacturing of avionics parts. 

Initial engagement with FAA on a new or revised product approval may include dialog regarding 

orientation of the approval process, gaining some initial guidance before launching the actual 

certification project with FAA, and receiving a familiarization briefing about the process. This 

is then followed by launching the Certification Plan. 

4.2.3.2 Purpose of Certification and Operations Approval Plan 

The goal of the Certification and Operations Approval Plan {from here on referred to as the Project 

Specific Certification Plan (PSCP)} is to establish a framework plan and schedule between the 

applicant and FAA on how the applicant intends to demonstrate compliance of the new or revised 

system capability to the Federal Aviation Regulations (FARs). 

A proper certification plan assures the FAA that the applicant has reviewed the FARs and is aware 

of the applicable requirements that need to be addressed as part of the approval process. The 

applicant receives FAA concurrence (or receives feedback on what updates will be needed to the 

PSCP in case not all elements are properly addressed) that the PSCP describes an acceptable means 

of demonstrating compliance with the FARs. 
30

Note: There are multiple references made in FAA guidance documents concerning the 

Certification Plan, e.g., in FAA Order 8110.4C [27]. 

1) CP (Certification Plan) – previously not required by FAA in earlier versions, but now 

required by FAA in this latest order 

2) CPP (Certification Project Plan) – represents FAA’s ACO’s high-level project plan 

3) PSCP (Project Specific Certification Plan) – represents the composite of both the 

applicants and FAA’s project plan information. The PSCP contains elements of the CP 

and CPP and includes relevant details of the Certification Process Improvement (CPI) 

initiative [28] between FAA and industry. 

The key element of the PSCP is the Compliance Check List, which indicates that the applicant 

understands all appropriate regulatory requirements to be satisfied for achieving certification and 

operational approval. The Compliance Check List provides a summary of the regulatory 

requirements via reference and points to the type of associated data submittals (i.e., artifacts) that 

need to be provided to approving authorities. 

The PSCP is important as part of the engagement process with FAA for product certification and 

approval. The PSCP ensures that the individual elements of the plan take place in proper order and 

at designated timeframes. This allows for planning of personnel and resources by both the 

applicant and FAA and provides a roadmap for coordination, information exchanges, and 

milestone completion dates. Without a well-coordinated PSCP and associated schedule 

information, the certification project stands little chance for timely completion. 

Typically, preparation of the PSCP should begin as soon as the basic design has been determined 

in order to realize the benefits from up-front considerations of the FARs and engagement with 

FAA approvers. The PSCP should be submitted to the FAA as soon as possible after the design 

concept is firm. The PSCP needs to be submitted in advance of any requests to FAA for conformity 

inspections, test plans review, or compliance data reviews. 

The remainder of this document describes the generalized content of the PSCP and provides 

TASAR-specific context where appropriate. A high-level Compliance Check List is provided as 

an input to the as-yet-to-be-determined certification and operational approval project of the 

TASAR EFB flight-deck application. 

4.2.3.3 Project Specific Certification Plan (PSCP) 

FAA allows a general form of the PSCP to be followed, and numerous similar outlines to this plan 

are documented in various FAA guidance documents. FAA does not impose an exact format to 

this plan and allows latitude to applicants for tailoring the process to their respective needs. 

ͶǤʹǤ͵Ǥ͵Ǥͳ 

“The FAA and Industry Guide to Product Certification (CPI Guide)” [28], provides a good 

overview of the certification process that is described herein. 

There are five Certification Phases that move from early project concept and initiation through 

post certification activities. The content of the PSCP outlines the FAA and applicant agreement 

and operating practices for a Product Certification project. Each phase is built on early mutual 

awareness of key certification issues, commitment to planning and managing projects, early 

identification and resolution of issues and other elements to achieve the aforementioned vision. 
31

All phases contribute to improving safety and serve to mitigate cost and project risk. The five 

phases of certification are: 

1) Conceptual design phase 

2) Requirements definition phase 

3) Compliance planning phase 

4) Implementation phase 

5) Post-certification phase. 

To the extent warranted by the new or revised product (e.g., due its size and complexity) 

considerable up-front engagement of both the FAA and the applicant is a key part of the process 

represented by these certification phases. The certification process described here is applicable for 

all aircraft system certifications, from new aircraft developments to EFB applications. However, 

the process, level of involvement by FAA and the applicant personnel, and complexity of the PSCP 

can vary widely and typically is tailored to meet the objectives to ensure that the new or revised 

product is implemented in a manner to assure the safety of flight operations. 

The key FAA participants in this process are as follows: 

• FAA and applicant’s Management

o Make commitments to the certification project and provide leadership and 

resources

• FAA and applicant’s Project Managers

o Jointly orchestrate the PSCP 

• FAA Standards Staff Project Officer

o Provides timely standardized policy and guidance 

• FAA Engineers and Designees

o Apply regulations and policy to find compliance including the determination of 

the adequacy of type design and substantiation data 

• FAA Inspectors and Designees

o Determine conformity and airworthiness 

• FAA Flight Test Pilots and Designees

o Conduct FAA flight tests 

• FAA Chief Scientific and Technical Advisor

o Provides expert advice and technical assistance 

• FAA Aircraft Evaluation Group (AEG)

o Evaluates conformance to operations and maintenance requirements. 

A more detailed description of the roles of the key players is found in the CPI Guide [28]. 

The following is a description of each of the five certification phases, providing a definition of 

each phase, identifying expected tasks, required information, deliverables, and defining criteria for 

success. Deliverables of each phase are prerequisites before entering the next phase. 
32

The following list represents the criteria that should be applied to all phases of certification to 

ensure success: 

• Mutual trust; confidentiality; meet all commitments; emphasize empowerment 

• Open and timely communication 

• Proper level of technical project and management leadership with frequent reviews to 

maintain awareness of status, significant issues, and commitments 

• Early familiarization meeting(s); meetings with well-structured agendas and presentations 

attended by proper participants 

• Document agreements, issues, actions; agree to clear time frames, expectations, action 

plans

• Timely, high-quality documentation of decisions, agreements, schedules, milestones, 

action item assignments, compliance/conformance submittals and approvals. 

4.2.3.4 TASAR EFB Applications Assumptions 

The following assumptions will influence the certification requirements for TASAR: 

1) TASAR (as currently defined by the TASAR operational concept [1][2], and TAP 

application description [3]) is anticipated to be designated as a “No Safety Effect” FEC. 

This is based on the Operational Hazards and Safety Requirements Analysis in [7], which 

identifies a number of significant hazard mitigations resulting in this designation. 

This failure effects designation is subject to approval by FAA certification and operational 

approval authorities. The highest failure effects designation for TASAR should be limited 

to no greater than “Minor” in the unexpected event that workload issues are deemed an 

issue with TASAR by approval authorities. 

Note: After meeting with FAA, TASAR will be designated as “Minor Effect” due to 

potential pilot workload associated with TASAR due to misleading / bad data 

(Section 4.3). 

2) TASAR is expected to be implemented and hosted on a Class 2 Portable Electronic Device 

(PED).

TASAR requires a read-only interface to on-board avionics systems, but will not be 

transmitting information to avionics systems. 

TASAR is expected to utilize antennas for accessible information sources via commercially 

available communication data links and associated networks. These antennas may either 

be permanently installed or may be self-mounted. 

3) For this certification and operational approval plan (i.e., the PSCP), the TASAR Class 2 

EFB is expected to be installed as a “cockpit mount” in the flight deck. A cockpit mount 

allows for easy insertion and removal of the EFB by the flight crew. A cockpit mount is 

desired compared to a yoke mount, which is a more critical installation. The cockpit mount 

is not to be confused with a fully installed EFB per Class 3 devices, which is not planned 

for TASAR. 
33

Note: It is at the discretion of the implementer and end user on whether or not the portable 

TASAR EFB will remain un-mounted or be mounted in the cockpit while in use. 

Note: Per FAA feedback, the only certification requirements would be for mounting / 

installation of the EFB, getting one-way, read-only access to certified systems data 

(e.g., via ARINC 429 busses), and partitioning and protections for non-interference 

with certified systems. The Aircraft Interface Device (AID) is intended to 

accomplish much of this. FAA did not see the need for a PSCP for the TASAR 

software, just for the installation. If they already have an existing installation, then 

the operational approval process is for a user to go directly to their POI (Section 

4.3).

4) TASAR is expected to utilize an AID to serve as an intermediary interface to avionics 

systems. 

The use of an AID device is not an explicit requirement. However, since the TASAR Class 

2 PED/EFB is expected to utilize a Commercial-Off-The-Shelf (COTS) computing device, 

an AID is needed to serve as the interface between the PED and the avionics systems that 

provide information to the TASAR application. Without an AID, the COTS PED would 

require modification to the commercial product to provide the avionics interface and 

associated interference and security protections on its own. This of course significantly 

reduces the cost benefits of using COTS products to enable EFB applications in the flight 

deck.

5) The TASAR software application is closely aligned to Type B EFB applications per AC 

120-76C [13]. While not mapping exactly to the Type A or Type B software applications 

as defined in [13], TASAR is well aligned to Type B applications. TASAR is viewed to be 

Type B “Lite”. 

Note: After meeting with FAA, TASAR is viewed to be a Type B application. The 

additional designation as a Type B “Lite” should not be used. Type B designation 

is sufficient (Section 4.3). 

Similar to Type B applications, TASAR utilizes processing algorithms to achieve its 

intended function (i.e., it is not just used for storage and lookup of static database 

information as is the case for Type A applications). 

As additional mitigations for TASAR when compared to Type B applications, Type B 

applications may be used in all phases of flight including flight critical phases. TASAR is 

primarily used in en route operations and during the latter portion of climb and early stages 

of descent operations. More importantly, unlike typical Type B applications, which are 

relied upon to support flight operations, (e.g., providing weight and balance; and aircraft 

performance calculation) the TASAR application’s sole purpose is to seek and provide 

flight path improvement opportunities to the pilot. Thus while similar to Type B 

applications already approved by FAA, TASAR is expected to have a lower threshold to 

meet the safety and operational requirements compared to Type B applications. 

4.2.3.5 General Use Considerations 

1) Components of the Class 2 EFB include all hardware and software needed to support EFB 

intended functions 
34

a. A Class 2 EFB may consist of modular components (e.g., computer processing unit, 

display, controls) 

i. Any EFB hardware not accessible to the flight crew on the flight deck (e.g., 

AID, antenna for aircraft wireless) and/or not portable must be installed in 

accordance with the applicable airworthiness regulations (AC 20-173 [16]) 

2) Class 2 EFBs are typically mounted to the aircraft via a mounting device and may be 

connected to a data source, a hard-wired power source, and an installed antenna (e.g., 

TASAR)

3) To be considered portable, the EFB must be removable from flight deck without use of 

tools by flight crew 

4.2.3.6 Software-Specific Approval Considerations 

1) Class 2 EFB hardware, internal components, and software do not require FAA 

airworthiness approval 

2) For Portable EFBs, DO-178B does not apply even for minor failure effects 

Note: FAA confirmed that Type B applications running on non-certified hardware (e.g., 

Class 2 EFB) do not require DO-178B compliance (Section 4.3).

3) Type A and Type B applications are typically considered as “hosted” because they have no 

requirement to be installed as part of aircraft type design or as an alteration 

a. Such equipment would usually identify the hardware installed as miscellaneous, 

non-required equipment 

4) Portable EFBs are limited to Type A and Type B software applications – the Airport 

Moving Map Display (AMMD) for ground operations is a Type C application and is the 

only current non-Type A or B exception being allowed on portable EFBs 

5) Single or Dual EFB Configurations 

a. Allows for partitioned Operating Systems (OS) and software applications 

i. Separate DO-178B Linux and non-certified Windows OS 

ii. DO-178B approved software applications and non-DO-178B hosted 

software applications allocated to their respective EFB and partitioned OS 

b. “Hosted” and “Approved” software applications 

i. Need to demonstrate that hosted applications (e.g., TASAR) when 

integrated with approved applications do not interfere with them 

6) Downloads of newly revised software applications into the EFB must provide assurance 

(i.e., have a means to verify) that other approved applications are not adversely affected 

7) Type A and Type B software development process does not require DO-178B 

Note: FAA confirmed that Type B applications running on non-certified hardware (e.g., 

Class 2 EFB) do not require DO-178B compliance (Section 4.3). 
35

The following steps are required for software development in this case (i.e., non-DO178B):

a. Develop and review high-level requirements 

b. Develop architecture on low-level requirements; these do not have to be reviewed 

c. System requirements (all derived) 

d. Prove code meets high level requirements; no structural coverage needed to be 

demonstrated 

e. Ensure that high-level requirements 

i. Comply with system requirements 

ii. Are accurate and consistent 

iii. Are traceable 

4.2.3.7 Hardware-Specific Approval Considerations 

1) Airworthiness regulations apply to installed EFB components 

a. Do not apply to portable EFB components 

b. Must only address specifications associated with the installed components 

i. Mounting (size and weight) 

ii. Power (maximum electrical load, voltage, and current frequency) 

iii. Data connectivity (input/output data specifications and security) 

2) Class 2 EFB hardware, internal components, and software do not require FAA 

airworthiness approval 

3) EFB components are “installed” when they are incorporated into aircraft type design under 

14 CFR part 21 or as a proper alteration under 14 CFR 43.3 

a. All other EFB components are considered “portable,” regardless of how often they 

are removed from the aircraft 

4) Type A and Type B applications are typically considered as “hosted” because they have no 

requirement to be installed as part of aircraft type design or as an alteration 

a. Such equipment would usually identify the hardware installed as miscellaneous, 

non-required equipment 

5) An alternate view on certification consideration for “Non-Flight” Systems: 

A number of systems may be installed in an aircraft that do not affect the basic flight 

capability of the aircraft. Systems such as 1) passenger entertainment systems, 2) 

information systems, 3) data storage devices, and 4) potentially TASAR may fall into this 

category. 

Certification approval of such systems depends on their function, and the kinds of hazards 

that the system can present to the aircraft. 

Non-flight systems could be for use only on the ground or may be used on both ground and 

while airborne (e.g., TASAR). 
36

A primary concern in gaining approval for such systems is that the hardware needs to be 

compatible with the rest of the aircraft and its systems. Testing must ensure that operation 

or failure of the non-flight system does not affect the safe flight of the aircraft: 

a. in general, units must stay in place during a crash and must not fail in such manner 

to cause a hazard (such as fire or smoke) to the aircraft they are installed in 

b. the function of potentially affected systems determines what level of integrity and 

environment testing that must be completed to meet the certification and customer 

requirements 

c. if failure of the unit has no safety consequence (i.e., effect) then from a certification 

perspective, the unit only has to be shown to be airworthy. 

The certification of non-flight systems as described above is closely aligned with Class 1 

and Class 2 EFB hardware that support Type A and Type B applications and is expected 

to support TASAR (as a Type-B application). 

4.2.3.8 Project Specific Certification Plan (PSCP) Overview 

The following is a representative outline of a PSCP that is amenable for use with TASAR: 

1) Purpose or Introduction 

Identify the intent of the Certification Plan. 

2) Description 

A brief description of the system, product and associated application should be included or 

submitted as a separate document if the design description is not yet available in detail or 

is too complex. 

3) FARs 

Applicable regulations need to be listed by sections and subsections, including the 

amendment level if it differs from the certification basis established for the product. Any 

plans for exemptions, equivalent levels of safety, or special conditions should be included, 

if known. 

4) Compliance 

Tell how compliance will be shown. Provide analysis results of failures and safety 

performance. Indicate tests, e.g., vendor qualification tests, applicant ground tests on test 

rig, ground test on flight test article, and flight test. Demonstrate software compliance, 

show similarity, demonstrate the design, and provide inspection results. If compliance is to 

be through the use of unique methodology, it should be so noted in the certification plans 

and should then be covered by separate submittals and discussions. Compliance data should 

be made a part of the certification plan. 

5) Conformity 

Indicate what parts of the installation conformity will be required. Ensures that parts are 

built to specifications. 

6) Data
37

List the data to be submitted to show compliance. It is acceptable to give “to be determined” 

(TBD) report and drawing numbers. 

7) Airplane Flight Manual (AFM) 

Indicate if this document is affected and how it will be revised (or revised as an AFM 

supplement). 

8) Type Certificate Data Sheet 

Indicate if this document is affected and how it will be revised. 

9) Proposed DER(s) 

The project ACO must determine the appropriateness of assigning designees to represent 

the FAA, e.g., the Designated Engineering Representative (DER), Designated 

Manufacturing Inspection Representative (DMIR), Designated Airworthiness 

Representative (DAR), and others as appropriate for each project. The ACO may not 

delegate the authority to approve certain aspects of a project even though a DER may have 

previously been granted authority in that general area. 

10) Master Minimum Equipment List (MMEL) 

Indicate if the MMEL is affected and describe the intended minimum Dispatch 

configuration.

11) System Criticality 

For applicable systems, the results of the preliminary function hazard analysis need to be 

made known, e.g., system criticality, software criticality, functional failure conditions 

summary.

12) Schedule

Provide a schedule which shows the following: 

a. Significant milestones 

b. If applicable, identify when a preliminary hazard analysis will be submitted and 

when all detail data submittals will be made: 

i. Descriptive data submittals (drawings) 

ii. Substantiating data submittal (compliance reports) 

iii. Test schedule (when and where), including Type Inspection Authorization 

(TIA), e.g., conformity and airworthiness inspections

iv. Conformity inspection requests and schedule (parts, systems, and 

installation) 

v. Compliance inspection schedule 

vi. Final approval 

After the FAA has indicated concurrence with the PSCP, it is not necessary to reflect the approval 

by revising the report. The letter of concurrence is considered as sufficient evidence. FAA letters 

of concurrence can be used as updates to conditional approvals or to subsequent revisions of the 

PSCP without the need to revise the report, resubmit it and then wait for another FAA letter of 

concurrence.
38

4.2.3.9 Additional PSCP Activities and Artifacts for TASAR 

The following additional activities and associated artifacts are candidates for further preparatory 

tasks by NASA: 

• Hold an Informational Meeting / Pre-Certification Meeting with appropriate FAA 

personnel prior to launching an actual Certification Project. This would allow comments 

from FAA to be factored into the actual certification. 

Note: This meeting was in fact accomplished since initially recommended (Section 4.3). FAA 

seems open to further engagements with the NASA TASAR team, even without a formal 

applicant. However a formal applicant would be beneficial when in engaging with FAA. 

FAA also suggested engaging with the POI as appropriate. 

• Artifact development pre-Certification Project kickoff: 

1) Some artifacts have already been developed as part of NASA and TASAR team member 

development and analysis effort: 

• Understanding of EFB airworthiness requirements (per this document) 

• TASAR Concept of Operation [1][2], TAP Application Description [3] and 

associated intended function and HMI design 

• Safety Assessment; Analysis of Operational Hazards; Safety Requirements [7] 

• University of Iowa OPL human factors assessment of TASAR in a Boeing 777 

simulation environment 

• Advanced Aerospace Solutions’ TASAR flight evaluation using a Piaggio Avanti 

P180 aircraft in November 2013 [8]. 

2) Remaining, yet to be developed artifacts: 

• A second flight trial of TASAR is expected to be conducted in May 2015 

• Analysis and test results from Advanced Aerospace Solutions’ TASAR flight 

evaluation and demonstration 

• Activities and deliverables identified [28], typically as part of the five-phase PSCP 

process, but only informally with the POI: 

i. Informally complete the steps of the PSCP; FAA seems open to further 

engagements with the NASA TASAR team, even without a formal applicant. 

However a formal applicant would be beneficial when engaging with FAA. 

ii. Agreed Type Certification Basis 

1. Detailed Compliance Check List 

2. Demonstration of compliance 

3. Compliance and conformance requirements verification 

a. Completion of analyses, test plan submission, TIA (Type Inspection 

Authorization), conformities, flight test, AEG (Aircraft Evaluation 

Group) evaluations, critical issues resolution plan, and other items 

affecting the completion of the project 

b. Completed test plans/reports, conformity requests, inspections, and 

compliance documentation 

c. Compliance and conformance findings 
39

4. Foundation for continued airworthiness activities and certificate 

management for the remainder of the product’s life cycle (this is needed 

once certification approval has been obtained and is on-going life-cycle 

upkeep of the certification 

a. Airworthiness limitations 

b. Maintenance and operations requirements 

c. Design change data 

d. Compliance Summary Document 

e. Type Inspection Report 

f. Instructions for Continued Airworthiness 

g. Continued Airworthiness Management Plan 

3) The following is a list of potential deliverables for TASAR: 

i. Software documentation and demonstration: 

Since software process and software development documentation do not 

require DO-178B for TASAR, documentation requirements are not excessive. 

The following steps are required for software development in this case (i.e., 

non-DO-178B): 

1. Develop and review high-level requirements 

2. Develop architecture on low-level requirements; these do not have 

to be reviewed 

3. System requirements (all derived) 

4. Prove code meets high level requirements; no structural coverage 

needed to be demonstrated 

5. Ensure that high-level requirements 

a. Comply with system requirements 

b. Are accurate and consistent 

c. Are traceable 

In addition, demonstration or proof of 1) how TASAR does not adversely 

affect other applications that may be integrated in the same EFB, and 2) how 

software revision downloads ensure that operation of the application is not 

adversely affected 

ii. Drawings and specifications of “installed” components of the TASAR EFB 

(e.g., aircraft mount, power connection, data connection, antennas, etc.). 

Whether conformity inspections are required is TBD. 

iii. Airworthiness tests and results, e.g., electrical load testing of TASAR 

components with aircraft power sources, non-interference testing with 

avionics systems, etc. 

iv. Data that describes the product design for COTS and installed components. 

Electrical and mechanical performance data. Installation specifications. 

Additional NASA / avionics vendor collaboration could be in the following areas: 

1) Validation of requirements 
40

2) Growing the TASAR HMI concept to one using a map depicting the flight path, traffic, 

other airspace and environment information for increased pilot situational awareness and 

more effective use of TASAR for 1) operational benefit and 2) for more effective use of 

TASAR by the pilot / flight crew 

Note: NASA’s update of the TAP HMI, specifically Version 4 (V4) address many of the 

recommendations made here and has been reviewed for impact on certification and 

operational approval, which is discussed in Section 4.2.5. 

3) Next generation TASAR, which includes writing to avionics, e.g., flight route from a 

trajectory change request recommendation to FMS, to reduce pilot workload 

4) Transitioning TASAR from a decision aid making recommendations to a much higher 

integrity application toward supporting Autonomous Flight Rule operations. 

Note: As indicated throughout this document, the TASAR EFB application is a lowcriticality flight-deck advisory capability and does not require very stringent 

certification and operational approval requirements. Our meeting with FAA 

confirmed the analysis results we provided. However, TASAR is expected to serve 

as an entry level flight-deck capability and can provide the basis for higher costbenefit and higher criticality uses, e.g., for guidance and/or separation assurance 

intended functions. The PSCP guidance documentation in this report, while only 

partially required for TASAR, will be directly applicable for certification and 

operational approval of these more advanced applications that may be derived 

from extensions of TASAR and are thus documented in this report. 

4.2.3.10 Additional TASAR Related Certification Discussion Topics 

After initial certification and operational approval requirements were provided to NASA, NASA 

requested additional perspectives to these following 3 topics: 

Topic #1: Delineation of EFB Software vs. EFB Hardware Approval Requirements 

NASA requested clarification and further input on the somewhat blurry line between approvals of 

EFB software vs. EFB hardware. Also, since some operators will already have EFBs installed 

(with appropriate approvals) and may wish to consider TASAR as an add-on application, it would 

help to clarify the “delta” approvals required in this case. 

Response: With respect to the blurry line between EFB hardware and software, it is actually quite 

clear. For Type A and B applications, there are no software airworthiness requirements. Per FAA 

feedback (Section 4.3) TASAR is designated as a Type B application (related to performance and 

planning calculations), and thus falls into this category. 

From the hardware perspective, only installed elements of the EFB require airworthiness 

approval, e.g., the mounting, data connection (to avionics via an Aircraft Interface Device), 

connection to aircraft power, and internet communications via data links. AC 20-173 [16] 

provides the airworthiness requirements and points to other associated tests. The PED aspects of 

the EFB do not require airworthiness approval. 

If hardware is already in place, this will have already undergone airworthiness approval of the 

installed components. No other airworthiness approvals will be needed. In the event any aspect of 

the hardware is not the same as the original installation, an applicant needs to show similarity to 

the initial installation and note what has changed and indicate how the change may affect things. 
41

An example could be if a higher bus speed is used in the new installation (i.e., Mega-bits or Gigabits per second). This could alter the sensitivity to EMI and one may have to retest those aspects 

and any other changes to installed components to ensure continued airworthiness. 

From a software point of view, this will depend on what software functionality is preexisting and 

how TASAR is expected to be integrated into the existing software system (i.e., other already 

existing applications and the Operating System). If existing applications are also “hosted”, i.e., 

other Type A and B applications, then adding TASAR should not require any additional or significant precautions as software airworthiness is not required. Considerations would be whether 

one application will be performed at a time or if multiple concurrent applications would be in use. 

Some applications may run in the foreground, others could be running as background loops. 

However, while existing applications may serve as paper replacement or provide performance 

calculations, it is likely that one must show that TASAR (or any other new application) does not 

interfere with those applications (although no DO-178B process is required here). 

If TASAR software is integrated with “approved” software (i.e., those developed and approved via 

DO-178B and likely supplementing some of the aircraft communications, navigation, and 

surveillance (CNS) functions), this has considerably more significant impact on ensuring that 

TASAR does not interfere in this case. Likely some appropriate level of partitioning will be needed 

(e.g., time partitioning, one application executing at a time, memory partitioning, separate OS’s, 

separate EFB processors, etc.). As more and more EFB applications find their way on-board the 

aircraft, some being “hosted” with others being “approved,” a partitioned EFB system approach, 

e.g., a dual EFB processor system, would likely be needed, requiring, for example, a DO-178B 

certified OS for approved applications, while a non-DO-178B OS could be used for the hosted 

applications. An AID will also be required to enable any interfaces to aircraft systems and 

avionics.

Topic #2: Typical Duration of Certification and Operational Approval Process 

NASA Request #2: For similar-sized projects (i.e., other Type B applications) how long does 

certification and operational approval typically take; what issues must typically be dealt with? 

Response: Rockwell Collins has been working EFB-like products since at least 1999. Common to 

all of these product initiatives (whether or not they resulted in actual products), these development 

efforts laid initial groundwork on providing internet connectivity in the aircraft, providing 

information servers, services, and attendant applications for cockpit and cabin use, and performed 

the necessary steps toward certification and operational approval. Meetings were held with FAA, 

wherein engineering and certification personnel presented these development efforts, their plans 

for certification (i.e., certification project plans), and activities that had already been completed 

and were planned to be included as part of the approval process. 

An important point to consider is that when going to the FAA for the actual start of the certification 

project, much of the planning and homework can and should already have been accomplished for 

this level of certification (i.e., lower criticality levels of minor or below). This was confirmed by 

FAA at our technical interchange meeting (Section 4.3) and this should also be done for a TASAR 

Certification Project. 

While no firm baseline estimates are available in terms of time and effort required, in consultation 

with DERs, typically the engineering effort for a project commences with either receiving or 

developing the requirements for the system being planned for development. Software and 
42

hardware development processes are initiated, including their subsequent integration. Thus while 

application software development is ongoing, the development / acquisition of the AID, and 

installation of “installed components” would take place. Only minimal effort is required for the 

PED EFB as it is expected to be COTS. 

While the software and hardware developments are ongoing, the PSCP with associated artifacts 

is also being developed. Once the PSCP is completed (from the applicant’s perspective), FAA is 

approached for commencing the Certification Project with the applicant. 

Note: Based on the FAA meeting, for EFB applications such as TASAR (i.e., Type B), the PSCP 

is not of primary importance and may not even be required. FAA noted that the applicant 

may be able to engage directly with the POI for approval of the EFB mount and for 

previously installed EFB components (Section 4.3). 

A notional 3-month certification time period is envisioned for TASAR, which represents the time 

period for periodic engagements with FAA in engaging with the POI and/or executing the PSCP 

(if utilized). If the initial inputs from the applicant indicate that the applicant has done homework 

and provided the required artifacts, the POI could allow use of the TASAR application in very 

short order (in the matter of a couple of weeks), allowing the go-ahead for the 6-month flight-use 

validation period with corresponding data collection. The validation time period may be shortened 

via approval by FAA for certification projects that are not excessively complex (in terms of 

certification level and/or no significantly new technologies or approaches being involved). TASAR 

would have good potential for a shortened validation period, but this is TBD with FAA. If the 

evaluation period is uneventful, then the operator will likely achieve full approval for use once the 

evaluation period is completed and a report documenting the results of this period is completed 

by the applicant and accepted by FAA. While this 3-month certification estimate is somewhat 

subjective (especially in lieu of the 6-month evaluation period), based on the successful meeting 

with FAA and feedback received, this 3-month estimate seems reasonable. A TASAR certification 

program should be relatively easy to achieve since it does not require certification of new 

technologies and has a low certification threshold (i.e., “Minor Effect” FEC). 

Topic #3: Concluding Set of Recommendations 

NASA Request #3: What further steps NASA could/should take without an actual applicant (e.g., 

an airline) or specific implementation (e.g., identified aircraft) to reduce the certification time and 

risk when such an applicant shows up. What materials can/should be developed that are not 

applicant specific? Are there additional steps a NASA/avionics vendor partnership could 

accomplish without an applicant? 

Response: Section 4.2 and 4.3 and associated Appendices B and C provide significant certification 

and operational approval information, including inputs on the PSCP and DER feedback (which 

will be presented in the next section {Section 4.2}). Since the scope of the current work effort does 

not include the actual certification and approval of TASAR, actual certification and operational 

approval was not pursued here. However, significant details have been provided concerning the 

specific steps and associated artifacts that must be followed in achieving approval of the TASAR 

EFB application as a flight-deck advisory system. Specific recommendations have already been 

provided in Section 4.2.3.9 above under “Remaining, yet to be developed artifacts.” 

This section examined FAA guidelines and regulatory requirements needed for the certification 

and operational approval of the TASAR EFB flight-deck application and provided a conceptual 
43

plan expected to lead to successful certification and operational approval of TASAR. The next 

section provides results of a “dry run” review of these requirements with in-house DERs at 

Rockwell Collins. 

4.2.4 DER “Dry Run” Review of Certification and Operational Approval Artifacts 

This section examines elements associated with the certification and approval processes as they 

apply to the TASAR EFB application, which underwent a preliminary review with DERs for 

feedback whether the certification basis and means of compliance for approvals are appropriate. 

Specifically, this describes the following: 

1) Representative artifacts and considerations of the TASAR certification and operational 

approval processes 

2) A preliminary DER review, i.e., “dry run” of these artifacts and requirements 

3) Results of this DER review, including feedback and recommended updates to these 

artifacts and certification requirements. 

4.2.4.1 TASAR Artifacts Developed for DER Review 

The majority of certification and operational approval artifacts utilized in the DER dry run reviews 

have already been discussed in Section 4.2.3 above. This section identifies additional artifacts that 

are more specific in nature and are provided in more detail in Appendix D. 

Appendix D consists of several sub-appendices as follows: 

• D.1 DO-178B Objectives Artifacts Requirements for Level D 

• D.2 Tabletop EFB Evaluation (Detailed Check List #1) 

• D.3 EFB Operational Evaluation (Detailed Check List #2) 

• D.4 EFB Report Information Template 

• D.5 EFB Line Evaluation Job Aid (Detailed Check List #4). 

The DER reviewers represented both software and hardware certification disciplines and expertise. 

In general, without exceptions, DER reviewers were in concurrence with the information presented 

to them for TASAR certification requirements and offered additional advice, clarification, and 

perspective on a number of points as presented herein. 

The following certification and operational approval artifacts and requirements were included in 

the information package discussed with the DER reviewers: 

1) Overview of the certification and operational approval plan (i.e., PSCP) 

a. Consisted of a brief overview of the five phases of the PSCP, i.e., conceptual 

design, requirements, compliance planning, implementation, and post certification 

phases

b. Brief review of the typical content of a PSCP 

c. Review of the PSCP as applied to TASAR 

2) Review of cornerstone EFB documents (FARs, regulatory, and guidance) 

3) Certification approval considerations for the TASAR EFB application 

a. TASAR EFB application assumptions 

b. Review of current industry trends for EFB applications 
44

c. Key points and observations related to TASAR EFB certification approval 

d. Software-specific approval considerations and compliance 

e. Hardware-specific approval considerations and compliance 

In addition to reviewing the above topics associated with achieving certification approval, the DER 

review also included several additional topics: 

1) Discussed designee process used by FAA and responsibilities of the operator and FAA in 

the approval process 

2) Discussed the TC, STC, TSO Authorization, Parts Manufacturer Approval (PMA), and the 

role of Conformity inspections 

a. Type Design data (and processes) focused on the “Build” of the EFB system 

b. Qualification data (and processes) focused on the “Airworthiness” of the EFB 

system. 

3) Role of DO-178B for EFB applications like TASAR 

4) Some potential risk reduction methods for: 

c. Use of partitioning of system components to manage risks due to EFB system 

failures 

d. Security considerations 

e. Software revision considerations 

4.2.4.2 DER Dry Run Review– Process Overview, Artifacts Discussion, and 

Feedback 

The review of the TASAR certification operational approval artifacts from Section 4.2.4.1 was 

held with two experienced engineers from Rockwell Collins’ Certification Support Organization. 

One engineer is a DER designee with responsibilities related to certification of software-intensive 

systems. The other engineer is a soon to be “Systems and Equipment Unit Member” designee and 

is a subject matter expert in the area of certification of hardware-intensive systems. 

Note 1: FAA is currently in the process of making changes to the “designee process” for 

approvals and is creating an Organizational Designation Authorization (ODA) Unit 

Member (UM) process. As it currently stands many DERs will eventually become Unit 

Members (UMs) with specialization in software, hardware, and/or systems. 

Note 2: NASA has strong interest for further development and maturation of the TASAR EFB 

application and would ultimately like to see TASAR fielded as a flight-deck capability 

to provide flight path recommendations to the pilot, with the expectation to attain 

operational benefits for the end user operator. This will require gaining certification and 

operational approval from FAA and/or associated designees. The above mentioned 

requirements and artifacts from the subsections of Section 4.2 in this report and 

associated appendices are expected to be needed to determine the certification basis for 

TASAR and to provide the means for compliance for TASAR operational approval. As 

such, this project does not constitute an actual Certification Project and approval on its 

own but should enable a direct path to such approvals. 

The DER review meeting commenced with a statement of the objective of the meeting, which was 

to present, review, and provide feedback on the information and artifacts that had been developed 

to identify and address TASAR-specific certification and operational approval requirements. The 
45

TASAR operational concept and intended function were also briefly reviewed to provide context 

to the DER review. References to previous analyses that were already conducted that are relevant 

to the certification approval process addressed in the subsections of Section 4.2 were noted along 

with results of the major findings of these analyses. 

The following topics were presented to and discussed with the DERs. 

4.2.4.3 Overview of the Certification and Operational Approval Plan 

The five phases of the certification process as provided by FAA guidance and the PSCP [27][28], 

both as a general review, and then with a TASAR-specific view of the PSCP, were presented as 

part of the DER dry run review. 

DER Feedback: The DERs were in concurrence with the five-phase certification process. The 

DERs were also agreed that the PSCP elements had been adequately addressed at a high-level, 

including the TASAR-specific elements that were presented. It is noted that the TASAR-specific 

PSCP were limited to some but not all artifacts, since a fully executed TASAR PSCP would require 

completion of all steps to a sufficient level of detail and verification to achieve approval of an 

actual certification of the TASAR product, which is beyond the scope of this study. 

4.2.4.4 Review of Cornerstone EFB FARs, Regulatory, and Guidance Documents 

The following were identified as key documents that are fundamental to be considered for the 

certification of EFB products and applications: 

The cornerstone FARs, regulatory and guidance documents for EFBs are as follows 

1) Title 14 of the Code of Federal Regulations (14 CFR) parts 21, 23, 25, 27, 29, 43, 91F, 

91K, 121, 125, and 135 [29] 

2) Flight Standards Information System (FSIMS) – 8900.1 Change 47, Vol. 4, Chapter 15 – 

EFB Operational Authorization Process [14] 

3) AC 120-76C, Guidelines for the Certification, Airworthiness, and Operational Approval of 

Electronic Flight Bag Computing Devices [13] 

4) AC 20-173, Installation of Electronic Flight Bag Components [16] 

5) FAA Order 8110.4C, Type Certification [27] 

6) AC 21-16F, RTCA Document DO-160 “Environmental Conditions and Test Procedures 

for Airborne Equipment” [17] 

7) AC 20-115, RTCA DO-178B, Software Considerations in Airborne Systems and 

Equipment Certification [20] 

Note: A number of documents provide elements of potential additional approval requirements, 

i.e., compliance to certification requirements. These are primarily associated with hardware 

aspects of EFBs. 

DER Feedback: The DERs agreed that this list represents the key documents that need to be 

carefully reviewed for deriving certification requirements that if met, will demonstrate knowledge 

and compliance by the applicant to FAA reviewers. 
46

4.2.4.5 Certification Approval Considerations for the TASAR EFB Application 

This section describes information provided to the DERs in a number of areas: 1) TASAR EFB 

assumptions affecting certification, 2) current industry trends for EFB applications, 3) key points 

and observations that affect TASAR certification, and 4) software-specific and 5) hardwarespecific approval considerations for TASAR EFB compliance to the regulations. 

ͶǤʹǤͶǤͷǤͳ 	

The following TASAR EFB assumptions were presented to the DERs for consideration as part of 

the certification and approval process review: 

1) Based on the Operational Hazards and Safety Requirements Analysis in [7], TASAR (as 

currently defined is anticipated to be designated as a “No Safety Effect” FEC, and should 

be limited to no greater than “Minor Effect” in the unexpected event that workload issues 

come to the forefront 

2) TASAR is expected to be implemented as a Class 2 PED / portable EFB, with a read-only 

interface to on-board avionics systems, and will utilize antennas for accessible information 

sources via commercially available communication data links and networks 

3) TASAR Class 2 EFB is expected to be installed as a “cockpit mount” in the flight deck 

4) TASAR is expected to utilize an AID to serve as an intermediary interface to avionics 

systems 

5) TASAR is viewed to be a Type B application. 

DER Feedback: The DERs were in agreement with the assumptions noted in this section, without 

any corrective feedback or significant counterpoints. 

ͶǤʹǤͶǤͷǤʹ 	

Current trends for EFB applications were reviewed with the DERs and are summarized as follows: 

1) EFBs and their software applications provide (or are expected to provide) a retrofit path 

for new, and increasingly more capable flight deck capabilities 

a. The increased ability of COTS PEDs is providing impetus to add new capabilities 

economically 

b. FAA has been relatively flexible in approving EFB applications but at times has 

become rigid in terms of what it is willing to allow for EFB implementations 

2) Airlines are beginning to see cost benefits of EFBs, often with different business cases to 

equip. They see reduced pilot workload, simplified flight operations, and greater situational 

awareness as key benefits. 

3) EFBs are becoming an essential tool in the flight deck, improving situational awareness 

and leading to improved pilot decision making. They allow the flight crew to connect in 

real time to rest of world (e.g. TASAR via data link connectivity to internet information 

sources for weather, traffic, airspace status data, etc.). 

4) Currently, EFB requirements are in a state of flux. Some companies, in applying for 

certification approval, fall short of meeting FAA’s intended requirements. This at times 

results in FAA implementing new changes and adding new requirements. 

5) While EFB hardware requirements and specifications are important, the future of EFBs is 

expected to largely depend on the capabilities offered by software applications. 
47

a. EFB hardware is expected to become commoditized. 

b. Shift is towards development of more robust software applications. 

6) Latest technological development for Class 2 EFBs is their ability to interface with aircraft 

systems and to provide an access point to wireless communications pipelines (similar to 

those planned for TASAR data connectivity). 

7) Once ADS-B IN becomes available for display in aircraft, benefits of EFB become 

significant.

a. However, this raises the stakes for EFB software applications, which may go 

beyond Type A and Type B and may affect higher FEC (no longer “Minor Effect” 

or less). 

8) TASAR is most closely aligned with Type B applications. 

a. Consists of processing algorithms to provide recommended trajectory change 

requests to the pilot 

b. TASAR is expected to be less critical than Type B applications associated with 

weight and balance and performance calculations. 

9) While Class 1, 2, and 3 EFBs may be Windows XP-based, and Class 3 EFBs are generally 

the same as Class 2 EFBs in terms of hardware, Class 3 EFBs require more rigorous testing 

to meet FAA qualifications test. 

10) Second generation EFB software continues to seek improved design to incorporate 

common workflow requirements, seeking reduced training time, and reduced number of 

touches, allowing more time for other tasks. 

11) There is a likelihood that EFB systems with hosted Type A and Type B applications and 

with approved software (those designed using DO-178B) will be integrated in some 

installations. 

a. This likely requires a dual processor EFB architecture, allowing partitioning of 

higher and lower criticality software applications 

i. e.g., “approved” (i.e. DO-178B certified) software applications to be 

allocated to one EFB processor running DO-178B-certified Linux OS, and 

Type A and Type B “hosted” applications (developed without using DO178B) running on a non-certified Windows OS (alternate architectures and 

approaches can be considered if equivalent in robustness). 

12) TASAR, as a hosted application, may be integrated with other software applications (some 

hosted and perhaps some approved) and may be installed in a variety of EFB platforms 

including some with certified OS. The manner of integration and hosting of TASAR may 

affect the software certification requirements of its design. 

DER Feedback: The DERs were in general agreement with the current trends in EFB applications 

without any corrective feedback or significant counterpoints. 
48

ͶǤʹǤͶǤͷǤ͵ Ǥ

The following were noted to the DERs as being important elements of the certification process for 

TASAR:

1) The authorization process intended is for Part 121, 125, and 135 operations and require 

authorization from the FAA Principal Inspector (PI). 

a. Part 91F operators do not require specific authorization for EFB operations, since 

TASAR does not replace any required systems. 

2) Installed components of a Class 2 EFB (intended for TASAR) require approval as part of 

TC, ATC, STC, and ASTC via PMA. This allows FAA 145 repair stations to test, repair, 

and place a FAA serviceable tag on equipment. 

3) Type A and Type B applications do not require DO-178B certification for applications 

software nor OS for Class 2 EFBs. 

4) Airworthiness regulations only apply to installed EFB components and do not apply to 

portable EFB components (i.e., in reference to hardware). 

a. Installed components for TASAR Class 2 EFB would include the mount (size and 

weight), power (maximum electrical load, voltage, and current frequency), and data 

connectivity (input/output data specifications and security). 

5) Components of the Class 2 EFB include all hardware and software needed to support the 

EFB intended function. 

a. Any EFB hardware not accessible to the flight crew on the flight deck (e.g., AID, 

antenna(s) for aircraft wireless), or not being portable must be installed in 

accordance with applicable airworthiness regulations (per AC 20-173 [16]). 

6) Class 2 EFB hardware, internal components, and software do not require FAA 

airworthiness approval. 

a. Type A and Type B applications are considered “hosted” because they have no 

requirement to be installed as part of an aircraft type design or as an alteration. 

i. Such equipment would usually identify the hardware as miscellaneous, nonrequired equipment. 

DER Feedback: The DERs were in general agreement with the elements identified in this section 

without any corrective feedback or significant counterpoints. 

ͶǤʹǤͶǤͷǤͶ Ǧ

With TASAR being a software application hosted on an EFB platform, the DER review and 

associated discussions paid particular focus to software and its associated development 

requirements. As noted earlier in Section 4.2.3.6, “hosted" Type-B applications actually do not 

require airworthiness approval. In other words, these applications can be developed outside the 

development process specified by DO-178B, even for Design Assurance Level (DAL) “D.” 

DER Feedback: As part of the DER review, there was considerable discussion about the extent 

and rigor required for software development of an EFB application such as TASAR. 

At a minimum, the following steps were identified as being required for development of TASAR 

software, which does not required DO-178B: 

1) Develop and review high-level requirements of the TASAR application software. 
49

2) Develop the software system architecture based on low-level requirements. The low-level 

requirements do not need to be reviewed as part of any verification process. 

3) Determine derived system requirements. 

4) Prove that code meets high level requirements. No structural coverage needs to be 

demonstrated. 

5) Ensure that high-level requirements: 

a. Comply with system requirements 

b. Are accurate and consistent 

c. Are traceable. 

The software development process for software similar to TASAR has rather minimal 

requirements associated with it in terms of rigor, artifacts, review process, and verification. The 

DERs recommended that one should strongly consider whether and the extent to which elements 

of the DO-178B process, particularly with respect to DAL D should be utilized. In the event of 

future updates and revision of the TASAR concept that could lead to a DO-178B requirement, by 

developing portions of the TASAR software using DAL D, one could make reuse of the code that 

has been developed to this DAL. 

DO-178B DAL D has a requirement to meet 28 objectives for the various software development 

steps. These are described in Appendix D.1 for reference. 

In summary, EFB software applications such as TASAR have a relatively low threshold of 

development required and do not require DO-178B to be applied. However, good software 

practices should be followed and depending on future reuse in higher certification levels, one may 

want to consider development of this software to DO-178B DAL Level D. 

ͶǤʹǤͶǤͷǤͷ Ǧ

While TASAR is a software-enabled EFB application, the majority of certification-related 

requirement for compliance for the TASAR EFB system fall into the hardware domain. 

Airworthiness regulations apply to installed EFB components and do not apply to the portable EFB 

components, including internal components of the EFB. For the TASAR EFB system, this 

primarily involves the installed components related to the following: 

1) Mounting (size and weight) 

2) Power (maximum electrical load, voltage, and current frequency) 

3) Data connectivity (input/output data specifications and security). 

EFB components are “installed” when they are incorporated into aircraft type design under 14 

CFR part 21 or as a proper alteration under 14 CFR 43.3. All other EFB components are considered 

“portable,” regardless of how often they are removed from the aircraft. 

EFBs may consist of modular components (e.g., computer processing unit, display, controls). Any 

EFB hardware not accessible on the flight deck by the flight crew or not portable must be installed 

and certificated equipment covered by a TC, amended TC, or STC. The one exception to being 

accessible on the flight deck is a remotely mounted antenna that provides signal reception to the 

EFB. The AID falls into this category of being installed and requiring type certification. 
50

Major Class 2 EFB components (motherboards, processors, random access memory, video cards, 

hard drives, power supplies and connections) must be configuration controlled, with any changes 

requiring reevaluation to demonstrate that the intended function is still met, i.e., non-interference, 

and reliability requirements are still met. For sealed components one should use the manufacturer 

model / part number. 

The following high-level hardware requirements are obtained from “Flight Standards Information 

System (FSIMS) – 8900.1 Change 47, Vol. 4, Chapter 15 – EFB Operational Authorization 

Process” [14]: 

A. With respect to the EFB display, e.g., TASAR, requirements must be met for legibility, 

brightness, viewing angle, etc., along with requirements associated with input devices (e.g., 

stylus, digitizer pen, touchscreen). 

The following hardware test requirements must be addressed, as applicable, to the use of the 

EFB system: 

B. Rapid Decompression (RD) Testing 

(should not be a significant consideration for TASAR) 

C. Electromagnetic Interference / Non-Interference Testing 

(also required for TASAR as a T-PED) 

D. Antennas airworthiness requirements 

E. Power Sources airworthiness requirements 

(TASAR likely to use aircraft power, but not a firm requirement) 

a) Battery primary 

b) Battery maintenance 

c) Aircraft secondary power 

d) Aircraft primary power 

F. Data Connectivity (Class 2 Only) airworthiness requirements (required for TASAR) 

G. Data Loading/Database Changes airworthiness requirements 

(TBD for TASAR; likely not a safety requirement but a usability requirement) 

1. Class 1 or 2 EFBs must have a reliable means for revising the EFB databases

1. Database currency is determined by what required aeronautical information the 

EFB is replacing.

2. Each method of data revision must ensure integrity of the data being loaded and not 

negatively impact the reliability of EFB operation.

3. Procedures must exist to protect the EFB from corruption, especially when internet 

and/or wireless means are used.

4. Database revision does not include application software or operating system 

changes.

5. Application software and/or operating system program changes must be controlled 

and tested prior to use in flight.

6. Database and/or application software changes may not be performed during 

operations (taxi, takeoff, in-flight, landing).
51

Note: External drives for data loading are considered ancillary EFB equipment 

and not subject to specific requirements beyond those identified for data 

loading/database revision above.

H. Mounting Devices (Class 2 Only) airworthiness requirement (likely required for TASAR) 

The EFB, when attached to its appropriately designed mounting device, must be evaluated 

to ensure operational suitability in all ground and flight operations and conditions (airborne 

use for TASAR).

a) When attached to its mounting device, the EFB must not interfere with flight crew 

duties and must be easily and safely stowed when not in use.

b) The attached EFB must not obstruct flight crew primary and secondary fields of view 

(See AC 120-76C).

c) The attached EFB must not impede safe egress.

The above hardware requirements represent an overview of high-level hardware requirements 

needed to be met to demonstrate compliance with the FARs, regulatory and guidance documents 

for EFB systems. More specific requirements are found in AC 20-173, Installation of Electronic 

Flight Bag Components [16] and AC 21-16, RTCA Document DO-160 “Environmental Conditions 

and Test Procedures for Airborne Equipment [17]. 

DER Feedback: The DERs were in general agreement with the elements identified in this section 

without any corrective feedback or significant counterpoints. 

4.2.4.6 DER Feedback 

In general the DERs were satisfied with the level of compliance requirements presented toward 

the certification of EFB systems such as the TASAR EFB application, relative to the information 

provided and with respect to software and hardware aspects of EFBs. No major areas of concern 

of significant counterpoints were raised. 

The DERs did offer some additional perspective in the following areas: 

1. Discussed designee process used by FAA and responsibilities of the operator and FAA in 

the approval process 

2. Discussed the TC, STC, TSO Authorization, PMA, and the role of Conformity inspections 

3. Some potential risk reduction methods 

ͶǤʹǤͶǤ͸Ǥͳ 	

FAA utilizes the ‘Designee Process’ as an extension to their certification and operational approval 

organizations (e.g., Aircraft Certification Office {ACO} also referred to as AIR; Flight Standards 

{AFS}, the Aircraft Evaluation Group {AEG}, Manufacturing Inspection District Office {MIDO}, 

and others. Organizations and individuals with demonstrated expertise can be appointed as 

approval designees for portions of the certification approval process. Individuals from engineering 

and manufacturers may receive designee appointment, e.g., DER, DMIR, and DAR, who can 

address either manufacturing or maintenance airworthiness of a product. DERs may be appointed 

to software, hardware, or systems as part of the certification process. DMIRs may serve as 

inspectors of conformity, i.e., that products and associated parts are built to the required 

specifications and process. Designee may come from 3rd party organizations, be appointed from 
52

small shops supporting certification for general aviation or from large manufactures for air 

transports, regional aircraft operators, and high-end business aviation. 

ͶǤʹǤͶǤ͸Ǥʹ ǡǡǡǡǡǡ

There are multiple means to certify a new product or a revised article. From an EFB system point 

of view, only installed components require a Type Certificate approval. The term Type Certificate 

can encompass a range of approvals, including TC, ATC, STC, and ASTC.

A TSO is a minimum performance standard, defined by the FAA, used to evaluate an article. An 

article can be a material, part, component, process, or appliance (refer to Title 14, Code of Federal 

Regulations, 21.1(b)(2)). Each TSO covers a certain type of article. When authorized to 

manufacture an article to a TSO standard, this is referred to as a TSO authorization (TSOA). 

Receiving a TSO authorization is both a design and production approval. 

There are two aspects to achieving approval, 1) Type Design Data which contains information and 

data associated with “building the product”, and 2) the “qualification” aspects of the integrity of 

data, including software verification, which demonstrates “airworthiness.” Manufactures must 

have established and maintain approved quality systems and processes to support approvals to 

meet airworthiness requirements. 

Conformity is typically a ‘one-of-a-kind’ inspection of an individual part that is used as part of an 

individual system being certified. When qualified, such a unit is issues an 8130 airworthiness tag. 

For a larger number of units being develop, this typically requires a Parts Manufacturer Approval, 

which is typically only issued to larger manufacturers. 

ͶǤʹǤͶǤ͸Ǥ͵ 

The following three subtopics were discussed with the DERs as part of the DER review: 

1) Use of partitioning of system components to manage risks due to EFB system failures 

2) Security considerations 

3) Software revision considerations 

4.2.4.6.3.1 Partitioning of System Components to Manage Risks Due to EFB Failures 

A key issue when integrating EFB applications such as TASAR with other software applications 

is the potential adverse effects of one application, e.g., the “hosted” typically non-approved 

software application with “approved” certified software applications. Several configurations are 

possible:

1) TASAR is standalone, with its own dedicated processor (own OS and application 

software) and dedicated display, this is will not require any partitioning or special 

protections

2) TASAR has its own dedicated processor, but shares a common display with other 

“Approved Software” applications / software. Recommended Display Standards, e.g., 

AC 25-11, Electronic Flight Deck Displays (for Part 25 aircraft) [30], and AC 23.1311-

1, Installation of Electronic Display in Part 23 Airplanes [31] must be followed. 

3) TASAR is hosted with other “approved” software applications in a shared processor. In 

this case, approved partitioning techniques must be followed. These techniques are 
53

required to guarantee throughput and resources (e.g., memory, hard drive, avionics data, 

etc.) of Approved Software applications. 

As EFB software use continues to increase, a dual EFB architecture, with separate OS and 

application software, segregated by hosted versus approved designations is a likely outcome. 

However it is accomplished, protections of processing time and memory space must be ensured to 

prevent one application from taking over and adversely affecting higher-criticality applications. 

4.2.4.6.3.2 Security Considerations 

While not expected to be a significant issue for TASAR, which utilizes a read-only interface to 

avionics systems and thus does not transmit and pose a security threat to aircraft systems, the DERs 

noted that security issues are becoming more paramount concerns for FAA. Mitigating techniques 

should be followed, such as maintaining read-only interfaces. In the case of transmit-only 

interfaces where the use of “polling” (e.g., once per second) for received inputs is used to manage 

the interface, techniques should be used to avoid disruption via a transmitter ‘babbling’ 

continuously and thus disrupting the I/O process. 

The DERs noted that for security, one should also address threat scenarios in the safety assessment. 

As currently defined, TASAR is not expected to pose a security threat as it is read-only. 

4.2.4.6.3.3 Software Revision Considerations 

The DERs provided insight with respect to the field-loading of updated software. A key step in 

this process is that assurance is required that what was loaded into the EFB is what was intended 

to be loaded. Use of checksums via the program itself, or via procedural means are potential 

candidates to assure that proper software and operating systems are loaded into the EFB system. 

4.2.4.7 DER Review Conclusions 

As noted throughout this section, EFB applications such as TASAR have relatively minimal 

software-specific certification requirements and do not require DO-178B as part of their software 

development process to gain approval. EFB hardware-specific requirements are considerably more 

extensive and apply to the installed portions of the Class 2 EFB. Thus in many ways, EFB approval 

should be relatively straight forward for the TASAR Type B EFB application. 

The DERs were in general agreement with the assessment presented to them for a TASAR-like 

EFB application. They provide some additional perspectives on the certification process related to 

the designee process, type certification, and risk reduction techniques relative to system 

partitioning, security, and the software revision process. 

While TASAR has a relatively low certification approval threshold, gaining full approval for an 

EFB system requires one to address a wide range of approval requirements, as reflected in the 

questionnaires in Appendices D.2 through D5. These questionnaires were reviewed and TASARspecific comments were entered into the questionnaires where applicable. 

4.2.5 TAP HMI Version 4 Certification and Operational Approval Analysis 

This section documents the results of a certification assessment of the Traffic Aware Planner 

(TAP) HMI, Version 4 (V4). The analysis examined all HMI elements that pose a potential 

increase in certification / operational approval requirements, with an emphasis on an assessment 

of regulations that may govern the graphical elements depicting aircraft navigation information 
54

(e.g., routes, heading), traffic information, weather and airspace information, and wind 

information. The analysis includes recommendations, with regulatory reference, on specific HMI 

changes to reduce the threshold for certification and/or operational approval. 

As background to this analysis, TAP represents the software engine of the TASAR EFB 

application that is being developed by NASA Langley Research Center and its research partners 

(refer to Figure 4). The TAP HMI V4 represents the latest version of the pilot interface in using 

the TASAR application, which incorporates updates and enhancements based on pilot feedback 

from 1) a HITL experiment conducted under this contract by the University of Iowa OPL [32], and 

2) a flight evaluation of TASAR in a relevant operational environment conducted by Advanced 

Aerospace Solutions, LLC for NASA under another contract [8]. NASA developed an updated 

TAP HMI user interface, V4, to address comments received and to further mature the effectiveness 

of the TASAR application in terms of situational awareness, workload, and compatibility with 

other on-board flight-deck systems. Pilot comments and feedback from [32][8] that influenced 

NASA’s update to the TAP HMI leading to V4 are described in Section 4.2.5.3.1.1 below. The 

TAP HMI V4 has undergone a second HITL evaluation [33] to determine its effectiveness of the 

revised HMI design. 

The Operational Hazard and Safety Assessment in Section 4.2.1 has determined a FEC of “Minor 

Effect” (which has also been confirmed by FAA – Section 4.3) for the TASAR EFB Application. 

This section (Section 4.2.5) provides the results of a certification assessment of the TAP HMI V4 

to determine if TAP display elements from V4 continue to be consistent with the “Minor Effect” 

designation of TASAR and to ensure that elements of the V4 HMI do not inadvertently raise any 

undo certification issues. The key guidance documents forming the basis of the certification and 

operational approval assessment of the TAP HMI V4 were FAA AC 120-76B [34] and Flight 

Standards Information System (FSIMS) – 8900.1 Change 47, Vol. 4, Chapter 15 – EFB 

Operational Authorization Process [14]. An updated version of AC 120-76, Version C [13] was 

reviewed to determine if any significant updates may affect the TASAR EFB certification 

assessment, particularly pertaining to the revisions made to the TAP HMI in V4. 

4.2.5.1 TASAR HMI Requirements Assessment 

While the TASAR EFB application has been designated with a “Minor Effect” FEC, this 

designation is silent with respect to the specific requirements to the TAP HMI. The following 

sections address HMI-specific approval considerations. 

ͶǤʹǤͷǤͳǤͳ 

A key certification issue related to the EFB display of map, route, and / or traffic information is 

the depiction of own ship as part of the EFB application. FAA AC 120-76B [34] was strict in its 

view of depiction of own ship on the EFB display, forcing a “Major Effect” designation if own 

ship was displayed. FAA AC 120-76C [13] relaxes this requirement somewhat by allowing display 

of own ship in certain cases. Reference [13] allows the display of own ship on the EFB display 

when the aircraft is operating on the airport surface at speeds less than 80 knots. From [13] display 

of own ship is only allowed as an aid to situational awareness and is not authorized for use for 

surface navigation, surface alerting, time-based operations, guidance, maneuvering and control 

functions. Display of own ship on the airport surface as a Type B application is intended to help 

flight crews orient themselves on the airport chart / map, and to improve pilot positional awareness 

during taxi takeoff and upon landing. Type B EFB applications using display of own ship position 
55

on the airport surface are not of sufficient certification pedigree to be used as the basis for 

operational guidance, maneuvering, and control. 

Display of own ship when operating on the airport surface at speeds of 80 knots or greater, or when 

used in actual flight, elevates the FEC to “Major Effect” with a corresponding increase in software 

certification and operational approval requirements, e.g., requiring approved software per DO178B.

From a TASAR HMI perspective, display of own ship is not allowed, as the TASAR intended 

function is strictly as an en route advisory tool for the pilot. The TASAR HMI V2 does not display 

own ship nor any other traffic information in any graphical depictions of route information (active 

nor preview of candidate trajectories).

V4 of the TASAR HMI provides a limited graphical indication of proximate traffic (not including 

its position) in relation to the preview route when the pilot is evaluating route improvement 

candidates using the TASAR Manual Mode. When TAP determines the presence of proximate 

traffic, serving as a traffic hazard, select information regarding this traffic hazard is depicted in the 

Visualization Panel to provide traffic awareness to the pilot. Presence of a traffic hazard would 

likely result in a clearance request being denied due to the traffic in question. 

Own ship is not explicitly shown in the TAP HMI V4 and can only be approximately inferred from 

the EFB display to be located somewhere near the bottom center of the Visualization Panel. The 

TASAR HMI V4, including the TAP Manual Mode, and the depiction of traffic hazards on the 

Visualization Panel are discussed in more detail in Section 4.2.3.2 below. Certification assessment 

analysis results of the TASAR HMI V4 are described in Section 4. 

ͶǤʹǤͷǤͳǤʹ 

FAA Flight Standards Information System (FSIMS) – 8900.1 Change 47, Vol. 4, Chapter 15 – 

EFB Operational Authorization Process [14] provides specific guidance concerning areas that must 

be addressed by the applicant when requesting approval of an EFB application by the POI, 

including areas related to the HMI. This guidance is provided in the form of a number of 

questionnaires the applicant must answer for review by Flight Standards / POI to gain operational 

approval for the EFB application. 

The following represents a summary of the specific focus areas of EFB HMI design as indicated 

by the EFB Evaluation Checklist 1 Questionnaire per Figure 4-79 [14] and provided in detail in 

Appendix D (D.1) that the operator must address with the POI pertaining to EFB display of 

information, i.e., the pilot Human Machine Interface. 

Checklist 1 represents the Tabletop EFB Evaluation that must be demonstrated to the POI. It 

consists of approximately 100 questions that must be answered as Yes or No, that describe whether 

the EFB application being considered meets the intended evaluation requirements. 

The checklist starts with 1) EFB hardware questions, then 2) presents general user interface 

questions, and 3) ends with specific application questions (if applicable). The checklist is designed 

so that any question answered as “No” requires a comment that may include, “Not Applicable.” 

After the operator has completed this checklist, the results are documented so the POI can review 

the results with the operator. 
56

Hardware-Specific Questions address EFB readability in sunlight, labeling of controls, ease of 

providing inputs, EFB start-up, ability to reboot, ease of comprehension of failure modes 

(identification, annunciation), and ease of recovery when EFB fails. 

General User Interface Questions address the following list of factors: Revision history and 

expiration dates to be clearly presented, responsiveness of EFB to inputs, EFB processing speed, 

use of busy / progress indicators, consistent user interface allowing selection and use of functions 

and navigating the display, display of needed information and ease of access (avoid missing or 

difficult to find information), common actions and timely access to critical functions, standard 

ways to perform common actions, uniformity of display and controls across the application and 

also other applications, color viewing and ability to distinguish in various lighting conditions, color 

coding / shading / highlighting for display of critical information, appropriate use of red and yellow 

colors (only use for warnings and cautions), readability of text (including in low-visibility 

conditions), contrast of text in relation to display background, use of upper and lower case 

frequency, ease of bringing out of view information into view, icon and symbol functions obvious 

and distinguishable / explained by label or other means, etc. 

Application Software-Specific Questions include the following: Ability to quickly and accurately 

find information, consistency of information layout, ease of being able to read high-priority 

information, ease to determine open/active application(s), detection of incorrect information 

formats / data range, and error messages, crew training, etc. 

The detailed Checklist 1 questionnaire is provided in Appendix D (D.1). 

4.2.5.2 Review of Changes to AC-120-76C; Potential Effects on TASAR FEC 

As part the TAP HMI V4 certification and operational approval review addressed in this report, 

FAA AC 120-76C [13] was examined for potential updates to approval requirements that could 

have an effect on TASAR (recall that the previous certification and operational approval analysis 

of TASAR were based on AC 120-76B). From this review the following represent notable changes 

from AC 120-76C: 

• AC 120-76C explicitly constrains the use of Type A and B applications to FECs of “Minor 

Effect / Hazard” or less 

Note: TASAR, as previously analyzed and confirmed by FAA approval authorities is a “Minor 

Effect” Type B, Class 2 EFB application. This report reviews TAP HMI V4 to determine 

if any updates adversely impact this designation (refer to Section 4 for results of this 

assessment) 

• FAA clarified the ability and limitations of an applicant with respect to being able to 

display own ship position for their respective EFB application (EFB Class and Software 

Type)

o Own ship can be displayed only on the airport surface, when operating at less than 

80 knots 

o Own ship cannot be displayed when in flight when using Class 1 and 2 EFBs and 

Type A and B software. In flight display of own ship warrants a “Major Effect / 

Hazard” designation and requires a Class 3 EFB (or avionics) with Type C 

software.
57

o Own ship depiction that is allowed on the surface can only be used for situational 

awareness and not for operational guidance / maneuvering / control of the aircraft. 

Note: TASAR is used during flight above 10,000 ft. altitude and can thus not display own ship 

position without adversely impacting its certification level (i.e., it would elevate the 

certification level to “Major Effect/Hazard” requiring Class 3 EFB / Type C Software 

designation).

• Section 11.e.4.c [13] notes that “data link EFB functions may display approved sources of 

weather for strategic / flight planning purposes” (thus removing the word “unapproved”) 

• Section 11.e.4.d [13] notes that “data link graphical weather from sources ... may be from 

approved sources of advisory weather information and can only be used for strategic / flight 

planning purposes. Do not use data link graphical weather information for tactical decisions 

during critical phases of flight, because data quality is uncontrolled for aviation use. Do 

not use data link graphical weather data as a substitute for airborne weather radar or 

thunderstorm detection equipment.” 

Note: The TAP HMI V4 provides weather hazard information for pilot situational awareness but 

does not replace the use of weather radar or thunderstorm detection equipment for tactical 

decisions. Since TAP HMI V4 utilizes display of weather hazard information for pilot 

situational awareness, this aspect is further analyzed in Section 4.3 for any impact on 

TASAR/TAP certification requirements.

• “Type C software applications are approved by the FAA using RTCA/DO-178 or another 

acceptable means. These are “non-EFB” software applications found in avionics and 

include intended functions for communications, navigation, and surveillance that require 

FAA design, production, and installation approval. Type C applications are approved 

software for surface and airborne functions with a failure condition classification 

considered to be a major hazard or higher.” 

Note: This is not a new requirement from AC 120-76C. However, this requirement continues to 

indicate that applications related to surveillance, e.g., ADS-B enabled Cockpit Display of 

Traffic Information (CDTI) applications fall under the banner of Class 3 EFB (or avionics) 

/ Type C software. Since TAP HMI V4 provides Traffic Hazard situational awareness, this 

aspect is further analyzed in Section 4.2 for any potential impact on TASAR / TAP 

certification requirements. 

4.2.5.3 Overview and Comparison of TAP HMI V2 and V4 

Before describing an overview and comparison of the TAP HMI V2 and V4, the next section 

summarizes some of the factors that led NASA to redesign the TAP HMI, leading to V4, which is 

analyzed in this report. 

ͶǤʹǤͷǤ͵Ǥͳ 	

As already noted, TASAR and TAP HMI V2 was already analyzed in a HITL experiment (HITL1 [32]), which served to inform the subsequent TASAR flight trial by Advanced Aerospace 

Solutions, LLC [8]. [32] and [8] provided pilot comments and feedback on the TAP HMI, which 

are summarized in the next sections. 

4.2.5.3.1.1 Pilot Comments, Feedback on TAP HMI from HITL-1 and TASAR Flight Trial 
58

The following summarize pilot feedback from HITL-1 [32] (Section 4.2.5.3.1.1.1) and the initial 

TASAR Flight Trial [8] (Section 4.2.5.3.1.1.2). 

4.2.5.3.1.1.1 HITL-1 Feedback on TAP HMI V2 

The results of the post-simulation questionnaire from HITL-1 [32] clearly indicate that the 

participants found the TAP interface easy to work with and useful to very useful. The participants 

generally rated the screen elements as useful to very useful and overall easy to understand. A few 

outliers existed concerning specific screen elements; however, the general consensus of the 

participants was that the TAP display as presented (V2) was useful and easy to use. Many of the 

narrative comments made by the participants directly affected the implementation of the TAP 

interface for the flight trial that was performed subsequent to this experiment [8] and for the 

development of the post-flight trial next generation of the TAP interface, i.e., TAP HMI V4. 

Overall, the TASAR application was very well received by almost all of the pilots in HITL-1. 

Several of them were excited to have such a tool available to them in the cockpit environment and 

felt that is was long overdue to have access to such information. 

From the post-simulation interviews and questionnaires completed by the 12 participants, the 

following comments and feedback on their use of the TAP HMI V2 were received: 

• There was some confusion about two of the button sets available to pilots. The first set of 

buttons causing confusion was the AUTO and MANUAL buttons along the top. The pilots 

indicated that the buttons either need to be removed on some screens (such as the Selected 

Optimization Screen) or grayed out differently to make it clear what screen was still 

available to be selected or which screen was the current one. 

• The buttons across the bottom of the Selected Optimization Screen also caused confusion 

in some pilots. These buttons were there to log the result of asking ATC for a flight path 

request that was generated by the TAP Auto Mode. Several pilots did not see the point of 

having these buttons and would prefer they were not there at all, claiming they did not add 

any value. The fact that these buttons were only visible in some modes caused additional 

confusion.

• Some pilots wanted to have more information available to them, in particular weather data 

to know why certain optimizations were being made. The pilots felt that it was not 

sufficient to simply know that a route optimization was being impacted by weather. Details 

such as approximate location and time until convective weather was to be encountered on 

the unmodified route are important factors that help give pilot situation awareness. The 

pilots also indicated that future builds of the TAP software should have more uniformity 

between the TAP Auto Mode and TAP Manual Mode screens, including the Route Display. 

4.2.5.3.1.1.2 Flight Trial Feedback on TAP HMI 

Advanced Aerospace Solutions, LLC conducted an initial flight trial of TASAR [8] with the goal 

to be able to demonstrate and evaluate TASAR functionality in an operational environment and to 

collect pilot assessment data of TAP operation and the TAP HMI. The following represent an 

overview of some of the key feedback received from pilots concerning the TAP HMI used in the 

flight trial (i.e., an updated version of V2 that incorporated some feedback from HITL-1). 
59

As with HITL-1, pilots in the flight evaluation perceived TAP as easy to use and understand. Likert 

ratings on ease of use generally yielded good scores but allowed room for improvement on route 

visualization and understanding and indicated needed improvements on bearing and distance 

controls. Recommendations of the TAP HMI included: 

1) Better visual depiction of optimized route, 2) request to add new airspace hazard classes 

(e.g., weather, SUA), 3) add speed control into optimizations. 

From the flight test evaluation of TASAR specific comments for possible HMI improvement 

opportunities are as follows: 

• Connection status of individual data connections is not necessary. If there is a problem, 

indicate it and provide ability to go to another screen with more details of the issue. 

• Many pilots had difficulty finding what waypoint was currently set as the optimization 

limit 

• Use color palette that is standardized for commercial aircraft 

• Selected Optimizations need to be easier to set 

• Show a line going around a SUA for better situational awareness 

• Need better map depiction; pilots are generally visual. Show conflicts to be avoided, e.g., 

SUAs 

• It would be nice to know what traffic TAP is considering 

• Verify all suggested routes with map for reasonableness 

• Make map consistent with Navigation Display, also North-up mode 

• Need better visualization tools, i.e., map. Show traffic. 

• Show full route waypoints/names and optimization names vs. 1, 2, 3 

o Show full current route, fix names on map, consider adding a title to every page 

• Yellow text, e.g., SUA should be bold for visibility reasons 

• Make conflicts stand out more; particularly meant for Manual Mode 

• Solution filters need rework or removal 

• Show own ship 

• Intelligently finding off-route waypoints to use 

• Need a more visual tool to select optimization 

• Use touch screen capabilities to find waypoints on map 

• Make it easier to remember to enter the Rejoin Waypoint 

• Make it easier to clear any one part of the optimization 

• Pilots want the “what” and “why” as part of displayed information 

• Consider adding a profile view for vertical change solutions 

• Add fix / bearing / distance tool 

• Many wanted to see winds data 

• TAP functions were well integrated, but a significant amount of inconsistency was noted 
60

• Most pilot wanted an alert, although verbally in debrief they were split on whether it should 

be an audible or a pop-up 

• Add volcanic ash advisory areas to avoid 

• Solution filters are not necessary 

• Provide ability to remove a specific constraint (e.g., second off-route waypoint, ...). 

Based upon pilot comments and feedback from HITL-1 and the TASAR flight trial, NASA 

incorporated many features to the HMI redesign embodied in TAP HMI V4. The next section 

provides an overview of V2 and V4 of the TAP HMI. 

ͶǤʹǤͷǤ͵Ǥʹ 

This section provides on overview description and comparison of the NASA-developed TAP HMI 

V2 and V4. TAP HMI V2 underwent an evaluation during the HITL-1 experiment [32]. This 

version of the TAP HMI was also used in the initial flight trial evaluation [8]. TAP HMI V4 was 

developed by NASA in response to feedback and lessons learned from HITL-1, the flight trial, and 

additional maturation of the TASAR application. Improvement recommendations, many identified 

in the previous section (Section 4.1) were incorporated into TAP HMI V4. The TAP HMI V4 has 

undergone a second HITL evaluation (HITL-2), which is currently being analyzed. 

TAP capabilities include an Auto Mode and Manual Mode that support the flight crew in receiving 

flight path improvement opportunities to the current flight plan. TAP utilizes on-board data sources 

for 1) aircraft state, FMS active route, etc., 2) ADS-B IN and other sources for traffic information, 

and 3) internet data for wind updates, convective weather hazards, and airspace constraint 

information in order to offer improvement opportunities for fuel and/or time savings. 

In the Auto Mode TAP continually monitors the current flight trajectory and information sources 

to periodically (~1 minute intervals) provide lateral, vertical, and combination lateral/vertical 

trajectory changes that are free of hazards /conflicts, e.g., traffic and weather, and offer fuel 

consumption savings and / or reduced flight times over the current flight plan. Recommended 

trajectories are evaluated for compatibility of ATC constraints (e.g., traffic complexity / density, 

airspace constraints, location within the sector) with the goal to have a higher likelihood of 

clearance approval by ATC. 

The Manual Mode of TAP allows the pilot to request specific trajectory changes for evaluation by 

TAP in seeking route improvement opportunities on their own initiative. In the Manual Mode, the 

pilot enters revisions to the current flight plan for evaluation by TAP. TAP then computes impact 

on fuel consumption and flight time and will also notify the pilot in the event the proposed 

trajectory is subject to traffic or weather hazard constraints. If no hazards or constraints exist and 

fuel and/or time savings can be achieved, the pilot, at his / her discretion can request a clearance 

from ATC for the new flight trajectory. 

Upon power-up of the TASAR application, the pilot inputs initialization of TAP data and reviews 

checklist items to ensure TAP is properly configured and operational. The pilot also established 

the cost index and preferred altitude and cruise speed (e.g., ECON setting) that are compatible 

with the FMS-loaded flight plan. 

4.2.5.3.2.1 Initialization (V2) and Startup Checklist (V4) Screens 
61

TAP HMI V2 utilizes an Initialization Screen, shown in Figure 5a, while for TAP HMI V4 the 

initialization screen was redesigned and updates and is referred to as the Startup Checklist Screen, 

which is illustrated in Figure 5b. 

For both versions, V2 and V4, the Initialization Screen (V2) and Startup Checklist Screen (V4) 

appear at startup of the TAP application. 

As illustrated in Figure 5a, the Initialization Screen displays the status of data connections and 

provides data validity checks. Once all items have passed, signified by being green, the pilot then 

accepts the initialization screen. 

The Initialization Screen from V2 was redesigned and enhanced for V4 and is now referred to as 

the Startup Checklist Screen (Figure 5b). The Startup Checklist Screen allows the pilot to perform 

the following tasks: 

1) Ensure that TAP is configured properly 

2) Confirm TAP’s status and settings 

3) Enter, verify, and correct route information for the flight. 

Figure 5a TAP HMI V2 Initialization Screen 

The V4 Startup Checklist Screen provides greater integration of initialization items in the V2 

Initialization Screen, eliminating some individual items, and aggregating them more globally. For 

example, information sources, e.g., Time, Own ship State, Flight Control Computer (FCC), Mode 

Control Panel (MCP), and FMS are no longer specifically highlighted and are handled by TAP 

automatically in the back ground. 

The Checklist Complete tab in V4 replaces the Accept button in V2 and ensures that the pilot has 

verified that the correct Navigation Database and TAP versions are being used. The TAP 

Connection tab consolidates the various data sources and indicates that TAP data sources are 

available and operational. The Startup Checklist Screen contains additional information fields that 

are not included in the V2 Initialization Screen, and thus makes more effective use of available 
62

display area, while integrating additional pertinent initialization information into one display 

screen. Also included in the Startup Checklist Screen (Figure 5b) are departure and arrival airport 

information and an input that allows the pilot to enter and verify the Route Waypoints along the 

flight plan. The Startup Checklist Screen also allows the pilot to select TAP optimization criteria, 

e.g., Cost Index, Cruise Altitude and Speed, and provides the Max Optimization Waypoint (WPT), 

representing the waypoint along the route to which TAP should seek trajectory improvement 

opportunities. The Checklist Complete tab allows the pilot to confirm that checklist items have 

been completed. 

Figure 5b TAP HMI V4 Startup Checklist Screen 

The V4 Startup Checklist Screen is considerably more consolidated in its information content and 

integrates additional pertinent information in one display screen when compared to the V2 

Initialization Screen. In addition, the use of selection windows (e.g., drop-down/pop-up) and 

keyboard entry allow for clear and easy to use entry and selection of information by the pilot. 

Upon completion of accepting (V2) or completing the checklist (V4), TAP checks whether or not 

the aircraft has achieved an altitude above 10,000 ft. TAP HMI V2 utilizes a Standby Screen 

(Figure 6) that is automatically displayed if the aircraft has not yet reached 10,000 ft. The current 

altitude is displayed to allow the pilot to readily see the flight status relative to the 10,000 ft. 

criteria. TAP HMI V4 eliminates the use of the Standby Screen and automatically transitions to 

the Auto Mode Screen that will be described in the next section. For V4 a “Standing by for 10,000 

ft.” TAP message is displayed in the Message Window of the Auto Mode Screen when the flight 

has not yet reached 10,000 ft. altitude above the ground. 

Once an altitude of 10,000 ft. is reached, V2 transitions from the Standby Screen to the Auto Mode 

Screen, while V4, already using the Auto Mode display, clears the “Standing by for 10,000 ft.” 

message in the Message Window. 
63

Figure 6 TAP HMI V2 Standby Screen 

4.2.5.3.2.2 Auto Mode Screens 

Figure 7 and Figure 9 illustrate the TAP HMI V2 and V4 Auto Mode Screens, respectively. 

4.2.5.3.2.2.1 TAP HMI V2 Auto Mode Screen 

For V2, the Auto Mode Screen provides designation of Mode (Auto or Manual) in the upper right 

corner, Controls across the top of the display for 1) selecting the number of Off-Route Waypoints 

(maximum of 0, 1 or 2) that TAP uses to compute trajectory improvement opportunities, 2) the 

optimization criteria of Time or Fuel, and 3) thresholds of lbs. of fuel saving and / or time savings 

used for filtering TAP solutions. The lower portion of the V2 Auto Mode Screen provides lateral, 

vertical, and combo (lateral and vertical) solutions on the left side, with outcomes of projected fuel 

and time impact (savings or losses) for each solution along the right side. 

The pilot can select any solution from the V2 Auto Mode Screen and can freeze it for display on 

the Selected Optimization Screen, illustrated in Figure 8, for further assessment prior to making 

an ATC request for a revised clearance of the new trajectory. The Selected Optimization Screen 

displays the selected optimization candidate and its outcomes, along with a listing of the waypoints 

and their Track To heading and Distance on the left side of the display (see Figure 8). The right 

side of the display provides a graphical depiction of lateral and combination views of the trajectory 

being assessed (depicted in blue) for possible request to ATC and also provides the original flight 

plan being followed (depicted in magenta). No graphical view is provided for vertical candidate 

solutions. 
64

Figure 7 TAP HMI V2 Auto Mode Screen 

4.2.5.3.2.2.2 TAP HMI V4 Auto Mode Screen 

The TAP HMI V2 Auto Mode Screen has undergone significant revision for the TAP HMI V4 

Auto Mode Screen (see Figure 9). From Figure 9, the V4 Auto Mode Screen consists of three 

panels: 1) the Solutions Panel in the upper left, 2) the Visualization Panel on the right half side, 

and 3) the Optimization Control Panel in the lower left of the Auto Mode Screen. In addition the 

Auto Mode Screen utilizes additional Top Bar and Bottom Bar status and control elements that 

increase pilot awareness of TAP operation (Cruise settings, Data Feeds, Auto Mode) and allows 

intuitive and easy control updates (display layers and wind flight level), and data recording (e.g., 

ATC Approved and ATC Denied). In addition, the Message Window on the middle left hand side 

informs the pilot of general TAP messages (e.g., “Standing by for 10,000 ft.”, “Updating Wind 

Data”, “Updating Active Route”), Auto Mode messages (e.g., “Processing”, “Monitoring for 

Optimal Solutions”, “No Predictions – Initial Turn Too Large”), and Manual Mode messages (e.g., 

“Ready to Create Route”, “Clear”, “SUA” / “Wx” / “Traffic” constraints / hazards impacting the 

candidate route, “Add Rejoin WPT”, “Unable to Rejoin Route at {waypoint name}”, “No 

Predictions – {waypoint name} Not Recognized”, “No Predictions – Excessive Turn at {waypoint 

name}”). 
65

Figure 8 TAP HMI V2 Selected Optimization Screen of the Auto Mode 

The V4 Auto Mode Screen effectively integrates two of the V2 Auto Mode Screens into a single 

display screen. V4 Auto Mode makes better use of the display area by effectively using display 

space without excessive information density, careful intuitive layout, and using color effects, 

shading and raised, 3D depth on tabs and display fields. Using these techniques, the V4 Auto Mode 

Screen combines both the V2 Auto Mode Screen (Figure 7) and the V2 Selected Optimization 

Screen (Figure 8) into a single V4 Auto Mode Screen, while also including Top Bar and Bottom 

Bar Controls and the Message Window (Figure 9). 

From Figure 9, the Solutions Panel in the upper left portion of the V4 Auto Mode Screen 

effectively integrates the entirety of the V2 Solutions and Outcomes Panels. The V2 Auto Mode 

Screen - Controls Panel portion is also integrated into the lower left portion of the V4 Auto Mode 

Screen. In addition, the V2 Selected Optimization Screen from V2 is integrated into the right hand 

side of the V4 Auto Mode Screen as the Visualization Panel. 

Figure 9 illustrates highlighting of the best solution using a green border that outlines the solution 

field (waypoints and outcomes). In addition Figure 9 illustrates the graphical depiction of the 

Preview Solution, from the Solutions Panel (upper left), into the Visualization Panel (right hand 

side); the double horizontal parallel lines, highlighted in lighter blue color, tie the textual Solution 

and Outcome to the graphically displayed Preview Solution (Cyan) in relation to the FMS active 

route (Magenta). 

The V4 Auto Mode Visualization Panel provides much improved graphical depiction of route 

information providing scale and orientation and also provides zoom in / out and step capability for 

viewing the active and preview routes. 

When using the Auto Mode, TAP only identifies and provides flight trajectory / route improvement 

candidates to the pilot that are clear of hazards / conflicts (e.g., traffic, weather, SUA). In the rare 

case that a hazard / conflict would be present and be observed by TAP and yet TAP offers the route 
66

as a candidate solution, the hazard would be indicated in the Message Window and also in the 

graphical route depicted in the Visualization Panel. 

Figure 9 TAP HMI V4 Auto Mode Screen 

Note 1: As indicated above, presence of a hazard / conflict should not occur for solution candidates offered by TAP when operating in the Auto Mode. In the event of this unplanned, 

rare occurrence, display of the hazard in the Message Window and Visualization Panel 

serves to mitigate any adverse effects of potentially misleading information. 

Note 2: Unlike Auto Mode, when the pilot utilizes the TAP Manual Mode to explore potential 

trajectory route improvement opportunities, TAP will evaluate the pilot’s route input 

for potential fuel and/or flight time savings, but in addition, will also evaluate the candidate route for potential hazards. When hazards are present that impact the desired 

route, this will be indicated in the Manual Mode Screen Message Window and also its 

Visualization Panel. The Manual Mode HMI is described below in the next section. 

Note 3: The description and comparison of the TAP HMI V2 and V4 provided above are 

relatively high-level and are intended to provide sufficient overview and insight into 

the TAP HMI design to allow identification of any issues that may affect certification 

of the TAP HMI for use as a flight-deck application. Additional details on the specific 

use of the TAP HMI (e.g., controls, status indications, use of drop-down and pop-up 

menus for selection purposes, and keyboard entries for input and editing) were derived 

from the respective pilot training presentations (in the form of PowerPoint slides and 

graphics) that were provided as training inputs to the pilots that participated in the two 

HITL experiments [32] for HMI V2 and [33] for HMI V4. 
67

4.2.5.3.2.3 Manual Mode Screens 

Figure 10 and Figure 11 illustrate the TAP HMI V2 and V4 Manual Mode Screens, respectively. 

4.2.5.3.2.3.1 V2 Manual Mode Screens 

The TAP HMI V2 Manual Mode Screen (Figure 10) is relatively basic in its use, providing the 

pilot a textual means to edit the active route to explore trajectory change candidates for fuel and / 

or time savings. The pilot must first specify the desired Reconnect Waypoint to which TAP will 

evaluate the proposed trajectory change. A pop-up window (not shown) lists the waypoints 

associated with the active route from which the pilot selects the Reconnect Waypoint. The pilot 

then selects 0, 1, or 2 off-route waypoints in creating the route that he or she wants to have TAP 

evaluate that can either be entered via keyboard or using the Find WPT tool for waypoint search. 

The pilot can also provide the desired flight-level change if he or she wants to evaluate a new flight 

level over the active route. At this pilot can choose to submit the entered route for evaluation by 

TAP. 

Figure 11 illustrates the results of an example evaluation of a manual-mode entered route by the 

pilot. While the example provided is not reflective of a good selection, it serves to demonstrate the 

outcome of the solution in terms of fuel and time impact compared to the current active route, 

while also indicating that the route under evaluation is impacted by both traffic and weather 

hazards / constraints and should thus not be requested from ATC. 

4.2.5.3.2.3.2 V4 Manual Mode Screen 

As was the case for Auto Mode, the TAP HMI V2 Manual Mode Screen has undergone 

considerable revision for the TAP HMI V4 Manual Mode Screen (see Figure 12). From Figure 12, 

the V4 Manual Mode Screen consists of three panels: 1) the Entry Tools Panel in the upper left, 2) 

the Visualization Panel on the right half side, and 3) the Route Tray Panel in the lower left of the 

Manual Mode Screen. The Manual Mode Screen utilizes additional Top Bar and Bottom Bar status 

and control elements that increase pilot awareness of TAP operation (Cruise settings, Data Feeds, 

Auto Mode) and allows intuitive and easy control updates ((display layers and wind flight level), 

and data recording (e.g., ATC Approved and ATC Denied). 

The TAP HMI V4 maintains overall compatibility between Auto Mode and Manual Mode Screens, 

with the notable exception relating to the fact that Manual Mode involves pilot entry of route 

information via the Entry Tools Panel and output of route evaluation results from TAP via the 

Route Tray Panel; otherwise the Auto and Manual Mode Screens are very consistent in their use 

and in their display representations for V4. 

In the V4 Manual Mode Screen, the pilot utilizes the Entry Tools Panel (upper left in Figure 12) 

to select flight level (FL) changes if desired, can add 1 or 2 waypoints via the Add WPT tab and 

also provides the rejoin waypoint via the Rejoin WPT to enter the route for evaluation by TAP. 

The Route Tray (lower left in Figure 12) allows textual display of the Message Window, 

identifying status and potential hazards (e.g., Traffic, Weather), and providing estimated effect of 

the proposed route on fuel and /or flight time in the Outcome Window. 

Figures 13, 14, and 15 provide several illustrations of the V4 Manual Mode Screen, with emphasis 

on the use of the Visualization Screen (right half of display area) using Preview Route, traffic 

hazard, and weather hazard depictions, respectively. 
68

Figure 10 TAP HMI V2 Manual Mode Screen 

Figure 11 TAP HMI V2 Manual Mode Screen with Evaluation Results 
69

Figure 12 TAP HMI V4 Manual Mode Screen 

Figure 13 illustrates the results of a manual route entered by the pilot using two off-route waypoints 

(NEWA and NEWB), rejoining the Active Route at NEXTE. Heading and distance are indicated 

to the next waypoint. The Route Tray provides depiction of the waypoints and indicates that they 

are free of hazards and indicated by the green simulated light-emitting diodes (LEDs). Also shown 

are the anticipated outcome for fuel and time savings. 

Figure 14 illustrates the V4 Manual Mode Screen for the scenario where a traffic hazard is impacting the pilot-entered route. This does not necessarily indicate that the aircraft would be on an 

immediate collision course, however. It indicates only that traffic is in the vicinity with separation 

loss being a possibility (TAP uses a significant buffer on the minimum separation criteria). As 

noted in the dialog boxes in Figure 14 (not part of the actual TAP display symbology, but to help 

highlight the display elements), the traffic is depicted in the Visualization Panel by a white line 

that represents the current track, flight level, and vertical trend (in this case traffic is climbing). 

Also shown is the general portion of the pilot-entered route being impacted via the dashed yellow 

line terminating at the NEXTC waypoint, representing the portion of the route affected by the 

traffic hazard. This depiction of traffic intentionally does not show the actual or predicted location 

of traffic at any point in time, but is only intended to provide situational awareness to the pilot that 

traffic is in the vicinity and the general impact to the Preview Route that the pilot is considering 

for evaluation by TAP (direct to NEXTC in this case). 

The Route Tray includes the Message Window which provides the textual indication of “Traffic” 

highlighted in yellow indicating the existence of the hazard; also contained in the Route Tray is 

the textual waypoint name impacted by the traffic hazard, i.e., NEXTC, with the status LED 

activated in yellow. 

Figure 15 illustrates the V4 Manual Mode Screen for the scenario where a weather hazard is in the 

vicinity of the current route. The weather hazard is shown in the form of a polygon (shown in 

white); the yellow dashed line indicates the orientation and general direction and distance of the 
70

weather hazard from the approximate location of own ship to the impacted waypoint along the 

current route (in this case NEXTE). This graphical depiction of the weather hazard provides the 

pilot with situational awareness and also allows the pilot to potentially request a candidate route 

using the manual mode for evaluation by TAP. 

The Route Tray includes the Message Window which provides the textual indication of “Weather” 

highlighted in yellow indicating the existence of the hazard; also contained in the Route Tray is 

the textual waypoint name that would be impacted by the weather hazard, i.e., NEXTE, with the 

status LED turned yellow. 

Figure 13 TAP HMI V4 Manual Mode Screen – Preview Route Depiction 

This section has attempted to provide an overview of TAP HMI V2 and V4, with emphasis on V4. 

V4 currently represents the most mature HMI interface developed by NASA for the TASAR EFB 

application and incorporates pilot feedback from HITL-1 [32], the initial flight trial of TASAR 

[8], and other pilot engagements. TAP HMI V4 has undergone assessment in a second HITL 

evaluation (HITL-2) at the University of Iowa OPL. The data of HITL-2 is currently being 

analyzed. 

Additional details of TAP HMI V4 are not covered in detail in this document as they are not viewed 

to impact certification of the TAP HMI. A more comprehensive description of TAP HMI V2 and 

V4 can be found on the respective pilot training presentations that were provided to pilots for the 

two HITL experiments [32][33]. 
71

Figure 14 TAP HMI V4 Manual Mode Screen – Traffic Hazard Depiction 

Figure 15 TAP HMI V4 Manual Mode Screen – Weather Hazard Depiction 
72

4.2.5.4 Certification Assessment of TAP HMI V4 

Thus far in this report it has been noted that TASAR is a “Minor Effect” Class 2 EFB Type B 

application, with supporting rationale summarized in Section 2 and Appendices A and B. Also 

noted is a list of references provided of pertinent of FAA regulatory, certification, and operational 

approval requirements that were cited as part of prior certification and operational approval 

requirements assessment. Included in this assessment was the TAP HMI V2. Additionally, Section 

2.3 provided an update to changes to the cornerstone Advisory Circular (AC) 120-76C that could 

potentially affect TASAR certification. 

Section 3 described both TAP HMI V2 and V4 and identifies pilot comments and feedback that 

led to many of the enhancements to the TAP HMI that are incorporated in TAP HMI V4. 

ͶǤʹǤͷǤͶǤͳ Ͷ	Ǧ


Many of the enhancements made resulting in TAP HMI V4 directly address the ease of use and 

understanding of the TAP HMI as noted by the pilots in HITL simulation evaluation [32] and 

during actual operational flight evaluation of TASAR [8]. In addition, the majority of 

enhancements in V4 address the checklist factors that the operator needs to specifically address 

with the POI in the Tabletop EFB Evaluation Checklist #1 [14]. This checklist addresses the 

following that must be satisfactorily answered as part of the HMI design: 

• Revision history and expiration dates to be clearly presented 

• Responsiveness of EFB to inputs 

• EFB processing speed 

• Use of busy / progress indicators 

• Consistent user interface allowing selection and use of functions and navigating the display 

• Display of needed information and ease of access (avoid missing or difficult to find 

information) 

• Common actions and timely access to critical functions 

• Standard ways to perform common actions 

• Uniformity of display and controls across the application and also other applications 

• Color viewing and ability to distinguish in various lighting conditions 

• Color coding / shading / highlighting for display of critical information 

• Appropriate use of red and yellow colors (only use for warnings and cautions) 

• Readability of text (including in low-visibility conditions) 

• Contrast of text in relation to display background 

• Use of upper and lower case frequency 

• Ease of bringing out of view information into view 

• Icon and symbol functions obvious and distinguishable/explained by label or other means 

• Ability to quickly and accurately find information 

• Consistency of information layout 

• Ease of being able to read high-priority information 

• Easy to determine open/active application(s) 

• Detection of incorrect information formats / data range, and error messages 

Note: The detailed Checklist 1 questionnaire is provided in Appendix D (D.1). 
73

TAP HMI V4 includes many updates and enhancements that are responsive to the pilot feedback 

from [32][8] and the above list of Checklist #1 Questionnaire used for POI review and approval 

[14]. While these are expected to significantly improve the TASAR EFB application, they are in 

themselves not critical with respect to having an adverse effect on to the TASAR FEC of “Minor 

Effect” that has already been established in our discussions with FAA approval authorities. The 

aggregate of changes made for the TAP HMI V4 from the list of items above all serve to improve 

the usability of the TAP HMI, but they do not raise any certification issues that impact the TASAR 

“Minor Effect” FEC. However, the updates to the TAP HMI V4 Visualization Panel as described 

in Section 3.2.3.2 were significant and require closer scrutiny with respect to potential certification 

impact to TASAR. The certification ramifications of these updates to V4 are discussed next. 

TAP HMI V4 enhancements to the Visualization Panel, particularly for Manual Mode, but also 

potentially a factor in the Auto Mode are 1) the graphical depiction of traffic hazards (Figure 14), 

2) graphical depiction of weather hazards (Figure 15), and 3) the implicit approximate location of 

own ship that can be inferred from the Visualization Panel, i.e., with own ship generally located 

near the bottom center of the Visualization Panel. 

Note: While the pilot’s use of the Manual Mode to evaluate route improvement candidates may 

result in hazards being identified by TAP (e.g., traffic, weather, SUA), in rare cases, the 

Auto Mode may also result in the identification of hazards. In the Auto Mode, TAP 

processing is designed and intended to inhibit any hazard-impacted solutions being offered 

to the pilot via the TAP HMI, and thus should not contain hazard impacted route 

candidates. However, in the event of an unanticipated processing failure, a spurious hazard 

could potentially be displayed in the Auto Mode. The same certification assessment of the 

graphical depiction of hazards on the V4 Visualization can be applied to both Manual and 

Auto Modes. 

Note: While not explicitly shown and considered in Section 3.2 in the description of the TAP 

HMI, indication of an active SUA region on the Visualization Panel, while not a hazard, 

represents an area that the aircraft must not enter, and can be treated similar to a weather 

hazard region. This is discussed further below. 

ͶǤʹǤͷǤͶǤʹ 

As discussed in Section 2.3 (from AC 120-76C [13]), applications supporting communications, 

navigation, and surveillance are viewed as “non-EFB” software applications by FAA, requiring 

Type C, certified software, and certified hardware platforms, e.g., avionics. For TASAR, the 

display of traffic information must be carefully considered to avoid crossing into the surveillance 

functions domain or equivalently into CDTI-based applications. Pilot feedback indicated a desire 

to be provided with the “what” and the “why” in using TAP, requesting to be shown the 

information concerning the potential hazards, e.g., traffic, that may arise in using the TAP Manual 

Mode.

The TAP HMI V4 was carefully designed by NASA to provide an indication of traffic hazards, as 

shown in Figure 14, by providing a sufficient level of traffic awareness, without showing precise, 

actual traffic location and speed information. In doing so, TAP does not encroach on explicitly 

displaying surveillance / CDTI-based information that may be (mis)used by the pilot for 

operational guidance, maneuvering, and control, but does serve to provide the situational 

awareness that the pilots have requested in their use and evaluation of the TAP HMI. 
74

The TAP HMI V4 display of traffic hazard information does not raise any additional certification 

issues commensurate with the TASAR “Minor Effect” FEC. Even in the event that the traffic 

information is erroneously displayed on the TAP display, while undesirable, this does not 

adversely affect the safety of operations, as significant mitigations are in place in using the TASAR 

application. Section 4.6 reiterates some of the major mitigations that support the TASAR “Minor 

Effect” FEC. 

ͶǤʹǤͷǤͶǤ͵ 

AC 120-76C [13] indicates the following as it relates to the use and display of weather information 

for EFB applications: 

 “Section 11.e.4.c [13] notes that “data link EFB functions may display approved sources of 

weather for strategic / flight planning purposes”. Section 11.e.4.d [13] notes that “data link 

graphical weather from approved sources of advisory weather information can only be used 

for strategic / flight planning purposes”. “Do not use data link graphical weather information 

for tactical decisions during critical phases of flight, because data quality is uncontrolled for 

aviation use. Do not use data link graphical weather data as a substitute for airborne weather 

radar or thunderstorm detection equipment.” 

Note 1: Pertaining to “approved sources of weather”, Air carriers and operators certificated 

under the provisions of 14 CFR Part 119 are required to use the aeronautical weather 

information systems defined in the Operations Specifications issued to that certificate 

holder by the FAA. These systems may utilize basic FAA/National Weather Service 

(NWS) weather services, contractor or operator-proprietary weather services and/or 

Enhanced Weather Information System (EWINS) when approved in the Operations 

Specifications. As an integral part of this system approval, the procedures for collecting, 

producing and disseminating aeronautical weather information, as well as the crew 

member and dispatcher training to support the use of system weather products, must be 

accepted or approved. 

Note 2: The FAA has identified three distinct types of weather information available to pilots and 

operators: 

1) Observations - Raw weather data collected by some type of sensor suite including 

surface and airborne observations, radar, lightning, satellite imagery, and profilers. 

2) Analysis - Enhanced depiction and/or interpretation of observed weather data. 

3) Forecasts - Predictions of the development and/or movement of weather phenomena 

based on meteorological observations and various mathematical models. 

Not all sources of aviation weather information are able to provide all three types of 

weather information. The FAA has determined that operators and pilots may utilize the 

following approved sources of aviation weather information: 

1) Federal Government - The FAA and National Weather Service (NWS) collect 

raw weather data, analyze the observations, and produce forecasts. The FAA and 

NWS disseminate meteorological observations, analyses, and forecasts through a 

variety of systems. In addition, the Federal Government is the only approval 

authority for sources of weather observations; for example, contract towers and 

airport operators may be approved by the Federal Government to provide weather 

observations
75

2) Enhanced Weather Information System (EWINS) - An EWINS is an FAA 

authorized, proprietary system for tracking, evaluating, reporting, and forecasting 

the presence or lack of adverse weather phenomena. The FAA authorizes a 

certificate holder to use an EWINS to produce flight movement forecasts, adverse 

weather phenomena forecasts, and other meteorological advisories. For more 

detailed information regarding EWINS, see the Aviation Weather Services 

Advisory Circular 00-45 and the Flight Standards Information Management System 

8900.1.

3) Commercial Weather Information Providers - In general, commercial providers 

produce proprietary weather products based on NWS/FAA products with 

formatting and layout modifications but no material changes to the weather 

information itself. This is also referred to as "repackaging." In addition, commercial 

providers may produce analyses, forecasts, and other proprietary weather products 

that substantially alter the information contained in government-produced products. 

However, those proprietary weather products that substantially alter governmentproduced weather products or information, may only be approved for use by 14 

CFR Part 121 and Part 135 certificate holders if the commercial provider is EWINS 

qualified. Commercial weather information providers contracted by FAA to 

provide weather observations, analyses, and forecasts (e.g., contract towers) are 

included in the Federal Government category of approved sources by virtue of 

maintaining required technical and quality assurance standards under Federal 

Government oversight. 

Pilot feedback indicated a desire to be provided with the “what” and the “why” in using TAP, 

requesting to be shown the information concerning the potential hazards that may arise in using 

TAP, e.g., weather hazards and their location. The TAP HMI V4 Visualization Panel provides 

depiction of weather hazard polygons and their location relative to the active and preview routes 

(Figure 15). 

The TAP HMI V4 display of weather hazard information does not raise any additional certification 

issues commensurate with the TASAR “Minor Effect” FEC, as pilots, supported by proper 

training, are only allowed to utilize this information as part of strategic / flight planning and for 

situational awareness purposes. They must utilize the out-the-window scan, weather radar and/or 

thunderstorm detection equipment to make any tactical decisions during critical phases of flight. 

Even in the event that weather information displayed erroneously on the TAP display, while undesirable, this does not adversely affect the safety of operations as the pilot must utilize their 

weather radar and/or thunderstorm detection equipment for tactical decision making of the flight.

ͶǤʹǤͷǤͶǤͶ 

FAA AC 120-76B [34] was strict in its view of depiction of own ship on the EFB display, forcing 

a “Major Effect” designation if own ship was displayed. FAA AC 120-76C [13] relaxes this 

requirement somewhat by allowing display of own ship in certain cases. Reference [13] allows the 

display of own ship on the EFB display when the aircraft is operating on the airport surface at 

speeds less than 80 knots. However, [13] continues to maintain that display of own ship in flight 

(or on the surface at 80 knots or greater) will result in a “Major Effect” FEC, requiring the 

corresponding increase in software certification and operational approval requirements, e.g., 

requiring approved software per DO-178B. 
76

From a TASAR application perspective, the TAP HMI must not display own ship position on the 

EFB display, as the TASAR intended function is strictly as an en route advisory tool for the pilot 

and cannot support surveillance functions. TAP HMI V4 does not explicitly depict own ship on 

the Visualization Panel, but implicitly assumes that own ship is generally in the near vicinity of 

the bottom center of the Visualization Panel (refer to Figure 14 or 15). 

Note: AC 120-76 Appendix 2 [13] allows for Type B applications that utilize precomposed or 

dynamic interactive electronic aeronautical charts (e.g., en route, area and approach, and 

airport surface maps) including, but not limited to, centering and page turning, but without 

display of airborne aircraft/own-ship position. This is similar to the TAP Visualization 

Panel depicting traffic and weather hazards without explicitly depicting own ship position. 

ͶǤʹǤͶǤͶǤͷ 

As with traffic and weather hazards, pilots do want to have situational awareness of SUA areas for 

display on the TAP HMI. Unlikely weather, SUAs are not necessarily hazards, but they represent 

areas that must be circumvented by flights. Flight plans and vectors from ATC ensure that aircraft 

successfully avoid SUA when they are active. TAP provides situational awareness to the pilot for 

SUA(s) in the form of polygon shapes and locates them in the proper location and orientation 

relative to the active and preview routes. In the event of misleading information that may result in 

improper or missing depictions of SUAs on the TAP HMI, while undesirable, sufficient 

mitigations are in place to mitigate any safety effects. Proper training to follow the actual flight 

plan via the FMS, ATC clearances, and ATC monitoring of flight progress will prevent inadvertent 

entry into an active SUA. 

ͶǤʹǤͷǤͶǤ͸ Ǣ

With the TASAR application having a “Minor Effect” FEC, associated information sources must 

be of comparable quality (accuracy, timeliness, and integrity) to maintain the probability of 

missing and undetected misleading information in line with the “Minor Effect” designation. 

Information quality is not a safety issue for TASAR, but a usability issue. In order for the TASAR 

application to be accepted by pilots, it must be sufficiently available, consistent, and predictable 

in its advisory role to not create undue confusion and unnecessary workload; otherwise, the pilots 

will not utilize TASAR for its intended role of assisting the pilot to determine route improvement 

opportunities.

TASAR has a number of strong mitigations, both internal and external to the application, and is 

also supported by procedures that ensure safety. Reference [7] provides a comprehensive list of 

TASAR mitigations that support the “Minor Effect” FEC. Several of these mitigations are listed 

below:

• The pilot has responsibility to evaluate TASAR-provided trajectory change request 

candidates before making a change request to ATC, providing cross-check opportunities 

to detect spurious or false trajectory change request candidates offered by TASAR 

• Pilot crosschecks of aircraft systems, e.g., FMS, weather radar, which serve as available, 

higher integrity information allowing quick check on acceptability and performance 

impacts of TASAR recommended change requests 

• ATC provides separation assurance independent of TASAR 
77

• Aircraft safety systems (e.g., Traffic Alert Collision Avoidance System {TCAS}, airborne 

Weather Radar {WxR}, and Terrain Awareness Warning System {TAWS}) provide 

hazard detection and alerting 

• ATC monitors execution and intercedes 

• Pilot Training 

4.2.5.5 TAP V4 Certification Assessment - Conclusions 

After careful review of the TAP HMI V4 improvements made by NASA in response to pilot 

feedback from the HITL-1 simulation evaluation [32], flight evaluation in an operational 

environment [8], and through pilot discussion forums, and review of the latest FAA guidance 

documents, e.g., AC 120-76C [13], this analysis concludes that the TASAR “Minor Effect” FEC 

is unaffected by the updates provided in V4. TAP HMI V4 is currently undergoing further 

evaluation and analysis in another HITL simulation experiment and in planned flight trial 

evaluations. It is anticipated that V4 improvements will continue to demonstrate that the TASAR 

application is 1) useful, understandable, and intuitive to operate, 2) provides situational awareness 

without adversely affecting workload, 3) does not interfere with the primary flight duties on the 

flight deck during nominal and off-nominal conditions, and 4) fits in nicely with flight deck 

operations, i.e., is a welcomed advisory tool that provides operational benefits of fuel and/or time 

savings. TAP HMI V4 has made many enhancements over initial TAP HMIs, addressing numerous 

pilot recommendations and is expected to bring NASA closer to eventual technology transition of 

TASAR as a flight-deck application. 

4.3 FAA Certification and Operational Approval Technical Interchange 

Meeting 

NASA and Rockwell Collins TASAR Principal Investigators met with key FAA decision makers 

regarding certification and operational approval for the NASA TASAR EFB application. A 

technical interchange meeting was held at FAA offices in Washington DC on July 24, 2013 with 

key FAA approvers of EFB and ADS-B avionics systems present, and with NASA Langley and 

Rockwell Collins participants. The meeting was scheduled for two hours duration; additional time 

was spent in dialog and demonstration of the TASAR EFB prototype. This section provides a 

summary of results from these discussions and notes any significant difference based on FAA 

feedback as compared to our original analyses. 

In general it was confirmed by FAA that the results of our safety analyses and our analyses 

concerning certification and operational approval requirements for the TASAR EFB application 

were closely aligned with FAA’s guidance materials that already exist for TASAR. FAA feedback 

reaffirmed that we had analyzed the requirements correctly as applicable to TASAR. 

Due to the “Minor Effect” FEC for TASAR as a Type B application, hosted on a Class 2 EFB, and 

the fact that existing FAA policies already fully cover the proposed TASAR EFB application, FAA 

noted that the full formalism of a Project Specific Certification Plan (PSCP) described in detail in 

this document will likely not be required. FAA noted that applicants can directly engage with the 

POI for operational approval of TASAR as currently defined, particularly in regard to the EFB 

mount and hardware installation. 
78

The following is a meeting summary along with feedback, key discussion points, and observations 

based on the discussions held with the FAA. More detailed feedback from this meeting is found in 

Appendix E. 

Meeting Highlights

FAA certification (AIR) and operational approval (AFS) personnel with approval authority for 

fielding of EFB applications and ADS-B avionics (IN and OUT) and representatives from the 

NASA TASAR team held a technical interchange meeting at FAA offices at L’Enfant Plaza on 

July 24, 2013. This meeting went very well from the NASA TASAR team’s perspective and met 

and exceeded expectations. The meeting in essence served as validation of information that was 

provided concerning future approval requirements for TASAR, per the current application 

description and concept of use [3]. Presentations provided by NASA (David Wing, the TASAR 

Principal Investigator) and Rockwell Collins (Steve Koczo, analyst of TASAR Certification and 

Operational Approval Requirements) provided an introduction to the TASAR concept, a 

comprehensive, integrated presentation of TASAR safety analyses, and assessments of 

certification and operational requirements as documented throughout this report. These 

presentations were provided to FAA prior to the meeting, and it was apparent that members of the 

FAA team took advantage to review this information going into the meeting. Per FAA, we had 

succeeded in assembling the “right team” of approvers for TASAR technologies. FAA participants 

were actively engaged throughout the 2.5 hour meeting and offered additional insight. An FAA 

representative noted that the meeting was in essence a “trial run” for how to conduct a meeting 

with FAA for certification and operational approval. 

The key result of the meeting is confirmation that existing policies already cover the proposed the 

TASAR application and we had correctly reviewed and analyzed FAA regulatory and guidance 

documents applicable for EFB applications such as TASAR. The following list summarizes 

feedback from FAA both confirming and helping to clarify some of our analysis results: 

• TASAR is a Type B application and is appropriately hosted on a Class 2 EFB 

• TASAR does not need to be added explicitly to the list of Type B applications in Appendix 

2 of AC 120-76C [13] 

• Type B applications running on non-certified hardware (e.g., Class 2 EFB) do not require 

DO-178B compliance 

• TASAR will be viewed as a “Minor Effect” application due to potential pilot workload 

associated with TASAR due to misleading / bad data. From a loss-of-function standpoint, 

TASAR is viewed as “No Effect” 

• TASAR is not an ADS-B IN applications, but rather a performance/planning application 

that leverages ADS-B IN data, if available 

• There is not a need to establish a separate standard for TASAR, allowing freedom for users 

to implement the application to fit their individual needs 

• If an operator already has an existing EFB installation, then the operational approval 

process is for the user to go directly to the POI. 

For detailed feedback and discussion items from the FAA meeting refer to Appendix E. 
79

Appendix A TASAR User Survey Results, Findings and Recommendations 

This appendix provides the detailed results of the analysis of TASAR survey results conducted by 

Rockwell Collins. Analysis results are provided and organized as follows: 

• A.1 examines current and planned systems that play a role in enabling early deployment of 

TASAR for the end user operator; operator equipage plans are considered for the possibility of 

early adoption of TASAR. 

• A.2 presents an overview of the operations and demographics of the operators surveyed. 

• A.3 examines survey responses related to challenges and disruptions to flight operations. 

• A.4 reviews the change request process in requesting a revised clearance from ATC. 

• A.5 examines tools used by pilots and dispatchers in flight planning and in-flight re-planning 

while en route. 

• A.6 discusses information sources, including their effectiveness (or lack thereof) in current 

Dispatch and flight operations. 

• A.7 identifies organizational policies, constraints, and cost factors associated with flight 

planning processes as obtained from survey responses. 

• A.8 summarizes the survey results, observations and recommendations obtained from the 

analysis of the TASAR User Survey for early adoption of TASAR. 

Note: The survey questions and corresponding responses were in many instances qualitative and 

subjective in nature. In addition, the responses represent only a small sample and thus 

cannot be used to make fundamental conclusions and extrapolations. However, the three 

operators represented in the survey and the comprehensive questions and responses from 

the various stakeholders involved in flight planning and flight execution do allow 

reasonable conclusions to be drawn that were used to inform the TASAR research team in 

developing updates to the TASAR application. 

A.1 Current & Planned Systems Supporting Potential Deployment of TASAR 

Figure A-1 provides a functional diagram of TASAR. The TASAR software, also known by the 

name “Traffic Aware Planner,” is hosted on the EFB and is enabled by information from own ship 

and via information derived via the internet and data link. Own ship data is provided via ARINC 

429 Busses from on-board systems, including the Flight Management System (FMS) and the 

Traffic Computer (the platform for ADS-B IN). These data are provided to the Aircraft Interface 

Device (i.e., Data Concentrator) for input to the EFB using the Single Text Avionics Protocol 

(STAP) interface. The User Survey probed for operator equipage (current and planned) for systems 

needed to support TASAR. Before explicitly examining the equipage results from the User Survey, 

the results of a meeting of the NASA TASAR team with FAA certification and operational 

approvers for EFB and ADS-B IN systems are noted below, as the results of this meeting 

reinforced our assessments of the level of requirements that need to be met in order to gain 

approval for operational use of TASAR. 

The TASAR User Survey requested inputs from three operators (a Global Network Carrier, 

Domestic Low-Cost Airline Carrier, and a Fractional Operator of Business Aircraft) on their 

equipage plans for the following capabilities: 
80

Figure A-1 TASAR Functional Diagram 

1) ADS-B OUT (1090 MHz or UAT) 

2) ADS-B IN (1090 MHz and/or UAT) – referred to as the Traffic Computer in Figure A-1. 

3) EFB Class (1, 2 or 3) 

4) EFB Operating System (Windows, Linux, iOS) 

5) Internet access (terrestrial network, satellite network) 

6) Data Comms (ACARS, CPDLC) 

Survey results were reviewed for each capability and for each operator. 

Note: Survey results were received during 2013; future plans and results of levels of equipage of 

the surveyed operators are subject to regulatory and market forces. The information below 

represents operator equipage and plans as of 2013 and reflect differences between operators 

and their respective markets. 

A.1.1 ADS-B OUT 

The Global Network Carrier surveyed is well on the path to equip toward the 2020 mandate of full 

ADS-B OUT equipage and tends to have relatively higher level of equipage already in place (40%), 

likely due their global operations footprint where ADS-B OUT is used more frequently (e.g., in 

Europe, Australia). While not explicitly stated, this operator will be 1090 MHz ADS-B as their 

entire fleet is Air Transport category aircraft, which will be 1090 MHz equipped per the ADS-B 

mandate. 

The Low-Cost Airline surveyed is also working toward the 2020 mandate, but is less aggressive 

in equipping its fleet compared to the Global Network Carrier. While not explicitly stated, this 

carrier will be 1090 MHz ADS-B as their entire fleet consists of Air Transport category aircraft, 

which will be 1090 MHz equipped per the ADS-B mandate. 

The Fractional Operator surveyed is currently not working toward the ADS-B OUT mandate, even 

indicating uncertainty for the 2020 mandate date. While unlikely, it is possible that some of their 
81

aircraft could equip with UAT for ADS-B (for those operating below 18,000 ft.), but in all 

likelihood, this operator will also need to equip with 1090 MHz ADS-B. 

General observations: 

• Currently anticipated ADS-B OUT equipage levels for the three operators in the survey suggest 

a relatively slow deployment, resulting in a significant number of aircraft being unequipped, 

i.e., a mixed-equipage environment is expected all the way to the 2020 mandate. 

• Aircraft not equipped with ADS-B OUT will consequently not be equipping with ADS-B IN, 

and thus these unequipped aircraft will not benefit from the ‘traffic aware’ benefits of TASAR. 

However, TASAR can be installed without “traffic awareness” if the business case warrants 

such an investment to equip. 

Note: All aircraft must have ADS-B OUT (with a few minor exceptions for aircraft that do not 

have electrical systems when certified and a few other minor exceptions). All aircraft 

operating above 18,000 feet must utilize 1090 MHz ADS-B OUT. 

A.1.2 ADS-B IN 

Based on the survey responses, Global Network Carrier currently is not planning on ADS-B IN in 

the near-term and no clear decision have been made for 2020 equipage at this time. 

The Low-Cost Airline is indicating intent to equip with ADS-B IN at levels comparable to their 

ADS-B OUT equipage plans, which is relatively slow. 

The Fractional Operator surveyed currently does not indicate any plans for ADS-B IN equipage. 

General observation:

• Without ADS-B IN, TASAR will not be able to benefit from quality ADS-B, TIS-B, and ADSR (rebroadcast) traffic data. TASAR is not reliant on traffic data from ADS-B, as benefits are 

expected to be available without traffic information. However, having access to quality traffic 

information such as provided via ADS-B is highly desirable. 

• With respect to TASAR creating a “pull” for operators to equip with ADS-B IN, this is yet to 

be determined. A strong cost-benefit case would be needed to create this “pull.” 

A.1.3 Electronic Flight Bag (EFB) 

The Global Network Carrier at present has 100% equipage of Class 2 EFBs, with some also 

equipped with Class 1. The survey response suggests that 2020 equipage plans for the class of EFB 

are not yet determined. This operator has no plans for Class 3 EFBs. 

The Low-Cost Airline surveyed has 100% Class 2 EFB equipage but will move to 100% Class 3 

EFBs in two years and beyond. 

The Fractional Operator has 100% Class 1 EFB equipage today and plans to maintain it for the 

future (to 2020). This operator also indicates that ~50% of its aircraft are currently equipped with 

Class 3 EFBs (going to 60% in 2 years). Their 2020 plans for Class 3 EFBs are undecided at this 

time. 

General observations: 

• The operators have diverse plans for EFB use spanning all Classes of use and also use of 

Operating Systems (mix of Windows, LINUX, and IOS). All users should be able to utilize 
82

their EFBs to host TASAR, although Class 1 EFBs will need to interface to an Aircraft Interface Device and will need to meet Transmit-PED (Portable Electronic Device) EMI/HIRF 

requirements for flight deck use). In the event operators integrate TASAR with a Class 3 EFB, 

or equivalently a certified Auxiliary Display System, additional approval steps will be required 

to ensure interoperability of TASAR with other approved software applications. 

• The most direct path for quick and affordable user adoption of TASAR is via a Class 2 EFB 

installation with TASAR as a Type B application. The operators are generally well on their 

way to have this capability that would support early adoption of TASAR. 

A.1.4 Data Connectivity 

The Global Network Carrier, according to their survey response, has limited internet access 

(whether terrestrial or satellite) available, at least for flight deck use. However, they likely can 

have terrestrial internet service via Gogo, as they are offering that to their passengers for cabin 

use. They also are planning to offer increasing levels of satellite internet for international flights 

via Ku-band for cabin use, which could be used by pilots as well. All aircraft of the Global Network 

Carrier are equipped with ACARS and are beginning to be capable of CPDLC (20% now, up to 

30% in 2 years). 

The Low-Cost Airline, as a domestic carrier, is planning on full equipage of terrestrial internet 

service within 2 years (if not already in place). This operator also has full ACARS equipage and 

will begin to equip with CPDLC (20% in 2 years, 100% by 2020). 

The Fractional Operator, as a business aircraft operator, already has a high-level of terrestrial 

internet equipage (80% today, 90 % in 2 years, 100% by 2020). They have only small amounts of 

ACARS and CPDLC equipage, which are typically used by air transports. 

General observation: 

• The two airline operators are fully equipped with ACARS and are beginning to equip with 

CPDLC (~20% in the near term). The Global Network Carrier has greater CPDLC likely due 

to its Future Air Navigation System (FANS) equipage needed as part of their international 

flight operations. The Fractional Operator, operating business aircraft, generally has limited 

ACARS and CPDLC (~10%), but has widespread terrestrial internet access. The Fractional 

Operator has, and within 2 years the Low-Cost Carrier will have, excellent internet access for 

their operations. The Global Network Carrier appears to be the most challenged in network 

connectivity for future TASAR use but could potentially leverage available cabin internet 

services they provide for passengers to support flight deck applications such as TASAR. 

General observation:

• Given a favorable cost-benefit business case for TASAR, all three operators could quickly 

equip with full TASAR functionality. Per our analysis of TASAR’s safety [7], certification and 

operational approval (Sections 4.2.2, 4.2.3, and 4.2.4) and subsequent meeting with FAA 

(Section 4.3 and Appendix E), the path to successfully implementing TASAR is 

straightforward with limited risk toward approval. The non-recurring expense for equipping 

with TASAR functionality is to be determined and would need to be addressed with each 

respective operator. In addition, the cost-benefit assessment likely would need to become more 

mature. The most significant cost item would be ADS-B IN equipage, when compared to the 

cost associated with EFB Class 2 hardware and internet connectivity services. 
83

A.2 General Observations on Operator Operations and Demographics 

This section characterizes and makes some initial high-level observations on the respective operator operations and their demographics; these will set the stage for more detailed review of User 

Survey results in order to draw conclusions that can help accelerate user adoption of TASAR. 

The operators in the User Survey represent a spectrum from major Global Network Carrier, LowCost Domestic Airline, and Business Aircraft Fractional Operator. Two operate in primarily 

domestic airspace (i.e., the Low-Cost Airline and the Fractional Operator surveyed). The Global 

Network Carrier surveyed has both major domestic and international operations. 

The two airlines surveyed are Air Transport operators and operate strictly Boeing and Airbus 

transport category aircraft. The Fractional Operator on the other hand operates a wide range of 

business aircraft types as part of their aircraft fleet. 

Seventy percent of Fractional Operator flights are short haul (<2 hours), while ~sixty-seven 

percent of the two airline operations are medium to long haul (>2 hours), with forty percent being 

long haul (>4 hours). As a high-level generalization, TASAR provides greatest benefits during the 

en route phase of flight, with benefits diminishing as one transitions to the terminal area, as it 

becomes difficult to affect any flight re-planning at that point during the flight. While TASAR can 

provide benefits during the entire flight regime, the early part of the flight including immediately 

after take-off and climb should still have relatively up to date information on current environmental 

constraints. It is anticipated that TASAR provides the most benefits for medium to long haul 

flights. While all three operators can benefit from TASAR, the longer haul flights of the Global 

Network Carrier and the Low-Cost Airline should be expected to gain additional benefits. 

All Global Network Carrier flights include at least one hub airport as a departing and/or arriving 

airport. 90% of the Low-Cost Airline flights have at least one hub as part of their departing and 

arriving airport. 60% of Fractional Operator do not involve a hub airport. Based on the Global 

Network Carrier and Low-Cost Airline route structures, a greater percentage of hub-to-hub airports 

flights would be expected. Since the Fractional Operator has a majority of its flights operating 

from/to non-hub airports, this removes a significant set of constraint factors related to ATC ground 

stops/holds, metering, etc. Thus while still beneficial, TASAR will not need to deal significantly 

with considering flight re-planning options to deal with ATC constraint factors. Both the Global 

Network Carrier and the Low-Cost Airline will require and benefit from TASAR’s ability to 

recommend trajectory candidates that help alleviate the severity of ATC constraints. 

General observation: 

• Of the three operators, the Fractional Operator, with its mostly short-haul operations, between 

mostly non-hub airports, has reduced opportunities to take full advantage of operational 

efficiencies offered by TASAR. Benefits are still expected, but their reduced exposure to ATC 

constraints and the shorter duration of flights offer less opportunities to achieve efficiencies. 

The two airline operators on the other hand, with their exposure to ATC constraints at the hub 

airports to which they frequently operate from/to and their generally longer haul flights, offer 

more opportunities to derive TASAR benefits. Additionally, the Fractional Operator’s lack of 

ADS-B IN equipage (at least in their current plans) reduces the “traffic-awareness” capabilities 

offered by TASAR. 

A significant difference exists in the number of pilots, average and peak number of airborne flights, 

and the number of dispatchers utilized by the three operators, ranging from very large numbers for 
84

the Global Network Carrier to relatively small numbers for the Low-Cost Airline and the 

Fractional Operator. 

General observations: 

• The Global Network Carrier has very large operations requiring many more dispatchers per 

airborne aircraft compared to the other operators surveyed. The Low-Cost Operator and 

Fractional Operator dispatchers tend to serve many aircraft per dispatcher at one time 

compared to Global Network Carrier. The Global Network Carrier likely must provide a 

greater expanse and diversity of services to support its broad, global operations. In addition, 

The Global Network Carrier’s operational complexities tend to increase Dispatch 

requirements. The Low-Cost Airline and Fractional Operator have simpler route structures and 

scheduling complexity of their operations, with considerably less dependencies on supporting 

connecting flights. These operators require only two to five dispatchers to serve 26 to 100 peak 

aircraft operations (i.e., 10 to 20 aircraft per dispatcher). The Global Network Carrier , with 

aggregate operations support for the worldwide reach of its command center, requires 

approximately one dispatcher for every five airborne aircraft. Surprisingly, per the User 

Survey, the Global Network Carrier’s Dispatch services airborne aircraft primarily when 

requested by the flight crew. 

• The Low-Cost Airline outsources some of it airline operations and supplements its Dispatch 

service using a 3rd party optimization service (i.e., Sabre). The Global Network Carrier and 

Fractional Operator’s Flight Operations are more self-managed. The Fractional Operator’s 

operations control center coordinates with FAA to manage re-routing, weather, ground stops, 

landing slots, etc. 

A.3 Challenges and Disruptive Factors to Flight Operations 

This section analyzes User Survey responses that identify the factors, frequency of occurrence, 

and level of severity to flight operations, specifically disruptive factors affecting the “actual” flight 

as compared to the original flight plan. The survey probed pilots for the frequency of “minimally,” 

“moderately” and “extremely” challenged flights they experienced during the past 12 months. 

Operator perspectives were sought for pilots, dispatcher, and flight operations personnel. 

“Minimally” challenged implies a flight minimally impacted by environmental factors, i.e., devoid 

of convective weather, no occurrence of un-forecast winds, no airspace system disruptions, and no 

adverse traffic influences. 

“Moderately” challenged implies a flight moderately impacted by environmental factors, e.g., 

regional convective weather, non-ideal winds, some airspace system disruptions, and some traffic 

delays.

“Extremely” challenged implies a flight with highly disrupted operations and severely impacted 

by environmental factors, e.g., widespread delays and diversions caused by weather, very adverse 

winds, airspace system disruptions, major traffic delays, and security events. 

A.3.1 Pilot Perspective 

Pilots indicated that ~2/3 of their flights during are past 12 months were minimally challenged / 

impacted, 25% were moderately; and 10% were extremely impacted. 
85

The estimated impact to these flights in terms of additional flight time and additional fuel 

consumption were as follows: 

• 2% time, 1.5% fuel impact for minimally challenged flights 

• 8.7% time, 9.3% fuel impact for moderately challenged flights 

• 17.7% time, 16.15 % fuel for extremely challenged flights 

General observation: 

• About 1/3 of flights are moderately or extremely impacted by adverse environmental factors, 

with ~9% to 17% impact on flight time and fuel impact. This suggests that there is considerable 

opportunity to gain operational efficiencies from decision aids such as TASAR. 

Pilots were asked to characterize the impact of various ATC constraints on operational efficiency 

considering the flights they conducted during the past 12 months. The following ATC factors were 

rated by decreasing level of severity in impacting operational efficiency: 

• Ground holds and ground stops were rated as most severe (5 out of 7, with 7 most severe) 

• Metering or miles-in-trail, also airborne holding are next severe (4.3/4.1 of 7) 

• Vectoring, speed control, re-routing due to weather are next (~4 of 7) 

• Re-routing of arrival fix, ATC preferred route next (~3.4 of 7) 

• Temporary Flight Restriction (TFR) /SUA (~2.7 of 7) 

General observation: 

• ATC holds and flow management are the primary adverse impacts on flight operations, 

followed by ATC routing. TFRs are not a significant impact. Weather was not mentioned 

excessively as key adverse effect. 

• High quality (timely and accurate) ATC constraint information would strengthen the benefits 

case for TASAR. 

A.3.2 Dispatch Perspective 

This section analyzes the factors that adversely affect the original flight plan and the reasons that 

cause flight re-planning by dispatchers. 

A.3.2.1 Factors Adversely Affecting the Original Flight Plan (Dispatcher View) 

Given that Dispatch has planned an effective flight plan prior to departure, the following factors 

(in decreasing order of severity) were identified in the User Survey as adversely affecting the 

original flight plan (from the dispatcher’s perspective). 

• ATC metering and flow management (5.33 of 7, with 7 as highest impact) 

• Three weather-related factors 

– En route weather is biggest factor for weather (4.92 of 7) 

– Destination airport weather is 4.42 of 7 

– Departure airport weather is 3.67 of 7 

• Departure delays are less of a factor 

– Due to airport surface (3.75/7) 

– Departure system delays (3+ of 7) 

• Failed on-time pushback from gate (2+ of 7) 
86

General observation: 

• TASAR, with good (i.e., pertinent, accurate, and timely) information on ATC metering / flow 

management and weather (especially en route and at the destination airport), has the potential 

to provide significant tactical re-planning capabilities for operational efficiency. With TASAR 

the key issue is its usability (i.e., providing benefits while at the same time being streamlined 

with operator dispatch, own ship flight procedures using the FMS, and with ATC’s overall air 

traffic control paradigm {change request clearances, traffic flow management, arrival 

management, etc.}). 

A.3.2.2 Reasons for Flight Re-Planning (Dispatcher View) 

The following factors were rated by dispatchers as the reasons requiring re-planning of the flight 

(in decreasing order of priority): 

• Significant Weather per Dispatch action is #1 reason (33%) 

– Also rated as the #3, 4, 5 reasons with decreasing # of responses 

• Significant Weather per notification from pilot or ATC is #2 reason (41%) 

– Also 4 and 6 with decreasing responses 

• Airspace Disruption (notified by ATC) 

– Broad spread from 2 to 7 

• Aircraft equipment failure 

– Mostly at 6 or 7, but other responses with broad spread from high to low 

• Dispatch initiated to save time, fuel, on-time arrival 

– 3 and 7 (25%) – spread over many priorities 

• Airspace Disruption (monitored and detected by Dispatch) 

– 8 (25%), but broad spread from 2 to 7 (16%, 8%) 

• Fuel Reserve 

• In-flight emergency 

– Priority 8, many small hits across wide level of priorities 

• Security Event 

– 9 (66%) 

General observation: 

• From the dispatcher’s perspective, Significant Weather as observed by Dispatch or per 

notification from the pilot or ATC are the primary reasons for re-planning of the flight. 

Airspace disruption notification from ATC follows Weather as the key factors for re-planning. 

The remaining factors are all rated approximately the same, with in-flight emergency and 

security event rated the lowest. 

A.3.3 Flight Operations Perspective 

The following represent survey responses related to disruptive and adverse factors that impact 

flight operations. 

A.3.3.1 Disruptive Flight Factors (Flight Operations View) 

The following disruptive flight factors were identified by operator flight operations: 

• Global Network Carrier view 
87

– Airspace disruptions are biggest factor (6 of 7 with 7 most severe impact) 

– Traffic Flow Management (TFM) Initiatives and poor forecast on location (5 of 7) 

– To a lesser extent, poor wind forecast, icing forecast, SUA, Notices to Airmen 

(NOTAMS) (2 of 7) 

• Low-Cost Carrier view 

– TFM Initiative is 7 of 7 

– Most others are 3 of 7 (poor wind, poor forecast at location, airspace disruptions) 

– Unexpected SUA/TFR and NOTAMS are 2 of 7 

– Poor icing forecast 1 of 7 

• Fractional Operator view 

– Airspace disruption, TFM Initiatives (5 of 7) 

– Poor wind and forecast at location (4 of 7) 

– Icing 3 of 7 

– SUA/TFR and NOTAMs 2 of 7 

General observations: 

• TFM Initiatives and Airspace Disruptions were viewed as most disruptive, followed to a lesser 

extent by poor forecasts On Location and of Winds. Unexpected SUA/TFR, NOTAMS, and 

poor forecast on icing were not viewed to be as disruptive. 

• No strong correlation between responses by operator is noted. 

A.3.3.2 Actual Flight vs. Original Flight Plan (Flight Operations View) 

The survey probed for a high-level assessment of how closely the actual flight was able to achieve 

the original flight plan performance (in terms of flight time, fuel burned, and on-time arrival) based 

on flights during the last 12 months. 

Actual vs. Original Flight Plan 

• With the exception of On-Time Arrival for the Global Network Carrier surveyed (4 of 7, 

meaning mixed results), all responses from all aircraft operators indicate 6 of 7 meeting 

the original plan (flight time, fuel, on-time). 

General observation: 

• According to the survey results, actual flights generally met expectations to original plan, OnTime Arrival being an exception for the Global Network Carrier. 

A.3.3.3 Adverse Effects on Performance (Flight Operations View) 

The following adverse effects on flight performance of actual flight relative to original flight plan 

were identified: 

• Global Network Carrier 

– Failed on-time pushback (7 of 7) 

– Adverse weather at destination (6 of 7) 

– System delays, metering, adverse weather at departure airport (5 of 7) 

– Departure delay on airport surface (4 of 7) 

– Adverse weather en-route (3 of 7) 

• Low-Cost Airline 

– Metering is highest impact (7 of 7) 
88

– All others are 3 of 7 or less 

• Fractional Operator 

– Most are 5 of 7 (departure delay on airport surface, system delays, adverse weather 

at departure airport, adverse weather at destination, metering) 

– Adverse weather en route (4 of 7) 

– Failed on-time at push back (1 of 7) 

General observation: 

• ATC factors seem to have adverse effects at a moderate level (5 of 7). Adverse en route 

weather, while an issue was rated ~4of 7. Thus TASAR has modest improvement opportunities 

related to ATC factors and a bit less impact on en route weather. 

A.4 Change Requests 

This section closely examines change requests, i.e., the number per flight, type of request, 

coordination with dispatch, and typical ATC response to the change requests. 

A.4.1 Total Number of Change Requests per Flight 

The following are the number of change requests per flight. 

• 1 or 2 per short flights (<2 hours) 

• ~equal responses of 1 or 2 and 3 or 4 (for 2 – 4 hour flight) 

– Averages to 2 to 3, with bias to 2 per flight 

• 3-4 or 5-6 (> 4 hour flight) 

– Averages to 4 to 5, with bias toward 4per flight 

General Observation: 

• Approximately one change request per flight hour regardless of length of flight (short, 

moderate, long haul). 

A.4.2 Type of Change Requests 

Pilots were asked of the type of change requests that are typical. 

• Types of change requests 

– altitude, lateral route (100%) 

– heading (~90%) 

– combination (60% responses) 

– speed (30+% responses) 

General Observation: 

• Change requests for speed are least frequent. 

A.4.3 Coordination of Change Requests with Dispatcher 

The following results address the level and types of coordination pilots conduct with dispatchers 

as part of making change requests. 

A.4.3.1 Percent of Change Requests Coordinated with Dispatch 

• Percent of change requests coordinated with Dispatch 
89

– 50% said <10% of time 

– 30% said 10-30% of time 

– 5% said 30-70% of time 

– 12.5 % said 70-90% of time (most of time) 

– Most pilots (80% said 30% or less of time), the rest tend to coordinate with Dispatch 

more frequently 

General Observation: 

• Only a small percentage of change requests are coordinated with Dispatch (~20%). A few 

pilots tend to check with Dispatch much more frequently. Not sure if this pertains to one 

specific operator. 

A.4.3.2 Type of Coordination with Dispatch 

The follow represent the type and level of coordination between pilot and dispatcher for change 

requests. 

Type of Coordination with Dispatch: 

• Dispatch initiated 

– <10% engagement 

• Pilot initiated, before change request is made to ATC 

– ~10+%

• Pilot initiates change request; no coordination with Dispatch 

– ~10+%

• Pilot advise Dispatch after the fact 

– >30%

General Observation: 

• Pilots generally initiate change requests without Dispatch input; advise Dispatch later or not at 

all. Dispatch initiates what leads to change requests very infrequently (<10%). 

A.4.4 ATC Response to Change Requests 

The following represent the typical responses and frequency from ATC to change requests. 

A.4.4.1 Type of ATC Response to Change Request 

ATC Response to change request: 

• 4 of 7, with 7 representing ‘always’ and 1 representing ‘never’ are immediately approve 

• 4.7 of 7 are cleared after standby 

• 3.1 of 7 are amended 

• 4.3 of 7 deferred to next controller 

• 2.8 of 7 denied 

General Observation: 

• ~2/3 of time approved with conditions. Slightly less than 40% are denied or deferred to next 

controller. 
90

A.4.4.2 Reason for ATC Denial of Change Requests 

Reason for ATC Denial 

• Traffic/traffic congestion, weather, metering, ATC workload: 

– Metering more often the occurrence 

– Controller workload, traffic congestion second, weather routing next 

General Observation: 

• No definitive trends are noted. 

A.5 Tools 

The following provides an overview of tools employed by dispatchers and pilots for flight 

planning/re-planning and monitoring. Effectiveness and short comings are also examined based 

on the survey results. 

A.5.1 Dispatch Tools 

A.5.1.1 Available Flight Planning Capabilities - Dispatch 

Available Flight Planning Capabilities – Dispatch: 

• Company personnel with tools (67%) 

• Automated monitoring in-house (33.3%) 

• Company personnel without tools (25%) 

• 3rd party automated monitoring (16.7%) 

• Minor reference to in-house weather department 

General Observation: 

• Most capabilities include tools (~75%). 

A.5.1.2 Tools for Monitoring Flight Efficiencies (Dispatch Perspective) 

The following tools for monitoring flight efficiencies were identified in the User Survey: 

• Sabre flight planning (used by the Low-Cost Airline surveyed) – Sabre services include 

dynamic flight planning, i.e., ability to run route scenarios, double check winds, overfly 

fees, etc., and can re-optimize during flight. The exact means for how this operator utilizes 

Sabre’s services is not specifically addressed in the User Survey. 

• Flight planning SW 

• Flight Explorer 

• Flight planning engine (Phoenix) – (not sure if this is used primarily pre-departure or also 

while aircraft is already en route 

• ATC weather feeds for big picture analysis 

• Contact crews via phone if needed 

• Flight status monitor (from FAA) – feed arrival/departure rates 

• Dispatcher can inquire position reports from Flight Management Computer (FMC) 

– Real-time information on current flight parameters 
91

• Very effective re-dispatch/re-evaluation tool (unclear how currently used en 

route)

General observation: 

• Tools provide a range of strategic and tactical capabilities with respect to monitoring flight 

efficiencies. Tactical tool capabilities seem to focus on Dispatch gaining access to a specific 

aircraft’s FMC for position reports associated flight parameter data and do not appear to 

provide a tactical integrated view of flight operations. TASAR has the ability to provide a more 

integrated tactical view from the specific own ship’s perspective, factoring in environmental 

constraints with respect to the current flight path. 

A.5.2 Pilot Tools 

The previous section examined dispatcher tools, associated information elements, and their relative 

effectiveness (or shortcomings) in the flight planning and in-flight re-planning processes. This 

section addresses the same topics from the pilot’s tools perspective for in-flight re-planning. 

A.5.2.1 In-flight Re-Planning Capabilities for Pilots 

The following represent in-flight planning tools available to pilots in decreasing order of use / 

utility as identified in survey responses. 

• In-flight re-planning capabilities for pilot: 

– FMS (100% response, i.e., always used) 

– Company provided (75%) 

– Automatic cockpit tools (62.5%) 

– Manual cockpit tools (50%) 

– Almost no 3rd party support 

– Other minor contributors to capabilities are 

• In-flight internet weather (likely the Fractional Operator) 

• Boeing wind update program (likely air transports operator(s)) 

• Ground weather radar data via internet (likely Flight Operations, or pilots 

bringing it on-board) 

• iPad Class 1 WiFi (likely provisioned by the Fractional Operator, or pilots 

bringing it on-board). 

A.5.2.2 Tool Effectiveness – Company Personnel Support without Tools 

• Tool Effectiveness – Company Support – without tools: 

– 60% of pilots do not use this approach 

– For those using this approach, this approach is viewed not to be very effective. 

A.5.2.3 Tool Effectiveness – Company Personnel Support with Tools 

• Tool Effectiveness – Company Support – with tools: 

– Much greater use than for case without tools (Section 7.2.2) (80+% use) 

– Considerably effective, particularly for Extremely Challenging and Moderately 

Challenging flights (the more challenged/impacted the flight, the more effective). 
92

A.5.2.4 Tool Effectiveness – Automated Monitoring and Advisory Service, Company 

• Tool Effectiveness – Automated Monitoring and Advisory Service, Company Resource: 

– Not used by 30 to 40% of respondent organizations 

– When used, effectiveness viewed best for most impacted flights 

• Very effective to effective in those cases. 

A.2.5.5 Tool Effectiveness – Automated Monitoring and Advisory Service, 3rd Party 

• Tool Effectiveness - Automated Monitoring and Advisory Service, 3rd Party Service: 

– ~80% do not use this approach of support 

– When used, effectiveness viewed best for most impacted flights, very effective to 

quite effective. 

A.5.2.6 Tool Effectiveness – In-flight Re-Planning by Pilots with Tools 

• Tool Effectiveness – In-flight re-planning by pilots, with tools: 

– Quite heavily used; >90%, with some drop off for extremely challenged flight, 

perhaps due to workload? 

– Very to moderately effective for all types of impacted flights. 

A.5.2.7 Tool Effectiveness – In-flight Re-Planning by Pilots without Tools 

• Tool Effectiveness – In-flight re-planning by pilots, without tools 

– Used ~70% of time 

– Somewhat effective at best. 

A.6 Information Source Assessment – Dispatch 

A.6.1 Dispatch Information Sources – Fundamental and Most Valuable Rating 

The following information sources used by dispatchers are viewed as fundamental to the flight 

planning process. An effectiveness rating is also provided based on survey results. 

Dispatch Information Sources – fundamental and most valuable rating: 

• Convective weather info – all want accurate, timely info – viewed fundamental 

• Airspace status – all want accurate and timely info – viewed fundamental 

• Wind speed, direction, temperature (80+%) – also rated high as a fundamental need 

• Airport facility status, weather / traffic info (80+%) also rated high as a fundamental need 

All seek better information, not clear how good it is for them today from survey. 

A.6.2 Importance of Information Sources for Dispatch 

The following rate the importance of information for Dispatch in-flight re-planning (by decreasing 

order of priority): 

• Accurate Convective Weather Forecasts and updates (58.3%) – Priority 1 

– Some rated it 2 (25%), 4 and 5 at 8.3% each 

• Wind speed, direction temperature – Priority 4 (50%), some also 1, 2, 3, with 3 more 

prominent (25%) than 2 (16.7), and 1 (8.3%) 
93

• Airspace Status was priority 2 and 3 (33.3%, 41.7%, respectively) 

• Airport facility status, weather, traffic info – broad 1,2,3,4 priority with 3 (33.3%) the 

highest, and 2 and 4 right behind (25%). 

General Observation: 

• Convective Weather is the highest priority source; airspace status and airport facility 

information sources are approximately equal as the next highest priority, with wind rated of 

lowest priority. 

A.6.3 Effectiveness of Information Sources for Dispatch 

The following ratings were received regarding the effectiveness of information sources for inflight re-planning. 

Effectiveness of Information Source: 

• Airspace Status - 5.7 of 7 (7 being most important) 

• Accurate Convective Weather Forecasts and updates - 5.4 of 7 

• Wind speed, direction temperature – 5.2 of 7 

• Airport facility status, weather, traffic info – 5.1 

General Observation: 

• Airspace status is 1, Convective Weather 2, Wind 3, Airport facility 4 in terms of order of 

decreasing order of effectiveness. There is not a lot of differentiation among these sources per 

survey results. 

A.6.4 Deficiencies of Information Sources 

The following identifies what information is currently either lacking or of insufficient quality (e.g., 

in terms of its availability, accuracy, and/or timeliness), that prevents Dispatch from achieving 

effective en route re-planning to enable the unconstrained flight in changing environmental 

conditions.

Lacking info / insufficient quality rating of Information Sources for Dispatch: 

• Convective Weather (Collaborative Collective Forecast Product – CCFP) 

– More frequent updates desired 

– Coverage of forecast areas often quite large 

– Level of resolution could be refined further 

– Anywhere in oceanic airspace 

Suggests weather information improvement opportunities. 

• Winds, speed/direction, temperature 

– Great value to have actual winds to utilize while in flight 

• Sabre Flight Plan Manager already provides updates 4 times a day (averages 

the 12 hour reading twice) 

Suggests an opportunity for improved information. 

• Airspace status (SUA, traffic management initiatives, etc.) 

– Real time information would be excellent (Opportunity?) 
94

– Better integration with Flight Explorer or other Aircraft Situation Displays 

(Opportunity?) – This is more a Ground Display of the big picture, not a flight deck 

display.

– Information changes so rapidly, it is difficult to keep up when monitoring 10 to 25 

flights

– Delays due to Overhead stream, aircraft limiting altitude 

• When aircraft re-file coming out of Airspace Flow Program (AFP), how 

does one know what routes may become available? (Opportunity?) 

• Airspace facility status, weather, traffic 

– Real-time Airport Facility Braking Action web-site (similar to Runway Visual 

Range (RVR)) would be excellent; during snow storms 

– While improved, still have time lags in information pushed out to Users and 

Operations Control Center 

• This is probably due to validation processes required (Opportunity?) 

– Inbound holds – are they the result of just switching runway configurations or is 

there something bigger going on? 

• Other

– Current Pilot Reports (PIREP) information from other flights (Opportunity?) 

– Time due to workload is an issue for dispatch. Dispatch requires easy to use 

information systems with associated tools. This is consistent with feedback that 

Dispatch tends to focus on flights pre-departure and not as much for en route replanning due to workload. 

General Observation: 

• Timeliness, accuracy, and breadth/extent of information must continue to improve to enable 

effective flight re-planning. At the same time information management is required to avoid 

dispatcher information overload of excessive information detail and rapidity of updates. This 

requires intelligent automation to support dispatchers to allow them to “manage” the planning 

and re-planning of flights while keeping workload at reasonable levels. 

The following represent factors identified by dispatchers surveyed that constrain re-planning of 

the current flight (in decreasing order of severity): 

• Fuel reserve is most significant constraint factor (4.4 of 7, with 7 as most severe impact) 

• Lack of accurate and timely weather information (4.2 of 7) 

– TASAR Opportunity 

• Lack of sufficient information on airspace status (3.6) 

• Lack of sufficient flight status information (3-) 

• Connecting flight (2-) 

General observation: 

• Clearly both Dispatch and the aircraft can benefit from improved information, particularly 

related to weather. Airspace information seems to be less of a factor. TASAR likely plays a 

tactical role in re-planning of the flight, while Dispatch is more strategic. 

Effectiveness of Current Flight Optimization Capabilities (and available time): 
95

• Only moderately effective (4+ of 7) 

– Slightly better for Minimally Impacted, slightly worse for Extremely Impacted 

Weather

General observation: 

• Dispatchers overall rate current flight optimization capabilities, and available time to do so as 

moderately effective (~4 out of a best rating of 7). 

A.6.5 Information that Would Significantly Improve the Flight Re-Planning Process 

The following information elements and associated improvements were identified by dispatcher 

survey respondents that they believe would significantly benefit the flight re-planning process. 

Beneficial Information Elements for Flight Re-Planning: 

• Accurate convective weather forecasts, i.e., updates on already occurring weather 

– Areas of moderate to severe/extreme turbulence 

– When convective activity is expected to affect route 

• Movement and speed of storms 

• Winds, speed and direction, temperature 

– Large change over short distances may help with turbulence forecast for a specific 

route

• Airport status (SUA, traffic management initiatives, etc.) 

– Real-time updates would be excellent 

– Airspace congestion, constraints, closure 

– Overhead stream issues 

• How long a wait versus filing another route; stuck in conga line – or another, 

better route for $100 to $200 additional cost 

• Airport facility status, weather, and traffic 

– National Airport Facility Braking Action website 

– Aerodrome closures, take-off and landing runways in use; RVR information; 

Navigation and runway NOTAMS 

– If airport back-ups occurring, would like to know so could slow down and save fuel 

General Observation: 

• A number of improvement opportunities are identified. It would be beneficial to more closely 

evaluate the major aspects of flight planning / re-planning processes and how they translate 

into successful conduct of the flight. Further analysis on which and how improvements in 

information quality will provide improved flight planning and in-flight re-planning is 

warranted. 

Additionally, the roles of Dispatch in planning and in-flight re-planning, in conjunction with 

the role of the flight deck (applications and flight crew capabilities) in performing in-flight replanning using tools such as TASAR, should be clearly delineated and allocated synergistically

for maximum benefit. In addition, re-planning in the presence of changing environmental 
96

factors needs to be accomplished in a consistent way with current and future ATC processes 

and procedures, again to be synergistic in nature. 

General observation: 

• Tools are generally employed. Without tools, any support is not viewed as effective. Handson company support is used significantly (80+ %) and is moderately and at times very 

effective. Automated monitoring and advisory services are used less frequently but when used, 

are effective. Most (80%) do not use 3rd party automated monitoring and advisory service 

support. Effectiveness is always best for the more impacted flights (extremely and moderately 

challenged). Pilot in-flight re-planning with tools is heavily used (90%) and very to moderately 

effective (perhaps used a bit less when extremely challenged – perhaps due to pilot workload 

(?)). Without tools, pilots still attempt to try to consider re-planning, but only with somewhat 

effectiveness at best. 

A.7 Flight Re-Planning Organizational Policies, Constraints, and Cost Factors 

This section examines organizational policies and procedures utilized by the operators surveyed 

with respect to the pilot’s ability to initiate in-flight re-planning of the current route. Also examined 

are constraints identified to the flight planning / re-planning process, and cost factors affecting 

operations.

A.7.1 Organizational Policies and Procedures for Flight Changes 

Based on User Survey responses from dispatchers from the three operators, a broad range of 

organizational policies and procedures are utilized by the operators for flight changes. 

More than half of the responses (7 of 12) indicate that pilot can initiate altitude and speed changes 

on their own discretion, while route changes must be done via dispatch. 

A small number of respondents (2 of 12) indicated that no policies are in place (conjecture is that 

this is likely Flight Options, due to the nature of their more flexible and diverse nature of end users 

and transportation needs). 

A small number of respondents (2 of 12) indicate that pilots may initiate (flight plan changes), but 

these must be approved by Dispatch. 

One respondent indicated that the pilot can initiate a change request without Dispatch input as long 

as it is within the context of the predefined Operations Control Manual. 

General observation: 

• Pilots have considerable latitude for flight changes, particularly for altitude and speed changes, 

guided by the company Operations Control Manual. Request for route changes are more likely 

to require Dispatch approval. Sufficient pilot empowerment is in place at the surveyed 

operators to allow utilization of TASAR capabilities to seek improvements to the current flight 

plan.

A.7.2 Flight Optimization by Dispatchers 

Dispatchers were asked regarding the extent of time they generally spend on optimization of each 

flight and to what thresholds of flight time savings and/or fuel savings they would consider replanning of a flight. 
97

A.7.2.1 Time Spent on Flight Optimization 

Dispatchers were surveyed concerning time spent per flight on optimization of the flight: 

• 50% answered less than 5 minutes 

• 41.7% answered 5 to 10 minutes 

• 8.3% answered 11 to 25 minutes 

Note: One wonders about the trade-off on time spent versus savings achieved – if airlines are 

not focused on this (i.e., not spending more or sufficient time to improve efficiency of flights), 

then they either do not have the means to do better in the way of tools of available quality 

information, or it is not a big cost issue (or they are not business focused – which is unlikely). 

A follow-up question would be concerning which flights should Dispatch expend more effort 

on optimization – long haul and/or international flights? Also, once operators are able to 

operate in more of a “free flight” airspace perhaps in NextGen, with fewer constraints imposed 

(versus the more rigid route structures of today’s operations), then more significant gains can 

be made, and greater focus on optimization by Dispatch may be warranted. 

A.7.2.2 Time and Fuel Savings Threshold for Re-Planning (Dispatch View) 

Dispatchers were asked at what level of savings (flight time and/or fuel) that they would consider 

an en route (in-flight) re-planning of a flight. 

Time Savings Threshold for En Route Re-plan: 

• Dispatchers responded with ~3 minutes average flight time savings (but also had wide 

variance in responses up to 15 minutes) 

Fuel Savings Threshold for En Route Re-plan: 

• Dispatchers responded with ~150 lbs. average flight time savings (but also had wide 

variance in responses up to 400 lbs.). 

A.7.3 Flight Planning Constraints 

This section examines survey responses related to constraints faced by Dispatch and Flight 

Operations in flight planning and for en route in-flight re-planning processes. 

A.7.3.1 Flight Planning Constraints (Inability to Achieve the Unconstrained Flight) 

Dispatchers were probed to identify the extent that ATC-preferred routes, TFM Initiatives, and 

SUA had on being able to achieve an unconstrained flight plan. 

• Due to ATC Preferred routes, TFM Initiatives, SUAs 

– 50% of dispatchers indicated that flights are very to significantly constrained due 

to these factors 

– 25% indicate moderately constrained 

– 25% indicate no or little constrained flights (conjecture that this is likely an input 

from the Fractional Operator surveyed, who are viewed to be less impacted by ATC 

constraints due to their operations from/to non-hub airports.) 
98

A.7.3.2 Company Constraints for En route Re-Planning (Flight Operations View) 

The following represent the constraints and their priorities to be considered by pilots when 

initiating en route re-planning as viewed from the Flight Operations perspective: 

• ‘Arrival time for critical connections’ 

– This is the highest priority constraint for Global Network Carrier surveyed (1 of 7, 

with 1 being most significant constraint factor) due to their networked route 

structures needing to support connect flights. 

• The Low-Cost Airline only rates this (4 of 7) 

• The Fractional Operator rates this least important (7 of 7) since meeting 

connecting flights is not a factor for Flight Options. 

• ‘Requirements for fuel stop’ are the highest constraint for the Low-Cost Airline (1 of 7), 

followed by the Fractional Operator (2 of 7), and Global Network Carrier (3 of 7). 

• ‘Organization’s priority for the flight’ is the most important constraint for the Fractional 

Operator (1 of 7) due to their fractional ownership business model 

– Second most important to the Global Network Carrier (2 of 7) 

– Followed by the Low-Cost Airline (3 of 7). 

• ‘Arrival time for gate availability’ and ‘arrival sequence with other organization flights’ 

are rated relatively low on constraint importance. 

A.7.3.3 Cost Factor Rating 

This section identifies and rates cost factors provided by Flight Operations personnel from the 

operators surveyed. 

Flight Path Performance Cost Factors: 

• Fuel cost is the #1 priority for all three operators 

• Schedule integrity is tied for #1 for the Fractional Operator, #2 for the two airline operators 

• Ride quality is also tied for #2 for the Global Network Carrier, #3 for the Low-Cost Airline, 

#4 for the Fractional Operator (may suggest that VIPs and other passengers for this operator 

are more ardent fliers able to understand and handle rougher flights compared to the general 

flying public on air transport aircraft (?) 

• Flight time is #3 for the Fractional Operator, #4 for the two airlines surveyed 

Revenue Impact: 

• For the Low-Cost Airline – completion, on-time performance, and fuel efficiency are all 7 

of 7 (7 being most important) 

– Ride quality for Low-Cost Airline is 5 of 7 

• The Global Network Carrier – completion is 7 of 7, on time performance and fuel efficiency 

are 6 of 7, ride quality only 2 of 7 

• For the Fractional Operator – completion and fuel efficiency are highest (6 of 7), on-time 

is 5 of 7, ride quality is 3 of 7. 

A.8 Survey Review and Assessment Results Summary 

Section 4.1.2 provided the review and assessment of results related to the TASAR User Survey, 

with the objective to provide “findings and recommendations for the TASAR concept and 

implementation strategies that would accelerate user adoption of TASAR.” 
99

Recommendations and observations fall into two categories which are then summarized below: 

1) Equipage for TASAR 

2) TASAR cost benefits, usability, and synergy with Dispatch and ATC processes. 

A.8.1 Equipage for TASAR 

A positive finding, from an equipage perspective, is that the operators surveyed in many cases are 

beginning to equip with the type of avionics systems and associated EFB and data communication 

capabilities needed to enable TASAR. ADS-B OUT (primarily 1090 MHz), EFB Class (1, 2 or 3), 

internet access (via terrestrial and/or satellite networks) and Data Comms (ACARS, CPDLC) are 

already in their plans. ADS-B IN (1090 MHz and/or UAT) plans are considerably less certain. 

In this regard, the Fractional Operator, with its fleet of business and regional aircraft, is already 

well equipped with data connectivity to ground systems. Air transport operators, particularly the 

Global Network Carrier, are more reliant on ACARS and Data Comms and are currently not as 

connected to internet data networks, but this is improving. It is recommended that data connectivity 

is strongly encouraged for all operators to provide the most effective information access for 

TASAR. While TASAR’s traffic awareness is highly desirable, a prolonged period of mixed ADSB equipage (both ADS-B OUT and ADS-B IN) is likely a reality for several more years. Cost 

benefits from TASAR may help with this, but these must be fairly significant to create the pull for 

ADS-B equipage on their own. More likely, additional beneficial ADS-B applications for NextGen 

will need to assist with this pull. 

The most significant and encouraging findings are that the operators surveyed, representing a 

significant cross-section of aircraft operators, are beginning to have avionics and associated EFB 

and data communications capabilities capable of supporting early introduction of TASAR. 

A.8.2 TASAR Cost Benefits, Usability, Synergy with Dispatch and ATC Processes 

In order to achieve a positive business case for TASAR, two key requirements must be achieved: 

1) Access to relevant, high quality (i.e., accurate, timely {sufficient update rates, sufficient 

latency}) information sources (both ground-based and flight-deck based)

2) Synergistic integration of TASAR with available flight (re)planning tools and processes 

used by dispatchers and pilots, while also being consistent with ATC processes (change 

requests, traffic flow management including arrival flows). 

Without quality and complete information, TASAR is unlikely to provide reliable cost benefits. 

Pilot acceptance of TASAR is likely dependent on TASAR providing consistent and believable 

trajectory change recommendations with indicated savings in fuel and/or flight time. In addition, 

in the longer term, TASAR’s utility should be integrated in a consistent manner with other flight 

planning, flight optimization processes utilized by Dispatch and should be consistent with ATC 

processes and procedures. 

While initial studies indicate the benefits of TASAR [5], a thorough assessment of TASAR cost 

benefits is likely required. Current on-going and planned flight simulations (University of Iowa 

Operator Performance Laboratory pilot evaluations in the use of TASAR using a Boeing 777 flight 

simulator), flight evaluation (Advanced Aerospace Solutions’ flight trial of TASAR using their 

Piaggio Avanti P180 aircraft), and planned HITL experiments by NASA can assist in development 

of the TASAR business case.
100

The following represent a collection of general observations and comments regarding current flight 

planning and in-flight re-planning procedures, tools, information sources and their effectiveness 

(or lack thereof) as determined from survey responses from pilots, dispatchers, and flight 

operations personnel from the operators surveyed: 

1) From a Dispatch perspective, significant weather as observed by Dispatch or per notification from the pilot or ATC is the primary reason for re-planning of the flight. Airspace 

disruption notification from ATC follows weather as the next key factor for re-planning. 

2) Dispatchers rate the effectiveness of current flight optimization capabilities (and the 

available time to perform those duties) as moderately effective. These capabilities were 

slightly more effective for “minimally impacted” flights and slightly worse for “extremely 

impacted” flights due to adverse environmental factors. 

3) In assessing survey responses, it is observed that weather is a primary consideration for 

dispatchers, with ATC constraints, airspace disruptions and other constraints being 

somewhat secondary factors (still important but not at the level of weather). Conversely, 

for pilots, ATC constraints and airspace disruptions are larger factors, with en route 

weather being a secondary, less constraining factor in in-flight re-planning. 

4) Tools provide a range of strategic and tactical capabilities with respect to monitoring flight 

efficiencies. Tactical tool capabilities seem to focus on Dispatch gaining access to a 

specific aircraft’s FMC for position reports and associated flight parameter data and do not 

appear to provide a tactically integrated view of flight operations. TASAR has the ability 

to provide a more integrated tactical view from the specific own ship’s perspective, 

factoring in environmental constraints with respect to the current flight path. 

5) Timeliness, accuracy, and breadth of information must continue to improve to enable 

effective flight re-planning. At the same time, information management is required to avoid 

dispatcher information overload of excessive information detail and rapidity of updates. 

This requires intelligent automation to support dispatchers to allow them to “manage” the 

planning and re-planning of flights while keeping workload at reasonable levels. 

6) It is evident that both dispatchers and the pilots can benefit from improved information, 

particularly related to weather. Airspace information seems to be less of a factor. TASAR 

likely plays a tactical role in re-planning of the flight, while Dispatch is more strategic. 

7) From pilot survey inputs concerning use of tools, it is noted that tools are generally 

employed. Without tools, any support is not viewed as effective: 

a. Hands-on company support is used significantly (80+ %) and is moderately and at 

times very effective. Automated monitoring and advisory services are used less 

frequently but when used, are effective. Most (80%) do not use 3rd-party automated 

monitoring and advisory service support. Effectiveness is always best for the more 

impacted flights (extremely and moderately challenged) due to adverse 

environmental conditions. 

b. Pilot in-flight re-planning with tools is heavily used (90%) and very to moderately 

effective (used a bit less when extremely challenged – perhaps due to pilot 

workload). Without tools, pilots still attempt to try to consider re-planning, but only 

with somewhat effectiveness at best. 
101

c. Survey results and insight into the pilot tools used (except for FMS, which is always 

used), are not very specific and would require further investigation and dialog with 

pilots. 

8) Pilots have considerable latitude for making flight changes, particularly for altitude and 

speed changes, guided by the company Operations Control Manual. Request for route 

changes are more likely to require Dispatch approval. Sufficient pilot empowerment is in 

place at the surveyed operators to allow utilization of TASAR capabilities to seek 

improvements to the current flight plan. 

9) From a Dispatch perspective pertaining to time spent on flight optimization, there is a tradeoff on time spent versus savings achieved; if airlines are not focused or motivated to spend 

additional time to improve the efficiency of flights, then they either do not have the means 

to do better (i.e., in the way of tools and available quality information), or it’s not a big 

cost issue to be considered. It is unlikely that they are just not focused on seeking cost 

improvements due to lack of focus and is likely related tool availability. 

a. A follow-up question would be concerning which flights should Dispatch expend 

more effort on optimization – long haul and/or international flights? Also, once 

operators are able to operate in a more “free flight” airspace perhaps in NextGen, 

with fewer constraints imposed (versus the more rigid route structures of today’s 

operations), then more significant gains can be made, and greater focus on 

optimization by Dispatch may be warranted. 

10) Dispatcher can inquire position reports from FMC and derive additional real-time 

information on current flight parameters, which is viewed as a very effective re-dispatch 

and re-evaluation tool. 

a. From survey responses, Dispatch tends to play a relatively limited role for in-flight 

re-planning. This is particularly the case for the Global Network Carrier surveyed, 

who only provides support services while the aircraft is in-flight when prompted by 

pilot requests. 

b. A potential area of research is to determine to what extent should Dispatch focus 

on in-flight re-planning, which is currently not their focus, or should this be 

delegated to flight-deck tools, e.g., TASAR. What is the proper balance of Dispatch 

versus aircraft-based in-flight re-planning to ensure synergy? In addition, to what 

extent can TASAR take on flight planning typically done by dispatch, particularly 

in future NextGen operations that support “free flight” capabilities? 

11) TASAR, with good (i.e., pertinent, accurate, and timely) information on ATC metering and 

flow management, and weather information (especially en route and at the destination 

airport) has the potential to provide significant tactical re-planning capabilities for 

operational efficiency. With TASAR the key issue is its usability (i.e., providing benefits 

while at the same time being streamlined with operator dispatch, own ship flight procedures 

using the FMS, and with ATC’s overall air traffic control paradigm (change request 

clearances, traffic flow management, arrival management, etc.). 

12) A number of improvement opportunities are identified as a result of survey responses. It 

would be beneficial to more closely evaluate the major aspects of flight planning and replanning processes and how they translate into successful conduct of the flight. Further 
102

analysis on which information elements and how improvements in information quality will 

provide improved flight planning and in-flight re-planning is warranted. 

13) Additionally, the roles of Dispatch in planning and in-flight re-planning, in conjunction 

with the role of the flight deck (applications and flight crew capabilities) in performing inflight re-planning using tools such as TASAR, should be clearly delineated and allocated 

synergistically for maximum benefit. In addition, re-planning in the presence of changing 

environmental factors needs to be accomplished in a consistent way with current and future 

ATC processes and procedures, again to be synergistic in nature. 

In summary from an aircraft equipage perspective, TASAR is poised to be readily achieved, with 

the possible exception of ADS-B IN. A positive cost benefit business case is a key requirement for 

operators to continue to equip and enhance their avionics, EFB and data communications level of 

equipage for their aircraft fleets. Perhaps the most significant challenge is the development of a 

more robust cost benefit assessment for TASAR that supports synergistic usability with Dispatch 

and ATC processes as part of the in-flight re-planning to achieve operational efficiencies in the 

presence of changing environmental conditions (e.g., weather and airspace disruptions).
103

Appendix B TASAR EFB Standards Adherence Requirements 

This appendix documents the detailed results of the EFB standards adherence requirements 

assessment summarized in Section 4.2.2, with focus primarily on EFB hardware and software 

requirements, including installation considerations. 

B.1 Determination of EFB “Class” Anticipated for TASAR 

Before addressing EFB “Class” for TASAR, it is necessary to provide some context on the use of 

EFBs in the flight deck, including a few definitions provided by FAA on their intended and allowed 

use. FAA Advisory Circular AC 120-76C [13] serves as the key document providing Guidelines 

for Certification and Operational use of EFBs and associated applications. 

With significant strides continually being made on increasingly capable and versatile portable 

computing devices (hardware, software, and applications), there is a strong desire by aircraft 

operators, aircraft manufacturers, and avionics manufacturers to leverage the computing power 

and connectivity offered by EFBs for applications that provide operational benefits and improved 

situational awareness in the flight deck. The relatively low-cost of these systems potentially 

provides an effective path for new flight-deck capabilities that supplement and complement 

traditional avionics systems that provide Communication, Navigation, Surveillance support for the 

pilot to conduct flight operations. These systems also potential offer a relatively low-cost path for 

system retrofit of new capabilities. 

FAA has recently updated the original AC-120-76 document to the newly released AC 120-76C 

[13] and is already working on a future update. While trying to accommodate end user innovation 

for new EFB-based applications, FAA is also looking to ensure interference-free operation to onboard certified avionics functions. As such, FAA has established guidelines and definitions for the 

use of PEDs as EFBs (also referred to as Portable EFBs). These devices may be carried onboard 

and used by the pilot / flight crew or could be mounted for use in the cockpit. Computing devices 

may also be permanently installed in the flight deck (also referred to as Installed EFBs). Depending 

on the application and intended use, PEDs and EFBs may be used standalone or they may interface 

directly to or indirectly to (via an AID) to avionics systems. When interfacing to avionics, the 

PED/EFB can be read-only or may also transmit to onboard avionics systems. As such, FAA has 

defined requirements for PED/EFB use for these operations that will be identified below, with 

focus on applicability to TASAR. 

The following definitions apply to PED/EFB use in the flight deck. It should be noted that many 

people tend to use the term EFB in a general sense, while FAA uses these terms in more specific 

context. While the user community envisions broad use of PEDs/EFBs for a wide range of 

increasingly capable applications, FAA currently restricts the definition of PEDs/EFBs to 

applications currently allowed to replace paper documents (i.e., Type A applications) or those that 

provide some sort of algorithmic processing, e.g., performance calculations (i.e., Type B 

applications). New applications that do not necessarily map directly into these defined categories 

(i.e., type of application, e.g., Type A, B, or C) may need to be developed, validated and evaluated 

by FAA certification and operational approval personnel for their intended function before gaining 

approval. EFB Types software is further examined in Section 4 below. 

Definitions
104

The following definitions are currently used by FAA as part of EFB guidance document AC 120-

76C and are applicable to the TASAR EFB assessment presented here: 

Electronic Flight Bag (EFB) - an electronic display system intended primarily for flight deck use 

that includes the hardware and software necessary to support an intended function. EFB devices 

can display a variety of aviation data or perform basic calculations (e.g., performance data, fuel 

calculations). In the past, some of these functions were traditionally accomplished using paper 

references or were based on data provided to the flight crew by an airline’s flight dispatch function. 

The scope of the EFB functionality may include various other hosted databases and applications. 

Physical EFB displays may use various technologies, formats, and forms of communication. An 

EFB must be able to host Type A and/or Type B software applications. 

Portable Electronic Device (PED). Title 14 Code of Federal Regulations (14 CFR) Section 91.21; 

§ 121.306; part 125, § 125.204; and part 135, § 135.144 refer to PEDs and place restrictions on 

the in-flight use of PEDs. There are two types of PEDs and two methods of compliance with these 

regulations.

(1) The non-EFB PED method of compliance with PED regulations is in the current edition of AC 

91.21-1 [15], Use of Portable Electronic Devices Aboard Aircraft. Use of these PEDs is prohibited 

in instrument flight rules (IFR) flight operations, except in cruise flight. 

(2) The EFB PED method of compliance with PED regulations is in FAA Order 8900.1 Flight 

Standards Information Management System (FSIMS) [14] and AC 120-76C [13]. 

Transmitting Portable Electronic Devices (T-PED). PEDs that have intended radio frequency 

(RF) transmission capabilities. 

B.2 Classes of EFB – Hardware Perspective 

Class 1 EFB Hardware - portable commercial off-the-shelf (COTS)-based computers, considered 

to be PEDs with no FAA design, production, or installation approval for the device and its internal 

components. Class 1 EFBs are not mounted to the aircraft, connected to aircraft systems for data, 

or connected to a dedicated aircraft power supply. Class 1 EFBs can be temporarily connected to 

an existing aircraft power supply for battery recharging. Class 1 EFBs that have Type B 

applications for aeronautical charts, approach charts, or an electronic checklist must be 

appropriately secured and viewable during critical phases of flight and must not interfere with 

flight control movement. 

Portable Class 1 EFB components are not considered to be part of aircraft type design; i.e., not in 

the aircraft Type Certificate (TC) or Supplemental Type Certificate (STC).) 

Class 2 EFB Hardware - portable COTS-based computers, considered to be PEDs with no FAA 

design, production, or installation approval for the device and its internal components. Class 2 

EFBs are typically mounted. They must be capable of being easily removed from or attached to 

their mounts by flight crew personnel. Class 2 EFBs can be temporarily connected to an existing 

aircraft power supply for battery recharging. They may connect to aircraft power, data ports (wired 

or wireless), or installed antennas, provided those connections are installed in accordance with AC 

20-173.

Portable Class 2 EFB components are not considered to be part of aircraft type design; i.e., not in 

the aircraft TC or STC. 
105

Class 3 EFB Hardware - EFBs installed in accordance with applicable airworthiness regulations. 

Refer to AC 20-173 for guidance on the installation of EFB components. 

Based on the above FAA definitions of Classes of EFBs, it is noted that a PED is by definition not 

considered as part of the aircraft design (i.e., not part of a TC or STC). An Installed Electronic 

Device is by definition Class 3 and will require TC/STC approval. 

The TASAR application, as described in Section 1, does not require to be hosted in an Installed 

EFB in the flight deck, but can be hosted in a PED, i.e., Portable EFB. Thus a Class 3 EFB is not 

required for TASAR. Note: If desired, TASAR could be integrated as part of a Class 3 EFB when 

integrated with other already approved software applications. It would need to be demonstrated 

that the TASAR software (operating system and application) would not adversely affect and 

interfere with already installed, certified software applications. 

B.3 Typical EFB System Components 

Figure B-1 illustrates typical components associated with an EFB (Figure B-1 is from FAA AC 

20-173, “Installation of Electronic Flight Bag Components”, [16]). 

Figure B-1 Typical EFB System Components 

When TASAR is implemented directly as an EFB, it will need to be a “mounted PED,” requiring 

interface (wired / wireless connectivity) to aircraft systems, and primary power from a source of 

aircraft power. This requires TASAR to be Class 2 EFB. When TASAR is implemented as a PED 

(i.e., display, processor) to be interfaced through an AID {referred to as Data Interface Device in 

Figure B-1), it could potentially be implemented as a Class 1 EFB/PED. In this case, the AID (i.e., 

Data Interface Device) takes over the burden of providing the necessary interfaces and protections 

to the aircraft systems and primary aircraft power. The assessment in this report treats the TASAR 

EFB as either a direct EFB implementation, or as an indirect interface to an AID, with the AID 
106

being part of TASAR. Thus this assessment will only consider the EFB standard adherence 

requirements as a Class 2 EFB for TASAR. 

The EFB system illustrated in Figure B-1 must ensure protection and isolation of the EFB 

application from installed avionics systems in terms of system security against vulnerabilities and 

threats, e.g., computer viruses, worms, unauthorized access, and malicious access. 

B.4 Class 2 EFB Approval Requirements 

This section examines the approval requirements for a Class 2 EFB for TASAR. In addition to AC 

120-76C, another key guidance document for FAA EFB Authorization is FAA 8900.1 Change 47, 

Volume 4 “Aircraft Equipment and Operational Authorizations”, Chapter 15 “EFB Authorization 

for Use”, Section 1 “EFB Operational Authorization Process” [14]. 

B.4.1 High-Level Steps for Installation and Operational Approval of a Class 2 EFB 

The following represents the high-level steps needed to be followed for the Installation and 

Operational Approval of a Class 2 EFB for TASAR: 

1. Applicant must obtain approval via TC or STC for initial alterations related to: 

a. mounting fixture installation 

b. installation of power and / or data connectivity 

Note: Any follow-on installation must use FAA-approved data. 

2. Manufacturer, provider, or installer must assure via testing that the Class 2 EFB provides 

interference-free operation 

a. If a data transmitter is used to transmit data to the Class 2 EFB, it must be tested to 

RTCA DO-160E, section 21, paragraph M. This ensures that conduction or radiation 

of emissions do not result in interference. 

3. Applicant must obtain TC, STC approval or DER approval for installation of antennas that 

provide data to the EFB, e.g., navigation, weather data 

Note: TASAR may fall into this category as it seeks to access information from networkenabled information services. However, since TASAR is of “Minor”, or “No Effect” FEC, the 

data integrity required may be relatively minor, and TC, STC, or DER approval requirements 

of installed antennas are to be determined with further analysis. 

FAA Involvement in EFB Approval Process 

The following FAA offices are involved in the EFB approval process, 1) Certification (AIR), 2) 

Aircraft Evaluation Group (AEG) - Flight Standards (AFS), and 3) the POI. 

The role of AIR is to issue approval of type design of installation for inclusion in the TC/STC. 

AEG may evaluate new EFBs and prepare an Operational Suitability Report (OSR). 

The POI conducts reviews and issues authorization by Operational Specification (OpSpec) or by 

Management Specification (MSpec) and Letter of Authorization (LOA), A061. 

Operator Requirements 

The following are requirements to be met by the Operator for the intended function / new EFB 

capability, in this case TASAR: 
107

1. Develops the program for usage 

2. Completes an operational evaluation of the new capability 

3. Ensures that the system performs its intended function 

4. Documents non-interference per AC 91.21-1 [15] 

5. Ensures non-interference with and isolation from aircraft systems during transmission and 

reception 

6. Determines usage of hardware architectural features, persons, procedures, and equipment to 

eliminate, reduce, or control risks associated with hardware failure 

Note: Installed elements of Class 2 EFB must be entered into aircraft records when added or 

removed 

B.4.2 EFB Mounting Considerations 

Before addressing the EFB standards adherence requirements associated with mounting the 

TASAR Class 2 EFB, the following definitions (from FAA AC 120-76C) are provided to support 

the discussion: 

Mounted. Any portable device that is attached to a permanently installed mounting device. 

Mounting Device. These include arm-mounted, cradle, clips, docking stations, etc. 

Stowed. A portable device that is placed in a secure stowage location but is not available for use 

or view by the pilot in that location. 

Viewable Stowage. A portable device that is secured in an existing provision with the intended 

function to hold charts or acceptable portable device viewable to the pilot (e.g., kneeboards). 

From the TASAR application perspective, the TASAR EFB is expected to be mounted (either 

directly, or indirectly via an AID to provide the intended functions. The mounting device may be 

connected to data source(s), hardwired to an aircraft power source (or via a connector), and 

hardwired to an installed antenna. 

The mounting device must be evaluated to ensure operational suitability in all ground and flight 

operations and conditions. As such, the mounting device must: 

1) not interfere with flight crew duties 

2) be easily stowed when not in use 

3) must not obstruct primary or secondary fields of view 

4) must not obstruct egress. 

As the EFB is portable (i.e., not installed permanently as part of the flight deck), it must be easily 

removable, without tools, and by the pilot / flight crew member. The EFB must be accessible to 

the pilot / flight crew (if it is not accessible, then it must be installed via a certified installation via 

TC, amended TC or STC). The only exception to the accessibility criteria is for a remotely mounted 

antenna that provides signal reception to the Class 2 (also Class 1) EFB. 

Two types of EFB mounts can be considered, 1) a yoke mount or 2) a cockpit mount. A yoke 

mount requires FAA AIR approval, either as a TC, STC or amended TC. DER or field approval is 

not permitted. A cockpit mount requires AIR airworthiness approval and cannot be Field 

Approved. A cockpit mount represents the preferred mounting approach for TASAR. 
108

B.5 EFB “Type” Considerations 

In order to address EFB standards adherence requirements with respect to the EFB “Type” (i.e., 

with respect to EFB software), the following definitions (again from AC 120-76C) are referenced: 

Critical Phases of Flight. Includes all ground operations involving taxi, takeoff, and landing, and 

all other flight operations conducted below 10,000 feet, except cruise flight. 

Note: This definition of the critical phases of flight is per those in part 121, § 121.542. 

Approved Software. Software approved by the FAA using the current edition of RTCA/DO-178, 

Software Considerations in Airborne Systems and Equipment Certification, compliance, or other 

acceptable means. 

Note: As defined below for Type C Software – “Approved Software” applies to non-EFB Software 

that is major hazard or higher and thus requires DO-178 for certification approval. 

Type A Software Applications. Type A applications are those paper replacement applications 

primarily intended for use during flight planning, on the ground, or during noncritical phases of 

flight. Examples of Type A software applications are listed in Appendix 1 in AC 120-76C. 

Type B Software Applications. Type B applications are those paper replacement applications 

that provide the aeronautical information required to be accessible for each flight at the pilot station 

and are primarily intended for use during flight planning and all phases of flight. Type B 

applications include miscellaneous, non-required applications (e.g., aircraft cabin and exterior 

surveillance video displays, maintenance applications). Examples of Type B software applications 

are listed in Appendix 2 in AC 120-76C. 

Type C Software Applications. Software approved by the FAA using RTCA/DO-178B 

compliance or another acceptable means. These are non-EFB software applications found in 

avionics and include intended functions for communications, navigation, and surveillance that 

require FAA design, production, and installation approval. Type C applications are for airborne 

functions with a failure condition classification considered to be a major hazard or higher. 

Precomposed Information. Information previously composed into a static, composed state (noninteractive). The composed displays have consistent, defined, and verifiable content, and formats 

that are fixed in composition. 

Hosted Application. Software running on an EFB that is not installed or considered part of aircraft 

type design. 

Interactive Information. Information presented on the EFB that, via software applications, can 

be selected and rendered in a number of dynamic ways. This includes variables in the information 

presented based on data-oriented software algorithms, concepts of decluttering, and selectable 

composition as opposed to precomposed information. 

Based on the above definitions, the following observations are made: 

Type A applications are primarily intended for use during flight planning, on the ground, or during 

noncritical phases of flight and are electronic paper replacement (i.e., they do not consist of specific 

algorithms and processing, but strictly depict precomposed database information. (Refer to 

Appendix 1 in AC 120-76C for a detailed list of approved Type A applications). 
109

Type B applications are intended for use during critical phases of flight or have software and/or 

algorithms that must be tested for accuracy and reliability by applicant. (Refer to Appendix 2 in 

AC 120-76C for a detailed list of approved Type B applications).

Sample Type B applications are 1) display of aeronautical charts viewable electronically and 

allows chart manipulation, 2) Electronic Checklists available in all phases of flight, 3) Weight and 

Balance calculations / algorithms, 4) performance calculations. These must be tested and proven 

by the applicant. 

While TASAR is currently neither a Type A or Type B application (i.e., not on the approved list 

of applications per Appendix 1 and Appendix 2 in AC 120-76C), TASAR has some key 

characteristics related to Type B software applications: 1) intended for use during flight planning 

(in case of TASAR, primarily during en-route phase of flight, but potentially during the later stages 

of climb, and early stages of decent), 2) includes variables in the information presented based on 

data-oriented software algorithms (in case of TASAR, using a variety of information sources for 

subsequent processing to determine trajectory change candidates), and 3) failure classification of 

no more severe than “Minor” failure effects. 

Note: While TASAR is similar to a Type B application, it is anticipated that it has a lesser threshold 

for acceptance / approval over traditional Type B applications; TASAR being an optional, 

supplemental, advisory support tool, that the pilot / flight crew can use at their discretion (i.e., can 

choose to ignore or disable at any time for any reason). Appropriate pilot training will ensure that 

pilot / flight crew will not be distracted by TASAR during flight operation while conducting 

normal operational tasks associate with the current flight. 

Based on the above definitions, PEDs/Portable EFBs (i.e. EFBs of Class 1 and Class 2) are limited 

to perform Type A and B application, which are of “Minor” FEC. In addition, Type C display of 

own ship position application is permitted for taxi speeds below 40 kts but is not allowed for 

airborne use, otherwise this would require use of an installed Class 3 EFB and would require DO178B Software certification. This is not a consideration for the TASAR application, as own ship 

position is not part of the TAP HMI design [3]. 

Type B Software Considerations

While TASAR is currently not defined as an EFB application, and is neither a Type A nor Type B 

software application, TASAR has many of the characteristics of a Type B application. 

Type B applications may be hosted by any Class EFB (Class 1, Class 2, or Class 3). Type B 

applications do not require AIR design approval or AEG evaluation and do not require DO-178B 

software development and certification. 

For Type B applications (and also anticipated for TASAR), the following responsibilities are 

identified for the various approvers and stakeholders in the approval process: 

FAA POI Responsibilities 

1. Verifies that: 

a) application criteria and operator requirements are met 

b) data updates follow maintenance manual and inspection program procedures 

c) applicable job aids, including human factors evaluation are completed 

d) training, checking, and currency programs are approved 
110

e) operational evaluation report from operator is appropriately reviewed 

f) OpSpec or MSpec A061 is issued upon completion of authorization process, as applicable 

2. Ensures that the level of information integrity is commensurate with TASAR requirement – 

this is to be determined, but as noted, TASAR is anticipated to warrant a FEC of no more than 

“Minor”, and may even be of “No Effect” (refer to the “Analysis of TASAR Operational 

Hazards and Safety Requirements" [7]). 

Flight Standards Service (AFS) 

Flight Standards Service (AFS) provides initial operational authorization granted for hosted 

application(s) (e.g., performance and/or weight and balance applications) based on AIR 

recommendations and AEG determination of flight crew training, checking and currency 

requirements. 

Operator Requirements 

The Operator addresses the following requirements as part of the approval process: 

1. Determines usage, architectural features, people, procedures, and equipment to eliminate, 

reduce, or control risks associated with an identified failure in a system 

2. Performs 6-month operational validation per authority granted in OpSpec or MSpec A061, 

as applicable 

3. Uses both EFB device / system and conventional paper copies during evaluation 

4. Submits final evaluation report to the POI, as appropriate after evaluation 

5. Operating system and hosted application software meet criteria for appropriate intended 

functions and do not provide false or hazardously misleading information 

6. Software revision loading will not corrupt data integrity of original software. 

Note: Depending on how the TASAR application will be integrated in a PED / EFB will dictate 

the level of partitioning required: 

1. If TASAR is standalone, with its own dedicated processor (own Operating System 

{O/S}and application software) and dedicated display, this is will not require any 

partitioning or special protections 

2. If TASAR has its own dedicated processor, but shares a common display with other 

“Approved Software” applications / software (per above definition), recommended Display 

Standards, e.g., AC 25-11, Electronic Flight Deck Displays (for Part 25 aircraft) [30], and 

AC 23.1311-1, Installation of Electronic Display in Part 23 Airplanes [31] must be 

followed 

3. If TASAR is hosted with other Approved Software applications in a shared processor, 

approved partitioning techniques must be followed. These techniques are required to 

guarantee throughput and resources (e.g., memory, hard drive, avionics data, etc.) of 

Approved Software applications. 

B.6 Principal Operations Inspector (POI) Review Checklists 

This section examines the items on the POI’s checklist used to review EFB applications. Guidance 

information for the POI checklist and review process is found in Flight Standards Information 

System (FSIMS) – 8900.1 Change 47, Vol. 4, Chapter 15 – EFB Operational Authorization 

Process [14]. 
111

The following represent the high-level categories addressed in the POI checklist review. This list 

of topics frames a much larger set of questions that may be asked by the POI to review and evaluate 

an EFB application to ensure that guidance documents, e.g. AC 120-76C are being followed by 

the applicant of the application to adhere to EFB standards requirements. In general the checklist 

questions are specific to initial installations and training for a given aircraft. This list of POI 

checklist questions is not repeated here due to their length, but can be found in [14]; four checklists 

are provided in Figures 4-79 to 4-82: 

1. Figure 4-79 represents Checklist 1, ”Tabletop Electronic Flight Bag Evaluation 

2. Figure 4-80 represents Checklist 2, “Electronic Fight Bag Operational Evaluation” 

3. Figure 4-81 represents the “Evaluation Report Information Template” 

4. Figure 4-82 represents Checklist 4, “Electronic Flight Bag Line Evaluation Job Aid”. 

The high-level POI checklist review for “General EFB” are as follows: 

A. General Considerations

A first step is to research if any EFB hardware or software is covered by an existing Aircraft 

Evaluation Group (AEG) report by FAA AFS. If found, this can be used as an equivalent 

artifact(s) to expedite the approval process of the new application. 

The general consideration also focuses on workload of using the EFB application. 

Determination of whether an in-flight evaluation will be necessary is made, in the event 

that evaluation of the EFB application cannot be accomplished on the ground to 

demonstrate the intended function. (For TASAR, it should be acceptable to demonstrate 

the application on the ground rather than an in-flight evaluation, given an appropriate set 

of Use Cases / scenarios to demonstrate flight crew use of the TASAR EFB. However, 

NASA intends to perform research in flight simulators and in flight trials to assess flight 

crew performance using TASAR.) 

As part of the workload assessment, the POI will review the operator’s responses to the 

workload-related questions in Checklist 2 (as noted in Figure 4-80 in [14]. The POI will 

also verify that procedures are published and available to all EFB users and maintainers, 

that preflight procedures and checklists are revised to include the EFB, and that procedures 

are established for EFB failures (e.g., single / dual EFB failures). 

B. Physical Placement 

This portion of the POI review process focuses on the design and placement of the 

“Structural Cradle” of the EFB mount. Numerous considerations are examined, e.g., 1) 

user procedures that specify location for EFB use and also stowage; 2) verification that 

EFB location does not a) obstruct visual or physical access to flight controls and/or 

displays; b) does not obstruct emergency egress path; c) provides security during flight; 3) 

mounting device a) documented per airworthiness documentation, b) locks in position 

easily, c) able to adjust to accommodate a range of pilot / flight crew preferences and 

physical abilities, d) is durable, and e) addresses crashworthiness considerations and 

restraint of EFB when in use. 

C. Training/Procedures Considerations 
112

1) EFB documentation and policy: Verifies that a) written policy adequately address each 

specific EFB application and that published AEG recommendations have been 

incorporated into the operator’s EFB program, b) procedures are in place to 

communicate upgrades of malfunctions of EFBs to users in a timely manner; c) EFB 

information from manufacturer is incorporated into operating procedures 

2) EFB Training: Verifies that a) initial EFB training includes evaluation of knowledge 

and skill requirements and include demonstration of key tasks; b) recurrent training 

includes evaluation of proficiency with the EFB; c) minimum training, checking, and 

currency requirements are specified; d) EFB training is customized to application being 

used.

D. Validation Phase and Continued Data Collection 

1) This step verifies that a) the 6-month validation phase provides documentation by pilots 

/ users of the EFB of feedback about the EFB and its performance; and b) procedures 

specify the personnel responsible for EFB maintenance and database management. 

2) Also ensures that operator has an ongoing data collection and feedback / correction 

process that ensures suitability and reliability of data; ensures that data collection 

processes are in place and are factored into the operators Safety Management System 

(SMS). 

E. SMS Interface

The SMS interfaced verifies that: 

1) Hazards associated with use and integration of the EFB have been identified, 

eliminated, or controlled, to an acceptable level through the life cycle. 

Hazards such as misuse, hazardous misleading information due to failure or 

malfunction, loss of information when needed, miscalculation, masking of information, 

confusion, corruption of data, excessive complexity of use, accidental damage, and 

human error in use, setup, and operation have been considered; 

2) Applicant’s SMS has procedures to mitigate identified hazards, e.g., availability, 

reliability of design, cross-checking of calculation/data, crew training, and misuse 

potential;

3) Applicant’s SMS incorporates EFB hazard analysis, risk assessment and related safety 

reports.

F. Software Considerations

Verifies that procedures are established for testing software revision or database update 

prior to operational use. 

G. Hardware Considerations

Verifies that: 

1) Display lighting and reflectivity has been evaluated for acceptability in each aircraft 

model;
113

2) EFB maintenance procedures are in place for batteries, displays, display interaction 

devices, display pixel burnout, and component condition. 

In addition to the above “General EFB” areas that the POI will review, the POI will also review 

the following areas, 1) Electronic Documents, 2) Electronic Check Lists, 3) Weight and Balance, 

Flight Performance calculations, 4) Electronic Charts. These areas are in reference to current Type 

A and Type B applications and are not specific to TASAR and are thus not addressed in additional 

detail.

In addition to these above noted review categories, the POI will also assess the EFB Validation 

Phase. The POI will verify that procedures are established to collect user data for normal and 

abnormal EFB functions during the validation phase; also that the user provides a written report 

of reliability and problem resolution prior to authorization, e.g., for paperless operation (or other 

intended uses of the EFB application). 
114

Appendix C Certification and Operational Approval Guidelines and 

Regulatory Requirements for TASAR; Project Specific Certification Plan 

Appendix C describes the 5 phases of a certification project as documented in “The FAA and 

Industry Guide to Product Certification (CPI Guide)” [28]. Section C.2 describes the Project 

Specific Certification Plan (PSCP) as applied to the TASAR EFB flight-deck application. Section 

C.3 represents a high-level Compliance Check List supporting the PSCP for TASAR. 

C.1 Phases of Certification Project 

C.1.1 Conceptual Design (Phase 1) 

This phase is initiated when the applicant begins design concept for a product that may lead to a 

viable certification project. The intent is to ensure early, value added, joint involvement with an 

expectation to surface critical areas and the related regulatory issues, and begin formulating a 

preliminary PSCP. This is an opportunity to develop a mutual understanding of potential new projects. 

C.1.1.1 Phase 1 Tasks 

• Early Familiarization Meetings on design concepts 

C.1.1.2 Phase 1 Required Information 

• New designs, technology, materials, processes, etc. 

o Likely not applicable for TASAR 

• Proposed certification basis and means of compliance 

• Supplier relationships 

o TASAR EFB related hardware, software, data connectivity suppliers, if 

applicable/selected 

• Initial safety assessments 

C.1.1.3 Phase 1 Deliverables 

Deliverables are prerequisites for subsequent phases and must be completed before entering the 

next phase, unless otherwise mutually agreed by the FAA and the applicant. 

• Meeting minutes and correspondence to document decisions, agreements, schedules, 

milestones, and action item assignments 

• Preliminary certification basis considering the intended means of compliance, initial safety 

assessments, and relevant policy material and begin formulation of a PSCP 

o Identifies regulatory compliance required for the TASAR EFB application based 

on a “No Effect” or “Minor” failure effects designation 

Note: After meeting with FAA, TASAR will be designated as “Minor Effect” due to 

potential pilot workload associated with TASAR due to misleading /bad data 

(Section 4.3). 
115

• Definition and plan for resolution of critical issues, e.g. new designs, technology or 

processes, potential special conditions, exemptions or equivalent safety findings, coproduction or foreign supplier arrangements requiring undue burden assessments; etc. 

o Not expected to large extent for TASAR. TBD 

• Identify core team for commitment to developing the PSCP elements to ensure continuity 

• Phase I Evaluation Checklist (See Appendix VII of [28]). 

C.1.1.4 Phase 1 Criteria for Success 

• Commitment to the signed Partnership to Safety Plan (PSP) for the pending certification 

project.

C.1.2 Requirements Definition (Phase 2) 

Efforts in this phase clarify the product definition and the associated risks, and conclude with a 

mutual commitment to move forward with product certification. Specific regulatory requirements 

and methods of compliance or critical issues are formulated. A more formal PSCP is developed. 

C.1.2.1 Phase 2 Tasks 

• Meetings to refine product definition, requirements, and develop the PSCP 

• Preliminary Certification Board Meeting 

C.1.2.2 Phase 2 Required Information 

• Applicant’s descriptive design and production data 

• Critical issues definition 

• Refined safety assessments 

• Proposed schedule 

C.1.2.3 Phase 2 Deliverables 

Deliverables are prerequisites for subsequent phases and must be completed before entering the 

next Phase, unless otherwise mutually agreed by the FAA and the applicant. 

• Submission of application, FAA Form 8110-12 (FAA Order 8110.4) 

• Acknowledgment of application 

• Certification Project Notification (FAA Order 8110.4) and establishment of project 

• Establishment of FAA and applicant project certification team 

• Meeting minutes and correspondence to document decisions, agreements, schedules, 

milestones, and action item assignments 

• Preliminary PSCP including project milestones and related events such as program status 

reviews 

• Agreement of TC certification basis plan and definition of project issues such as means of 

compliance including special conditions, equivalent safety findings, exemptions, etc. 

• Phase II Evaluation Checklist (See Appendix VII of [28]) 
116

C.1.2.4 Phase 2 Criteria for Success 

• Commit to the early development of the PSCP. 

C.1.3 Compliance Planning (Phase 3) 

During this phase a PSCP is completed. The plan is a tool to which the responsible parties commit 

and use to manage the product certification project. 

C.1.3.1 Phase 3 Tasks 

• Project planning and PSCP development meetings 

C.1.3.2 Phase 3 Required Information 

• Initial Failure Mode and Effects Analysis (FMEA)/Safety Assessments 

• Stakeholder identification 

• Refined critical issues 

• Production processes 

C.1.3.3 Phase 3 Deliverables 

Deliverables are prerequisites for subsequent Phases and must be completed before entering the 

next Phase, unless otherwise mutually agreed by the FAA and the applicant. 

• Meeting minutes and correspondence to document decisions, agreements, schedules, 

milestones, and action item assignments 

• Signed PSCP 

• Project schedule with established FAA/applicant milestones for completion of analyses, 

test plan submission, Type Inspection Authorization (TIA), conformities, flight test, AEG 

evaluations, critical issues resolution plan, and other items affecting the completion of the 

project

• Agreed Type Certification Basis 

• Compliance Check List 

• Completion of Stage 1 on all issue papers 

• Identification of stakeholders, including suppliers, installers in the case of engines, 

propellers, or systems, etc. 

• Delegations defined with oversight criteria 

• Resource requirements 

• Conformity procedures 

• Project evaluation measures 

• Phase III Evaluation Checklist (See Appendix VII [28])

C.1.3.4 Phase 3 Criteria for Success 

• Commit to agreement on the PSCP 
117

C.1.4 Implementation (Phase 4) 

During this phase the applicant and FAA work closely in managing, refining, and achieving their 

agreed PSCP to ensure that all agreed upon product specific certification requirements are met. 

C.1.4.1 Phase 4 Tasks 

• Demonstration of compliance 

• Compliance and conformance requirements verification 

• Final Certification Board Meeting 

C.1.4.2 Phase 4 Required Information 

• Design and production analysis 

• Witnessing 

• Inspection results 

• Safety analysis 

C.1.4.3 Phase 4 Deliverables 

Deliverables are prerequisites for subsequent Phases and must be completed before entering the 

next Phase, unless otherwise mutually agreed by the FAA and the applicant. 

• Meeting minutes and correspondence to document decisions, agreements, and action item 

assignments 

• Meet milestones for completion of analyses, test plan submission, TIA, conformities, flight 

test, AEG evaluations, critical issues resolution plan, and other items affecting the 

completion of the project 

• Completed test plans/reports, conformity requests, inspections, and compliance 

documentation 

• Issue Papers, Special Conditions, Exemptions, Equivalent Safety Findings 

• Compliance and conformance findings 

• Type Design and Production approval issuance 

• Phase Evaluation IV Checklist (See Appendix VII of [28])

C.1.4.4 Phase 4 Criteria for Success 

• Manage to the PSCP 

• Conduct frequent project schedule and compliance checklist status reports, team and 

management reviews, and make revisions as needed to PSCP. 

C.1.5 Post Certification (Phase 5) 

During this phase close-out activities provide the foundation for continued airworthiness activities 

and certificate management for the remainder of the product’s life cycle. 

C.1.5.1 Phase 5 Tasks 

• Project follow-up and closure 

• Certificate management 
118

C.1.5.2 Phase 5 Required Information 

• Airworthiness limitations 

• Maintenance and operations requirements 

• Project lessons learned 

• Relevant safety data 

• Type Certificate Data Sheet 

• Evaluation findings 

• Design change data 

C.1.5.3 Phase 5 Deliverables 

• Meeting minutes and correspondence to document decisions, agreements, schedules, 

milestones, and action item assignments 

• Compliance Summary Document 

• Type Inspection Report 

• Instructions for Continued Airworthiness 

• Continued Airworthiness Management Plan 

• Phase V Evaluation Checklist (See Appendix VII of [28]). 

C.1.5.4 Phase 5 Criteria for Success 

• Work together for continuous improvement 

• Manage to the PSCP with a focus on continued operational safety 

• Provide proper levels of technical project and management leadership with frequent 

reviews to ensure project close-out to schedule and resolution of significant post-TC issues. 

C.2 PSCP with TASAR Content 

This section applies details of TASAR to the PSCP described in outline form in Section 4.2.3.4. 

Before addressing the TASAR-specific content of the PSCP, Figures C-1 and C-2 are provided 

from FAA Order 8110.4C [27] that overview the Typical Type Certification Process (Figure C-1) 

and the Implementation Phase of this process (Figure C-2). In addition, Figure C-3 is provided 

from FAA Order 8900.1 CHG 47, Volume 4, Chapter 15 on the EFB Operational Authorization 

Process [14]. Figure C-3 illustrates the high-level interactions and activity flows between the FAA 

and the applicant as part of the product certification and approval process. 

The following is a more TASAR-specific version of a PSCP (the outline repeated from Section 

4.2.3.4).

1) Purpose or Introduction 

This Project Specific Certification Plan (PSCP) represents the project plan intended to be used 

by the applicant (TBD name) and FAA for the certification and operational approval of the 

TASAR Electronic Flight Bag (EFB) system. TASAR is a Type B application to be installed 

in TBD aircraft using a Class 2 EFB (e.g., the Goodrich SmartDisplayTM EFB currently being 

used by the TASAR team for flight evaluation) along with an associated Aircraft Interface 

Device (AID) that provides read-only access to avionics such as the FMS, etc. 
119

2) Description 

The following is a high-level application description of TASAR system as developed by the 

NASA TASAR team. 

TASAR is a flight deck-based Decision Support Tool, consisting of algorithms and automation 

processing, intended as an optional, advisory-only service (i.e., in the form of recommendations) 

to the pilot crew to seek trajectory improvement opportunities over the current flight plan. 

TASAR is expected to be hosted as an application on a portable Class 2 EFB as a Type B 

application. TASAR requires read-only access to avionics systems via an AID. In addition, the 

TASAR HMI [3], as currently defined does not make use of depiction of a map of the flight plan, 

own ship position, or other geo-referenced depictions of the external environment that may affect 

the flight plan. The TASAR HMI primarily offers recommended updates of proposed trajectory 

changes to be considered by the pilot for possible request of a change request to Air Traffic 

Control (ATC) to the current flight plan. 

Figure C-4 illustrates a high-level functional diagram of the TASAR application. Based on 

inputs provided by 1) the pilot (in the form of flight objectives and optimization criteria), 2) onboard avionics systems, and 3) via data link and network-enabled communications, the TASAR 

application computes available trajectory change request candidates that may improve the 

current flight plan. Trajectory change request candidates provided by TASAR are intended to 

have a relatively high probability of ATC approval if requested by the pilot, as TASAR seeks 

to provide conflict free recommended trajectory candidates that also anticipate ATC and 

airspace constraints. 
120

Figure C-1 Typical Type Certification (TC) Process 
121

Figure C-2 Implementation Phase of TC Process 
122

Figure C-3 Approval/Acceptance Process Flow Diagram 
123

Figure C-4 TASAR Functional Diagram 

The pilot has full discretion on the use of trajectory change request information provided 

by TASAR. They can choose to use TASAR recommended trajectory change request 

candidates as part of a change request to ATC, or they can choose to ignore them. TASAR 

can be manually inhibited at any time, for any reason. 

TASAR is a supplemental system intended to provide operational benefits, without 

adversely impacting safe operations and does not replace any aircraft systems or avionics 

functions required for flight operations. 

TASAR information sources are as follows: 

1. Own ship information, e.g., flight identification (Flight ID), aircraft state (position, 

velocity, altitude), guidance / Mode Control Panel settings, flight plan and intent 

information, cost index and performance information, etc. 

2. Other traffic information via ADS-B IN, TIS-B, and/or other available sources of traffic 

information, including aircraft state, and if available, intent information. 

Note: After meeting with FAA, it was indicated that TASAR is not an ADS-B IN 

application, but rather a performance/planning application that leverages ADS-B 

IN data, if available (Section 4.3). 

3. Air Traffic Management (ATM) system status and forecast (e.g., sector use, sector 

configuration, Traffic Management Initiatives, Special Use Airspace, etc.) 

4. Weather information (current and forecast) 

5. Wind information (current and forecast) 
124

6. Airline Operational Communications (AOC) / Flight Operations Center (FOC) 

information, including operator flight planning, preferences, objectives. 

TASAR is described in detail in the following documents currently under development by 

NASA and NASA contractors; Concept of Operations [1][2], and TAP Application 

Description [3]. An Operational Hazard Assessment of the TASAR intended function has 

been conducted [7]. Based on the above description of TASAR and its intended function, 

the TASAR Operational Hazard Assessment indicates that TASAR may be implemented 

with a “No Effects” FEC, with a worst case “Minor” FEC. With this level of safety 

requirement and the nature of TASAR application processing being well aligned with a 

Type B EFB software application, it is expected that certification and operational approval 

should be commensurate with prior EFB application approvals of similar type. 

Note: After meeting with FAA, TASAR will be designated as “Minor Effect” due to 

potential pilot workload associated with TASAR due to misleading / bad data 

(Section 4.3). 

3) FARs 

Section 7 provides a high-level Compliance Check List to the applicable Federal Aviation 

Regulations (FARs) and associated regulatory and guidance documents from FAA for 

TASAR. No exemptions, equivalent levels of safety, or special conditions are anticipated 

for TASAR (to be verified). 

4) Compliance 

Compliance is expected to be shown by providing results from analyses (e.g. the 

Operational Safety Assessment), tests (e.g. non-interference testing of installed EFB 

components), documented results from the 6-month validation period, any conformity 

inspection results for the EFB mount, and review and demonstration of EFB use 

questionnaires of the intended function. At this point, no new and unique methodologies 

are expected to be used for TASAR, as this is expected to be closely aligned with 

certification approval of Type B applications. 

Refer to the Schedule in 12) below for reference to some of these deliverables. 

5) Conformity 

Installation of the EFB mount, aircraft power, and antennas to broadband wireless systems 

are likely candidates for conformity. Some of these components may be developed by 3rd

party vendors and will require testing and inspection, whether as part of conformity, or 

TBD other Compliance requirements. 

6) Data

Refer to the Schedule in 12) below for reference to some of the data deliverables. 

7) Airplane Flight Manual (AFM) 

It is expected that a revision to the AFM or AFM supplement will be required for TASAR. 

This is TBD at this time. 

8) Type Certificate Data Sheet 

Indicate if this document is affected and how it will be revised. TBD. 
125

9) Proposed DER(s) 

A TBD Designated Engineering Representative is expected to be FAA designee for the 

both the hardware and software aspects of the TASAR system. 

10) Master Minimum Equipment List (MMEL) 

TASAR does not affect the MMEL. 

11) System Criticality 

An Operational Hazard Assessment of the TASAR intended function has been conducted 

[7]. Based on the above description of TASAR and its intended function, the TASAR 

Operational Hazard Assessment indicates that TASAR may be implemented with a “No 

Effects” FEC, with a worst case “Minor” FEC. With this level of safety requirement and 

the nature of TASAR application processing being well aligned with a Type B EFB 

software application, it is expected that certification and operational approval should be 

commensurate with prior EFB application approvals of similar type. Refer to [7] for 

specific details on operational hazards and failure effects of TASAR. 

Note: After meeting with FAA, TASAR will be designated as “Minor Effect” due to 

potential pilot workload associated with TASAR due to misleading / bad data 

(Section 4.3). 

12) Schedule

The PSCP schedule addresses the activities, milestones, and deliverables that guide the 

certification process from initial Type Certificate application by the applicant to the FAA 

until final certification approval is achieved. Several characteristics of the PSCP and 

associated process make it difficult to develop a detailed PSCP plan for TASAR at this 

time: 

• Engineering is an iterative process and thus requires multiple phases of effort 

• Few projects will traverse the time line from left to right 

• Planners work with limited information; as the project progresses, the plan should 

be kept flexible and revised as necessary 

It is at this point difficult to provide even a notional schedule for TASAR certification and 

operational approval. However, Figure C-1 (overall schedule view) and Figure C-2 

(implementation phase schedule view) presented in Section 6 provide a guidance of a 

general schedule with activities, milestones, and decision gates. 

The following is list of potential deliverables for TASAR: 

• Software documentation and demonstration 

Since software process and software development documentation do not require 

DO-178B for TASAR, documentation requirements are not excessive. A 

description of requirement based on the topics listed in Section 5.4 should be 

included. In addition, demonstration or proof of 1) how TASAR does not adversely 

affect other applications that may be integrated in the same EFB, and 2) how 

software revision downloads ensure that operation of the application is not 

adversely affected. 
126

• Drawings and specifications of “installed” components of the TASAR EFB (e.g., 

aircraft mount, power connection, data connection, antennas, etc.). Whether 

conformity inspections are required is TBD. 

• Airworthiness tests and results, e.g., electrical load testing of TASAR components 

with aircraft power sources, non-interference testing with avionics systems, etc. 

• Data that describes the product design for COTS and installed components. 

Electrical and mechanical performance data. Installation specifications. 

• Need for any special inspections (unlikely to be required for TASAR) 

• Any issues papers (none expected for TASAR at this time (TBD). 

The schedule must account for the various meetings that need to be conducted, including 

the Type Certification Board Meeting (TCBM) (not sure how many TCBMs may be 

required for TASAR due to the relatively small size of EFB certification projects), 

coordination meetings between the FAA and applicant engineers and other participants 

should be identified. Dates for tests and required participants for observing the test need to 

be scheduled. 

More specific information may be gained via an initial Informational and / or PreCertification Meeting with FAA representatives. Such a meeting(s) would include 1) a 

presentation of the high-level TASAR concept to FAA, 2) a joint dialog about the concept 

with some initial observations and notable points that may impact a future TASAR 

certification project, 3) guidance from FAA on expectation of a notional certification 

project for TASAR, and 4) input from FAA on documentation, tests (ground-based, flight 

test, etc.) and steps to be followed as part of a future certification project and subsequent 

approval.
127

C.3 Compliance Check List 

This section represents a high-level Compliance Check List supporting the PSCP for TASAR. 

C.3.1 Cornerstone EFB Documents 

The following represent the primary, higher-level documents supporting the certification basis of 

TASAR. Numerous additional documents representing the FARs, regulation, and guidance 

documents apply to provide the detailed EFB approval requirement. These lower-level but 

important requirements will be provided in a future report that documents the results of a “Dry 

Run” review with Designated Engineering Representatives (DER) of TASAR-related PSCP 

information. 

1) Title 14 of the Code of Federal Regulations (14 CFR) parts 21, 23, 25, 27, 29, 43, 91F, 

91K, 121, 125, and 135 [29] 

2) Flight Standards Information System (FSIMS) – 8900.1 Change 47, Vol. 4, Chapter 15 – 

EFB Operational Authorization Process [14] 

3) AC 120-76C, Guidelines for the Certification, Airworthiness, and Operational Approval of 

Electronic Flight Bag Computing Devices [13] 

4) AC 20-173, Installation of Electronic Flight Bag Components [16] 

5) FAA Order 8110.4C, Type Certification [27] 

6) AC 21-16F, RTCA Document DO-160 “Environmental Conditions and Test Procedures 

for Airborne Equipment” [17] 

7) AC 20-115, RTCA DO-178B, Software Considerations in Airborne Systems and 

Equipment Certification [20]. 

C.3.2 Compliance Check List – High-level Items 

The following certification and operational approval compliance requirements for EFBs and 

associated software applications, with focus toward TASAR, are derived from FAA Order 8900.1 

Change 47, Vol. 4, Chapter 15 – “EFB Operational Authorization Process” [14]. This document 

represents the FAA Principal Investigators guidance for such approvals. In addition to these highlevel requirements to achieve certification and operational approval for TASAR, there are 

numerous additional regulatory documents that provide specific details to these requirements. 

These more fine-grained requirements will be addressed in a future document of the DER “Dry 

Run” review of the TASAR certification process noted above. 

Note: The following references in the next section, e.g. “4-1643” refer to specific portions of 

EFB Operational Authorization Process document of FAA Order 8900.1 Change 47 [14]. 

C.3.2.1 4-1643: EFB Hardware Classes 

B. Class 2 EFB (i.e., TASAR) 

• Typically mounted to the aircraft by a mounting device, may be connected to a data 

source, a hardwired power source, or an installed antenna 

o All these apply to TASAR 

• Represents a portable PED/EFB 
128

o Must be located on the flight deck and controlled by the flight crew during all 

flight operations 

 For TASAR, primarily used for en route, late stage of climb, early stage 

of descent 

o Must be accessible to the flight crew at all times and must be removable by a 

crew member without the use of tools

o Attached to the aircraft via a mounting device 

 Cockpit mount is likely choice for TASAR (yoke-mount should be 

avoided as this becomes a much more complex approval) 

o Components of the Class 2 EFB include all the hardware and software needed 

to support EFB intended functions (of TASAR) 

 Portable EFBs are limited to hosting Type A and Type B software 

applications or TSO functions limited to “Minor” FEC 

• Airport Moving Map Display with own ship position is an 

exception to this as a “Major” application – can only be used for 

ground operations below 40 kts. 

o EFB may consist of modular components (e.g., computer processing unit, 

display, controls) 

 Any EFB hardware not located on the flight deck and not accessible by 

the flight crew must be a certified installation via TC, amended TC, or 

STC. 

 Any EFB hardware not accessible on the flight deck by the flight crew 

and/or not portable must be installed and certificated equipment covered 

by a TC, amended TC, or STC. 

• The one exception to being accessible on the flight deck is a 

remotely mounted antenna that provides signal reception to the 

EFB. 

• The AID falls into this category of being installed and requiring 

type certification. 

C.3.2.2 4-1644: Hardware Specifications - Class 2 EFBs 

2. Major Class 2 EFB components (motherboards, processors, RM, video cards, hard drives, 

power supplies and connections) must be configuration controlled 

o Any changes will require reevaluation to demonstrate intended function still met 

 Non-interference, reliability requirements still met 

o For sealed components use manufacturer model / part number 

A. Display considerations 

(likely TASAR requirements, TBD for input devices listed below) 

o Must meet Legibility requirements 

o Must meet Brightness requirements 

o Viewing Angle 

(see AC 120-76C, paragraph 10b(3) for important issues concerning viewing angle) 
129

o Stylus. For a stylus screen, there must be an easily accessible stowage position for 

the stylus and an accessible spare stylus (or substitute stylus) must be available. 

o Digitizer Pen. When a digitizer pen is used to operate the EFB, the digitizer pen 

must have an easily accessible stowage position and be tethered. A spare digitizer 

must be immediately available and adjusted for use on each EFB. 

o Touch Screen. If a touch screen is used, it must be evaluated for ease of operation. 

The touch screen must be responsive and not require multiple attempts to make a 

selection, but not be so sensitive that erroneous selections occur. 

B. Rapid Decompression (RD) Testing 

C. Electromagnetic Interference/Non-Interference Testing 

o Also for TASAR as a Transmitting PED (T-PED) 

D. Antennas airworthiness requirements 

E. Power Sources airworthiness requirements 

(TASAR likely to use aircraft power, but not a firm requirement) 

o Battery primary

o Battery maintenance

o Aircraft secondary power

o Aircraft primary power

F. Data Connectivity (Class 2 Only) airworthiness requirements 

(required for TASAR) 

G. Data Loading/Database Changes airworthiness requirements (TBD for TASAR) 

o Class 1 or 2 EFBs must have a reliable means for revising the EFB databases

 Database currency is determined by what required aeronautical information 

the EFB is replacing

 Each method of data revision must ensure integrity of the data being loaded 

and not negatively impact the reliability of EFB operation

 Procedures must exist to protect the EFB from corruption, especially when 

internet and/or wireless means are used

 Database revision does not include application software or operating system 

changes

 Application software and/or operating system program changes must be 

controlled and tested prior to use in flight

 Database and/or application software changes may not be performed during 

operations (taxi, takeoff, in-flight, landing).

Note: External drives for data loading are considered ancillary EFB 

equipment and not subject to specific requirements beyond those 

identified for data loading/database revision above.

H. Mounting Devices (Class 2 Only) airworthiness requirement 

(likely required for TASAR) 
130

o The EFB, when attached to its appropriately designed mounting device, must be 

evaluated to ensure operational suitability in all ground and flight operations and 

conditions (airborne use for TASAR)

 When attached to its mounting device, the EFB must not interfere with flight 

crew duties and must be easily and safely stowed when not in use

 The attached EFB must not obstruct flight crew primary and secondary 

fields of view (See AC 120-76C)

 The attached EFB must not impede safe egress. (See AC 120-76C)

C.3.2.3 4-1645: EFB Software Specification 

Figure 4-77, Flowchart for Determining Electronic Flight Bag Software Application Type, is 

provided to aid in the determination of the EFB software application type.

B. Type B. Type B applications are applications that are intended for use during critical 

phases of flight or have software and/or algorithms that must be tested for accuracy and 

reliability. AC 120-76C, Appendix 2 may be referred to for examples of Type B 

applications. 

TASAR is viewed to be a Type B application.. 

C. Type C. These software applications are RTCA DO-178B, Software Considerations in 

Airborne Systems and Equipment Certification, compliant and require Aircraft 

Certification design approval. (NA for TASAR). 

C.3.2.4 4-1646: Operational Suitability Requirements 

Entry into aircraft records is required to add or remove installed elements (also for TASAR) 

The user/operator is responsible for ensuring that a Class 1 or Class 2 EFB, along with Type 

A and B applications, will reliably perform its intended function while not interfering with 

other aircraft equipment or operations. (Required for TASAR) 

A. Application Documentation. The user/operator must present application 

documentation to the POI demonstrating that the EFB meets its intended function. 

The attached flowcharts illustrated in Figure 4-75 and Figure 4-77 [14] will assist the 

user/operator with the identification and documentation of EFBs. 

Determining the operational suitability of a particular EFB is the responsibility of the 

user/operator and may be subject to specific guidelines from the applicable AEG 

reports.

A. When an operator has completed the evaluation of a Class 1 or 2 EFB, the 

operator must submit an application requesting authorization to use the EFB 

The POI will review the application submitted by the operator and authorize/not 

authorize the use of the EFB based on the findings of the POI Review Checklist 

3, illustrated in Figure 4-78, POI Review Checklist [14]. 

2) When a new aircraft model is added to an existing EFB authorization, the 

suitability of the EFB for that aircraft must be addressed as part of aircraft 

conformity using this evaluation process. When a new EFB is added to an 

existing EFB authorization, the suitability of the new EFB must be addressed 

using this same evaluation process. 
131

B. Operational Evaluation of Class 1 or 2 Hardware/Type A or B Software. The 

user/operator must evaluate the EFB for suitability of intended functions in each 

aircraft model. (TASAR requires avionics to support its intended function; depends on 

aircraft equipage) 

The user/operator must use the checklist as illustrated in Figure 4-79 [14], Checklist 1, 

Tabletop Electronic Flight Bag Evaluation, to evaluate the operational suitability of the 

proposed EFB intended functions and aircraft model suitability. The intended functions 

of software applications must be appropriate to the individual aircraft make and model. 

(TASAR suitability). 

The user/operator should use the checklist shown in Figure 4-80, Checklist 2 Electronic 

Flight Bag Operational Evaluation, to develop a flight scenario for final EFB testing 

when initial EFB use is being evaluated 

Operators requesting initial EFB authorization must include their POI in the 

flight/simulator evaluation of an initial EFB implementation. 

Operational evaluations for subsequent additions of EFBs or aircraft models need not 

conduct flight/simulator evaluations provided intended functions remain substantively 

the same as previously evaluated EFBs. 

C.3.2.5 4-1647: EFB Procedures. 

(Required for TASAR) 

The operator’s operations and maintenance procedures must be specific to each EFB and the 

operations conducted. 

The operator’s manual must identify each model of EFB authorized and each model of aircraft. 

A. EFB Configuration Control. (Required for TASAR) 

Standard EFB configuration control must be established and base-lined (i.e., initial 

hardware and software version at time of application) along with procedures to ensure 

that the EFB configuration control is maintained during system updates/revisions. 

Class 1 or 2 EFB configuration affects usability and battery life through setup of 

suspend/sleep modes. 

All classes of EFBs must have established standard operating procedures (SOP) to 

ensure reliable use of hardware and software. 

Procedures must be established for EFB database revision. This should include 

verification of continued intended function prior to use in flight operations following 

an EFB database revision. 

Note: Software updates, especially in the EFB operating system, must have 

extensive test procedures prior to use in flight operations. 

Software revision procedures must be comprehensive to ensure continued 

reliability of the EFB and verification of reliable intended function. 

B. Normal and Abnormal Operating Procedures. (Required for TASAR)

1) Normal procedures for flight operations must be developed for all flight operations 

with EFBs. 

Preflight must address battery charging, EFB database revision and data currency, 

EFB configuration control, and SOP for EFB setup. 
132

In-flight procedures must include standard application operating procedures and 

EFB standard flight operating procedures for use. 

2) Abnormal procedures must be established to address likely EFB function failures. 

Procedures for single and dual EFB failure must be established. 

3) Class 1 or Class 2 EFB operating procedures and limitations must be established if 

the EFB being used has not demonstrated Rapid Decompression (RD) testing while 

on and operating. (See subparagraph 4-1644B above) 

4) Checklists must be established or revised to include normal and abnormal EFB 

procedures to be used by pilots in flight. This may be accomplished by amending 

checklists when approved operator-customized cockpit checklists are used or by 

creating an EFB checklist supplement when aircraft manufacturer cockpit 

checklists are used. 

C. Minimum Equipment List (MEL). 

(NA for TASAR; TASAR does not affect the MMEL) 

D. Maintenance. Regular maintenance procedures are required for Class 1 and 2 EFBs, 

including measures to ensure the continued readability of the viewing screen. EFB 

battery maintenance needs to be addressed to ensure battery life, change intervals, and 

safety. TBD if TASAR has any instructions for continued airworthiness (ICA).

E. Risk Mitigation. Procedures must be established for a transition to paperless 

authorization. Initial procedures establish an independent backup during the EFB 

validation period. Procedures must be established for continuous reporting of problems 

with EFBs. There must be procedures in place for the user/operator to review these 

reports periodically to mitigate potential unreliability issues and correct operating 

procedures where necessary. Procedures must be established to notify flight crews of 

EFB problems or use issues. (For more information on risk mitigation, refer to Volume 

10, Chapter 1.) 

F. Training. The operator must develop EFB training for all personnel involved with EFB 

use, database servicing, and maintenance. EFB training must comply with training 

identified in AC 120-76C and be FAA-approved where applicable. 

Note: Training was noted as a requirement for approval of TASAR during the meeting 

with FAA. NASA noted that TASAR likely would require approximately 30 

minutes of training based on its relative complexity compared to other similar 

applications, e.g., the In-Trail Procedure application, which requires 30 minutes of 

training. FAA did not openly object with that estimate for training for TASAR (i.e., 

it is probably in the ball park of what is appropriate). 

C.3.2.6 4-1648: Airworthiness Requirements 

This paragraph outlines the airworthiness and return to service (RTS) requirements for 

installed components or provisions of Class 1 or Class 2 EFBs. These airworthiness 

requirements are applicable to all installed provisions capable of supporting EFB 

functions at flight crew stations, regardless of any other stated intended function. 

The installer remains responsible to ensure that all certification and airworthiness 

requirements are met for each installation. For provisional installations, each installer 

remains responsible for compliance with EFB airworthiness requirements, and each 
133

operator is responsible for EFB operational use requirements of the installed provisions 

capability. All Class 3 EFB installations require certification under TC, amended TC, or 

STC prior to installation. 

Note: Per FAA feedback, for Class 2 EFBs, the only certification requirements would 

be for mounting / installation of the EFB, getting one-way, read-only access to 

certified systems data (e.g., via ARINC 429 busses), and partitioning and 

protections for non-interference with certified systems. The AID is intended to 

accomplish much of this. FAA did not see the need for a PSCP for the TASAR 

software, just for the installation. If they already have an existing installation, 

then the operational approval process is for a user to go directly to their POI. 

A. EFB Power Source.

2) Class 2 EFB Power Source. 

(TASAR requirement is TBD) 

This is aircraft power used as the primary EFB power supply and requires the power 

supply to be hardwired or connected with certified connectors to ensure reliability. 

This is an EFB that continuously depends on connection to aircraft power to 

perform its intended function (no sustaining battery power) 

The aircraft power for Class 2 EFB power supplies must be designed to remain 

available at an acceptable level for required flight information, in the event of 

aircraft electrical malfunctions. 

Class 2 EFB power supplies require design approval by AIR under TC, amended 

TC, or STC, thus not eligible for field approval. 

B. EFB Data Connectivity. (TASAR requirement) 

This read-only data is provided to an EFB from the aircraft’s systems (e.g., flight 

management system (FMS), Global Positioning System (GPS), air data, fuel system) 

through a certified ARINC 429, RS-232, RS-485, or other compatible interfaces or 

certified router. 

EFB data connectivity does not include raw antenna reception data from an installed 

antenna going directly to the EFB. EFB data connectivity must include isolation to 

preclude the EFB from interfering with any aircraft system, and all associated wiring 

must be protected from damage and secured. EFB data connectivity requires design 

approval. Such design approval must be accomplished under TC, amended TC, or STC 

by AIR and excludes the installation from eligibility for field approval. 

Note: Data converters (e.g., ARINC 429 to RS-232) that are capable of 

supporting EFB functions at flight crew stations must have design 

approval issued by the FAA. 

C. EFB Mounting Devices. 

(For TASAR, avoid yoke mount as this is a flight-critical installation.) 
134

2) Cockpit-mounted EFBs are Class 2 EFBs mounted in the cockpit other than on the 

control yoke. The EFB mounting device requires airworthiness approval by AIR. 

FAA policy excludes this installation from eligibility for field approval. 

D. Installed Antennas. (TBD for TASAR) 

Installed antennas are those antennas permanently installed in the aircraft. Portable 

antennas attached to a portable EFB, but not attached to the aircraft, are not subject to 

these airworthiness requirements. Portable antennas and temporary antenna holders, 

like suction cups, are subject to EFB evaluation requirements only. Installation of 

antennas capable of supporting EFB functions at flight crew stations must be 

accomplished using existing guidance for antenna airworthiness considerations. 

1) Antennas combining reception for both aircraft navigation and EFB must be TSOapproved for this intended function, providing isolation to preclude the EFB from 

interfering with antenna reception for aircraft navigation. 

2) TSO- or STC-approved antennas may be used to independently provide GPS and/or 

satellite weather for an EFB in accordance with existing installation airworthiness 

requirements. 

3) Portable EFB-only antennas without a TSO may be used to provide a GPS or 

satellite weather signal for EFB-only use. Non-interference testing by the installer 

is required. 

E. Installed Satellite Receivers (e.g., Weather Radar (WX), XM Weather, WSI 

Inflight). (TBD for TASAR) 

If any component of a weather receiver is installed in an aircraft separate from a 

portable EFB on the flight deck, it is subject to avionics installation requirements and 

may not be considered a PED. If the result of the received weather data is capable of 

being displayed on an EFB, the individual components of the weather receiver system 

cannot be installed as STC provisions only because the installation cannot meet 14 CFR 

part 43 requirements for testing of non-interference without performing its intended 

function. (See the current edition of FAA Order 8110.4, Type Certification, for more 

information on this subject.) The weather receiver must be non-interference tested with 

the intended EFB installed and operative even though the installation only applies to 

the weather receiver. The airworthiness for the weather receiver installation is 

independent of EFB/PED suitability responsibility of the user/operator. The 

user/operator is responsible for EFB non-interference as a PED and the installer is 

responsible for non-interference for the weather receiver as part of installation 

requirements. This installation requires design approval under TC, amended TC, or 

STC, which excludes the installation from eligibility for field approval. 

C.3.2.7 4-1649: Authorization Process. 

The operator is responsible to ensure that all operational requirements are met for an 

EFB. The operator must submit documentation demonstrating compliance with all 

operational requirements for EFBs to their POI. The FAA evaluation process for an EFB 

follows the general process for approval and acceptance as described in Volume 3, 

Chapter 1. 
135

A. Phase One - Initiation. Phase one of the process begins when the operator requests 

authorization to use the EFB from the FAA. During this phase, the FAA and the 

operator reach a common understanding of the role of the FAA and what documents 

and actions the operator is responsible for during each phase of the authorization 

process.

B. Phase Two - Required Application Information. Phase two begins when the operator 

submits a formal EFB plan to the POI for evaluation. The plan is reviewed for 

completeness, and the POI facilitates coordination with other inspectors and FAA 

offices, as necessary. During phase two, the POI may coordinate with the appropriate 

AEG for guidance on EFBs that have functions not addressed in this guidance. Once 

the plan is accepted, the operator follows that plan to produce a complete EFB program. 

The operator must submit the following information in the application package: 

• EFB hardware and application specification (Figure 4-76) and Evaluation Report 

Information Template (Figure 4-81) [14] 

• EFB operator procedures/manual revisions 

• EFB cockpit procedures checklists 

• EFB training program 

• EFB evaluation report (Figure 4-79 and Figure 4-80) [14] 

• Rapid Decompression test data (when required) 

• Completed non-interference test results 

• Airworthiness documents for Class 2 equipment 

(mounting device, aircraft data connection, aircraft power primary, remote 

antenna).

C. Phase Three — POI Review. The POI must use the checklist found in Figure 4-

78 [14] to conduct a review of the application submitted by an operator. All POI 

specialties should coordinate the review of an operator’s EFB program. 

The POI should participate in the simulator evaluation or flight evaluation (TBD for 

TASAR) of an EFB when a user/operator is requesting initial EFB authorization. 

Additional simulator/flight evaluations are not required for adding a new EFB to an 

existing authorization unless there is a substantial change in EFB intended functions. 

When a new aircraft is added to a certificate with existing EFB authorization, the 

suitability of the EFB for that aircraft must be addressed as part of aircraft conformity 

and configuration control process. 

Inspectors should examine the technical content and quality of the proposed EFB 

program and other supporting documents and procedures. The user’s/operator’s 

program for EFB management is critical to EFB reliability (TBD for TASAR) and must 

be well documented for EFB users. 
136

D. Phase Four - Temporary Authorization to Use an EFB. 

An interim EFB authorization is granted to allow the certificate 

holder/operator/program manager to proceed with the required EFB 6-month 

operational validation testing. 

Note: The 6-month validation test formally begins when the certificate 

holder/operator/program manager is issued this A061 temporary 

authorization. Use Figure 4-82, Checklist 4 - Electronic Flight Bag Line 

Evaluation Job Aid [14], for data collection during the validation phase. 

Validation testing should follow the guidelines in AC 120-76C. 

1) Unacceptable Validation Results. If the POI finds the proposed EFB reliability 

and/or function to be unacceptable by the conditions of this EFB guidance, then the 

POI should contact the operator for corrective action. EFB deficiencies must be 

corrected and the EFB function revalidated before proceeding to Phase Five. 

2) Acceptable Validation Results. If at the completion of the EFB 6-month 

validation test, the POI finds the proposed EFB reliability and/or function to be 

acceptable based on validation data, then the certificate holder/operator/program 

manager can proceed to phase five of the EFB A061 authorization process. 

E. Phase Five—Authorization to Use an EFB. The certificate holder/operator/program

manager subject to regulations under 14 CFR parts 91K, 121, 125 (including 125 Letter 

of Deviation Authority (LODA) holders (125)), and 135 is granted authorization to use 

an EFB through OpSpec/MSpec/LOA A061 after acceptable completion of validation 

testing in phase four. The POI will remove the “temporary authorization” annotated in 

the restrictions and limitations column of Table 1. Any subsequent change to EFB 

hardware or intended functions must be validated at a level appropriate to the effect of 

the change on the EFB program. 

C.3.2.8 POI Checklists for EFB Evaluations 

The following is a compressed version of the comprehensive questionnaires utilized by the FAA 

POI in reviewing the applicant’s EFB implementation and operational use. 

Note: Refer to Tables 4-79 through 4-82 in [14] for the detailed list of questions. 

Successful completion and acceptance to the responses to these questionnaires are an integral part 

of gaining approval of the TASAR EFB application. 

1. Checklist 1 Tabletop Electronic Flight Bag Evaluation (Figure 4-79 in [14])

Checklist 1 contains a list of questions for operators to use during a tabletop evaluation of the EFB 

focusing on the EFB hardware and software applications. The checklist includes the following 

subtopics:

• EFB Hardware 

• General User Interface 

• General Software Applications 

• Electronic Documents (If Applicable) 

• Electronic Charts (If Applicable) 

• Electronic Checklists (ECL) (If Applicable) 
137

• Performance Calculations (If Applicable) 

After the operator has completed this checklist, the results should be documented so the POI can 

review the results with the operator. 

2. Checklist 2—Electronic Flight Bag Operational Evaluation (Figure 4-80 in [14])

Checklist 2 contains a list of questions for operator consideration during an operational evaluation 

of the EFB, its documentation, procedures, and training. The first four pages contain questions that 

can be answered in a training or operational environment by pilots, instructor/evaluators, or other 

operational personnel. The last page contains sample crew performance questions that can be 

addressed in a simulation environment. 

After the operator has completed this checklist, the POI will review the results with the operator. 

• General EFB Hardware 

• Stowage (If Applicable) 

• Unsecured EFB (If Applicable) 

• General User Interface 

• Software Applications

• EFB Procedures 

• Procedures for Keeping EFB Content/Data Current 

• Procedures for User Feedback 

• Procedures for Specific Applications (If Applicable) 

• EFB Training 

• Training for Charts (If Applicable) 

• Training for ECL Systems (If Applicable) 

• Training for Flight Performance Calculations (If Applicable). (NA for TASAR) 

• Crew Performance: Preflight Planning 

• Crew Performance: Takeoff 

• Crew Performance: Cruise 

• Crew Performance: Descent 

• Crew Performance: Approach/Landing 

• Crew Performance: Destination Ground Operations 

3. Checklist 3— Evaluation Report Information Template (Figure 4-81 in [14])

This outline is used by the user/operator to ensure that the minimum content requirements of the 

evaluation report have been met. The format of the report is optional. However the information in 

the detailed questions must be included, as a minimum. 

4. Checklist 4— EFB Line Evaluation Job Aid (Figure 4-82 in [14])

This checklist is used for data collection during validation period. 

• Describe system configuration description and flight conditions 

• Overview questions concerning the main aspects to be assessed in validation period 

• General.

• Electronic Charts, Documents, and Checklists. (NA for TASAR) 

• Flight Performance Data/Calculations (NA for TASAR). 
138

• General Conclusions. 

The following approval signature and entry items are completed after reviewing the four 

checklists. Refer to [14] for details on these checklists. 

Assigned Aircraft: ___________Date: ______Print Observer Name:____________________ 

Observer Signature: _____________________Certificate Number: _____________________ 
139

Appendix D DER “Dry Run” Review and Artifacts Details 

D.1 DO-178B Objectives Artifacts Requirements for Level D 

This appendix provides a summary of the 28 objectives that must be satisfied for the DO-178B 

Level D software design assurance level for the various software development process steps. While 

TASAR does not required DO-178B to be applied for software approval, consideration should be 

given whether some elements of TASAR software should be developed to DAL Level D for 

possible future reuse in the event TASAR is upgraded and requires a more formal process. 

1) Software planning related – 2 objectives 

a. Software development and integral processes activities are defined 

b. Additional considerations are addressed 

2) Software development process related – 7 objectives 

a. High-level requirements are developed 

b. Derived high-level requirements are derived 

c. Software architecture is developed 

d. Low-level requirements are developed 

e. Derived low-level requirements are defined 

f. Source code is developed 

g. Executable object code is produced and integrated in the target computer 

3) Verification of outputs of software requirements process – 3 objectives 

a. Software high-level requirements comply with system requirements 

b. High-level requirements are accurate and consistent 

c. High-level requirements are traceable to system requirements 

4) Verification of outputs of software design process – 1 objective 

a. Software partitioning integrity is confirmed 

5) Verification of outputs of software coding and integration processes – 0 objectives 

6) Testing of outputs of integration process – 3 objectives 

a. Executable object code complies with high-level requirements 

b. Executable object code is robust with high-level requirements 

c. Executable object code is compatible with target computer 

7) Verification of verification process results – 1 objective 

a. Test coverage of high-level requirements is achieved 

8) Software configuration management process – 6 objectives 

a. Configuration items are identified 

b. Baselines and traceability are established 

c. Problem reporting, change control, change review, and configuration status 

accounting are established 

d. Archive, retrieval, and release are established 
140

e. Software load control is established 

f. Software life cycle environment control is established 

9) Software Quality Assurance Process – 2 objectives 

a. Assurance is obtained that software development and integral processes comply 

with approved software plans and standards (with independence) 

b. Software conformity review is conducted (with independence) 

10) Certification Liaison Process – 3 objectives 

a. Communication and understanding between the applicant and certification 

authority is established 

b. The means of compliance is proposed and agreement with the Plan for Software 

Aspects of Certification is obtained 

c. Compliance substantiation is provided. 

As indicated, the above 28 objectives i.e., required activities to be performed, in item (8) above 

(with two objectives having independence requirements, i.e., where a second individual reviews 

the work of the person who created the original artifact) represent the Level D design assurance 

level as part of the software development process required by RTCA DO-178B. Table D-1 

provides a summary of all levels of DO-178B in terms of the number of objectives and the extent 

of independence required. As is expected, the higher the design assurance level (Level A being the 

highest), the more intensive and rigorous will be the software development process. 

Note: While it is desirable to have the lowest design assurance level possible while meeting the 

safety requirements, the designer needs to consider what portions of the software 

development may need to be repeated at a future time at a higher design assurance level. 

In some cases, the designer may choose to develop portions of the software system to a 

more stringent design assurance level, allowing future reuse of such code. In the case of 

TASAR, it is not expected that DO-178B needs to be used in the software development 

process, and thus has a considerably reduced level of formal steps in its development. This 

would expedite the development and reduce the overall cost of the system. In the event 

TASAR functionality is upgraded in future applications, it is possible that a higher design 

assurance level may arise, requiring a redevelopment of the software to the higher-level of 

design assurance using the DO-178B objectives. 

Table D-1 Summary of DO-178B Objectives Required per Design Assurance Level 

Level Failure condition Objectives With independence

A Catastrophic 66 25 

B Hazardous 65 14 

C Major 57 2 

D Minor 28 2 
141

D.2 Tabletop EFB Evaluation (Detailed Check List #1) 

Note 1: The following represents the detailed checklist utilized by the POI as part of the EFB 

Application approval process for the “Tabletop EFB Evaluation”. The list is taken from 

Figure 4-79 in FAA Order 8900.1 Volume 4 “Aircraft Equipment and Operational 

Authorizations” [14]. 

Note 2: While this document provides information concerning the certification and documentation approval process for TASAR, it does not on its own address and achieve the actual 

certification and operational approval. Some observations are offered to assist this future 

process in looking through the list of questions provided in the Appendix. 

Tabletop Electronic Flight Bag Evaluation – Checklist 1 (Figure 4-79) [14] 

1. If the EFB is to be used outside of the flight deck, can the EFB display be read under direct 

sunlight?  No _ Yes

While intended for cockpit use, it is conceivable that the pilot could access TASAR preflight to program and select the operational goals and objectives of how they want TASAR 

to support the upcoming flight. EFB use outside of the cockpit is not required but may be 

desirable for some users. 

 

2. Is the display brightness and contrast adjustable?  No _ Yes

3. Is the display brightness acceptable when it adjusts automatically?  No _ Yes

4. Are there any display artifacts such as jagged lines that impair functionality? _ No  Yes

NA  

5. Are controls labeled appropriately to describe their intended function?  No _ Yes

6. Are buttons and labels visible and readable under all flight deck illumination conditions?  No _ Yes

7. Can EFB inputs be made quickly and accurately in any operational environment?  No _ Yes

8. Does the input device provide sufficient tactile feedback in all environmental conditions?  No _ Yes

9. Are inadvertent or multiple activation of controls minimized?  No _ Yes

10. Does the EFB start up in a predictable state?  No _ Yes

11. Can the EFB be rebooted when power is cut to the EFB?  No  Yes

TBD. Should be able to be rebooted. 

12. Does the EFB function correctly when rebooted?  No _ Yes

13. Are all the EFB failure modes easy to see and identify?  No _ Yes

14. Is the failure annunciation/message appropriate for the EFB function that has failed?  No _ Yes

15. Are EFB recovery means easy to remember and apply when the EFB fails?  No _ Yes

Provide the Number and a Comment for Each EFB Hardware Question Checked as “No.”

See above for each answer

General User Interface 

16. Is the revision information and currency expiration date available and presented clearly?  No _ Yes
142

17. Does the device respond immediately to user inputs?  No _ Yes

18. Is the processing speed always appropriate for normal use?  No _ Yes

19. Are appropriate busy or progress indicators displayed when processing is delayed?  No _ Yes

20. Is the user interface, including functions and navigation, consistent throughout the EFB?  No _ Yes

21. Is all information that is needed displayed and easily accessible? Is there missing or 

difficult to find information?  No _ Yes

User interface provides access to all information relevant to TASAR with easy access.  

22. Are common actions and time-critical functions easy to access?  No _ Yes

23. Are there standard ways to perform common actions?  No _ Yes

24. Are the displays and controls used on the EFB similar across applications? Are a common 

set of controls and graphical elements used?  No  Yes

The answer should be yes. At this point this project has addressed TASAR as a standalone 

application and has not examined how it may be integrated with other EFB applications. A 

windows-like operation between applications is possible or some equivalent means may be 

considered. Future actions required to address this question more specifically. 

25. Can all colors be distinguished under the various lighting conditions?  No _ Yes

26. Is color coding implemented with a secondary code such as shading or highlighting when 

used to display critical information?  No  Yes

TBD. TASAR on its own does not involve critical information.  

27. Are the colors red and yellow used appropriately only for warnings and cautions?  No  Yes

TBD. TASAR on its own does not require warning and cautions colors.  

28. Is the text easily readable?  No _ Yes

29. Do the characters stand out against the display background?  No _ Yes

30. Are upper case and italic text used infrequently?  No _ Yes

Actually this is TBD as part of the detailed design but the answer should be Yes.  

31. Is text that may be used in low-visibility conditions appropriate in size and easy to read?  No _ Yes

32. Is it easy to zoom in on text or graphics when they are too small?  No _ Yes

33. Is it obvious when information is out of view and can it easily be brought into view?  No _Yes

May be NA for TASAR - TBD  

34. Is the spacing between characters appropriate?  No _ Yes

35. Is the vertical spacing between lines appropriate?  No _ Yes

36. Are icons and symbols legible?  No _Yes

37. Are icon and symbol functions obvious?  No _ Yes

38. Are the icons and symbols distinguishable from one another?  No _ Yes
143

39. Is each icon’s meaning explained by a label or other means?  No _ Yes

40. Are the EFB icons and symbols consistent with their paper equivalents?  No  Yes

TASAR is not a paper replacement application – NA.  

41. Do EFB alerts and reminders meet the requirements in the appropriate regulations as noted 

in the current edition of FAA Advisory Circular (AC) 120-76, Guidelines for the Certification, 

Airworthiness, and Operational Approval of Electronic Flight Bag Computing Devices, 

paragraph 10 (i.e., The Human Factors Considerations for EFBs)?

 No  Yes

TASAR is not expected to require alerts and reminders. In the event a requirement for this 

arises it needs to be documented and meet the applicable requirement – NA or TBD.  

42. Are alerts and reminders consistent across all applications?  No  Yes

TBD – see answers to24 and 41.  

43. Are alerts and reminders implemented so as not to distract?  No  Yes

Should be if it becomes an issue. See answers to 24 and 41.  

44. Is there control over when, and whether, the audio or video is activated?  No  Yes

TBD for TASAR. Answer should be yes if applicable.  

45. Is it easy to reset parameters to their default when they have been customized?  No _ Yes

46. Is EFB customization controlled through an administrative control process?  No _ Yes

Provide the Number and a Comment for Each General User Interface Question Checked as “No.”

See above for each answer ____________________________________________________________________

General Software Applications 

47. Can required information be found quickly and accurately within all applications?  No _ Yes

48. Is the information within applications organized consistently?  No _ Yes

49. Is information layout consistent with the paper equivalent?  No  Yes

Paper replacement for TASAR is NA  

50. Is the layout of information appropriate for all applications?  No _ Yes

51. Is high priority information easy to read?  No _ Yes

52. Is it easy to tell which application is currently open/active?  No _ Yes

53 Is it easy to switch between applications?  No _ Yes

54. Is extra acknowledgement required to open applications that are not flight related?  No _Yes

55. Do all open applications function as intended on an individual basis?  No _ Yes

56. Is access or links to related information appropriately supported?  No _ Yes

57. Are similar types of information accessed in the same way?  No _ Yes

58. Is it easy to return to the place where the user started from?  No _Yes

59. Is printing supported, and if so, is the hard copy usable?  No  Yes
144

NA for TASAR  

60. Can a portion of a document be selected to be printed?  No  Yes

NA for TASAR  

61. Can a print job be terminated immediately?  No  Yes

NA for TASAR  

Provide the Number and a Comment for Each General Software Applications Question Checked as “No.”

See above for each answer. Many answers assume multiple applications to coexist and thus provide anticipated use.

Electronic Documents (If Applicable) 

62. Is it easy to tell where one is in relation to the full document?  No  Yes

63. Is it easy to move between documents quickly?  No  Yes

64. Is it easy to tell what document is currently in view?  No  Yes

65. Is there a list of available documents to choose from?  No  Yes

66. Is the document search function appropriate?  No  Yes

67. Are tables, especially complex ones, readable and usable?  No  Yes

68. Are figures readable and usable?  No  Yes

Electronic Charts (If Applicable) 

69. Is there a way to pre-select specific charts for easy access during a particular flight?  No  Yes

70. Is there more than one way to search for a chart?  No  Yes

71. Is it easy to access charts when a last minute change is necessary?  No  Yes

72. If the chart application uses aircraft location to facilitate access to charts, is this function 

appropriate (i.e., either approved by Aircraft Certification or explicitly allowed by AC 120-

76)?

 No  Yes

73. Is it easy to switch between a decluttered and normal display if decluttering is supported?  No  Yes

74. Is there a clear indication when any chart elements are suppressed?  No  Yes

Provide the Number and a Comment for Each Electronic Documents and Charts Question Checked as “No.”

Questions 62 thru 74 are NA for TASAR (not paper nor chart replacement)______________________________

Electronic Checklists (ECL) (If Applicable) 

75. Are normal checklists available in the appropriate order of use?  No  Yes

76. Can checklists be accessed individually for review or reference?  No  Yes

77. During non-normal conditions, are relevant checklists easy to access?  No  Yes

78. During non-normal conditions, does the device indicate which checklists and/or checklist 

items are required and which are optional?  No  Yes

79. Is it clear where to find all checklists, whether on the EFB or on paper?  No  Yes

80. Is the location of a paper document provided when it is referred to by the ECL?  No  Yes
145

81. Does each checklist have a constantly visible title distinct from other checklists?  No  Yes

82. Is it easy to select a checklist from a set of open checklists?  No  Yes

83. Is there a reminder to review incomplete items when closing an incomplete checklist?  No  Yes

84. Can an incomplete checklist be closed after acknowledging it is not complete?  No  Yes

85. Does the ECL discourage two or more checklists from being used simultaneously?  No  Yes

86. Is progress through the ECL clear?  No  Yes

87. It is easy to reset the ECL to start over again?  No  Yes

88. Does the checklist provide appropriate reminders for tasks that require a delayed action?  No  Yes

89. Does the checklist clearly highlight decision branches?  No  Yes

90. Can you return to the checklist from links or related information in one step?  No  Yes

91. Is there an indicator of which item in the checklist you are working on?  No  Yes

92. Is the checklist’s active item clearly indicated?  No  Yes

93. Can the status of an item be easily changed?  No  Yes

94. Does the next item automatically become active when the previous one is complete?  No  Yes

95. Can the current item be deferred without completing it?  No  Yes

96. Is it easy to view other items, even in a long checklist, without changing the active item?  No  Yes

97. Is it easy to move between items within a checklist?  No  Yes

98. Does the active item change to the next after an item is completed?  No  Yes

99. Is there a clear indication that all items as well as the whole checklist are complete when 

finished?  No  Yes

Provide the Number and a Comment for Each ECL Question Checked as “No.”

Questions 75 thru 99 are NA for TASAR (not paper nor chart replacement)______________________________

Performance Calculations (If Applicable) 

100. Does the device identify entries that have an incorrect format or type and does it generate 

an appropriate error message?  No _ Yes

101. Does the error message clarify the type and range of data expected?  No _ Yes

102. Are units for performance data clearly labeled?  No _ Yes

103. Do the labels used in the EFB match the language of other operator documents?  No _ Yes

104. Is all the information necessary for a given task presented together or easily accessible?  No _ Yes

105. Can the crews modify performance calculations easily, especially when making last 

minute changes?  No _ Yes

106. Are outdated results of performance calculations deleted when modifications are 

entered?

 No _ Yes
146

107. Does the display and/or crew training provide information to the crew on the 

assumptions on which the calculations are based?  No _ Yes

108. Are crews trained to identify and review default values and assumptions about the 

aircraft status or environmental conditions?  No _Yes

109. Are the assumptions made about any calculation as clear to pilots as similar information 

would be on a tabular chart?  No _ Yes

Provide the Number and a Comment for Each Performance Calculations Question Checked as “No.”

Note: The answers to the question in the above section are made in the spirit that while TASAR is not a 

Performance Calculation applications, the questions are analogous to what may be required for the TASAR 

pilot decision

aid.______________________________________________________________________________

[14] Checklist 1 contains a list of questions for operators to use during a tabletop evaluation of the Electronic Flight 

Bag (EFB) focusing on the EFB hardware and software applications. The checklist starts with EFB hardware 

questions, then presents general user interface questions, and ends with specific application questions (if applicable). 

The checklist is designed so that any question answered as “No” requires a comment that may include, “Not 

Applicable.” – This approach is used in answering the questions below. After the operator has completed this 

checklist, the results should be documented so the POI can review the results with the operator. 
147

D.3 EFB Operational Evaluation (Detailed Check List #2) 

Note 1: The following represents the detailed checklist utilized by the POI as part of the EFB 

Application approval process for the “EFB Operational Evaluation.” The list is taken 

from Figure 4-80 in FAA Order 8900.1 Volume 4 “Aircraft Equipment and Operational 

Authorizations” [14]. 

Note 2: While this document provides information concerning the certification and documentation approval process for TASAR, it does not in on its own address and achieve the 

actual certification and operational approval. Some observations are offered to assist this 

future process in looking through the list of questions provided in the Appendix. 

Checklist 2—Electronic Flight Bag Operational Evaluation (Figure 4-80) [14] 

Checklist 2 contains a list of questions for operator consideration during an operational evaluation of the Electronic 

Flight Bag (EFB), its documentation, procedures, and training. The first four pages contain questions that can be 

answered in a training or operational environment by pilots, instructor/evaluators, or other operational personnel. The 

last page contains sample crew performance questions that can be addressed in a simulation environment. The 

checklist is designed such that any question answered as “No” requires a comment that in some cases may be “Not 

Applicable.” 

After the operator has completed this checklist, the POI will review the results with the operator. 

General EFB Hardware 

1. Is there a backup source in the flight deck for EFB information?  No  Yes

NA for TASAR  

2. Is the EFB display readable under all typical flight-deck lighting conditions?  No  Yes

3. Does each type of EFB failure have minimum impact to crew tasks and workload?  No  Yes

4. Is the EFB installation appropriate for use in high workload phases of flight?  No  Yes

Not expected to be an issue for TASAR. Primarily used en route and potentially during late 

portion of climb and early stage of descent, workload permitting.  

5. Are there appropriate Master Minimum Equipment List (MMEL)/minimum equipment list 

(MEL) items to handle EFB failures?  No  Yes

TASAR does not affect MMEL as it is optional and not required to support flight operations. 

6. Have EFB failure items been incorporated into FAA-approved checklists?  No _ Yes

Not expected to be an issue for TASAR. More of a training issue to ignore / turn off TASAR 

if it unnecessarily distracts the pilot.  

7. Does the EFB mount allow appropriate access to flight controls and displays?  No _ Yes

8. Does the EFB mount allow appropriate access to the emergency egress path?  No _ Yes

9. Are crews able to adjust and lock the EFB for optimal viewing?  No _ Yes

10. Is there appropriate access to all flight controls during both ground and in-flight operations 

when the EFB is positioned for optimal viewing?  No _ Yes

11. Is there appropriate room to manipulate the EFB controls and to view its display?  No _ Yes

12. Are all EFB hardware components that are routinely used easy to access?  No _ Yes
148

13. Are the EFB hardware components usable and suitably durable for the flight deck?  No _ Yes

Provide the Number and a Comment for Each General EFB Hardware Question Checked as “No.”

See above for each answer, which are the anticipated outcomes resulting from the operational evaluation. 

Whether this requires a flight test or if a ground test and demonstration is sufficient is TBD. It is anticipate that 

a ground test would be adequate pending FAA approvals.____________________________________________

Stowage (If Applicable) 

14. Is there a stowage area for the EFB?  No _ Yes

15. Is the stowage securing mechanism simple to operate?  No _ Yes

16. Is the stowage securing mechanism unobtrusive when not in use?  No _ Yes

17. Does the stowage system allow appropriate access to flight controls/displays and egress 

routes?

 No _ Yes

18. Is the design of the stowage area acceptable?  No _ Yes

19. Can the EFB be moved easily to and from the stowage area without blocking access to 

flight displays/controls?

 No _ Yes

20. Are the device and/or the stowage area unlikely to be damaged under normal use?  No _ Yes

Unsecured EFB (If Applicable) 

21. Is there appropriate access to flight controls/displays when the unsecured EFB is in use?  No _ Yes

22. Is there an acceptable place to put an unsecured EFB when in use?  No _ Yes

23. Is there an acceptable place to put an unsecured EFB when not in use?  No _ Yes

24. Can the kneeboard EFB be positioned such that the pilot has full control authority?  No _ Yes

25. Is the kneeboard EFB comfortable for the pilot to wear under normal conditions?  No _ Yes

Provide the Number and a Comment for Each Stowage and Unsecured EFB Question Checked as “No.”

See above for each answer. The answers to the above are conceptual in nature and are expected to reflect an 

appropriate implementation of TASAR. The exact nature of use mounted or unsecured are TBD at this time. Both 

should be acceptable. It is conjectured that due to the longer duration of en route operations, mounted use would 

be more desirable. 

_____________________________________________________________________________ 

General User Interface 

26. Is the workload using the EFB the same or less than the current process?  No _ Yes

TASAR represents a new capability and is expected to be easily managed per proper design. 

27. Is the workload acceptable when there is an EFB failure?  No _ Yes

In event EFB failure, TASAR operations are simply unavailable and terminated (unless a 

second EFB is available to choose to continue using TASAR. TASAR use is optional.  

28. Are other than critical EFB messages inhibited during high workload phases of flight?  No _ Yes

TASAR use is at the discretion of the pilot. There is not an expectation for excessive messages 

from TASAR, but in the unanticipated event for this to occur, they are either ignored by the 

pilot (per training) or disabled. 
149

29. Is the EFB user interface consistent with other flight deck systems?  No _ Yes

30. Does the EFB use terms, icons, colors and symbols consistent with other flight deck 

systems?  No _ Yes

Software Applications 

31. Is the workload acceptable when configuring electronic charts while flying a procedure?  No  Yes

NA for TASAR.  

32. Does using the electronic checklist (ECL) produce the same crew actions that using the 

paper equivalent would?  No  Yes

NA for TASAR  

Provide the Number and a Comment for Each User Interface and Application Question Checked as “No.”

See above for each answer. The answers to the above are conceptual in nature and are expected to reflect an 

appropriate implementation of TASAR ___________________________________________________________ 

EFB Procedures 

33. Are there procedures for starting up and shutting down the EFB?  No _ Yes

34. Are there appropriate procedures for all the EFB failure modes?  No _ Yes

35. Are there EFB procedures for when other aircraft system failures could render the EFB 

unusable?  No _ Yes

36. Are there procedures for using EFB backup information?  No  Yes

NA for TASAR as TASAR is optional.  

37. Are there procedures to mitigate EFB workload?  No _ Yes

TASAR is optional for use and via training, the pilot will disregard or disable TASAR if it 

affects workload in an adverse manner. 

38. Are there procedures for establishing which source of information is primary?  No _ Yes

TASAR information is used only for recommendations to the pilot and should not be used in 

lieu of other sources supporting flight operations.  

39. Are there appropriate procedures for using EFB in high workload phases of flight?  No _ Yes

TASAR is primarily intended for en route use or late part of climb segment and early stages 

of descent. If flight operations become high workload for any reasons, the pilot via training 

will cease to use TASAR until reduced workload allows pilot to choose to use TASAR again 

if desired. 

40. Are there procedures that specify what data to use when data is redundant or different 

form the EFB?  No _ Yes

TASAR information is used only for recommendations to the pilot and should not be used in 

lieu of other sources supporting flight operations.  

41. Are there procedures for removal of a kneeboard EFB during emergency landing or egress 

(If Applicable)?  No _ Yes

Provide the Number and a Comment for Each EFB Procedures Question Checked as “No.”
150

See above for each answer. The answers to the above are conceptual in nature and are expected to reflect an 

appropriate implementation of TASAR.___________________________________________________________

Procedures for Keeping EFB Content/Data Current 

42. Are there procedures to ensure data is accurate and current for each software application?  No _Yes

43. Are changes to content/data appropriately documented?  No _ Yes

44. Are there procedures to notify crews of EFB updates?  No _ Yes

45. Are there procedures to ensure that the correct information is installed when EFBs use 

information that is specific to the aircraft type or tail number?  No _ Yes

46. Are operational control procedures consistent with regulations concerning preventative 

maintenance?  No _Yes

TBD if applicable for TASAR. 

47. Is there a procedure to avoid corruption/errors during changes to the EFB device?  No _ Yes

48. Is there a procedure to ensure that all EFBs have the appropriate content/data installed 

when there are multiple EFBs on the flight deck?  No _ Yes

49. Is there a procedure to ensure that EFB data in use is approved for use in flight?  No _ Yes

50. Is there a procedure for when the database is not approved for use in flight?  No _ Yes

51. Is there a procedure to ensure that all customized values are cleared from the EFB?  No _Yes

Procedures for User Feedback 

52. Is there a procedure for EFB users to provide feedback?  No _ Yes

53. Is there a procedure for the operator to monitor feedback, correct EFB deficiencies, and/or 

notify the EFB manufacturer?

 No _ Yes

54. Are there procedures or built-in limits that prevent defining customized color schemes that 

conflict with flight deck color conventions?

 No _ Yes

55. Is there a policy regarding the use of supplemental audio and/or video in flight?  No  Yes

NA for TASAR as currently defined.  

56. Is the EFB audio set to minimize any interference with higher priority communications?  No  Yes

NA for TASAR as currently defined. 

Procedures for Specific Applications (If Applicable) 

57. Are there specific policy/procedures for using the electronic charts application?  No  Yes

NA for TASAR 

58. Does the policy specify what other EFB applications can be used while a procedure using 

the electronic charts is actively being flown?  No  Yes

NA for TASAR. However, with respect to TASAR, use of other applications is TBD but is 

considered feasible.  

59. Are there procedures on how to use the electronic charts when the EFB uses aircraft status 

data to configure chart elements?  No  Yes
151

NA for TASAR. 

60. Are there procedures to ensure that navigation/approach charts required for the flight are 

installed and available?  No  Yes

NA for TASAR.  

61. Is there a procedure to identify the controlling copy of Weight and Balance (W&B)?  No  Yes

NA for TASAR. 

62. Is there a procedure to establish responsibility for completion of W&B software?  No  Yes

NA for TASAR.  

63. Are there procedures to maintain required W&B records?  No  Yes

NA for TASAR. 

64. Is there a procedure to ensure that EFB performance data can be stored outside the EFB?  No  Yes

NA for TASAR.  

Provide the Number and a Comment for Each of the above EFB Procedure Question Checked as “No.”

See above for each answer. The answers to the above are conceptual in nature and are expected to reflect an 

appropriate implementation of TASAR. _________________________________________________________

EFB Training 

65. Are there appropriate EFB training, checking, and currency requirements?  No _ Yes

66. Does the EFB training program address all EFB intended functions and applications?  No _ Yes

67. Is there training on how to use unique features of the software applications?  No _Yes

68. Are crews proficient on the EFB at the completion of EFB training?  No _ Yes

69. Is EFB training customized for new users?  No _ Yes

70. Is the manufacturer’s EFB documentation sufficient?  No _ Yes

71. Does the EFB training device provide an appropriate degree of fidelity when the actual 

EFB is not used?  No _ Yes

It is envisioned that the TASAR EFB applications also serves as the EFB training device. 

72. Does the EFB training device simulate the key aspects of the task?  No _ Yes

73. Does the EFB training appropriately address the meaning of icons and symbols?  No _ Yes

To the extent applicable to the TASAR user interface – TBD. 

Training for Charts (If Applicable) 

74. Is training on the use of electronic charts appropriate?  No  Yes

NA for TASAR. 

75. Is there training on unique features of the electronic charts?  No  Yes

NA for TASAR.  
152

76. Is there training on differences in map scale, orientation, and data quality between the 

electronic charts and other flight deck displays?  No  Yes

NA for TASAR. 

77. Is there training on the limitations of own aircraft position when it is displayed?  No  Yes

NA for TASAR.  

78. Is there training on policies pertaining to use of the electronic charts?  No  Yes

NA for TASAR. 

79. Can crews use the electronic charts as well as paper charts?  No  Yes

NA for TASAR.  

80. Can crews use the electronic charts to orient themselves and track their progress as they 

fly required procedures?  No  Yes

NA for TASAR. 

Training for ECL Systems (If Applicable) 

81. Is there appropriate training on how to use ECLs?  No  Yes

NA for TASAR. 

82. Is there training on how to use unique features of the ECLs (e.g., how the EFB indicates 

that a checklist item has been deferred)?  No  Yes

NA for TASAR.  

83. Is there training on which checklists are supported electronically and which are not?  No  Yes

NA for TASAR. 

84. Is there training on the limitations of ECL automation when it uses aircraft status data?  No  Yes

NA for TASAR  

Training for Flight Performance Calculations (If Applicable). 

85. Is there appropriate training on how and when to use the flight performance application?  No  Yes

NA for TASAR. 

86. Is there training on critical performance calculation assumptions (e.g., runway length, 

W&B)?  No  Yes

NA for TASAR.  

87. Is there training to review default values for aircraft status and environmental conditions?  No  Yes

NA for TASAR. 

88. Is there training on how to enter information required by the performance software?  No  Yes

NA for TASAR.  

89. Is there training on how to interpret and use results of the flight performance calculations?  No  Yes
153

NA for TASAR. 

90. Is there training on where to obtain values when their normal sources are not available?  No  Yes

NA for TASAR.  

91. Is there training on coordinating the roles of dispatchers and flight crews?  No  Yes

NA for TASAR (from the perspective of flight performance calculation, which are not part of 

the TASAR concept. 

Provide the Number and a Comment for Each Training Question Checked as “No.”

See above for each answer. The answers to the above are conceptual in nature and are expected to reflect an 

appropriate implementation of TASAR. __________________________________________________________

Crew Performance: Preflight Planning 

Do crews with the EFB perform as well or better than crews with paper documents when—

92. Calculating aircraft W&B, takeoff, climb, and maneuvering speeds?  No  Yes

NA for TASAR. 

93. Crews maintain critical data for immediate reference?  No  Yes

NA for TASAR.  

94. There is a runway change and a need to reference deicing fluid requirements or an MEL 

item?  No  Yes

NA for TASAR. 

95. There are time critical adjustments prior to block out/taxi and takeoff?  No  Yes

NA for TASAR.  

Crew Performance: Takeoff 

Do crews with the EFB perform as well or better than crews with paper documents when—

96. There is a takeoff on a runway that requires briefing a special operator engine-out 

procedure?

 No  Yes

NA for TASAR. 

97. There is complex Standard Instrument Departure (SID) with an abnormal or an emergency 

during the departure climb-out?

 No  Yes

NA for TASAR.  

98. There is an emergency that requires a return to the departure or alternate departure airport?  No  Yes

NA for TASAR. 

99. One EFB fails, requiring one pilot to rely on the EFB of the other pilot immediately after 

takeoff?

 No  Yes

NA for TASAR.  

Provide the Number and a Comment for Each Preflight and Takeoff Question Checked as “No.”

The above questions are NA for TASAR___________________________________________________________
154

Crew Performance: Cruise 

Do crews with the EFB perform as well or better than crews with paper documents when—

100. There is an engine failure/fire with possible condition of destination below weather 

minimums?  No  Yes

NA for TASAR. 

101. There is electrical smoke in the cockpit requiring use of smoke mask/goggles while 

completing checklists or using EFB for approach briefing?  No  Yes

NA for TASAR.  

Crew Performance: Descent 

Do crews with the EFB perform as well or better than crews with paper documents when—

102. There are conditions that require reference to Surface Movement Guidance and Control 

System (SMGCS) taxi routing or a complex clearance?  No  Yes

NA for TASAR. 

103. Reported runway conditions require reference to operational limitations?  No  Yes

NA for TASAR.  

Crew Performance: Approach/Landing 

Do crews with the EFB perform as well or better than crews with paper documents when—

104. There is runway change or the need to re-compute landing weight and V speeds during 

approach?  No  Yes

NA for TASAR. 

105. There are poor weather conditions or airports with complex taxi routes?  No  Yes

NA for TASAR.  

106. There is a request for a specific taxiway turn during rollout after landing?  No  Yes

NA for TASAR. 

Crew Performance: Destination Ground Operations 

Do crews with the EFB perform as well or better than crews with paper documents when—

107. There is an EFB partial failure or erroneous output requiring maintenance discrepancy 

to be entered?  No  Yes

NA for TASAR. 

Provide the Number and a Comment for Each Crew Performance Question Checked as “No.”

The above questions are NA for TASAR ___________________________________________________________
155

D.4 EFB Report Information Template 

Note 1: The following represents the detailed template used by the user / operator and reviewed 

by the POI for the information captured as part of the Evaluation Report. The list is taken 

from Figure 4-81 in FAA Order 8900.1 Volume 4 “Aircraft Equipment and Operational 

Authorizations” [14]. 

Note 2: While this document provides information concerning the certification and documentation approval process for TASAR, it does not in on its own address and achieve the 

actual certification and operational approval. Some observations are offered to assist this 

future process in looking through the list of questions provided in the Appendix. 

Evaluation Report Information Template (Figure 4-81) [14] 

This outline is used by the user/operator to ensure that the minimum content requirements of the evaluation report 

have been met. The format of the report is optional, however the information below must have been included, as a 

minimum: 

1. Electronic Flight Bag (EFB) evaluation identified by EFB make/model and aircraft make/model. 

While any number of Portable PEDs/EFBs, along with associated Aircraft Interface Devices, may be used 

for TASAR to provide the required Class 2 (or higher) EFB functionality, one particular EFB is being 

used by the TASAR research team for flight testing. The Goodrich SmartDisplayTM EFB and ARINC 828 

Aircraft Interface Device is a representative EFB for TASAR. 

2. The manufacturer’s name and model number of the mounting system evaluated. 

TBD for TASAR. 

3. EFB location and stowage suitability. 

TBD for TASAR. 

4. EFB display lighting and reflectivity. 

TBD for TASAR. 

3. Suitability of procedures for EFB use during all phases of flight. 

Specific procedures for TASAR are TBD for this report. A pilot assessment of the use of the TASAR EFB 

application is part of other research currently being conducted by the TASAR team. 

4. Suitability of procedures to follow when one unit fails and when both units fail to include alternate means 

of accessing data. 

TASAR being optional, its use will cease in the event of failure of the EFBs. No procedures required to 

provide an alternate means or mitigation. 

5. A revision process procedure/method that ensures appropriate database accuracy and currency. 

TBD for TASAR. 

6. Training effectiveness and typical acceptable training course completion. 
156

TBD for TASAR. 

9. Usability of each application (for example): 

a. Electronic documents’ functional suitability; 

 NA for TASAR. 

b. Aircraft performance, Weight and Balance (W&B), and speeds reference functional suitability; and 

 NA for TASAR. 

c. Electronic charts’ functional suitability. 

 NA for TASAR. 

10. Usability of multiple applications at one time. 

 TBD for TASAR. 

11. Crew workload and currency for proficient use. 

 TBD for TASAR. 

5. Effectiveness of procedures that govern the distribution of application software updates to the aircraft and 

confirmation of the aircraft EFB configuration. 

 TBD for TASAR. 

6. Flight report—when and how reports of malfunctions or anomalies are reported and resolved. 

 TBD for TASAR. 
157

D.5 EFB Line Evaluation Job Aid (Detailed Check List #4) 

Note 1: The following represents the detailed checklist utilized by the POI as part of the EFB 

Application approval process for the “EFB Line Evaluation”. The list is taken from 

Figure 4-82 in FAA Order 8900.1 Volume 4 “Aircraft Equipment and Operational 

Authorizations” [14]. 

Note 2: While this document provides information concerning the certification and documentation approval process for TASAR, it does not in on its own address and achieve the 

actual certification and operational approval. Some observations are offered to assist this 

future process in looking through the list of questions provided in the Appendix. 

Checklist 4—Electronic Flight Bag Line Evaluation Job Aid (Figure 4-82) [14] 

USED FOR DATA COLLECTION DURING VALIDATION PERIOD 

This tool provides a starting point for Electronic Flight Bag (EFB) line operations evaluations. The questions are 

primarily designed to aid the POI but may also be useful to the operator for the collection of a structured set of 

observations about the use of the EFB before and during the 6-month validation phase. Use of this tool can be 

customized as appropriate for the situation. This is a final check to ensure that there are no problems with the EFB 

design/interface, training, or procedures prior to the authorization for use. 

The questions below encompass the operations and safety evaluation. In cases where a system shows weaknesses or 

limitations, mitigations must be developed in consultation with the applicant. 

In some cases, an EFB may add to the complexity of flight operations. The key questions to be answered are: 

1) Can the flight be conducted as safely with an EFB as with the methods/products it is intended to replace? 

2) Does the EFB add an unacceptable level of complexity for any critical activity or phase of flight? 

In order to answer these questions, it is helpful to consider more specific aspects of EFB usage, which are covered in 

Sections II through V below. Space is also provided in Section I to record general notes about the system and the 

evaluation.

I. Describe system configuration description and flight conditions: 

Details of the TASAR system configuration sought for certification and operational approval will be determined 

once an applicant initiates this process and makes the appropriate design decisions to support their intended use 

to achieve operational benefits. TASAR may be implemented in a number of ways; as a standalone EFB 

application or may be integrated and operate concurrently with other EFB applications, in either a single or 

dual EFB system. 

The TASAR team will be conducting flight trials of the TASAR EFB prototype using a Piaggio Aero P180 Avanti 

test aircraft (per Engility and its AdvAero partner on the NASA TASAR research team). 

Currently, flight operations and flight trials will consist of several scenarios, based on short-term flight segments 

that will evaluate the TASAR concept (i.e., the Traffic Aware Planner (TAP) application). Several scenarios 

have been identified in initial planning: 

• Data Scenarios: designed to ensure that the TAP engine is receiving the correct data from the aircraft. 

• Functionality Scenarios: designed to exercise the TAP engine through each of its modes and capabilities. 

• Pilot Interaction Scenarios: designed to have the test subject exercise each of TAPs capabilities to gather 

subjective operational feedback on the capability and user interface, as it pertains to the in-flight 

environment.

• ATC Interaction Scenarios: designed to have the test subject generate an optimization using TASAR, 

request the route change from ATC and, with the help of the safety pilot, execute the route change. 
158

As currently envisioned, the TASAR Flight Trials will involve 10 flights based at Newport News/Williamsburg 

International Airport (KPHF) near NASA Langley Research Center. Each flight will be planned to fly a route 

as if en route to a destination. This destination will change from flight to flight to optimize the traffic and/or 

weather conditions for the given day. Approximately mid-way through the flight, the aircraft will be re-routed 

back to KPHF. 

The Pilot Interaction and ATC Interaction scenarios will be executed on flights 3 - 10. One new test subject is 

planned for each flight. The test subject qualifications are to be a currently licensed IFR pilot with a valid 

medical, and to not have been involved in the TASAR project (for independence). 

During the approximately 120 minute period of each flight, the test subject will execute 11 scenarios, each 

exercising different TAP functionalities. The intention is to gather and demonstrate subjective feedback directly 

about each of the TAP functionalities. 

The final two scenarios involve generating a proposed route modification and coordinating it with ATC. One 

of these scenarios will involve a mock ATC operator in the cabin of the aircraft, and the second will involve a 

live ATC request, following through with execution of the request, if it is approved. Since it is not realistic for 

ATC to approve multiple requests for route changes through the course of a relatively short flight, the decision 

was made to hold off making any live ATC requests until after the other scenarios are complete, and following 

through if approved. 

While the test subject is performing the 11 scenarios, flight test engineers in the cabin of the aircraft will be 

performing functionality scenarios. These scenarios will put TAP through its paces using the scenarios being 

flown by the test subject. The intent here is to test TAP in various real-world operational scenarios, piggybacking on the flight scenario being executed by the test subject. This piggy-backing will be on a noninterference basis. 

Results such as those obtained from the described flight trials are expected to allow any necessary refinements 

to TASAR, but can also serve as flight evaluation results that could be offered to FAA in a future certification 

and operational approval process. 

Note: In addition to the flight trials noted above, additional research is planned to be conducted to evaluate pilot 

performance in a flight-deck simulator to assess and evaluate pilot performance in using the TASAR humanmachine interface (to be conducted in the University of Iowa Operator Performance Laboratory {OPL}). In 

addition, NASA Langley is planning to perform part-task simulations of TASAR to further evaluate pilot 

workload and the effectiveness of TASAR.

II. Overview. The main aspects to be assessed are encompassed by the following questions: 

1. Was training adequate to ensure that the pilot(s) could perform in a safe and efficient 

manner?

• Were individual pilot knowledge and skills adequate to allow normal coordinated flight 

deck activities?

• Was pilot knowledge regarding observed software applications adequate?

No Yes

2. Are adequate procedures in place to ensure that the EFB is integrated into the 

crew’s/operator’s system (e.g., normal and abnormal/emergency operations and 

maintenance functions)?

No Yes

3. Was the EFB hardware or software adequate and appropriate during the flight? If there 

were any problems, particularly in a critical phase of flight, describe in the notes space 

below.

No Yes

4. Could the pilot(s) recover from usage errors without undue distraction or discussions? If 

usage errors were frequent or a distraction, describe in notes below. No Yes

5. Was the workload required for completing a task with the EFB equal to or less than the 

workload for completing the task with the conventional method? If no, specify phase of No Yes
159

flight and task for any marginal or unacceptable increases in workload in notes space 

below.

Describe any problems noted as “No” above: 

TBD for TASAR based on planned flight trials and associated evaluations of pilot performance. 

III. General. 

6. Was each pilot able to use the cursor, track ball, touch screen, etc., for menu and 

functionality without frequent errors? No Yes

7. Was the device appropriate and operational when exposed to environmental factors (e.g., 

turbulence, cold weather, vibration)? No Yes

8. Was the device free of significant limitations in regard to display (e.g., off-axis view 

angles or various different lighting conditions)?

• The device had easy and adequate dimming functions in low light (nighttime) 

conditions?

• The device was adequately backlit and/or was viewable by flight deck lighting in lowlight (nighttime) conditions?

• The device was clearly visible in bright sunlight conditions?

No Yes

9. Was the device display clear (adequate resolution)? Confirm that the display was never 

misinterpreted because of viewing limitations. If so, record issues in notes space below. No Yes

10. Did the pilot(s) ensure proper stowage and security (i.e., between flights, etc.) of the EFB 

per standard operating procedures (SOP)? Temperature limitations acknowledged? No Yes

11. Does the display continue to be usable after prolonged use in the flight deck environment 

(if applicable)? No Yes

12. Normal functions (e.g., shutdown, startup) are adequate and do not require undue pilot 

attention or concern? No Yes

13. Were procedures adequate for identifying currency of EFB data? No Yes

14. Could the pilot(s) easily find and use required items and functions? No Yes

15. Were the abbreviations and/or icons easy to understand? No Yes

16. If multiple applications are supported, could the pilot(s) easily switch between critical 

applications? No Yes

17. If critical (e.g., abnormal or emergency checklists) applications are authorized in the EFB 

configuration basis, is their use at least equal to or better than previously approved 

methods?

No Yes

 N/A

18. The time to complete normal tasks was appropriate. No Yes
160

19. The audio features did not cause pilot distraction and/or were adjustable and appropriate 

for the flight deck environment. No Yes

 N/A

Describe any problems noted as “No” above: 

TBD for TASAR based on planned flight trials and associated evaluations of pilot performance.

IV. Electronic Charts, Documents, and Checklists. 

20. Were all necessary documents (including charts, checklists, and manuals) found, 

identified, and easily viewed by the pilot(s) without undue distraction? No Yes

21. Was information contained in electronic charts, documents, and checklists complete, 

equal in quality to previously provided products, and easily accessible and 

understandable?

No Yes

22. Was pilot knowledge of chart/document/checklist selection and viewing adequate? No Yes

23. Could the pilot(s) easily rearrange content on the screen to meet needs (e.g., by zooming, 

panning, or otherwise customizing the view)? No Yes

24. If printers are used, are printouts acceptable? No Yes 

25. Did the pilot(s) exhibit adequate knowledge of EFB functions to efficiently brief and fly 

required procedures? No Yes

26. Did the pilot(s) exhibit adequate knowledge of the software revision process 

procedure/method that ensures appropriate database accuracy and currency? No Yes

27. Did the pilot(s) exhibit adequate knowledge of contingency procedures? 

In the event of a failure of a single device. 

In the event that both devices fail.

No Yes

28. Were both pilots able to monitor necessary electronic chart displays during critical 

phases of flight? No Yes

29. Did the EFB allow quick entry of updates for last minute changes (e.g., flight 

plan/runway changes)? No Yes

30. For electronic checklists (ECL), was it easy to track completed items? No Yes

 N/A

Describe any problems noted as “No” above: 

TBD for TASAR based on planned flight trials and associated evaluations of pilot performance.

V. Flight Performance Data/Calculations. 

31. Could the pilot(s) interpret and use flight performance data/calculations efficiently and 

accurately? No Yes

 N/A
161

32. Did the device allow quick entry of updates for last minute changes (e.g., flight 

plan/runway changes)? No Yes

 N/A

33. In the event that the Weight and Balance (W&B) and/or performance calculation 

software is not approved by the Aircraft Certification Office (ACO), all crewmembers 

are aware of the software’s limitations and understand that only approved calculation 

methods may be used as a primary means of computation.

No Yes

 N/A

Describe any problems noted as “No” above: 

 NA for TASAR. 

VI. General Conclusions. 

34. Were any unique safety issues or events caused or exacerbated by using the EFB during 

this evaluation? No Yes

 TBD for TASAR pending flight evaluation or ground demonstration as agreed to 

between applicant and FAA per Certification Plan. 

35. Can the flight be conducted as safely with an EFB as with the methods/products it is 

intended to replace? No Yes

 TBD for TASAR pending flight evaluation or ground demonstration as agreed to 

between applicant and FAA per Certification Plan. 

36. Does the EFB add an unacceptable level of complexity for any critical activity or phase 

of flight? No Yes

 TBD for TASAR pending flight evaluation or ground demonstration as agreed to 

between applicant and FAA per Certification Plan. 

Assigned Aircraft: ___________Date: ______Print Observer Name:____________________ 

Observer Signature: _____________________Certificate Number: _____________________ 
162

Appendix E FAA Technical Interchange Meeting Details 

This appendix provides details of the technical interchange discussions between the FAA team of 

EFB and ADS-B certification and operational approval experts and NASA TASAR research 

representatives (i.e., David Wing, the NASA TASAR Principal Investigator, and Steve Koczo, 

Rockwell Collins Principal Investigator supporting NASA in the TASAR certification and 

operational approval analyses). 

David Wing of the NASA Langley Research Center, Crew Systems and Avionics Operations 

Branch, and Steve Koczo of Rockwell Collins Advanced Technology Center traveled to 

Washington DC on July 24, 2013, to brief NASA’s TASAR concept and technology to FAA 

officials responsible for policy setting, certification, and operational approval of EFB (Electronic 

Flight Bag equipment, EFB software, and ADS-B (Automatic Dependent Surveillance-Broadcast) 

IN applications. The seven FAA officials described themselves as being “all the right people” for 

assessing the TASAR application from the perspectives of certification and operational approval. 

NASA TASAR concept for “Traffic Compatible Flight Optimization” received favorable FAA 

review. The outcome of the meeting was very successful, with widespread agreement of NASA’s 

and Rockwell Collins’ briefing materials and results from analyses, indicating TASAR has 

minimal certification and operational approval requirements. 

The FAA host for the meeting with the NASA TASAR team, and one of the key approvers of EFB 

applications from a flight standards and operational approval perspective, provided the following 

post-meeting exchange: “I want to thank you both for the presentation yesterday on TASAR. 

Overall, I believe the meeting was very productive. If you have any questions in the future, please 

do not hesitate to contact us. Also, if there's any confusion, when displaying this technology to 

stakeholders, on whether or not this is an EFB function, please let me know. I want to ensure that 

these performance calculations are considered EFB software applications. Thanks again for your 

great presentation.” 

As a major conclusion to the meeting, it was noted that existing policies already cover the proposed 

application, and an applicant (e.g. an airline) should have no difficulty getting approval to 

implement TASAR from their standpoint. This finding supports NASA’s objectives of developing 

a near-term, low-cost application for in-flight optimization of trajectories using ADS-B IN traffic 

data to increase the likelihood of approval. The application enables airspace users to gain early 

benefits of ADS-B IN at minimal investment risk, while also paving the way for the emergence of 

more advanced airborne surveillance applications with even greater operational benefits. 

The following represents major points and discussion results from the technical interchange: 

1. TASAR meets the definition of a Type B application and does not need to be added 

explicitly to the list of Type B applications in Appendix 2 of AC 120-76C [13]. Type B 

applications running on non-certified hardware (e.g., Class 2 EFB) do not require DO178B compliance. 

The FAA clearly considers TASAR a Type B software application (“performance 

applications”). They understood and agreed with the “Type B Lite” description although 

no such qualification is needed. It is not a problem that TASAR is not listed in AC 120-

76C Appendix 2 (Type B applications), and it does not need to be added. 
163

2. It was solidly agreed that TASAR is not considered an “ADS-B IN application” but rather 

a performance / planning application that leverages ADS-B IN data, if available. 

A key element in FAA’s view is that traffic is not displayed. AC 120-76B will soon have 

“Change 1” allowing own ship to be displayed on Type B applications on the airport 

surface only. 

3. No need was identified to establish a TASAR standard. 

Such a standard would have ensured that different avionics vendors would produce 

compatible TASAR systems, but they saw no benefit in this. 

4. TASAR should be viewed as a “Minor Effect” application because of potential pilot 

workload associated with TASAR due to misleading/bad data. From a loss of function 

standpoint, TASAR is viewed as “No Effect.” 

5. If an end user already has an existing EFB installation, then the operational approval 

process is for the user to go directly to the POI to demonstrate that TASAR is safe 

(including the workload issues) and provide a training program. 

David Wing offered a training estimate of 15 minutes for TASAR (using the In-Trail 

Procedure {ITP} of 30 minutes as a reference), which did not raise any objections. 

6. Existing policies already cover the proposed TASAR application. 

The following represents additional feedback, discussion points, and observations from the active 

discussions among all participants: 

• It was confirmed that TASAR software would not require DO-178B compliance. In fact, 

no certification of the TASAR software is required at all provided it resides on noncertified hardware (e.g. Class 2 EFB). 

• The only certification requirements would be mounting/installation of the EFB, getting 

one-way, read-only access to the certified systems data (e.g., via ARINC 429 busses), and 

partitioning and protections for non-interference with certified systems. The AID is 

intended to accomplish much of this partitioning/protection. 

It was noted that even a one-way, receive (read)-only connection could short an ARINC 

429 bus, but this can be managed. An applicant must show isolation and non-interference 

between the EFB and certified systems. 

• FAA did not see the need for a PSCP for the TASAR software, just for the installation. If 

they already have an existing installation, then the operational approval process is for a 

user to go directly to their POI. It may be worth talking to a POI about TASAR to better 

understand this process. 

The FAA host noted that our technical interchange meeting was in essence a “trial run” for 

how to conduct a meeting with all FAA involved (indicating that we had the right group 

together).

• The whole idea of a “Class 3” EFB is going away. It will be considered an installed 

“Auxiliary Display”. 

For TASAR software installed on such a system, the software would be considered “Minor 

Effect” but would require DO-178B conformance (i.e., Design Assurance Level “D”). 
164

Asked whether new software is required or whether existing TASAR software (R&D code) 

could be certified, FAA indicated that existing code could still be used depending on how 

it was designed, developed and documented (i.e., the implication being that software was 

designed with DO-178B design objectives being considered up front). 

• FAA recommends using existing guidance for designing cockpit applications, e.g. human 

factors guidelines, and related to quality requirements of data. 

• If the EFB is to be shared by TASAR and other applications, human factors issues may 

need to be addressed regarding transferring back and forth, particularly if certified 

applications are involved. 

• The FAA certification authority on traffic surveillance asked whether TASAR would use 

TIS-B and TCAS traffic, and inquired on requirements for data content and accuracy. 

TIS-B has notoriously bad velocity data, and TCAS has none. Both also have limited range 

(TIS-B in particular). However a receiver can distinguish between and filter for only ADSB data if desired. He recommended that we determine whether either of these systems 

would meet the performance requirements of TASAR. 

Somewhat related questions were raised on whether ground-based sources of traffic data 

(e.g. commercial sources) actually exist that could work, i.e. support TASAR. 

• It was recommended we talk with WSI about access to weather products. 

• The only other application using ADS-B IN data besides TASAR that does not employ a 

CDTI is TSAA (Traffic Situation Awareness with Alerts) which uses audio cueing rather 

than visual cueing. 

• FAA had no concern with TASAR’s map display on the “selected optimization” screen. 

Their only comment on the display was a preference to avoid use of yellow or amber if 

possible, as these are generally reserved for higher levels of hazard. 

• Benefit numbers from the NASA TASAR benefits study were viewed as very significant. 

FAA asked where the big hitter benefits arise from; we noted that wind route, weather 

(pop-up and when it dissipates) were key factors 

• It was suggested that TASAR could function in the General Aviation market without 

avionics connectivity (TBD). 

Potential areas of concerns and additional discussion items were noted for further consideration: 

• Some concerns were raised regarding whether TASAR solutions would be at odds with 

arrival flow planning and routing, particularly for Operational Evolution Plan (OEP) 

airports (i.e., largest 35 US airports) 

Destinations other than OEP airports were not viewed to be a problem. An open question 

is how TASAR would know the arrival constraints for a particular airport, e.g., an OEP 

airport.

• FAA Flight Standards representative for traffic surveillance – could this (TASAR) lead to 

too many change requests to ATC? 

• FAA representative - what about future Trajectory Based Operations (TBO), i.e., point-topoint locations at specific times, will TASAR and TBO clash? 
165

• Discussion about Top of Descent (TOD) and inward (i.e., approaching the terminal area), 

with future greater use of Optimum Profile Descent (OPD), Required Time of Arrival 

(RTA) at metering fix, FAA noted that TASAR may work for smaller airports but what 

about East Coast corridor? David Wing noted that this is where use of constrained 

waypoint(s) would be in order for TASAR; also RTA 

• FAA made reference to the National Route Program (NRP), and that it is typically 

discouraged to deviate from the NRP (implication being how does this affect TASAR use) 

• FAA comment – “not one size fits all” with respect to airspace operations, users, and 

implication of TASAR use 

• FAA asked about “throttle jockeying”, whether TASAR is reading the actual fuel flow in 

making route optimization decisions (we answered we did not think so, but were not fully 

sure; this would be a question to be directed to Engility in their algorithm design) 

• It was asked if we had talked to Air Traffic Controllers. We responded we had not. 

• FAA representative responsible for EFB certification made the following comments - 

TASAR application is almost like a workstation; airlines will want to automate it, i.e., more 

data link, auto download to FMS 

o He also noted that the Air Traffic Organization should also consider a TASAR like 

tool for ATC, i.e., meaning looking/factoring in data like weather, traffic, etc., in 

making route suggestions 

o Made a comment about “making the gray line more solid”, with respect to EFB 

regulatory policy and guidance 

o He also commented about bringing additional on-board displays into the cockpit 

(implication that this is an unwanted proliferation, e.g., pilots bringing PEDs onboard {perhaps multiple} for additional apps – suggesting some sort of integration 

of displays needs to occur to halt proliferation) 

Should not be second display – do not want to keep bringing on additional displays 

• The FAA host noted that POI is authorized to approve the EFB mount (which is not 

certified); while AID, which is certified, must follow AC 20-173 

• 2,200 OpsSpecs are already in existence, which can be leveraged for future approval if they 

are equivalent to any new intended applications. The references to these OpsSpecs are for 

iOS and android type EFB applications 

• AC 120-76B Change 1 will be out before end of calendar year 2013, will allow own ship 

on surface as a Type B application. Currently in signature cycle 

• FAA noted that EASA (FAA’s certification counterpart in Europe) looks at EFBs as 

portable vs. installed; blackening the line seeking to remove ambiguity. 

David Wing provided a brief demo of TASAR on the mobile prototype system that he brought to 

the meeting. The demonstration provided an excellent view of the TASAR application and its 

intended use and was very well received. 
166

Acronyms 

AC Advisory Circular 

ACARS Aircraft Communications Addressing and Reporting System 

ACO Aircraft Certification Office 

ADS-B Automatic Dependent Surveillance – Broadcast 

ADS-R Automatic Dependent Surveillance - Rebroadcast 

AE Abnormal Event 

AEG Aircraft Evaluation Group 

AFM Airplane Flight Manual 

AFS FAA Flight Standards Service 

AIAA American Institute of Aeronautics 

AID Aircraft Interface Device 

AIR FAA Aircraft Certification Service 

ALT Altitude 

AMMD Airport Moving Map Display 

AOC Airline Operational Communications 

AOSP Airspace Operations and Safety Program 

ARMD Aeronautics Research Mission Directorate 

ARP Aerospace Recommended Practice 

ASA Aircraft Surveillance Applications 

ASAS Aircraft Surveillance Applications System 

ASOR Allocation of Safety Objectives and (Safety) Requirements 

ASP Airspace Systems Program 

ASTC Amended Supplemental Type Certificate 

ATC Air Traffic Control 

BC Basic Cause 

CCFP Collective Forecast Product 

CDTI Cockpit Display of Traffic Information 

CFR Code of Federal Regulations 

COTS Commercial of the Shelf 

CP Certification Plan 

CPDLC Controller Pilot Data Link Communication 
167

CPI Certification Process Improvement 

CPP Certification Project Plan 

CR Contractor Report 

CTD Concept and Technology Development 

DAL Design Assurance Level 

DAR Designated Airworthiness Representative 

DCE Data Concentrator Emulator 

DER Designated Engineering Representative 

DMIR Designated Manufacturing Inspection Representative 

EASA European Aviation Safety Agency 

ECL Electronic Checklist 

ECON FMS Economy Setting 

EFB Electronic Flight Bag 

EMI Electro-Magnetic Interference 

EUROCAE European Organization for Civil Aviation Equipment 

EUROCONTROL European Organization for Civil Safety of Air Navigation 

EWINS Enhanced Weather Information System 

FAA Federal Aviation Administration 

FANS Future Air Navigation System 

FAR Federal Aviation Regulation 

FCC Flight Control Computer 

FEC Failure Effects Classification 

FMC Flight Management Computer 

FMEA Failure Mode and Effects Analysis 

FMS Flight Management System 

FOC Flight Operations Center 

FSIMS Flight Standards Information System 

GAMA General Aviation Manufacturers Association 

GPS Global Positioning System 

HIRF High Intensity Radiated Fields 

HITL Human-in-the-Loop 

HMI Human Machine Interface 

ICA Instruction for Continued Airworthiness 
168

IEEE Institute of Electrical and Electronic Engineers 

IFR Instrument Flight Rules 

ITP In-Trail Procedure 

LED Light Emitting Diode 

LOA Letter of Authorization 

LODA Letter of Deviation Authority 

LVC Live Virtual Constructive 

MACS Multi-Aircraft Control System 

MCP Mode Control Panel 

MEL Minimum Equipment List 

MIDOS Manufacturing Inspection District Offices 

MMEL Master Minimum Equipment List 

MSpec Management Specification 

NASA National Aeronautics and Space Administration 

NOTAM Notice to Airmen 

NRA NASA Research Announcement 

NRP National Route Program 

NWS National Weather Service 

ODA Organizational Designation Authorization 

OE Operational Effect 

OEP Operational Evolution Plan 

OH Operational Hazard 

OHA Operational Hazard Assessment 

OPD Optimum Profile Descent 

OPL Operator Performance Laboratory 

OS Operating System 

OSA Operational Safety Assessment 

OSED Operational Service and Environment Definition 

OSR Operational Suitability Report 

PC Production Certificate 

PED Portable Electronic Device 

PIREP Pilot Reports 

PMA Parts Manufacturer Approval 
169

POI Principal Operations Inspector 

PSCP Project Specific Certification Plan 

PSP Partnership to Safety Plan 

RD Rapid Decompression 

RF Radio Frequency 

RTA Required Time of Arrival 

RTCA Radio Technical Commission for Aeronautics 

RTS Return to Service 

RVR Runway Visual Range 

SAE Society of Automotive Engineers 

SC Severity Class 

SID Standard Instrument Departure 

SMGCS Surface Movement Guidance and Control System 

SMS Safety Management System 

SO Safety Objective 

SOP Standard Operating Procedures 

SPD Speed 

SPR Safety Performance (and Interoperability) Requirements 

ST Safety Target 

STAP Single Text Avionics Protocol 

STC Supplemental Type Certificate 

STI Scientific and Technical Information 

SUA Special Use Airspace 

SW Software 

T-PED Transmitting Portable Electronic Device 

TAP Traffic Aware Planner 

TASAR Traffic Aware Strategic Aircrew Requests 

TAWS Terrain Awareness and Warning System 

TBO Trajectory Based Operations 

TC Type Certificate 

TCAS Traffic Alert Collision Avoidance System 

TCBM Type Certification Board Meeting 

TFM Traffic Flow Management 
170

TFR Temporary Flight Restriction 

TIA Type Inspection Authorization 

TIS Traffic Information Service 

TIS-B Traffic Information Service – Broadcast 

TOD Top of Descent 

TSAA Traffic Situation Awareness with Alerts 

TSO Technical Standard Order 

TSOA Technical Standard Order Authorization 

UAT Universal Access Transceiver 

UM Unit Member 

W&B Weight and Balance 

WPT Waypoint 

Wx Weather 

WxR (Airborne) Weather Radar 

XM Satellite Data Link Service Provider 
171

References 

[0] Burke, K., Cover, M., Engler, J., Koczo, S., Reuter, C., Schnell, T.,Wing, D., “TASAR EFB 

Application and HMI Simulation Evaluation for Operational Approval”, Summary Report, 

Contract #NNL12AA11C Task 2, NASA Contractor Report – In Publication, 2015. 

[1] Ballin, M., Wing, D., “Traffic-Aware Strategic Aircrew Requests (TASAR)”, AIAA-2012-

5623.

[2] Henderson, J., “Traffic aware strategic aircrew requests (TASAR) concept of operations”, 

NASA Contractor Report, NASA-CR-218001.

[3] Woods, S., Vivona, R., Roscoe, D., LeFebvre, B., Wing, D., Ballin, M., “A Cockpit-based 

Application for Traffic Aware Trajectory Optimization”, AIAA-2013-4967. 

[4] Wing, D., Ballin, M., Koczo, S., Vivona, R., “Developing an On-Board Traffic Aware Flight 

Optimization Capability for Near-Term Low-Cost Implementation”, AIAA-2013-4231. 

[5] Henderson, J., Idris, H., and Wing, D., “Preliminary Benefits Assessment of Traffic Aware 

Strategic Aircrew Requests (TASAR)”, AIAA-2012-5684. 

[6] Koczo, S., Wing, D., “An operational safety and certification assessment of a TASAR EFB 

application”, Digital Avionics Systems Conference (DASC), 2013, IEEE/AIAA 32nd, 

October 2013. 

[7] Koczo, S., “Analysis of Operational Hazards and Safety Requirements for Traffic Aware 

Strategic Aircrew Requests (TASAR)”, NASA Contractor Report, NASA/CR–2013-218002, 

2013.

[8] Maris, J., Haynes, M., Wing, D., “Traffic Aware Planner (TAP) Flight Evaluation”, AIAA 

2014-2166.

[9] SAE ARP 4761, Guidelines and Methods for Conducting the Safety Assessment Process on 

Civil Airborne Systems and Equipment.

[10] AC 23.1309-1, System Safety Analysis and Assessment for Part 23 Airplanes.

[11] AC 25.1309-1, System Design and Analysis.

[12] RTCA DO-264 / EUROCAE ED-78A, “Guidelines for Approval of the Provision and Use 

of Air Traffic Services supported by Data Communications”.

[13] AC 120-76C, “Guidelines for the Certification, Airworthiness, and Operational Approval of 

Electronic Flight Bag Computing Devices”.

[14] Flight Standards Information System (FSIMS) – 8900.1 Change 47, Vol. 4, Chapter 15 – 

EFB Operational Authorization Process. 

[15] AC 91.21-1, Use of Portable Electronic Devices Aboard Aircraft. 

[16] AC 20-173, Installation of Electronic Flight Bag Components.

[17] AC 21-16, RTCA Document DO-160 “Environmental Conditions and Test Procedures for 

Airborne Equipment”. 

[18] TSO-C195 (i.e., RTCA DO-317 – ASAS MOPS), Avionics Supporting Automatic Dependent 

Surveillance – Broadcast (ADS-B) Aircraft Surveillance Applications (ASA).
172

[19] SAE ARP 4754A, Guidelines for Development of Civil Aircraft and Systems.

[20] AC 20-115, RTCA, Inc., Document RTCA/DO-178B.

[21] AC 20-152, RTCA, Inc., Document RTCA/DO-254, Design Assurance Guidance for 

Airborne Electronic Hardware. 

[22] AC 20-159, Obtaining Design and Production Approval for Airport Moving Map.

[23] AC 25-11A, Electronic Flight Deck Displays. 

[24] AC 91-78, Use of Class 1 or Class 2 Electronic Flight Bag (EFB).

[25] TSO-C165, Electronic Map Display Equipment for Graphical Depiction of Aircraft Position. 

[26] RTCA/DO-257A, Minimum Operation Performance Standards for the Depiction of 

Navigational Information on Electronic Maps.

[27] FAA Order 8110.4C, Type Certification

[28] “The FAA and Industry Guide to Product Certification”, AIA, GAMA and FAA Aircraft 

Certification Service, September 2004 

[29] Title 14 of the Code of Federal Regulations (14 CFR) parts 21, 23, 25, 27, 29, 43, 91F, 91K, 

121, 125, and 135. 

[30] AC 25-11, Electronic Flight Deck Displays (for Part 25 aircraft.

[31] AC 23.1311-1, Installation of Electronic Display in Part 23 Airplanes.

[32] Schnell, T., “TASAR Human-in-the-Loop Simulation Experiment #1 Report”, NASA 

Contract NNL12AA11C, In Publication, University of Iowa Operator Performance 

Laboratory, March 2014. 

[33] Schnell, T., “TASAR Human-in-the-Loop Simulation Experiment #2 Report”, NASA 

Contract NNL12AA11C, In Publication, University of Iowa Operator Performance 

Laboratory, May 2015. 

[34] AC 120-76B, “Guidelines for the Certification, Airworthiness, and Operational Approval of 

Electronic Flight Bag Computing Devices”.
REPORT DOCUMENTATION PAGE Form Approved

OMB No. 0704-0188

2. REPORT TYPE 

&RQWUDFWRU5HSRUW

 4. TITLE AND SUBTITLE

7$6$5&HUWLILFDWLRQDQG2SHUDWLRQDO$SSURYDO5HTXLUHPHQWV$QDO\VHV

DQG5HVXOWV

5a. CONTRACT NUMBER

 6. AUTHOR(S)

.RF]R6WHIDQ-U

 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

1$6$/DQJOH\5HVHDUFK&HQWHU

+DPSWRQ9$



 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

1DWLRQDO$HURQDXWLFVDQG6SDFH$GPLQLVWUDWLRQ

:DVKLQJWRQ'&

 8. PERFORMING ORGANIZATION

 REPORT NUMBER

10. SPONSOR/MONITOR'S ACRONYM(S)

1$6$

13. SUPPLEMENTARY NOTES

/DQJOH\7HFKQLFDO0RQLWRU'DYLG-:LPJ

12. DISTRIBUTION/AVAILABILITY STATEMENT

8QFODVVLILHG8QOLPLWHG

6XEMHFW&DWHJRU\

$YDLODELOLW\1$6$67,3URJUDP

19a. NAME OF RESPONSIBLE PERSON

67,+HOS'HVNHPDLOKHOS#VWLQDVDJRY

14. ABSTRACT

7KLVUHSRUWGRFXPHQWVWKHUHVXOWVRIUHVHDUFKDQGGHYHORSPHQWZRUNSHUIRUPHGE\5RFNZHOO&ROOLQVLQDGGUHVVLQJWKH7DVNREMHFWLYHVXQGHU1$6$&RQWUDFW

11/$$&8QGHUWKLVFRQWUDFW5RFNZHOO&ROOLQVSURYLGHGDQDO\WLFDOVXSSRUWWRWKH1$6$/DQJOH\5HVHDUFK&HQWHU/D5&LQ1$6$¶VGHYHORSPHQWRID

7UDIILF$ZDUH6WUDWHJLF$LUFUHZ5HTXHVWV7$6$5IOLJKWGHFN(OHFWURQLF)OLJKW%DJ()%DSSOLFDWLRQIRUWHFKQRORJ\WUDQVLWLRQLQWRRSHUDWLRQDOXVH7KH

WZRSULPDU\REMHFWLYHVRIWKLVFRQWUDFWZHUHIRU5RFNZHOO&ROOLQVDQGWKH8QLYHUVLW\RI,RZD23/WRSHUIRUPDQLPSOHPHQWDWLRQDVVHVVPHQWRI7$6$5

WRZDUGHDUO\FHUWLILFDWLRQDQGRSHUDWLRQDODSSURYDORI7$6$5DVDQ()%DSSOLFDWLRQ7DVNRIWKLVFRQWUDFWDQGGHVLJQGHYHORSDQGFRQGXFWWZR

+XPDQLQWKH/RRS+,7/VLPXODWLRQH[SHULPHQWVWKDWHYDOXDWH7$6$5DQGWKHDVVRFLDWHG7UDIILF$ZDUH3ODQQHU7$3VRIWZDUHDSSOLFDWLRQWRGHWHUPLQH

WKHVLWXDWLRQDODZDUHQHVVDQGZRUNORDGLPSDFWVRI7$6$5LQWKHIOLJKWGHFNZKLOHDOVRDVVHVVLQJWKHOHYHORIFRPSUHKHQVLRQXVHIXOQHVVDQGXVDELOLW\RIWKH

IHDWXUHVRI7$37DVNRIWKLVFRQWUDFW7KLVUHSRUWUHSUHVHQWVWKH7DVNVXPPDU\UHSRUW7KH7DVNVXPPDU\UHSRUWLVSURYLGHGLQ>@

15. SUBJECT TERMS

$LUFUHZ&HUWLILFDWLRQ)OLJKWFUHZV6LPXODWLRQ6WUDWHJLF7UDIILF

18. NUMBER

 OF 

 PAGES



19b. TELEPHONE NUMBER (Include area code)



a. REPORT

8

c. THIS PAGE

8

b. ABSTRACT

8

17. LIMITATION OF 

 ABSTRACT

88

Prescribed by ANSI Std. Z39.18

Standard Form 298 (Rev. 8-98)

3. DATES COVERED (From - To)

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

5d. PROJECT NUMBER

5e. TASK NUMBER

11/$$&

5f. WORK UNIT NUMBER

 

11. SPONSOR/MONITOR'S REPORT

 NUMBER(S)

1$6$&5

16. SECURITY CLASSIFICATION OF:

The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, 

gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this 

collection of information, including suggestions for reducing this burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and 

Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person 

shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number.

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS.

1. REPORT DATE (DD-MM-YYYY)