1. FLS & UMS Software Standardization Conference
Dennis Wallace, Software Technical Specialist
July 2005

2. Order 8110.49 Approval of Field-Loadable Software (FLS)
Approval of FLS by Finding Identically through the Parts Manufacturer Approval (PMA) Process
Approval of Airborne Systems and Equipment Containing User-Modifiable Software (UMS)

3. DO-178B References to FLS
Field-Loadable Software (FLS) and Loading References: - System Design: Sections 2.0 and SW Process: 6.4.3a., 7.2.1d., e.; 7.2.8, g. - SW Data: 11.1g., 11.2c.(3), 11.4b.(8), (9); g., 11.11, 11.15, 11.16, g.

4. Definitions Field- Software that can be loaded without
Loadable removal of the equipment from the
Software aircraft installation.
User- Software intended for modification
Modifiable by the airplane operator without review
Software by the certification authority, air framer,
or equipment manufacturer.
Option- Software that contains approved and
Selectable validated components that may be
Software activated by the user.

5. Examples Field-Loadable Software User-Modifiable Software
Engine Control Software
Flight Control Software
Boeing 777 Has Many Systems With FLS
User-Modifiable Software
Non-Required, Airline-Specific Electronic Checklists
Option-Selectable Software
Selection Of Sensors For An FMS

6. Approval of FLS
Developing 3
Considerations
Loading
Changing

7. Approval of FLS Developing
Meets 178B Objectives
Considers 178B Paragraph 2.5
Verify SW on Target HW
Configuration Management
Considering Redundant Parts

8. Approval of FLS Loading
Data
Integrity Check?
Consider
loading system
during SW verif.
Approve
onboard
loading system. Y
Verify SW part
number onboard
the aircraft.

9. Approval of FLS Changing
Is FLS
also UMS?
Use guidelines
for UMS Y
Change Impact Analysis

10. Installation of FLS Documentation to Include the Following Items:
a) Aircraft and HW Applicability
b) Verification Procedures
c) Post Load Verification and/or Procedures
d) Actions for Unsuccessful Load
e) Reference to Approved Loading Procedures
f) Maintenance Record Entry Procedures
g) Reference to AFM, AFMS, or Ops Manual
Record keeping system in place

11. Maintenance & Part Marking of FLS
Maintenance Procedure in Aircraft Maintenance Manual
Procedure to Include Reading of SW Version
Procedure to Include Part Number in Maintenance Records
Changes Reflected in Appropriate Manual or Logbook

12. Maintenance & Part Marking of FLS
LRU P/N:
HW P/N:
SW P/N:
Procedure to Verify
SW Load
Procedure to Verify
Nameplate & SW Load

13. Parts Manufacturer Approval of Field-loadable Software

14. Purpose Provides Guidelines for Approving FLS Through PMA
Limited to Identicality With or Without a Licensing Agreement
Does Not Cover Test and Computation

15. Technical Information
FLS Is Beneficial to Airlines and Applicants
Order , “PMA Procedures,” Does Not Specifically Address Software
CFRs , 303, and 305 Do Not Specifically Address Software
Data Being Loaded Is Approved, Not Media

16. Procedures
Follow Part 21 and O in Conjunction With the Software-Specific Procedures in O O
Part 21 O

17. Procedures 2 1 Design Change Design Approval w/ Licensing w/ Licensing
Agreement
Design Approval
w/ Licensing
Agreement 3
Design
Approval w/o
Licensing
Agreement 4
Design Change
w/o Licensing
Agreement

18. Design Approval Identicality With Licensing Agreement
Reference O , 8(a)(3)(a)
FLS Should Be Approved Through TC, STC, ATC
FLS Should Be Installed Via Service Bulletin Or Similar Means
Configuration Management Process Should Be In Place To Assure Software Part Number, Hardware Part Number, Aircraft Series, etc. Are Accurate

19. Design Change Identicality With Licensing Agreement
Reference O , 8(h)(5)
Applicant Should Coordinate Change With TC, STC, ATC Holder
Change Impact Analysis
Determine Minor/Major Classification
Major change  O (h)(5)(a)
Minor change  O (h)(5)

