1
Introduction
STUDY OVERVIEW
“Software” is a digital representation of a sequence of logical decisions intended for execution in a computational environment.
Whether the software is intended to serve as a stand-alone data processing application with a human-computer interface or whether it is embedded code integrated into a weapon system hardware platform, software does not age, wear out, or suffer from fatigue. “Unlike hardware, software never dies.”1 Software can be recorded and stored as a backup, and this backup can be used at any time in the future absent storage failures to reinstantiate as many exact copies of the software on as many copies of the target hardware as may be desired. Rather than return a system to its original state, much of software sustainment is involved with the design, development, and delivery of new functionality that offers incremental improvements over previous versions and recoding to fix issues or problems in the original software such as discovered defects and vulnerabilities.
The U.S. Air Force (USAF) uses the term “weapon system” broadly. A weapon system could be a fighter aircraft, a bomber aircraft, or an air-to-air missile. But the USAF also categorizes command and control systems, such as the Air Operations Center and Intelligence, Surveillance and Reconnaissance (ISR) systems, many
___________________
1 See Department of Defense (DoD) Defense Science Board, 2018, “Design and Acquisition of Software for Defense Systems,” https://dsb.cto.mil/reports/2010s/DSB_SWA_Report_FINALdelivered2-21-2018.pdf, accessed June 2, 2020.
space systems, and unmanned aerial vehicles (UAVs), as weapon systems. In discussing embedded software for weapons systems, this report is specifically looking at software that resides in specialized computers that are part of these systems. A key difference here is that embedded software generally contains major portions of custom-written code for these specialized computers, often with real-time or near-real-time requirements. This report is not specifically addressing business and accounting software or software that might reside on an individual’s personal laptop or tablet as a Web application or resident program.
There are very few systems in the USAF today that do not have at least a minimal amount of software as part of the overall design. Personnel systems, business systems, intelligence, communication, surveillance, spacecraft, and aircraft all depend on some measure of software for their operations. These software packages include commercial-off-the-shelf (COTS)2 software, open source applications, and custom-built software. Each hardware system’s software requires some degree of sustainment for the life cycle of the system. For hardware systems, the purpose of sustainment operations is to restore the hardware system to a like-new capability: to reverse the effects of aging, wear, corrosion, or damage on a system. The overall objective of hardware maintenance is to reset the state of the system to a prior configuration condition. The objective of software sustainment is fundamentally different from that of hardware sustainment. Commercial software sustainment requires installing the vendor’s latest version, while custom-built software sustainment requires writing new code while simultaneously correcting existing code.
This study’s effort was directed to “conduct an in-depth study to examine and provide recommendations on how the Air Force can improve planning, implementation, or other aspects of software sustainment and maintenance of weapons systems.” The term “weapons system” covers a broad number of systems, such as the Operational Flight Program (OFP) on an aircraft and the analytic tools for the Distributed Common Ground System (DCGS). The study statement of task (see Appendix A) further refines the effort to “assess how software that is embedded within weapon platforms is currently sustained within the USAF.” Given this context, this study concentrates on the sustainment of software in embedded systems such as those on the F-15 or MC-130J Commando II cargo plane OFP.
The members of the study committee (see Appendix B) met five times to hear presentations, engage in questions and answers, as well as hold panel discussions with representatives from the three Software Engineering Group (SWEG) locations. To collect more direct knowledge of the SWEG operational teams, committee members attended meetings and tours at two of the SWEGs: Hill Air Force Base
___________________
2 See NIST Computer Security Resource Center, Glossary: “Commercial-Off-the-Shelf,” https://csrc.nist.gov/glossary/term/commercial_off_the_shelf, accessed June 2, 2020.
(AFB) in Ogden, Utah, and Warner-Robins AFB in Warner-Robins, Georgia. The agendas for each of the meetings appear in Appendix D of this report.
HISTORICAL CONTEXT
The current state of software sustainment is more an artifact of avionics architecture evolution than the commercial industry’s software and computer progression (Figure 1.1). In the 1960s, avionics were predominately analog, using a distributed architecture. The limited number of avionics systems on an aircraft used dedicated wiring for operation. The 1960s avionics architecture sustainment concept logically matched that of other aircraft components, such as the hydraulics, landing gear, and control surfaces. A broken avionics component, such as radar, would be taken off the aircraft, sent to a back-shop for repair on a dedicated test stand, and then returned to the supply chain. Specifically, avionics boxes were viewed as a commodity, like aircraft components. This similarity in sustainment worked, as the avionics components generally lacked any measurable software content.
As avionics line replaceable units (LRUs) became more digital in their design, the distributed analog architecture was followed by a similar architecture, replacing the analog with digital. The distributed digital architectures enable the capability
of one source transmitting to multiple receivers, while retaining the dedicated wiring. Although the avionics components were becoming more digital, the degree of software was minimal. As such, there was not the need or motivation to change the sustainment concept. Avionics continued to be maintained, as if they were still like other aircraft components.
The introduction of the MIL-STD-1553 data bus in the 1990s facilitated the change to a federated digital architecture: “The federated digital architecture allows for a more interrelated functionality between systems that were previously independent in architectures of the past.”3 The federated architecture brought with it a marked increase in the avionics software content and exponential growth for the future (Figure 1.2).4,5 Each component in the federated architecture had its own independent operating system and software. On an aircraft, there could be several programming languages used on the different avionics systems, requiring each to have a sustainment concept specific to the components. This complicates the skills sets and support tools necessary to maintain a complex weapon system.
Viewing avionics subsystems as independent components on a weapon system perpetuated a sustainment approach that mirrored other nonavionics components such as landing gear, hydraulics, and engines. Development and sustainment of an individual subsystem would be performed typically in a System Integration Laboratory (SIL). As an example, for the B-2 during development, there were SILs for the radar, navigation, defensive, and weapon systems. While there was a marked increase in the software content, the previous sustainment concept to treat software as other aircraft components continued. Each avionics system had its own dedicated repair station, where both hardware and software issues were resolved. Also, the degree to which capability was improved through software was minimal.
The current trend is integrated modular networks:
Where components in federated networks generally function with independent operating systems per hardware module, integrated modular networks allow for a layer of abstraction between the hardware and software, in order to more swiftly allocate resources to and from any subsystem of the aircraft. These highly integrated systems often leverage the Avionics
___________________
3 Intelligent Aerospace, 2017, “MIL-STD-1553B in Avionics: Where Data Networking Has Been and Where It’s Going,” https://www.intelligent-aerospace.com/commercial/article/16544804/milstd1553b-in-avionics-where-data-networking-has-been-and-where-its-going, accessed June 2, 2020.
4 J.D. Kennedy and M. Towhidnejad, 2017, “Innovation and Certification in Aviation Software,” 2017 Integrated Communications, Navigation and Surveillance Conference (ICNS), doi: 10.1109/ICNSURV.2017.8011916, https://ieeexplore.ieee.org/document/8011916, accessed June 2, 2020.
5 System Architecture Virtual Integration (SAVI), “Exponential Growth of System Complexity,” https://savi.avsi.aero/about-savi/savi-motivation/exponential-system-complexity/, accessed June 2, 2020.
Full-Duplex Switched Ethernet (AFDX) data network with the APEX application program interface (API), as specified in ARINC 664 part 7 for data communications.6,7
The integrated modular network relies heavily on software for capability and improvements. However, while the avionics architecture shifted to a heavy reliance on software, the organic organization structure lagged and continued to approach sustainment, as if the software components were predominately hardware.
Throughout the evolution of avionics system and embedded software architectures, the challenge of government data access to source code and development
___________________
6 See TTTech, “Avionics Full-Duplex Switched Ethernet (AFDX),” https://www.tttech.com/product-filter/avionics-full-duplex-switched-ethernet-afdx/, accessed June 2, 2020.
7 See Intelligent Aerospace, 2017, “MIL-STD-1553B in Avionics: Where Data Networking Has Been and Where It’s Going,” https://www.intelligent-aerospace.com/commercial/article/16544804/milstd1553b-in-avionics-where-data-networking-has-been-and-where-its-going, accessed June 2, 2020.
tools compounded the issue of organic sustainment. Without these vital elements, any transition to organic sustainment is and will be difficult, especially if access is not provided in a timely manner.
In summary, the current state of organic software sustainment is framed by two characteristics. The first is the legacy of treating avionics as a hardware commodity, even as the software content has increased. Second is that the inability to gain access to data rights and software development tools has slowed organic growth while perpetuating USAF reliance on contractor sustainment support.
