SYSML12 — Streamlined notation for representing system variance

System variants are often required to modify a system in order to satisfy evolving needs, and to support product lines with varying applications and environments. System variants have some components in common and some components that may be unique for each variant. SysML currently includes some capability to address variants, such as a property-specific type for specifying a variant usage of a component (i.e., block) in a local context, redefinition for redefining the type of the component, and generalization sets for specifying alternative components. However, what it lacks is a convenient mechanism and notation for describing variations that occur in deeply nested contexts within blocks.

Issue
System Variants
Classical product configuration management evaluates whether the change to an assembly affects the next higher assembly in terms of its form, fit, or function. If there is no change to its form, fit, or function, the modification does not propagate up the hierarchy (Note: This should be confirmed). In order to ensure there is no adverse impact to the next higher assembly, one must establish criteria to evaluate the impact of the change on the next higher assembly, and then evaluate the impact of the change against the criteria.

Figure 1 describes the baseline block hierarchy for a Vehicle; in the following paragraphs we will discuss how to address variants of this baseline system.

Figure 1 - Definition of the baseline configuration for a vehicle
In considering variance, one first checks to see if the change to a component affects the interface of the next higher level assembly. For example, in Figure 1, if the number of lugbolts is changed from 6 to 8, this could impact the interface to the braking disc. In addition, one must evaluate other potential impacts due to form, fit, and function. For example, if the weight of the bolt changes, the impact may propagate up the hierarchy to affect the overall vehicle weight. Or if the modified bolt has a lower stress rating, it may impact the safety of the vehicle. These impacts need to be understood to make a determination of whether the modification to the lugbolt impacts the next higher assemblies and the vehicle as a whole. If the change propagates up the system level, then each higher level of the assembly that is impacted must be subclassed (e.g., this may correspond to a new model number) to represent the variant assembly.
Representing Variants using Block Definition Diagrams

When a system variant results from changes in its components, the variant system model must include representations of the variations at each level of the system hierarchy from the system level down to the component level where the changes occur. The example in Figures 2 illustrates the SysML solution when a modification to a lugbolt results in a variant to the automobile at each level of the system hierarchy. In Figure 2, a change to the lug bolt (i.e. LugBolt A) propagates up the system hierarchy resulting in a variant to the wheel, to the chassis (or equivalent next assembly), and to the vehicle. The variant system hierarchy includes Vehicle A, Chassis A, Wheel A, and LugBolt A as subclasses of the baseline system elements.

Figure 2 ­ Varying all levels of the system hierarchy

The following reference provides further information on a general approach to capturing variants: “Extended Generic Product Structure: An Information Model for Representing Product Families by Sean Callahan.” This short paper can be found at http://129.187.108.94/dsm-conference/fileadmin/user_upload/downloads/2009/pdf/Callahan_GPS_published.pdf and a longer version at http://129.187.108.94/dsm-conference/fileadmin/user_upload/downloads/2009/pdf/Callahan_GPS_extended.pdf.

System Variants Using Property-Specific Types

In Figure 2, 4 new types were introduced. If there is no impact to the form, fit, or function of the higher elements in the assembly, then modeling these intermediate assemblies using new types can be very cumbersome. There is a need for a more streamlined approach to capturing variations in deeply nested parts that do not affect intermediate level assemblies.

At first glance, the property-specific type concept in SysML seems to fit the bill. As shown in Figure 3, using property-specific types, the replacement part is shown using dot notation on the IBD for Vehicle A, without the need for the user to explicitly represent Chassis A, etc. on the corresponding BDD.

Figure 3 - Use of property-specific types to capture variants

However, as can be seen, the redefinition clause in the part symbol does not give a clear indication of the location of the part being redefined, nor is there a notation on a BDD for showing this replacement part.

Note: Figures were not able to be included with this posting but are available on the SysML v1.2 RTF Wiki

This RTF declines to add specialized notation for variants.
Disposition: Closed, no change