0% found this document useful (0 votes)
30 views19 pages

FAA Order 8110.49A

This order explains how Federal Aviation Administration (FAA) aircraft certification staff can use and apply RTCA/DO-178B and RTCA/DO-178C when working on certification projects. The guidelines apply to the approval of airborne systems and equipment and the software aspects of those systems.

Uploaded by

AnnaKarenina25
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
30 views19 pages

FAA Order 8110.49A

This order explains how Federal Aviation Administration (FAA) aircraft certification staff can use and apply RTCA/DO-178B and RTCA/DO-178C when working on certification projects. The guidelines apply to the approval of airborne systems and equipment and the software aspects of those systems.

Uploaded by

AnnaKarenina25
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

U.S.

DEPARTMENT OF TRANSPORTATION
FEDERAL AVIATION ADMINISTRATION ORDER
8110.49A

National Policy Effective Date:


3/29/2018
SUBJ: Software Approval Guidelines

This order explains how Federal Aviation Administration (FAA) aircraft certification staff can use and
apply RTCA/DO-178B and RTCA/DO-178C when working on certification projects. The guidelines
are applicable to the approval of airborne systems and equipment and the software aspects of those
systems. Because it’s impractical to cover all situations or conditions, supplement these instructions
with good judgment when handling problems.

Dr. Michael C. Romanowski


Director, Policy & Innovation Division
Aircraft Certification Service

Distribution: Electronic Initiated By: AIR-600


3/29/18 8110.49A
Table of Contents
Paragraph Page

Chapter 1. General Information ............................................................................................... 1-1


1. Purpose. .......................................................................................................................... 1-1
2. Audience. ........................................................................................................................ 1-1
3. Related Publications. ...................................................................................................... 1-1
4. Cancellation. ................................................................................................................... 1-2
5. Explanation of Changes. ................................................................................................. 1-2
6. Software Topics Covered in This Order. ........................................................................ 1-2
7. Definitions. ..................................................................................................................... 1-3
8. Acronyms........................................................................................................................ 1-4
9. Records Management. .................................................................................................... 1-5
10. Suggestions for Improvement. ........................................................................................ 1-5
11. Where to Find this Order. ............................................................................................... 1-5

Chapter 2. Software Review Process ........................................................................................ 2-1


1. General............................................................................................................................ 2-1
2. Objectives of the Software Review Process. .................................................................. 2-1

Chapter 3. [Reserved] ................................................................................................................ 3-1

Chapter 4. Software Conformity Inspection ........................................................................... 4-1


1. General............................................................................................................................ 4-1
2. Discussion. ...................................................................................................................... 4-1
3. Software Part Conformity Inspection. ............................................................................ 4-1
4. Software Installation Conformity Inspection. ................................................................ 4-2
5. Summary. ........................................................................................................................ 4-3

Appendix A. Level of Involvement Worksheets ..................................................................... A-1

Appendix B. Directive Feedback Information ....................................................................... B-1

i
3/29/18 8110.49A

Chapter 1. General Information

1. Purpose. This order guides Aircraft Certification Service (AIR) offices and designees on
how to apply RTCA/DO-178B and RTCA/DO-178C, herein called RTCA/DO-178B/C for
approving software used in airborne computers. Both are titled “Software Considerations in
Airborne Systems and Equipment Certification”. The guidelines are applicable to the approval
of airborne systems and equipment and the software aspects of those systems related to type
certificates (TC), supplemental type certificates (STC), amended type certificates (ATC),
amended supplemental type certificates (ASTC), and technical standard order (TSO)
authorizations (TSOA).
Note: References to use of DO-178C in this order include use of supplements (DO-331, DO-332,
DO-333) and DO-330, as applicable.

2. Audience. Managers and staff of the FAA Aircraft Certification Service, including any
persons designated by the administrator, and organizations associated with the certification
process required by Title 14 of the Code of Federal Regulations (14 CFR).

3. Related Publications. The latest amendments of the following publications are the primary
reference materials for this order:

a. Code of Federal Regulations. 14 CFR part 21, Certification Procedures for Products
and Parts.

