Acronym

19.1 Introduction

This chapter defines user-modifiable software (UMS) and provides several examples of such software. The chapter then explains certification guidance to consider when designing an airborne system that contains UMS. The last section focuses on the user (e.g., an airline) who will modify and maintain the software after system certification.

19.2 What Is User-Modifiable Software?

UMS is “software intended for modification without review by the certification authority, the airframe manufacturer, or the equipment vendor, if within the modification constraints established during the original certification project” [1]. ARINC 667-1, entitled Guidance for management of field loadable software, describes UMS as: “software intended for modification by the aircraft operator without review by the certification authority, the TC [type certificate] or STC [supplemental type certificate] holder, or the equipment manufacturer. Modifications may include modifications to data or executable code, or both” [2].^* There are various forms of UMS, including executable source code, aircraft-specific parameter settings, or databases [2]. The user is typically the aircraft operator or an airline. However, there may be situations where the user is the equipment customer (e.g., the aircraft manufacturer who installs a Technical Standard Order authorized unit, possibly as a commercial off-the-shelf unit, into their aircraft).

UMS is normally designed and initially approved as part of an airborne system that has both nonmodifiable software (e.g., flight controls, engine monitor, or navigation software) and modifiable software (e.g., airline modifiable checklists). The nonmodifiable software is not designed or intended to be changed by the user and has been the primary subject of this book. The UMS, on the other hand, is designed to be changed by the user utilizing approved procedures. The nonmodifiable software must be protected from any changes by the user. As will be discussed later in this chapter, there are several options for such protection.

During the initial certification, the system is designed to allow user modification and to protect the nonmodifiable software from user changes. Additionally, the UMS procedures are approved with the initial approval of the system. Since the UMS is outside the control of the equipment and aircraft manufacturers, it is typically treated as level E software during the initial certification. Some manufactures may treat it as level D, but that is for quality purposes rather than for certification.

Both DO-178C and Federal Aviation Administration (FAA) Order 8110.49 Chapter 7 address UMS. These documents concentrate on airborne software that is approved as part of type certification. They emphasize the need to design the system to be modifiable and to protect the nonmodifiable software from the UMS. Both documents also explain that UMS will not require involvement from the certification authority once it is approved as UMS. However, approval from the operational authority may still be required. Type certification and operational approval of the aircraft are typically granted by different divisions of the certification authority (e.g., in the United States, the FAA’s Aircraft Certification Offices grant the aircraft type certificate and the Flight Standards Offices grant aircraft operational approval). Therefore, from the user perspective, there may be two classes of UMS: (1) UMS that requires operational approval, and (2) UMS that does not require operational approval. The first category is classified as airline certifiable software or user certifiable software by some entities, since the user or airline is responsible for obtaining the operational authority’s approval [2].^†

19.3 Examples of UMS

The type and volume of UMS varies from aircraft to aircraft and airline to airline. A recent student of mine, who works for a major international airline, explained that one of the aircraft types that he manages has around 130 modifiable components. The following provides just a few examples of UMS.

Example 1: Aircraft Communications Addressing and Reporting System (ACARS). ACARS provides the ability to send messages between aircraft and ground stations. Users can optimize the system for the specific airline’s needs. Some of the functions that ACARS may perform are abnormal flight condition identification, repair and maintenance plan, e-mail messaging between crew and air traffic control, weather reports, and engine reports.

Example 2: Airplane Condition Monitoring System (ACMS). The ACMS allows the user to collect data necessary to make decisions about maintenance. Users can program the ACMS to log specific data for future analysis. The ACMS receives data from the airborne system, but it does not send data to the nonmodifiable software.

Example 3: Airline-specific checklists. Some airlines have programmable checklists for their specific operations. Such checklists may require operational approval by the regulatory authority but are not approved as part of the type certification.

Example 4: Modifiable circuit breaker panel. A modifiable circuit breaker panel allows nonrequired equipment (e.g., coffee pot, flight entertainment, or stereo) to be added after type certification. UMS is used to set the circuit breaker limits based on the user input.

Example 5: Cabin placard and lighting system. The placards and lighting system varies from airline to airline. Therefore, some airlines program these using UMS. This UMS requires operational approval but is not approved as part of the aircraft type certificate.

Example 6: Airline-Modifiable Information (AMI). The AMI is a data file that allows users to specify preferences for cabin management data, recording, report formatting, and services provided to the various passenger seating zones (e.g., first class, business class, and economy class).

19.4 Designing the System for UMS

