MBSE

MBSE

An Authoritative Systems Engineering Source of Truth

Model-based systems engineering, or MBSE, is a methodical way of looking at complex problems that yields tremendous insights. Rather than scattering information across multiple documents, diagrams, and spreadsheets, the knowledge is captured clearly and cohesively in an authoritative systems engineering source of truth. You’ve got one idea in one place providing the right data at the right time in the right presentation for communication and analysis.

The benefits of this approach range from lightweight to lifesaving. One of the chief benefits of MBSE is aligning the team around a shared understanding of both the problem and solution so that they can solve the right problem the right way free from unintended consequences.

Just what is MBSE?

A way to represent a system with a model

Good systems models effectively capture both the problem (requirements) and solution (architecture) in a consistent, coherent way, improving understanding and managing complexity.

A way to manage knowledge

Modeling allows for the capture of key concepts and their interrelationships at the level of detail you need across the project life cycle.

A way to improve quality and lower risk

MBSE allows you to discover and address problems early before costly defects become embedded in the design.

A way to communicate and analyze before building

Modeling enables teams to quickly grasp change impacts, communicate design intent, and analyze a system design digitally before it’s built.

Why MBSE?

Why MBSE?

Lowers costs

Model-based approaches cost 55% less and improve on-time delivery. (From a report by Sandia: Systematic Literature Review: How is Model-Based Systems Engineering Justified? By Edward R. Carroll and Robert J. Malins, published in March of 2016.)

Saves time

One model means that everyone is on the same page; the team is not coordinating disparate documents.

Reduces risk

MBSE users report a 68% reduction in defects. (From a paper by Steven Saunders of Raytheon-Australia: Deploying MBSE on a Program: Lessons Learnt, in 2011.)

Avoids waste

MBSE eliminates redundant work with one integrated model.

Features of Good MBSE

  • Considers all elements

    It considers all elements that meaningfully affect a system — from the small to the large, the parts and their interactions — providing the context and insight to make good decisions.

  • Looks at the boundaries

    It examines the boundaries of a system. What elements or other systems does the system of interest interface with, and how might these affect the system?

  • Highlights the interfaces

    Systems engineering is about defining the pieces and the interactions between those pieces to yield the desired results. Good MBSE manages not only the definition of the pieces, but also the interaction between those pieces, keeping the interfaces up-to-date and aligned.

  • Examines the 4 domains of systems engineering

    Using an MBSE approach allows you to understand the key aspects — requirements, behavior, architecture, and verification & validation — and how they interrelate. This approach yields a robust, comprehensive model.

  • Takes a level by level approach to problem solving

    Good MBSE establishes a high-level view connecting problem, solution, and verification before moving to more and more detail around areas of new requirements, unproven technologies, high risks, and high consequence of failure. This strategy of progressive elaboration enables the engineering team to generate the highest return on investment as they focus their time and energy around the critical aspects and unknowns while working within a cohesive framework.

  • Increases insight through multiple representations

    Implemented correctly, MBSE allows you to represent the system model in multiple ways, tuned to different audiences and different analytical needs, each representation generated from the same underlying data.

  • Maintains integrity over the lifecycle of a project

    MBSE captures not only the system architecture, but also the journey of design — the rationale behind decisions, changes to a system, who made those changes, and when they were made. Requirements, behavior, architecture, verification, risk, concerns, decisions — all are captured, interrelated, and managed across the entire lifecycle of a project, from cradle to grave.