b. FAA ACs and Orders. Copies of the following ACs and orders are available from the
FAA website at http://www.faa.gov/regulations_policies.

(1) AC 20-115, Airborne Software Development Assurance Using EUROCAE ED-12( )


and RTCA DO-178( ).

(2) AC 21-43, Production Under 14 CFR Part 21, Subparts F, G, K, and O.

(3) AC 23.1309-1, System Safety Analysis and Assessment for Part 23 Airplanes.

(4) AC 25.1309-1, System Design and Analysis.

(5) AC 27-1, Certification of Normal Category Rotorcraft.

(6) AC 29-2, Certification of Transport Category Rotorcraft.

(7) AC 33.28-1, Compliance Criteria for 14 CFR 33.28, Aircraft Engines, Electrical and
Electronic Engine Control Systems.

(8) AC 33.28-2, Guidance Material for 14 CFR 33.28, Reciprocating Engine, Electrical
and Electronic Engine Control Systems.

(9) AC 33.28-3, Guidance Material for 14 CFR 33.28, Engine Control Systems.

1-1
3/29/18 8110.49A

(10) Order 8040.4, Safety Risk Management Policy.

(11) Order 8110.4, Type Certification Process.

c. RTCA, Inc. Documents. Copies of RTCA documents may be purchased from RTCA,
Inc., 1150 18th St. NW, Suite 910, Washington, D.C. 20036. Alternatively, copies may be
purchased on-line at http://www.rtca.org. RTCA documents referenced in this order are:

(1) RTCA, Inc., document RTCA/DO-178B, Software Considerations in Airborne


Systems and Equipment Certification, dated December 1, 1992.

(2) RTCA, Inc., document RTCA/DO-178C, Software Considerations in Airborne


Systems and Equipment Certification, dated December 13, 2011.

(3) RTCA, Inc., document RTCA/DO-248C, Supporting Information for DO-178C and
DO-278A, dated December 13, 2011.

(4) RTCA DO-330, Software Tool Qualification Considerations, dated December 13,
2011.

(5) RTCA DO-331, Model-Based Development and Verification Supplement to


DO-178C and DO-278A, dated December 13, 2011.

(6) RTCA DO-332, Object-Oriented Technology and Related Techniques Supplement to


DO-178C and DO-278A, dated December 13, 2011.

(7) RTCA DO-333, Formal Methods Supplement to DO-178C and DO-278A, dated
December 13, 2011.

4. Cancellation. This order cancels and supersedes FAA Order 8110.49 Chg 2, Software
Approval Guidelines, dated April 10, 2017.

5. Explanation of Changes. FAA Order 8110.49 Chg 2, dated 4/10/17, Chapters 5 – 16 were
deleted to eliminate duplication or conflict since the topics previously addressed in these
chapters are now addressed in AC 20-115D, AC 00-69, or were removed.

6. Software Topics Covered in This Order.

a. This order assumes that RTCA/DO-178B/C is the means of compliance proposed by the
applicant for software approval. If the applicant proposes other means, additional policy and
FAA guidance may be needed on a project-by-project basis.

b. This order addresses software-related topics and is supplemental to RTCA/DO-178B/C.


Guidelines in the following areas are addressed:

(1) The software review process (chapter 2); and

(2) Software conformity inspections (chapter 4).

1-2
3/29/18 8110.49A

7. Definitions. For purposes of this order, the following definitions apply:

a. Certification authority is the aviation authority that accepts and/or approves software
life cycle data.

b. Certification credit is the acceptance by the certification authority that a software


process, software product, or demonstration satisfies a certification requirement (see
RTCA/DO-178B/C, Glossary).

c. Original certification project is the first use of the software life cycle data in a
completed certification project.

d. Review is the act of inspecting or examining software life cycle data, software project
progress and records, and other evidence to assess compliance with RTCA/DO-178B/C
objectives. Review is an encompassing term and may consist of a combination of reading
documents, interviewing project personnel, witnessing activities, sampling data, and
participating in briefings. A review may be conducted at your own desk, at an applicant’s
facility, or at an applicant’s supplier’s facility.

