In late October, I attended the National Defense Industry Association Systems Engineering Conference, held in Springfield, Virginia. The conference covers a wide spectrum of system engineering topics, primarily supporting the Department of Defense, but also in support of other federal agencies. There were many interesting topics and discussions over the course of the four-day conference. The ones that resonated with me concerned the state of systems engineering, particularly as it applies to the federal government. I will tell you about a few of them here.
The second day of the conference was dedicated to a keynote presentation by Vice Admiral Paul Grosklags, commander of the Naval Air Systems Command, and followed by a series of four panel discussions spread across the remainder of the day.
Is lack of competition making us complacent?
Grosklags led off his address by taking the audience back to the early days of systems engineering in defense. In the ’60s and ’70s, we stayed ahead of our competition by leveraging systems engineering to build better, more robust systems. Grosklags contrasted this to today’s world, where we no longer have a near peer competitor. This, he pointed out, may be making us complacent, and in many cases we feel we have a lot of time to get it right. But in reality, our adversaries on the battlefield have observed our systems, and they use rudimentary tactics to counter our advantage.
The natural conclusion is that we really don’t have unlimited time. And in many cases we probably have less time than we think to either evolve existing systems or engineer new ones.
As I was listening to this, it led me to think that this is directly related to the “Third Offset Strategy.” The Third Offset Strategy develops next-generation technologies and concepts to assure U.S. military superiority. (You can read more about this in an article by Cheryl Pellerin, Deputy Secretary: Third Offset Strategy Bolsters America’s Military Deterrence, in DoD News.) Key to pursuing this strategy is the ability to take systems already developed, and repurpose or transform them in ways never envisioned before. Of course, the ability to accomplish this rests on the ability to have access to and understand the system design information.
Accordingly, it came as no surprise that the subsequent panel session on Tuesday focused in one way or another on being efficient in the system design process and/or capturing system design data in a central, model-based data repository. This theme continued in the following two days throughout many presentations on the notion of Digital Engineering as an answer.
What’s the significance of Digital Engineering, Digital Thread, and Digital Twin?
You’ve probably heard of Digital Engineering, but what does this term really mean? (In fact, Vitech President David Long recently wrote a blog post about it: Digital Engineering, Digitization, and the MBSE Disconnect.)
Digital Engineering is defined by the Office of the Deputy Assistant Secretary of Defense (System Engineering) – ODASD (SE) –as “an integrated digital approach that uses authoritative sources of systems’ data and models as a continuum across disciplines to support lifecycle activities from concept through disposal.” (Defense Acquisition Glossary 2017)
Two other terms were used throughout the conference that bear defining: Digital Thread and Digital Twin. Here again, if you had never heard these terms before, or if you were unsure of their meaning, you could easily be confused as to how or what impact these have on systems engineering overall.
Digital Thread: An extensible, configurable, and component enterprise-level analytical framework that seamlessly expedites the controlled interplay of authoritative technical data, software, information, and knowledge in the enterprise data-information-knowledge systems, based on the Digital System Model template, to inform decision makers throughout a system’s life cycle by providing the capability to access, integrate, and transform disparate data into actionable information. (The definition comes from the Defense Acquisition University Glossary.) This is a lot of words which basically mean that Digital Thread is the ability to trace or provide traceability of information as well as an integrated view of the information in the system.
Digital Twin: An integrated multi-physics, multiscale, probabilistic simulation of an as-built system, enabled by Digital Thread, that uses the best available models, sensor information, and input data to mirror and predict activities/performance over the life of its corresponding physical twin. (Again, the definition is courtesy DAU Glossary.) In order to have a Digital Twin you must have the ability to access the specification of the information describing an element together with the engineering models describing the geometry, materials, and behavior of the element.
I know the question that is on your mind as you read all of this. “How do I meet the need for Digital Engineering, Digital Thread, and Digital Twin?”
Take a deep breath and look at how the ODASD (SE) website describes Digital Engineering. It states that “Digital Engineering (also known as model-based engineering or model-based systems engineering) is an initiative developed … to streamline the way defense programs collect, retain, and share data.”
If you have been using a true model-based system engineering (MBSE) toolset, a toolset that uses an underlying database to capture system element information and uses that information to render diagram and textural views of the system design, then you are meeting the intent of Digital Engineering. A true MBSE toolset by its very architecture allows for one to accomplish Digital Threads to trace information about any element in the system design to all other elements it is related to. Finally, if you can connect the system design information in the descriptive model to the analytical model(s) that reflect the design information, then you have met the intent of having a “Digital Twin.”
GENESYS and Digital Engineering
Does Vitech GENESYS meet the requirements for Digital Engineering? GENESYS uses a SQL database to manage the system design model. Using GENESYS, you can view system design information in graphical and textual formats. As system design information is added or changed, GENESYS checks the information for completeness and consistency, and the graphic information is changed in all diagrams that are affected by the change. Additionally, GENESYS provides the ability to run various reports, including an entity specification. This provides for “one source of information on the system design” and the ability to view information in graphical and specification format.
Any entity in the system design model can be related to another entity in the system model. Building the system design in GENESYS provides for traceability from any element to all other elements in the system design that it is related to, thereby providing Digital Thread capability.
In GENESYS, we have the ability to describe constraints on the system design and relate constraints to the parametric equations relating the constraints to one another. And, we have the ability to seamlessly connect to Matlab to solve the series of equations relating to system design. GENESYS has an open Application Program Interface (API) leveraging .NET framework to allow individual users with custom models to architect their own interface to GENESYS. This provides us the ability to meet the needs of providing a Digital Twin capability. By supporting Digital Engineering with GENESYS, we are helping companies design next-generation systems in ways never thought of before.
