Seats available for the Nordic MBSE School

RainWell, actually it is summertime. However the weather reminds me more of autumn. At least here in Sweden. In any case it is a good time to plan and book your next training.

One of my favourite projects the Nordic MBSE School provides a comprehensive MBSE program. Four course modules for you to combine to a 2, 4, 6 or 8 days training. Each course module is two days long and is conducted in central Stockholm. I will do the modules about requirements engineering and system architecture with SysML.

For more information visit Nordic MBSE School or download the flyer.

Hope to see you in autumn – when the leaves come falling down,
Tim

Flattr this!

SysML Diagram Interchange Architecture

What’s new in SysML 1.4 – SysML Diagram Interchange

The Diagram Definition (DD – previously known as Diagram Interchange (DI)) is a format to exchange diagram data between tools. The data about diagrams is separated from the data about the model information. The interchange format for the model data is XMI (XML Metamodel Interchange; see XMI specification page).

The following figure depicts the whole picture of the SysML Diagram Interchange architecture. As well as SysML is an extension of UML, the SysML Diagram Interchange is an extension of the UML Diagram Interchange. And the UML DI is a specialization of the generic DD.

SysML Diagram Interchange Architecture

SysML Diagram Interchange Architecture

Let us have a look on a simple example of a single use case. The next figure shows a SysML use case diagram with useless use case:

A useless use case

A useless use case

The model data of the use case is an instance of the metaclass UseCase with the appropriate properties. The next figure depicts an extract of the model data by a instance specification:

Instance of metaclass UseCase

Instance of metaclass UseCase

Using XMI exchanges the data of the use case in a XML-based format.

The diagram information of the use case covers data like position and size of the shape on the diagram. The information is an instance of the shape metamodel element of the DD:

Diagram definition data of a use case

Diagram definition data of a use case

The SysML Diagram Interchange is an extension of the Diagram Definition. It covers special notation aspects of SysML. For instance the dashed control flow arrows in an activity diagram. The following figure depicts how this notation is implemented in SysML:

Diagram definition of a SysML Activity Diagram

Diagram definition of a SysML Activity Diagram

The SysML Diagram Interchange is part of the non-normative appendix of the SysML 1.4 specification. That means a tool vendor must not provide the format to be 100% SysML compliant. However it is strongly recommended that it is provided by SysML modeling tools. Unfortunately I do not know a modeling tool that has implemented the diagram interchange format. If you know one, please drop a note as comment to this blogpost.

This was the last post of my blogpost series about the changes of SysML 1.4.

Flattr this!

SysML Block FFDS with behavior compartments

What’s new in SysML 1.4 – Several minor changes to the block and port concept

The sixth part of the blogpost series about the changes in SysML 1.4 presents the updated concepts for blocks and ports. The new concept of bound references is already covered in the special blogpost What’s new in SysML 1.4 – Constraining decompositions.

Behavior Compartment

A SysML block can own behaviors. For instance a state machine or an interaction. A special behavior owned by the block is the so-called classifier behavior. It represents the autonomous behavior of a block and is executed when an instance of the block is created and terminates with the deletion of the instance.

With the new SysML 1.4 the owned or classifier behavior can be depicted in special compartments of the block rectangle. The following figure shows a block that represents a forest fire detection system (FFDS). The compartment classifier behavior depicts a state machine that specifies the states of the FFDS including the reaction when events are received. The compartment owned behavior depicts an activity that specifies how the FFDS switches to the maintenance mode.

SysML Block FFDS with behavior compartments

Click to enlarge

Each compartment of a block could also be shown as part of the shape of a property typed by that block, i.e. the classifier behavior and owned behavior compartments could also be depicted in a internal block diagram.

Inherited Features

With a generalization relationship from one block to another block the block at the source side of the relationship inherits the features (properties, operations) of the block at the target side. The following figure shows parts of the definition of the sensors of our forest fire detection system. The sensors are specializations of the abstract sensor that specifies some general properties. These properties are inherited, i.e. they are also part of the definition of the special sensors. To overlook all features of a block in a block definition diagram you must see the complete generalization hierarchy and visually collect the features along the generalization paths.

SysML FFDS Sensor generalization

Click to enlarge

In SysML 1.4 the new notation of inherited features displays all inherited features of a block in the appropriate compartments. The next figure depicts the specific sensors with the new notation. The syntax of inherited features is like “normal” features with a leading ^ symbol.