e. Sampling is selecting a representative set of software life cycle data for inspection or
analysis. The purpose is to determine the compliance of all software life cycle data developed up
to that point in time in the project. Sampling is the primary means of assessing the compliance
of the software processes and data. Examples of sampling may include the following:

(1) Inspecting the traceability from system requirements to software requirements to


software design to source code to object code to test cases and procedures to test results.

(2) Reviewing analyses used to determine RTCA/DO-178B/C objective compliance (for


example, timing analysis).

(3) Examining the structural coverage of code modules.

(4) Examining software quality assurance (SQA) records and configuration management
records.

f. Software is computer programs and, possibly, associated documentation and data


pertaining to the operation of a computer system (see RTCA/DO-178B/C, Glossary).

g. Software Configuration Index (SCI) identifies the configuration of the software


product. It can contain one configuration item or a set of configuration items (see
RTCA/DO-178B/C, Section 11.16).

h. Software library is a controlled repository of software and related data and documents
designed to aid in software development, use, or modification (see RTCA/DO-178B/C,
Glossary).

i. Software life cycle data are data produced during the software life cycle to plan, direct,
explain, define, record, or provide evidence of activities (see RTCA/DO-178B/C, Section 11.0).

1-3
3/29/18 8110.49A

Sections 11.1 through 11.20 of RTCA/DO-178B and Sections 11.1 through 11.22 of
RTCA/DO 178C describe different kinds of software life cycle data.

j. Software Life Cycle Environment Configuration Index identifies the configuration of


the software life cycle environment. It is written to aid reproduction of the hardware and
software life cycle environment (see RTCA/DO-178B/C, Section 11.15).

k. Software plans and standards are a set of data that directs the software development
processes and integral processes (see RTCA/DO-178B/C, Sections 4.0 and 11.1 through 11.8).

l. Software tool is a computer program used to help develop, test, analyze, produce, or
modify another program or its documentation (see RTCA/DO-178B/C, Glossary).

m. Test for certification credit is system certification test conducted under a


FAA-approved test plan for the purpose of showing compliance to the regulations.

n. Tool qualification is the process necessary to obtain certification credit for a software
tool within the context of a specific airborne system (see RTCA/DO-178B/C, Section 12.2 and
Glossary).

8. Acronyms. The following is a list of acronyms used in this order:


Acronym Explanation

AC Advisory Circular
AIR Aircraft Certification Service
ASE Aviation Safety Engineer
ASI Aviation Safety Inspector
ASTC Amended Supplemental Type Certificate
ATC Amended Type Certificate
CFR Code of Federal Regulations
CRC Cyclic Redundancy Check
FAA Federal Aviation Administration
MIDO Manufacturing Inspection District Office
MISO Manufacturing Inspection Satellite Office
SAS Software Accomplishment Summary
SCI Software Configuration Index
SCMP Software Configuration Management Plan
SQA Software Quality Assurance
STC Supplemental Type Certificate
TC Type Certificate
TIA Type Inspection Authorization
TSO Technical Standard Order
TSR Total Score Result

1-4
3/29/18 8110.49A

9. Records Management. Refer to Orders 0000.1G and 1350.14B or your office Records
Management Officer (RMO)/Directives Management Officer (DMO) for guidance regarding
retention or disposition of records.

10. Suggestions for Improvement. If you find deficiencies, a need for clarification, or want to
suggest improvements on this order, send a copy of FAA Form 1320-19, Directive Feedback
Information, to the Aircraft Certification Service, Attention: Directives Management Officer at
9-AWA-AVS-AIR-DMO@faa.gov, for consideration. If you urgently need an interpretation,
you may contact the Systems Integration Section at 202-267-1575 for guidance. You should also
use the FAA Form 1320-19 as a follow-up to verbal conversation. FAA Form 1320-19 may be
found in Appendix B and electronically at https://employees.faa.gov/tools_resources/forms/.

11. Where to Find this Order. You can find this order at
http://www.faa.gov/regulations_policies/orders_notices and on the FAA Regulatory and
Guidance Library (RGL) website at http://rgl.faa.gov.

1-5
3/29/18 8110.49A

Chapter 2. Software Review Process

1. General.

