Throughout the 30-40 year lifecycle of a typical Defense acquisition program, digital tools are now pervasive. But for leaders who are pushing for a move to digital engineering, the problem is there’s still a whole lot of paper along the way.

For decades, engineers have used computer-aided design to model the physical objects they’ve been tasked to build at the beginning of the process, and other participants have their own digital tools, all the way through the sustainment phase.

What’s missing — a challenge some leaders in the Defense engineering community have started to overcome — is an approach that keeps everything that’s understood about a system in the digital realm from start to finish.

“There’s a difference between executing engineering using digital things and truly doing digital engineering — where you’re actually marrying all that up together,” said Joseph Pack, the digital engineering lead for Naval Sea Systems Command’s warfare centers. “That’s been one of those big focuses that we’ve had within the warfare centers. We do a lot of research, development, test and evaluation work, and the integration is in the seams between these different digital disciplines.”

But NAVSEA and other pockets of DoD are starting to see what’s possible when those seams are closed: When digital threads start to connect one tool to another, eliminating the need for people to write written descriptions of what one tool produced, only to have that document’s content be ingested and reinterpreted by another tool — or more commonly, human beings — at another stage of the process.

“Typically, when we do one of our technical reviews with our developers, they’ll give me a bunch of documents, we’ll check them all off, and that takes literally a month,” said Nick Freije, the assistant chief engineer for mission architecture at Naval Information Warfare Systems Command. “But recently, we did a review using only a SysML [systems modeling language]-based model. My configuration manager usually spends two weeks combing through documentation to see if they actually have their product baseline documented, but this time, they did it in two hours. We were doing our review not based on documents, but actually based on the models themselves.”

Making digital engineering the norm

Digital engineering exists in some form in pockets of many government organizations. The challenge is developing a mindset and policy framework that makes it the norm.

There’s also some ambiguity in what “digital engineering” means for a particular organization — or even a particular program. NAVWAR, for example, has a newly-published strategy that seeks to communicate to the broader workforce why digital engineering is important, but the strategy itself acknowledges that the organization has a long way to go before digital, not document-centric approaches to engineering are more the norm than the exception.

But Dan Reineke, the general manager for Arcfield’s Strategic Systems Consulting division, said he believes end-to-end digital engineering will be the standard practice  in DoD within the next 10 to 15 years.

“What we try to do is work with our customers at whatever level of maturity they’re at, identify the tools they’re using, and really try to put together a plan to mature them on that digital roadmap,” he said. “In industry, there are some companies that are very mature. [For others], we help distill the basics for them to say, hey, we understand your tools, you understand the systems, we need to start crawling. Let’s start with training. Let’s start with maturing your capability in systems engineering using model-based systems engineering and build on that to get to an end state of integrated digital engineering. There’s some large prime contractors that have pockets of these capabilities across their corporations, and very similar with the government.”

But the integration challenge: Getting to a single “digital thread” for a given system or related family of systems is arguably more difficult in government. That’s partly because of institutional realities, and partly because of policies that assume the creation of documents at various milestones of the acquisition process.

“We have 10 different warfare centers, and when you look at each one, they all have different things that they specialize in. That’s not uncommon in any large organization that’s responsible for executing a lot of [early-stage] work,” Pack said. “But what that ends up creating is the old way of doing things: It’s document based, and we’re segregated according to the milestones and the documents that we’re responsible for. Each organization may be excellent, but it’s excellent within its silo. We’re going to have to start seeing institutional integration at a level that we have not seen in the past, and that’s likely going to be a big hurdle. But I think that’s ultimately going to be one of the things that makes us more effective as a research and design community.”

Updating policies to encourage digital practices

Meanwhile, DoD’s acquisition policies don’t exclude the possibility of engineering systems with digital-centric strategies. But they don’t exactly encourage it either.

Freije said that was an early digital engineering lesson from the Navy’s Consolidated Afloat Networks and Enterprise Services program, the project that began more than a decade ago to modernize the service’s shipboard information technology.

“Back then it wasn’t called model-based systems engineering … it was an architectural approach. But because we had a SysML model, in order to appease the acquisition community, we were able to create a document based on the model,” he said.

But that sort of thing might become easier under what Freije said is a new approach the Navy is taking to technical requirements. In general, the idea is for the Chief of Naval Operations’ staff to outline their requirements and budget documents in broader, more flexible terms that give designers more room for experimentation in a particular budget year.

“We call it agile acquisition, but it’s really just how we review our engineering documentation with them to say, ‘How can I play within that? That new way of bringing in the fleet, bringing in the resource sponsor, bringing in engineering — you kind of have that triad of trading off requirements with the operator with the funding. I think we could bring the models into that same discussion,” he said.

Eventually, in a hypothetical world in which every element of a system’s design is represented digitally — in a way that’s digestible by any stakeholders that might need to understand it — all sorts of interesting possibilities start to present themselves, like applying AI to engineering problems, and getting a much better understanding of how to sustain a system once it’s finally fielded.

“We’re building upon the data at each stage of the lifecycle. We’re leveraging that data — we’re not having to recreate new data at each stage,” Reineke said. “So as we start to model the system’s design, we have tools that allow us to put it into an augmented reality, like a Microsoft HoloLens, and we can start to do things in sustainment that show people exactly what type of maintenance needs to be done. And we also have digital tools now on the manufacturing side for predicting the amount of parts and supply that we’re going to potentially need later in the system’s lifecycle.”

Learning objectives:

• Current overview of digital-centric vs. document-centric engineering approaches
• Tactics to embrace digital engineering practices
• How agencies can partner with industry on digital engineering

Please register using the form on this page.