SysML inherited features notation

Click to enlarge

Parts in a internal block diagram are properties. Inherited parts are shown the same way as properties or operations in the block compartments with a leading ^ symbol before the name of the part. The next figure depicts a simple example of the inherited part notation.

SysML FFDS Configuration

Click to enlarge

SysML inherited part notation

Click to enlarge

Adjunct property

The adjunct property constraints the values of the property to other values in the model. The values are instances of association blocks, call actions, object nodes, variables, parameters, interaction uses, or submachine states..

An application of adjunct properties is the activity tree. The activity tree shows the call hierarchy of activities in a block definition diagram. The following figure depicts a activity tree of the FFDS use case activitiy Detect and report fire.

Use case activity tree Detect and report fire

Click to enlarge

The properties of the association ends are adjunct properties depicted by the stereotype «adjunct». The values of those properties are constrained to the values of the appropriate call behavior actions defined in the context of the activity. Next figures depicts the activity diagram of Detect and report fire:

Use case activity Detect and report fire

Click to enlarge

Ports with Compartments

Any notation available for parts is also available for ports. That includes compartments with textual or graphical representations. The port shape is accordingly large and still placed on the border of the appropriate part rectangle. 

SysML Port with compartments

Flattr this!

Nordic MBSE School

The Nordic MBSE School

Nordic MBSE SchoolThe Nordic MBSE School is one of my favourite projects. The Nordic MBSE School is organized by the Nordic Systems Engineering Alliance – a network of small and medium-sized organisations with unique competencies in product creation and technical leadership. One of these organisations is my company oose.

Model-based Systems Engineering (MBSE), has for the last decade gradually changed the practice of development and procurement of complex technical systems. Wisely used, MBSE contains a significant potential for improving the quality and efficiency of systems engineering, but it comes with a steep learning curve. To meet this demand, the Nordic MBSE School is an open modular education program conducted in Stockholm, Sweden, October to December 2015.

The program consists of four different two day courses, and a voluntary individual project assignment, that you combine to meet your individual learning outcomes.

The modular approach of the school intends to target different audiences and pinpoint their individual needs. To support individual adaptation of the program, several combinations of course modules stretching from two to eight days are available. This school is equally suitable for organisational leaders, project managers, and engineers wishing to learn more how MBSE can leverage your development organization, and how to put in into useful practice.

More details and registration: The Nordic MBSE School

Flattr this!

Meter

What’s new in SysML 1.4 – Units

The fifth part of the blogpost series about the changes in SysML 1.4 presents the updated concept of units.

But first a big sorry for being quiet for such a long time. But better be quiet than posting spam. I hadn’t enough time to continue my series about the news and updates of SysML 1.4 as well as other interesting things for the MBSE community.

The reason for my absence was one of those interesting things: I was on the final spurt of my new book. Together with some co-authors I’ve written a book about model based system architectures. I’ll publish more details about that project as soon as the book is officially announced by the publisher.

Back to the new things of SysML 1.4. In this blogpost I cover the units of SysML. The modeling of units is part of SysML since the first version 1.0.

In SysML 1.0 a unit was a special value type. A value type could have a reference to a unit and a dimension. The following figure shows the definition and application of some SI units with SysML 1.0. The unit Kilogram is defined with the dimension Mass at the bottom of the diagram.A value type Kg linked with the unit Kilogram is defined at the right side of the diagram. The block My System Component is an example how to use the value type for the value weight. Looks a little bit complicated, but all elements except the block My System Component are supposed to be defined only once in a model library.

SysML 1.0 Units

SysML 1.0 Units

The relationships between a value type, unit and dimension in SysML are shown in the next figure that depicts the definition of the appropriate SysML stereotypes. From my perspective it was a little bit inappropriate that unit and dimension were special value types.

SysML 1.0 Definition of Unit and Dimension

SysML 1.0 Definition of Unit and Dimension

The concept of units was slightly changed in the next version SysML 1.1. Instead of being special value types, the unit and dimension elements were now special instance specifications.That makes more sense, because a unit is not a blueprint fot different unit instances, but already a specification of a single unit instance. Same for the dimension concept.

The following figure shows the definition of the SysML 1.1 unit concept.

SysML 1.1 Definition of Unit and Dimension

SysML 1.1 Definition of Unit and Dimension

