8 min read

A Use Case for Digital Engineering

A Use Case for Digital Engineering

Our Approach to Digital Engineering

SPEC Innovations takes a unique approach to digital engineering (DE). We began by developing a seamless product, Innoslate, that spans all aspects of systems engineering and program management. We call that “horizontal integration.” This approach has provided a domain-independent way to optimize cost, schedule, and performance while mitigating risk throughout the product lifecycle for systems of systems.

Our next step in digital engineering provides interoperability from the systems engineering domain to the design engineering domains throughout the lifecycle. We call this “vertical integration.” To accurately perform this vertical integration we need to identify the information needed by each design engineering modeling tool and the output from each of these tools.

We should be able to provide the specific inputs required using Innoslate/LML’s ontology with limited extensions. Most of the values for these inputs can be captured as Characteristics or Measures and then provided directly to the tool. We have done this as an example with LabView for a hardware-in-the-loop (HWIL) demonstration using a hardware mockup of a CubeSAT.

We should also identify the specific outputs from each tool to identify how they affect the decision-making process at the higher levels. This output from the design engineering tools may take the form of a curve or distribution that affects the overall mission/system-level simulation developed in Innoslate. An example of that would be to use a high-fidelity simulation, such as Riverbed (formerly OPNET), to characterize the latency and capacity of a network. These limitations would then be used in the Innoslate simulator to assess the impact of these potential delays on the overall mission or system performance using Innoslate’s simulators.

Note that in the cases above, there was no reason to directly interface through file transfers or APIs the information. Having an “air gap” allows for a more complete analysis of the detailed models before “feeding” the mission/system simulation. We need to make sure any digital engineering solution we develop avoids the famous, “garbage in - garbage out” problem.


Innoslate's Digital Engineering Features

SPEC Innovations has been following the Digital Thread/Digital Twin initiative by DASD(SE) since its inception. Below are the Digital Thread Posters presented at the AIAA SciTech Conference in January 2018. These posters have previously been shown at the 2017 NDIA SE Division Conference. We will use the questions from these posters to show the Innoslate approach to Digital Engineering.


Development, Integration, and/or Curation of Models

Innoslate provides modeling capabilities across many languages/frameworks, including SysML, LML, some UML, and some IDEF. It also provides the capability to create documents, with diagrams from the tool embedded in the document and updated as those diagrams are updated.

Screenshot 2023-10-10 155724


The modeling is done in one or many projects. Models between projects can be shared using the cross-project relationships available within the tool. Import/export of XML is also available. 

Curation can be accomplished using Artifacts, Baselining documents, and export of models via XML (which can in turn be uploaded as Artifacts within the database). The information can be tagged using labels and searched for using the complex search capability.


Use of Models to Communicate, Collaborate, & Perform Model-Driven Lifecycle Activities

Innoslate® provides a means to author models in one language, such as SysML, and then display the information in other forms (e.g., LML, IDEF, etc.). The use of a common ontology (LML) that has been mapped to other languages (SysML) and Frameworks (DoDAF/DM2, IDEF0), enables this capability. Thus information can be communicated in a form that any stakeholder can understand and assimilate.

Innoslate® was designed as a collaboration tool. All users of a project see the same database at the same time. Real-time indicators show who is looking at what information independent of their view of that information. If an item is changed, a refresh indicator will appear. A built-in Chat (private and group) capability is also available to enable communications between users.

Screenshot 2023-10-10 160127

Innoslate's real-time indicators and chat enable collaboration around the world


LML and Innoslate® support the entire lifecycle from concept development through disposal. It contains the capability to conduct program and test planning, CONOPS development, requirements analysis and management, modeling and simulation (discrete event and Monte Carlo), and verification through the Test Center. It also supports program management functions, such as Risk and Issue tracking, WBS development, capturing of decisions, and cost and schedule generation from business processes. Resource modeling and other constraints are also available via the tool. It has been used in every phase of the lifecycle.


Implements the Authoritative Source of Truth Concept

Since the tool generates the diagrams and other views of the information from the database, it acts as a single source of “truth.” Since this database can be virtualized, it can grow as large as the hardware and SQL Server will allow. With cross-project relationships and permissions, we can also compartment information as needed.


Use Authoritative Source of Truth to Produce Digital Artifacts, Support Reviews, and Inform Decisions

All artifacts (diagrams, reports, exports) come from a single database, thus all artifacts produced from the tool will represent the state of the information at their time of production.

