Collaboration & Alignment

[Webinar Recap] The Real Intent of MBSE – Keeping Up with Complexity

By |

The Real Intent of MBSE

In this blog, we recap a webinar discussing the real intent of MBSE (model-based system engineering.)

Today’s products are becoming increasingly complex and software intensive. This presents major challenges for organizations being able to effectively manage all the data, information, and artifacts across the lifecycle for these types of systems — and one of the key reasons that Model-Based Systems Engineering (MBSE) is fast becoming the standard approach to systems engineering for digital transformation today.

Since one size doesn’t fit all, an organization needs to assess the SE capabilities that best fit its domain, product line (degree of complexity), and culture. The level of SE capability an organization establishes needs to be tailored to the size and complexity of systems developed by the organization, whether small, medium, or large projects.

In this webinar, we will cover the following topics:

  • Challenges associated using 20th century document-based approach to Systems Engineering
  • What is MBSE?
  • What is the real intent of MBSE?
  • Is MBSE the same thing as SysML?
  • Benefits of implementing Systems Engineering from a data-centric perspective
  • How Jama Connect helps SE practitioners address these challenges

This webinar will be especially beneficial for those in the aerospace, automotive, defense, and medical industries.

Below is an abbreviated transcript and a recording of our webinar.

The Real Intent of MBSE

Joseph Pitarresi: Well, hello everyone. This is Joseph Pitarresi and I’m the senior product manager for Jama Software labs. I’m very excited about today’s topic, The Real Intent of Model Based Systems Engineering and Keeping up With Complexity. And I’m pleased to introduce our two industry experts for this webinar. First is Lou Wheatcraft, he’s the managing of Wheatland Consulting. Lou has over 50 years experience in MBSE thought leadership and his specialties are in needs and requirements, definition and management and verification and validation. Lou currently co-chairs the INCOSE Requirements Working Group, and he has consulted with global leaders in the sectors of aerospace and defense, medical devices, consumer goods, transportation, and energy.

Very pleased to have Lou with us today. Our second area expert is Jama Software’s own Cary Bryczek. Cary serves as a principal systems engineer and aerospace defense for Jama Software. She’s been with Jama Software for over eight years and has over 15 years in systems engineering leadership roles. Now, with those introductions, let’s get started. Over to you Lou.

Lou Wheatcraft: Well, thank you for having me. It’s an honor to participate in this webinar. The subject is The Real Intent of Model-Based Systems Engineering- Keeping Up With Complexity. This presentation is a follow on to the Whitepaper published by Jama in early December. Today’s increasingly complex centric systems are becoming more than norm how we practice system engineering needs to evolve to help us better develop and manage these more software centric or software intensive systems. Yesterday’s electro-mechanical systems had fewer interactions both internally and externally. Interfaces could be shown on drawings. It isn’t too long ago for a lot of our electro-mechanical systems didn’t contain a single computer chip and now today’s systems like automobiles can have over a hundred computer chips and associated embedded software and all the complexities of interaction between the software in those computer chips and with the hardware mechanical systems.

For software centric systems, internal and external interactions have increased orders of magnitude as have threats and the vulnerabilities. Critical functions in today’s software centric systems are carried out mainly by the software and really the electro-mechanical parts of the system are enablers for the softwares that carry out their key functionality. In INCOSE vision 2025, they recognize this complexity, this set of constant themes throughout the evolution of systems engineering is the ever-increasingly complexity of systems, which can be observed in terms of the number of system functions, components and interfaces and their non-linear interactions, and emerging properties. Each of these indicators, the complexities increased dramatically over the last 50 years and will continue to increase due to the capabilities that stakeholders are demanding and advancement in the technologies that enable these capabilities.

Keeping Up with Complexity

Lou Wheatcraft: This complexity presents organizations with challenges that need to be addressed. Failures can result in tremendous loss. These challenges result in increases in complexity in our systems, increases the role software has in the software architecture. So software centric, software intensive systems are the norm. Dependencies and number of interactions has dramatically increased between parts of the system. Interactions also between the system and the macro system is a part. The number of threats across the interface boundaries and vulnerabilities to those threats, dependencies between project management and the systems engineering, dependencies between system engineering and life cycle process activities and artifacts. The increases in oversight, competition, the pressure and need to reduce development time and time to market. The increases in risk, not just program and project risk, but also development risk, manufacturing, risk, system integration, system verification, system validation, and risk during operations.

And the number of projects that are over budget and experiencing schedule slippage. To address these challenges we must change how we practice system engineering. To address these challenges, it’s important projects incorporate systems thinking into all phases of product development. Projects must manage the integrated system and associate SE artifacts from beginning with the focus on the interdependencies, the parts that make up the system, interactions, both internal and external, integrated system behavior and emerging properties. And this is important because the behavior of the system is a function of the interaction of the parts, both the parts internal, but also interactions of the system within the macro system as part. When we were developing integrated system, they have emerging properties that were not indicated within our needs and requirements and relationships between the engineer and artifacts across the system life cycle. During development of our system, the different life cycle phases involved in developing products each has its own set of artifacts and these artifacts are related to each other.

We need to think about the relationships of the different life cycle processes and the resulting artifacts. And shouldn’t be developed and managed in a silo. Understanding the role of textual needs and requirements as well as diagram/models, which form is the best to communicate specific thing. It’s like two sides of the same coin. One is not sufficient. We need both the textual needs and requirements as well as we need diagrams and models as key analysis tools from which the needs and requirements are derived. We need to establish traceability between all data information across the system life cycle. So the focus of the rest of this presentation is addressing the real intent of model based systems engineering or MBSE for short. From the INCOSE System Engineering handbook, they talk about MBSE versus a Document-Centric Approach System Engineering. And they say, “In a document based system engineering approach, there’s often considerable information generated about the system that’s contained in documents and other artifacts such as specifications, interface control documents, system description documents, trade studies, analysis reports, and verification plans, procedures, and reports.

An MBSE Approach

Lou Wheatcraft: The information that obtained within these documents is often difficult to maintain and synchronize and difficult to assess in terms of quality, correctness, completeness, and consistency.” The document centric approach to system engineering, there are several key issues. The sheer volume of documentation has become overwhelming. We have a large number of documents for a project, each containing key data and information. All this has to be documented, reviewed, baseline configuration managed. Often these documents are done thoroughly at different times, and because of this, it’s nearly impossible to keep data and information in sync, current, correct, consistent resulting in no real single source approved. The vast number of documents results in cost and time overhead that consume a significant part of development cost eating into profit margins.

For projects that are still using the document centric approach system engineering, the development times and time to market are longer for many products, making the company less competitive. To avoid these issues, organizations must move from a document centric to a data centric perspective of systems engineering. The model based system engineering approach addresses many of the problems from the document centric approach to SE. From the INCOSE System Engineering handbook and the MBSE approach, much of this information is captured electronically in the system model or set of models. The system model is a primary artifact of the system engineering process. MBSE formalizes the application, the system engineering through the use of models. The degree to which this information is captured in models and maintained throughout the life cycle, depends on the scope of MBSE effort

Watch the full webinar to learn more about The Real Intent of MBSE


Jama Software
Latest posts by Jama Software (see all)