A packed house of engineers at defense contractor HTii’s Lexington Park headquarters July 19-20 heard IBM experts explain details of a digital modeling process the Navy is considering to develop new weapons systems: model-based systems engineering.
The meeting at HTii of the Southern Maryland Rational User Group featured MBSE authority Gavin Arthurs and an “open lab,” where additional experts helped attendees try out Rhapsody, IBM’s MBSE application, and other programs in the company’s Rational series.
“There’s a lot of interest in MBSE among engineers we support,” said systems engineer Adam Hammett of HTii, the leader of the user group. “We had a standing-room-only crowd, and the questions asked showed they knew a lot about Rhapsody already.”
HTii provides systems engineering services using MBSE tools to NAVAIR, the Joint Strike Fighter program and multiple private sector clients.
IBM’s Arthurs discussed MBSE topics ranging from basic model definitions to examples of integrated modeling and simulation software. The combination allows an engineer to simulate the operation and testing of a digital design such as a new electric motor in a computer-generated virtual environment.
“Systems today are far too complex to build without first completely modeling all aspects of their functionality, especially their interaction with related systems and sub-systems,” Hammett said.
This interaction, known as Interoperability, has increased exponentially as technology has grown more complex, he noted. “A B-17 had only a couple of interfaces to worry about – the bombs had to fit in the racks, and the radios had to use the same frequencies.”
But he said with today’s complex systems, interoperability must be built in from the beginning, and the only way to do that is to create digital models that can be manipulated in a computer.
Arthurs provided a simple model example using a crude sketch of a house. He then broke the sketch down into an elementary model – a big box labeled “house” with lines going to and from smaller boxes representing the door, chimney, windows, roof and side.
“Now from the sketch you wouldn’t know there was a window on the back of the house,” he said. “But the model provides that additional information.”
“Ultimately a model is a database,” said Andrew Ridenour, an HTii Rhapsody user who works in systems engineering. “Parts of it can be represented on the computer screen with simple abstract elements – boxes and ovals with lines connecting them,” he said. “But what makes it much more than just a PowerPoint diagram is the linkage of these elements to the underlying database and the ability to drill down to levels of greater and greater detail and across different perspectives.
Ridenour noted that models aren’t limited to just the structural parts of the system – like roof, door and windows. “There are also behaviors, actors, events, requirements, constraints, and test cases,” he said.
As an example, he cited a conventional blueprint that shows the house structure. “But it doesn’t list the regulations the architect designed the kitchen around or explain how to use the appliances,” he said. “A model is meant to capture all that information and let engineers see the house from all perspectives. A model is many different kinds of blueprints, all in one place.”
Models are necessary because of the sheer size and complexity of modern military programs, he said. “They give us a way to keep track of system details, but at the same time simplify how we interact with those details.”
As Arthurs put it: “A model is always an abstraction where we eliminate details that aren’t essential to our purpose.”
Hammett pointed out that models have a major advantage over traditional document-centered engineering when it comes to keeping track of a project. “You can enter every bit of supporting information you have – the rationale, along with the detailed specs, drawings, and data a requirement is based on,” he said. “Even if the person responsible for the requirement has moved on, all that metadata is immediately accessible, so that everyone on a project team can be as knowledgeable as the person who wrote it originally.”
Models’ ease of access also is a major advantage when it comes to keeping track of changes, he added. “When making a change in a traditional engineering document, every part of every other document affected by that change has to be updated manually,” he said. “That’s time-consuming, and it’s easy to overlook something.”
But with MBSE, a change only has to be made one time at one place in the model; the software then automatically propagates the change to every other part of the model affected by it, he said, “and everybody on the team can see the changes immediately.”
Arthurs said the net result of these advantages is that MBSE helps all members on a development team work efficiently with a consistent focus. “Team members typically have a view of the system biased by their past experience, areas of expertise and interest in the system,” he said. “As the level of complexity increases, the opportunity for divergent mental models among the team increases.”
This divergence can be a serious problem with the traditional document-centered approach, Hammett said, but with all members of a team able to access the same model, divergence is minimized.
Said Arthurs: “Modeling helps us develop a shared vision.”