The Digital Product Model – The Hechenberger 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.

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.