Levels of MBSE Capability

Posted on: November 14th, 2016 by Lou Wheatcraft No Comments

In the first part of the series, I addressed the question “Why implement MBSE?”, listing benefits for doing so as well as discussed how MBSE enables you to use measures to better manage your system development efforts.

In this second part of this series, I introduce the concept of MBSE capability levels (MCLs) and discuss the need to choose an MBSE toolset appropriate for the MCL chosen.

It is important for organizations to first decide what level of MBSE capabilities they need to help better manage the development of the systems in their specific domain and types of systems they develop.  Once they have decided on the level of SE capabilities needed, they can then do what is needed to provide those capabilities including: developing the organizational policies, processes, and procedures, selecting and procuring the SE tools that support the defined processes, and then train their people in the use of the SE tool set and processes.

It is also important to realize that this journey can be done in a series of small steps.  You don’t have to jump into SysML complex modeling at the beginning.  Start small with a electronic (vs. hard copy documents) requirement management capability with the ability to support allocation and traceability.  Then add to that the capability to manage the requirements over the lifecycle of the project, linking requirements to design, and linking requirements to verification planning artifacts.  Then add the capability to use diagrams like functional flow diagrams or context diagrams and link your requirements to those diagrams.  From there you can add the capability for SysML modeling, and over time, progress to more complex simulation grade models (only if there is some benefit to be gained from doing so.)  Thus, it is useful to define different levels of MBSE “capability”.

What specific SE capabilities you need depends on your product line, its complexity, issues you are having and want to address, your workforce knowledge and experience, the tools you use, and your organization’s processes, standard operating procedures and work instructions.

Below are proposed MBSE Capability Levels (MCLs).  Each level assumes the previous level has been experienced and surpassed.  As you move up levels, your MBSE capability increases.

  1. MCL 0: The SE lifecycle stages are stove-piped, with a focus on hardcopy, printed documents, design description documents, ICDs, CAD drawings, etc. Often there are inconsistencies between documents, it is difficult to assess completeness, configuration management is a nightmare, artifacts are not linked together, it is difficult to identify and manage dependencies.  Unfortunately, this level represents many legacy system development processes and associated shortcomings seen in today’s world of more complex systems.
  2. MCL 1: The lifecycle stages may still be still stove-piped, but more and more of the artifacts are being developed using SE tools (e.g., requirement management tools, diagraming tools, CAD tools, etc.) and are stored as datasets that are accessible by preferably more than one tool. Datasets are linked within the lifecycle stovepipe, but not necessarily across lifecycle stages.  That is, parent/child relationships are managed within the SE tools, but requirements are not linked to diagrams or design.  A minimum of attributes and associated measures is defined as they apply to the particular lifecycle stage.  Some parts of the organization (e.g., software) may be using modeling tools, but in isolation from other parts of the system architecture.
  3. MCL 2: Stovepipes are gone. Datasets are not only linked within a lifecycle stage, but linked across lifecycle stages and can be used by a range of SE tools across those stages.  Requirements are linked to the stakeholder needs and higher level requirements allocated to the system, design is linked to requirements, system verification and validation is linked to design and requirements.  There is traceability between requirements, analysis, design, verification, validation. Attributes and associated measures are used to manage the overall SE effort across all lifecycle stages.  The data available is used to generate reports, dashboards, etc. to manage the SE processes.  MOEs, MOPs, KPPs, TPMs, LIs are used to better manage the project and system engineering processes.
  4. MCL 3: Non-language-based diagramming tools are used to better understand and define the system architecture, identify interfaces, and identify dependencies. Requirements and design artifacts are linked to the diagrams. The artifacts and resulting datasets are developed, analyzed, and managed holistically as an integrated system.  The dataset represents an overall system architectural model.
  5. MCL 4: Language-based modeling tools are used. Analytical models, using a modeling language such as SysML are developed. All lifecycle artifacts are linked with the analytical model. Engineers interact with the model via various graphical and textual views of the model.
  6. MCL 5: Language-based simulation capability is tied to the analytical models.
  7. MCL 6: Actual system operational data is inputted into the analytical models and simulations. This is used for monitoring system performance and predictive anomaly identification and resolution.

