Modeling of the MBSE project itself-Pitaya Software

Modeling of the MBSE Project Itself

Zu Tao （Pitaya System Engineering）

Views

2020-5-26

Why build an MBSE Engineering Model

The goal of MBSE (Model Based Systems Engineering) is to track and manage the entire System engineering work throughout the life cycle based on the Model. These involve:

Multiple stages: Requirements analysis, System analysis and Design, software analysis Design and development, hardware analysis Design and development, System testing.

Multiple roles: Product Manager, Systems Engineer, Software Engineer, Hardware Engineer, Test Engineer.

Multiple Models: user Requirements Model, System Requirements Model, System Design Model, software Requirements Model, software Design Model, software implementation Model, test Model, etc

Multiple documents: user Requirements documents, System Requirements documents, System Design documents, software Requirements documents, software Design documents, software code, hardware code, test documents, etc.

Because the goal of MBSE is to drive and manage the whole life cycle of Systems engineering, involving so many stages, roles, Models, and documents, a clear grasp of the MBSE project itself is the basis for the effective implementation of MBSE. Moreover, it is also a more challenging thing.

Therefore, the MBSE project itself also needs to be Modeled, so that the engineers involved in the MBSE can know what to do, how to do it, and what the quality Requirements are.

What is MBSE Engineering Modeling

So let's see, what is the engineering Modeling of MBSE itself?

To describe an engineering process, there are generally three views of the core content:

Workflow: Describe what phases the work is divided into, who, what is done, and what is delivered;

Role view: what roles these people are divided into and what responsibilities they have;

Artifact view: What artifacts the deliverable is divided into, what the content template is, and how they relate to each other.

This can undoubtedly be described clearly through Modeling.

In particular, because the workpiece is Model-driven, it is necessary to understand the relationship between various Models: user Requirements Model, System Requirements Model, System Design Model, software Requirements Model, software Design Model, and test Model. It is also important to understand the relationship between the Model and the corresponding documents and items.

How to build an MBSE engineering Model

Having said all this, MBSE is difficult, and one of the solutions is to carry out engineering Modeling of the MBSE project itself.

So, how do you build it?

Modeling the MBSE workflow view with an activity diagram:

Describe clearly: who is responsible for the process - use the tunnel description, what is done - use the activity description, what is delivered - use the artifact description.

The MBSE role Model is Modeled using a role diagram:

Describe clearly: what are the people-people elements, which roles are abstracted into the role-role elements, what responsibilities do they undertake—the activities for which the role is responsible.

Artifact diagram to describe the workpiece Model of MBSE:

The description is clear: Items - Structured Classes, Models - Sys ML or UML Models, Documents - Word Documents/Excel Documents, Pictures - Graphs and Images.

So, how do you Model the process of MBSE? Dragon Fruit Software provides the MBSE platform iSpace to support the engineering Modeling of MBSE:

You can start by creating an MBSE workflow

Then assign roles to the work in it

Assign artifacts to deliverables in it.

ISpace supports the assignment process, and the roles and artifacts assigned in the workflow are automatically organized The role directory and the artifact directory, the three views (workflow, role, artifact) can be managed independently or linked to tracking.

On top of that, these MBSEs are interrelated through Models, which can quickly switch between multiple views, and locate elements from one view to another, which is much easier to manage.