Secrecy surrounds nearly every detail of the U.S. Air Force’s new stealth bomber. Analysts seeking an estimate of the Northrop Grumman B-21’s takeoff weight are forced to scrutinize the two released renderings for possible clues such as the size and shape of the landing gear. Other fundamental features—like the number and size of the engines, the capacity of the weapons bay and even the aircraft’s unrefueled combat radius—remain shrouded in classified mystery.
A consistent and surprising exception to the Air Force’s tight-lipped discretion, however, comes with the B-21’s software.
Even as the results of ground-based testing for the engines, structural materials and sensors remain a closely guarded secret, Air Force leaders feel free to boast about the lines of software code embedded in the B-21’s computers and running as applications on an open architecture processing system. While the rest of the aircraft’s development systems are described broadly as progressing on schedule, the secretive program’s managers slip in specific details about the pace of software updates to the bomber’s systems integration laboratories.
- B-21 and F-16 labs integrate software container
- Open architecture processors coming for F-22 and F-15EX
- USAF official sees opportunity to disrupt defense industry
“We’re not doing what was termed a normal OFP [operational flight program] drop every year or two,” says Randall Walden, director of the Air Force Rapid Capabilities Office (RCO). “We’re seeing it, like, every month or two. So that level of compression of time gets after those typical errors that take a long time to fix.”
The B-21, according to Walden, is participating in a dramatic shift in software development within the military and the defense industry. It began a few years ago with a move to an agile software release schedule, with small capability increments released every few months instead of every few years. Over the next several years, multiple aircraft, including the B-21, Lockheed Martin F-22 and F-35 and Boeing F-15EX, will be fielded with architecture compliant with open mission systems (OMS).
Once the agile software method and OMS-compliant systems are in place, Air Force officials are preparing for even more profound changes. As software updates rather than new hardware begin to drive new combat capabilities, a powerful set of tools already used by commercial industry potentially becomes available to combat systems. The tools may allow developers to untangle the software code for a specific application from a military jet’s operational flight program (OFP), which would markedly reduce the cost and schedule for introducing new, software-driven capabilities on the combat fleet.
The implications for the defense industrial base could be dramatic. If the technology survives the technical, regulatory and cultural challenges that still lie ahead, some Air Force technical leaders, including Chief Software Officer Nicolas Chaillan, will seek to disrupt a pillar of the defense industry’s business model, with the government taking ownership of the valuable intellectual property (IP) embedded in the source code OFP. Instead of controlling the life cycle of a franchise weapon system, the industry’s revenues would come from developing the most valuable software-driven applications, which would generate licensing fees based on the government’s usage.
The B-21 program guards many secrets, but not its role in the shift to a new software development model. As Northrop continues assembling the first flight-test aircraft in Palmdale, California, the systems integration laboratories for the B-21 are receiving new containerized applications orchestrated by a Google-derived tool called Kubernetes.
“Kubernetes allows us to reduce the regression time because not all of the software is in this spaghetti-code makeup,” Walden says. “It’s broken up into [discrete applications] and allows us to do a much better job of . . . getting [the applications] on the airplane.”
Software development in U.S. defense programs has been a problem for decades.
In modernization programs, the pace of upgrading existing aircraft such as the F-22 has been partly driven by a software development method known as “waterfall.” Software developers divided the code into separate applications, with each developed and tested separately. At the end of a usually two-year development cycle, the individual software modules would be integrated and tested together for the first time as a complete system.
Inevitably, the testers would find numerous deficiencies, which could take months or even years to resolve. The Increment 3.2A upgrade for the F-22 OFP suite, for example, fell a year behind schedule under the water-fall method, according to a 2018 report by the Defense Department Inspector General.
The same waterfall method also has sometimes partly dictated the pace of software development for new aircraft. Prat Kumar, Boeing’s F-15 program manager, says the typical program would begin with Air Force development requirements. At some point, a request for proposals would be released. Months later, a company would be awarded a contract, launching the software development process. A final bundle of software would finally be released to a testing organization, which would reveal deficiencies that need to be fixed. Half a decade could pass between the requirements being set and the capability being delivered.
“It could be a 3-5-year time frame, broadly speaking,” Kumar says.
The commercial industry largely moved toward agile software development methods over a decade ago, and the defense industry is now starting to come along. In an agile process, the goal is to deliver new capabilities in smaller increments, which can then be tested at the integration level much sooner. The agile process does not eliminate software bugs, but in theory the method simplifies the resolution.
In many cases, some form of agile development method is already the norm for the Air Force’s most advanced combat aircraft. The F-35 adopted the Continuous Capability Development and Delivery process for Block 4 modernization, although the Government Accountability Office recently noted that the method fell short of expectations during the first full year of production in 2019. The F-22 program, meanwhile, has adopted the Raptor Agile Capability Release process, which broke up the Tactical Mandates upgrade program into a series of smaller capability insertions delivered more rapidly.
Though in production for nearly a half-century, Boeing’s F-15EX also is making a similar transition. The Air Force plans to order a minimum of 144 F-15EX aircraft, and the first lot of eight aircraft will be delivered with Block 9.1X software for the OFP. Starting with Lot 2 aircraft deliveries in 2023, the Air Force has contracted Boeing to deliver Block 9.2 software, which will set a new fleet-wide baseline, Kumar says. That means new F-15EX and older models, including the F-15C and F-15E, will use a common software suite.
At the same time, Boeing is working on a new Phantom Works-developed mission systems processor for the F-15EX. The new computer hardware is compliant with the Air Force’s OMS architecture. As the processor enters service beginning in 2023 on Lot 2 jets, the possibilities for new upgrades will change. Applications developed by vendors outside Boeing’s proprietary software standards will have an easier path to integration on the F-15EX. The OFP will continue to be updated in roughly yearly intervals, Kumar says.
The OMS architecture also is spreading to Lockheed’s stealth jets. A new, OMS-compliant processor has been installed on the first five F-22s for development testing at Edwards AFB, California, and Nellis AFB, Nevada, says O.J. Sanchez, Lockheed’s vice president for F-22 programs.
“We’ll start to see that retrofitted in the fleet after it’s approved for release next fall,” Sanchez says.
Beyond agile development and OMS-compliant architectures, the Air Force’s next push will be to containerize new software capabilities. To software developers, the idea of using virtual containers to deliver new applications is nothing new. Containers are commonly used for the software that runs applications for consumers and even information technology services in the defense industry.
A container allows a computer processor to run a new application without entangling the source code of other systems on the jet. A cottage industry of containerizing tools, such as Docker and OpenShift, allows developers to create the new applications. Depending on the number and complexity of containers involved, the developers can use Google’s Kubernetes automated orchestration tool.
For now, containers do not yet exist on flight-certified applications for any aircraft—much less the Air Force’s most advanced combat jets. But that could begin to change.
On Nov. 7 Chaillan and Will Roper, the Air Force’s assistant secretary for acquisition, technology and logistics, met at Hill AFB, Utah, to attend a major milestone: For the first time, an internal Air Force software factory inserted a new containerized application into flightworthy hardware. In this case, the hardware belonged to the F-16 systems integration laboratory (SIL), a ground-based testing rig.
The Air Force integrated new map and sensor applications into the display of the F-16 SIL purely as a proof-of-concept demonstration, Chaillan tells Aviation Week. Roper and Chaillan had challenged Hill’s software factory to develop the code, integrate Kubernetes and run the application on the F-16 SIL’s existing computers within 45 days. Using a traditional, noncontainerized approach, the same upgrade could require additional weeks or months of regression testing to verify that the software would not interfere with other systems on the jet.
As the RCO’s Walden confirms, the Air Force later performed the same demonstration on the B-21, although further details have not been released.
“People were always saying: ‘Well, you know we can do all this stuff on business systems, but, we cannot do it on weapon systems. And we knew [that] was wrong and was completely possible,” Chaillan says. “We wanted to demonstrate that in 45 days, so we picked the F-16 to show it could be done on legacy hardware, and it’s not required to replace any component.”
Following the proof-of-concept demonstrations on the F-16 and B-21 SILs, the Air Force is seeking to obtain flight certification for containerized software updates, allowing the mission systems for jets to be updated wirelessly during flight. Aircraft certification standards for software now require extensive validation and verification for every line of software code before they can be installed on a jet on the ground, so the new approach represents a significant change. The Air Force is now seeking to approve the new certification policy and achieve safety-of-flight certification, Chaillan says, but he cannot offer a timeline for completing the process.
Chaillan considers containerization critical to the future of combat aircraft technology. If future fighter and bomber pilots want to stay relevant, they cannot wait for software developers to complete the same level of regression and security testing used today for new updates, he says.
“I don’t think we have a choice,” Chaillan says. “I think if we don’t do it, China and Russia are going to be 20 years ahead. The last 30 years of innovation was driven by hardware. The next 50 [years of innovation] are going to be software-defined. It’s going to be artificial intelligence software that’s going to be able to make decisions before you even have the time to touch the button.”
If flightworthy software containers become reality, Chaillan foresees profound changes for the defense industry. Upon entering U.S. government service after a successful career as a technology entrepreneur in France, Chaillan found the military’s relationship with defense contractors over the rights to software source code backward compared to the commercial industry. The government pays defense companies to develop the source code for an aircraft OFP, but industry keeps the IP rights to the code. Chaillan wants to reverse that approach.
“We paid for the software and yet we didn’t own the IP. That will never happen on the commercial side,” Chaillan says. “On the commercial side, if you go to a company, and you say, ‘I’m going to hire you to build whatever capability, and I’m going to pay 100% of the cost of developing it,’ well, guess what, you better own the IP.”
Defense companies could still make money, but the business model would change. Instead of basing a business case on owning rights to the OFP source code, defense companies could develop new, containerized software applications, Chaillan says. Each application could be licensed by the company to a military, government or even a commercial customer, with fees paid for how often the application is used.
“It’s a recurring revenue model,” Chaillan says. “You can sell the same piece of software as a monthly fee or a consumption-based fee.”
As the OMS architecture and software containers replace proprietary OFP source code on military aircraft, the new model also could lower barriers to entry for traditional technology companies to develop new applications for the military. Chaillan acknowledges the transition is likely to take several years.
“It’s not going to happen in a year; it’s going to happen in 10 years,” Chaillan says. “If we don’t do it, we’re going to get behind.”
Related Content
