MBSE Tutorial
MBSE tutorial prepared by TONEX intends to review the concept, tools, models, and requirements of mode-based systems engineering. This tutorial is a general guideline to introduce you to the topics on-going in this area and to give you some hints on what to look for to study and learn if you need to deeply understand this subject. Thus, this article is useful for you if you are just starting to learn MBSE, or if you want to brush up you knowledge about MBSE.
Introduction to MBSE
The idea behind MBSE was to develop a tool to simplify the understanding of complex systems by modeling them. In fact, MBSE helps to facilitate the system requirements, design, analysis, verification, and validation activities. It can be employed at any level of the system, from the initiating design, through development, and to life cycle phases.
In other words, MBSE intends to replace the document-based methods to improve the practice of systems engineering by fully understanding the definition of systems engineering protocols.
MBSE Definition
Model-based systems engineering (MBSE) is basically a thought process. It delivers the structure to enable the systems engineering team to be efficient and coherent all the way from the start of any project to the end. At the same time, it is adequately adaptable to let the “thought” process to adjust to certain limitations or conditions existing in the problem.
The main advantages of using MBSE include models comprehensively take the whole engineering problem into consideration, apply a coherent language to explain the problem and the solution, generate a reliably designed solution, and thoroughly and verifiably satisfy all the system requirements presented by the problem. Such techniques of model-based systems engineering are crucial advantages when searching for a solution to the systems design problem.
System Definition
According to INCOSE, system is constructed or collected of various elements that together can generate the outcomes that are not achievable by the individual elements, alone.
Moreover, a system should connect its components together through definitive relationships, in a way that they are coherently organized.
Furthermore, the system components should be organized following a defined purpose or goal. In other words, the system’s elements should be constructed in order to achieve a series of certain tasks with the goal of producing the expected results.
System Design Properties
- Entities
- The parts construct a system, including atoms or molecules; larger bodies of matter like sand grains, raindrops, plants, or animals; or even components like motors, planes, missiles, etc.
- Attributes
- The features of the entities that could be seen and evaluated such as quantity, size, color, volume, temperature, reliability, maintainability, and mass.
- Relationships
- The relations that happen among entities and attributes. Such relations are based on cause and effect.
The System Language
In order to describe a design, like any other matter, engineers need to use some form of language. Such language is defined based on the system properties—the entities, attributes, and relationships. The system language is crucial to explain and communicate the system properties and characteristics between the engineering team as well as to other stakeholders.
Thanks to system language, each system can be demonstrated hierarchically, enabling it to be seen as decomposable into eloquent subunits. These subunits are traditionally named:
- a system is made of subsystems;
- subsystems in order are comprised of assemblies;
- assemblies are constituted of subassemblies, and
- subassemblies are combined of parts
The parts of a system communicate with each other to generate the function of the entire system. It is automatically clear that all elements of the system must be operating as planned in order for the system to operate accurately. However, it is not so clear that how enhancing the operation of one of the system elements, would essentially enhance the performance of the entire system. The reason is because the impacts of interaction inside the system are often not very clear.
Systems Engineering Definition
According to INCOSE, systems engineering is responsible to generate and perform a cross-functional procedure to certify that the client and stakeholder’s demands are fulfilled at a high level, reliable, cost efficient and timetable compatible behavior across the whole life cycle of a system.
Essentially, this means that the systems engineer’s job is to generate and sustain a system that fulfills the customers’ needs. That can be achieved only through focusing on the entire system and the system’s exterior boundaries.
Systems engineering focuses on the designing, constructing, and applying systems comprised of real entities such as engines, machines, and structures. It is comparable to business systems, which are constituted of processes. Systems engineers require accessing an organized tool of thinking about those systems in their functional frameworks. This approach of thinking is the core of systems engineering.
Multidisciplinary Approach
The regularity of systems engineering unites divisions of engineering and science to plan and create solutions for the stakeholders’ demands. By applying a systems view of the problem and the potential solutions, systems engineers can tie the diverse disciplines to design a solution that answers the needs of the stakeholders in the most efficient way. The control of systems engineering comes from applying such cross-functional technique of problem solving to fulfill the needs of stakeholders by creating or modifying a system.
Every technique has its pros and cons. The multidisciplinary perspective of the systems engineering team empowers the divergent experience and skill of the different approaches though it also can cause possible problems due to the diversity of specified vocabulary and approaches of interacting that are customary in those disciplines. It is the job of the systems engineer to provide the coordination and communication that will allow the power of a multidisciplinary approach to benefit the problem-solving effort without being impeded by the potential miscommunication and friction between the disciplines.
Problem Classes
- Top-down or “clean-sheet” problems
- Middle-out or system-improvement problems
- Reverse-engineering or system-replacement problems
Top-Down Engineering Problems
In these situations, which are by the way the most famous one among the three problem classes, the engineering team deals with designing an exceptional system solution to stakeholder problems. Such designs are also usually called “greenfield” or “clean-sheet” development works. These systems have many mysteries, solving of which often requires extensive research, creating new materials, new elements, and new production methods to deliver all that is required to execute the solution.
Middle-Out Engineering Problems
Middle-out engineering starts with modeling the “as is” stage of all or a part of a system. This offers a comprehension of the current “solution” and the supporting procedures and technology. Then, the engineer could see what can and cannot be modified and spot the possibilities for modification and enhancement or fulfilling new requirements. This is the stage for designing an enhanced or “to be” set of solutions to customer-reported problems using the developed system- level specifications and the customer-derived problem statement(s).
Reverse-Engineering Problems
Bottom-up or reverse engineering employed to promote or substitute legacy systems, which may have been in operation for many years. Such systems could have had broad improvements and corrections added over the life of the system. These are commonly executed in the absence of sufficient documentation. If documentation is adequately available, it usually includes various losses and errors.
The Design Space: Three Systems
Every system design or improvement happens within the three systems. The most noticeable is the system being designed. The system being designed will operate within a larger system. The second system is a contextual system; the system under design, “living and working.” The third and final system is the system that is used to design the system and make it alive. This system is crucial because it encourages the quality and eventual success of the design. This is the system that must know the other two systems and must at the same time be “self-aware.” It is only via such self-awareness that the design can adopt its full evaluation of intentionality and control the considerations presented in the other two systems.
The Design Space: Boundaries
Once the systems engineer digests the notion of the three systems, they must understand the boundary between the system being designed and the system it will live in. The first one is inside the “control” of the design process, and the other simply exists and must be adapted to.
The Process
Systems engineer firstly need to generate an unambiguous problem statement, establishing the issue or issues are being addressed by the proposed system. This requires collaborating with others (particularly system stakeholders and subject-matter experts) to determine the expressed requirements that control what would describe an satisfactory solution.
Domains
The work on the design progresses in four domains:
- Requirements
- Functional behavior
- Architecture
- Verification and validation.
Model Definition
Models connect the concept behind a design solution with its execution as an actual system. Models intend to demonstrate the entities of the engineering problem (opportunities) and their interactions to each other and tie them to the projected solution or the current mechanism that describes the problem. The model used in this way is the centerpiece of MBSE.
Model Components
- Language
- Structure
- Argumentation
- Presentation
Successful Model Characteristics
- Order
- Power to Demonstrate and Persuade
- Integrity and Consistency
- Insight
Language Behavior Characteristics
- The capability to seize the process flow and control
- The capability to seize observables
- Understandability
- Executability
- The capability to reserve behavior across:
- Decomposition
- Aggregation
- Allocation
Structure: The Model Expresses System Relationships
- Sequence
- Concurrency (or AND) construct
- Select (or OR) construct
- Multiple Exit Function
- Iterate (IT)
- Loop (LP)
- Loop Exit
- Replicate
- Exit
Requirements for a Systems Engineering Process
Below are the systems engineering requirements that MBSE can perfectly fulfill:
- The process must coherently lead to successful systems development
- The process must regulate and monitor system complexity well
- The process must lead to efficient solutions to a variety of customer needs.
- The process must be able to serve the three main problem classes
MBSE Tools
- Functional flow and improved functional flows
- N2
- IDEF0
- Physical block
- Systems Engineering Solutions
- Robust and agile analysis
- Requirements definition through architecture to systems verification
- End-to-end traceability
- Extensive behavioral modeling representing control flow, function flow, and interface flow
- System simulations
- Behavioral models
- Integrated Model-Based
- Model Based Operational and System Architecture
How Can You Learn More?
Browse through our hands-on training courses to find what serves you best:
Advanced SysML Training | Creating SysML Models
MBSE Training | Model-Based Systems Engineering Training
Model Based Requirements Engineering
Requirements Engineering Workshop with Use Cases
SysML Training | Systems Modeling Language Training
MBSE Tutorial