MBSE and SysML have spent some time growing up together – and even gotten popular together, and now they’re finding that many are confusing them as twins, or even two names for the same concept. Although both can complement each other and many organizations find systems engineering success using SysML notations in an MBSE environment, SysML is not MBSE.
Systems engineering has been formally practiced for at least four decades. While the notations, such as SysML, used to document designs is continually evolving and becoming more standardized, the primary systems engineering work products aren’t changing as dramatically. From the first years that project team members started to officially call themselves systems engineers, they have been responsible for performing systems design, integration and testing, developing requirements of various types, determining systems behavior, and building systems architecture (structure and interfaces). Systems analysis has always included trade studies along with thread, performance, and budget analyses. In addition, there has always been a systems engineering management aspect with systems engineers supporting programmatic activities, performing risk analysis, and so forth. While the notation may change with, say, activity diagrams replacing IDEF-0 diagrams, the tasks have remained essentially the same.
Irrespective of notational choices such as SysML, each aspect of systems engineering has always been inter-related. Called ‘traceability,’ systems engineers ensure design completeness by tracking the relationships between requirements, architecture, behavior, testing, and so forth. So, just as adding a bedroom to a house may impact the house’s electrical requirements, so too changing any aspect of a system design may impact many other areas. Requirements changes impact architecture, performance changes impact testing, etc.
In non-model-based environments, expert systems engineers often keep track of the big picture of a system in their heads with the assistance of documentation. These engineers are essential to project teams because they are the ones who can call out the inconsistencies early, answer almost every question that comes from the project team instantly, and communicate features of the system to any stakeholder throughout the project. Although the value-level is high, these engineers become a failure risk to the project themselves – when an engineer leaves the team – so does his or her understanding of the project.
Consequently, these leading engineers have struggled with finding ways to provide the value of what is taking place in their heads without being in all places at all times throughout a project. They begin to search for ways to record the complexity that is so well organized in their heads in a way that can be understood and used by the entire project team, to better leverage the expertise of the other team members.
So models are born. Introducing a model methodology to systems engineering, i.e., model-based systems engineering or MBSE, alleviates the impossibly complex set of relationships that must be tracked to ensure a robust system design. The model – now in a software tool rather than a head – provides a platform to find and report inconsistencies that otherwise would not be visible. Fixing these defects early reduces system design cost and increases quality.
Essentially, the software tool chosen for the job of capturing the model must mimic the engineer’s mind as closely as possible – with near endless connective abilities and the potential to understand and visualize the same concept many different ways. Vitech’s MBSE tools have been inspired by the abilities of top engineering minds, and are structured to not only demonstrate the model from a multi-faceted, fully integrated approach but to provide a common “mind” that the entire team can contribute to and work from. This approach works regardless of the notation used to describe the system, and the tools have been built to illustrate the system in multiple ways – MBSE’s friend SysML included.
For a more in-depth description, catch the recording of our webinar, Characteristics of Model-Based Systems Engineering, as it identifies multiple characteristics of MBSE. Each of these characteristics is independent of the notation used, with MBSE working equally well with SysML as with Functional Flow notations, IDEF-0, N2 or any number of other representations of the requirements, behavior, architecture, testing, and the rest of systems engineering.
