The Modelling language SysML

Home 9 Languages 9 SysML

Introduction to SysML

SysML (Systems Modelling Language) is one of the most well-known modelling languages alongside UML, particularly within the engineering and systems domain. SysML 1.x is an extension of UML, more specifically a UML profile.

Version 1.0 of SysML was published by the Object Management Group (OMG) in 2007, with the latest version being SysML 1.7. SysML 1.7 is expected to be the last in the 1.x family, as SysML 2.0 is currently in development. Unlike SysML 1.x, SysML 2.0 will no longer be a UML profile, but a language with its own metamodel (KerML).

SysML 1.x is based on the UML language family with its 14 diagram types, whereby the 14th diagram is the UML profile mechanism with which UML can be extended. SysML 1.x is such an extension. However, SysML is not only a UML profile, but also an OMG standard, which defines a subset of UML for SysML (UML4SysML) and extends the UML language via SysML-specific stereotypes (additional designations on UML language elements).

The reason for a Systems Modelling Language was that some UML diagrams are very much geared towards the description of software systems and are strongly reminiscent of object-oriented software development in terms of terminology. For this reason, some model elements were renamed using stereotypes and some properties were added using TaggedValues. Of the 14 or 13 diagrams (if the UML profile is not calculated), 7 were adopted and two new diagrams were added. SysML therefore has 9 diagrams in contrast to UML with 13 (14 with UML profile) diagrams.

In SysML we therefore find some diagrams that have been adopted 1:1 from UML. These are: the Package Diagram, the Use Case Diagram, the State Machine Diagram and the Sequence Diagram.

The UML Class Diagram, the UML Composition Structure Diagram and the UML Activity Diagram were extended using UML profiles and restricted by constraints defined in the SysML specification.

In addition to these UML diagrams, there are also two completely new diagrams in SysML, the requirements diagram and the parametric diagram.

UML Diagrams

Diagrams are important elements in UML. Find out about all diagram types at a glance here.

UML Diagrams with extensions

SysML for describing domain models

Block Definitions Diagram (BDD)

The UML class diagram is now called the block definition diagram. The main extension is the introduction of the stereotype ‘block’ for the UML class. We no longer speak of classes, but of blocks. The block corresponds more to the understanding of a system engineer.

An extension in SysML is that interfaces can be specified more precisely using UML ports (interaction points) and thus the material exchange between systems and system components can be described more precisely and formally.

For example, we can define that a certain substance (air, liquid, special fuels, electricity, etc.) flows in or out.

The direction of flow is defined with so-called FlowProperties. A property is an attribute that can be contained in a block. The type of the property defines what it is. The type can be another block or a DataType element, which again can be specified more precisely.

The components of the PowerSubsystem with simple blocks, without displaying their ports.

We use the BDD to describe the structural layout of a system, for example. The SysML BDD does not specify which view should be taken, this is defined by a special method, e.g. whether a BDD describes a logical view of the system, a physical view or a software view or a combination of these. Yes, SysML can also be used to describe (software) systems, just as UML can also be used for the general description of systems, with the restrictions added by SysML.

The components of the PowerSubsystem with simple blocks, without displaying their ports.

The PowerControlUnit block with displayed ports, some are typed by blocks with FlowProperties, therefore they show arrows for the flow direction. These ports can also be displayed in the IBD on PowerControlUnit type properties and linked to other ports or properties.

Internal Block Definition Diagramm (IBD)

The internal block definition diagram is an extension of the UML composition structure diagram. As a rule, BDD and IBD in SysML are regarded as two sides of the same coin (black-box and white-box view of the system) and generally always occur together.

