Thanks for this example!!! 👍We've been doing something similar for a couple of years, but have found the type of technique demonstrated here has an undesirable characteristic with respect to "End A" and "End B". Sometimes "End A" is "Subsystem A" and sometimes it is "Subsystem B". This is the result of how the connector created; End A is the starting point when drawing the connector, and End B is the ending point. This can make the ICD harder to read/understand. For readability purposes, it is often desirable to create the ICD from the perspective of one subsystem or the other, such that End A is always the same subsystem. This can be accomplished by creating derived properties which define "ConnectorEndSelf" and "ConnectorEndOpp" (for Opposite). The ICD table can then be created with "Scope" on one part or the other. The derived property expression is a bit more complicated, but we've found that it is worth the trouble. It would be interesting to see your way of accomplishing this.
Nice, good method. I like the idea of starting from one part and then working your way outward. I absolutely understand the issues with the direction of the connector.
Honestly really love the insights here, but I do struggle to adapt these techniques to actual systems. How can these tools allow us to scale this up? I mean, cable connectors are bad enough but a 2-dozen slot backplane with a couple dozen ports to/from each module? And those aren't all straightforward things like power and ground -- there are multiple data lanes with bidirectional, differential signals like a "simple" Ethernet connection which is physically four traces but it's electrically TX+, TX-, RX+, and RX- so the directionality and polarity matter. Even then, at the logical level two identical ports could be doing either 10Mbps or 100Gbps -- or trying to -- so keeping track of the signal integrity characteristics is critical there too. Oh wait, do those interfaces support link-speed negotiation so they can find a common speed, or are you just out of luck if you connect the wrong ones? It just gets out of control very, very quickly when all that information has to get into a single interface model! 😵💫
I actually completely agree with you. We are working more robust examples to explain other methods to design logical and physical breakdowns and explain the pro/cons of each method. That video will be released in a month or two.
@@CameoMagic That sounds great. You have some of the best, most focused, and most approachable content I've seen, so please don't take this as any sort of critique about your examples. Just trying to wrap my head around what to do with that knowledge! 😃 Thanks again for this one.
A metachain can be made for this. In hindsight, we should've added that to this example. Pro: Scalable for mechanical, electrical, etc. aspects. Fairly easy to implement. Con: Metachain more involved. Another alternative is that you have a completely different breakdown that is purely physical and not logical and then map elements from one breakdown to another with a relationship like a(n) abstraction or dependency relationship. Pro: No complex metachain, arguably more straightforward. Con: Must make entire new decomposition (longer to implement). Another alternative is that you have a relationship between the physical block and the logical element (via mount relationship potentially). Pro: Fairly easy to implement. Con: Metachain involved (not terribly difficult), not quite as scalable (arguable) I'm sure there's other alternatives as well. I think either way you model it, you will have the trade space between doing a lot more modeling with less metachains necessary or doing less modeling with a more complex metachain required.
Thanks for this example!!! 👍We've been doing something similar for a couple of years, but have found the type of technique demonstrated here has an undesirable characteristic with respect to "End A" and "End B". Sometimes "End A" is "Subsystem A" and sometimes it is "Subsystem B". This is the result of how the connector created; End A is the starting point when drawing the connector, and End B is the ending point. This can make the ICD harder to read/understand. For readability purposes, it is often desirable to create the ICD from the perspective of one subsystem or the other, such that End A is always the same subsystem. This can be accomplished by creating derived properties which define "ConnectorEndSelf" and "ConnectorEndOpp" (for Opposite). The ICD table can then be created with "Scope" on one part or the other. The derived property expression is a bit more complicated, but we've found that it is worth the trouble. It would be interesting to see your way of accomplishing this.
Nice, good method. I like the idea of starting from one part and then working your way outward. I absolutely understand the issues with the direction of the connector.
I love this. Can you do an approach for software interfaces?
please do
Honestly really love the insights here, but I do struggle to adapt these techniques to actual systems. How can these tools allow us to scale this up? I mean, cable connectors are bad enough but a 2-dozen slot backplane with a couple dozen ports to/from each module? And those aren't all straightforward things like power and ground -- there are multiple data lanes with bidirectional, differential signals like a "simple" Ethernet connection which is physically four traces but it's electrically TX+, TX-, RX+, and RX- so the directionality and polarity matter. Even then, at the logical level two identical ports could be doing either 10Mbps or 100Gbps -- or trying to -- so keeping track of the signal integrity characteristics is critical there too. Oh wait, do those interfaces support link-speed negotiation so they can find a common speed, or are you just out of luck if you connect the wrong ones?
It just gets out of control very, very quickly when all that information has to get into a single interface model! 😵💫
I actually completely agree with you. We are working more robust examples to explain other methods to design logical and physical breakdowns and explain the pro/cons of each method. That video will be released in a month or two.
@@CameoMagic That sounds great. You have some of the best, most focused, and most approachable content I've seen, so please don't take this as any sort of critique about your examples. Just trying to wrap my head around what to do with that knowledge! 😃 Thanks again for this one.
How is anyone expected to figure out this is what's needed for the metchain stuff? There must be a more intuitive way.
A metachain can be made for this. In hindsight, we should've added that to this example.
Pro: Scalable for mechanical, electrical, etc. aspects. Fairly easy to implement.
Con: Metachain more involved.
Another alternative is that you have a completely different breakdown that is purely physical and not logical and then map elements from one breakdown to another with a relationship like a(n) abstraction or dependency relationship.
Pro: No complex metachain, arguably more straightforward.
Con: Must make entire new decomposition (longer to implement).
Another alternative is that you have a relationship between the physical block and the logical element (via mount relationship potentially).
Pro: Fairly easy to implement.
Con: Metachain involved (not terribly difficult), not quite as scalable (arguable)
I'm sure there's other alternatives as well. I think either way you model it, you will have the trade space between doing a lot more modeling with less metachains necessary or doing less modeling with a more complex metachain required.
@CameoMagic would love a video going over some of this.