This article is primarily aimed at system architects who specify and/or document simple as well as highly complex systems using a standardized notation. The OMG (Object Management Group) standardized SysML (Systems Modeling Language) specifically for these tasks. SysML specifies a total of nine diagrams and their notations. This article presents the four most important ones and their application in the example project of an engine control unit. Tools support system architects in applying SysML. Learn how a SysML model can be structured.
What is SysML?
In document-centric development, technical project information is scattered across numerous documents and often difficult to locate. Model-centric development, on the other hand, aims to centralize all this information within a single model. The corresponding documents mentioned earlier, such as the system architecture specification, can then be generated from the model with the help of a tool at the push of a button. For these models to be understandable to all project stakeholders, the notations used must be familiar and ideally adhere to a standard. In software development, this is achieved through the use of... UML (Unified Modeling Language) is already widely used. However, it is only partially suitable for system modeling.
For this reason, the related species exists SysML (Systems Modeling Language) Standard specifically for system modeling.
Figure 1: Model-based development with SysML and UML
UML and SysML provide semantics (meaning) and notation (graphical representation of meaning) in the form of diagrams.
Historically, UML existed before SysML. Figure 2 shows that both standards specify some of the same diagrams.
Figure 2: Relationship between SysML and UML
Figure 3 shows a detailed overview of the diagrams standardized in SysML and their relationship to UML.
Figure 3: SysML diagram overview
Only the diagrams marked with a dot in Figure 3 are considered below as a first introduction to the topic of system modeling with SysML:
Use case diagram, sequence diagram, block definition diagram and state sequence diagram.
Presentation of a system example: Engine control
The example system of motor control shown in Figure 4 will serve as a practical application of SysML diagrams. The functionality of the motor control system can be summarized as follows:
The system consists of a motor unit, a motor control unit, and a motor controller. The motor unit comprises an encoder, a brushless DC motor, and a gearbox. The motor control unit handles the direct control and speed regulation of the BLCD motor. The motor controller unit manages user interaction via an LCD touchscreen and executes the following application.
The application allows the user to adjust the rotational speed of the BLDC motor using virtual, displayed values from -7.0 to +7.0 in increments of +/-0.5. The sign determines the direction of rotation, and 0 means standstill.
The application provides the user with two primary operating modes: STOP and RUN. The user can switch between these two modes using the STOP/RUN button. In STOP mode, the drive is deactivated. In RUN mode, the drive is activated and provides the user with two operating modes, DIRECT and PRESELECT, selectable via the MODE button.
Figure 4: System example engine control – SysML
In DIRECT mode, pressing the INCREASE ▲ and DECREASE ▼ buttons directly affects the motor's current speed. The ENTER key has no function in DIRECT mode. In PRESELECT mode, the user can set the preselected speed using the INCREASE ▲ and DECREASE ▼ buttons. The motor's current speed remains unchanged initially. Only when the ENTER key is pressed does the preselected speed become the current speed and thus apply to the motor. Once the speed is applied, the application automatically resets the preselected speed to zero.
Use case diagram of the SysML notation
In the context of the system development process, the use case diagram supports the system requirements analysis (see Table 1) by graphically visualizing functional requirements and their relationships.
Figure 5: Use-case diagram notation (SysML)
The (sub)system boundary precisely defines the system under consideration. Everything that is part of the system lies within the boundary. Actors represent all elements that interact with the system. These can be, for example, people, but also other external systems. A use case represents a set of functional requirements. Functional requirements specify what the system visibly accomplishes externally.
To ensure the use case name is as meaningful as possible, it should consist of a noun-verb combination. The association, as a relation between actor and system, more precisely between actor and use case, describes the interaction between them. Direction can be indicated by arrows (unidirectional, bidirectional). In the diagram above, the direction is not specified. This is represented by the simple connecting line without arrows.
The use case diagram offers several other notations to represent more complex situations.
SysML Use Case Diagram – Practical Example: Engine Control
The context view in Figure 6 shows the environment into which the system integrates. A key characteristic of the context view is the single, all-encompassing use case that represents the complete central system functionality(s).
Figure 6: Context view with the use case diagram (SysML)
In this example, the Power_Supply acts on the system, the user interacts bidirectionally, and the system generates a RotationalSpeed_Torque.
The functional requirements view refines the central use case of the context view. For more complex systems, a hierarchical organization of the functional requirements views is recommended.
Figure 7: Functional requirements view – top level (SysML)
At the top level, the operating modes STOP and RUN are the focus. The use case "Select and operate RUN mode" also executes the use case "Enable drive", which is done via the < The relationship is modeled. This also applies analogously to the other two use cases.
Figure 8 shows the use case diagram, which describes the use case "Select and operate RUN mode" in more detail.
Figure 8: Functional requirements view for the use case Select and operate RUN mode (SysML)
The operating modes DIRECT and PRESELECT can be refined in further use-case diagrams.
Sequence diagram of the SysML notation
In the context of the system development process, the sequence diagram supports system requirements analysis and system architecture analysis (see Table 1) by graphically representing interactive and non-generic interactions between different elements. These behavioral excerpts are also referred to as scenarios. They can be used, for example, as test scenarios at various stages of development.
Figure 9: Sequence diagram notation (SysML)
The structural elements used to communicate over time depend on the current step in the development process (see Table 1). Each structural element contains a lifeline that indicates its lifetime. In system requirements analysis, use cases and actors can be represented via external communication. In system architecture analysis and design, these are the blocks and their ports presented below.
The sequence diagram distinguishes between synchronous (filled arrow) and asynchronous (open arrow) interaction. In synchronous communication, the caller waits until the interaction is complete and then continues. The control focus indicates the call duration. Upon completion of the synchronous interaction, a return to the caller occurs, which can provide information. In asynchronous communication, the caller (trigger) initiates the interaction, for example, via signals or events, and then continues immediately without waiting.
The sequence diagram offers many other powerful notations to represent even the most complex, non-generic processes.
Sequence diagram of SysML – Practical example of motor control
The scenario in Figure 10 describes a specific process for the use case "Select and operate PRESELECT mode". The scenario describes exactly the process for getting from the specified preconditions to the postconditions – nothing more!
Figure 10: Scenario for the use case Select and operate PRESELECT mode (SysML)
Block definition diagram of the SysML notation
In the context of the system development process, the block definition diagram supports system architecture analysis and system architecture design (see Table 1) through the graphical representation of functional and physical structural elements and their communication links.
Figure 11: Block Definition Diagram Notation (SysML)
A block represents a physical or functional architectural element. The precise identification of whether it is physical or functional could, for example, be achieved using stereotypes. Blocks can be nested; for instance, a physical block can contain multiple functional blocks. Associations between blocks determine the communication paths. Flow ports serve to specify the communication points at the blocks more precisely. From the use case diagram, the actors there, as system-external elements, can be connected to blocks, optionally via ports, using this association.
If a block of the same type is present multiple times in a system, blocks and ports can be instantiated. For physical blocks, this means that the block is developed once but produced multiple times and installed multiple times in the system. Identical and/or parameterizable functional blocks can also be used multiple times. The block definition diagram offers many other powerful notations for representing even the most complex system architectures..
Block definition diagram of SysML – practical example: engine control
Figure 12 shows the system architecture from a physical point of view with the internal communication paths, but also the communication to external elements (actors) is modeled.
Figure 12: Physical system architecture view (SysML)
In this example, the Reduction attribute specifies the gear ratio of the engine transmission.
State sequence diagram of the SysML notation
In the context of the system development process, the state sequence diagram supports the System requirements analysis and that System architecture design (see Table 1) by graphically representing the generic behavior of individual elements, e.g., a use case or a block.
It is possible to equip the blocks with additional elements; for example, the system architect can specify the corresponding block properties via attributes.
Figure 13: State sequence diagram notation (SysML)
State sequence machines are used in many development disciplines, not only in system modeling but also in software and logic development. A state machine consists of the states that the described element can assume and the possible state transitions between them. The initial transition defines the starting point of the state sequence machine. Each transition can be arbitrarily combined with a parameterizable event, a condition, and an action list. Once the event and condition have been defined, both must be present for the transition to be executed.
Each state is itself divided into three substates, which are traversed automatically. Upon entering a state, the onEntry substate is traversed, and the optionally associated action list is executed. The automaton then enters the onDo substate, which can also be optionally linked to an action list. Before executing an exit transition, the onExit substate is traversed, and the optionally associated action list is executed. The substates and their action lists are also valid for self-transitions. State sequence automata can be structured hierarchically (nested) and can contain parallel automata.
The state sequence diagram offers many other notations to represent even the most complex generic processes in the system.
SysML state sequence diagram – practical example: engine control
Figure 14 shows the state behavior of the Main_Control_Board. This does not yet indicate whether it will later be implemented in hardware or software.
Figure 14: State sequence machine of the Main_Control_Board (SysML)
SysML model building
There are certainly many approaches to building and organizing a SysML model. Regardless of the model structure you ultimately choose, it's crucial that every project member understands and adheres to it. A template model should be available within the company for this purpose. All modeling agreements should be documented in a company-specific SysML style guide.
Figure 15: Model organization in SysML
Figure 15 shows an example of a model organization. The SysML model of the motor control is divided at the top level into System_Requirements and System_Architecture, thus separating the WHAT (requirements) from the HOW (architecture).
Summary
The SysML standard specifies diagrams and their notations. However, it doesn't directly address their use in the system development process. Defining this for one's own needs is the challenge for each company. Table 1 provides an initial guideline.
| Activity in system development |
Visualized situation |
SysML diagram
|
| System requirements analysis
|
System context view |
Use case diagram |
| Functional requirements view |
Use case diagram |
| Scenarios of external communication (use-case and actor-based) |
Sequence diagram
|
| System architecture analysis |
Functional and/or physical system architecture |
Block definition diagram |
| Communication architecture |
Block definition diagram |
| Internal communication scenarios (block- and port-based) |
Sequence diagram
|
| System architecture design
|
Refined functional and/or physical system architecture |
Block definition diagram |
| Generic behavior for functional and/or physical blocks |
State sequence diagram
Activity diagram
(not presented here) |
Table 1: SysML usage in the context of the system development process
Further links
SysML and UML are registered and protected trademarks of the Object Management Group (OMG).
MicroConsult supports you with training and coaching in the areas of system analysis and system design:
Training & coaching on the other topics in our portfolio can be found here.
Workshops on system analysis and system design
Furthermore, there is the possibility to explore the topic area Systems Engineering also in tailor-made workshops to address. They are tailored to the specific needs of tasks, projects, teams, and roles.
Please contact us with your questions, requests and requirements – we are happy to assist you at +49 (0)89 450617-71. Or send us the contact form.
EN 
DE 