20. Design Approval Identicality W/o Licensing Agreement
Order , 8(a)(3)(b) - Parts Must Be Identical In “All Respects”
FLS Should Be Identical To The Software On The TC, STC, ATC Approval
Bit-by-bit Comparison
Evidence of Identical Type Design Data - DO-178B Section 9.4

21. Design Change Identicality w/o Licensing Agreement
Change Considered Major
Reference Order , 8(h)(5)(a)

22. Summary Chapter 5 - Approval of FLS
Chapter 6 – Approval of FLS by Finding Identicality through PMA
Reference DO-178B, Part 21, and Order

23. Approval of Airborne Systems and Equipment Containing User-modifiable Software

24. Purpose
To Provide Guidelines To ACO Engineers and DERs For Approval of Systems With User-Modifiable Software (UMS)
To Encourage Working With Flight Standards Personnel:
Maintenance Inspectors, Avionics Inspectors, and Operations Inspectors

25. DO-178B References to UMS
User-Modifiable Software (UMS) References: - System Design: Sections 2.0 and 2.4a.- d. - SW Process: 5.2.3, 7.2.2b. - SW Data: 11.1g., 11.10g., 11.20g.

26. Technical Information
Biggest Concerns:
Corruption of Non-modifiable, Safety-related Software
Change Control Problems in the Field
Compelling but Invalid Information in the Cockpit

27. Definitions User- Software intended for modification
Modifiable by the airplane operator without review
Software by the certification authority, airframer,
or equipment manufacturer.
Option- Software that contains approved and
Selectable validated components that may be
Software activated by the user.
Field- Software that can be loaded without
Loadable removal of the equipment from the
Software aircraft installation.

28. Definitions UMS OSS FLS
The definitions are not mutually exclusive. One type may also be another type, or not.
FLS

29. Databases, etc? What About Navigation or Terrain Databases?
What About Programmable Waypoints or Other Programmable Database-Like Items?

30. Order Addresses UMS Only
5. SCOPE. This notice applies to user-modifiable software only. The guidance provided below does not apply to option-selectable software nor field-loadable software, except where such software is also user-modifiable.

31. Earlier Version of DO-178 (Section 6)
Earlier Versions of DO-178 Contain No Guidance for User-Modifiable Software
Use DO-178B Guidance for The User-Modifiable Portions
6. THE USE OF EARLIER VERSIONS OF RTCA/DO Versions of RTCA/DO-178 earlier than revision B do not provide any guidance regarding user-modifiable software, and should not be used as a means of compliance for user-modifiable software approvals. For software developed to earlier guidelines, at least the user-modifiable component, the protective schemes, and the affected aspects of the non-modifiable component should be developed to RTCA/DO-178B or other acceptable equivalent means as agreed to between the applicant and the Aircraft Certification Office (ACO). DO-178B provides guidance for upgrading software from earlier standards.

32. Safety Considerations
Once Certified as UMS There is No Certification Authority Oversight
Anomalous behavior of user-modifiable software should have no effect of the operational capability or the aircraft or increase crew workload

33. Safety Considerations
Modifications Should Have No Effect On
Safety
Margins
Crew
Workload
Operational
Capability
Non-
Modifiable
Components
Software
Boundaries
Protective
Mechanisms

34. Safety Considerations
Effects Must Be Bounded

35. Identification of Displayed Data
Obvious or Explicit Indication That the Data is Not Cert Authority Approved
8. IDENTIFICATION OF DISPLAYED DATA. Where information is displayed to the flight crew and is derived from user-modifiable software, the information should be identified in such a way to indicate that it has not been reviewed or approved by the regulatory authority. In the event that the design or inherent nature of the equipment or user-modifiable component makes the distinction between approved and unapproved information so readily apparent to the flight crew that errors distinguishing the two types of information are reasonably precluded, explicit identification may not be required. Such identification, where required, should be provided by the non-modifiable component and should allow the flight crew to clearly distinguish between information reviewed or approved by the regulatory authority and information not reviewed or approved.

36. Performance Parameters
Modifications to Provide or Revise Performance Parameters Requires Certification Authority Review and Approval
Examples of Parameters
Safety margins
Operational capabilities
Crew workload
MAJOR Change

