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.

SysML 1.3 Reference Cards available in English, German and French

SysML 1.3 / SYSMOD Reference Card (English)
Now the SysML 1.3 reference card is also available in French. Thanks to Jean-Michel Bruel for the translation.

You can download the reference card in English, German, and French language from the download section.

Currently I work on the new SysML 1.4 version and will publish it as soon as SysML 1.4 is final.

SysML Full Ports versus Proxy Ports

How to use full ports and proxy ports and what’s the difference? SysML changed the way how to model ports with version 1.3 in 2012. (see also What’s new in SysML). Besides others the new version 1.3 introduced the concept of full and proxy ports.

Full port
A full port is an element of the system. It is part of the bill of material (BOM) and could – as any other part – specify behavior and an internal structure. The type of a full port is typically a standard block. The following figure shows an extract of a forest fire detection system. The Smoke sensor has a full port that specifies the attachment of the sensor to the environment. The attachment is a part of the Smoke sensor with it’s own structure specified by the block Attachment.

Smoke sensor with a full port

Proxy port
You can model the same semantics with a proxy port. The attachment is a internal part of the Smoke sensor. The proxy port provides the relevant features of the attachment to the outside. The features are specified with the interface block SIF_Attachment (SIF = System Interface).

Smoke sensor with Attachment and interface definition

The proxy port and the internal part are connected with a binding connector that assures that the instances of the proxy port and the part have the same value. For that reason the types of the port and the part must be compatible. Therefore the block Attachment is a specialization of the interface block SIF_Attachment.

Smoke sensor with proxy port

My recommodation
I recommend to use only proxy ports and to ignore full ports.

  • All parts of the system are modeled the same. There is no special case that full ports are also parts.
  • The separation of parts and their relevant features for the context puts an important focus on interfaces. Full ports provide the complete set of features of the element to the outside.
  • If every port in the model is a proxy port, you can discard the stereotype notation proxy. That makes the diagrams less cluttered.

The 4th Industrial Revolution

In the German manufacturing community everyone talks about Industry 4.0. But hardly anyone could say what it really is and what that supposed to mean. I’ll shed a little more light on it and show the relationship to MBSE.

Industry 4.0

Industry 4.0 is a project of the German government in the context of their high-tech strategy to establish Germany as a pioneer in solving the global challenges of our time. The term industry 4.0 refers to the thesis that we are at the beginning of the 4th industrial revolution.

End of the 18th century the 1st industrial revolution was triggered by the usage of mechanical machines powered with steam. The 2nd industrial revolution was the introduction of mass production enabled by electric energy at the beginning of the 20th century. The increasing usage of IT and automationin the 1970ties is known as the 3rd industrial revolution.

Each industrial revolution was a huge change of our industrial landscape. That’s why we call it revolution. It was existential for the companies to follow the mega change. Therefore every company of at least the manufacturing domain should carefully listen to the current discussions about industry 4.0.

The 4th industrial revolution is characterized by the communication of the systems of the manufacturing process with each other. The workpieces carry the information of their purpose and communicate it to the manufacturing machines. Such a setting is also called smart factory. They enable dynamic engineering processes to meet individual customer requirements and last-minutes changes.

The network of the manufacturing systems is also called internet of things. The physical objects have virtual represenations that are connected. An example is the shipment tracking system of courier companies. Another name for the internet of things is cyber-physical system. There are some discussions about both terms. I see no benefit to treat them differently and use the terms as synonyms.

Of course there are lot of interesting points about the impact on the manufacturing processes and techniques. I like to view on the 4th industrial revolution from the viewpoint of model based systems engineering.

Relationship to MBSE

Modeling and Systems Engineering are techniques or disciplines to handle complex systems. Complexity is defined by the number of different elements and their connections. Systems Engineering comes into play when you have complex connections between elements of different engineering disciplines. Looking back software engineering was the first discipline that exceeded the complexity threshold closely spaced by the electrical engineering discipline. Now the mechanical engineering disciplines crosses the complexity border and has an increasing demand for MBSE.

Complexity Engineering Disciplines MBSE

The gap between systems engineering and mechanical engineering is much bigger than the gap between systems engineering and software or electrical engineering. I’ve observed in many projects that mechanical engineers find it difficult to apply MBSE methods & tools. I’ll put more focus on the interface between the two disciplines and improve them to bridge the gap. Currently I plan a collaborative project between industry and research institutes to develop a method, languages and tools to connect a SysML model with CAD.

NoSE 2013 – A Report from the Tour

From April 15th to April 17th I did the first Nordic Systems Engineering Tour. I’ve initiated the tour together with Erik Herzog from Saab in Sweden. NoSE is a 1-day conference event in Hamburg, Copenhagen, and Stockholm in 3 days. The purpose of the events is to promote Systems Engineering and also to strengthen the links between the German and the Swedish chapters of INCOSE and to support the Danish systems engineering community. It was great fun and very experiencing. The tour speakers including me came from Germany, Sweden, Lithuania, and Spain. In addition we had local speakers at each venue.

We’ve started with a smaller audience in Hamburg. oose was the host of the day and sponsored the room and catering. The talks were about

  • the SYSMOD-Zigzag pattern,
  • a reflection of 15 years of Systems Engineering
  • verification & validation of the mission system of the Frigate F125 (local talk)
  • Ontology-Based Systems Engineering, and
  • best practices for modeling.

After a very interesting day the tour speakers headed to the central station for the train to Copenhagen. During the trip we had time to relax and to discuss our systems engineering experiences. At midnight we arrived in Copenhagen.

Our host in Copenhagen was the hearing aid company GN ReSound. This time the audience was 5 times larger than in Hamburg. Personally I’ve learned a lot from all the discussions around our talks. The local speaker Henrik Balslev talked about RDS coding principles. I didn’t know RDS (and Henrik) before. I’ve discussed the relationship of RDS and SysML with Henrik. We’ve agreed to elaborate it further. Both of us don’t know any work that covers RDS and SysML.

After the conference the Danish systems engineering community met to discuss the opportunities to establish a Danish local chapter of INCOSE. The NoSE tour was a perfect platform for them and good marketing for the value of chapters.

Again the tour speaker headed to the central station for the train to Stockholm. A few minutes after Copenhagen the train crosses a great systems engineering example – the Øresund Bridge from Copenhagen to Malmö. The bridge is a case study in the INCOSE handbook. At midnight we arrived in Stockholm.

Our host in Stockholm was the KTH, the Royal Institute of Technology. In addition to the talks of the tour speakers we had a local talk from Erik Herzog about system views and system properties and a talk from Pär Hammarström about product lines in practice.

It were three intense days. We all agree that it is worth to do the tour again in 2014.

Nordic Systems Engineering Tour