Logical & Physical System Design in SysML and Sparx

[pauldab]

Hi,

I am trying to model logical architecture and physical architecture in Sparx.

1. This is what I came up with so far:



So physical elements can inherit logical elements operations.
The main issue with this is that in Sparx I cannot trace between relationships.

2. The other solution:


This is perhaps more preferable, because one could use full port and type it with a concerete connector. This physical port with a connector could be traced to multiple logical ports. Still one could trace physical elements like Cable to logical association - when you try to trace block it gives a ProxyConnector depedency.

Still in this case I am not sure that it's very compliant with SysML - connecting ports on bdd with connectors.
Also if one connects physical E1 with Cable with association, then you cannot type a connector on ibd between ports on those element propreties...

3. Wondering if:
a) it's better to use operations or maybe allocate activities to block elements.
b) to use generalization from physical components or realisation or any other relation.
c) how to relate connectors to object flow (the same issue with relationship tracing)

I would be grateful for any insights or suggestions.

Here you can download the qea file:
https://drive.google.com/file/d/1f_jok4iCn1n30aHJm9eheouwcq2mYDnJ/view?usp=sharing

Best regards,
Paweł

[Takeshi K]

Hello pauldab,

In my opinion,

- Usually we do not describe connections (interactions) between sub blocks in the BDD. They should be described in IBD (of parent Block). In your example, 'Logical Interface E1-E2' should be described in the IBD of Domain block.

- I think tracing connectors is one of 'traps' in creating models. Everyone who wants to build/maintain 'complete' traceability, he/she wants to trace them. But costs of maintain them is not small, but in my opinion, to keep consistency and find impact when changing it is enough to create traceability among elements only.

- 3a: In your logical model, an Activity (and an Activity diagram) should be owned by the Domain block and sub blocks (e.g. Equipment 1 logical) should be shown as an Activity Partition in the Activity diagram. Each sub block has not Activity but Actions. It is okay that you define operations and drop them as CallOperationActions in the Activity diagram.  But I do not do so because the information will be duplicated (operation and its CallOperationActions). For me, I do not define any operations but define as Actions because I just want to know 'What to do' for each Blocks, not want to create a perfect model.

-3b: Generalization should be used for the items in the same 'world'. In this case, usually we use Allocations. This means that each Logical Block is allocated to one or more Physical Blocks.

-3c: If I understand correctly, there is no way to synchronize (or check consistency) between Flows in Activity diagrams and Connectors in IBDs by using EA.

HTH,

[pauldab]

Hi Takeshi,

Thanks for the reply and your opinions.

- Usually we do not describe connections (interactions) between sub blocks in the BDD. They should be described in IBD (of parent Block). In your example, 'Logical Interface E1-E2' should be described in the IBD of Domain block.

Thanks. I believe that it is possible in general - so we can create associations between blocks on BDD, and then type the connectors on IBD with those associations (i.e. multiplicity). So far I was not able to find a good reason to this, so in general thanks for the suggestions - it may make my work easier.

This also leads me to another example:


So creating two context blocks IBD (but context I mean that our system communicates with different external equpiments in the same time, so it will have two connector, but let's say that I want to analyze those contexts seprately). So this has created two properties and I belive that this is wrong.

I general I create properties like that:


And then use those properties as my final system components and add specific connectors on System context 1 and 2 IBDs.

Please let me know what you think.

Also for the document generation purposes should I move the IBDs outside of System Context 1 and 2?

- I think tracing connectors is one of 'traps' in creating models. Everyone who wants to build/maintain 'complete' traceability, he/she wants to trace them. But costs of maintain them is not small, but in my opinion, to keep consistency and find impact when changing it is enough to create traceability among elements only.

Thanks I'll consider that.

- 3a: In your logical model, an Activity (and an Activity diagram) should be owned by the Domain block and sub blocks (e.g. Equipment 1 logical) should be shown as an Activity Partition in the Activity diagram. Each sub block has not Activity but Actions. It is okay that you define operations and drop them as CallOperationActions in the Activity diagram.  But I do not do so because the information will be duplicated (operation and its CallOperationActions). For me, I do not define any operations but define as Actions because I just want to know 'What to do' for each Blocks, not want to create a perfect model.

So in my above example my systems contexts can own the Acitivities and the specific activities will contain CallBehaviorActions.
So In general I could put those activities anywhere I like, but I suppose that it helps to organize the model?

-3b: Generalization should be used for the items in the same 'world'. In this case, usually we use Allocations. This means that each Logical Block is allocated to one or more Physical Blocks.

Thanks, makes sense.

-3c: If I understand correctly, there is no way to synchronize (or check consistency) between Flows in Activity diagrams and Connectors in IBDs by using EA.

I was wondering if it could be achievied by using scirpts and underlying model schema.

Best regards,
Paweł

[Guillaume]

Hi,

Regarding the parts you're getting under each system context block, this is normal behaviour. When you create a composition between 2 blocks, a matching part is created under the parent block with the role name + multiplicity. For instance if you create 2 composition links from System context 1 to Equipment 1 logical and give them different role names, you'll get the matching parts, named after the given role.
Note it is important to leave these parts under the main block and create your IBDs under this main block.
In the screenshot you gave, System context 1 and System context 2 each have composition links to equipment 1 and equipment 2, and each system context block has the matching parts to build the IBD for its respective equipments. Note that parts can then be connected on the ibd, directly or via a sub element (part or port).
Similarly if you delete a composition link, EA prompts to delete the binded part to keep the model consistent.
If you use simple aggregation links, you'll get references (parts with a dashed border).

Sparx EA Example project has System Modelling examples with SysML blocks. The OMG Sysml specs is also a good reference to check the bdd and ibd content definitions.

Guillaume

[Modesto Vega]

Paweł

So physical elements can inherit logical elements operations.
The main issue with this is that in Sparx I cannot trace between relationships.

If you are arguing that physical elements are instances of logical elements, I do like the sound of your first option. You are correct, there is no relationship to depict an instantiation, to my knowledge this is the case with all modelling languages I am familiar with (and, in my opinion, it is a weakness of modelling languages.

[Takeshi K]

Hello Paweł,

Thank you for your reply post.

First, my following comment is not accurate.

- Usually we do not describe connections (interactions) between sub blocks in the BDD. They should be described in IBD (of parent Block).

connections (interactions) -> flows

I think connecting between sub-blocks with an Association is okay, but we should describe data flows (shown as a black triangle) in IBDs.

Other questions except the last one, I agree Guillaume.

The last question about consistency between IBDs and Activities, yes, we can check by using the Automation Interface. If two Actions are connected by a Control Flow, and each Action is on a Partition typed by a Block, and an Association connects two Blocks in a BDD or two Properties of the Blocks are connected by a Connector in an IBD, is it okay? Basically yes, but I do not know if this condition is ALWAYS correct.

[pauldab]

Gentlemen,

Thank you very much for the replies and your insight. Please find my additional comments below:

Regarding the parts you're getting under each system context block, this is normal behaviour. When you create a composition between 2 blocks, a matching part is created under the parent block with the role name + multiplicity. For instance if you create 2 composition links from System context 1 to Equipment 1 logical and give them different role names, you'll get the matching parts, named after the given role.

I agree – this is normal behavior and I understand it.

Note it is important to leave these parts under the main block and create your IBDs under this main block.

In general I agree also with that. If I design a real piece of equipment that has internal parts like PCB boards, cables etc. this makes great sense.

In my example I was showing a system context which, as I believe, is an abstract concept. Context can contain specific actors, external systems (as in my example above) and system may offer different functionality for actors in this specific context (generally goals to achieve).

So I want to use a power of modeling tool and be able to analyse those contexts separetly. If I stay „compliant” with above I finish with many instances (parts) which are not related (in a model). There is no traceability between those. So far this is my understanding.

So creating one system/component part and use it in every context gives me the whole system and it’s interconnections.

After writing all above I am wondering that not all connections and interactions may be used at the same time, i.e. in maintenance there is a connection (through cable) to test equpiment. So I am wondering now how to relate my system instance in different states to different connections.

Again different parts for every context could allow for that…. (showing different connections).

But how to correlate everything then in my final system spec?

Paweł

So physical elements can inherit logical elements operations.
The main issue with this is that in Sparx I cannot trace between relationships.

If you are arguing that physical elements are instances of logical elements, I do like the sound of your first option. You are correct, there is no relationship to depict an instantiation, to my knowledge this is the case with all modelling languages I am familiar with (and, in my opinion, it is a weakness of modelling languages.

I had couple of discussions about that. It's very much a matter of taste - it can take hours to discuss such topics.
Right now after Takeshi posts I agree that one must consider "IS-A" relantionship. In my example that makes sense, but more generally as I have thought about it you may have functional blocks, like "Security functions", "Time Management", "Communication Module", etc. Then you cannot use "IS-A" relationship when you go to the physical level - it makes sens to allocate those functional components to physical component.

The last question about consistency between IBDs and Activities, yes, we can check by using the Automation Interface. If two Actions are connected by a Control Flow, and each Action is on a Partition typed by a Block, and an Association connects two Blocks in a BDD or two Properties of the Blocks are connected by a Connector in an IBD, is it okay? Basically yes, but I do not know if this condition is ALWAYS correct.

Thanks I will look into it. What do you mean if this is always correct? Shouldn’t it be correct to make the model complete? Perhaps we could check that it’s not the case and use this information to fix the model/system spec?

[Takeshi K]

Thanks I will look into it. What do you mean if this is always correct? Shouldn’t it be correct to make the model complete? Perhaps we could check that it’s not the case and use this information to fix the model/system spec?

Suppose we create a IBD which contains two Properties typed by Blocks and connected them by a Connector and create an Activity diagram which contains two Partitions typed by the Blocks. Each Partition has an Action, and they are connected by a Control Flow. I think this situation is okay, consistent.

Usually there are two or more Activity diagrams. I recommend creating Activity diagrams for each Use Cases. (i.e., Activity diagrams are used for describing Use Case scenarios and clarify which Actions each Block has. (Actions owned by a Block are its feature and/or responsibility.)

In this assumption, it is consistent that at least one of Activity diagram has a Control Flow between Actions on Partitions. If there is a Connector between Properties typed by Blocks but there is no Control Flow between Actions on Partitions typed by the Blocks in all Activity diagrams, it is inconsistent. I hope you agree this rule.


We sometimes do a trade-off analysis by using SysML models. In this analysis, there are two (or more) group of Activity diagrams, and we will choose best group to meet requirements. (Now I do not consider BDDs and IBDs. I know we might need to create groups of BDD and IBD for trade-off analyses.)
In this situation, if one of the groups has a Control Flow but another does not have, it is inconsistent for the latter group. But if we check for entire model, it is consistent because there IS an Activity diagram which has a Control Flow between Blocks. So, we need to define groups and check for each group. I want to say here that sometimes we cannot check entire model to confirm if it is consistent or not.


In another situation, suppose an artificial satellite. Usually there are two groups, one is common and basic features for satellites (the satellite bus. e.g., the Attitude Orbit Control System, AOCS) and another is mission-specific features (e.g., surface temperature monitoring). In model, we sometimes describe only mission-specific features because the satellite bus is already fixed and we can re-use. In this situation, if there is no Control Flow in Activity diagrams, it might be okay because it might be used in the bus. I want to say here that if there is no Control Flow or Connector and there is inconsistency, it might be okay for entire design.


Anyway, we need to consider various things. This is why I consider it is difficult to create the checker by using the Automation Interface. Synchronizing is more difficult; we cannot determine automatically to synchronize to which model or diagram.

Hope this helps,

[pauldab]

Hi Takeshi,

Thanks for the reply.

Suppose we create a IBD which contains two Properties typed by Blocks and connected them by a Connector and create an Activity diagram which contains two Partitions typed by the Blocks. Each Partition has an Action, and they are connected by a Control Flow. I think this situation is okay, consistent.

Usually there are two or more Activity diagrams. I recommend creating Activity diagrams for each Use Cases. (i.e., Activity diagrams are used for describing Use Case scenarios and clarify which Actions each Block has. (Actions owned by a Block are its feature and/or responsibility.)

In this assumption, it is consistent that at least one of Activity diagram has a Control Flow between Actions on Partitions. If there is a Connector between Properties typed by Blocks but there is no Control Flow between Actions on Partitions typed by the Blocks in all Activity diagrams, it is inconsistent. I hope you agree this rule.

a.   I agree, but up to this point I was considering Object Flows instead of Control Flows. In general systems, system elements can exchange items – material, energy and data (information) and I would assosciate them with Object Flows. Those item flows are sent through the connector. So above description makes absolute sense for me if we were using Object Flows instead.
b.   I am not sure how to get physical with Control Flows – in Activity diagrams we are talking about tokens, but they are purely abstract. In real systems I suppose that we „implement” Control Flow by using Object Flows and sending some sort of item i.e. command (i.e. implemented by a signal or block).
I would say that in initial analysis we could use Control Flows, but then still they would have to be replaced with Object Flows?
c.   What about connectors that simply mean mechanical connection? Maybe we should tag those connectors as mechanical and exclude them from the above rule?

We sometimes do a trade-off analysis by using SysML models. In this analysis, there are two (or more) group of Activity diagrams, and we will choose best group to meet requirements. (Now I do not consider BDDs and IBDs. I know we might need to create groups of BDD and IBD for trade-off analyses.)
In this situation, if one of the groups has a Control Flow but another does not have, it is inconsistent for the latter group. But if we check for entire model, it is consistent because there IS an Activity diagram which has a Control Flow between Blocks. So, we need to define groups and check for each group. I want to say here that sometimes we cannot check entire model to confirm if it is consistent or not.

Ok makes sense. This is a matter of querying the model and being able to detect such occurrences.
How do you make such groups in SysML?

In another situation, suppose an artificial satellite. Usually there are two groups, one is common and basic features for satellites (the satellite bus. e.g., the Attitude Orbit Control System, AOCS) and another is mission-specific features (e.g., surface temperature monitoring). In model, we sometimes describe only mission-specific features because the satellite bus is already fixed and we can re-use. In this situation, if there is no Control Flow in Activity diagrams, it might be okay because it might be used in the bus. I want to say here that if there is no Control Flow or Connector and there is inconsistency, it might be okay for entire design.

This basically means that we should check automatically interfaces for your suggested consistency rule. Still if we are re-using I believe that we should add interfaces (connector and related item flow and performance and timing) between our new model elements and re-used blocks.

Anyway, we need to consider various things. This is why I consider it is difficult to create the checker by using the Automation Interface. Synchronizing is more difficult; we cannot determine automatically to synchronize to which model or diagram.

I am starting to realize that. I suppose that this is a true know-how of MBSE – how to find a sweet spot between details, synchronization and verification of the model. It seems like a daunting task.

Hope this helps,
 

So far our discussion helped me a lot  - thanks. I hope that it also will help other readers as well.

[Takeshi K]

Hello Paweł,

About your question a, I agree with you. I supposed only Control Flows in this discussion, but Object Flows are the same for the checking rule.

About your question b and c, I think it depends on scope of the project. We need to define where (or which) SysML is applied to. For example, we need to discuss and describe in SysML about how to communicate between a satellite and earth stations, using the X-band or the S-band. But usually we do not discuss in detail about the bands since these technology specifications are already defined and fixed. Actual communication protocols are important in the Component level design, but I do not think they are imporant in the Systems, System and Sub-Systems levels designs. I want to say here that implementation is sometimes out of scope from SysML models.

About a trade-off analysis, copying package structures is very simple way to define the 'group'. After creating the 'Plan-A' model, press Ctrl+SHIFT+C for a top level Package in the Browser and press Ctrl+V on the target Package. But in this way we can not apply the compare feature because they have different internal IDs (GUID). If I do it now, I will use LemonTree, a great additional product for Enterprise Architect. After creating the 'Plan-A' model, copy the project file and modify the copy for the Plan-B. You can compare them graphically by using LemonTree.

HTH,

[pauldab]

Thanks,

Paweł