modeling language Archives

With the trend of organizations practicing Systems Engineering to move towards what is referred to as “Model-based Systems Engineering” (MBSE), there are various perspectives as to just what is meant by MBSE. Similar to the old story of the blind men and the elephant, MBSE cannot be effectively practiced when viewed from just one perspective (requirements, models, patterns, standards, industry specific application, etc.). To successfully practice MBSE, wise systems engineers recognize and use each perspective as appropriate to their specific needs. Based on these needs, they choose the appropriate capabilities, tools, and visualizations that will meet their needs. One size doesn’t fit all.

The degree to which the data and information is captured and managed is driven by the needs of the organization and projects from a business and technical perspective based on the size and complexity of their systems, their product line, culture, processes, workforce, their diversity and complexity of supply chains, and types of engineering information that comprises a technical baseline for their system of interest.

SysML and other language-based modeling tools

MBSE is a concept that is maturing and means different things to different people. To some practitioners, MBSE is equated to the use of SysML and other language-based modeling tools. With these tools, practitioners can develop detailed analytical, behavior, and architectural models of a system, with a primary focus of functionality, performance, and interactions between various entities defined to be part of the system being modeled. These types of models are useful tools for system analysis, developing simulations, and creating what is referred to as a “digital twin”.

To others, what they are calling MBSE is really Model-based Design (MBD). MBD design starts with a set of requirements and using various language-based modeling tools to architect and design a system, develop simulations to assess the behavior of the system, and then develop a set of design output specifications to which the system is built or coded. Often the MBD activities are completed in a silo separate from the other SE lifecycle process activities.

MBSE is much more than SysML!

The above language-based modeling approaches do not address the true intent of MBSE. While these capabilities can be useful, MBSE is much more than using language-based modeling tool to develop analytical, logical, behavioral, and architectural models.

The goal of an organization, when adopting MBSE, is to move from a document-centric to a data-centric practice of Systems Engineering (SE) so as to realize the real intent of MBSE which is to develop, maintain, and manage a data and information model of the system being developed along with a model of all the system life cycle process activities, resulting artifacts, and their underlying data and information.

MBSE is not really about any particular type of model or visualization of data and information – whether that be a model, diagram, report, document, sets of needs, or sets of requirements – but is about the underlying data and information model that enables consistency across the data and information that represents the various models and visualizations.

The data and information model that must be developed should represent SE artifacts generated during the product development process activities across all lifecycle stages. Information associated with the elicitation of stakeholder needs and requirements, lifecycle concepts definition, analysis, and maturation, deriving an integrated set of textual needs, transforming those needs into sets of textual design input requirements, verification the system meets those requirements, and validation that the system meets the needs must also be captured within the data and information model. In addition, relationships and dependencies of the individual data items must be captured (traceability) in order to help determine and ensure consistency across all lifecycle stages, prove compliance with standards and regulations, as well as help assess the impact of changes made to any of the data items across all lifecycle stages.

Can my organization adopt MBSE without using SysML or other language-based tools?

Sadly, there are many organizations that have a misconception concerning what the true intent of MBSE is – as a result they think that MBSE is not for them.

In a recent conversation with a system engineer, I was told that her organization was not going to adopt MBSE because they don’t see the utility of developing complex SysML models of their products. In addition, she noted that to do so would require a change in how their managers and engineers think based on the SysML standard as to how to construct models and the specific terminology used. To them SysML modeling is not intuitive, has a large learning curve, and has little apparent utility and return on investment – for their organization, especially for their product line that has a minimum amount of software and complexity.

My response to her was: MBSE is not SysML!

I told her what the true intent of MBSE is to practice systems engineering with a data-centric perspective, establishing the capability to capture, manage, access data, and manage the interrelationships between SE work products can be accomplished through a variety of methodologies, which range from the establishment of a single relational database to a virtually integrated, but distributed, database by means of a federation (or data map/index) of disparate data sources.

The resulting data and information model can be captured using a variety of SE tools and applications. To effectively manage our ever increasing complex, systems there are benefits to managing this underlying data and information in such a way it can be shared across the system life cycle process activities, shared between the various SE tools used to create and manage this data and information, and shared between organizations involved in the development and operations of the system of interest. This sharing will help ensure correctness, consistency, and completeness of the data and information typical of our ever increasingly complex systems as well as enable collaboration between not only the project team members, but also external stakeholders involved in the development of the system.

Parting Thoughts

The answer to the question: “Can my organization adopt MBSE without using SysML or other language-based tools?” is YES!

Since one size doesn’t fit all, an organization must assess their needs and produce an MBSE solution that best fits its domain, product line (degree of complexity), and culture. As a minimum, they need to establish a capability to define and manage needs, requirements, verification, and validation across the system lifecycle. These capabilities will allow the organization to build a data and information model of their products and systems engineering process activities and artifacts.

Based on these needs and desired capabilities, the organization can choose the appropriate SE toolset, update their processes, and train their people in these tools and processes.

Stay tuned for more to come from Lou Wheatcraft in the coming months.

Models are ubiquitous in product development. There are many different models, including CAD models, systems models and simulation models. Very often, only a small group of experts creates and uses a specific model. This is not surprising; one definition of “model” is “a simplified representation of something for a purpose.” But this hinders collaboration, as one group’s model might be meaningless to another group.

