Government and industry are working quickly to gain as much knowledge as they can during the science and technology phase of the Future Vertical Lift (FVL) program, hoping to understand how to write the underlying software in mission-specific building blocks before the acquisition program formally begins at the end of the decade.

Robert Sweeny, the PMA-209 lead avionics architect at the Naval Air Systems Command, said Tuesday at the Center for Strategic and International Studies that the eventual FVL software must be an open design to allow for future innovation and competition in industry.

Artist's rendering of a potential Boeing-Sikorsky future vertical lift platform.
Artist’s rendering of a potential Boeing-Sikorsky future vertical lift platform.

Though mission requirements and specifications about the helicopters’ designs have not been finalized yet, the strategy on the software side is “taking a model-based development approach and looking at each of those requirements and breaking them down into functions that can actually be reused to make up the capabilities across platforms or families of systems.” The military would essentially end up with software applications for various operational functions, written in the same coding language and able to be used on any platform with a Future Airborne Capability Environment (FACE) transport service.

Dan Bailey, the Joint Multi-Role/Future Vertical Lift program director, said the program office cannot start writing the software yet, but it can start learning how to write these function-based software apps and ensure that the apps can run on any operating system with a FACE plugin.

“We’re not developing the mission equipment package, we’re not developing the architecture per se; we’re trying to implement demonstrations over time to learn as we go. And that’s what we’re doing really for the next five years,” he said at the same CSIS event. “We don’t want to learn in the first iteration of FVL and every other subsequent FVL changes; we want to learn before we actually implement the first one.”

An early step the program office has already taken is to conduct a Mission Systems Effectiveness Trades and Analysis with industry to gain a better understanding of the current state of technology and where it is likely to go in the coming years. Bailey said the analysis showed that fiber connections and wireless data transfers, multicore and distributed processing, multiple-layer security and other features would be significant aspects of the environment their FVL software would have to operate in. Understanding what that means for the software before deciding on standards and common interfaces now should yield significant time and cost savings later, he said.

On the contractor side, Thomas DuBois, the FVL/Joint Multirole (JMR) chief systems architect at Boeing [BA], said the company was given about four months to demonstrate its ability to develop a fusion application that could run in the open JMR operating environment. The Boeing-Sikorsky [UTX] team took Boeing’s existing core fusion engine from an existing family of products, wrapped it with a FACE interface and portability unit, and successfully operated in in the JMR environment within about three months.Textron [TX] leads the other team competing for the Army’s JMR program.

Taking the experiment a step further, DuBois said the contractor team then tested the fusion application in three other environments–the legacy AH-64 Apache operating system, the emergent Sikorsky Raider helicopter and the future Boeing Phantom Fusion. “Very few changes needed to be made” to the software in the new test environments, and the changes that were made were done at the transport layer, not within the application software itself.