Although design states provide a powerful mechanism for multi-level test definition and large-scale diagnostic problem solving, this feature can be a severe hindrance when not utilized properly. There are a few good practices that, if followed, can help the Analyst to maximize the advantages of design states while minimizing the potential dangers.
Have a Specific Use in Mind - Design states are a means to an end and should only be included in a design when the Analyst has a specific task in mind. Don't add design states to a model merely in order to document the possible operational configurations of a system.
Set the Design State Usage - Each design state's Usage field should reflect the intended use of that state. This can greatly reduce the burden on both the Analyst and the software. (Note: design state Usage settings can be quickly modified for batches of design states in Grid View). Here are some sample situations in which you may wish to limit design state Usage:
To simplify the selection of states within local test definitions (set the Usage to "Local only")
To provide control of lower-level paths through the design within an upper-level test definition (use "Hierarchical only" in the lower levels and "Local and Hierarchical" in the upper level)
To determine an optimized set of state configurations for diagnostics (use "Local and Hierarchical")
To define hierarchical system state configurations for use by an external simulation tool (use "Hierarchical only")
Optimize Work-Flow - Some modeling operations can slow down significantly when a model contains a large number of design states. Therefore, to speed up the modeling process, you should wait to add design states until the model is nearly complete. Also, don't be afraid to remove design states temporarily when performing certain operations and then add them back into the design afterwards. Remember, however, that the internal ids will be different for the new design states, so any local test definitions that utilize design states will have to be updated/recreated, as well as design states and/or test definitions in upper-level designs that link to the current design. Nevertheless, it may take considerably less time to delete and recreate design states and test definitions, rather than repeatedly wait while the software "grinds away" updating 20,000 design state definitions to reflect each design change, Reducing the number of design states that are generated by this operation. Although one of the strengths of the Auto-Create operation is its ability to create a large number of design states in a single batch, the Analyst should always consider ways in which automatic generation of design states can be constrained without jeopardizing their intended use.
Remove Invalid, Unnecessary or Superfluous Design States - Perhaps the single most important "Good Practice" is to remove any design states that either represent invalid state configurations, or are not required within a model (this is especially important when hierarchical states are used within a large system design, since the number of states may grow exponentially within higher design levels). One extremely useful technique is to use diagnostics to determine an optimized set of design states. For design states that are only used within local test definitions (i.e., that are not inherited hierarchically), the Analyst may also wish to switch each test definition so that it utilizes object states (rather than design states) once the optimized set of state configurations has been determined (all design states can then be removed from that design level).
Ensure that Inherited Design States Provide Full Coverage - When design states are inherited hierarchically, the Analyst should make sure that the set of inherited design states encompasses all functions that are utilized by the upper-level design. Any output functions that are excluded from all design states in a lower-level design will not be included in the functionality of the upper-level assembly that is linked to that design. One way to ensure that all lower-level functions are included in at least one design state definition is to temporarily create a set of tests in the lower-level model for each design state at each possible test location. Next, create a diagnostic study and generate fault detection using these tests as candidates and make sure that the percentage of detected functions is 100%. If not, then include the non-detected functions in the design state definitions (either by modifying existing design states or adding new ones). Once you have ensured that all functions are included, you can remove the test definitions and set the Usage to "Hierarchical only".
Rename Design States to Reflect Operational Configurations - Once design state definitions have been reduced to the smallest set needed to support their intended use, each design state should be renamed (if necessary) to reflect the corresponding operational configuration. This will really help the Analyst when state selections are edited within test definitions. Even more importantly, when design states are inherited hierarchically, the upper-level output function and object state names will only be meaningful if lower-level design states were properly named. Hint: for design states generated using the Auto-Create operation, a list of enabled functions can be found in the description field.
