MBSE Process

[pauldab]

Hi,

This topic is somewhat related to my previous one: https://sparxsystems.com/forums/smf/index.php/topic,46948.0.html  (Logical & Physical System Design in SysML and Sparx), but I would like to extened it and discuss additional modeling concepts for the system and whole MBSE.

As a initial starting point I have found and would like to spread the Minimum MBSE process introduced and proposed by Sparx JAPAN:

https://www.sparxsystems.jp/en/trace/minimumMBSE.htm
https://www.sparxsystems.jp/en/trace/MinimumMBSE.pdf

This is simple, yet contains the most important concepts (without specialty engineering e.g., SWaP-C, FMEA, Reliability, Availability - but surely could be extened with those).

My proposal to MinimumMBSE would be to introduce multiple system contexts:

I am considering multipile system contexts (i.e. operational context, maintenance context, production context).
So every system context can have at least one UseCase, but can have more.

And after applying proper SysML I get couple of part properties representing my system (in this case Power Control System):

So far I have thought that this is smth inherently bad, but...

... after I named those part properties It perhaps makes more sense. But still my block definition directly won't have any connections to other systems by itself.

1. So my first question is what do you think about that approach to system design in different contexts with couple part properties (different views?) and how to generate any specification out of that?

2. Let's, for the sake of discussion, that we are at physical level. After finding my two connections (mechanical and electrical) in production context I could then manually add two ports to represent those interfaces on system side:

and then use those on my production context part property.

Then simply also include those ports in my production context ibd and "rewire" the connectors form part poperty to specific ports:


This way system definition with those ports could be passed, with additional requirements (that could be traced to the port) to detailed design for specification (mechanical connector selection, wires diameter etc).

Are there any better alternatives? Ideas?

3. Can a part property exhibit state the same way as instance specification?

Because if we were to use in the system design instance specifications (representation of built system) we could define:

and this would allow to make the model more complete, so states could be used included in system specification:


So far I wasn't able to find a way in Sparx to add states to part properties (also a representation of my built system?).

Best regards,
Paweł

[Takeshi K]

Hi Paweł,

Thank you for introducing my document.

If I manage contexts, I will use package structures. The following is an example (skeleton).

• First, I create context diagrams to define each context e.g., who are related to the system and what are outer systems.
• Then, find Requirements in each context.
• And I also find Usecases in each context.
• I will not create context block like you. To describe structures for each context, I will create a BDD and a IBD for each context. In BDDs, Blocks are commonly used (i.e., copy some Blocks in a main BDD by Ctrl+C and paste them onto a context BDD by Ctrl+V). If I want to describe IBD for each context, I will create IBDs under the main Block (in above image, the Power Control System block)

To summarize, I will use diagrams to describe contexts but elements (in this example, Blocks and Actors) in diagrams are commonly used (except Properties in this case - Properties are instanced objects of Blocks).

[pauldab]

Hi Takeshi,

Thanks for the reply.

• First, I create context diagrams to define each context e.g., who are related to the system and what are outer systems.

So you create directly part properties on those diagrams for Power Control System and other systems?
Then you connect them with connectors and maybe show items flows?

• Then, find Requirements in each context.
• And I also find Usecases in each context.

Makes sense. In my approach I am trying to use context blocks and then trace all necessary requirements and use cases to this block.

• I will not create context block like you. To describe structures for each context, I will create a BDD and a IBD for each context. In BDDs, Blocks are commonly used (i.e., copy some Blocks in a main BDD by Ctrl+C and paste them onto a context BDD by Ctrl+V). If I want to describe IBD for each context, I will create IBDs under the main Block (in above image, the Power Control System block)

To summarize, I will use diagrams to describe contexts but elements (in this example, Blocks and Actors) in diagrams are commonly used (except Properties in this case - Properties are instanced objects of Blocks).

I assume that IBDs in Context Diagrams show connections of our Power Control System with external systems, and IBDs under Power Control System show internal connections.

Best,
Paweł

[Takeshi K]

So you create directly part properties on those diagrams for Power Control System and other systems?
Then you connect them with connectors and maybe show items flows?

When we create context diagram, there is no BDD, IBD or all other diagram. So we create elements directly. Actually, there is no definition of a context diagram in the SysML specification, but I usually use IBDs to describe contexts. You can see examples in the EAExample model and the SysML specification, the Annex D: Sample Problem.

I assume that IBDs in Context Diagrams show connections of our Power Control System with external systems, and IBDs under Power Control System show internal connections.

I use context diagrams to understand, clarify and share 'what we will create and what we will not (i.e. use existing other systems)'. So, I describe very rough information in the context diagrams. In detail, I need to describe in other diagrams at a later step.

For example, I use just a 'Command' in context diagram to describe communiation to other system by some Commands, but usually there are many kind of actual Commands. I will use other diagrams for detail (e.g. return ACK command (reply) when a system receive a START command), in a later step.