Do you model separate blocks when creating interfaces in SysML?

[mse]

Suppose I have 10 signals like CAN messages for example, that are sent from one block to another. All are signals of the same type (CAN).

Do I model 1 block of type CAN and then create multiple item flows using that same type?

Or do I create 10 CAN blocks for example, each with a different name and then refer to them in the item flows?

In the book by Friedenthal, Practical SysML there was an example of using flows of electricity (DC). The notation used there I could not get in EA:

azm supply : DC
fm supply : DC
elm supply : DC

I suspect the DC is of course a block, but the names to the left I cannot figure out how to do in EA. The reason I am confused is because a block represents a type, so I have doubts about creating 10 CAN blocks when all are of the same type. In EA however, I can't seem to distinguish them. All 10 connections just show CAN.

[PDC]

Suppose I have 10 signals like CAN messages for example, that are sent from one block to another. All are signals of the same type (CAN).
Do I model 1 block of type CAN and then create multiple item flows using that same type?
Or do I create 10 CAN blocks for example, each with a different name and then refer to them in the item flows?

You *can* (no pun intended) do either, but personally I would do the first option. Define 'CAN signal' as a Block and use it as the Classifier to type the data items flowing around your system. That way you can add generic descriptions to the classifier and only have to do it once. And it's applied consistently throughout. YOu can also do this using just one itemflow and attach all 10 CAN data items to that one flow, although this assumes some semantics... e.g. that all of the 10 items generally flow across that link in the same scenario. If there are different scenarios then multiple data flows would help you illustrate the specific data flows in each case.
If you need to create a hierarchy then that could be useful (e.g. if all 10 signals are broadly the same, but then 5 of them have some special characteristic that the other 5 don't).

Hope some of that helps... though it's probably easier to illustrate my points graphically rather than English-ly.

In the book by Friedenthal, Practical SysML there was an example of using flows of electricity (DC). The notation used there I could not get in EA:
azm supply : DC
fm supply : DC
elm supply : DC
I suspect the DC is of course a block, but the names to the left I cannot figure out how to do in EA. The reason I am confused is because a block represents a type, so I have doubts about creating 10 CAN blocks when all are of the same type. In EA however, I can't seem to distinguish them. All 10 connections just show CAN.

Can't be 100% sure without seeing the notation (I don't have the book) but it looks like 'DC' is a single classifier (a Block) and then 'azm supply' et al are the names of instances of that classifier.

[mse]