a. Section 9 of RTCA/DO-178B/C describes the certification liaison process. This process


is the vehicle to establish communication and understanding between the applicant and the
certification authority. Sections 9.2 and 10.3 of RTCA/DO-178B/C state that the certification
authority may review the software life cycle processes and data to assess compliance to
RTCA/DO-178B/C. This chapter does not change the intent of RTCA/DO-178B/C.

b. Although desk reviews may be used to successfully review software, on-site reviews
have the advantages of access to software personnel, to all automation, and to test setup. Both
on-site and desk reviews may be delegated to properly authorized designees. For on-site
reviews, the certification authority should include the following practical arrangements with the
software developer:

(1) Agreement on the scope of review(s) that will be conducted.

(2) Agreement on date(s) and location(s) of the review(s).

(3) Identification of the certification authority’s personnel involved.

(4) Identification of any designees involved.

(5) Development of the agenda(s) and expectations.

(6) Listing of software data to be made available (both before and at the review(s)).

(7) Clarification of procedures to be used.

(8) Identification of any required resources.

(9) Specification of date(s) and means for communicating review results (may include
corrective actions and other post-review activities).

2. Objectives of the Software Review Process.

a. The certification authority may review the software life cycle processes and associated
data to obtain assurance that a software product submitted as part of a certification application
complies with the certification basis and satisfies the applicable objectives of RTCA/DO-
178B/C. The software review process assists both the certification authority and the applicant to
determine if a particular project will meet the certification basis, applicable guidance, and
RTCA/DO-178B/C objectives by providing:

(1) Timely technical interpretation of the certification basis, RTCA/DO-178B/C


objectives, FAA guidance, issue papers, and other applicable certification requirements.

2-1
3/29/18 8110.49A

(2) Visibility into the implementation compliance and the applicable data.

(3) Objective evidence that the software project adheres to its approved software plans
and procedures.

(4) The opportunity for the certification authority to monitor designee activities.

b. The level of certification authority involvement in a software project should be


determined and documented as soon as possible in the project life cycle. Appendix A provides
examples that may be used to determine the level of involvement. The scope and number of
software reviews, if any, will depend on several factors including:

(1) Software level(s), as determined by a system safety assessment.

(2) Product attributes (such as size, complexity, system functionality or novelty, and
software design).

(3) Use of new technologies or unusual design features.

(4) Proposals for novel software methods or life cycle model(s).

(5) Applicant’s experience in satisfying the objectives of RTCA/DO-178B/C.

(6) Availability, experience, and authorization of designees.

(7) Issues associated with Section 12 of RTCA/DO-178B/C in the project.

(8) Applicability of issue papers for software-specific aspects of the certification project

2-2
3/29/18 8110.49A

Chapter 3. [Reserved]

3-1
3/29/18 8110.49A

Chapter 4. Software Conformity Inspection

1. General. This chapter describes the software conformity inspection process. This process
applies to TC, STC, ATC, ASTC, and TSO authorization projects. This chapter is based on FAA
Order 8110.4B and RTCA/DO-178B. While RTCA/DO-178B is recognized by AC 20-115B as
a means, but not the only means, to secure FAA approval of the digital computer software, it is
used here because it is the typical means of compliance used by applicants integrating airborne
software. If another means of compliance other than RTCA/DO-178B is used, the conformity
concepts of this chapter should still apply.

2. Discussion. A conformity inspection is required to determine that the applicant complies


with 14 CFR § 21.33(b) and that the product and components conform to approved type design.
For software, type design consists of, as a minimum, Software Requirements Data, Design
Description, Source Code, Executable Object Code, Software Configuration Index, and the
Software Accomplishment Summary (see RTCA/DO-178B, Section 9.4). Determination of an
applicant’s compliance to software type design is largely assessed through ASE or DER
(if authorized) reviews throughout the software development life cycle; the details of which are
presented in chapter 2 of this order. However, there are instances where the state of the software
must be reviewed and documented before issuance of TC, STC, ATC, ASTC, or TSO
authorization (specifically, test acceptance and installation). Accordingly, there are two means
for achieving this: (1) software part conformity inspection, and (2) software installation
conformity inspection.

