Be Advised: Classified, FOUO, and PII Content is Not Permitted

Best Practices for Representing Cables in SysML

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.

Parents
  • 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.

  • This is a clean example, but it has two instances of the DVI Splitter, where there is only one physical object. As I am trying to represent an even more complex connection, like a wiring harness, I don't think this is ideal.
  • I made an attempt at another example based on the method that Mike shared.  This one is a simple example of two devices connected with an Ethernet cable.  I think this method should work fine for more complex wiring harnesses by adding additional ports/interfaces to the "cable" block.

    https://community.apan.org/wg/navair-set/navair-mbse-community-of-practice/m/documents/286022 rename to .mdzip

  • Looks good. As I mentioned, sometimes I have blocks own their own interface blocks because there are often unique pinouts and such to resolve.
Reply Children
No Data