When used properly, design states can greatly reduce the amount of time it takes to perform certain tasks. Here are three situations in which the use of design states can be particularly beneficial:
Reducing Work During Test Definition
- When batches of path-based tests need to be defined using the same configurations of enabled and disabled object states, design states can be used to simplify the test definition task. Not only can sets of object states be quickly enabled/disabled by selecting a single design state, but tests can be automatically generated for one or more design states. If this is done in a lower-level design, however, the Analyst should mark the design state Usage to "Local only" so that the design states are not inherited hierarchically—this will help avoid incomplete functionality at higher design levels (for a description of this issue, refer to the topic "Dangers of Using Design States").
Controlling Lower-Level State Configurations for Upper-Level Tests
- Because design states can be inherited hierarchically, they can be used to create top-level design states reflecting system-wide state configurations. This means that a top-level design state can be selected for a given path-based test and the coverage of that test within the diagnostics will be constrained by enabled and disabled states at various levels of the hierarchical design. Most importantly, it allows state selections to be controlled within multiple lower-level designs (this can be difficult to do using other test definition methods). Also, when a design state is selected within a top-level test, the top-level coverage for that test will also be constrained based on the paths allowed by the corresponding lower-level state settings.
Determining Optimized Set of State Configurations
- Analysts sometimes need to determine an optimized set of state configurations that can be used to diagnose a given design. This task can often take weeks to complete using conventional methods. In eXpress, the Analyst can use the Auto-Create operation to generate design states for all possible system state configurations and then automatically create path-based test definitions for each of these states (at one or more test locations). If these tests are then used as candidates for both fault detection and fault isolation within a diagnostic study, the resulting test sequence will utilize a relatively small set of those tests (based on the diagnostic goals implied by the selected diagnostic algorithms and test weightings). By reviewing the design states enabled within the tests that were selected by the diagnostics, the Analyst can easily determine the set of design states that are needed to fully diagnose the system.
Identifing Diagnostically-Useful, Non-Operational State Configurations
- When diagnostics are generated using path-based tests that have been created for each design state (and where the design states themselves have been automatically created), the Analyst may discover state configurations that are useful diagnostically—even though these settings do not represent valid operational configurations of the target system or device. In some situations, design states can prove to be a useful mechanism for recognizing testing options that may not been apparent when the design was approached in purely operational terms.
