“Manual workarounds”—a phrase that comes up in the latest DOT&E report—are a common theme in the ALIS saga. The majority of what ALIS is supposed to be able to do only works with “a high level of manual effort” by maintenance crews and administrative staff. For example, problems with the Deployment Planning Tool and transferring data generated on the aircraft into the ALIS network still have not been corrected. To complete the necessary tasks, contractor specialists must take over from the service members, causing “frequent work stoppages.” Every time an F-35 requires a maintenance action it must be logged in the system. According to the testing report, “documenting maintenance tasks in ALIS frequently takes more time than completing the maintenance action.”

When a component like an ejection seat has a problem, crews must record it in ALIS’s Electronic Equipment Logbook, which is then supposed to track parts through the supply chain. As for most such actions, ALIS is supposed to automate this process. But so far, maintenance crews have found they must instead manually enter “missing or incorrect” data into the network. The lack of standardization among vendors for the F-35’s various subsystems is one of the main drivers of problems with the Electronic Equipment Logbook feature. The outsourcing of subcontracts to about 1,500 vendors all over the country has helped buy the program widespread Congressional support, but compounds ALIS data errors, slows parts deliveries, and increases costs to the program.

With all of these problems, and the fact that many have persisted for years, “end users” (read: hard-working uniformed maintenance crews) have good reason to question the functionality of ALIS. According to the report, some crews keep two sets of books, maintaining separate databases on laptops to track the usage of parts as a check against the data ALIS generates, which frequently proves incorrect.

Many of these problems will likely continue indefinitely as the software continues to receive patches on top of patches. ALIS has gone through at least 27 versions. This year’s testing report alone includes discussion of 5. Each is meant to add functionality and correct deficiencies in earlier iterations. DOT&E reports some progress, including a patch that helped filter the false alarms that have afflicted the system. Yet ALIS continues to cause more problems than it solves. The program is planning to release four major ALIS upgrades over the next three years. The challenge inherent in this is that each version will almost certainly introduce new problems. “According to some estimates, between ten and fifteen percent of security patches actually introduce new vulnerabilities,” software developer Chad Perrin wrote on TechRepublic in 2010. The program plans to roll out more frequent, smaller releases to deal with this.

ALIS designers have their work cut out for them solving new problems and those that have endured since early in the development process. For example, nearly six years ago, ALIS’s Squadron Health Management application incorrectly reported an aircraft as non-mission-capable, while at the same time another application, the Customer Maintenance Management System, reported the aircraft as ready to fly. First identified in ALIS version 1.0.3A3 in December 2012, this problem has yet to be corrected.

Problems with ALIS are so bad that the Air Force recently announced that, with help from Lockheed, it is now working to develop a new program, called “Mad Hatter,” which would perform all of ALIS’s intended functions by incorporating Wi-Fi and touchscreens on the flight line. To be clear, taxpayers funded Lockheed Martin to create ALIS, and Lockheed made a complete mess of it. Now, taxpayers will pay Lockheed Martin to build the Mad Hatter replacement, while also footing the bill for patch after patch on the original system.

Data Files Required to Test Threat Evasion Not Finished

Program officials have not built or funded the programming capacity to build all the data files needed to power the F-35’s complex array of computers and sensors, known collectively as the aircraft’s mission systems. The full range of functionality of the F-35, particularly its use of stealth, depends on having up-to-date information about enemy ground and air radar signals, missiles, and jammers, as well as similar information about friendly units. This data is gathered into massive files called Mission Data Loads (MDLs), which the aircraft’s sensors use to identify threats, disregard friendly signals, and calculate safe flight paths. Programmers must tailor MDLs for each potential combat theater, because every country employs its own array of radar and weapon systems. These combinations change frequently, so MDLs must be continuously updated, and, accordingly, their accuracy reverified. Without up-to-date and fully verified MDLs, the F-35’s radar, electronic warfare systems, and other onboard sensors cannot properly locate, track, evade, or target enemy systems.

Programmers at the United States Reprogramming Laboratory at Florida’s Eglin Air Force Base create and update the MDLs. Because the lab’s hardware and software are so cumbersome, it took 12 to 15 months to build and test the MDLs intended for the Initial Operational Test and Evaluation stage—and these have yet to be verified as accurate. According to the report, the lab still “lacks adequate equipment to be able to test and optimize MDLs under conditions stressing enough to ensure adequate performance against current and future threats in combat.”

The Joint Program Office has mismanaged the process of creating and testing MDLs. The lab doesn’t have enough high-fidelity signal emulators to reproduce the kind and quantity of radar signals that a realistically dense enemy defense system would emit. Those emulators are needed to stimulate the F-35’s electronic warfare sensors to test whether they respond properly. The lab is funded to install eight high-fidelity signal emulator channels in each of its two test lines by the end of 2019. The program office’s own analysis shows 16 to 20 high-fidelity channels are recommended in each of the two test lines to adequately replicate near-peer threat signal environments for MDL testing—but the office has not provided funding to purchase them. Inadequate signal emulators will inevitably lead to inadequate test MDLs—and, far more seriously, will lead to inadequate MDLs for use in real combat, which could put missions and troops at risk.

While the program has already fallen behind in the production of these critical files, the situation will only get worse as it presses forward with the current so-called follow-on modernization phase, variously known as Block 4 or Continuous Capability Development and Delivery (abbreviated as C2D2). This nomenclature is effectively a smokescreen for evading the onerous milestones, capability definitions, and schedule commitments of a normal development phase for any major weapons program. The Continuous Capability “innovation” allows the Joint Program Office to roll out small increments of new and ill-defined capabilities every six months or so, thereby escaping responsibility for not having met the standard schedule and capability thresholds for the development phase. A substantial portion of the Continuous Capability rollouts will actually be fixes for the mountain of unresolved deficiencies that remained when the Joint Program Office arbitrarily called off the formal development phase in 2018. Taxpayers have already paid for the development phase. They will now be billed again to fix the many lingering problems and complete what the program left undone.

The Continuous Capability rollouts of new hardware and software every six months will necessitate continuous new MDL updates and, worse, “continuous” operational testing—a veritable nightmare for the programmers at the lab, and even more of a nightmare for the operational testers. With 6 current F-35 configurations, plus at least 4 new Block 4 iterations planned, and 12 geographic regions requiring region-specific MDLs, the Reprogramming Laboratory will have to create, update, distribute, and manage at least 120 MDLs. Creating new MDLs for that testing is estimated to take eight months, and, according to DOT&E, even minor updates take “several months.” The program office has not identified the manpower or hardware required for the task, and has not contracted for it.

Cybersecurity Concerns Continue

Pentagon officials have touted the F-35’s supposed advantages as a “computer that happens to fly.” The aircraft derives almost all of those advantages from the intricate internal and external network of hardware and software linking it to other aircraft, intelligence sources, ground stations, satellites, software labs, maintenance computers, and more. Testing for cyber vulnerabilities is therefore crucial to any evaluation of the program. The Government Accountability Office released a report in October 2018 showing that nearly every software-enabled weapon system tested between 2012 and 2017 can be hacked, often by simple means like looking up default passwords online for commercially available software. Numerous parts of the F-35 program use this kind of software; ALIS runs on Windows, for example.

Cybersecurity testing has long been part of F-35 program evaluation. The testing office is mum on the specific issues found so far, but reports that as of 2018 “some of the vulnerabilities identified during earlier testing periods still had not been remedied.” DOT&E calls for more cyber testing of the aircraft and of the program’s supply chain to “ensure the integrity of hardware components for initial production of air vehicles and ALIS components, plus resupply of replacement parts.”