Many companies deal with the challenge to introduce MBSE. As a consultant for MBSE I often ask my customer about their objectives to apply MBSE techniques. The answers are more or less the same: the systems are getting more complex and at the same time we must decrease costs and time-to-market and increase the quality. These are good arguments to change development processes and to apply MBSE. However these arguments are not new. I would had heard the same arguments 20...

It is very well unknown and I know only a single modeling tool that explicitly supports it: the SysML activity tree. Although it is very useful and supports common systems engineering practice. What am I talking about? You may know use cases and activities to describe the use case flows. Simply spoken they describe the functions of the system from the user perspective. The following figure shows a use case and the activity of a forest fire detection system (FFDS), The...

Models do not only contain the "real" artifacts for your system, but also additional auxiliary information like notes, issues, images, and so on (metadata). It is very useful to store such information at the place where you need or create it. Switching from one tool to another is a hurdle that prevents people from looking up things or creating ones. As a result many little deficiencies occur that lead in summary to less quality, more effort and costs. My previous post...

The extended system context describes the system interfaces and the detailed connection to the system actors and to the internal parts of the actors. In the previous post How to model a simple system context with SysML I've written about system context in general and the simple edition of system context that is simply spoken just a list of external systems and human actors who interacts with the system under development. The extended system context adds information about the interfaces at the...

The system context defines the system boundary and all system actors - humans and external systems - that interact with the system under development. It is one of the most important parts of the system model. Many artifacts of the system specification and architecture are relative defined to the definition of the system. Every system behavior and structural element is completely inside the system and not covered by any system actor. If you change the system boundary, you must also change the...

How to relate requirements and architecture on different abstraction levels The SYSMOD zigzag pattern describes the different levels of abstractions and the relationship between requirements and architecture. [caption id="attachment_135" align="aligncenter" width="584" caption="The SYSMOD-Zigzag-Pattern"][/caption] Your system requirements do not start at the very top of the levels, i.e. they already include some technical decisions. The base architecture is the architecture one level above your top level requirements. The following figure shows a simple base architecture of a forest fire detection system (FFDS). [caption id="attachment_406" align="aligncenter" width="469"...

In a previous post I've described an approach how to model variants with SysML (Variant Modeling with SysML). Modeling variants leads to a model that represents a multidimensional configuration space. It is a description of each variant, the common elements and the relationships between them in a single model. A single configuration is a valid selection of variants that together with the common elements represents a complete system (in a specific configuration). Today unfortunately there is no explicit tool support in...

The OMG has published the new SysML version 1.3. The specification document is available on the OMG website. You can also download a version with change bars to see the differences to the previous version. The new version reflects feedback from the industry using SysML. In the SysML working group we've done major changes to the port elements that are often an issue doing model based systems engineering with SysML. Read my previous post What's new in SysML to find out...

On the first view it seems to be simple to define the package structure of a SysML model. However you'll often get problems with a implicit built structure. A model has many - orthogonal - aspects and abstraction layers that could be mapped into the package structure, e.g. domain, modeling, or organizational aspects. You can easily mix up the aspects. The MBSE Challenge Team SE^2 for Telescope Modeling describes a best practice for the package structure in the MBSE Cookbook. The...

I often hear arguments against SysML that the diagrams are not suitable for the stakeholder concerns. For example it is not a good idea to choose the requirements diagram to show thousands of requirements or a block definition diagram to show the complete mapping of the functional to the physical architecture with allocate relationships. It can’t be mentioned enough: You must differentiate between the diagram and the repository. Although a modeler sees the model through the diagram, the most important part...