Preface by VITA’s Executive Director, Jerry Gipper:

Model-based engineering (MBE) uses models to represent the structure, behavior, operation and other characteristics of a real-world system. Models can define a products form, fit and function. Switching to a model-based approach helps coordinate system design activities, satisfy stakeholder requirements and provide a significant return on investment. The purpose of MBE is to move away from error prone “document-centric” approaches to complex system design. In this month’s blog, Tram shares a real-life experience that convinced him of the value of MBE.

OK, try it now; Tram Chase, Technical Director, SimVentions

Back in 1995, I worked on an effort to integrate the Navy’s Aegis Weapon System with several other US weapon systems in a distributed network in order to test the military’s ability to collaboratively defend against enemy missiles.

At the beginning of the project, we were given a document—the Distributed Interactive Simulation (DIS) Standard—that defined the messages (fields and data types) that should be used to enable communications between the various systems. It also included some guidance in the form of sequence diagrams as to how those messages should be exchanged, e.g. when one system sends message A, another system should respond with message B.

So, we went off for a few months and built our software, and then came the big event! Each of the sites brought up its systems and software and we all connected over a network. One site played a scripted scenario that simulated incoming missiles and our system, along with everyone else’s, began sending messages all around in an effort to track and shoot down the missiles. Now, rarely did all participants make it to the end of the scenario—it could vary from 20 seconds in or 20 minutes in—but almost always there was a phone call to say that we were stopping – one of the sites, possibly us (Aegis), had crashed or run into problems.

Now, I can’t speak for all of the other nodes in the exercise, but when that happened at our site, there was always the same scene: everyone frantically stared at code and log files trying to diagnose the problem.

Then, after an on-the-fly code change or magical reboot, we would say “OK, try it now.” And then everyone started the same process over again. And we repeated this MANY times until everyone made it through the entire scenario.

This approach eventually worked, but was far from ideal. Looking back, one of the reasons I think we had so many problems was that we used a document-centric approach. Each site used the same specification (DIS) to build their system, but the process of manually implementing that specification left too much room for misinterpretation and error. (Figure1)

Figure 1: A document-centric approach can inhibit efforts when integrating a standard across different military weapons systems.

Aside from manual errors, using a document-centric approach leads to several other issues:

• Stove-piped manual workflows are painfully repeated with each change or update – Each document revision forces everyone who has adopted that standard to design and implement the necessary changes.
• Difficulty in quickly finding information – Typically, each standard will reference one or many other standards and forcing engineers to maintain an enormous set of bookmarks in multiple documents, meaning too much time is spent turning pages to find answers to questions.
• Complex data synchronization – Take message formats, or example. They are documented in the standard, again in the source code, again in the comments for that code, and then often in other project specific documents, as well. Any changes in the standard document require several manual updates be applied across several other locations.

Moving from 1995 to 2019, I’m now working on building a software tool to make it easier to integrate the hardware that goes into a Navy jet. As part of that effort, I was at a “plugfest” where vendors brought a bunch of equipment and hooked it up together to demonstrate their latest and greatest capabilities.

The scene I witnessed was three guys standing around a test chassis and backplane. They would put a card in a slot, turn on the power, wait a few minutes for some lights to flash, maybe run a software utility to check some status, turn the power off, pull the card out, put it in a different slot, and say “OK, try it now.” Seem familiar?

Surely after almost 25 years, we would have eliminated a bunch of those problems that we had back in 1995. Not really, as it turns out.  These engineers were still relying heavily on documents, a lot of labor intensive analysis, and several “OK, try it now”s before they produced a working system, just like we did in 1995.

There’s got to be a better way!

I believe we can reduce the amount of time and pain involved in integrating components by adopting a more data-centric approach. We need to capture the data contained in the owner’s manuals, spec sheets and standards in a machine-readable, common digital format and let computers do the work. By doing this, we can then:

• Quickly search for existing components that meet requirements – Repositories or libraries of data describing components can be built that allow easy searching by all sorts of criteria.
• Easily compare specifications for components – Tools can be built that can compare components and facilitate faster replacement of legacy components.
• Automate the generation of source code and documents – Tools can be built that automatically generate spec sheets, requirement documents or parts lists based on the component data. Source code can also be autogenerated and shared across the community.
• Generate model components and systems of components – Models and simulations can be built allow engineers to detect and mitigate integration issues, before buying a single piece of hardware.

Figure 2: Model-based engineering provide more efficient system development by streamlining data inputs and reducing manual errors.

And these are just some of the benefits. So, for those still reading this, I challenge you to “Try this now.” Collaborate. Work together to define a data model that describes your domain, in this case modules, backplanes, chassis, etc. And then use that data model as a basis for tools and repositories that allow engineers to focus on building great capabilities.

We need to enter the era of “Smart” standards based on data models!