MBSE

7 New Approaches for Model-Based System Engineering

By |

Systems are getting more complex, from autonomous vehicles to smart energy grids to the Internet of Things, and systems engineering must keep pace.

Creating and testing physical prototypes is too expensive and time-consuming in many cases. Systems must rely on digital models until the final stages of development. But this raises a new challenge: with so many digital models in use, how do the systems developers keep them consistent and use them together effectively?

The requirements for a new class of digital frameworks for Model-Based System Engineering (MBSE) are becoming clear, and here are seven examples.

  1. MBSE supports a single, digital model of the system, the Total System Model (TSM)

MBSE replaces document-based systems engineering, where communications between engineers and models in different disciplines are by emails, slides or spreadsheets.

  1. Federation, not centralization, is the most practical strategy for building the TSM

Few organizations want to replace all their existing software tools for requirements, architecture, design, analysis and project management, or try to centralize all system data into a single database.

Federation calls for most of the system data and engineering efforts to remain invested in existing tools, but an MBSE Platform connects them. No single tool is indispensable or the hub for all connections.

  1. The MBSE platform will be an enterprise application

Systems engineering isn’t just for systems engineers anymore. The functionality to create, use, query and visualize the connections between model elements in different tools should reside in the cloud or an on-premises server.

It should also be available to all the members of the project team, through a variety of portals: computers, tablets and even smart phones. It must also be scalable, with rapid response times, to the largest projects with millions of elements.

  1. The MBSE platform supports the full system lifecycle

The platform must support the entire system lifecycle, creating a digital thread from design to manufacturing to operations.

Connecting design data to manufacturing, quality, logistics and field deployment data provides traceability and better diagnostics. It also requires that the TSM be configuration-managed, just as many of the individual domain models are.

  1. The MBSE platform must be methodology-independent

The platform should not enforce a specific workflow, so it should support multiple use cases.

These include connections that link disparate elements in different tools, and model transformations that share information across domain boundaries. It also implies the ability to program the platform through user-written apps and scripts to support any particular organization’s engineering processes.

  1. The MBSE platform should make the system engineer’s job easier

This includes the ability to make connections automatically under rule-based guidance.

It should also provide the ability to identify and evaluate the impact of extended chains of connection — the “line of dominos” effects that systems engineers are particularly responsible for. This requires powerful visualization and pattern-matching algorithms to pull the key factors out of the mass of data.

  1. The MBSE platform should protect proprietary information

Sharing data across organizational boundaries is rarely just a technical problem. The platform should respect the access constraints of the individual repositories and control sharing through mechanisms like common models that show only the data that each side has decided to share, but are linked to, and updated by, the hidden models on both sides.

The adoptions of MBSE integration approaches like those described above have implications for individual engineering tools themselves. In this environment, success engineering software tools will be:

  • Enterprise applications with robust, standards-based APIs
  • Specialized, doing a few things with excellence rather than trying to do everything

Dirk Zwemer is President of Intercax, which is pursuing the vision discussed in this article with Syndeia — from the Greek roots for “the practice of bringing things together.” It connects model elements in a range of engineering software tools, including Jama Connect™, in a vendor-neutral framework and applies modern graph theory and technology to the challenge of visualizing and querying large systems models. Just released, Syndeia 3.2 takes important steps toward a robust server-based enterprise application and greatly expands the range of users and use cases supported. To learn more, visit www.intercax.com/syndeia for more detailed information and video demonstrations.

Latest posts by Dirk Zwemer (see all)