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!
Tim

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!

Tim

 

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

What is a model?



Could you easily answer this question? Is a document a model? Why not?

Most references define a model or properties of a model like this

A model is a representation of something. It captures not all attributes of the represented thing, but rather only those seeming relevant. The model is created for a certain purpose and stakeholders.

That definition includes text documents. They are also a representation of something and do not capture all attributes of the real thing. However I don’t feel comfortable to call a document a model. If a document is a kind of a model why everybody talks about the shift from document-based to model-based systems engineering.

We must specialize the common definition of a model for systems engineering. I define two additional rules for the MBSE model definition.

The first rule clarifies a typical misunderstanding. MBSE is not only about SysML. MBSE is also about methodologies. And looking on the model you can use many different models and model languages in a MBSE environment. Although SysML is the most important modeling language for MBSE.

The first specific rule for the MBSE model definition is:

[MODEL1] A model could consist of many model repositories.

I separate the terms model and model repository. For example a MBSE model could consist of a requirements model repository (e.g. IBM Rational Doors™) and a SysML model. From the users perspective it is one model. It doesn’t matter that the model data is located in different repositories. You need tool chains to link several model repositories, i.e. bridges, adapters, or a model bus.

The first rule still does not exclude documents from the model definition. A model is build with a model language. Typically the users focus is on the diagram and notation – the so called concrete syntax. Much more important is the world behind the concrete syntax. There is the abstract syntax and semantic of the model elements. Simply spoken the data structure and the meaning. The abstract syntax is the enabler to do computer-based analysis, simulation, traceability and so on. That’s the difference between a model and a drawing.

The second specific rule for the MBSE model definition is:

[MODEL2] A model is build with a model language with an abstract syntax that covers the basic concepts of MBSE like requirements, structural system elements and functions.

SysML is such a modeling language. It has elements like requirements, blocks, activities, and so on. The language “knows” MBSE concepts. A typical text document does not fit to this rule. Even if it has a abstract syntax, the syntax does not cover MBSE concepts. Of course it is possible to specify a textual language with an abstract syntax for MBSE concepts. In that case a text document written with “textual SysML” is a model.

The two rules [MODEL1] and [MODEL2] in addition to the common definition of a model are in summary the

Definition of a MBSE model

A model is a representation of something. It captures not all attributes of the represented thing, but rather only those seeming relevant. The model is created for a certain purpose and stakeholders.

[MODEL1] A model could consist of many model repositories.

[MODEL2] A model is build with a model language with an abstract syntax that covers the basic concepts of MBSE like requirements, structural system elements and functions.

I could think of more aspects like graphical representations, view concepts, simulation, and so on. However they are all optional and not mandatory.

Two Kinds of Patterns



Did you know that you use patterns every day? It’s a very powerful mechanism and much more powerful when they are explicit and known.

A pattern describes a proven solution for a problem. Every experienced engineer has a huge set of patterns. Think about your daily work. If you must solve a problem that you’ve solved successfully before, you will remind your solution and apply it again. If you describe your solution in a general and reusable way, you’ve made your experience explicit and persistent. Voila! You’ve found a pattern.

Christopher Alexander described patterns for building architectures (his pattern book), Erich Gamma & Co. described patterns for software engineering (their pattern book) and Robert Cloutier describes patterns for systems engineering (his work).

I’d like to put a focus on another kind of a pattern. In system modeling the graphical representation of the model data is an important part. It definitely makes a difference how you present your data. The human brain looks for graphical patterns and not for all the little details. That makes life much easier. For example you can change the letters in a text while keeping the pattern structure and you could still read the text:

Mdoel Baesd Setmsys Ennneigierg mekas my procjets mroe ecffetive.

Cool, isn’t it. Similar things happen when you look at SysML diagrams. You’ll see graphical patterns. Unfortunately such patterns are not well known and described. Here’s a huge potential to be more effective.

For example it makes a difference if you layout a product tree in a block definition diagram top-down, bottom-up or in a non-tree layout style.

Product Tree Forest Fire Detection System Top-down Style

Product tree (top-down)

Product Tree Forest Fire Detection System Bottom-up Style

Product tree (bottom-up)

Product Tree Forest Fire Detection System Non-tree Style

Product tree (non-tree style)

I prefer the top-down layout. It emphasizes the break down of the product (Product Breaddown Structure (PBS)).

I know that there is lots of information about human pattern reception in general. But I know no paper or book that combines those results with system modeling. I appreciate any hint.

Finally some guidelines/facts:

  • Typical reading direction is from top to down, from left to right. It is different in some cultures.
  • A diagram should not contain more than 7 main elements.
  • A diagram should have a printable layout (A4 or letter format).