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

  • Replies 13 replies
  • Subscribers 462 subscribers
  • Views 84753 views
  • Users 0 members are here
Related

Best Practices for Representing Cables in SysML

Richard Henrichsen

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
  • 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. )?
  • in reply to William Jago
    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.
Reply
  • in reply to William Jago
    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.
Children