What’s new in SysML 1.4 – View and Viewpoint

The third part of the blogpost series about the changes in SysML 1.4 presents the updated concept of view and viewpoints. View and Viewpoint are model elements of SysML since the very first public version 1.0. As you may know SysML was developed based on a request for proposal with a set of requirements. One requirement was about views:

SysML 1.4 - View and Viewpoint - Requirement

SysML 1.4 – View and Viewpoint – Requirement (click to enlarge)

In SysML 1.0 the view and viewpoint concept is consistent with the IEEE 1471 standard (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems) – now the ISO-42010 standard.

The viewpoint specifies rules for constructing a view including a set of stakeholders, their concerns and the purpose to address the concerns. The view is a representation of the system from the perspective of a viewpoint. The following figure shows a simple view and viewpoint example with SysML < Version 1.4:

SysML 1.4 - View and Viewpoint - Exemple before SysML 1.4

SysML 1.4 – View and Viewpoint – Exemple before SysML 1.4 (click to enlarge)

In theory that was a good concept. However I’ve never seen a valuable implementation in practice. You need a tool that generates the real view, i.e. the text document, spreadsheet, etc.. But no such tool was available. All SysML modeling tools have their own way how to generate documents from the model. Without the implementation the modeling of views and viewpoints was not very useful.

SysML 1.4 has an updated concept of view and viewpoints. It is still consistent with ISO-42010 and has a more formalized concept how to generate a view. However the final implementation of the view generation is still out of scope of the SysML specification. The following figure shows a view/viewpoint scenario with the all model elements.

SysML 1.4 - View and Viewpoint - Example

SysML 1.4 – View and Viewpoint – Example (click to enlarge)

With version 1.4 SysML provides a model element for stakeholders. The stakeholder has a name and a list of stakeholder concerns. The concerns are comment model elements. The relationship between the stakeholder and the comments has no notation. The SysML model element stakeholder extends the UML classifier, i.e. a stakeholder could be a special actor as well as a special block. The stakeholder is defined in the context of the view and viewpoint concept. It is not the common stakeholder known from requirements engineering.

Now the SysML model element view extends the UML class. Before version 1.4 it was a special UML package. The view has two derived properties: a list of stakeholders derived from the stakeholders list from the viewpoint and the related viewpoint derived from the conform relationship that relates a view to a viewpoint. Conform extends the UML generalization relationship. That means a view is a special kind of a viewpoint and inherits all the features of the viewpoint. The view represents the physical artifacts of the view for example a text document, spread sheet or slide presentation.

The version 1.4. viewpoint has some updated properties according to version 1.4:

  • concernLIst is a list of concerns of the stakeholders that should be addressed by this viewpoint. Each concern is modeled by a comment. Again there is relationship notation defined between viewpoints and comments.
  • concern is a derived property that lists the bodies of the comments of the concernList. I wasn’t able to activate that property in my modeling tool. Therefore it is not shown in the diagram above. However it modeling tool already shows the comment body in the concernList property.
  • method is a derived property that shows the behavior that is used to create the view. It is derived from the behavior of the constructor of the viewpoint (see below).
  • language specifies a list of languages used to express the models that represent content which is represented by the view.
  • presentation defines a prescription of the format and style of the view.
  • stakeholder is a list of stakeholders whose concerns are to be addressed by the view.

A viewpoint must have a View() operation with applied stereotype Create. The method of the operation is a list of behaviors. For instance it could be a opaque behavior that specifies the creation of the view in a modeling tool specific language.

The expose relationship relates a view to model elements that are passed to the View() constructor when it is invoked. The model elements are the entry point for the model query that is typically part of the View() implementation to query data from the model for the view.

Finally I show you a simple example how to use the new view/viewpoint in a modeling tool. For instance the Cameo Systems Modeler from NoMagic provides a report generator based on the SysML 1.4 view/viewpoint concept. The tool provides some predefined implementations for the View() operation of the viewpoint. The following model specifies a view with a short textual introduction and a list of the content of the FFDS model.

SysML 1.4 - View and Viewpoint - Example Cameo Systems Modeler

SysML 1.4 – View and Viewpoint – Example Cameo Systems Modeler (click to enlarge)

The preview shows the text and a table of content of the FFDS model with the name and the documentation of the packages on the next level.

SysML 1.4 - View and Viewpoint - Preview