Does this mean that models are doomed to be confined to silos? Of course not, but it takes active work to make them accessible and useful for every stakeholder who might benefit from them. For innovative companies, ensuring that models serve all stakeholders is imperative to unlocking the benefits of modeling and justifying the initial investment.

Identify Friction, Define Value

Before you can solve a problem, you need to recognize it.

If you are reading this article, chances are you already have something in mind (“Why do I have to explain every detail of this SysML IBD to my manager?”). Be sure to concisely identify the problem: Which aspect of the SysML model does your manager need to understand and why?

Efficiency is often a concern. For instance, a change request from a stakeholder may result in multiple, manual, error-prone updates across your models. If this applies, try to quantify the amount of effort exerted through manual transcription of information from one model to another.

In short, take the time to identify the problem to be solved, document it and discuss it with your stakeholders.

Four techniques to make models more valuable

Once you understand the value of broadening the use of your models, you can search for the right solution. The following four techniques allow you to boost the value of the model that you already have and maintain.

1. Extract KPIs

One of the easiest approaches for leveraging models is to generate key performance indicators (KPIs) for your stakeholders. This is particularly useful for reporting up to stakeholders who are not really interested in the details. KPIs are often metrics like progress, burndown rate or potential bottlenecks.

Some modeling tools are already capable of generating KPIs that are useful for other stakeholders. In particular, software tools often feature metrics like code coverage, burndown rate, defect age, and others right out of the box.

A far greater number of modeling tools, on the other hand, have no features of this kind, but do at least have scripting facilities that allow you to generate metrics. Of course, you need to know what you are looking for.

2. Produce Customized Views

Related to KPIs is the creation of views that are acceptable to your stakeholders. In contrast to KPIs, views typically contain relevant information, not just aggregated data. Most tools include reporting facilities powerful enough to produce reports that stakeholders will accept.

As an example, I once worked on a project where we defined the requirements in UML, a language that the customer and the product manager were not familiar with. By carefully building a custom report, we could generate Word documents that the stakeholders accepted and embraced. I actually wrote about this project for IREB’s Requirements Engineering Magazine.

Keep in mind that you will never be able to generate a view as elegant as a hand-crafted artifact. Depending on the capabilities of the report generator, you may still have to invest in teaching the stakeholders how to read and understand the deliverable.

3. Teach the Stakeholders to Read

This is obvious, but often forgotten: If you cannot completely hide the model behind a view that’s easy for the stakeholders to understand, then you must teach them how to read the modeling notation you use. Stakeholders don’t need to learn the complete modeling language, only certain aspects; depending on your situation, a one-hour training session could be sufficient.

Some organizations understand the need to teach the modeling language but send everybody — both creators and readers — to the same training. Since standard trainings focus on creation, this forces all stakeholders to sit through a time-consuming training that only a few of them actually need.

4. Integrations

The most elegant and effective (but also expensive) approach to broadening the use of models is integrating them.

For instance, most products start with textual stakeholder requirements. These get refined into system requirements and eventually design. Textual requirements are typically also modeled, but with a simple data model consisting of entities and relationships. At some point, however, you may want to switch to a different systems model, for instance by using SysML. Ideally, the two models are linked, so that you have end-to-end traceability from your requirements tool to your systems modeling tool.

Using integrated tools gives you two advantages. First, stakeholders operate in an environment that they are familiar with. Second, integration allows changes in one model to propagate to another model. This is a big advantage that can remove a lot of friction.

While there are solutions that promise “one model for all,” in practice, you end up with a monolithic tool that is mediocre. In practice, an integrated “best of breed” tool chain performs better and poses less risk, as individual components can be exchanged if needed. For more on this, see our blog post, “7 New Approaches for Model-Based System Engineering.”

Plan and Buy, Don’t Grow and Build

All too often, we see product development environments that grew over years or even decades. Tools were added without giving thought to integration beforehand, and brittle scripts hold everything together. This was fine 20 years ago, but in today’s world, it’s a severe competitive disadvantage.

The four techniques described above are tactics, but they need to be applied in the context of an overarching modeling strategy. From this you can derive proper model and tool architectures.

When selecting new modeling languages and corresponding tools, attention should be given to the use cases they need to support. More importantly, new modeling languages and tools need to support all stakeholders’ use cases, not just their direct users’. All use cases should support one of these business priorities: Improve quality, accelerate development or use resources more efficiently.

For all four tactics, the existing off-the-shelf solutions are preferable to self-build solutions. After all, you’re busy creating complex products in a competitive market; you don’t want to waste resources building internal software.

Key takeaways:

KPIs can be produced to help inform your product development process.
A good modeling tool should provide facilities for customized views (web-based, custom reports or otherwise). There are also third-party reporting tools that connect directly to data sources.
If you have more than a handful of stakeholders, outsource training courses for reading models. There are excellent training providers for all standardized modeling languages. Make sure that you provide tailored training, even if it is more expensive than canned trainings.
Integration is hard, so rather than writing brittle scripts, use an existing integration hub like Tasktop. This solutions is robust and easy to configure.

The good news is that you can transform your product development iteratively. As your business evolves, make sure that each upgrade aligns with your modeling strategy. You will unlock new value from your existing models in no time.

If these ideas resonate with you, check out our whitepaper, “Systems Engineering and Development” for thoughts on building better products, with input provided by the author of this post, Michael Jastram.

Tag Archive for: modeling language