Systems with UMS must be designed to be modifiable. DO-178C (sections 2.5.2 and 5.2.3), FAA Order 8110.49 (chapter 7), and the European Aviation Safety Agency (EASA) Certification Memorandum CM-SWCEH-002 (chapter 9) provide insight into how to design a system to accommodate UMS [1,3,4]. This section briefly summarizes that process using developer recommendations that are applicable during the initial certification of the system. The next section (Section 19.5) then provides user recommendations for those who will modify the software after certification.

Developer Recommendation 1: Consider the UMS aspects during the type certification and system development. The intended presence of UMS should be planned (in the Plan for Software Aspects of Certification [PSAC], Software Development Plan, and possibly the Software Verification Plan) and coordinated with the certification authority. UMS is normally explained as an additional consideration in the PSAC. Requirements and design should be in place to accommodate the UMS and to protect the nonmodifiable software. Such requirements must also be verified.

The UMS itself is not approved as part of the type certificate. As noted in DO-178C (section 7.2.2.b): “User-modifiable software is not included in the software product baseline, except for its associated protection and boundary components. Therefore, modifications may be made to usermodifiable software without affecting the configuration identification of the software product baseline” [1]. Basically, the system approved by the certification authority will be able to accommodate UMS, but will not include the UMS itself.

Developer Recommendation 2: Ensure that the UMS cannot adversely affect safetyrelated data. The UMS itself and changes to the UMS must not impact any of the following safety-related data: safety margins, operational capability of the aircraft or engine, flight crew workload, nonmodifiable components, protective mechanisms, software boundaries (such as preverified ranges of data) [3]. These should be considered as part of the system safety assessment process. If any of the safety-related data can be impacted by the UMS or a change to the UMS, the software should not be classified as UMS.

Developer Recommendation 3: Involve appropriate stakeholders. Since UMS crosses the airworthiness and operational boundaries (i.e., aircraft and system design and user operation), it is important to involve the appropriate stakeholders, including the certification authority, operational approval authority, aircraft manufacturer, systems developer, software developer, safety personnel, and users. Coordination with these entities early and throughout the development is essential to success.

Developer Recommendation 4: Put measures in place to protect nonmodifiable software. DO-178C section 5.2.3.a emphasizes that “the non-modifiable component should be protected from the modifiable component” [1].^* The protection should be robust during operation of the UMS and when modifying the UMS. Protection may be implemented via hardware (e.g., separate processors), software (e.g., a software partition), tools (e.g., a user interface that limits what can be entered), or a combination of the hardware, software, and tools [1]. One example of protection is a monitor function embedded in the core software to prevent any changes to nonmodifiable software. The monitor and the nonmodifiable software are inaccessible to the user [2]. The development assurance level of the protective mechanism should be the same as the most severe failure condition in the system that the UMS could impact [3]. For example, if the airborne (nonmodifiable) software is level A, and software partitioning is used to protect the nonmodifiable software, the software partition needs to be developed to level A. (Chapter 21 provides information on partitioning.)

Developer Recommendation 5: Evaluate tools used to enforce protection of the nonmodifiable software. Most systems that accommodate UMS provide a tool or toolset for users to modify the UMS. The impact of the tool on nonmodifiable software needs to be considered. During the initial development of the system, the tool use, control, design, functionality (modifications to UMS), and maintenance should be considered. The tool must be robustly designed to prevent incorrect entries by the user. Order 8110.49 section 7.6.b even goes as far as to state: “Software forming a component of the tool and used in the protective function should be developed to the software level of the most severe failure condition of the system, as determined by a system safety assessment” [3].

There are cases when the tool may need to be qualified. Order 8110.49 section 7.6.c encourages tool qualification “and approval of procedures to use and maintain the tool” [3]. Unfortunately, the guidance on when the tool requires qualification is somewhat unclear. DO-178C section 12.2 provides guidelines for when tools used in DO-178C processes should be qualified and to what level. However, for UMS, this is not without ambiguity (since tools to enable UMS do not normally reduce, automate, or eliminate a DO-178C process). I generally recommend that if the protection mechanism relies on the tool alone, the tool should be qualified; conversely, if the tool’s impact is mitigated by system architecture (e.g., the embedded monitor), qualification may not be needed. Even if the tool does not require qualification, it should still be specified, verified, and configuration controlled. The determination of whether or not to qualify the tool must be coordinated with the certification authority. (See Chapter 13 for more information on tool qualification.)

Developer Recommendation 6: Consider displayed data. FAA Order 8110.49 (section 7.3) explains that any data displayed to the flight crew that were driven by UMS should be clearly noted to the crew as advisory or should have operational approval. Basically, it is important that the pilots understand the integrity of the data they observe in order to ensure that they use it properly. This type of data needs to be closely coordinated with flight test and human factors personnel during the initial certification of the aircraft.