3. Software Part Conformity Inspection. The conformity of the test article, test setup, test
procedures used, and the validity of the test results should be established for each test conducted
for certification credit. Test for certification credit is defined in this chapter as system
certification test conducted under an FAA-approved test plan for the purpose of showing
compliance to the regulations. The FAA-approved test plan is the test plan approved before
conducting an official FAA ground or flight test. It is not the Software Verification Plan
referenced in RTCA/DO-178B. Examples of tests conducted to satisfy FAA certification credit
are RTCA/DO-160D environmental qualification tests, system functional tests, systems
integration tests, aircraft ground functional tests, and aircraft Type Inspection Authorization
Tests (TIA) flight tests.

a. The ASE should perform the following tasks:

(1) Establish that the software baseline complies to its type design and released software
plans by conducting FAA desk and/or on-site reviews (see chapter 2 of this order); or establish
that the software DER (if delegated) has approved the baseline software by submitting a FAA
Form 8110-3, “Statement of Compliance with the Federal Aviation Regulations.” The DER
should state in Form 8110-3 that the “purpose of Form 8110-3 is to approve the software
baseline for the purposes of conducting FAA testing for certification credit.”
Note: In some cases, special purpose software is used for environmental qualification
testing. When this is the case, the manufacturer must verify, validate, and control the
configuration of the special purpose test software. The test software should be included as part
of the test setup conformity conducted before the qualification testing.

4-1
3/29/18 8110.49A

(2) Establish that the test configuration of the software to be installed in the Line
Replaceable Unit complies with its software test baseline.

(3) Establish that all software artifacts associated with the test baseline are properly
identified, under configuration control, and reflect the current state of the software under test.

(4) Establish that any software development tools or software verification tools that
require qualification have been qualified. However, if the tool qualification activities are not
completed at the time of conformity, the tools and supporting data should have their
configuration documented.

(5) Initiate a FAA Form 8120-10, Request for Conformity, and submit it to the
MIDO/MISO, providing instructions for the ASI to perform the following:

(a) Verify that the proper build and load file(s) was/were removed from the
software configuration management (SCM) library.

(b) Verify that approved build and load instructions are followed during the
software build and load process.

(c) Verify that any data integrity checks and software part numbers (including
version numbers) are verified in the Line Replacement Unit.

(d) Verify that the test setup conforms to the test setup configuration identified in
the approved engineering test plan.

(6) Establish that the procedure used for retention, archive, and retrieval of the software
life cycle data is compliant with the approved SCM plan.

b. The ASI should perform those tasks mentioned in paragraph 4-3a(5) above and as
identified on the Form 8120-10.

c. The software part conformity inspection should be successfully conducted before


requesting a software installation conformity inspection.

4. Software Installation Conformity Inspection. A software installation conformity


inspection is required anytime an FAA aircraft-level ground or certification flight test is
performed, such as tests conducted per the TIA. The main objectives are to show that:

a. An approved, controlled version of the software is loaded successfully into the target
system in conformance with approved system installation procedures and/or software loading
procedures, and

b. The correct version for that system was loaded and will successfully initialize.

c. The ASE should ensure:

(1) A prior software part conformity inspection was successfully completed.

4-2
3/29/18 8110.49A

(2) Load procedures have been approved.

(3) A FAA Form 8120-10, Request for Conformity, or FAA Form 8110-1, Type
Inspection Authorization (TIA), is initiated and contains the software part number and/or version
number for which an installation conformity inspection is being requested. The software part
number and/or version number should be identifiable, under configuration control, reproducible,
and documented in the SCI or similar configuration documentation. The request should also
include any actions/activities to be verified by the ASI including:

(a) Verification that the correct software version has been loaded into the system
and that the correct system hardware (part numbers and serial numbers) has been installed on the
aircraft.

(b) Verification that the loading procedure(s) ensures the correct software part
number (and version number) is loaded into the correct system hardware components (serial
numbers and part numbers). An error indication should result anytime that the software loading
procedure or ground support equipment detects a mismatch of part and version numbers or an
unsuccessful load. The installation conformity inspection should determine that the
manufacturer’s loading procedure(s) are followed and that the software load initializes correctly.
Mismatches should be identified and documented.

