Be Advised: Classified, FOUO, and PII Content is Not Permitted
What is the best practice for representing cables in SysML? From what I understand, they are typically represented merely as connectors. However, I would like to put block information on cables, such as part numbers. Also, I would like to be able to handle more complex cables, such as Y-cables. I see two ways to do this, but I'm unsure.
One way is to create a regular block to represent the part, and to connect to it. This works, but it doesn't represent very well that the connections are going through the cable, instead of to the cable.
The other way is to create an association block to type the connection. This is cleaner, but it doesn't allow split connections. This is also nice, because it allows the details of the connection to be hidden when they aren't relevant. It also seems to require typed ports, which can create some more work upfront.
An example of a connection I would like to model this way is a DVI splitter, which connects one port on a desktop to two monitors.
Edit: I think a better example of what I want to model is a wiring harness. It has little internal structure, but it connects several things using a variety of ports.
I'm not sure why you can't represent the DVI splitter using association class, one end just need to have a monitor property with multiplicity of 0..2 or whatever max your splitter is. Then in an IBD you type your connections with your DVI association class and subset your connections with the associated monitor connector property. You can do this with ports if you connect both ends of your splitter association class to the interface block. Lastly, you need to have a Context block that shows exactly how many monitors you have, and this becomes the IBD context. Using proper subsetting, redefinition, typed connectors and binding connectors between all your properties in context, you can have a complete model of 1 desktop with 2 monitors. I've attached the model I built to make sure I was not steering you wrong. You will get one warning Block[3] that you can ignore since SysML 1.6 no longer applies it. Validation also gives you an incompatible port direction warning when using a binding connector between properties with flow properties, you can either leave that binding connector out, not as complete a model, or ignore the error as it is a wrong warning. The warning would be right if you used a regular connector, not a binding connector, but that warning is just the tool trying to be helpful (and failing) and not actually a constraint violation per the UML or SysML specification.
The mdzip was uploaded as a zip file here:
https://community.apan.org/wg/navair-set/navair-mbse-community-of-practice/m/documents/285777
All connectors should be subsetted (and redefined as shown) of the correct association block property. Also should have named connectors of type DVI Splitter Ports. Otherwise diagrams are good example. As with all models, you dont have to show everything on the diagrams that I did, or make it as complete, but I wanted to be through.
See attached (rename from .txt to .mdzip). Validation rule checks that <<plug>> ports are connected to self (passing through system w/conjugated) or other interface blocks specifically called out as compatible with a <<compatible>> relationship.
Also, stylisticaly, I never directly connect deeply nested parts; I maintain modularity by putting ports at each level of the model. That may or may not be appropriate.
Also note how I've nested interface blocks based on context, etc. I'd be happy to discuss via WebEx...there's a lot going on in this example.
I like to use <<realize>> relationships between logical/physical and can base an entire set of validation checks on that.7752.CableExample.txt