Model-Based Reviews (MBRs) can be accomplished using the tool’s commenting feature (available at the object level and accessible from any diagram or view). MBRs have been performed using the tool for all the NASA milestone reviews. This capability was demonstrated to the NDIA M&S Committee in February 2014.

A Decision entity class is available within the tool to facilitate the decision process, but all facets of the tool help inform decisions, particularly the Requirements Quality Checker and Intelligence Views, which use NLP technology to evaluate the quality of the modeling. The simulators also aid in verifying the processes.

Using a web interface makes the human-machine interface easier and more intuitive, plus it takes advantage of built-in browser tools, such as spelling and grammar checking. The underlying language (LML) provides explicit decision points that can be allocated to either the human or the machine, thus making the modeling of these HAI processes more clear and complete. The Java SDK and REST APIs also offer third parties the capability to design and experiment with different user interfaces. We call this “Architecture to Operations,” a paper that was presented at the 2017 NDIA conference.


Infusion of Technological Innovations to Enable the End-to-End Digital Enterprise

Innoslate® was designed for the application of new technologies and innovations for the digital enterprise. It Innoslate® was designed for the application of new technologies and innovations for the digital enterprise. It was one of the first systems engineering tools to use cloud computing and a web front-end. Currently, Innoslate® has applied Natural Language Processing (NLP) technology to check the quality of requirements, identify modeling issues (Intelligence View), and assist in the traceability of entities (Traceability Assist and Suspect Assist). With the use of the JavaScript interface, the simulator can use API calls to other web services and bring that information into the simulation. Also, the Java SDK and REST APIs enable greater integration of new technologies into Innoslate® by third parties.


Development, Maturation, and/or Use of Digital Engineering IT Infrastructures

Being cloud-based and on all the major commercial cloud environments (Amazon AWS, Google AppEngine, and Microsoft Azure), as well as classified clouds, such as NSERC and C2S, enables Innoslate® to fit into the modern IT infrastructures that will have to be used for digital engineering. Innoslate® was also designed with scalability in mind. Digital engineering will require the capturing and management of Exobytes of data. Scalability will become critical to that environment.


Development, Maturation, and/or Use of Digital Engineering Methodologies

Innoslate® can support any methodology and be used to model processes and other aspects of those methodologies. Workflow can also be used to enforce processes.

Screenshot 2023-10-10 161737

Innoslate's real-time indicators and chat enable collaboration around the world


Innoslate Best Practices

Innoslate® currently uses best practices identified by work done through the Naval Postgraduate School and Stevens Institute of Technology as the basis for the heuristics used in Intelligence View. Additional best practices can be captured as a document in Documents View for sharing with other projects in the organization.

Screenshot 2023-10-11 095320

Intelligence View enforces best practices in digital engineering modeling


Accountability to Measure & Facilitate Improvement of Tangible Results

Since Innoslate® automatically captures all change information, these History files can be mined to identify ways to improve digital engineering practices. The Activity Feed on the dashboard also allows managers to see who is changing what. Workflow provides a means to control the changes in the status of requirements, issues, and any other entity class in the tool.

Screenshot 2023-10-11 095724

Innoslate tracks the change history of every entity


Visualizes Modularity of the System

Figure 1. shows a SysML Internal Block Diagram (IBD) for the Innoslate modular architecture. Plugins are viewpoints of the Innoslate database. Plugin features include:

  • Not a standalone application (requires Innoslate Core)
  • All authentication is through Innoslate Core with the options for:
    • Single-Sign-On CAC (Default)
    • Native Email/Password (Optional)
    • LDAP (Optional)
  • All data is stored in the U.S. Government or commercially managed MSSQL database using Innoslate Core
  • Innoslate REST API facilitates plugin data exchange

Screenshot 2023-10-11 100227

Innoslate Modularity


Identifies & Visualizes System Components & Interfaces

Innoslate® provides many different diagrams to visualize the system's components and interfaces, including the Asset Diagram (LML), Internal Block Diagram (SysML), and N2 Chart. All these diagrams use the same ontological elements: Assets for the components and Conduits for the interfaces. Data flows (Input/Output entities) can be allocated to the Conduits. These data flows have “size” (which can be a distribution) and the Conduits have “capacity” and “latency” attributes as well. These attributes are used in the simulators to constrain the functional model, thus affecting the overall system performance.