d. The ASI should perform the software installation conformity inspection addressed in
the FAA Form 8120-10, or FAA TIA Form 8110-1 (see item 4-4c(3) of this chapter) by one of
two methods:

(1) By physically witnessing the successful loading of the correct software part number
and version into the actual system (that is, actual part number and serial number) installed on the
aircraft or to be installed on the aircraft. Successful load may be determined by witnessing that
an integrity check was used to verify the software load (for example, comparison of cyclic
redundancy checks (CRC)), and by witnessing that the software successfully executed the
initialization procedure. The software loading process must be done in accordance with the
software load procedures reviewed and approved by the ASE.

(2) By obtaining the manufacturing inspection records that document the results of the
actual software loading. These records should include aircraft identification information, system
hardware part numbers and serial numbers, and software part numbers and version number, as
applicable. The records provided should identify the hardware unit part number and serial
number information so that the ASI (or designee, if delegated) can trace it to the system installed
on the aircraft. The records provided should also show the software part number that was loaded
into the system hardware. The records should indicate when and how the software was loaded
and that the loading and initialization process was successful.

e. The software installation conformity inspection ensures that the system(s) installed on the
aircraft and the software loaded into the system(s) for the purpose of conducting aircraft-level
testing conforms to the FAA-approved type design data.

5. Summary. The purpose of a conformity inspection is to ensure that the product built
(hardware and software) conforms to the type design. The two types of software conformity

4-3
3/29/18 8110.49A

inspections addressed in this chapter are “software part conformity inspections” and “software
installation conformity inspections.” The responsibilities for ASEs and ASIs are identified for
each of the two types of software conformity inspections addressed in this chapter. Software part
conformity inspections and software installation conformity inspections are required whenever
an applicant is to conduct laboratory system/hardware testing for certification credit as defined in
paragraph 4-3, and during the installation of the system with the embedded software for the
purpose of conducting aircraft-level ground and/or flight testing. The purpose of the
aforementioned software conformity inspections is to ensure:

a. The configuration of the unit under test reflects the correct hardware and software
configuration that was approved for the given test being conducted for FAA certification credit.

b. The configuration of the unit under test is well documented should there be any changes
to the hardware and/or software after the tests have already been conducted.

c. The systems installed on the aircraft and the software loaded into the installed systems for
the purpose of conducting aircraft-level testing conforms to the FAA-approved type design.

d. The final software and hardware configuration product baseline presented for
certification conforms to the type design.

4-4
3/29/18 8110.49A
Appendix A
Appendix A. Level of Involvement Worksheets

Appendix A contains three worksheets that may be used to help the certification authority or
designee determine an appropriate level of involvement in software projects. The worksheets are
provided as examples only; may contain criteria that are not applicable to all projects; and their
use, individually or in combination, is not mandatory. Worksheet 1 indicates a level of
involvement based on the software level of the project. Worksheet 2 allows for additional
refinement of involvement based on more specific criteria. Worksheet 3 uses the total score
result from Worksheet 2 to indicate a level of involvement.

Worksheet 1: Level of Involvement Based on Software Level

RTCA/DO-178B/C Software Level Level of Involvement


D LOW
C LOW or MEDIUM
B MEDIUM or HIGH
A MEDIUM or HIGH

A-1
3/29/18 8110.49A
Appendix A
Worksheet 2: Level of Involvement Based on Other Relevant Project Criteria
Criteria Scale MIN. MAX. Score

1. Applicant/Developer Software Certification Experience


