18 Field-Loadable Software
Acronym
| CD | compact disk |
| DAL | development assurance level |
| DVD | digital video disk |
| FAA | Federal Aviation Administration |
| FADEC | full authority digital engine control |
| FLS | field-loadable software |
| LAN | local area network |
| LRM | line replaceable module |
| LRU | line replaceable unit |
| PMAT | portable multi-purpose access terminal |
| PSAC | Plan for Software Aspects of Certification |
18.1 Introduction
On my very first day on the job at the Federal Aviation Administration (FAA) Headquarters, as the national software program manager, I was introduced to the issues surrounding field-loadable software (FLS). I sometimes wonder if it was some kind of mean initiation by my coworkers. They were probably standing on the other side of the cubicle laughing their heads off…
It started out as a typical first day. Having just moved from Kansas to the Washington, DC, area, I figured out how to ride the Virginia Railway Express train; I also found the right floor of the FAA Headquarters building, got my badge, filled out theplethora of paperwork, met everyone intheavionics branch, and was ushered to my cubicle. As I was messing with my phone to set up voicemail, it rang. I figured it was the administrative assistant apprising me of something we forgot to cover. Instead it was a lawyer—a very loud and angry woman from one of the alphabet soup aviation organizations in Washington, DC. She began chewing me out for the FAA’s lack of responsiveness on the need for guidance on part manufacturer approval for FLS, etc. etc. etc. I kept reminding myself: “We’re not in Kansas anymore, Toto.”
18.2 What Is Field-Loadable Software?
DO-178C describes FLS as “software that can be loaded without removing the system or equipment from its installation” [1]. It is loaded into the aircraft or engine equipment using some kind of data port without the need to open the unit. FAA also treats software loaded through a data port at qualified labs (e.g., repair stations or service centers) as FLS [2]. Essentially, FLS is contrasted with factory-loadable software, where the line replaceable unit (LRU) or line replaceable module (LRM) may require the unit seal to be broken in order to load the software (e.g., flashing).
The media used to load FLS changes with time. In the early 1990s, 3.5-inch diskettes were used. For example, the original Boeing 777 carried around binders full of floppy disks. The technology has moved on to compact disks (CDs), digital video disks (DVDs), thumb drives, mass storage devices, and even local area networks (LANs).
As long as the appropriate safety measures are taken and the software is approved by the certification authorities, nearly any kind of equipment can be field-loadable—all the way from flight controls and engine controls to navigational and communication systems to flight management systems and traffic collision avoidance systems. Establishing processes and developing systems to be field-loadable are not trivial tasks. There are numerous regulations (e.g., part marking and approved repair station regulations) to consider at multiple levels (e.g., the equipment level, the aircraft level, the flight operations level). However, FLS is very common in today’s aviation industry.
It should be noted that while aeronautical databases (e.g., navigational or terrain databases) are field-loadable, they are not treated the same as FLS. In general, aeronautical databases are covered by DO-200A guidance, whereas DO-178C guidance applies to FLS. Chapter 23 provides specific information on aeronautical databases.
18.3 Benefits of Field-Loadable Software
FLS allows more efficient maintenance processes that meet the needs of the worldwide aircraft fleets. Rather than shipping LRUs or LRMs, pulling equipment out of the aircraft to upgrade, and maintaining a large inventory of expensive equipment, software can be distributed and loaded in the aircraft. This allows less downtime for the aircraft, helping meet the needs of the airlines and the flying public.
18.4 Challenges of Field-Loadable Software
As with nearly everything in life, the benefits do not come without struggle. There are several challenges to address when implementing processes that impact lives across the world. There are also multiple stakeholders involved in managing the challenges, including software and equipment developers, aircraft or engine manufacturers, airlines, and certification authorities. Some of the challenges include the following:
Designing the system to be safe, which involves protecting from unauthorized changes, performing integrity checks, etc.
Managing configuration at multiple levels (software, equipment, and aircraft or engine) to ensure (1) the approved software is installed in approved equipment and (2) the approved equipment is installed in the certified aircraft or engine.
Applying equipment-oriented regulations to software (e.g., part marking regulations). Most of the regulations are written for the aircraft or engines and their installed systems. Because FLS becomes a stand-alone part, such regulations require interpretation to apply them at the software level.
Ensuring that all loaded software is approved by the certification authority and that no unapproved parts are installed on the aircraft or engine.
Ensuring that there are no security issues (viruses, hackers, etc.), particularly when software is transferred or loaded using a network.
Verifying that the software is completely loaded without corruption.
Disabling loading capability during flight.
Managing compatibility with other equipment, when software is updated. Updates to software could impact equipment that interfaces with the software, so equipment that interacts with the software must also be evaluated.
18.5 Developing and Loading Field-Loadable Software
Fortunately, after two decades of experience with FLS, many of the challenges have been overcome. FLS is routinely used now. This section considers four areas to be considered when developing FLS: (1) developing systems to be field-loadable, (2) developing FLS, (3) loading FLS, and (4) modifying FLS.
18.5.1 Developing the System to Be Field-Loadable
Designing FLS is not just about the software. The system itself must be designed to safely load the software. DO-178C section 2.5.5 points out several items to consider when developing a system to safely load software in the field, including the following [1]:
Protection from inadvertent loading (e.g., loading during flight). This may be through hardware, software, or a combination of hardware and software mechanisms. The safety assessment must analyze the impact of the detection mechanism’s failure. Unless justified in the safety assessment, the detection mechanism is normally designed to the highest development assurance level (DAL) of the software being loaded.
Detection of failed, partial, or corrupted loads. Per DO-178C section 2.5.5.b, if a safety or default mode is entered when detecting a partial, corrupted, or inappropriate FLS load, “then each partitioned component of the system should have safety-related requirements specified for recovery to and operation in this mode” [1].
Determination of inappropriate (incorrect) software loads, for example, inadvertently loading the wrong files(s) or not loading the software at all.
Integrity of the display mechanism used to verify the aircraft configuration (i.e., to confirm the right software is loaded). The loss or corruption of the ability to display the software part identification also needs to be considered. This is only considered if the on-aircraft display system is used to verify software load.
Addressing these details requires system-level requirements and design and the involvement of the system safety personnel. It is advisable to involve safety personnel early. I recently discovered a flaw in one company’s systemlevel field loading strategy while reviewing the Plan for Software Aspects of Certifiction (PSAC). The PSAC is prepared after the systems architecture is established and initial safety assessment is performed. This discovery led to a system-level redesign late in the project that could have been prevented if safety had been involved earlier.
Another system-level consideration is the part marking approach for FLS. Some manufactures update the hardware part number whenever FLS is loaded. Others manage the hardware and software part numbers separately. Either approach is acceptable; it just needs to be established as part of the system design.
18.5.2 Developing the Field-Loadable Software
Like any other software, FLS is developed to comply with DO-178C and/or applicable supplements. Additionally, the FLS must be designed to support the field loading. This typically means implementing an integrity check (e.g., a cyclic redundancy check), designing the software to address the issues noted earlier, and developing a field loading application (oftentimes, a separate application). Many applicants design their systems to comply with ARINC 615, which provides both “general and specific design guidance for the development of software data loading equipment for all types of aircraft” [3]. Additionally, ARINC 644 may be applied for the maintenance terminal. ARINC 644 provides guidance for development of a portable multi-purpose access terminal used by airlines [4].
Planning is an important part of any DO-178C effort. This is especially true of FLS. The plans describe the development, verification, configuration management, quality assurance, and certification liaison aspects of the FLS. The PSAC explains the plans for FLS, ensures that the issues noted earlier are addressed, explains the utilized integrity check and its sufficiency for the given software level (i.e., accuracy), and describes the configuration management details for the FLS development and verification. The Software Development Plan builds upon the PSAC contents by providing details for the FLS development team; it includes an explanation of the protective mechanisms, integrity checks, and any special standards that apply (e.g., ARINC 615). The Software Verification Plan includes details to ensure that the FLS, the integrity checks, and the protective mechanisms are verified and tested. The Software Configuration Management Plan discusses the configuration management process for the FLS. During the development phase, configuration management will probably be the same as non-field-loadable software, but there will need to be some explanation of who is responsible for configuration management after development (this is normally explained in the PSAC as well as the Software Configuration Management Plan).
Once the plans are developed, they should be followed, just as they are for any other airborne software.
18.5.3 Loading the Field-Loadable Software
After the FLS is developed and approved by the certification authority, it can be loaded. Most applicants use an integrity check (e.g., a cyclic redundancy check) to ensure the software is not corrupted during the loading process. The adequacy of the integrity check should be confirmed during the development. The accuracy is typically determined by the integrity check’s algorithm and the size of the file(s) being protected. For large files, it may be necessary to use higher bit integrity checks (e.g., 32 bits vs. 8 bits or 16 bits) or divide the data into smaller packages and use additional integrity checks. The probability of error should be consistent with the level of the software being loaded.
If a reliable integrity check is not used, the equipment used to load the FLS may require some kind of qualification (e.g., the data loader software may need to be developed using DO-178C or DO-330 and the software may only be loaded using the approved data loader). This approach is rarely used anymore.
Per FAA Order 8110.49, the FLS loading process should also ensure the following [2]:
The software being loaded has been approved by the certification authority.
The loading procedure has been approved and is followed. (As noted in Chapter 10, loading procedures are normally referenced or included in the Software Configuration Index. If they are not the responsibility of the software team, they may be included in systemlevel or aircraft-level documentation. If this is the case, the Software Configuration Index should explain it.)
The software is approved for the hardware it is being loaded on (i.e., it is an approved hardware/software configuration).
The software is approved for the aircraft or engine it is being loaded on (i.e., approved aircraft or engine configuration). This includes ensuring that any redundant parts on the aircraft or engine are appropriately configured; for example, if there are two full authority digital engine control (FADECs), both may need to be loaded when upgraded software is loaded, unless the aircraft or engine configuration allows one FADEC to have the new software version and the other FADEC the older software version.
The software is completely loaded without error. This is typically done by confirming that the cyclic redundancy check matches what is provided in the load instructions.
The software part number (including version number, if applicable) is confirmed after the load.
The change in configuration is documented in the aircraft or engine configuration records and any other applicable maintenance records.
18.5.4 Modifying the Field-Loadable Software
One of the motivators for FLS is that the software can be modified and loaded without having to return the equipment to the manufacturer.
When FLS is modified, it should go through a change impact analysis process, like any other airborne software. All changed and impacted data and code are re-verified. (See Chapter 10 for information on change impact analysis.) The software must be re-verified for the target hardware and aircraft or engine configuration intended for installation. And, the modified software must be approved by the certification authority for the equipment and aircraft or engine configuration prior to installation.
18.6 Summary
FLS is commonplace in today’s aviation industry. However, the system and software design, loading considerations, and configuration management must still be carefully managed, particularly as newcomers come to the market and as loading approaches advance.
References
1. RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification (Washington, DC: RTCA, Inc., December 2011).
2. Federal Aviation Administration, Software Approval Guidelines, Order 8110.49 (Washington, DC: Federal Aviation Administration, Change 1, September 2011).
3. Aeronautical Radio, Inc., Software data loader using ethernet interface, ARINC REPORT 615A-3 (Annapolis, MD: Airlines Electronic Engineering Committee, June 2007).
4. Aeronautical Radio, Inc., Portable multi-purpose access terminal (PMAT), ARINC REPORT 644A (Annapolis, MD: Airlines Electronic Engineering Committee, August 1996).