NASA Logo, National Aeronautics and Space Administration

HyDE Models

The models used by HyDE are similar to simulation models. They describe the expected behavior of the system under nominal and fault conditions. The model can be constructed in modular and hierarchical fashion by building component:sub-system models (which may themselves contain component:sub-system models) and linking them through shared variables/parameters. The component model is expressed as operating modes of the component and conditions for transitions between these various modes. Faults are modeled as transitions whose conditions for transitions are unknown (and have to be inferred through the reasoning process). Finally, the behavior of the components is expressed as a set of variables/parameters and relations governing the interaction among them (for example, equations). The hybrid nature of the systems being modeled is captured by a combination of the above transitional model and behavioral model. Stochasticity is captured as probabilities associated with transitions (indicating the likelihood of that transition being taken) as well as noise on the sensed variables.

HyDE Faults

HyDE can deal with discrete faults, that is, those that correspond to an abrupt change in the configuration of the system. HyDE models represent discrete faults as transitions without guards (called unguarded transitions). The absence of guards signifies that the occurrence of these transitions cannot be directly observed, and hence must be determined by reasoning about symptom observations. Examples of such faults are valve stuck open, motor stalled and circuit breaker tripped. Unexpected behavior not explicitly modeled can be handled as an unguarded transition to a unique “unknown” location that has no model associated with it, assuring that it will be consistent with all observations. It is also possible to model parametric faults (abrupt changes in the values of system parameters) if the new values for the parameters are known. For example, we can model resistive faults as an n% change in resistance for several pre-specified values of n. It is not possible to model the general case in which n is not known and has to be inferred by reasoning.

The use of unguarded transitions allows HyDE to infer the occurrence of any unobserved event, not just faults. For example, a transition that is based on a supervisory controller command may be represented as an unguarded transition if the issuance of the command is not observed.

HyDE Reasoning Process

The HyDE reasoning process revolves around the maintenance of a set of candidates that are consistent with the observations seen so far. A candidate represents a single hypothesized trajectory of the system inferred from the transition and behavior models of the system, knowledge of the initial locations of all components and initial values of all variables, and the sensor observations reported to HyDE. The candidates’ weights are a way of ranking them and depend on several factors, including prior probabilities of transitions and the degree of fit between model predictions and observations.

Each candidate contains a possible trajectory of system behavior evolution represented in the form of a hybrid state history and transition history. The hybrid state is a snapshot of the entire system state at any single instant. It associates all components with their current locations and all variables with their current values.

HyDE’s reasoning process uses the same sequence of operations for each time step. The reasoning process can be divided into three categories of operations, as illustrated in the following picture.

  1. Candidate Set Management
  2. Candidate Testing
  3. Candidate Generation
HyDE Reasoning Architecture

Candidate Set Management

HyDE Reasoning Architecture

Candidate set management deals with the maintenance of the set of candidates and consists of four main operations:

  1. Updating weight of all candidates. The Candidate Testing operations are called to update the weight of each candidate in the candidate set.
  2. Prune candidates. After the candidate weights have been updated, candidates with weights below a user-specified threshold are pruned from the candidate set.
  3. Add candidates. Additional candidates may be needed to fill the candidate set to a user-specified minimum count. To re-fill the candidate set, a new potential candidate is requested from the bank of candidate generators created as a by-product of the candidate-testing operations. The candidate generators are responsible for selecting the next best candidate based a user-specified ranking function. The potential candidate then goes through Candidate Testing and may be pruned if its updated weight is not high enough. More potential candidates are requested until the candidate set has the requisite number of candidates.
  4. Re-sample weights. As an optional step, candidate weights may be normalized by re-sampling from the distribution of weights.

Candidate Testing

HyDE Reasoning Architecture

At each time step, each candidate is tested by simulating or propagating the behavior of the system under the conditions hypothesized by the candidate and comparing the predicted behavior with observations. This involves the following main operations:

  1. Find enabled transitions. Find all transitions (commanded and autonomous) that have been enabled for the time transition between the previous and current time step.
  2. Estimate beginning hybrid state. Apply the transitions identified in the previous step and update the discrete and continuous state accordingly.
  3. Load the propagation model. Based on the updated discrete and continuous state load the corresponding propagation model.
  4. Estimate end hybrid state. Execute the propagation model loaded in the previous step using input values for the current time step to update the discrete and continuous states at the end of the current time step.
  5. Update weight of candidate. Compare the estimated values with observations to determine a degree of fit which is then used to update the weight of the candidate.

Candidate Generation

HyDE Reasoning Architecture

Candidate generation supplies the next best candidate (determined by user defined criteria) when requested by candidate set management. In order to do this candidate generation uses a conflict-directed search. Conflicts are generated from information about the degree of fit computed in the candidate testing phase. The conflict-directed search tries to find the best candidate that resolves all conflicts.

First Gov logo
NASA Logo -