Screenshot 2023-10-11 101022

Innoslate's unique Physical I/O Diagram shows Assets, Conduits, and I/Os in one chart


In addition, Innoslate® provides a CAD Viewer to view .stl or .obj files, which are standard output formats from CAD tools. If the .obj file is used, the objects in the file can be translated into Innoslate Asset entities and linked back to the drawing.


Visualizes Modularity at Different Levels in the System

The underlying language (LML) provides an ontology where all classes of information are decomposable. This capability enables the modeling to be performed at any and all levels necessary. Innoslate® also supports cross-project relationships, so that each level can be modeled separately, if desired, and then shared with other models. This modularity will become critical when concerned with the sharing of proprietary information. Users who do not have permission to see information from a particular project will not see that information if it is included in another project using the cross-project relationships. A redaction bar shows up in its place.

Screenshot 2023-10-11 101331

Innoslate permissions and cross-project relationships enable the use of information from other projects while protecting that information


Visualizes the Impacts of Interfaces With Other Systems

This visualization occurs with any of the physical diagrams. Again, if cross-project relationships are used, you can see those specific interfaces. Another visualization tool is the Spider Diagram. Since Innoslate® uses relationships to capture the interfaces, the Spider Diagram shows those related elements as well.


Determines Interoperability

Since interoperability requires interfaces at many levels, Innoslate® provides the means to identify those interfaces at every level. The fact that all the drawings are generated from the data will allow the analyst to see how the information connects. Further research in this area is also feasible and may be yet another place where graph theory and NLP technologies can be used to provide more automated heuristics.


Captures Linkages Between Hardware & Software

Innoslate® provides the means to identify any interfaces between hardware and software as well. They are both (along with people) considered “Assets” in the ontology. Assets can have Conduits or Logical Connections between each other. So, if the modeler does not want to use the Conduit, they could use the Logical connection for this purpose. And, of course, other relationships can be provided using the Schema Editor.


Provides Application Programming Interfaces to Use Custom Applications

Innoslate® comes with a complete set of APIs, including Java, REST, and for Enterprise users, JavaScript. These APIs are used by Innoslate® developers as well, so they are rarely deprecated. We have developed completely new user interfaces for Innoslate® to mimic legacy tools using these APIs.


Enables Data Transfer From One Model Construct to Another

The APIs provide a means to “put” or “get” information and can provide this function. Other data transfer mechanisms of models include the XML and XMI importers, along with Word, CSV, and Plain Text import capabilities.


Captures Standards Info for System Interfaces & Components

Standards can be captured as Artifacts and decomposed into Statements and Requirements. Those standards can then be easily related to any other information in the database, including interfaces (Conduits) and components (Assets).


Tests for Standards Compliance

Innoslate® provides the Traceability Assistant as part of the Traceability Matrix. This matrix and assistant can be used with the standards trace to interfaces and components to help identify that the standards are being met.

In addition, when rules are available, Innoslate diagrams, such as the IDEF0, have the tools to indicate when errors occur. For example, when the number of boxes exceeds six on the diagram, this violates one of the IDEF0 rules (must have between 3 and 6 functions on a graph).

Screenshot 2023-10-11 102358

Innoslate rule checking aids the modeler in meeting requirements


Intelligence View checks the entire model for best practices, using 68 tailorable heuristics, developed from work by the US Naval Postgraduate School.


Tests for Verifies Modularity & Openness

These criteria can be captured as part of the Test Center’s Test Cases and results. If criteria can be developed for these, SPEC would be interested in using those criteria as part of its Intelligence View, as well.

Screenshot 2023-10-11 102650


4 Ways Innoslate Can Prevent Bridge Disasters With MBSE

4 Ways Innoslate Can Prevent Bridge Disasters With MBSE

The tragic Baltimore Bridge accident in March necessitates improvements to prevent similar incidents in the future. Dr. Corren McCoy, Chief Data...

Read More
Rethinking Requirements Derivation: Part 2

Rethinking Requirements Derivation: Part 2

By John Fitch, for Project Performance International (PPI) [Fitch, John. “Rethinking Requirements Derivation: Part 2.” PPI Systems Engineering...

Read More
Rethinking Requirements Derivation: Part 1

Rethinking Requirements Derivation: Part 1

By John Fitch, for Project Performance International (PPI) [Fitch, John. “Rethinking Requirements Derivation: Part 1.” PPI Systems Engineering...

Read More