4. Sensor Set Analysis

MADE sensor set analysis is driven by the interrogation of two sets of data: the propagation table, and the observed failure responses that each sensor in the set may detect. In the propagation table, each row represents an initiating failure event, i.e. failure of a functional flow, and each column represents a flow response to that failure at a set point in the system. Failures are considered covered when a specific failure can be detected and distinguished from the other potential failures in the system.

4.1 Coverage

The primary parameter that drives analysis in the PHM module is the coverage parameter. Coverage is a property of a sensor set that represents the percentage of failures in the system that the sensor set can uniquely isolate — e.g. when a failure has occurred, the user needs to consider whether the suite of sensors will be able to identify which item the failure was initiated in.

MADE determines a failure as "covered" when the combination of flow responses sensed for that failure are, as a set, unique in comparison to every other failure in the system. Simply put, MADE looks at the propagation table for the system, where each failure is represented by a row and each potential sensed flow response is a column. Sensors are allocated to sense a specific flow (they observe a specific column). Each failure (row) will then have a set of observed flow responses (columns with sensors). MADE compares each failure row's sensed flows to every other failure row's sensed flows — if the sensed responses for a row are, as a set, unique, then the failure row is covered.

4.2 Propagation Table

The propagation table is the major output from the model that is used in PHM analysis. Its major function is to present the expected responses that may be observed in the system when a failure has occurred.

The table is generated from the model using either FCM or Bond simulation. A failure is simulated by "injecting" a failure into the model, i.e. a functional flow property of an item is perturbed, and the responses across the system are captured ("Nominal", "Low", or "High" response of the other functional flow properties). Each failure is represented as a row in the propagation table, with responses of the system represented as columns.

The propagation table is the basis for the PHM module and is constructed using the system model. The results coming out of PHM are dependent on the accuracy of the model's failure simulation.

4.2.1 Example Propagation Table & Selection of High Coverage, Low Test Point Sensor Set

The example below demonstrates a simple propagation table:

