Do you model separate blocks when creating interfaces in SysML?

[PDC]

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.

FlowProperties are owned by an InterfaceBlock.
FlowProperties are typed by a Classifier.
The Blocks in the design have Ports that are typed by the InterfaceBlock.

So one way (probably not the only way) to model our gasoline scenario could be: 'InterfaceBlock1' owns an incoming Flowproperty called 'gas-in' which is typed by a Classifer 'Gasoline'. And the Classifier 'Gasoline' may be a Generalization of another Classifier 'Liquid' (purely to support definition of other subtypes of liquid). Then there are multiple Blocks that have Ports, and the Ports are typed by 'InterfaceBlock1'. The Ports are connected (on an IBD) by InformationFlows, for which we use the 'Information Items Conveyed' context menu to add Information Items typed by the 'Gasoline' classifier.

All of that produces an IBD consistent with the Distiller one in your latest post (saves me working out how to upload screenshots )
It looks like the Distiller example uses Blocks ('H2O', 'Heat', 'Residue' & 'Fluid') to type the Ports, rather than InterfaceBlocks. This seems kind of a little naughty to me but there may be good reasons for doing so that I'm not aware of.

[Guillaume]

Very interesting thread as I wasn't aware of this approach to select instances e.g. with the 1st example to show that gasoline (instance of Liquid) is sent from one part to another.
I tried the Distiller example, and I couldn't select main1, main2.. in the information flow connector having only these parts as a result of the composition links. I'm getting a feeling that information flows between the blocks ports have been defined as an intermediary step. Is that correct to achieve the distiller ibd ?

The impact of such approach, based on my understanding and attempt to reproduce the examples, is that you have to define all possible information flows at the BDD level i.e. between the ports of the blocks. So once you get to the IBD, you simply need to select the info flow(s) to realize for a given connector from the list. I would have thought that connecting block's ports in the BDD is not compatible with the black box view since naming what flows on connectors should be specific to the ibd (white box -> connecting parts / instances of blocks). I may be wrong and I'm interested in any feedback on this. I can see the advantage to define all possible flows if it is consistent with the studied system.

From a user perspective, I find it a bit time consuming to define and I'm not surprised Takeshi came up with an addin.

Note: for the example of the gasoline versus water being exchanged between 2 subsystems (parts) that can pour and receive some liquid, my approach would involve creating 3 Value Types Liquid, Gas, and Water, with Gas, and Water linked with a Generalization to Liquid.

About the InterfaceBlock, I looked at SysML 1.5 specs and it only says that it cannot own any behaviour. Based on previous versions of SysML, my understanding was that an InterfaceBlock is used to type Proxy Ports. But since I only use Ports, I usually don't use InterfaceBlocks at all ; instead I put all Blocks that can type ports in a specific library branch of the model, and if possible I apply a stereotype (e.g. portType) with a custom colour if an MDG is used. These blocks can have flow properties and/or directed features operations.