37. Performance Parameters
Modifications to Provide or Revise Performance Parameters Requires Certification Authority Review and Approval
Examples of Parameters
Safety margins
Operational capabilities
Crew workload
9. MODIFICATION OF AIRPLANE (AIRCRAFT) PERFORMANCE PARAMETERS. Modifications that would affect the safety margins or operational capability of the aircraft or increase crew workload include modifications of data displayed or otherwise provided to the flight crew for use in determining airplane performance parameters. Modification of data displayed or otherwise provided to the flight crew for use in determining airplane performance parameters should require certification authority review and approval. Modification of the user-modifiable component to provide or revise these parameters, regardless of whether they are provided as primary or advisory information, should require certification authority review and approval. Such a change warrants rescinding the classification of the software as user-modifiable, and requires design approval and a part number revision.

38. Protection UMS Components Shouldn’t Affect Non-UMS Components
Assure Protection Is Developed to at Least Same Level of Robustness Required of the Most Robust Non-UMS Component

39. Protection Two Considerations Operating In: Changing Out:
Protection in the design and operation
Changing Out:
Protection during modification

40. Protection Examples Partitioning Hardware Modes Encoding Tools
Modifications
Loading Protection
Protection should be developed to at least the level of robustness required for the most robust non-modifiable component
The protection should be such that any modification or failure of the user-modifiable software shall no result in loss of protection
Protection integrity cannot depend on any activities being accomplished by the user.
Examples:
The protective scheme can be breached accidentally under reasonable probable circumstances (Programming error)
The protective scheme can be breached intentionally without undue effort when using specified protective tools (skirting approved procedures)

41. Protection Accidental Breach Intentional Breach Protect Against
Low Likelihood Under Reasonably Probable Circumstances
(Subjective statement of probability - not a xx.1309 definition)
Intentional Breach
Low Likelihood Without Undue Effort
10. PROTECTION
Some examples illustrating the improper application of protection or partitioning follow:
a. The protective scheme, including partitioning, can be breached accidentally under reasonably probable circumstances (such as committing a programming error) during user modification.
Protect Against
Breaches

42. Tools Used to Enforce Protection
Not DO-178B Qualified Tools?
Demonstrated As the Only Means To Modify UMS Component
Tool design - Understand the features and functions of the tool.
Use - approved procedures identifying how
Control - version and usage
Modifications/Maintenance - requalification due to changes

43. Tools Requires Review and Approval Of: Use Control Tool Design
Tool design - Understand the features and functions of the tool.
Use - approved procedures identifying how
Control - version and usage
Modifications/Maintenance - requalification due to changes
Modifications
Maintenance

44. Design Approval of Tools
By ACO Engineer
11. TOOLS USED TO PROTECT NON-MODIFIABLE COMPONENTS
a. approval of the tool design by that part of the regulatory authority responsible for the approval of the equipment design, and

45. Maintenance Approval of Tools
Jointly By:
ACO Engineer
Operational Authority
Maintenance Authority
11. TOOLS USED TO PROTECT NON-MODIFIABLE COMPONENTS
a. approval of the tool design by that part of the regulatory authority responsible for the approval of the equipment design, and

46. Software Configuration Software Accomplishment
Data Requirements
PSAC
Design Data
Software Configuration
Index
Procedures identify to FAA
Each computer which contains user-modifiable software.
Approved procedures to modify user-modifiable software components
That approved procedures have been followed
Software Accomplishment
Summary

47. Other Considerations
User Follows the Approved Procedures for Modifications to UMS
User Responsible for Configuration Management, Quality Assurance, and Verification of the Software
Changing Anything Besides UMS Can Result in Certificate Being Rescinded
Procedures identify to FAA
Each computer which contains user-modifiable software.
Approved procedures to modify user-modifiable software components
That approved procedures have been followed

48. Summary
Order Provides Guidelines For Approval of Systems & Equipment Containing UMS
Provides Guidelines On:
Safety Considerations & Safety Parameters
Protection
Tools
Data Requirements
Working With FSDO Personnel
Procedures identify to FAA
Each computer which contains user-modifiable software.
Approved procedures to modify user-modifiable software components
That approved procedures have been followed