The Sikorsky-Boeing SB-1 Defiant concept for the Joint Multi-Role demonstrator, a predecessor to the Future Vertical Lift aircraft.

WASHINGTON: The first Future Vertical Lift Aircraft won’t fly until the 2030s but the Army, Navy, and industry are already at work on software standards. Those include a new “model-based” approach to software architectures that will require a culture change among programmers and defense bureaucrats alike.

Why take on so much so early? Because FVL will fly for all four armed services and will probably have multiple variants of different sizes. That makes it uncomfortably comparable to the Army’s cancelled Future Combat System and the tri-service F-35 Joint Strike Fighter — both programs infamous for costly and time-consuming software problems. On the upside, if the new approach succeeds it could reduce costs not only for FVL but for contracts to upgrade existing aircraft, and even on programs entirely outside the aviation world.

Common software standards let different programs and services reuse the same software, instead of having to reinvent the wheel. “If we don’t stay aligned, we’re going to fail from the get-go,” Cmrd. William Hargreaves of Naval Air Systems Command this afternoon at the Center for Strategic and International Studies. “If we don’t apply it across the services the same way, we’ll run into the cost growth that has plagued previous joint programs.” On the other hand, he said, if the FVL effort can move the services towards common standards, that will benefit not just FVL itself but all the aging aircraft the military must modernize.

“Once this standard gets defined… hopefully we only write it [a piece of software] once and it can be used in all the different aircraft,” said Boeing’s Thomas DuBois, speaking alongside Hargreaves. DuBois led a Boeing-Sikorsky team in a four-month demonstration project where they took data fusion software already in service on the Navy P-8 Poseidon and, with modest rewriting, got it to run on three sets of hardware: Boeing’s AH-64 Apache helicopter; Sikorsky’s prototype Raider; and a Boeing experimental computing system called Phantom Fusion. (Honeywell also did a similar four-month study).

Standards would not only let multiple pieces of hardware run a single piece of software. They would allow multiple companies to compete to develop that software. The ideal is an open environment comparable to the Google Android, where anyone can develop an application and have it run on a wide range of phones, Hargreaves said. If someone makes a better mousetrap, the government can swap out the old application and swap in the new one.

“We haven’t tied our standards or methods to a specific platform or to a specific requirement,” said NAVAIR’s Robert Sweeney, who chairs the working group for what’s known as the Future Airborne Capability Environment (FACE). “It’s not specific to Future Vertical Life,” he told the CSIS audience. “It’s not even specific to aviation, though that’s in the name.”

By contrast, Sweeney said, in past multi-service programs like FCS or F-35, software was tied tightly to a specific military requirement and a specific set of hardware. FVL doesn’t have defined requirements yet, let alone hardware, so it’s forced to adopt a more flexible approach.

Besides common standards, the second and more arcane aspect of the new method is something called a “model-based” development approach. Military programs start with fairly broad-brush requirements that need to be translated into lines of code that actual run on a particular machine, said Michael May, the associate director for software and embedded systems in the office of the assistant secretary of Defense for research and engineering. In between those initial requirement and the working code, the current system has many steps where things get increasingly specific — and there’s opportunity for misunderstanding at every step, or even for someone to mistype a specification in the spreadsheets often used as (crude) planning tools. “It tends to be a very error-prone process,” May said.

In model-driven development, however, “you actually record what the interfaces are, the semantics, and that information is available to anyone who wants to use it… down to the very end of the chain where you’re actually going to produce code,” May said. What’s more, the model-based approach includes “formal methods” (a programming term of art) for rigorously assessing whether a particular piece of code will actually work.

This new approach is not fully mature, May allowed. “Some of our methods don’t scale well” from pieces of software to entire systems, he warned. They also require different programming skills and levels of education — “the formal-methods guys tend to be PhDs,” May said — than are found in the current workforce.

Current software engineers tend to have a lot to unlearn. DuBois noted one of his best programmers on the project was one of his youngest. His competitor, Honeywell’s Joseph Riter, agreed: “The software developers struggled with the concept of the data model.”

Likewise on the government said, “we’re working towards bringing our work force up to speed,” Sweeney said. “I wouldn’t say we’re there today.”

Hopefully, there’s time. “We’re not developing the mission system architecture per se for Future Vertical Life. It’s way too early to do that,” emphasized the FVL program director, Army civilian Dan Bailey. Instead, the services and industry are embarking on a five-year Joint Common Architecture (JCA) demonstration program. But even the final production of that demonstration will be a workable software architecture, not necessarily the final architecture for FVL. There is still a lot to learn.