Understanding SysML: A systems modeling language in MBSE
In this post, we will cover System Modeling Language (SysML), one of the main topics of this blog.
First of all, what is SysML?
SysML is a systems modeling language used in Model-Based Systems Engineering (MBSE), which focuses on visualizing and communicating system design ideas. The language uses graphical notation, including grammar and vocabulary, and expresses a variety of meanings like a natural language. The purpose of SysML is to clearly communicate system design among stakeholders.
The rules and grammar of SysML are defined by the Object Management Group (OMG), a standard developed collaboratively by industry, government, and academic institutions. SysML is an extension of the Unified Modeling Language (UML) and should be referenced in conjunction with UML’s specification document.
SysML is only a modeling language and does not suggest a specific modeling methodology. This means that you and the project team must select and adapt a methodology that fits your project goals.
This language encompasses various system elements, including hardware, software, and data, and helps specify and design the system. SysML can represent a system’s structural composition, interconnections, functional behavior, physical and performance properties, and relationships with requirements.
The point is that SysML is a very useful tool for systematically analyzing and managing complex systems. This provides a clear view of the overall structure and operation of the system and improves communication between various stakeholders. SysML comprehensively covers various aspects of systems engineering and is a powerful tool for the holistic understanding and management of complex systems.
SysML Diagrams: A Comprehensive Overview of the 9 Essential Types
Composition of SysML Diagram
SysML diagrams provide a variety of visual representations for system modeling, divided into a total of 9 types.
These diagrams represent different aspects of the system and help in understanding and communicating complex systems. The key content of each diagram is as follows:
- Block Definition Diagram (bdd)
- Expresses the structural elements of the system (blocks, value types, etc.) and their relationships.
- Shows the hierarchy and classification of the system.
- Based on UML’s class diagram.
- Internal Block Diagram (ibd)
- Specifies the internal structure, connections and interfaces between parts of a specific block.
- Represents the interconnections and interfaces between block parts.
- Transforming UML’s complex structure diagram.
- Use Case Diagram (uc, Use Case Diagram)
- Expressing system functions and user interactions from a black box perspective.
- Indicates how external entities use the system.
- Same as use case diagram in UML.
- Activity Diagram (act, Activity Diagram)
- Expresses the conversion process from input to output through work flow and control flow.
- Indicates task execution order and conversion method.
- A modified form of UML’s activity diagram.
- Sequence Diagram (sd, Sequence Diagram)
- Displays interactions between objects, invocation of actions over time, and message flow.
- Useful for detailed design and test case specification.
- Same as UML sequence diagram.
- State Machine Diagram (stm)
- Expresses state changes of objects, reactions to events, and state transitions.
- Indicates state transition by event.
- Same as state machine diagram in UML.
- Parametric Diagram (par, Parametric Diagram)
- Demonstrates connections between constraints and system properties.
- Suitable for performance, reliability, availability analysis and architecture trade studies.
- There is no corresponding diagram in UML.
- Package Diagram (pkg, Package Diagram)
- Indicates the package structure of the model and dependencies between packages.
- Displays model composition and package inclusion relationships.
- Same as UML package diagram.
- Req, Requirement Diagram
- Displays text-based requirements and relationships between requirements and model elements.
- Indicates the relationship between design elements and test cases.
- There is no corresponding diagram in UML.
These diagrams graphically represent different aspects of the system model, and the use of model elements and associated symbols is limited to each diagram type.
For example, an activity diagram may include elements representing tasks, control flow, and input/output flow, but it does not include elements for connectors and ports. SysML also provides a way to express model information through tabular representations (e.g., allocation tables). These different representation methods make system modeling more effective and play an important role in the systems engineering process.
Understanding SysML Diagrams: Key Elements and Their Structural Significance
Basic structure and elements of SysML Diagram
- Diagram frame: The outer rectangle of a SysML diagram, the area that contains all content.
- Content area (canvas): The area inside the frame where model elements and relationships are displayed. This contains the main visual content of the diagram.
- Header: Located in the upper left corner of the diagram, it contains important information such as diagram type, model element type, model element name, and diagram name. The header information consists of [Diagram kind] [Model element type] [Model element name] [Diagram name].
- Diagram type and name: The diagram type is denoted by the abbreviation SysML, and the diagram name is given to focus on a specific aspect of the model. For example, bdd stands for block definition diagram, and the diagram above is named taxonomy. This indicates that the diagram focuses on the taxonomy of SysML.
- Model element type and name: Each diagram represents a specific element of the system model. The diagram frame represents the corresponding element in the model, and the header indicates the type and name of that element. For example, in the diagram above, the model element type is “package” and the name is “diagram hirearchy”. This means that BDD stands for ‘structural package’ of the model hierarchy.
- Model Element Namespace: The diagram defines a namespace for model elements. That is, the model element type and name shown in the header indicates where to find the element for that diagram within the model. These connections are important in SysML, making clear the location and role of diagram elements within the model.
- Diagram type and name: The diagram type is denoted by the abbreviation SysML, and the diagram name is given to focus on a specific aspect of the model. For example, bdd stands for block definition diagram, and the diagram above is named taxonomy. This indicates that the diagram focuses on the taxonomy of SysML.
In SysML, the representation of frames is essential. This is one of the differences from UML: frames serve to represent the formal structure of the diagram. When creating a diagram, these structural elements are important for the clarity and information conveyance of the diagram.
Models and diagrams in SysML: interrelationships and important principles
SysML Diagram Relationship between diagram and model
1. Relationship between model elements and diagram types: Model elements can be structural elements (e.g. packages, blocks) or behavioral elements (e.g. activities, interactions, state machines), the model that the diagram can represent.
The type of element depends on the type of diagram you are creating. To elaborate a little more on what the table below means, it does not mean that only package, model, modelLibrary, view, block, and contraintBlock can be entered as Elements on Bdd. Rather, the object being explained by a certain Bdd can be package, model, modelLibrary, view, block, or contraintBlock.
2. Difference between model and diagram: A system model is the engineering result itself, while a diagram is a view of the basic model. A diagram of a model is only a view of the model, not the model itself. This can be explained by comparing a model to a mountain and a diagram to a picture of a mountain.
3. Remove focus and details from the diagram: A given diagram should not attempt to convey all the details. Instead, you need to remove extraneous model information to keep the diagram in focus. The absence of a particular feature in a diagram does not mean that the feature does not exist; it may appear in other diagrams in the model.
These principles form the core of model-based engineering and are important for understanding the relationship between models and diagrams. A model represents a complex system as a whole, while a diagram provides a specific aspect or view of that system. Therefore, for a holistic understanding of the model, various diagrams must be comprehensively considered.
Outro of SysML
In this post, we briefly looked at SysML.
Lastly, I will conclude this post with what I think is the basic knowledge about systems engineering that a systems engineer working in the electronics industry should know.
Since the field of systems engineering is very broad and difficult, I hope that the 10 posts I wrote will give you an opportunity to get a feel for what systems engineering is.
As I wrote in the introduction, I am also writing a blog post to study on my own, so I think there will be a lot of shortcomings and incorrect information. Please be tolerant of these aspects, and if you have any comments or feedback, please always leave a comment.
From the next post, I plan to use Sparx Enterprise Architect to study SysML Modeling from the basics and post step by step.
If you are interested in other articles on systems engineering in the automotive electronics industry, please refer to the links below!
[Systems Engineering] #1. INTRODUCTION – Navigating Systems Engineering
[Systems Engineering] #2. Definition of System
[Systems Engineering] #3. Understanding Systems Thinking
[Systems Engineering] #4. Useful knowledge of systems thinking
[Systems Engineering] #5. Understanding Systems engineering
[Systems Engineering] #6. Who is Systems Engineer
[Systems Engineering] #7. Understanding MBSE (Model Based Systems Engineering)
[Systems Engineering] #8. Additional practical knowledge about MBSE