Below is an illustration (source:https://www.webel.com.au/node/1553). They show in the IBD a connector depicting Water. In the explanatory notes they mention that you can either use a classifier "Water" or you can use specific item properties like "liquid : Water".

I agree, it is much better to have one classifier since blocks are types, not objects or instantiations. I just can't find anywhere in EA how to do that. In fact the documentation doesn't even show item properties. It always refers to Information flows and Information Items.

In the example I cited, yes, the classifier is DC and the item is "azm supply" but I cannot get the same effect in EA.

[philchudley]

Hi

In EA v16, you can create an Association between two Blocks and then use Information Flows Realized to specify what is flowing between the blocks:

BUT

You can only use classifiers such as Blocks and Value types, You cannot use any classified type and such as a Value Property like liquid : Water

I cannot find a way round this, unless I name a Value Type as liquid : Water (which I don't like).

Phil

[Takeshi K]

Hi all,

To apply an instance to the flow, specify it via the Tagged Value 'itemProperty' of an SysML::ItemFlow.
(The tagged value is defined in the SysML specification and EA implements it as defined in the specificaction correctly.)

Steps are like:
Create an ItemFlow and apply an instance to the Tagged Value, then add a Connector between Properties then realize the Connector - it is very complex so I have created an add-in to support these steps (users can specify both classifiers and instances in the same manner) and offer the addin to my customers.

HTH,

[mse]

Thank you Takeshi! And I also see that looking it up in the SysML, it is consistent. I had missed that tagged value completely. Here is the excerpt from the standard (bold emphasis mine):

One can label an ItemFlow with the classifiers of the items that may be conveyed. For example: a label Water would
imply that instances of Water might be transmitted over this ItemFlow. In addition, if the item flow identifies an item
property, then one can label the item flow with the item property. For example, a label of "liquid: Water" means Water
items might flow and these items are the values of the property "liquid," i.e., the values of the "liquid" item property are
the instances of Water flowing at any given time.

Now the notation shows up just fine.

[PDC]

Think I understand the question a bit better now.
I think the following steps give a semantically-similar result.
This includes all steps to build an ICD.

1. create the data definitions (e.g. define 'Liquid' and 'Water' as Blocks, with 'Water' as a Generlization of 'Liquid')
2. create an InterfaceBlock with a FlowProperty that represents the data items permitted to pass over that interface (e.g. a FlowProperty called 'Water' that is typed by the 'Liquid' Block, or another FlowProperty called 'gasoline' that is typed by the 'Liquid' Block)
3. add Ports to your Structural Blocks and classify them using the InterfaceBlock (helps give your ICD meaning)
4. draw the ItemFlow between the Ports and add an InformationItem typed by the 'Water' Block and 'itemProperty' tagged value set to be the flowProperty defined within your InterfaceBlock definition
5. draw a Connector between the Ports and link it to the ItemFlows relevant to a particular context*

What you should see on the ItemFlow/Connector is "Water: Liquid"

* on another diagram, you might have an ItemFlow carrying the 'Gasoline' data item, which would be rendered "Gasoline: Liquid". This lets you should the same connection with different flows for different scenarios/contexts

[mse]

Excellent summary, thanks. And that is how it worked out in my case as well.

I just have this one last theoretical question regarding the InterfaceBlock. If in my case I have different messages all of the same type, then I think the flow properties need to be on the owning block, and not in the InterfaceBlock. Suppose you had two messages of type CAN: speed, torque. Then I would have two ports typed by an InterfaceBlock called CAN. If I have the flow properties on the InterfaceBlock however, then anytime I type a port with a CAN InterfaceBlock, it will have both properties and I want to avoid that, which makes me think perhaps the block has to own the flow properties instead. The InterfaceBlock would have just the common information. It is like saying, "the block can accept CAN messages for torque and speed".

To see what I mean, in Figure D.23 of https://sysml.org/.res/docs/specs/OMGSysML-v1.6-19-11-01.pdf there is a Fuel block which types the flow properties. The flow properties are on the owning blocks however. The ports are typed by the block Fuel which is what flows over the connector. There are separate connections: one for fuel return and one for fuel supply.

[PDC]

Excellent summary, thanks. And that is how it worked out in my case as well.

No problem... although I have to admit that now I go back into my sandbox area it is rendered as "Water {Water}", not "Water: Water". I think this is purely a graphical thing though and the underlying semantics are equivalent. Water/water... Potato/Tomato...

I just have this one last theoretical question regarding the InterfaceBlock. If in my case I have different messages all of the same type, then I think the flow properties need to be on the owning block, and not in the InterfaceBlock. Suppose you had two messages of type CAN: speed, torque. Then I would have two ports typed by an InterfaceBlock called CAN. If I have the flow properties on the InterfaceBlock, then anytime I type a port with a CAN InterfaceBlock, it will have both properties and I want to avoid that, which makes me think perhaps the block has to own the flow properties. The InterfaceBlock would have just the common information.

Personally I wouldn't worry about this. For one thing, I don't think Blocks *can* own FlowProperties - they have to belong to the InterfaceBlocks.
At the same time, the InterfaceBlock defines what is permissible to flow across that interface, as a static representation of the interface agreement between 2 entities. You then use the rest of the model to describe what actually does pass over that connection in different circumstances. So you might know that it is an RJ45 connector, and there is an almost infinite number of different information items that 'could' be sent over that interface, but you use the IBDs to give context for a particular scenario, and use logical modelling to describe how the InterfaceBlock decides what is sent (e.g. an Activity Diagram that illustrates a choice, like "if a data packet of type packetA is received from the internal Block, then send out a packet of type 'packetB' on the external connection").
I guess it all depends on what your model is trying to communicate though

[Takeshi K]

Hello mse,

Just for your information,

To see what I mean, in Figure D.23 of https://sysml.org/.res/docs/specs/OMGSysML-v1.6-19-11-01.pdf there is a Fuel block which types the flow properties. The flow properties are on the owning blocks however. The ports are typed by the block Fuel which is what flows over the connector. There are separate connections: one for fuel return and one for fuel supply.

SysML 1.6 and earlier versions of the SysML specification examples have many inconsistencies with the specification, and one of the goals of SysML 1.7 is to correct these inconsistencies. Figure D.23 has also been updated so that we should see the figures in the SysML 1.7 specification.
(Normally we do not connect between ports in BDDs, so I think D.23 is incorrect and it has been fixed in the 1.7 document).

[Takeshi K]

No problem... although I have to admit that now I go back into my sandbox area it is rendered as "Water {Water}", not "Water: Water". I think this is purely a graphical thing though and the underlying semantics are equivalent. Water/water... Potato/Tomato...

I am afraid that "Water {Water}" and "Water: Water" are not equivalent. I cannot see the "Water {Water}" display because I cannot follow the step 4 of your steps (InformationItem is a classifier and it cannot be typed by another classifier).

When a label is 'water : Liquid', it is an instance (usually Ports or Properties in the SysML BDD/IBD) named as 'water' and it is typed by a classifier (usually Blocks, InterfaceBlocks or ValueTypes) as 'Liquid'. And usually instance names are not capitalized. In the case, maybe create a Property from a Block 'Liquid' and name it 'water', then specify the Property to the Tagged Value as a flowing item. Usually FlowProperties are used to specify input/output of interfaces and are not used as actual flowing items (i.e. FlowProperties are not used as conveyed items of ItemFlows).

I am afraid my understanding is not correct, so please tell me if my post is wrong.

HTH,

[PDC]

I am afraid my understanding is not correct, so please tell me if my post is wrong.

No I totally agree with everything you said there (I wrote a long response explaining that I agree, and then my network went down as I pressed 'Post' so it was lost. But you are correct!)

After posting my previous post I continued playing around and found that EA was behaving inconsistently. Actions like restarting EA or opening/closing different Element properties was affecting the display of the labels on the diagram. I do agree that it is strange that it lets me set the InterfaceBlock FlowProperty as the itemProperty on the ItemFlow... maybe that's where I had managed to confuse EA into showing something that it shouldn't.

[mse]

SysML 1.6 and earlier versions of the SysML specification examples have many inconsistencies with the specification, and one of the goals of SysML 1.7 is to correct these inconsistencies. Figure D.23 has also been updated so that we should see the figures in the SysML 1.7 specification.
(Normally we do not connect between ports in BDDs, so I think D.23 is incorrect and it has been fixed in the 1.7 document).

Thanks for that reference Takeshi. I went to those diagrams and they made the updates by removing the deprecated features. Unfortunately, the notation is lost in the updated diagram because they show only generic labels. We'll see what it looks like when it is published.

I went on to read more about ItemProperty in the same document and got an idea of what they are but now have doubts on whether I'm using them properly:

An optional property that relates the flowing item to the instances of the connectors enclosing block. This property is applicable only for item flows realized by connectors.

PDC, so if I understand your response correctly, that means then that blocks own properties representing the data items that are transmitted/received. So for example a block owns a property called Gasoline, typed by something like Liquid. It owns another property called Water also typed by Liquid. As we create the ports and connections, we relate the ItemProperties to the Properties of the owning blocks and that is what makes it clear to the reader where the information is going.

[mse]

By the way, I also just found this in the forum which is practically the same issue that we discussed here:

https://sparxsystems.com/forums/smf/index.php?topic=10332.0

I don't know why I did not find this before when searching Item Property information online.

[mse]

Looks like I found some diagrams that finally illustrate the concepts in Enterprise Architect. Here is the BDD for the Distiller:



And here is the IBD showing the Item Flows for the Distiller:



Notice the main1, main2, main3, and main4 item flows. All of the item flows are typed by H2O. These Item Properties are shown in the Distiller block on the BDD.