• Failures that may occur in the system: Failures A, B, C, and D
• Potential Test Points (TP) in the system: Test points 1, 2, and 3
• Responses to failures at each test point (e.g. if Failure A occurs, a high response at Test Point #1 will result)

Propagation table (Failure × Test Point response):

Failure	TP1	TP2	TP3
A	High	Nominal	Nominal
B	High	Low	Nominal
C	Nominal	Low	High
D	Low	High	Low

(Note: the source PDF table's cell-to-column alignment was garbled during text extraction — the raw extracted text shows a jumbled sequence of "High/Nominal/Low" values across rows without clean column boundaries. The reconstruction above is inferred from the narrative in section 4.2.2 below, which explicitly describes: Failure D covered/distinguishable at TP1; Failures A and B ambiguous at TP1 (both "High"); Failure C not detectable at TP1 (matches nominal); at TP2, Failure D covered again, Failures B and C ambiguous (both "Low"), Failure A not detectable (nominal) — the table above is the simplest 4×3 arrangement consistent with all of these stated facts, but the exact response value for column TP3 in each row could not be independently confirmed from the extracted text and should be treated as a plausible reconstruction rather than a verified transcription.)

4.2.2 Sensor Set Selection

• If a sensor is placed on TP1:
  • Failure D would be covered
  • Failures A and B would be ambiguous (matching "High" observed responses)
  • Failure C could not be detected, as the observed response would match that of a healthy (nominally operating) system
• If a sensor is placed on TP2:
  • Failure D would again be covered
  • Failures B and C would be ambiguous (matching "Low" observed responses)
  • Failure A could not be detected (matches nominally operating system)
• If sensors are placed at TP1 and TP2:
  • All the failures would be covered, as each failure shows a unique set of responses at observed test points
  • For example: ambiguous Failures A and B for TP1 (both "High") are distinguished by the unique responses at TP2 ("Nominal" and "Low" for Failure A & B respectively)
• If sensors are placed at TP1, TP2, and TP3:
  • All failures would again be covered
  • However, more sensors would be required than the previous combination

A sensor set with TP1 and TP2 maximizes coverage (all failures are isolated) and minimizes the number of sensors (only need two out of three possible test points). As such, the sensor set of TP1 and TP2 would be selected as the most efficient configuration of sensors.

4.3 Inclusions

Inclusions are preferences in the automated analysis that let the user force sensor locations to be included, and therefore the associated failures are covered in the generated sensor sets. Inclusions are always made from the Inclusions tab.

4.3.1 Must Cover Failures

The user has the option of selecting any failures that occur in the system that must be covered in any potential sensor sets generated. The sensor sets generated in the forthcoming Sensor Set Analysis tab will therefore all be able to cover those failures selected.

4.3.2 Must Use Sensors

Sensor locations selected under the Must Use Sensors section will automatically be included in the generated sensor sets. The option to include CTP sensors and locations under the Legacy Sensor Set section of this tab has an analogous function — rather than selecting locations manually, the CTPs in the model are included.

4.4 Exclusions

Exclusions allow users to remove either initiating failure events or possible physical sensor locations (sensed flow properties) from the PHM analysis. The user may want to do this for a variety of reasons, e.g. when detection of the failure is not necessary, or it is not possible or feasible to sense a flow output from a specific item. The mechanism by which exclusions are made within the software allows the propagation table that the analysis is conducted upon to be reduced in size.

4.4.1 What Happens When a Failure is Excluded

Excluding a failure removes that failure from further consideration in any subsequent PHM analysis. The row representing that failure is removed from the propagation table. This has several impacts upon the analysis:

• The failure cannot be covered
• Other failures are not compared to the excluded failure (there cannot be any ambiguities with the excluded flow)
• The failure is not considered in coverage calculations
  • E.g. For a system with 10 failures, each failure represents 10% of the total potential coverage of the system. If 1 failure is excluded, the remaining 9 failures now each represent 11.11% of the total potential coverage of the system.

Exclusions can be made from three major areas in the PHM module:

• Analysis Management page
• Exclusions page
• Ambiguity Groups page

4.4.2 Analysis Tab

When setting the options for a sensor set, the user can select response states and propagation focus. These effectively perform an exclusion action and remove certain rows and columns from the propagation table.

4.4.2.1 Response States

Typically, the user has the option of selecting transient state, steady state, or both from the Response State drop-down menu. A transient response state is the system state immediately following a failure, with each flow property of each item exhibiting either a high, low, or no deviation from its nominal level. A steady response state is the system state reached following a failure once a constant flow response (i.e. not fluctuating) has been reached by the items within the system. Often both transient and steady state responses for a specific flow property will be the same. In these cases, both failure states will be represented on the same line in the propagation table for analysis.

If the user selects only one of the response states in the tab, only that response is used in the PHM analysis. For example, the user may decide to only analyze steady state flows, as the diagnostics system they seek to represent will only sense constant or persistent flow responses.

4.4.2.2 Propagation Focus

This feature filters failures and sensed flow properties based upon the flow property. The user may choose to disregard certain flow properties from the analysis. Failures that have a disregarded flow property will not be included in analysis. Item flow properties that are the same as the disregarded flow property will not be included in analysis.

4.4.3 Exclusions Tab

4.4.3.1 Detectable Cause and Sensor Location Exclusions

This allows the user to manually select failures and sensed flow properties that do not need to be considered. For example, a failure may be excluded when it is not likely to occur during the operational life of the system, or when the failure is not system critical. A sensed flow property may be excluded when it is not possible to sense the flow property, whether due to technological and cost considerations, or not being physically able to place a sensor on the item.

4.4.3.2 Failure Criticality

The user can select a criticality threshold. Only failures that exceed the threshold criticality will be included in the analysis propagation table.

4.4.4 Ambiguity Groups Tab

The user can exclude failures from the ambiguity tab. The purpose of this feature is to allow the user to resolve ambiguous flow responses. For example, if two failures have the same sensed responses, they will be flagged as ambiguous. In the case that the user knows that in practice they can distinguish between the two failures, they may choose to exclude one of the failures so that it is not included in the analysis.