User:IveGoneAway/sandbox/FAA Order 8110.49
Objectives:
- Coverage of the historic but now reduced Mega Order
- Redirect target for the original Orders replaced by the Mega Order (so they don't need separate stubs)
- Traceability from CASTs to the Mega Order and EASA CMs
- Traceability from the Mega Order to the replacement Orders and ACs
- Feature on DYK
 FAA Publication | |
| Abbreviation | FAA Order 8110.49 (previously "The Mega Order") |
|---|---|
| Year started | 2003 |
| Latest version | A 2018 |
| Organization | Federal Aviation Administration |
| Domain | Avionics, type certification |
| Website | faa.gov |
FAA Order 8110.49A, Software Approval Guidelines, is an FAA publication that explains how Federal Aviation Administration (FAA) aircraft certification offices and designees (e.g., DERs) can use and apply DO-178B/DO-178C standards when reviewing software projects and conducting Software Conformity Inspections. These guidelines apply to Aircraft Certification Service and Flight Standards District Office personnel, persons designated by the administrator, and organizations associated with the certification processes required by Title 14 of the Code of Federal Regulations (14 CFR). Past revisions of the order also provided guidelines to applicants to those certification processes; for example, Leanna Rierson referred applicants to a number of chapters of the Change 1 release of Order 8110.49.[1]
Originally known as the Mega Order because of its replacement of several FAA orders and notices with a single large FAA order,[2] the present Revision A deals with just two subjects:
- The FAA Software Review Process (for assessing compliance with agreed certification bases)
- Software Conformity Inspection.
The order also contains worksheets that certification authorities may use to determine their level of review involvement in a software project (previously known as Level of FAA Involvement, or LOFI).
The Mega Order[edit]
At just three chapters, the present revision is a much-reduced publication compared to its prior issues. The original Order 8110.49 issue was called the Mega Order because it collected the contents of several existing FAA Orders into a single large order. The FAA withdrew the replaced orders after their inclusion in Order 8110.49. Later, the FAA replaced Order 8110.110, splitting that Order's content into four chapters that were largely concerned with particular aspects of Configuration Management, thereby expanding Order 8110.49 to sixteen chapters.
The replaced orders and notices include:
| 8110.85 | 8110.86 | 8110.87 | 8110.89 | 8110.90 |
| 8110.91 | 8110.92 | 8110.93 | 8110.94 | 8110.97 |
| 8110.110 | ||||
The replaced orders' titles and their mappings to the Mega Order chapters are listed in the revision history section, below.
Background[edit]
Included in the release of DO-178B was the requirement that applicants for certification under that standard define the methods they will use to perform the required activities to accomplish the standard's objectives. Applicants sought both clarifications on guidance in DO-178B and suggestions for acceptable methods. In particular, the Commercial Aviation Safety Team (CAST) developed a number of position papers that attempted to provide clarification and standardization in application of DO-178B by DERs. These publications also included suggested methods. Some of CAST's clarification efforts contributed to the eventual publication of DO-178C, but prior to that, methods similar to those described by CAST were incorporated into some of the FAA Orders and Notices listed above.
Wording along this line appears in the 2022 AC 20-189 and AC 00-71 for management of Open Problem Reports. While these ACs do not define methods for problem reporting they do define a standard interface for problem reports, that is, standard attributes for tracking criticality and status of Open Problem Reports. However, both ACs state that applicants may define alternative means for tracking and communicating OPRs to DERs, but also that use of such alternative means may not be a "basis for affirmative enforcement action or other administrative penalty."
"Streamlining"[edit]
However, since early 2018, most of these subjects were considered too prescriptive to private applicants for inclusion in a work order of requirements for FAA employees and representatives. A few of the topics were deleted from the whole of active FAA publications. The FAA moved some of those subjects to Advisory Circulars (AC) or other publications as "supporting information". In this process, however, most of the retained topics were "streamlined", which largely meant removal of any suggested methodology, leaving only a few clarifying statements in the remnant AC publication.
streamline...AMC 20-115D on the EASA side, and AC 00-SW ...[3]
The "sister" EASA publication is EASA CM-SWCEH-002 Issue: 01 Revision: 01 Software Aspects of Certification. This CM largely has the same chapters and contents as the FAA Mega Order. Less concerned about prescriptive guidance, the EASA has maintained their "Mega Order", even expanding it to cover 7 additional chapters.[5]
Present content[edit]
FAA software review process[edit]
Stages of Involvement (SOIs) [see also concept introduced by CAST]
Stages of Involvement (SOIs)
https://repositorio.unifesp.br/xmlui/bitstream/handle/11600/61002/Dissertation_MPIT_TMRS_Final_post_defense.pdf?sequence=1&isAllowed=y
See Page 15)
Level of Involvement[edit]
FAA conformity inspection process[edit]
parameter scrubbing
With the reduction of the scope … content was moved to
Removed content[edit]
Several sections of earlier revisions have been removed. Largely, these were sections covering activities performed by applicants rather than work instructions to FAA staff and representatives. So interpreted as instruction to applicant, some of those sections became regarded as overly prescriptive. The removed sections may still be referenced by applicants where these methods are practical to their processes.
As with the recommendation that Applicants at Level D, for example, are still expected to assure that low-level requirements are developed and verified and the source code tested, an applicant may still employ the activities defined in DO-178C for the omitted objectives in doing so; however, evidence need not be submitted to the FAA.
Provided some
Was replaced by
The Software Conformity Review objective of DO-178C is not addressed by 8110.49; however, 8110.86 had 6 informative paragraphs on the subject.
Level of FAA Involvement (LOFI)[edit]
Relative Hazards of the application, experience of the developers and the maturity of their quality management systems, and the technical scope, complexities, and risks of the application,
SOI #3[edit]
Effort to date
Has or will accomplish
- complete coverage of requirements by verification
- adequate level of level of structural coverage by testing
Replaced FAA Orders[edit]
A series of FAA Orders and Notices for software review and approval processes were incorporated into the original and revised 8110.49, thereby replacing those orders, which were then canceled. However, the replaced orders were not entirely transcribed into the Mega Order; particularly, certain recommended methods were omitted. Even so, it can be useful to be aware of some of these omitted methods as they continued to be referenced by some developers and authors.
The following sections briefly summarize a few of the replaced notices and their omitted content.
Notice 8110.86[edit]
DO-178B/C provides some guidance on its Software Conformity Review activities but holds no guidance on the relationship to Software Conformity Inspection. Even though Notice 8110.86 Guidelines for Software Conformity Inspection and Software Conformity Review is canceled, it provides discussions of the distinct processes of Software Conformity Inspection and Software Conformity Review not found in the replacing order. FAA Order 8110.49 does nothing more that refer to Software Conformity Review by name, while 8110.86 provided 6 paragraphs of discussion to supplement the Software Conformity Review activities described in Section 8.3 of DO-178C. Knowledge of this content can be useful to applicants preparing their processes to support eventual FAA-managed audits and inspections.
Notice 8110.86 describes Design Assurance Software Conformity Inspection and Software Installation Conformity Inspection, which are replaced by the Software Part Conformity Inspection and Software Installation Conformity Inspection processes defined in 8110.49.
PCI is an assessment for existence of reasonable evidence of an airworthy design; that is, a verified type design
ICI is an assessment for existence of reasonable evidence of conformity of a part, as manufactured and installed, with its type design
Notice 8110.87[edit]
The conformity review portion of 8110.87, Guidelines for Determining the Level of Federal Aviation Administration Involvement in Software,
Revision history[edit]
The initial content was "supplemental information to DO-178B", which was guidance to software certification applicants, and was compared to DO-248B and DO-278.[6] However, one of the efforts of the release of DO-178C was to clarify the meaning of "guidance", using that word to convey a stronger sense of obligation than "guidelines". The titles of several of the replaced orders began with the "guidelines", but their presence in the Order" conveyed that their contents were prescriptive to some degree.
out of place?
"The FAA's position as expressed in the FAA Order 8110.49 and Software Job aid is that if an applicant provides evidence to satisfy the objectives, then the software is DO-178B compliant." [7]
the initial 8110.49 incorporated and replaced 12 prior FAA Notices into the single order. Initially replaced … which were then canceled.
Prior to the original released of this order,
Guidelines for Software Conformity Inspection and Software Conformity Review Conformity Inspection is a certification liaison activity while Software Conformity Review is an applicant activity
Change 1 addition of 4 sections, largely concerned with issue of Configuration Management
Generally dated 2000-2002, corresponding with the release of DO-178B
| Replaced Prior Orders | 8110.49 (original 2003) (added in Change 1, 2011) ( |
8110.49A (2018) and Advisory Circulars, etc. |
EASA (2012) CM-SWCEH-002 |
|---|---|---|---|
| 8110.90, Guidelines for the Software Review Process | 2. Software Review Process | 2. Software Review Process | 4. Guidelines for the Software Review Process |
| 8110.87, Guidelines for Determining the Level of Federal Aviation Administration (FAA) Involvement in Software Projects | 3. Reserved |
3. Reserved (Deleted) | 5. Organisation, Role and Level of Involvement of EASA and Applicants in Software Projects |
| 8110.86, Guidelines for Software Conformity Inspection and Software Conformity Review | 4. Software Conformity Inspection | 4. Software Conformity Inspection | 6. Reserved |
| 8110.95, Guidelines for the Approval of Field-Loadable Software | 5. Approval of Field-Loadable Software (FLS) | AC 20-115D Section 8b |
7. Guidelines for the Approval of Field Loadable Software (FLS) |
| 8110.93, Guidelines for the Approval of Field-Loadable Software by Finding Identicality through the Parts Manufacturer Approval Process | 6. Approval of Field-Loadable Software (FLS) by Finding Identicality Through the Parts Manufacturer Approval (PMA) Process | 8. Reserved | |
| 8110.94, Guidelines for the Approval of Airborne Systems and Equipment Containing User-Modifiable Software | 7. Approval of Airborne Systems and Equipment Containing User-Modifiable Software (UMS) | AC 20-115D Section 8c |
9. Guidelines for the Approval of Airborne Systems and Equipment Containing User-Modifiable Software |
| 8110.92, Guidelines for Applying the RTCA/DO-178B Level D Criteria to Previously Developed Software (PDS) | 8. Previously Developed Software (PDS) – Applying RTCA/DO-178B Level D Criteria | AC 20-115D Section 9 DO-248C DP#10 |
10. Guidelines for Applying the ED-12B / DO-178B Level D Criteria to Previously Developed Software (PDS) |
| 8110.91, Guidelines for the Qualification of Software Tools Using RTCA/DO-178B | 9. Qualification of Software Tools Using RTCA/DO-178B | AC 20-115D Section 10 |
11. Guidelines for the Qualification of Software Tools Using ED-12B / DO-178B |
| 8110.89, Guidelines for the Approval of Software Changes in Legacy Systems Using RTCA/DO-178B | 10. Approval of Software Changes in Legacy Systems Using RTCA/DO-178B | AC 20-115D Section 9 |
12. Guidelines for the Certification of Software Changes in Legacy Systems Using ED-12B / DO-178B |
| 8110.85, Guidelines for the Oversight of Software Change Impact Analyses Used to Classify Software Changes as Major or Minor | 11. Oversight of Software Change Impact Analyses Used to Classify Software Changes as Major or Minor | AC 00-69 Section 3.1 |
13. Oversight of Software Change Impact Analyses Used to Classify Software Changes as Major or Minor |
| 8110.97, Guidelines for Approving Reused Software Life Cycle Data | 12. Approving Reused Software Life Cycle Data | AC 20-115D Section 9 |
14. Guidelines for Approving Reused Software Life Cycle Data |
| 8110.110, Chapter 1. Properly Overseeing Suppliers | 13. Properly Overseeing Suppliers | 15. Properly Overseeing Suppliers | |
| 8110.110, Chapter 2. Software Problem Reporting | 14. Software Problem Reporting | DO-248C DP#9 AC 20-189(2022) AC 00-71 (2022) |
16. Management of Problem Reports |
| 8110.110, Chapter 3. Assuring Airborne System Databases and Aeronautical Databases | 15. Assuring Airborne System Databases and Aeronautical Databases | 17. Embedded Software Configuration Files | |
| 8110.110, Chapter 4. Managing the Software Development and Verification Environment | 16. Managing the Software Development or Verification Environment | 18. Managing the Software Development and Verification Environment | |
Appendix A. Level of Involvement Worksheets |
Appx. A. Level of Involvement Worksheets | ||
| Appendix |
Appx. B. Directive Feedback Information | 26. Remarks | |
| DO-332/ED-217 | 19. The Use of Object Oriented Techniques at the Design rr Source Code Level | ||
| CAST-17 | 20. The Use of (OCC) Object Code Coverage for Equivalence to Modified Condition Decision Coverage (MCDC) | ||
| CAST-15 | 21. Merging High-Level and Low-Level Requirements | ||
| AC 00-69 Section 3.2 (from CAST-19) |
22. Clarification of Structural Coverage Analyses of Data Coupling and Control Coupling | ||
| DO-331/ED-218 | 23. The Validation and Verification of Model-Based Software Requirements and Designs | ||
| DO-248C FAQ #82 |
24. The Use of Pseudocode as Low-Level Requirements | ||
| 25. Stack Overflows |
References[edit]
- ^ Leanna Rierson (19 December 2017) [7 January 2013]. Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance. CRC Press. ISBN 9781351834056. Retrieved 2022-02-14.
... Certification Authorities Software Team (CAST)* paper CAST-15 ... warn against merging software requirements into a single level. There are a few projects where one level of software requirements is needed (...) but they are in the minority.
- ^ Mike Kress. "Synopsis Of 2003 FAA National Software Conference, Sept. 16-19, 2003, Reno, Nevada" (PDF). Software Quality (Winter 2003-2004): 7–10. Retrieved 2020-08-28.
John reported on the consolidation of the 8110 series of FAA Notices into a single Mega-Order 8110.49 with 12 chapters. 8110.49 incorporates 11 existing Notices and was coordinated within the FAA, industry and the public:
- ^ "Regular update of AMC-20: update of EASA AMC 20-115C and FAA AC 20-115C". Notice of Proposed Amendment (NPA 2017-02). EASA. Retrieved 2023-04-21.
Moreover, two additional guidance material documents have been created (GM to AMC 20-115D on the EASA side, and AC 00-SW on the FAA side) in order to keep and streamline 'best practices' topics that were considered to be important clarifications:
- ^ EASA, NPA 2017-02, page 6.
- ^ "Software Aspects of Certification" (PDF). Certification Memorandum (CM-SWCEH-002 Issue 1). EASA. 9 March 2012. Retrieved 2023-04-19.
- ^ Spitzer, Cary R.; et al., eds. (2015). Digital Avionics Handbook (PDF). Boca Raton, FL: CRC Press. p. 12-3. Retrieved 2020-09-01.
For more information on software-assurance guidelines, see Chapter ???[sic] of this book and supplemental information to DO-178B, such as RTCA/DO-248B, ... RTCA/DO-278 ... and FAA Order 8110.49, ....
{{cite book}}: Explicit use of et al. in:|editor=(help) - ^ Spitzer, Cary R., ed. (2007). Digital Avionics Handbook, Second Edition, Avionics, Development and Implementation. Boca Raton, FL: CRC Press. p. 7-12. Retrieved 2020-09-01.
The FAA's position as expressed in the FAA Order 8110.49 and Software Job aid is that if an applicant provides evidence to satisfy the objectives, then the software is DO-178B compliant.
External links[edit]
- "FAA Order 8110.49A" (PDF).
- Regulations & Policies on the FAA website
Bone pile[edit]
EASA CM-SWCEH-001, EASA
CM-SWCEH-002,
FAA Order 8110.105A ‘Simple and Complex Electronic Hardware Approval Guidance’, 5 April 2017 —
FAA Order 8110.49A "specifies how to determine the level of certification authority involvement in a software project."[1]
Ferrell:"Waning Vigilance or Needed Correction?" "a number of the deleted topics have found there [sic] way into FAA AC 20-115D and the new 'software best practices' AC 00-69, both released in July of 2017. Even so, this is a significant shift in software design assurance policy. Orders are mandatory and govern how FAA personnel and their designees perform oversight of software development programs. ACs, as their name implies, are advisory only."[2]
https://www.faa.gov/documentLibrary/media/Order/8110.49%20Chg%201.pdf |quote= [The page is titled “SW Mega Order”].
For example, Change Impact Analysis was clearly worded as a task of Applicants. This topic was moved, with considerable changes and reduction, to AC 00-69.
8110.110 Software Approval Guidelines, Continued 2010-01-27 to 2011-01-27 |url=https://www.faa.gov/documentLibrary/media/Notice/N%208110.110.pdf
https://www.faa.gov/search/?q=%22mega+order%22 Change 1 “the FAA “Mega Order” know in that previous revision as SW Mega Order
http://arsa.org/wp-content/uploads/2018/04/ARSA-Hotline-FDYTC-201803.pdf Order: Software Approval Guidelines Issued 03/29/2018 Document #: 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 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.
Synopsis of 2003 FAA National Software Conference Reno, Nevada • Sept. 16-19, 2003 |journal= Software Quality |issue = No.1 Winter 2004 By Mike Kress http://asq.org/software/2004/01/software-quality-v58-i01-full-issue.pdf FAA Order 8110.49 Software Approval Guidelines John Lewis Software Specialist FAA Aircraft Certification Service AIR 120 John Lewis is a computer engineer and software specialist for AIR 120 in Washington, D.C. He has experience in developing FAA Notices, Orders, TSO’s, and advisory circulars. He currently serves as secretary for RTCA SC 200 for IMA. John graduated from Virginia Tech with a BSEE and from Florida Tech with a Masters in Engineering Management and Business Administration. John reported on the consolidation of the 8110 series of FAA Notices into a single Mega-Order 8110.49 with 12 chapters.8110.49 incorporates 11 existing Notices and was coordinated within the FAA, industry and the public:
Most of the information in these chapters was preserved from the original release of the Mega-Order, with the exception of Chapter 4 on Software Conformity Inspection and Chapter 6 on PMA via licensing agreements, which were significantly revised.
FAA Order 8110.49 Software Approval Guidelines John Lewis Software Specialist FAA Aircraft Certification Service AIR 120 John Lewis is a computer engineer and software specialist for AIR 120 in Washington, D.C. He has experience in developing FAA Notices, Orders, TSO’s, and advisory circulars.He currently serves as secretary for RTCA SC 200 for IMA. John graduated from Virginia Tech with a BSEE and from Florida Tech with a Masters in Engineering Management and Business Administration. John reported on the consolidation of the 8110 series of FAA Notices into a single Mega-Order 8110.49 with 12 chapters.8110.49 incorporates 11 existing Notices and was coordinated within the FAA, industry and the public: Chapter Topic 1 Introduction 2 Software Review Process 3 LOFI* in software Projects 4 SW Conformity 5 Approval of FLS 6 PMA of FLS 7 Approval of UMS 8 Previously developed Software 9 Qualification of software tools 10 Software Changes in Legacy systems 11 SW Change Impact Analysis 12 Reused software life cycle data
- Level of FAA Involvement
Most of the information in these chapters was preserved from the original release of the mega-order, with the exception of Chapter 4 on Software conformity and Chapter 6 on PMA via licensing agreements, which were significantly revised.
Update of the Software Review Job Aid Leanna Rierson National Resource Specialist Leanna Rierson is the FAA’s chief scientist and Technical Advisor for Aircraft Computer Software since 1999. She has over 15 years’ experience in the computer/aviation industry.She graduated summa cum laude with a bachelor’s degree in electrical engineering. She also holds a master’s degree in software Engineering and is pursuing a doctorate. The Software Review Job Aid was first released in 1998 to provide a tool for standardized reviews by FAA engineers and designees and to improve the quality of the reviews. The purpose of the update is to address policy that has change and matured, correct errors, and implement lessons learned. The tool has four parts: Overview Software Review Tasks Stages of Involvement (SOI) Activities and Questions Summary of Compliance/Findings The Job Aid is built around the framework and requirements of DO-178B and the guidance of 8110.49. The stages of involvement are the classical R-D-C-I life cycle stages and the Aid provides guidance to the review of the artifacts of those stages. Many of the changes were editorial in nature but some added new material to accommodate developments in OO, the realtime development course, and the new 8110.49 order.
- ^ Dewi Daniels, Software Safety Limited. "The Boeing 737 MAX Accidents". SCSC. Safety-Critical Systems Club.
FAA Order 8110.49A (FAA 2018) specifies how to determine the level of certification authority involvement in a software project. Even under the previous regulatory regime before Boeing was given ODA, the FAA would not have participated directly in Stage of Involvement (SOI) audits for a Level C software project by an established supplier such as Rockwell Collins. In this instance, Boeing ODA would have performed the independent oversight.
- ^ Thomas Ferrell, Senior Certification Engineer and FAA DER at Joby Aviation (June 6, 2018). "Waning Vigilance or Needed Correction?". Retrieved 2023-04-09.
a number of the deleted topics have found there [sic] way into FAA AC 20-115D and the new 'software best practices' AC 00-69, both released in July of 2017. Even so, this is a significant shift in software design assurance policy. Orders are mandatory and govern how FAA personnel and their designees perform oversight of software development programs. ACs, as their name implies, are advisory only. First, the group within the FAA who owns this particular order had their hand slapped some years ago by the FAA legal department who viewed many of the requirements in the order as a backdoor way of imposing new regulations on Applicants seeking FAA approval. This set the stage for a rewrite that would divide 'Applicant direction' from 'FAA Employee mandate.' The second drive for change is the FAA's stated intent to shift from prescriptive compliance enforcement to a risk-based approach to ensuring aviation safety. Less regulation, more collaboration in the name of improving safety. Finally, there was significant push back on elements of the order such as its call out for use of something called the Software Job Aid for software reviews as this was contributing to an unhealthy shift from focusing on safety to focusing on process minutiae and paperwork (the so-called checklist mentality).
- ^ Mike Kress. "Synopsis Of 2003 FAA National Software Conference, Sept. 16-19, 2003, Reno, Nevada" (PDF). Software Quality (Winter 2003-2004): 7–10. Retrieved 2020-08-28.
John reported on the consolidation of the 8110 series of FAA Notices into a single Mega-Order 8110.49 with 12 chapters. 8110.49 incorporates 11 existing Notices and was coordinated within the FAA, industry and the public: