Home » Aviation » NAVAIR Pushing Paperless Engineering to Speed Aircraft, Weapon Design

NAVAIR Pushing Paperless Engineering to Speed Aircraft, Weapon Design

CGTrader Image

SPRINGFIELD, Va. – The commander of Naval Air Systems Command called for a new model-based systems engineering environment that would usher aircraft and weapon development through a paperless process of generating specifications, digital drawings, and testing the design in a virtual environment.

Vice Adm. Paul Grosklags told a group of government and industry engineers on Tuesday at the National Defense Industrial Association’s Systems Engineering Conference that operators want three things when a new product is delivered, and NAVAIR has proven itself good at only one of them.

“They want to know that that capability has been fully characterized, so not only do they know what it does, but they know what it doesn’t do – equally important to them when they take it into combat,” he said, acknowledging NAVAIR is diligent about doing this characterization testing.
“When we deliver that capability to them on Day 1 it’s fully integrated with the environment they’re expecting to utilize it in,” he said, which is done poorly, and “give them a system on Day 1 that they can fully train with. Fully train with, 100-percent of the capability we’re giving them. (Currently) we’re telling them what it can do, but typically we also go, ‘don’t worry, your training system, your simulator software, it’s an iteration or two behind, but it’ll catch up.’ Well, it usually doesn’t catch up because we keep rolling the operational software but the training software comes behind.”

Vice Adm. Paul Grosklags, commander, Naval Air Systems Command. US Navy Photo

Grosklags argued that the successful implementation of model-based systems engineering would solve the integration and training problems, as well as reduce the time and burden required to design, vet, redesign, and test and evaluate new planes, ships, weapons and more.

First, he said, program offices need to sit down with operators and understand the requirement on a tactical level: what mission needs to be accomplished, what capability is needed, what threat is being countered, how will the system be used, who will use it, and more. If that information is all included in a computer model, NAVAIR can insert a notional placeholder aircraft or weapon into the model and pass it along to industry to actually engineer.

“I’ve got a model of my threat; I’ve got a model of my blue forces; I’ve got environmental models, whether I’m operating in an [electromagnetic warfare] spectrum or I’m operating in the acoustic spectrum under the water; it’s all done with models,” he said. It’s important for industry to engineer the new product within that model, instead of today’s practice of, “we write a 500-page specification with 20,000 shall-statements, and we give it to industry and go, here, (design) this. We don’t give them the threat models, we don’t give them the blue force models, we don’t give them that system of systems family model we just built. We give them a 500-page document with 20,000 shall-statements.”

If industry can work within that model environment, then little changes can be made along the way – swapping one sensor for another, for example – without wondering how that change may affect the aircraft’s aerodynamics or its low-observability or other features that today are designed separately on paper. With a digital drawing in a threat-representative environment, the sensor could be swapped out and thousands of possible engineering solutions generated until the best one is chosen – which Grosklags said could be done in a matter of hours or days, rather than the months it would take with today’s processes to make those changes.

The NAVAIR commander said the benefits to this type of design effort continue throughout the test and evaluation, fielding and sustainment phases.

For example, he said, in lieu of a paper-based design review, as industry meets various milestones in maturing its design “let’s take those models and let’s put them back in the tactical scenarios we developed with the operator back in step 1 and just see how it goes. What better evaluation or assessment of how the program is maturing than to actually run the current level of maturity of performance that we see in our models through the tactical situations we’ve built with the operators? Because in the end that’s what matters, in the end capabilities-based test and evaluation is about testing the capabilities – it’s not about ensuring industry met every one of those 20,000 specs. That’s where we spend all our time today during T&E, validating that industry met the specs. The fleet couldn’t care less, the fleet wants to know that the attributes and the capabilities that they’re counting on will be met.”

That sort of constructive testing – all conducted within the simulated environment – could pave the way to eventual virtual testing once the first hardware is delivered, which would then pave the way to eventual live testing in the field with real operators. That flow would make the best use of everyone’s time and allow any problems to be addressed as early on as possible, he said.

Developing and maturing a “digital representation of that system and how it interacts with its environment” would also go a long way in delivering relevant trainers from the outset, rather than today’s simulators without the latest software update or inaccurate threat environments. Grosklags added that the digital representation would also help with sustainment efforts throughout the life of the program, as models could help show how the system would hold up over time and in different environments.

Grosklags made clear that advocating this idea is much easier than actually implementing it, but he pointed to the MQ-25A Stingray unmanned carrier-based aerial tanker as an early example of trying to implement the model-based engineering.

“We’re in the process of building that model-based specification, that model spec for industry right now,” he said.
“When we get that part right, build that spec, now it’s in industry’s hands” to continue to make best use of that model environment.”

Artist’s Concept of the General Atomics MQ-25 Stingray. GA Image used with permission

Grosklags said he hoped to learn a lot about model-based engineering with MQ-25 without bogging the program down with new processes and design tools. To supplement that learning effort, he suggested that the Navy and industry conduct a “Surrogate System Experiment: to help identify potential kinks in the new process.

“It could be a UAV, that’s what we have in mind, but it could be just about anything. And the idea would be to bring this group – representation from the organizations represented in this group today – into a collaborative environment where we can actually build a surrogate program and execute that model, the capabilities-based acquisition model,” Grosklags told the government and industry engineers in the room.
“Find out where the hard spots are, find out where we have to go soft, find out what is that deliverable, what kind of contract will work, where do we have to hand off between government and industry, how do we truly make that integrated data environment work in a cyber-secure environment?”

He added that NAVAIR intends to begin implementing the model-based engineering concept into any new design, capability upgrade or sustainment program it can, seeking opportunities to learn as quickly as possible, “as opposed to waiting for the big bang on a brand new program.”