SysML 1.4 – View and Viewpoint – Preview (click to enlarge)

These are very basic views and viewpoints. With them you can create your own toolbox of predefined viewpoints and create complex views/viewpoints by combining them.

What’s new in SysML 1.4 – Grouping of Elements

The second part of the blogpost series about the changes in SysML 1.4 presents the new concept to group elements.

The use case is simple: Create a group of model elements:

SysML 1.4 ElementGroup Use cases

SysML 1.4 ElementGroup Use cases (click to enlarge)

Okay, on the second thought there are some more: Update a group and Delete a group. And I’m sure that you’ll find some more use cases on the third thought. It also depends on your personal definition of a use case. I won’t start that discussion here.

Surprisingly it is not possible to simply group model elements with SysML until version 1.4 or with UML. The first pick would probably be the package. Looks like a perfect grouping element. However there is another important requirement for our grouping element: It must not add any semantics to the members of the group. A package adds a very strong semantic to the members. It is a namespace.

The requirement Semantic free contains several more requirements on the next level of detail:

SysML 1.4 ElementGroup Requirements

SysML 1.4 ElementGroup Requirements (click to enlarge)

  • A model element could member of any number of groups (#2.1). That – for instance – is not possible with a package as a grouping element. A model element could only be a member of one package (namespace).
  • The group may contain arbitrary elements (#2.3). Again that is not possible for packages that could only contain packageable elements like blocks or use cases, but not ports or properties.
  • The group does not change the members (#2.2, #2.4), i.e. it does not change any property of the elements or create relationships between them.

SysML 1.4 provides the new model element ElementGroup that satisfies the given requirements:

SysML 1.4 ElementGroup Stereotype

SysML 1.4 ElementGroup Stereotype (click to enlarge)

Since SysML is a profile of UML it is not possible to create a new model element out of the scratch. You must define a stereotype that extends a given UML model element without contradicting the semantics of the UML element. The challenge was that UML has no semantic-free grouping element. The solution is the comment. ElementGroup is a stereotype that extends the UML element Comment.

A Comment is nothing more than a text – the comment – and a set of annotated arbitrary model elements. It does not have any semantics and does not any semantics to the model elements. It is just a comment like a sticky yellow note attached to a document. The comment is shown in a note symbol. The annotated element could be shown by dashed lines between the comment symbol and the element. The following figure shows a example of a comment:

SysML 1.4 Comment example

SysML 1.4 Comment example (click to enlarge)

The lower left annotated element is not the block, but the operation probeInput().

A ElementGroup adds a name property to the comment to give the group a name. The text of the comment element is used to describe the criterion that an element is a member of the group. The criterion is also a derived property of the element group, i.e. it is derived from the body text of the comment. Another derived property is the size of the group. The members of the groups are also a derived property. They are derived from the annotated element property of the comment. Since the set of annotated elements allows no order, the ElementGroup has an additional optional property to define a order of the group members.

The notation is the same as the comment, stereotype and tagged value notation. The following diagram shows the element group Revenue with 3 members that are in particular relevant for the revenue of the product vendor of the forest fire detection system (FFDS).

SysML 1.4 ElementGroup example

SysML 1.4 ElementGroup example (click to enlarge)

The big disadvantage of using the Comment as the base element for the ElementGroup is that it is not possible that a ElementGroup is a participant in a relationship. For instance you cannot model a trace relationship from or to an element group or a refine relationship from our Revenue element group to a appropriate requirement. There is no simple solution for this issue except a new first class model element. For that we must wait for UML 3.0.

Now you know the new SysML ElementGroup. Would you use it? I’m interested in your applications of the ElementGroup. I hope there are not so many, but I’m also in your issues with the ElementGroup. Please let me know. Write a public comment to this blogpost or send me a private note.

The Digital Product Model – The Hechenberg theses

“It grows together what belongs together.” – Mechatronics, Systems Engineering, OSLC, ReqIF, AutomationML, feature teams, cross-functional teams, … After a strict separation of the engineering disciplines in the past, now the movement is unmistakably towards a closer integration.

The market demands ever more complex systems in ever shorter time-to-market times. This is clearly demonstrated by hot spots like industry 4.0, Internet of Things or cyber physical systems. The organizations that want to successfully develop the systems of the future have to adopt new methods and tools. You can’t develop ever more modern systems for tomorrow with yesterdays tools. Or does your software engineers still use punch cards?

The interplay of disciplines, developing a product is not to see black and white, but a balancing act. Of course there must be a separation of the engineering disciplines and we still need specialized experts in mechanical or software engineering.

But we can no longer separate the disciplines with high walls and communication channels build on documents only. The disciplines must work closely together
to jointly develop the best solution for a system function.

Systems Engineering plays a significant role in that scenario. It is a discipline that covers all engineering disciplines, but looking at the system on an abstract and
holistic level. Well performed it is the perfect glue between the disciplines.

Engineering disciplines and product features

Engineering disciplines and product features

The information and their dependencies behind a product that needs to be handled by an engineer are enormous. A systems development project produces and works with a variety of documents and models. The models are ideally the source of the information and the documents are only the views. The increasingly close integration of the disciplines must also lead to an integration of the models. Single model repositories of engineering disciplines are combined into a single conceptual digital product model. In an ideal world, the engineer can immediately identify the impact of proposed changes in the system and in other disciplines. While SysML, CAD, Simulink, Modelica & Co. are part of the digital product model, product lifecycle management (PLM) provides the methods and structures to manage the individual product components and their dependencies.

The digital product model

The digital product model

The sendler/circle is a group of CEOs or marketing directors of major software and service providers in the PLM environment to exchange experiences and to discuss the general market trend. I am a member of the circle as CEO of oose – a leading German consultancy for software and systems engineering.

The sendler/circle adopted four theses about digital product models in the Bavarian village Hechenberg on May 19th, 2014:

  1. The basis of innovative, “smart”, connected products are digital product models.
  2. The digital product model must contain all the elements of mechanical, electrical, electronics and software and may reflect their interaction virtually.
  3. Digital models make development, production and operation of complex products manageable.
  4. The integrated management of digital product models throughout their entire life cycle is an important prerequisite for the realization of Industry 4.0.

(see also Hechenberger Theses from the sendler\circle on Industrie 4.0).

What’s new in SysML 1.4 – Overview

Logo OMG Systems Modeling Language (OMG SysML)We are still waiting for the official release of the SysML version 1.4. The work on the update already finished several months ago. Due to some organization obstacles the official release is delayed. In April 2014 the OMG published a beta version of the SysML 1.4 and some tool vendors already published updates of their modeling tools with SysML 1.4. You can find the SysML 1.4 beta specification on the SysML specification website.

So it is time to report about the changes from SysML 1.3 to SysML 1.4. There are many minor changes like typos or other more formal issues. I will focus on the changes that are relevant for the model user or builder and publish a blogpost for each change. That leads to a serie of around 7 blogposts. Currently I plan or already write the following blogposts:

1. Overview (this blogpost)
2. Grouping of Elements
3. View and Viewpoint
4. Constraining decompositions
5. Units
6. Several minor changes to the block and port concept
7. SysML Diagram Interchange

I plan to publish at least one post per week. Publishing this first one is a public commitment to keep the publication plan. Feel free to complain if I don’t.


New edition Systems Engineering with SysML/UML covers SysML 1.4 and more

Systems Engineering with SysML/UMLMy publisher just released the third edition of my book “Systems Engineering with SysML/UML”. To be exact it is the German version of my book “Systems Engineering mit SysML/UML”.

Since the second edition 6 years have passed. In this time the language SysML, my MBSE methodology SYSMOD and MBSE in general have been further developed. The media book could hardly follow the high dynamics that currently happens in our engineering environment. Extremely spoken the book is outdated when it leaves the printing company. Okay – that’s probably to extreme. However for that reason I’ve started this blog to publish valuable MBSE information in a timely manner.

The main changes in the third edition of my book are:

  • The book covers SysML 1.4. Likewise it also covers SysML 1.3 which at the time of the second edition of my book was not yet available.
  • The MBSE methodology SYSMOD now address explicitly different types of system architectures: basic architecture, logical architecture, physical product architecture and functional architecture.
  • Several minor changes of SYSMOD, based on experience and feedback from users.
  • A new chapter for the preparation for the OCSMP certification has been added.
  • Feedbacks that I have received to the 2nd edition are incorporated.

I wish you much joy and knowledge in reading and looking forward to your feedback.




NoSE 2014 – A Report from the Tour

NoSE Traveling

What a great week! Summer, Fun, Great Cities and Systems Engineering. The 2nd Nordic Systems Engineering Tour from Hamburg via Copenhagen and Stockholm to Helsinki has just finished.
Four tour speakers who did the whole tour and several local speaker gave great performances and shared their knowledge and experience with nearly 200 participants. And vice versa during the discussions participants gave an insight to their knowledge and experience. I’ve learned a lot!

The NoSE Tour is a non-commercial event organized by four local chapters of INCOSE: Germany, Denmark, Sweden, and Finnland. The organizers are volunteers who work with much blood, sweat and tears to support the systems engineering discipline. Great Thanks for them!

I am proud to was one of the tour speakers. It was a pleasure to travel with

  • David Long (INCOSE president and president of Vitecht; @David: I’m still wondering how do you do two full time jobs at the same time),
  • Jonas Andersson (INCOSE Associate Director for Events and SE consultant),
  • and Paul Schreinmarkers (INCOSE Technical Deputy Director and SE consultant).
(In)cosy NoSE Traveling 2014

(In)cosy NoSE Traveling 2014: David, Tim, Paul, Jonas (from left to right)

David gave a comprehensive introduction to INCOSE. That was very valuable for most participants, because systems engineering or INCOSE were new to them.

His second talk Systems Engineering in Turbulent Times perfectly fitted to my talk Foreseeing the Unforeseeable. We talked about the challenges of the ongoing big changes like the Internet of Things and how to face these challenges with Systems Engineering, MBSE, Agile, Lean, Design Thinking, and more.

Jonas addressed the very important aspect of learning with his talk Touching the learning aspect of five diciplines to enable the fifth. We spend lots of time and money in the education of engineers. So it is a good advise to have a careful look on the quality of our learning activities.

Paul talked about the System Architectures for the Dutch Railways. A very interesting insight into the concrete application of systems engineering for a specific domain.

I’ve heard each of these talks 4 times. So now I know them very well.

I would like to also say thank you to the local talks. I’ve enjoyed them very much as well.

After the tour is before the tour. We plan to do the 3rd NoSE Tour in 2015. Stay tuned!

NoSE on Tour 2014 – Here we go!

The Program is online, the registration is open – we are looking forward to see you in Hamburg, Copenhagen, Stockholm or Helsinki. Register here!

The 2nd Nordic Systems Engineering Tour 2014 starts May 20th in Hamburg and ends May 23rd in Helsinki. At each venue we provide a one-day conference with great speakers and time for networking. It is not a commercial event. It’s organized by four local chapters of INCOSE and our objective is to strengthen systems engineering and the systems engineering community.

Today a big challenge is complexity and dynamic. Things are getting more and more complex and things are changing faster and faster. Organisations without an explicit systems engineering feel the pain that the specific engineering disciplines can’t handle the increasing interfaces and dependencies to other disciplines anymore. Several talks of the NoSE tour deal with that challenges.

The tour speaker talks:

  • David Long (INCOSE, USA) – Systems Engineering in Turbulent Times
  • Tim Weilkiens, Stephan Raimer (oose, Germany) – Forseeing the Unforseeable – Creating Clarity from Complexity
  • Jonas Anderson (Syntell, Schweden) – Touching the learning aspect of five diciplines to enable the fifth
  • Paul Schreinemakers (How2SE, Niederlande) – Modeling the Systems Architecture for the Dutch Railways

We have specific local talks at each venue:

  • Hamburg: Piotr Malecki (ThyssenKrupp Marine Systems) – The taste of the Systems Engineering Sandwich in the real life or how to profit from SE being between the Customer and the Suppliers
  • Copenhagen:
    • Bjarne Månsson – Risk-based testing
    • Jonas Mørkeberg Torry-Smith – Application of Systems Engineering in small and medium sized companies
  • Stockholm: to be announced
  • Helsinki: Kristiina Söderholm, Ph.D – Systems Engineering possibilities in Nuclear Industry

Don’t wait and register today for one of the NoSE events. We have limited seats.

See you!

A System Architecture is what System Architects create

There are hundreds of definitions about architecture available. Fortunately they have a lot of things in common. Personally I like the following definition:

“An architecture is the set of fundamental decisions that cannot be reversed without greater effort and impact.”

That definition focusses on the role of the system architect. It does not define the set of artifacts that are part of an architecture. It could be anything. This definition – as any other – is vague at the borderline. It does not clearly define what is part of the architecture and what is not. I’m pretty sure that you won’t find a useful definition that could clearly answer that question. Otherwise let me know

What does that implies for the practice? Simply spoken: Keep care of the interfaces! The borderline between System Architecting and Requirements Engineering, Systems Design, and any other specific engineering disciplines is blurry. Focus on the interfaces at these borders. And with interfaces I do not mean technical interfaces. It is about communication and processes.

For example the SYSMOD-Zigzag-Pattern explains the close collaboration between the Requirements Engineer and the System Architect. It helps to clarify the separation of both roles and defines the services provided and requested by each role. The requirements engineering must communicate the requirements to the systems architect. “Communicate” means really communicate and not just sending dozens of documents by email. The systems architect creates a system architecture that satisfies the requirements. She must communicate the architecture to the requirements engineer to assure that she has correctly understood the requirements. If you have another layer accordung to the SYSMOD-Zigzag layers, the requirements engineering derives requirements based on the architecture and the communication flow starts again.

Conceptually the relationships described above exist in every project. Whatever you explicitly apply the zigzag pattern with SYSMOD or any other methodology. It clearly shows that the requirements engineer and the system architect must collaborate and communicate as close and personal as possible.

Collaboration Requirements Engineering / Systems Architect

Collaboration Requirements Engineering / Systems Architect

European Systems Engineering Tours

Last year we did the first Nordic Systems Engineering Tour. It was a fantastic success. We had great presentations, discussions and of course fun! Behind the scenes it was a collaboration between the German and the Swedish chapters of INCOSE and the Danish systems engineering community. See also my blog post about the tour: NoSE 2013 – A Report from the Tour.

We do a new tour this year. The Nordic Systems Engineering Tour 2014 starts in Hamburg at May, 20th, then Copenhagen, May 21st, Stockholm, May 22nd, and for the first time Helsinki, May 23rd. The Finnish chapter of INCOSE joined the tour and will organize the event in Helsinki. The Danish community chartered a Danish chapter of INCOSE end of last year. They’ll organize the event in Copenhagen.

The Call for Presenters is open. We are looking for tour speakers and for local speakers.

Juan Llorens from Spain was a tour speaker of NoSE tour last year. As a technical director of the Spanish chapter of INCOSE he brought the idea of the tour to the south. And now we have also a southern systems engineering tour: The South Europe Systems Engineering Tour 2014 from May 28th – 30th. The tour will visit Lugano, Paris and Madrid. The Call for Presenters is open.

Join us and

  • learn about Systems Engineering from local and tour speakers.
  • get contact to other Systems Engineering in your area.
  • be part of the INCOSE community.
  • have fun.

Looking forward to see you there!



HowTo Model Use Case Activities in SysML

Activities are commonly used to describe the behavior of use cases. In SysML these are separate model elements: the use case and the activity. The use case is a specification of behavior. Whereas the activity is the definition of the implementation of the behavior. Instead of an activity you can also use interactions (sequence diagrams), state machines or opaque behavior. However I favor the activity.

Typically in a SysML model the activitiy is in the namespace of the use case. You could see that in the containment tree of your modeling tool. The activity is one level below the use case:

Activity in namespace of a Use Case

Activity in namespace of a Use Case

That’s sufficient for most projects. However it does not specify what you want to specify. The activity is simply in the namespace of the use case. Nothing more. It is not the behavior of the use case. The model element UseCase has a property ownedBehavior. It references the set of behaviors – typically only one. The modeling tool MagicDraw automatically sets that property when you place an activity in the namespace of a use case:

Use Case property ownedBehavior

Use Case property ownedBehavior

You can show the relationship in the diagram. According to the specification it is possible to show a compartment owned behaviors if the use case is shown in rectangle notation instead of the ellipse notation. MagicDraw does not provide that feature, but allows to display element properties like the ownedBehavior property in the diagram:

Use case with property ownedBehavior shown in a diagram

Use case with property ownedBehavior shown in a diagram

If you write model queries use the ownedBehavior property and not the namespace containment relationship. You can move the activity to another namespace, e.g. a package, and it is still the ownedBehavior of the use case. Check how your modeling tool handles the relationship between use case and activity.