We use the BDD to define the components (types) in our system. We use different relationships (generalisation (= inheritance), composition & aggregation (= part-whole relationship) to describe how a system consists of other systems.

The internal wiring of the components of a system is carried out in the IBD. For each aggregation/composition relationship in the BDD, we receive a property element in SysML, which can be seen as a concrete placeholder for the block that is linked to aggregation/composition in the BDD. A block can therefore contain several properties of the same type if there are several aggregation or composition relationships in the BDD.

Composition relationships lead to properties with a solid frame and aggregation relationships to properties with a dashed frame.

Properties usually have a name, a colon, followed by the type of the property (<PropertyName> : <TypName>), usually the type is another block from the BDD. The name of the property is displayed in the BDD as the name at the end of the aggregation/composition relationship. As a result, the BDD and the IBD are each a view of the overall system, which synchronise each other.

 

If a block has ports (small rectangles on the frame), these can also be displayed on the properties in order to access the interaction points of the blocks if they are used in another block (typed as a property with a block with a port). For example, the PowerControlUnit has some ports that can also be displayed in the IBD.

If the port was typed with a block that in turn contains FlowProperties, the port shows a direction [<] [>] or [<>]. The latter means that the ‘good’ defined by the FlowProperty flows in and out or that different things flow in or out.

Aktivity Diagram

The core of the SysML activity diagram is not customised and works in exactly the same way as the UML activity diagram. There are only some extensions with some stereotypes to achieve a better control of flows in the activity diagram. In SysML activity diagrams, for example, we can specify probabilities for the flows (ObjectFlow), define optional flows and describe continuous flows in more detail.

New Diagrams in SysML 1.x

Requirement Diagram

There is no separate model for requirements in UML.The only model that can be used for this is the use case diagram.

We define functional requirements for different stakeholders using Use cases, which are described by UML actors. The use case, depending on the system context, describes the purpose of the system.

However, if we want to describe non-functional requirements or functional requirements that do not necessarily describe the primary purpose of the system, a model is missing in UML.

There has always been a requirements model in Enterprise Architect (EA). In SysML, this is now also standardised and also available in the EA.

With the requirements model, we can primarily define textual requirements modules and link these with the relationships available in SysML in order to enter statements and thus structured information into our model so that we can process these automatically later. This allows the model to answer interesting questions.

SysML offers some special relationships that are used between requirements elements. Not all of them have to be used. The most important relationship between requirements is the ‘derivReqt’ relationship, which states that a requirement exists because of another requirement. If the target of the ‘derivReqt’ relationship is changed, this has an effect on all requirements derived from it.

SysML requirements can also be linked to the rest of the model, allowing complete traceability from the stakeholder requirement to the desired system level to be modelled.

Other important relationships are the ‘refine’ relationship, with which we can describe a requirement more precisely using another model element. This allows us to build a bridge between text modules and model-based requirements.

The ‘verify’ relationship allows us to link test cases (‘testCase’) elements with requirements. The test case describes how the requirement to which it is linked should be tested.

The ‘satisfy’ relationship describes the realisation of a requirement by another model element. For example, a requirement can be implemented by one or more blocks.

Parametric Diagram

The Parametric Diagram is a completely new model and a specialisation of SysML blocks. The SysML block here is called ConstraintBlock (block with stereotype ‘constraint’) and defines a type of equation – which can also be seen as a function – with input and output variables (values). The variables are used in an equation.

«constraint» blocks can now be instantiated in the Parametric Diagram and are called Constraint Properties. Several constraint properties can now be assembled to form a function graph.

Parametric diagrams can be analysed using simulation options. Different sets of variable configurations (of the input data) can be defined. The simulation then calculates the output data.

Mathematical solvers such as Matlab-Simulink or Modellica can also be used for the calculation.

Einfaches Parametic Diagramm mit einem Constraint Property

By combining several constraint properties in a parametric diagram, we can describe more complex systems. The individual constraint blocks serve as a library and the use as a constraint property in a parametric diagram as a simple description of a complex system behaviour.

SysML with Enterprise Architect

In this basic training course, you will learn to understand and use the Systems Modelling Language (SysML) using practical examples with the Enterprise Architect tool.

t

FAQs on SysML

What is SysML and what is the language used for?

SysML (Systems Modelling Language) was developed as a graphical modelling language specifically for systems engineering. SysML 1.0 was officially published by the OMG in 2007 and the beta version of SysML v2 was presented in 2023. SysML is an extension and adaptation of UML (Unified Modelling Language).

As SysML is used for modelling complex systems, it is primarily used in areas such as aerospace, the automotive industry, medical technology and defence.

The main areas of application of SysML are

  • Requirements analysis: modelling and linking of system requirements
  • System architecture: Definition of system components with their relationships and interfaces
  • System behaviour: Modelling the dynamic behaviour of systems using activity, state and sequence diagrams
  • Communication: SysML models are used for communication between different disciplines (e.g. mechanics, electronics, software)

How do you integrate SysML and UML models into a systems engineering project?

To work with SysML and UML models in a systems engineering project, you need a methodical approach.

Here are some practical tips for implementing this integration:

  • Use cases and modelling goals: As is usual at the start of any modelling process, the use cases and objectives of the project should be clearly defined. This is the best way to utilise the strengths of both languages.
  • Diagram types: Depending on the requirements of the project, you now select the relevant diagram types from the two languages
  • Metamodel: The common metamodel defines the relationships between the elements of the SysML and UML models
  • Tool selection: Modern modelling tools such as Enterprise Architect support both SysML and UML and offer mechanisms for integrating both model types
  • System architecture: The system architecture is usually modelled in SysML, which uses block definition diagrams (BDD) and internal block diagrams (IBD).
  • Software modelling: UML is used for the detailed modelling of software components; class, sequence and activity diagrams are usually used for this purpose
  • Linking: Requirements created in SysML can be linked to the corresponding software components (UML)
  • Documentation: Document the models and their relationships in detail to ensure clear communication within the team
  • Integration: By closely integrating the modelling into the development process, you ensure that the current status of the project is always represented

What is SysMLv2 and what innovations does it provide?

SysMLv2 (Systems Modelling Language Version 2) was introduced in the beta version 2023. It is intended to remove the limitations of SysML and thus simplify the modelling of complex systems.

The most important improvements in SysMLv2:

  • Syntax and semantics: the more consistent syntax and semantics should make modelling less error-prone
  • Extended diagram types and modelling concepts
  • Modularity and reusability are better supported
  • Better automation options should make the modelling and verification process more efficient
  • Standardised interfaces for integration with other technologies