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

SysML: small customizations to lower level components, while maximizing reuse of higher level assembly common structures

What's the best way to make small customizations (e.g. IP addresses) to lower level components of a common subassembly (block) in SysML?  Key consideration is maximizing reuse of higher level assembly common structures (e.g. internal connectivity).

Case in-point:

Common Server Rack used in several places on-board a ship.  Each application has unique IP addresses, each assigned down to a lower level component (several layers below the Common Server Rack level of definition.

Here's a simplified outline of the scenario:

 - Server Rack <<block>>

-- Display Computer <<block>> (part of Server rack)

--- Display Computer IP Address (value property of Display Computer)

-- Server Computer <<block>> (part of Server rack)

--- Server Computer IP Address (value property of Server Computer)

-- Network Switch <<block>> (part of Server rack)

--- Network Switch IP Address (value property of Network Switch)

 The actual definition of the Server Rack is much more complex (many more value / part properties and internal / external connections), but I'm simplifying it for this discussion.

 There's one server rack on the port side, and one server rack on the starboard side.  However, I don't want to make "copies" of the server rack in the model.  I'd rather use inheritance (via generalization); so that both the port/starboard racks inherit the common features of the server rack architecture, but also allow for customization of the IP addresses at the lower levels.

This has sweeping implications across the entire system model, as I have many common items that have slight customizations across 4 or 8 different applications within the shipset.

Any help on this is greatly appreciated!

  • Jim Ciarcia
    Per SysML 1.6 See section 8.3.1.2.8 Initial Values Compartment

    This would allow you to assign IP addresses specifically to the parts of the Server rack without having to assign them, as default values, to the Blocks that type those parts.

    "In addition to the form of default value specifications that SysML supports on properties of a block (with an optional "=" <value-specification> string following the rest of a property definition), SysML supports an additional form of value specification for properties using initialValue compartments on an internal block diagram (see Internal Block Diagram on page 4). An entire tree of context-specific values can be specified on a containing block to carry values of nested properties as shown on an internal block diagram."

    docs.nomagic.com/.../Initial Values
    Note: I have found that you do not need to have a Default Value assigned to the Block property as specified in NoMagic URL.. it works even without that in 19.0 sp3 (however I didn't double check before writing this, going from memory). Showing this data on something other than an IBD is convoluted however, as you need to access the default value of the part and then the slot for the property you are looking for. But that should work in all fully conformant SysML 1.6 tools.

    See also:
    blog.ricksteiner.net/ (Has good example)

    www.youtube.com/watch (I did not watch video.. so may be wrong about relevance)

    www.sparxsystems.com/.../index.php
  • Geoffrey Shuebrook
    Mike,
    I believe I understand your need.

    Rather than get into the many details of possible approaches, I'll just suggest you look at this web page: modelbasedtest.wordpress.com/.../

    I can provide you with the model that this blog post was sourced from. Otherwise review the No Magic guidance on Context specific initial value properties and see if that will solve your problem.

    I suspect I would use instance specifications of each Server Rack instance, but that is just how I would do it. Many others would not use instance specifications. IMHO, the default value and initial value property specification approach we see in SysML models departs from the intent of the UML language. But that is just my opinion, and I admit I am in the minority.

    Instance Specifications have a role in the detailed design of a complex system, as well as documenting the 'as is' specification. Again, just my opinion.

    One of the considerations might be whether every vessel instantiated from the detailed design model employs the over-ridden default value by the context specific initial value (context=server rack port]starboard). Do you feel that a platform independent model (i.e., logical model) serving as the description of the architecture of the system (vessel) would have IP address detail?

    Regards,
    Geoff
Related