New views for SysML

Posted on 14. May 2012 by Weilkiti

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 is the repository. The repository contains all data of the model. The diagrams are only views on the repository. You can delete all your diagrams and still have the information in the repository. You can compare it with a spreadsheet tool like Excel. The important information is in the rows and cells of your spreadsheet. You can create line charts, block charts, and so on, to display the information. The charts show only a cut-out of your information and you don’t loose it when you delete the charts. That doesn’t mean that charts and diagrams have no value.

If the SysML diagrams doesn’t suit your needs than simply choose another view. SysML itself provides two more views: tabular and matrix views. Most modeling tools have implemented them. The following figure shows a matrix in the modeling tool MagicDraw of the relationships between functional groups and activities (see the method for functional architectures for systems (FAS method) details: http://www.fas-method.org).

SysML Matrix Example: Functional groups of the FAS method (source: http://www.fas-method.org)

In addition in most modeling tools it is easy to export model information to Excel to provide table or matrix views on the data. For example the prototype of a variant configurator (see the blog post about variant modeling with SysML for details).

SYSMOD Variant Configurator (prototype)

Conclusion

First think about the stakeholder concerns and how to address them with a view. Second check if SysML provides the view. If not try to implement the view with simple tool extensions or tool chains. There are more views for SysML than the 9 nine diagram types.

Variant Modeling with SysML

Posted on 7. May 2012 by Weilkiti

PDF

Many systems exist in different configurations. A product line, a custom product or different designs for trade-off studies. The current version 1.2 of SysML doesn’t provide explicit built-in language constructs to model variants. The profile mechanis of SysML can be used to extend SysML with a concept for variant modeling.

I’ve defined a simple variant profile that consists of three core stereotypes and some additional optional extensions. The core stereotypes of the SYSMOD variant profile are:

A variation point marks a core element as a docking point for a variant element. A core element is an element that is valid for all variants.
A variation contains a set of variants that have a common discriminator.
A variant is a complete set of variant elements that varies the system according to the variation discriminator. A variant is also known as a feature of the system.

Variant modeling example with SYSMOD profile

At least one element in the variant package is connected with the variation point. The relationship is typically a generalization, but could also be another one, e.g. a derive relationship between requirements.

Maybe you already know the common feature trees to describe variations (e.g. FODA). You can also use SysML with the SYSMOD variant profile to create feature trees:

SYSMOD variant example: Variant feature tree

OPTIONAL ADDITIONAL VARIANT ELEMENTS

There are two new elements in the variant feature tree to add constraints to the possible feature configurations. {xor} and {requires} are SysML constraints to model rules between variants of the same or different variations. In our example the password-based customer identification requires a visual user interface, e.g. some kind of a display. And it is not allowed to select the barcode and the fingerprint customer identification feature at the same time ({xor}, exclusive or).

The min/max values are properties of the variation stereotype. They control the number of variants of the variation that can be selected for a single system configuration. For both variations in our example you must select at least one feature, but could also select two of them, e.g. a system that provides two different ways of customer identification.

Finally we need a model element to store a single system configuration. Unfortunately the current SysML version 1.2 doesn’t have a generic grouping mechanism. There are some ideas in the SysML working group of the OMG to add such a construct in a future SysML version. I use a stereotyped block with trace relationships to define a system configuration:

SYSMOD system configuration example

Although the stereotypes are simple and powerful it’s a challenge to handle the complexity of the model. Even a system model without variants could be a challenge. With variants it is a multidimensional configuration space. Special views, reports and model transformations are helpful to manage the complexity.

Problems, introduction and opportunities of MBSE

Posted on 27. April 2012 by Weilkiti

PDF

Location of Graz Symposium Virtual Vehicle Development (Casino Congress)

In my last post I’ve reported from my visit of the Graz Symposium Virtual Vehicle Development. In my workshop at the symposium I asked the participants about

the problems that are solved by MBSE.
what must be done/what we need to introduce MBSE in the organization.
the opportunities of MBSE.

We had very interesting discussions about the three points. I’d like to proceed the discussion here in the blog and hope that I’ll get some input from you!

Here are some good starting points from the workshop session in Graz:

Project Problems that are solved by MBSE

Intransparency
No system thinking
Hard to manage complexity
Abstraction muddle
No traceability
Inconsistencies
Redundancies

What must be done/what we need to introduce MBSE in the organization

MBSE training of the engineers
MBSE as a profession
Views for discipline-specific engineers, e.g. mechanical engineers
Change of organizational structures
Interdisciplinary processes
Templates and Pattern
Configuration management of models
Commercial model libraries
Iterative introduction of MBSE

opportunities of MBSE

Information management of expert knowledge
Integration of suppliers
Integration of other engineering methods (FMEA, FTA, …)
Reusability
Traceability
Automated tests
Reduced costs, higher quality, decreased time-to-marked

Now it’s your turn! I and the MBSE community appreciate your opion!

Thanks,
Tim

MBSE meets Virtual Vehicle Development

Posted on 19. April 2012 by Weilkiti

PDF

5. Graz Symposium Virtual Vehicle Virtual Vehicle development is an exciting new technology. This week I’ve visited the 5^th Graz Symposium Virtual Vehicle in Graz (Austria). I was very impressed by the engineering methods & tools that were already reality. An important missing link for the virtual vehicle development is the combination of all the single models
and simulations in a comprehensive system model. MBSE is definitely an enabler for the virtual vehicle and essential for the automotive industry to handle the incredible challenges they were facing in the next year.

There is a huge demand for MBSE. Again it shows that it’s a hot race between existing capabilities of MBSE and the demand of the industry. We must keep moving at high speed to improve the MBSE methods & tools. The INCOSE challenge and activity teams are an important piece for this task.

The conference chair of the symposium invited me to moderate the MBSE Action Table. Ca. 15 automotive experts discussed 90 minutes about the challenges and opportunities of MBSE. I remember the following key outcomes of the discussion:

The system model does not replace existing models, but integrates them on the system level (requirements model, CAD, Modelica, and so on).
MBSE requires organizational changes.
Broad MBSE knowledge is missing in the automotive domain and MBSE is not sufficiently teached at universities.
MBSE enables virtual vehicle development.
MBSE enables interdisciplinary communication.
MBSE is important for safety aspects, e.g. regulatory rules from ISO 26262 (Road vehicles – Functional safety).
It is unclear how MBSE changes the traditional engineering roles like mechanical engineering, electrical engineering, and so on.
The mindset of MBSE is hard to understand for mechanical engineers.
We need interoperability standards for data exchange between different engineering tools and the system model tool.

I’ve enjoyed the discussion very much. Thanks to all contributors.

Crash test simulation (Source: Argonne National Laboratory)

Open source MBSE Plugin for MagicDraw with SysML

Posted on 13. April 2012 by Weilkiti

PDF

A message from the INCOSE Telescope modeling challenge team:

The INCOSE Telescope modeling challenge team releases version 1.1. of its MBSE plugin for MagicDraw with SysML: https://sourceforge.net/projects/mbse4md/

Support for more productive Model Based Systems Engineering, following the recommendations in the Cookbook of the INCOSE SE2 Challenge team.
The Plugin for the MagicDraw modelling tool provides support for model based document generation which ties together system model and documents to keep them up to date and consistent, using a AWYSIWYG editor in MagicDraw.
It provides basic support to model variants and extract variants from a system model.
It provides support to generate organizational structures according to the SE2 Cookbook recommendations.
It provides basic pattern based support to reason on a system model, for example to extract numbers like total power, cost, power consumption for a given product tree

The MBSE plugin for MagicDraw requires MagicDraw 17.0 SP4 or higher with an installed SysML plugin 17.0 SP5 or higher. Installation instructions can be found in the file ReadMe.txt in the download area as well as the corresponding UMs.

Another open source MBSE plugin for MagicDraw is published by the FAS working group: https://www.sourceforge.net/projects/fas4md.

Next edition of my MBSE book

Posted on 10. April 2012 by Weilkiti

PDF

Since a few months I work on the next edition of my MBSE book “Systems Engineering with SysML/UML”. I plan to publish it in the first quarter of 2013. It’ll be the third edition of my German version. So far I have no plans for the English version of the book.

New content will be:

Updates to the MBSE process SYSMOD
SysML 1.3 or SysML 1.4
Preparation guide for the OMG Certified Systems Modeling Professional certification exam (OCSMP)
Alignment with my upcoming book about system architectures (I’ll post details about the work in progress in this blog).

I’ve gotten a lot of great feedback about my book from you. I’ll consider it for my next edition. You still have the chance to send my some helpful hints I should incorporate in the next version. Don’t hesitate to contact me: twe(at)system-modeling.com. Thanks!

What’s new in SysML 1.3

Posted on 2. April 2012 by Weilkiti

PDF

The newest version 1.3 of the SysML will be published in a few weeks. The development of the version 1.3 already finished last year and we currently work on the next version 1.4. I’ll report on the work for the 1.4 version in a separate post in the near future.

Typically the dot versions of SysML contain only minor changes. Anyhow the SysML 1.3 comes with many changes in the area of ports. The basic concept is still the same. There are “normal” ports to provide and request features and there are flow ports to specify the flow of things inside and outside of a block. New is the implementation of the concept and the concepts of proxy and nested ports. I give you a short summary of the main changes of the port concept that are relevant for the user.

Implementation

The flow specification is deprecated in SysML 1.3. Instead a block could have flow properties to specify the items that could flow between a block and its environment. A block could also have provided and requested features, i.e. operations and properties. Using provided and requested operations makes the standard UML interface element and the irritating ball and socket notation superfluous. The block with flow properties or provided and requested features is the type of a port.

Nested ports

The feature of nested ports could already be used with some SysML modeling tools before SysML 1.3. For example see the model of the INCOSE MBSE Challenge Team at http://mbse.gfse.de. It is conform to the syntax of SysML. However the specification doesn’t explicitly allows nested ports and says nothing about the semantics. In SysML 1.3 nested ports are a official feature of SysML.

If the block that types a port has itself ports, you get nested ports. In the example the block CSPort has itself two ports to specify electrical and mechanical connections.

Proxy ports

A proxy port exposes internal features of a block. The port itself doesn’t own the features. Typically ports at the system border are flow ports. The system block is virtual element. The real elements of the system are the parts of the system block. A port to provide or request power at the system border is a proxy for the real port somewhere inside the system.

The SysML callout notation

Posted on 28. March 2012 by Weilkiti

PDF

I’ve just found this question in a sysml discussion forum:

Is it really not possible to place requirements objects on an Activity, State Machine, or several other similar behavioral diagrams?

Yes, it is not allowed to put requirement elements on a state machine or activity diagram. Since it is essential to show such cross cutting relationships SysML provides the callout notation. A comment symbol is attached to the state or action or to any other element in the state machine/activity diagram. The text inside the comment describes the relationships to the requirements. Although it looks like a simple comment it is a formal representation of the model. A good SysML tool could display the callout notation automatically.

SysML Callout notation

The callout notation works for the allocate and the requirements relationships.

The SYSMOD Zigzag Pattern

Posted on 26. March 2012 by Weilkiti

PDF

Are your requirements really free of any solution? Requirements describe the What, the system architecture describes the How. Sounds easy, but…. Requirements are solution-free and they contain solution aspects at the same time. It depends on the level of abstraction.

Let’s assume that you have absolutely solution-free requirements (I argue that those requirements are not viable in practice). Now you derive a system architecture that satisfies the requirements and you get the typical what/how-pair. For example you have requirements about a transportation system for people and you derive a system architecture of a car. The solution car leads to new requirements that contain aspects of the solution. They are on another abstraction level and solution-free from the viewpoint of that level, but they contain solution aspects of the previous level. Again you derive a solution from the requirements, e.g. a hybrid engine. Again that solution leads to new requirements and so on. All in all the logical steps represent a zigzag pattern.

The SYSMOD-Zigzag-Pattern

Requirements in practice always contain some solution aspects. Unfortunately they are often implicit and are one of the causes why requirements are a sore spot of many projects.

I’ll write further posts to discuss consequences from the SYSMOD-Zigzag-Pattern.

Update: SYSMOD and MagicDraw

Posted on 23. March 2012 by Weilkiti

PDF

NoMagic provides a free SYSMOD plugin for MagicDraw (see Download page). NoMagic just released SysML version 17.0.1 SP2 with the following updates for the SYSMOD plugin:

The New SYSMOD profile version is now with enhanced variants modeling support (See CarAccessSystem example model).
The message box stating that the SYSMOD plugin should be installed will no longer be shown after loading the existing SYSMOD projects.
The «Functional block» stereotype has been removed from the new SYSMOD profile to avoid conflicts with the new FAS plugin that contains the same stereotype. Projects deploying the «Functional block» stereotype will be automatically updated to be usable.

You find more details about the update on the NoMagic website.