The following is a release from David Vergun and the U.S. Army:

Future Vertical Lift, or FVL, is an initiative looking at the next-generation of rotorcraft for 2040 and beyond for the U.S. military. FVL recently added new architecture, which promises to increase safety and security and reduce cost overruns, delays and performance problems, according to Alex Boydston.

• RELATED STORY: Army Research Lab Developing Energy Harvesting Backpack

It’s called Architecture Centric Virtual Integration Process, or ACVIP, a type of Joint Common Architecture, or JCA, and it’s so new, it’s still in the demonstration phase.

Boydston – who is a project engineer for Joint Multi-Role, or JMR, Mission Systems Architecture Demonstration, or MSAD, for the U.S. Army Aviation and Missile Research, Development and Engineering Center, Aviation Development Directorate at Redstone Arsenal, Alabama, spoke Oct. 29 at the National Defense Industrial Association-sponsored 18th Annual Systems Engineering Conference about the ACVIP Shadow Effort conducted on the JMR MSAD program’s recent JCA demonstration.

WHAT’S THIS ARCHITECTURE?

Architecture consists of a plan, standard procedures, software, computer language and models shared by all of the engineers. It can be thought of like a blueprint that an architect creates to erect a building, but in this case, an aircraft.

“An important aspect of ACVIP,” Boydston said, “is that it contains ‘a single source of truth’ which means that information in the architecture models are stored in such a way that when updates or changes are made, revised information is available to all designers and analysts so there are no inconsistencies.”

It’s a sole reference for the Army – which is the lead for FVL and which holds the architecture repository – as well as the other military services and contractors with their second- and third-tier vendors.

“Without this single source of truth, there would be ambiguity in the design and the requirements, leading to defects, which most likely would result in major rework in later phases of the development process,” he said.

The models used in the architecture are not only used by the design teams and engineers, they will be used by the requirements and acquisition communities as well, he said.

Since there’s a commonality and standardization within ACVIP, communications between the acquisition and requirements community, contractors, engineers and decision makers should be a lot more effective than in previous system builds, he said, adding that he thinks this is a “paradigm shift,” a term he said he doesn’t use lightly.

The architecture will remain intact throughout the lifecycle of FVL, Boydston said, which means most likely for the remainder of this century. Nothing will be thrown away or lost, he said.

HOW ACVIP EMERGED

The foundation for ACVIP has its origins with the Aerospace Vehicle Systems Institute, or AVSI, a consortium of commercial aerospace companies and government agencies, Boydston said.

In 2008, AVSI launched System Architecture Virtual Integration, or SAVI, “to address the problem of growth in complexity in systems leading to cost and schedule overruns,” he said.

The objective was to develop a standards-based Virtual Integration Process that allows multiple parties to integrate and analyze systems virtually throughout the development lifecycle.

ACVIP’s architecture, built two years ago, “leverages SAVI to a great extent,” Boydston said.

The next step was to select a computer language.

AMRDEC did a survey of several architectural description languages and found that Architecture Analysis and Design Language, or AADL, was a good language to use when describing “complex software and an intensive system,” which FVL will feature.

The AADL will likely be used as the modeling language and will be integrated within the software and hardware that controls FVL and its mission systems. AMRDEC is also looking at using other languages like Unified Modeling Language, he added.

SOFTWARE IMPORTANT

Getting the software right from the get-go is no small matter of importance, Boydston said.

“Software interaction complexity drives system costs,” he said, noting that in 1997, software as a percentage of total system cost for the average new system was 45 percent. By 2010, it was 66 percent, and by 2024, it’s expected to be 88 percent.

Much of that cost was on post unit-test software rework, he said, adding that a lot of those software problems originate early in the design phase so now is the time to get it right.

Also, corrupt software can result in false positives, false negatives and untimely information, which can have “catastrophic consequences,” he said.

Another area of concern for software that is being addressed is in the area of portability, modularity, and reuse. These concerns are being addressed by the Future Airborne Capability Environment, or FACE Standard and the JCA reference architecture. The FACE Standard is an open standard established between the Department of Defense and Industry.

Scott Dennis, director of the AMRDEC’s Software Engineering Directorate, Aviation Systems Integration Facility, said “FACE is working to establish a software common operating environment that allows portability and the creation of software product lines for the entire military vertical lift community and does this in consensus fashion.”

The U.S. Navy and U.S. Army were founding members of the FACE consortium in 2009. The consortium’s purpose is to establish an open software architecture to help achieve commonality.

While FACE provides an architectural framework, it does not define the applications that will reside within the layers of the FACE architecture. This is where the JCA comes in. JCA is a reference architecture designed for the FVL family of systems.

JCA will guide and constrain the future architecture implementations by providing a common lexicon and taxonomy, a common architecture vision and modularization and complementary context. The Army is working with industry via the Vertical Lift Consortium, or VLC, to define and decompose the mission level capabilities that will reside in a mission computer operating environment.

PUTTING ACVIP, JCA AND FACE TO THE TEST

The JMR MSAD program is conducting a series of science and technology demonstrations to reduce risk for FVL and prove the utility of FACE, JCA, ACVIP and other processes, tools and standards. The JCA Demo was completed this year. Its goals were to validate the JCA and FACE approaches, mature JCA, FACE Standard & Ecosystem tools, and business practices and gain experience implementing a model-based acquisition approach.

The JCA Demo culminated with a meeting in Huntsville, Alabama, in May 2015 with more than 75 lessons learned captured to be used in moving forward with the FACE™ Standard, JCA Reference Architecture and ACVIP.

ACVIP TIMELINE

Near-term tasks for JMR MSAD include continued development of the JCA Reference Architecture, an Objective Mission Equipment Package definition, and continued collaboration with the FACE Consortium.

Near-term MSAD tasks for ACVIP include developing handbooks, conducting training and providing mentoring in AADL and ACVIP, standing up an ACVIP “community of practice” and providing tools for use in an upcoming demonstrations.

The next JMR MSAD demonstration will be the Architecture Implementation Process Demonstration, which is expected to be posted on www.fbo.gov in November. In 2018, a follow-on demonstration called the Mission Systems Architecture Capstone Demonstration is expected.

“With the expected start of the first FVL program in the 2019 time frame, the processes, tools, standards and guidelines need to be matured, debugged, verified and validated to ensure there are no surprises,” Boydston said.

Boydston said the JMR MSAD team wants to deliver standards, tools and process guidance to the FVL program that are mature. “We’re skeptical” of everything until it’s fully tested out, he said. “We don’t want the FVL PM to have problems. We’re trying to draw down their risk through our S&T research and demonstrations.”