Not every organization needs to be at level 4 (or higher!!)  Most organizations should strive to be at least at level 2, but are encouraged to get to level 3 or higher, that is IF there is an ROI to the organization for doing so.  Take baby steps.  You may set a goal of being at level 4 or 5, but plan out a roadmap, going from level 0 to level 1, and then increase your SE capability as in makes sense for your organization.

Choosing an Appropriate MBSE Tool Set

Currently many organizations want to “do” MBSE because that is what they are told they need to do – with the false assumption that they need to go straight to SysML modeling tools in order to say they are “doing” MBSE.   In reality, MBSE tools tend to focus on specific needs and types of artifacts.  Organizations (at the Enterprise level) need to perform trade-studies to see if the expense of purchasing a specific MBSE tool, training people to use the tool, maintaining the tool, maintaining models and other artifacts developed by the tool, etc. are going to provide a positive ROI, improved time to market, or reduce the number of warranty work and recalls.  No one would argue against efficiency and will incorporate SySML level modeling into their SE processes if it makes sense to do so.  However if it makes more sense to implement a lesser fidelity of MBSE solution, they should go that route.

If you need a detailed model that is defined via a complex modeling language that will allow you to run simulations, then you will need the proper MBSE tool set and knowledge to allow you to do this.  However, you may not need this fidelity.  Maybe you just want to better manage requirements throughout the product development lifecycle.  Maybe you want to use functional flow diagrams and context diagrams to better understand your interfaces and to better understand the functionality of a complex system and the interactions of the parts that make up that system.  Maybe you want to be able to develop requirements from these diagrams and link your requirements to these diagrams as well as link information between artifacts, and link artifacts across lifecycle processes.

Given today’s systems are increasingly complex, an MBSE tool set, including requirement management tools (RMT), diagraming tools, and modeling tools may be needed to help manage the challenges associated with these increasingly complex systems.

A MBSE tool set provides a more effective way of carrying out portions, or in some cases, all of the SE lifecycle development process. To more effectively develop systems, the MBSE tool set needs to be tailored to your organization’s needs, as evidenced by statements such as the following in NASA’s NPR 7123.1, NASA Systems Engineering Processes and Requirements (NASA 2013)  “...technical teams and individuals should use the appropriate and available sets of tools and methods to accomplish required common technical process activities. This would include the use of modeling and simulation as applicable to the product-line phase, location of the WBS model in the system structure, and the applicable phase exit criteria.

Going beyond requirements, MBSE tools can support the entire system lifestyle including design, building/coding, system verification and system validation, and sustaining engineering activities.  These tools are used to collect, link, visualize, analyze, manage, and communicate data across the system lifecycle.  The MBSE tool set allows us to produce various views of our system and create and maintain the various artifacts (documents, databases, reports, diagrams, drawings, models, etc.) needed to more effectively manage our system development efforts as shown in Figure 1.

What capabilities you need from an MBSE tool set depends on your product line, its complexity, issues you are having and want to address, and your workforce knowledge and experience. You need to understand what data best meets your needs and which set of SE tools you need to work with and manage this data.  MBE tools are like any other software application…one size does not fit all.  The MBSE tool set that is best for your organization is the tool set that meets your requirements management, systems engineering, and modeling needs.  Consider the outcomes you need as a result of using MBSE tools and the Return on Investment (ROI) resulting from these outcomes.

Before you embark on your own MBSE tool set evaluation and selection initiative, work with your management, project teams, engineering staff and other key stakeholders to determine what your organization needs to help you better manage the development of the systems in your domain.   What features and functionality do you need in a MBSE tool set so that you can effectively and efficiently manage your requirements, design, and other MBSE activities throughout your product life cycle?  Specifically, choose the MBSE tool set that supports the MCL you have decided to strive for within your organization.

For a more detailed discussion on features an MBSE tool set should have, see my blog: “Features an SE Tool Set Should Have”.

In the third part of this series, I provide guidance and a roadmap your organization can follow to implement your chosen MCL.

Comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts”  page and we will do our best to provide a timely response.

Tags: , , , , , , ,
Posted in Systems Engineering | Tagged , , , , , , , | Leave a comment

Leave a reply