Time Metric Calculations

If you configure XFRACAS to track incidents and part repairs/replacements for specific serialized systems, you can capture time/usage data for use in reliability data analysis.

There will always be one primary time/usage metric (Time Metric 1) and you can choose to enable up to two additional fields (Time Metric 2 and Time Metric 3). By default, these fields are called "System Hours," "Number of Starts" and "kW Run Hours, but you can record any metric(s) of interest (hours, miles, kilometers, cycles, etc.) and use the Resource Editor to modify the interface labels.

Reported System Hours

The Customer Support (CSI) page for a serialized system displays the latest reported value(s) for the time/usage metric(s) enabled for the entity. This information can be obtained from any or all of the following sources:

  • Incidents reported for the serialized system
  • Manual entry via the Customer Support interface
  • Usage data imported from an external source

Click the link to see the history of all usage reports for that particular system. Click Add to manually enter new information.

Estimated System Hours

For the primary metric only (Metric 1), the Customer Support page also displays the estimated usage at today's date. If there are at least two reported values for the system's actual time/usage, the estimate is calculated as follows:

(Commission Date - Today's Date) x Average Usage per Day

To estimate the average usage per day, XFRACAS fits a slope to the reported time/usage values. However, if the estimate exceeds the maximum possible per day (which is specified in the "Incident - Max Units/Day - Time Metric 1" preference), the max per day will be used instead.

This estimate is used for CSI MTBF calculations (discussed below) and may also be incorporated into custom reports and charts if applicable.

Auto-Populate Time Metric 1

By default, users will be prompted to enter the time/usage metric(s) in each incident report for a serialized system. Alternatively, you can configure XFRACAS to automatically populate the primary metric (Metric 1) when the following preferences and inputs are available:

Preferences

  • Incident - Auto-populate Time Metric 1 is True
  • Incident - Max Units/Day - Time Metric 1 is a number greater than 0

Incident

  • Serial Number has been entered
  • Occurrence Date has been entered

Customer Support

The commission date has been entered and it is earlier than the incident's occurrence date.

  • If the System Down Event field (a special Detail field for incidents) is not enabled for the entity, the calculation is as follows:

    (Commission Date - Occurrence Date) x Max Units/Day
  • If the System Down Event field is enabled, downtime is obtained from any incidents for the serialized system where this check box is selected. For each incident, the time down is the Repair Date – Occurrence Date (or if a repair has not been entered, it is Today's Date – Occurrence Date). The calculation to auto-populate Metric 1 is:

    (Commission Date - Occurrence Date - Time Down) x Max Units/Day

Auto-Calculate Time Metric 1, 2 or 3

You can also configure XFRACAS to automatically calculate a time metric based on the value for another metric. For example, if Metric 1 is miles, you can configure Metric 2 as kilometers and calculate it automatically based on the value entered for miles (t1 * 1.60934). The behavior depends on the following preferences and what the user enters in the incident page.

  • Incident - Display Time Metric [2/3]
  • Incident - Always Auto-calculate Time Metric [1/2/3]
  • Incident Time Metric [1/2/3] Formula

It is important to be aware that your Preferences settings do not prevent you from saving incompatible settings or invalid formulas, which may result in unexpected behavior for the metric fields in incidents. Note that:

  • If the formula is blank, the field saves the entered value, regardless of whether "Auto-calculate" is True.
  • If the formula is not blank and "Always Auto-calculate" is True, the field attempts to calculate the value. If the formula is invalid, the calculated value will be 0.
  • If the formula is not blank and "Always Auto-calculate" is False, the field EITHER saves the entered value OR attempts to calculate if a value was not entered. For example, this configuration may be appropriate if some incidents have usage reported in Metric 1 and other incidents have usage reported in Metric 2.

Also note that:

  • Operands and operators must be separated by spaces.
  • Valid operators are * / + and –.
  • A valid operand can be a number, a time metric field (t1, t2 or t3) or a list of parameters (e.g., [t1,t2]) that will be checked in order until a parameter is found that is not 0.
  • A metric's formula should NOT refer to...
    • Itself — e.g., the formula for Metric 1 should not be t1 * 20.
    • A metric that is not enabled.
    • A metric that is already set to auto-calculate — e.g., if the formula for Metric 2 is t1 * 30 (e.g., 30 miles for every hour), do not set the formula for Metric 3 as t2 * 1.60934 (e.g., 1.60934 km for every mile); instead, set it to t1 * 48.202 (e.g., 48.202 km for every hour).

MTBF, MTBCF, MTBNCF and MTBI

The CSI page provides the option to display some very basic reliability metrics based only on the data from a single serialized system. If the preferences are enabled, the MTBF metrics are calculated as follows:

Number of Incidents ÷ Total Time/Usage

Although we recommend using Weibull++ for more robust reliability analysis whenever possible, the CSI MTBF metrics may be used, for example, to monitor a specific machine in a manufacturing line to determine whether it is meeting the contracted MTBF.

The CSI page displays two values for each metric (e.g., MTBF / MTBFE). The first is based on the reported usage for Metric 1; the second is based on the estimated usage.

Since an incident may be a "chargeable failure" or a "non-chargeable failure" depending on the Incident Category, there's a choice of four metrics that can be displayed:

  • CSI - Display MTBF (mean time between failures) and CSI - Display MTBCF (mean time between chargeable failure incidents) are the same metric
  • CSI - Display MTBNCF is the mean time between non-chargeable failure incidents
  • CSI - Display MTBI is the mean time between incidents (both chargeable and non-chargeable)

Extract Data for Reliability Analysis

For more robust reliability analysis, you can use the Reliability Data Warehouse (RDW) in the ReliaSoft Weibull++ desktop application to extract data from XFRACAS that can be used for either life data or reliability growth analysis.

For information about using the desktop applications to extract the data and transfer to an analysis folio, see Extracting Data from XFRACAS in the desktop application's help files. The extraction process for life data analysis works as follows:

1 – Select Part

The user selects one or multiple parts to be analyzed together in the same data set.

2 – Get Data from Serialized Incidents

The RDW identifies all serialized systems that contain the specified part(s). For each serialized system, the RDW then finds all "serialized incidents" and orders them by occurrence date to build a timeline.

  • The RDW finds all incidents within the timeline in which the specified part(s) were repaired or replaced.
  • The RDW checks the "Failure Type" for the repair and the "Incident Category" for the incident:
    • If both are chargeable (e.g., repair is "Primary Failure" and incident is "Component Failure"), then the incident is treated as a Failure (F).
    • If one or both are non-chargeable (e.g., repair is "Primary Failure" but the incident is "ASP Error"), then the incident is treated as a Suspension (S).

3 – Get Data from Part Incidents

The RDW finds all "part incidents" in which the specified part(s) were repaired or replaced.

The RDW checks the "Failure Type" for the repair and the "Incident Category" for the incident (as described above) to determine if the incident will be treated as a Failure (F) or Suspension (S).