The next version SysML 1.2 again changed the unit concept. The model element dimension was renamed to quantity kind and some properties for the unit and quantity kind model elements were added.

SysML 1.2 Definition of Unit and Quantity Kind

SysML 1.2 Definition of Unit and Quantity Kind

There were no relevant changes in SysML 1.3 for the unit model elements.

Now the latest version SysML 1.4 comes with another change. The basic concept is the same, but the concrete implementation of the model elements fits now better into the architecture of SysML. The unit and quantity kind are now no longer stereotypes. They are instance specification properties of the value type as depicted in the next figure.

SysML 1.4 Definition of Unit and Quantity Kind

SysML 1.4 Definition of Unit and Quantity Kind

The properties of the unit and the quantity kind concepts are defined in a model library.

SysML 1.4 Model Library for Unit and Quantity Kind

SysML 1.4 Model Library for Unit and Quantity Kind

The next figure shows the application of the SysML 1.4 unit concept

SysML 1.4 Example of Unit Kilogram

SysML 1.4 Example of Unit Kilogram

The SysML 1.4 specification provides a model library with the ISO 8000 units in the appendix. That library is for instance implemented by the modeling tool Cameo Systems Modeler from NoMagic. With that library the modeler has access to a huge set of predefined units.

Parts of the ISO-8000 library in Cameo Systems Modeler

Parts of the ISO-8000 library in Cameo Systems Modeler

Flattr this!

Nordic Systems Engineering Tour

NoSE 2015: Last submissions, please!

End of this week is the deadline for the Call for Presenters for the 3rd Nordic Systems Engineering Tour. Share your knowledge and join the tour.

The NoSE Tour is a non-commercial community event organized by four local chapters of INCOSE. It is a 1-day conference traveling from Hamburg to Copenhagen via Stockholm to Helsinki.

Find more information about the tour on the official website: www.nordic-systems-engineering-tour.com.

Reports from the last tours NoSE 2013 and NoSE 2014.

See you,
Tim

Flattr this!

Binding of bound references

What’s new in SysML 1.4 – Constraining decompositions

The fourth part of the blogpost series about the changes in SysML 1.4 presents the new concept to constrain a decomposition hierarchy.

The following figure shows a simple product tree of a drone subsystem (DS) for a forest fire detection system (FFDS). It is the sample system I’ve also used in some previous posts.

Product tree of a drone subsystem for a forest fire detection system

Product tree of a drone subsystem for a forest fire detection system (click to enlarge)

The structure allows different configurations of drone subsystem instances due to the multiplicitiy of the camera and the heat sensor and generalization of the camera. For instance drones with 2 standard FFDS cameras and no heat sensor or 1 highend FFDS camera and 1 heat sensor and so on.

SysML 1.4 introduces a new model element to constrain decomposition hierarchies. It is called bound reference. It  is a marker to highlight properties that are connected to other properties with a binding connector to constrain them. The binding connector specifies that the values of the connected properties must be the same.

The following diagram shows the definition of the bound reference properties for the drone subsystem:

Product tree of a drone subsystem for a forest fire detection system with bound references

Product tree of a drone subsystem for a forest fire detection system with bound references (click to enlarge)

The bound reference properties are connected with the appropriate properties in the decomposition hierarchy with a binding connector:

Binding of bound references

Binding of bound references (click to enlarge)

The bound reference bindingPath is a derived property. The value specifies the path from the enclosing block to the connected property and could be derived from the binding connector relation.

The type of the bound reference must be compatible with the type of the connected property. Otherwise the values of properties could not be the same.

In our example the types are the same (Camera and Heat sensor). The multiplicity of the bound reference is more general than the multiplicity of the connected properties. Therefore it is not necessary to update the multiplicity each time when the multiplicity of the connected properties changes, for example due to a change of the requirements or a new architecture decision..

Now it is easy to define special drone subsystem configurations. For instance drones with 2 standard FFDS cameras and no heat sensor or drones with 1 highend FFDS camera and 1 heat sensor:

Variants of a drone subsysteme with bound references

Variants of a drone subsysteme with bound references (click to enlarge)

Of course the concept of the bound reference properties could be used for the modeling of variants (for example see my blogpost Variant Modeling with SysML).

Flattr this!

SysML 1.4 - View and Viewpoint - Example

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.

Flattr this!

SysML 1.4 ElementGroup

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.

Flattr this!

The digital product model

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).

Flattr this!