Best Practices for Representing Cables in SysML

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.

So here's an example where I'm going to differ with James a bit...

Since the cable has a part number, I would use a block (usually I create a <<cable>> stereotype for the cables and a <<connector>> stereotype for the top-level ports that it owns). This allows you to make very specific pinouts (each cable owns the interface blocks that type its connectors...for example, 50 pin one one end, 2x25 pin on the other). I use "atomic" interface blocks to type the pins (for example, 28V+ that owns a flow property typed by 28V+). I also usually make unidirectional flows "out" and conjugate them to flip them.

You should then connect "through" the cable because you have ports on both sides of the part (and connected inside it).

I don't like association blocks very much and never use them; I also don't use binding connectors anywhere other than parametric diagrams (since I believe they're designed to say the two ends are equal).

Here's a video on pinouts; I've evolved my technique a bit since then: https://youtu.be/7RAg8_QBlt4

If there's interest I can create an example (it's a bit late to tackle that tonight).

I am definitely interested in seeing a more detailed example.

The example in your video shows the logical connections between things like [pin 1] of [connector 1] of [Block 1] to [pin 1] of [connector 1] of [Block 2]. I'd like to figure out the best way of then allocating this to a physical solution (modeling the wiring harnesses, connectors, feed through panels) that a specific design might use to satisfy those logical connections.

I assume there would be ways of doing this so that consistency of all the cable assemblies can be checked against the simpler logical connection model.

Also, is there a good reference for better understanding the metachain table from the video? That's unfamiliar territory for me.

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

Re metachains: I'm working on more videos to support training on metachains. That's where the real magic happens.

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.

This discussion raises several other questions in my mind:
1. Ports: full ports (typed by blocks) vs proxy ports (typed by interface blocks) and when/why?
2. Best practices for modularity and reuse?
3. Streamlining the modeling process: Can you set up interfaces such that defing a connection between an RJ45 plug and an RJ45 jack in an IBD automatically implies connections on their nested ports- pin1<->pin1, pin2<->pin2, etc on each for example?
4. Validation:
4a. How to check for things like mate compatibility between physical connectors, correct wire gauge to pins, differential signals to twisted pairs, current to correct wire gauge, etc.?
4b. How to query for end-to-end tracing of a signal through a set of complex cables? Or use a satisfy/realize/allocate type of relationship to check for it?
4c. How to incoporate other value parameters (such as optical or RF link budgets and losses, rollups of wire length tallies, etc. )?

William:

I am all about telling the story of a system as cleanly and elegantly as possible (fewest possible element types, relationships, customization, etc.)

1. I never use full ports; don't see the value.
2. Modularity is a tough question...still working on that. I do force all connectors to pass through ports on every boundary (no direct connections between deeply nested parts). This enables modularity. I use item flows to sew sets of connectors together.
3. There is an autowire function that aids in autoconnection.
4a. Some things are automatic (checking flow properties, for example, so pin types match). You can write validation rules to test what you're discussion...I'd put those in the library for reuse. It's a question of how much detail is appropriate in the architecture model and what should be left to CAD, eCAD, etc.
4b. Use an item flow to set all connectors together (see my hypermodeling video on that). I'd be happy to work a demo for you.
4c. It depends on what should own that info...see my power scenario work for some ways to do that. We could put a tag on a <<wire>> stereotype and add those up for all connectors in an item flow, for example.