Developer Recommendation 7: Prevent inadvertent and unauthorized changes. The UMS should only be modified by authorized personnel on the ground using the approved procedure. During the initial certification, it must be ensured that the approved procedure is the only way to change the UMS [3].

Developer Recommendation 8: Inform users of all UMS software. The type certificate holder should inform the aircraft user of all UMS on the aircraft. Additionally, approved procedures for changing the UMS should be clearly documented and provided to the users. Such procedures should be repeatable and under configuration control.

Developer Recommendation 9: Identify constraints and procedures for the users. The initial system development should clearly document constraints and procedures to ensure that users have adequate data to make modifications to UMS without impacting aircraft safety. DO-178C section 11.16.j indicates that the Software Configuration Index should identify “procedures, methods, and tools for making modifications to the user-modifiable software, if any” [1]. Such procedures need to be provided to the users. Interestingly, airline representatives indicate this is an area they frequently find lacking. Oftentimes, airlines receive unclear or incomplete documentation from the aircraft or systems manufactures. This causes airline employees to make assumptions which may or may not be accurate. This is one of the reasons why 11.16.j was added to DO-178C.

Additionally, any changes that impact the UMS should be clearly communicated to the users (e.g., changes to the system which accommodates the UMS, updates to the approved procedures, or modifications to the tool used to change the UMS). Airline operators indicate that they rarely receive updated procedures when the system, procedures, or tool are updated.

19.5 Modifying and Maintaining UMS

Once the software is approved under the type certificate as UMS, it is the user’s responsibility to manage the UMS. This includes management of the environment, the changes to the UMS, and the overall aircraft configuration. The available guidance for modifying and maintaining UMS is very sparse; therefore, this section provides some recommendations for users who are required to manage UMS. Since the types of UMS vary greatly, these recommendations are general. The specific details must be worked out among the project-specific stakeholders.

User Recommendation 1: Ensure agreements are in place. Users should ensure that agreements are in place (e.g., technical service agreement) with the aircraft and/or equipment manufacturer(s) to obtain all of the necessary data, tools, and support.

User Recommendation 2: Manage the configuration of all UMS on the aircraft. It is important to know what version of software (UMS, as well as nonmodifiable software) is installed on each aircraft. Maintenance records should identify when specific software versions or part numbers are installed.

User Recommendation 3: Manage the environment of each UMS component. Each UMS component will have an environment to change and modify the UMS. The tools that comprise the environment are typically provided by the equipment manufacturer or aircraft manufacturer (examples included software editor, compiler, part number generator, and media set creation tools) [2]. The supporting tools should be under configuration management. If updated tools are provided by the equipment or aircraft manufacturer, the impact of these tools should be assessed prior to their use. Understanding this impact may require coordination with the equipment or aircraft manufacturer.

User Recommendation 4: Modify the software using constraints and procedures provided. As noted in Developer Recommendation #9, the equipment or aircraft manufacturer should identify any constraints and procedures to be followed by the user. These constraints and procedures are referenced by the type certification data (i.e., is approved as part of the type certificate). Therefore, the user is expected to follow the procedures. If the procedures are missing or unclear, the user should coordinate with the supplier. As noted in Order 8110.49 section 7.8, failure to follow the approved procedures could have serious consequences, including potential withdrawal of the aircraft type certificate [3].

User Recommendation 5: Make modifications to UMS using an organized and repeatable process. The modifications to UMS should be planned and driven by documented requirements. The configuration management process for the UMS modification should include change control (to ensure changes are authorized), change tracking (to ensure the changes are documented), configuration identification (update to software version or part number, as well as the supporting documentation), release, and archival. The modification should be verified (preferably using some testing) to meet the requirements and monitored by quality assurance. While the UMS is typically not required to comply with DO-178C, consider using a DO-178C-like process (such as DO-178C level D). Such a process helps to ensure the functionality, configuration management, and quality assurance of the UMS. Whatever process is used, it should be auditable.

User Recommendation 6: If needed, obtain operational approval of the UMS. As previously noted, some UMS may require approval by the operational authority, even though it may not need type certification authority review. Such approval should be obtained prior to using the modified UMS for flight operation.

User Recommendation 7: Ensure proper installation of the modified UMS on the aircraft. Once the appropriate approval is granted (e.g., operational approval), it should be ensured that the approved version of the UMS is actually the version installed on the aircraft. As noted in User Recommendation #2, maintenance records should be kept up to date.