States are added to Objects to test the dependency flow through a model in the same manner as the real system. For example a valve can be on or off. States can be setup to test the path through it in both conditions. Another example is a splitter or multiplexer, States can be established on this modeled item to test each of the applicable paths through it. Object States (often referred to simply as "States") are groupings of output functions that are used to further define the behavior of an object. Whereas functions and failure modes can be thought of as inherent capabilities of an object, states can be thought of as the different modes in which the object can operate. States are also the mechanism that is used to model timing (by defining what functions are active at a particular point in time). The ultimate goal of states is to help constrain functional flow within test definitions—either directly, or indirectly via design states. The Analyst should always bear this in mind and be careful to not over-model states (i.e., define more states than are necessary to accurately develop test coverage).
Each object state has a list of Active Functions that defines what output functions are associated with that state. Each listed output function is assumed to be operating when the state is enabled. If an object has no states, all functions are assumed to be active. When an object has at least one defined state, however, output functions are assumed to be inactive unless a state is called out (e.g., in a test definition) to make them active. Although, within test definitions, states generally default to being enabled (in which case all related functions are considered to be operating), objects with mutually-exclusive states can have only one state enabled per test or design state definition.
Control Dependencies
Each object state also has a list of Control Dependencies. Since most states must be commanded to turn on or off, it is sometimes useful to describe the port(s) through which the command to switch states arrives. When a state has control dependencies, the eXpress diagnostic reasoner factors in these additional control paths when a test that uses that state fails. The logic behind this reasoning is that a test requiring certain states may also fail because the states failed to activate. Failures from this source should be traceable through the control dependencies. See Using Input Ports as State Control Dependencies
