In this post, we will introduce the MBSE Grid method, one of the MBSE (Methods of Model-Based Systems Engineering) methodologies.
MBSE Grid
This content is based on the paper “MBSE Grid: A Simplified SysML-Based Approach for Modeling Complex Systems.” The authors of the paper include Aurelijus Morkevicius.
The MBSE Grid framework can be seen in the picture below. This framework addresses four key aspects of systems engineering using Systems Modeling Language (SysML). These aspects are ‘Requirements’, ‘System Structure’, ‘System Behavior’, and ‘Parameters’. These are expressed in columns, and the ‘Problem Domain’ and ‘Solution Domain’, which present each problem and solution, are divided into rows.
This structure provides an effective understanding of how to systematically model complex systems.
Problem Domain is largely subdivided into Black Box Domain and White Box Domain. The Black Box Domain discusses the System of Interest (SOI) as a whole, defining stakeholder requirements, functionality the system should provide, user scenarios, interactions between the SOI and the environment, and efficiency measures. This includes an analysis of the operation of the system.
On the other hand, the White Box Domain describes the expected behavior of the SOI’s subsystems. In this view, the external environment, including the users of the SOI, is no longer considered, and the inputs and outputs of the SOI are delegated to subsystems. The results of white box analysis are system requirements derived from stakeholder needs.
Each cell in the MBSE Grid represents a different view in model-based systems engineering, and these views represent specific models that can be visualized through SysML diagrams. This structured framework greatly helps in clearly understanding and systematically analyzing the characteristics of complex systems.
A description of each View is as follows.
1. Stakeholder Needs
Stakeholder requirements represent information collected from various stakeholders in the system. This includes state user requirements, government regulations, policies, procedures and internal guidelines. These requirements are derived from interviews, surveys, focus group discussions, and documentary research in various formats. The information derived is raw, but does not need to be specifically rewritten. During the subsequent refinement of the model, these requirements are structured and formalized. Capture this using a SysML requirements diagram or table.
2. Use Cases
Use cases capture granular functional stakeholder requirements in the form of SysML use case diagrams. Each use case defines the goals to be achieved using the system by the primary or secondary users (maintenance personnel, external software or hardware). It also includes use case scenarios that define the flow of actions or events, prerequisites, constraints, etc.
3. System Context
System context captures how the system’s interest (SoI) interacts with its environment. Capture system context using SysML internal block diagrams.
4. Measurements of Effectiveness
Effectiveness measures express in numeric form the non-functional goals set by the user for the system. Measures of Effectiveness (MoE) are captured in SysML block definition diagrams. The MoE calculation method is illustrated using SysML parametric diagrams.
5. System Requirements
Input data for specifying system requirements are stakeholder requirements. By analyzing stakeholder requirements, system requirements are identified and specified. These requirements are captured using SysML requirements diagrams, tables, or both. This step involves defining and documenting the basic functions and characteristics that the system must meet.
6. Functional Analysis
Functional analysis continues the analysis of functional use cases and uses process techniques to focus on the internal functionality of the system. Functional analysis is also used to identify logical subsystems that perform a set of functions. This process can be represented in the form of several SysML activity diagrams.
7. Logical Subsystems Communications
Communication between logical subsystems is used to identify how the subsystems relate to each other based on the control and resource flows captured in the functional analysis model. Logical interfaces are identified, defined, and used as input to create an Interface Control Document (ICD). To capture this point, a combination of SysML block definition diagrams and internal block diagrams is used.
8. MoEs for Subsystems
Subsystem Measures of Effectiveness (MoEs) and Performance Measures (MoPs) are identified and captured for each logical subsystem. This measure is captured in the SysML block definition diagram. The method for calculating MoEs is explained using SysML parametric diagrams.
9. Component Requirements
Component requirements capture detailed, formal requirements for each component. These requirements are derived from system requirements and include design constraints, etc. Component requirements are captured using SysML requirements diagrams, tables, or both. This process clearly defines what function and role each component should play within the system.
10. Component Behavior
The behavior of components is described in detail by defining the state and behavior of each component. This includes algorithm execution, operation invocation, signal processing, etc. The detailed behavior of components can be verified through simulation, captured using a combination of SysML state machines, activity, and sequence diagrams. These diagrams help you visualize how each component will perform in a real operating environment.
11. Component Structure
The structure of a component shows the connections between physical components. This connection is based on physical interfaces, where physical components implement logical subsystems created from a problem perspective. The detailed design of the components is not covered at this point, but the structural connections are captured using a combination of SysML block definition diagrams and internal block diagrams.
12. Component Parameters
The parameters of a component capture the physical properties of each component and the dependencies between them, and how these physical properties contribute to achieving the Measures of Effectiveness (MoEs) and Measures of Performance (MoPs) defined in the problem definition hierarchy. Please specify. Parameters are captured in SysML block definition diagrams, and how derived parameters are calculated is described using SysML parametric diagrams.
The instantiation method of every View specification by SysML diagram is shown in the figure below.
CASE STUDY
An example of the vehicle temperature control system, which is the case presented in the paper, is summarized below.
Problem Domain: Black Box
Stakeholder Needs
Requirements received from project stakeholders can be entered directly into SysML or in other formats, such as requirements management tools such as IBM® Rational® DOORS®, spreadsheets such as Microsoft Excel, and ReqIF files containing requirements data exported from other tools. You can get it from the tool:
In SysML, stakeholders’ requirements are specified as requirements that include a unique identifier, name, and text description. All requirements can be viewed at a glance in the SysML requirements table or requirements diagram. Requirements can be hierarchically related to each other through containment relationships.
For example, a stakeholder’s requirement for a climate control device is shown in the SysML requirements diagram (Fig 5. a). This requirement is further analyzed and refined, and the requirement called “Heat and Cool Modes” is ” It is broken down into use cases called “Feel Comfortable Temperature”. This process is derived from the “Reach Desired Temperature” step in the use case scenario.
Use Cases
SysML use case diagrams specify the users of a system (humans, organizations, external systems) as actors or blocks and relate them to use cases using standard associations. (Fig 5.b)
MBSE (Grid) requires use cases to be grouped into contexts that use the system in various situations. Therefore, every SysML use case diagram must be created taking into account the context in which the use case it represents is performed. Context can be stored in the model as a SysML block. For example, you see the use case “Feel Comfortable Temperature” in the context of “Vehicle On”. One use case can be performed in many different contexts.
Use cases are supplemented with additional information as needed, including follow-up conditions, baseline scenarios, and alternative scenarios. Each use case must have a base scenario; alternative scenarios are optional. Use case scenarios can be captured in the form of SysML activity diagrams and expressed as a flow of actions performed by actors and systems. (Fig 5. c)
For example, the base scenario for the “Feel Comfortable Temperature” use case is represented by swimlanes representing the perspectives of actors and systems. The activities performed are allocated according to actors and systems. The activities performed by the climate control unit are the core functions of the system. All top-level features are connected to the SN (Stakeholder’s Requirements) using a refine relationship, for example the “Reach Desired Temperature” feature refines the “Heat and Cool Modes” SN.
System Context
SysML internal block diagrams are used to show how the system interacts with the environment of interest (actors, external systems, etc.) in different contexts, which are identified while modeling the use case. Because each context defines a unique situation of system use, the environment of the system may vary.
For example, you can see Figure 5d, which shows the interaction between a climate control unit and its environmental units in the context of “Vehicle On”. These diagrams clearly illustrate the connections and communication paths between a system and its external elements, helping system designers better understand the system’s integration and interaction.
Measurements of Effectiveness
You can use SysML block definition diagrams to define Measures of Effectiveness (MoEs). The MoEs captured in this diagram break down non-functional stakeholder requirements (SNs). A separate block called ‘Climate Control MoEs’ is created to define a set of reusable MoEs (see Figure 5e). System of Interest (SoI) inherits MoEs from ‘Climate Control MoEs’.
SysML’s override mechanism allows defining different default values for each MoE and refining different requirements. This allows system designers to customize the details of MoEs to define performance metrics specific to a particular system or scenario.
Problem domain: White box
White box defines the white box of a System of Interest (SoI), including system requirements (SR), functional analysis, and logical architecture. This step helps you understand the expected results rather than the design of the system to be delivered.
System Requirements
System requirements relate to all view specifications within the domain and are derived from stakeholder requirements step by step as you work through functional analysis and logical subsystem communication view specifications. This process demonstrates how system requirements are linked to the initial needs of stakeholders and how these requirements are broken down into more specific features and components of the system.
For example, Figure 6a shows the ‘SR Heating and Cooling’ system requirements derived from the stakeholder demand (SN) ‘Heat and Cool Modes’. This is a good example of how functional requirements are linked to the functionality of the actual system during the system design process.
Functional Analysis
Functional analysis is a continuation of the process of breaking down use cases using SysML activity diagrams. Once the top features of a system of interest (SoI) are identified as BlackBoxes, they can be further refined. In the MBSE (Grid) approach, there are several granularity rules to maintain consistency between levels of granularity in various pillars. For example, the swim lanes shown in the SysML activity diagram generated for the top-level features of the SoI should be representative of the logical subsystems of the SoI.
A new SysML activity diagram is generated for every function assigned to a SoI. For example, Figure 6b shows the SysML activity diagram for the ‘Reach Desired Temperature’ feature. There are two Swim lanes in this diagram, one representing the ‘Data Transfer Group’ subsystem and the other representing the ‘Control Group’ subsystem. Each feature identified in the diagram can be further refined in the following ways:
- Can be further refined by the new SysML activity diagram.
- Functional system requirements (SR) can be broken down. For example, the ‘Start Heating’ function subdivides into ‘SR Heating and cooling’.
Logical Subsystems Communications
Swimlanes in a SysML activity diagram are very useful for identifying logical subsystems, and once these subsystems are identified, the connections and interfaces between each need to be defined. Following the MBSE (Grid) approach, as a first step, a SysML block definition diagram is created for the system of interest (SoI) (Figure 6c), followed by a diagram for each logical subsystem. The purpose of this diagram is to define the subsystem of interest (SSoI) as a BlockBox. In this diagram, it is recommended to capture the inputs and outputs of the SSoI, often also the Metrics of Effectiveness (MoEs) of the SSoI.
In the next step, a SysML internal block diagram for SoI is created. The purpose of this diagram is to connect the use of subsystems through defined interfaces. For example, Figure 6d shows the internal block diagram of a climate control unit. This diagram shows how the control group subsystem communicates with other subsystems, such as the data transfer group.
MoEs for Subsystems
The final step is to specify the Metrics of Effectiveness (MoEs) for the system’s subsystems and define methods for evaluating them. The method for evaluating MoEs is defined using constraint blocks. It is recommended that MoEs have a refine relationship with System Requirements (SRs). This approach effectively structures the system’s performance evaluation process and helps ensure a clear measure of the contribution of each subsystem to meeting overall system goals.
Solution domain
After you have accurately defined the problem, you can identify one or more solutions.
Component Requirements
Solution architecture defines requirements more clearly and specifically in a text-based manner. This requirement has the following characteristics:
- Concreteness – Requirements relate directly to concrete elements such as physical components and their characteristics, such as design constraints.
- Verifiability – According to the study by Morkevicius and Jankevicius (2015), all requirements in the solution domain should be designed so that they can be automatically verified.
For example, component requirements are derived from system requirements (SR), and a specific example is noise-related among component requirements (CR) derived from SR heating and cooling, as shown in Figure 7a. ‘CR noise’ is very specific, such as “below 45dBA”, and such text is clear enough for machines to read and automatically verify. This approach streamlines the design and verification process and reduces the potential for errors in systems engineering.
Component Structure
The SoI structure is modeled together with or simultaneously with component requirements (CR), and this process includes the following elements:
- Modeling Tools – SoI structures are modeled using two main tools in SysML (Systems Modeling Language):
- Block Definition Diagram – Defines the components of a system and their relationships.
- Internal Block Diagram – Shows the internal structure and interconnections of components.
- Characteristics of the diagram – Compared to the logical subsystem communication diagram of the problem domain, there are several important differences:
- Physical Components – The parts of a component structure diagram represent the physical parts of the system.
- Physical Interface – Interfaces modeled in diagrams have physical properties, not logical ones.
- Classification of components and interfaces – According to best practices, components and interfaces are classified into categories such as software, mechanical, electrical, optical, etc.
- Importance of Detailed Design – It is important to perform detailed design of every physical component, which implements the logical components defined in the problem domain. In this process, abstraction relationships are used to capture vertical traces.
- Visual Example – For example, Figure 7d graphically shows the structural breakdown of a climate control system. These diagrams help you visually understand the components of a complex system and their interactions.
This modeling approach plays an important role in increasing the accuracy and efficiency of systems engineering.
Component Behavior
The process of defining the behavior of the component of interest (CoI) is done to simulate the behavior and physical properties of the system. The main SysML (Systems Modeling Language) tools used in this course are:
- SysML State Machine Diagram – This diagram visualizes the possible states of a component or group of components and the transitions between those states. Each state represents a specific condition or activity state that a component can take.
- SysML Activity Diagram – An activity diagram shows the behavior of a component and the flow that follows that behavior. This diagram includes the tasks performed by the components, the sequence of tasks, and the flow of data between the tasks.
For example, the SysML state machine diagram of climate control software shown in Figure 7b specifically shows how the software passes through various operational states. This provides the following benefits:
- Understanding the dynamic behavior of a system – State machines and activity diagrams allow engineers to systematically understand and predict the behavior of components.
- Error and Exception Handling – By modeling possible error situations and the resulting exception handling procedures, you can increase system reliability.
- Optimization of system design – Visualization of behavior provides an opportunity to identify and improve missing elements or inefficiencies in the design.
These modeling tools allow you to clearly express the behavior of complex systems and more effectively manage the interactions between components and the behavior of the overall system.
Component Parameters
According to the Measure of Effectiveness (MoE) defined in the problem domain, the parametric model is applied to a physical System of Interest (SoI) model to calculate the derived physical properties of the components. The key elements and workflow of this approach are:
- Parametric calculation – For example, for the compressor system depicted in Figure 7c, calculate certain parameters such as noise level. This is done for all relevant components, calculating the noise contribution of each component.
- Overall SoI Noise Level Assessment – Calculates and evaluates the overall SoI noise level based on the calculated individual noise levels. This process is important for understanding the performance and efficiency of the system as a whole.
- Dynamic Simulation – Since all properties of physical components cannot be computed statically, it is common to run behavioral simulations using SysML parameters. This allows you to model the dynamic behavior of systems interacting with real-time data.
- Perform a trade-off study – By performing a comparison and trade-off study between various solution architectures, we explore the best alternative to solve the defined problem. This process helps you evaluate the pros and cons of each architecture and choose the optimal solution.
These methodologies play an important role in the design and optimization of complex systems, helping systems engineers develop more accurate and effective solutions. In particular, it provides the opportunity to optimize the overall system design by considering various aspects such as performance, cost, and efficiency.
If you are interested in other articles about the MBSE Methods, please refer to the links below!
[MBSE-Method] #1. OOSEM (Object-Oriented Systems Engineering Methodology)