1.1 Experience with civil Scale: 0 5 10
aircraft or engine # projects: 0 3-5 6+
certification.
1.2 Experience with Scale: 0 5 10
RTCA/DO-178B/C. # projects: 0 2-4 5+
1.3 Experience with Scale: 0 3 5
RTCA/DO-178 or # projects: 0 4-6 7+
RTCA/DO-178A.
1.4 Experience with other Scale: 0 2 4
software standards # projects: 0 4-6 7+
(other than RTCA/DO-
178 [ ]).
2. Applicant/Developer Demonstrated Software Development Capability
2.1 Ability to consistently Scale: 0 5 10
produce RTCA/DO- Ability: Low Med High
178B/C software
products.
2.2 Cooperation, openness, Scale: 0 5 10
and resource Ability: Low Med High
commitments.
2.3 Ability to manage Scale: 0 5 10
software development Ability: Low Med High
and sub-contractors.
2.4 Capability assessments Scale: 0 2 4
(for example, Software Ability: Low Med High
Engineering Institute
Capability Maturity
Model, ISO 9001[]).
2.5 Development team Scale: 0 5 10
average based on Ability: < 2 yrs 2-4 yrs > 4 yrs
relevant software
development
experience.
3. Applicant/Developer Software Service History
3.1 Incidents of software- Scale: 0 5 10
related problems (as a Incidents: > 25% > 10% None
% of affected products).
3.2 Company Scale: 0 5 10
management’s support Quality: Low Med High
of designees.
3.3 Company software Scale: 0 5 10
quality assurance Quality: Low Med High
organization and
configuration
management process.

A-2
3/29/18 8110.49A
Appendix A
Criteria Scale MIN. MAX. Score
3.4 Company stability and Scale: 0 3 6
commitment to safety. Stability: Low Med High
3.5 Success of past Scale: 0 3 6
company certification Success: None > 50% All
efforts.
4. The Current System and Software Application
4.1 Complexity of the Scale: 0 5 10
system architecture, Complex: High Med Low
functions, and
interfaces.
4.2 Complexity and size of Scale: 0 5 10
the software and safety Complex: High Med Low
features.
4.3 Novelty of design and Scale: 0 5 10
use of new technology. Newness: Much Some None
4.4 Software development Scale: 0 3 6
and verification Environ: None Older Modern
environment.
4.5 Use of alternative Scale: 0 3 6
methods or additional Standard: Much Little None
considerations.
5. Designee Capabilities
5.1 Experience of Scale: 0 5 10
designee(s) with Projects: <5 5-10 > 10
RTCA/DO-178B/C.
5.2 Designee authority, Scale: 0 5 10
autonomy, and Autonomy: None Self-starter Outgoing
independence.
5.3 Designee cooperation, Scale: 0 5 10
openness, and issue Effectiveness: Non-Responsive Responsive Cooperative/Open
resolution effectiveness.
5.4 Relevance of assigned Scale: 0 5 10
designees’ experience. Related: None Somewhat Exact
5.5 Designees’ current Scale: 0 5 10
workload. Workload: High Medium Low
5.6 Experience of Scale: 0 3 5
designees with other Projects: <5 5-10 > 10
software standards
(other than RTCA/DO-
178[]).

Total Score Result (TSR): ______

A-3
3/29/18 8110.49A
Appendix A
Worksheet 3: Level of Involvement Combining Results of Worksheet 2 with Software Level

Total Score Result Software Software Software Software


(TSR) Level A Level B Level C Level D
TSR < 80 HIGH HIGH MEDIUM LOW
80 < TSR < 130 HIGH MEDIUM MEDIUM LOW
130 < TSR MEDIUM MEDIUM LOW LOW

A-4
3/29/18 8110.49A
Appendix B

Appendix B. Directive Feedback Information

Directive Feedback Information

Please submit any written comments or recommendation for improving this directive, or suggest
new items or subjects to be added to it. Also, if you find an error, please tell us about it.

Subject: Order 8110.49A, Software Approval Guidelines

To: 9-AWA-AVS-AIR-DMO@faa.gov or
complete the form online at https://ksn2.faa.gov/avs/dfs/Pages/Home.aspx

Please check all appropriate line items:

An error (procedural or typographical) has been noted in paragraph _______ on page


_______.

Recommend paragraph _______ on page _______ be changed as follows:

In a future change to this AC, please cover the following subject:


(Briefly describe what you want added.)

Other comments:

I would like to discuss the above. Please contact me.


Submitted by: __________________________________ Date: __________________
Telephone Number: __________________ Routing Symbol: _________________

FAA Form 1320-19 (10-98)

B-1

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy