How to set a value, attribute or property of a block instance independent from a block

Question

I am trying to define different systems (software and hardware) made of common building blocks in SysML. In the following I try to describe my approach with a sample:

For this purpose I have defined a common set of blocks in one BDD and described the common relationships of all blocks using ports and connectors in one IBD - nothing special so far:

• block A, B, C
• each block using each two ports
• each block's port connected to other blocks ports

Now when using the blocks defined as given above, I want to add static characteristics of blocks and ports for each system I define based on the above building blocks. The system is defined in one additional BDD and IBD using the same blocks from above:

System(s) AX and AY have:

• additional connections between two blocks A and B, described in IBD (OK)
• additional characteristics of the ports (NOK)
• additional characteristics of the blocks (NOK)

Problem: The last two "NOK" points are a problem as follows:

• Whenever I add additional properties/attributes/tags to a block in one system/IBD it also applies to the other systems/blocks
• Whenever I add additional properties/attributes/tags to a port in one system it also applies to the other systems/blocks

My question can be generalized: How would I define characteristics of instances of blocks in a way that they do not affect the original blocks they are instantiated from. The issue came up in multiple attempts to design systems, maybe SysML is not intended to be used in such a way at all?

I also tried to design my system in UML using component diagrams and components / component instances and the same problem appears there: instance specific attributes/values/ports do not seem to be supported.

Side Note: I am using MagicDraw as a tool for SysML und UML.

Answer 1

I understand you want to define context specific connectors and properties.

First I want to clarify that all of these are already context specific. The context of properties is their owning block or InterfaceBlock (type of the port). The context of connectors is their owning block (IntefaceBlocks cannot have parts, therefore also no connectors).

So, a connector needs a context. Let's call it system A0. It has parts of type A, B and C and owns the connectors between the ports of its parts.

Now you can define systems AX and AY as special kinds of system A0. As such it has the same parts, but you can add more parts and connectors.

If you define additional properties of the parts of your special systems, you are in fact creating new special types of A, B and C and the port types. SysML 1 forces you to define these new types. And I think rightly so. If block A' shall have more features than block A, then it is a new type. It is irrelevant that A' is only used in the context of system AX. If you later decide to use it in system AZ, it would still have the same features.

Not all of these changes mean that it is a new type. For example if you only want to change the voltage of an adjustable power supply, this is not a new type of power supply. In the context of system AX it might be set to 12 V and in system AY it might be set to 24 V. In order to allow this, SysML 1 has context specific initial values. Cameo has great support for these. This helps around the somewhat clumsy definition in SysML 1. This will be much better in SysML 2.

If the value is not adjustable, a 12 V power supply would technically be a new type of power supply. However, I can see that it might be useful to only define this as context specific value, even though it is strictly speaking not context specific. I don't want to be more papal than the pope.

Now a lot of systems engineers don't like to define their blocks. I really don't understand why. But in order to accomodate this modeling habit, SysML 1 has property specific types. In the background these types are still regular blocks, only on the surface it appears as if they are only defined in the context. Up to now, no one could explain to me, what the advantage of this would be. However, SysML 2 has made it the core of the language. Here you can define properties of properties, even without first defining blocks.

Sometimes you have sub assemblies with some flexibility regarding cardinalities and types. If you use such a sub assembly in a certain context, it is often necessary to define context specific limitations. For example you could say the generic landing gear can have 4..8 Wheels, which could be High load wheels or Medium load wheels, but when used in a Boing 747, it will have 6 high load wheels. For this SysML 1 has bound references. Is that your use case?