Download the data file. Extract the database files (Transmission_MES.mdb and Transmission_DMDR.mdb) in a folder, say in "\ExaktBasic" on your hard drive.

Launch “EXAKT for Modelling”. This is the program for validating and analyzing condition monitoring and event data and for building the optimized CBM (condition based maintenance) model.

Start, Exakt for Modelling

File, New, Navigate to the folder where you placed the Transmission_MES.mdb file, File name: Transmission_WMOD.mdb, Create

The analysis and model building phase is complete. We are now ready to export the optimal decision model we created into our maintenance system environmnent (where it has access to continuously renewing data), and, where it can do its job.

Activate the left pane, ModelDbase, Connect to Database Script, key in (or copy) the script for exporting the model

DATABASE="Transmission_DMDR.mdb";
ATTACH DecModels,
     UnitToModel,
     DecCovariatesOnEvent,
     DecEventsDescription,
     Decisions

Save

In the next slide we will send the model to a database located on the network. You will notice that several new table links appear in the tree view. Now that the links to the Transmission_DMDR.mdb database have been set up, we proceed to the actual export in the next slide.

In 2003, the Condition Based Maintenance Laboratory at the University of Toronto developed a data structure and methodology for the predictive analysis of complex systems - items containing multiple components and subject to a variety of failure modes.

The example of this tutorial is of a single reduction gearbox that contains two gears (referred to as Gear1 and Gear2) respectively. We concern ourselves, in this example with the failure mode “tooth fails due to root crack”, which can occur on either gear. We treat this unit, therefore, as a complex item having two failure modes. A CBM policy must consider all significant (reasonably likely) failure modes whose potential failures are detectable in the condition monitoring data set. The policy must distinguish data patterns characterizing one failure mode from those characterizing another. The policy must advise on which potential failure mode is imminent and it should also provide a residual life estimate.

The EXAKT software uses the term Marginal Analysis to indicate that a complex item is being analyzed. The database whose structure is shown in the slide contains the data for the equipment or fleet under analysis. It contains the original data or data that has been transferred or linked from the CMMS and one or more CBM databases.

Marginal analysis will allow us to build several CBM decision models, each corresponding to a specific component or to a specific failure mode. The slide illustrates the strucure of a database containing Event and Inspection tables as well as six other supporting tables. This structure will enable us to conduct analyses of complex items. From those analyses we develop models for multiple failure modes occurring in a single equipment item.

In the Tables tree view delete the three default tables:

1. CovaratesOnEvent,
2. EventsDescription, and
3. VarDescription

(These are default table structures not applicable to marginal analysis. They will be recreated in the step 5.)

Enter "GBX" as the base model.

OK

Repeat steps 9 to 13 making the obvious changes (as shown) required for the second model.

Extract Files_For_Exercise3.zip into a working folder, say test.

Start the “EXAKT for Modeling” application.

File, New, Navigate to the working folder (test/Extract Files_For_Exercise3) that contains the Mar2004CRC_MES.mdb

File name: Mar2004CRC_WMOD.mdb, Create

Activate the left sub-window by clicking anywhere in it, Modeling  (on menu bar), DataSetup, copy and paste the following script into the script editor:

Database="Mar2004CRC_MES.mdb";
Attach Inspections=OilInspections,
       Events,
       EventsDescription,
       CovariatesOnEvent,
       VarDescription

Execute, Save

Notice that the five tables in the script's "attach" statement are now visible in EXAKT's left window tree view. You may open and examine each of those tables (as you did in the Basic Tutorial).

Data Preparation,

Enter General Data,

Project Title: CRC Data Analysis,

CBM Model: PHM (no OC),

Description: Wheel Motors,

Time Unit: hr, OK

Activate left pane, Modeling (on menu bar), Extend Output Variables, Copy and paste the following into the script editor:

// OutputVarScript
PrevSed1=Sed-Diff(Sed);
CorrSed1=Sed*(Sed>0)+(Sed=0)*PrevSed1;
PrevSed2=CorrSed1-Diff(CorrSed1);
CorrSed=CorrSed1*(CorrSed1>0)+(CorrSed1=0)*PrevSed2;
LogSed=Log(1+CorrSed);
LogFe=Log(1+Fe);
CorrSi=Si*(Si<>900)+1.2*Fe*(Si=900);
SqrtFe=Sqrt(Fe)

With Covariates (Complete)

After a few moments notice the appearance of the C_Inspections table and the C_Events table.

C_Inspections table, scroll to the right

Notice the extended variable columns PrevSed1, CorrSed1, PrefSed2, CorrSed, LogSed, LogFe, CorrSi, SqrtFe

Close the C_Inspections table

Activate left pane, Edit, Check Database, Data

Examine the "Summary of Data Check" report

Notice that the number of Beginnings, 177 = 89 + 41 + 46 = the number of Ending events. This is the most basic data validation of the "life data" and is made first.

Close the report.

Now we will make some deeper checks into the "life" data

Open DataCheck table,

Click on “Description” column header

View (menu bar), Inspections, Include Events View, OK

Arrange windows and panes so that the Inspections and Events window covers the top two-thirds of the screen and the DataCheck window the bottom third. Drag the bottom boundary of the Inspectons window upwards to expose the Events panes.

The Inspections window should now have four panes.

Widen the Date column of the top right pane so that the entire Date is visible

The five panes (tables and and graphic views) are now in automatic synchronization. This makes it easy to find and correct errors, as we shall see in subsequent steps.

Look at the DataCheck window. You will notice that there are many requests in the table to “Check whether the "history is temporary suspended or 'EF/ES' is 'missing.” The software has no way to distinguish between missing ending events and “temporary” suspensions (units currently in operation).

The user must ascertain that all such indicated records correspond to units that are operating currently. If the lifetime corresponding to the message, is, in fact, going on at this moment, then the user should ignore this message. EXAKT will then consider that they are indeed temporary suspensions. Otherwise the message means that you are missing an ending event, either an EF or an ES. You must manually insert the missing record into the Events table.

DataCheck window, scroll to Record 47 and place cursor in Ident field of Record 47.

The 47th record of the DataCheck table has the description

“This record can't be properly identified. It has the same Ident, Date, WAge , and Event as the previous record:Id=5508L 2, Date=27.08/1997, WAge=68926, Event-IN in Inspections table”

Inspections window, widen the Date column so the full date is visible, scroll up 1 row on the scroll bar so that record 818 is visible

Note that the pointer is at record 2217 in the Inspections table and the Events table likewise has its pointer positioned at record 1036.

Note that record 2216 corresponds to an oil sample taken on the same equipment on the same day as record 2217. EXAKT is suspicious about this and is asking you to verify the dates and working ages for these two. Maintenance planning personnel tell us that record 2217  must be an error. Therefore we may delete it.

Delete record 2217 (by selecting it and hitting the Delete key).

DataCheck window, record 52,

Inspections window, scroll up up to the recored mentioned.

"Id=5503R, Date=31/07/94, WAge=65634, Event-IN in Inspections table"

Here is a similar type of problem. But in this case two samples have the same working age but different calendar dates. EXAKT is not pleased with this situation and is asking you to do something about it. You should check if the equipment was really idle for one month, or if this is a data entry error.

Thus, does one go systematically through the database records, as indicated by the DataCheck table, correcting the anomolies that are pointed out by EXAKT.

View, Cross Graph, maximize window, Table: Inspections, Horizontal:  WorkingAge , Vertical: SI, Condition: Si < 1000, Show

A pattern in the silicon readings strikes us as unusual. We question the unusual fact that multiple readings are exactly 900 ppm. Investigation found that the laboratory's spectrometer had an incorrect photomultiplier tube over a number of years and was saturating at 900 ppm. One should avoid using known incorrect data for model building. A correction needs to be applied if Si is to be analyzed in the model building process.

Horizontal: Fe, Vertical: Si, delete Condtion: “Si1000”, Show

We notice the correlation between iron and silicon. We can make use of this relationship.

Reduce and close the cross graph window

Modeling (on menu bar), Create Model Input tables, Complete data, View, Cross Graph, maximize, Table: C_Inspections , Horizontal:  Fe, Vertical: CorrSI , Show, reduce, X

Recalling the extended variable script from Slide 3, the line:

CorrSI =Si*(Si<>900)+1.2*Fe*(Si=900);

can be read as: The corrected values of Si shold be set to the original values of Si if the original Si is not 900 ppm. However, if the value of SI is (exactly) 900 ppm then multiply it by the slope of the Si vs Fe line which was found to be 1.2

Reduce and close the Cross Graph window.

For more discussion on EXAKT's transformation scripting language see the post by Martin Kay on the EXAKT forum

EXAKT handles events (such as oil changes, adjustments, alignments, calibrations and other minor maintenance) that impact condition data in a correct manner.

Display the C_Inspections table.

Scroll to record 356

Note that for a period of 5 months, From 7/6/94 to 11/21/94 no oil change (OC) events are indicated, where oil changes were performed previously about every month. We suspect that the oil changes occurred but were not reported. This could affect the model.

Reduce and close the C_Inspections table

Add the following two lines to the OutputVarScript, (adding a semicolon to the end of the current last line) so that the last three lines read:

SqrtFe=Sqrt(Fe);
HWAge = WorkingAge-First(WorkingAge);
OilAge = HWAge-NonDecr(HWAge*(Precedence = 1))

We have applied a transformation to the data, which originally does not contain OilAge. Now we have a variable for the oil's age at any CBM inspection. This transformation allows further analysis, by the following steps.

Click "With Covariates (Compete)"

Activate left pane, Modeling (menu bar), Create Model Input Tables, Complete Data, View, Cross Graph, Table: C_Inspections, Horizontal:  OilAge, Vertical: Fe, Show

Note the samples whose oil age is as high as 15000 hours. Synthetic oils were introduced only towards the end of the period represented by this sample. It is impossible that the mineral oils would have remained unchanged for upwards of 2000 hours. Rather, we may conclude, oil changes often went unreported.

Modeling (on flow chart), Weibull PHM, Select Covariates, Fe ->, CorrSed ->, OK, OK, close report window, Residual Analysis, In Order of Appearance, Close graph window

Left Window, Residuals: PHM(noOC)(*) #1”, click on the “Residual” column header to order the records by Residual, scroll down to last row, note the History Number of 64, close the table

Transition Probability Model, Transition Rates, OK Decision Model,

Decision Model Parameters, Replacement (C): 1200, Failure (C+K): 6000, Inspection Interval: 250, OK, Close Cost Function graph window

History numbers (such as 64) are applied by EXAKT to the life cycles in chronological order. We must identify which life cycle of which unit is the offending one. Following the instructions below, we can find the history (life cycle) is the 2nd history of unit 5509R.

Procedures panel, Decisions, All Histories, Select History 5501L1 (That is the first lifetime of the left wheelmotor of haul truck 5501), hit the DnArrow key 63 times, Note that we are at 5509R[2],Close

We need to examine the cause of the offending history. The instructions below reproduce the table and graphs shown on the slide. From these, we observe that the cause of offending history is the unusually high values of Fe and Si not explained by a failure event. A reasonable solution to obtain a better fit model is to assume that a maintenance event was not properly recorded and to exclude this history from the model.

View, Inspections, Include Events View, View by history, Select All:  Uncheck, move all variables to “Unselect” position, move Iron and Si to “Selected” position (as shown on Slide), OK

Select 5509R2

Click on a point on the large peak around 65000.

We note that there is an unexplained increase in Fe and Si. That is there is no event to support the strange increase and 4 months later the decrease in values. The residual analysis of the previous slide is telling us that this history violates the model that we are attempting to build. We remove this history from consideration in the analysis, because, obviously, a failure event went un reported. See the EXAKT forum for a way to remove the offending history.

Activate left (tree view) window, View, Inspections, OK, Ident drop down list, hit various idents and observe their inspection data, reduce the inspections window, close (X) the inspections window.

Note the randomness yet increasing nature (generally rising slope) of the data. Although it is obvious that the item's deterioration is reflected by the monitored data, how does one make a decision at any given inspection if the data is so erratic? How do we know if a high reading is due to noise fluctuation or to a deteriorating failure mode? The following steps in EXAKT provide a solution to this problem.

EXAKT provides a way to perform “smoothing transformations” of the data. In the OutputVarScript window you will see a small program that transforms the original variable LeakRate into the transformed variables leakSmooth and leakSmoothAve . EXAKT’s programming language provides several smoothing functions. Smooth() and SmoothAve() are smoothing functions that take parameters to adjust the way in which they transform the variables.

Database pane, OutputVarScript , X

(Note that we have defined 4 new variables from the original LeakRate and WorkingAge variables:

leakSmooth0, leakSmooth, leakSmoothAve0, and leakSmoothAve

Let's look at the first transformation:

leakSmooth0=Smooth(LeakRate,WorkingAge ,3);

leakSmooth0 will be the smoothed transformation of the LeakRate using a smoothing window of three time units. That is, each value of leakSmooth is transformed into what its value would be on a linear regression line fitted to all the points in the 3 time unit window.

Let us generate the decision graphs of the model built directly on the original (untransformed) data.

A) Modeling (on menu bar), Select Current Model, CBM Model:  Seals, Submodel: LR_b1, OK, Procedures panel, Decisions, Select Ident: 5EH1, scroll down to last row, shift+8WH4, Report, Close, PageDown or PageUp, X

B) Modeling (on Procedures panel), Weibull PHM, Select Covariates, (note the variable used for this model LR_b1 is LeakRate), Cancel

Observe how much randomness there is in the inspection data. Such randomness may bias the model and may make it difficult to clearly apply an optimal decision.

Repeat Step A (Slide 4) but select the submodel LR_Smooth0 instead of LR_b1

Repeat Step B (Slide 4) but note the variable used for this model LR_Smooth0 is leakSmooth0 , Cancel

The model LR_Smooth0 uses a variable that has been smoothed by the Smooth() function in EXAKT. On the decision graphs, we observe that we have eliminated the randomness of the previous submodel. But we have another problem. We observe a drooping artifact at the end of every history. This causes a poor model and a poor decision recommendation because the current value of the condition indicator leakSmooth0 is erroneously low! In step 7 we will correct this problem with a further transformation.

Repeat Step A (Slide 4) but this time use the submodel LR_Smooth

Repeat Step B (Slide 4) but this time note that the variable used in the submodel LR_Smooth is leakSmooth

The adjusted smoothed variable produces a better model and a better decision recommendation. Note that the randomness of the data is further reduced and the drooping artifact has been corrected.

Now that we have seen some techniqes for pre-processing data to eliminate confusing noise, we may look more closely at the model itself. You may be wondering about the naming convention we adopted for the model “LR_Smooth_b1”. The “b1” part of the name indicates that we have fixed Beta, the shape factor, to 1. We will proceed to learn why we did this.

Modeling (on Procedures panel), Weibull PHM, Select Covariates, Cancel

We note, in carrying out the above steps, that this Submodel “LR_Smooth” uses the transformed variable leakSmooth and that the “Fix shape factor to 1” checkbox is unchecked.

Residual Analysis, Summary Report, scroll down. (note that the goodness of fit hypothesis is rejected), reduce window, X

Look at the modeling results in the orange framed "Parameters" window inside the Procedures window. Note the NS (not significant) indication after Shape = 1.35644.

Upon executing the above steps, we note that the model is rejected by the Kolmogorov-Smirnov test. The test is telling us that the hypothesis that the model is “good” (fits the data) must be rejected.

EXAKT has told us in the previous step that working age is not significant. In fact it is highly significant, so much so that it correlates closely with the LeakRate . Thus EXAKT is really telling us that the LeakRate itself contains all the information we need, to establish a good predictive model, and it is telling us that we should remove WorkingAge as a significant factor from the model by setting Shape to 1.

Modeling (on menu bar), Select Current Model, LR_Smooth_b1, Modeling (on Procedures panel), Weibull PHM,  (note that the shape parameter has been fixed to 1 for this submodel), Cancel

Residual Analysis, Summary Report, expand and scroll down. (note that the goodness of fit hypothesis is not rejected), X

Similar results can be found for models: LR_SmoothAve0_b1, and LR_SmoothAve_b1. You may go ahead examine these models using the tecniques you have learned in this exercise.

Once you have made smoothing and other adjustments to the model, you may apply cost data as in the Basic tutorial in order to develop the decsion model. it is ready to be deployed as an intelligent agent. You no longer have to worry about the erratic and noisy nature of the data. The compensating algorithm has been built into the model and will be applied automatically each time a new set of condition monitoring data is received.

1. We will begin by building a new database in which to hold the eventual data for analysis.

Start, Data Prep Tool,

File, New Corporate Database,

From Default Template, Standard MES.

2. Navigate to a folder (say test\Exercise5), name, and Save the database.

3. Begin adding the variable names for the condition data you expect to be analyzing and from which you eventually wish to build a CBM decision model. OK.

4. Close the “Open Corporate Database” dialog.

Close the Data Preparation Tool.

5. Start, EXAKT for Modeling,

File, New,

Navigate to the folder where you created the tutorial5_MES.mdb file, Select it and change the name to “Exercise5_WMOD.mdb”,

Create

6. Modeling, Data Setup, Copy and paste this script into the Script Editor, Execute, Save.

Database = "Exercise5_MES.mdb";
Attach
CovariatesOnEvent,
Events,
EventsDescription,
Inspections,
VarDescription

The “Create Initial Data” option in EXAKT will be used to start building a PHM model where there are an insufficient number of histories.

7. Edit, Create Initial Data, Events.

1. One can set up pairs (i.e. Bs and EFs) of events records for each failure mode to be modeled.
2. In table shown we created four histories for failure mode "linea potencia" and two histories for "desgaste general"
3. In the DataPrep tool we would set up a _MES database for Marginal analysis.
4. We would likely set it up with warning limits.
5. Then we would the artificial event records that we created into the Events_MA table.
6. Finally we would proceed with Marginal analysis as in Exercise 2.
7. Manually add warning limits to the VarToModel table.

Set up the General Project Data.

Open and close any table, to activate the buttons on the flow chart.

The C_Inspections and C_Events tables appear in the tree view.

Decision Model, Decision Model Parameters, Replacement (C): 1000, Failure (C+K): 5000, Cost Unit: $

OK

Decisions, All Histories, Select a (real) Item, Report.

Data Preparation, With Covariates (Complete), Modeling, Weibull PHM, Select Covariates, Submodel Name: HIERRO, Select HIERRO, OK.

Transition Model, Transition Rates, OK, Decision Model, Decision Model Parameters, Replacement (C): 1000, Failure (C+K): 5000, Cost Unit: $, Inspection Interval: 30, OK, Close Cost Function Window.

Decisions, Select, Report

Download the zip file and extract into a folder, say "test".

(the test folder will now contain the folder Exercise6)

Start DataPrep tool

File, New Corporate Database, From Default Template, MES for Combined Analysis

Navigate to the test\Exercise6 folder

Save the file as combinado320_MES.mdb

Close the DataPrep tool.

DATABASE = "ComplexItemsDemo_DMDR.mdb";
ATTACH DecCovariatesOnEvent,
       DecEventsDescription,
       UnitToModel,
       DecEventToModel,
       DecVarToModel, Decisions,
       DecModels, DecIntegratedModels

It may be desirable to "group" covariates. EXAKT refers to these groups as partitions. Then one composite covariate will represent each group, and by this technique, reduce dimensionality to the number of partitions.

The sum of all "group" (partition) composite covariates is then equal to the composite covariate of the original model.

EXAKT gives the created composite covariate the same default name as that of the created model, which by default is:

Z__00 (using two underscores).

In a similar manner, the default names of the partition composite covariates will be:

Z__00_00, Z_00_01, ….

Partition variable names can be edited, as well as the composite covariate name.

A covariate should be included in one and only  one group. The program will do an check for this. Therefore, the hazard function of the original PHM will not change its value, but only its form. Howerver the dimension of the transition probability matrix (that depends directly on the number of covariates) will be significantly reduced.

The dimension of the transition probability matrix is one of the main factors in all calculations regarding the decision model and the calculation of decisions.

² This is an option in EXAKT which may be used when setting the decision parameters. Sometimes there is a short period of time at the beginning of a life cycle where the mechanical components are "bedding in" or "wearing in". During this period monitored variables, such as wear metals may be abnormally high. This would cause the hazard as calculated by the PHM to be high. Yet the model should not return a potential failure alarm during this transitory period. By setting this parameter, we avoid false alarms during the time of bedding in.

Minimum preventive maintenance time 

See explanation given in step 7.

Regular maintenance interval 

This is an option in EXAKT that is used when setting the decision parameters. This optional parameter of the CBM Model will, if applicable, improve the calculation of the optimal policy. The Regular Maintenance Interval refers to non-rejuvenating events performed regularly in time and those actions are known to impact the covariate values. Such events may include minor adjustments, calibrations or oil changes carried out at some interval of the working age. For example, oil changes performed every 600 hours.

“Current”: 

What actually occurred. Of the 13 actual histories in the sample 6 failed, 3 were replaced, and 4 are “undecided” – that is, at this time we do not know whether they will eventually fail or be preventively replaced. (At present they are still operating).

EXAKT applied: 

When the EXAKT policy is applied retroactively to the data set,

• 1 history would have ended having failed,
• 6 would have been preventively replaced, and
• 6 would have been undecided

Fitted EXAKT applied:

The curve of the EXAKT decision chart is fitted to the actual data; so as to minimize “average” realized cost.

EXAKT applied: The cost of the policy obtained from applying the optimal model retroactively to the sample.

Fitted EXAKT applied: The curve of the EXAKT decision chart is fitted to the actual data; so as to minimize “average” realized cost.

EXAKT: The theoretical “expected” cost effectiveness of the EXAKT model.

Replace at failure: The policy of not using any proactive (neither scheduled nor on-condition) maintenance.

Table B provides the other extreme assumption.

While Table A assumed that histories that are at present incomplete will have been (successfully) preventively replaced by the proposed decision model, Table B simply ignores the incomplete histories.

One may consider the assumptions of A and B as defining the envelope of possibilities of future performance of the model. If both provide satisfactory results, we may confidently apply the model going forward.

Clear any results left over from a previous user.

Each platform has its own breakdown structure (at left in image below) of systems, subsystems, components, and failures modes (the failure modes being the leaves of the tree structure).

The platform has logged the indicated accumulated age variables: e.g. Hours in Service, Total Hours Operated, Hours on Land, Hours in Water, Miles Driven, Engine Starts, or whatever else has been recorded and is considered significant to the survival probabilty of the platform and its failure modes.

Note the Engine starts Accured Age of 7348.13

Examine the Engine Starts indicator. The value is 840 for the engine whose serial number is SN-091, not the 7348.13 Engine Starts indicated at the Lav-25A1 platform level.

Notice also the columns differentiating  Age since new and Age since last visit. Of course these can have different influences on survival probability.

The Proportional Hazards Modeling (PHM), that relates monitored variables to a failure mode probability, are input into SPAR-PHM so that prediction and optimization will account for the influence of both operational (external) and sensor (internal) variables as well as age.

Failure modes are check boxed  as "Critical" or not depending on whether their occurrence will compromise the mission.

At the failure mode level the accured accrued Age is indicated. As well the baseline distribution (in this case Weibull) and the Proportional Hazard Model coefficients are displayed. Alternatively an "Aging Factor" can be used where no PHM is available to estimate the impact on accumulated hazard of past and future operating conditions.

The radio subsystem, for example, has five failure modes in series.

We will be considering only serial systems here. The block diagrams tell us about the relation between a system's failure modes and its ability to perform the mission. The serial block diagram (blocks in series) indicates all components as being mission critical.

The dashboard displays the current and projected "% Cumulative Damage" (accumulated hazard)  for the platform and its components. The % Cumulative Damage reflects all the significant factors (past and projected usage as well as latest sensor readings).

Because we selected Radio in the Data Explorer, it is in focus at the top of the Dashboard. Its accumulated hazard is currently 46.53. If we hit Sort, the radio's failure modes will be sorted with the worst offenders at the top.

Definition:

Cumulative Damage: The Cumulative Failure Probability, F(t), when calculated at the time of interest, t, taking into account relevant age and sensor values, represents the percentage of "life" that has been used as a result of operation prior to t.

F(t) depends on:

1. The system RBD
2. Its usage, past and projected, as recorded by its operating variables,
3. The latest sensor data, and by
4. Maintenance, past and projected, whose effect is to reduce cumulative damage.

A failure mode’s failure behavior may depend on one or more of

1.  sensor covariates,
2. operational covariates, or
3. aging units such as miles driven or hours on land.

All of these may impact the failure rate (hazard). Therefore the model must use these in order to make optimal maintenance and supportability decisions.

Hit the Description Tab.

Hit the Graph tab.

The verticle line marks the present time. The blue line is the projected operating profile for this variable which is a user input. (We will see how to provide this information to the model.)

Similarly for Sensor variables.

The simulation will include the proportional hazard model and apply it to current sensor data.

With the cumulative distribution function F(t) available from the simulation, the user may have the software calculate survival probabilty at the system, sub-system, LRU, or failure mode level for any duration of the current or next mission.

Any number of scenarios that we have developed may be recorded and played back at any time. For example:

This is the cumulative distribution function, F(t), for the configured system scenario, in this case "No maintenance".

  Simulating various alternative strategies will allow choosing an optimal one.

At the current time, then, the Radio is the line replaceable unit (LRU) that represents the greatest portion of accumulated damage (cumulative failure probability).

Assume that it is expedient to replace the radio now, and plan more extensive maintenance at the next scheduled opportunity.

We would like to investigate how replacing the radio now will impact the current mission's survival probability from now till the next maintenance opportunity.

In a "no maintenance" scenario, the Dashboard, once you hit Sort in the "Current" column, indicates that the most likely source of failure will take place within the Communication system.

Hence the radio is the main offender in the communication system.

Drilling further, it is the Transmitter.

We analyzed the system by drilling down to the failure modes that have the highest probability of interrupting a mission.

If we are able to maintain (decrease F(t)) the "bad actors" now or at some specified time in the future, SparPHM allows us to understand to what degree those maintenance actions will improve  the system's ability to perform its mission.

SPAR-PHM also provides the the cost to do so.

Several alternative sets of activities and costs may be examined (simulated) to determine the optimal maintenance plan and operational profile.

The health indicator, F(t), allows us to consider, statistically,  the probabilistic damage level. If we

• undertake pressing maintenance activities now, and
• plan the less pressing additional activities at a future maintenance opportunity, and if we
• adjust the projected operational profile within allowable parameters,

SPAR PHM will guide us to a plan with which to maintain system health at the level needed to accomplished the mission.

The objective, then, is to use the software tools to determine the best actions and their timings in order to ensure that the mission will be accomplished with acceptable confidence and cost.

With the radio replaced, the Drive System is the major source of unreliability. In the next steps we drill down to the most critical failure mode in the Drive System.

Each operational variable is planned in the following calendar. These may be numerical or qualitative variables. Both are used in the simulation. Examine the default usage profile for each of the operations variables. You may use hte defaults in this exercise. Note  the planning horizon in month intervals from 01/04/2008 to 01/01/2010. The horizon and its intervals may be changed for each operations variable individually by hitting the calendar drop down as shown.

This view shows the active maintenance schedule for the current platform. We have an opportunity to perform maintenance a the current time (25/03/2008) and in six months (26/09/2008) with a planned end of mission six months later on (30/03/2009).

Task planned for current maintenance period (0).

Tasks planned for next maintenance period (1).

End of mission No tasks planned for next maintenance period (2).

SparPHM allows us understand how a given maintenance plan will reduces "virtual age" so as to increase its survival profile. The simulation applies the proposed  maintenance plan. This will illuminate, through what-if analysis whichindividual tasks applied at the scheduled maintenance periods, will best reduce virtual age to the degree required for mission success.

Effect Factor

Note that a task does not not necessarily reduce age to zero (as-good-as-new). The Effect Factor for each task shown above indicates the amount of age conservation. In the above maintenance of the radio, all failure modes are considered to have been repaired to an as-good-as-new state. That is no age has been conserved from the previous life cycle.

MTTF Multiplier

The maintenance task may include an upgrade (or downgrade) which would affect the failure distribution. This effect would be input as a MTTF Multiplier, say 1.5 (which would have the effect of changing the beta parameter of the failure mode Weibull distribution).

Cost

The requirement is to know what failure modes are being affected and in what way, since they would affect future availability (the failure distribution). There is a cost input. Some maintenance tasks are more expensive than others. Optimization requires the accomplishment  of required levels of survivability per dollar spent so that the most cost effective strategy can be selected through multiple simulations.

The last step of the Maintenance  Planner wizard asks if you want to update the plan. Keep the existing plan.

The important output is the failure probability of the system. We want to understand how all those factors, collectively and individually will be affecting system reliability - the capability of the platform to perform its upcoming mission.

Historical usage is procurred from operational databases.

The sensor readings and operational data are processed and formatted  the SparPHM input database. The PHM models are in place for calculating the system failure distribution. Future maintenance plans and usage profiles are updated. And a simulation is performed.

A living RCM process will be used to update the distributions based on past failures as recorded in the SAP, Maximo, or other maintenance information systems.

The following table lists typical sensor data used in the software.

It is not necessary to have all the covariates stamped with common time points. The software normalizes the values so that they can be processed by the PHM algorithm on a single timeline.

For example, certain sensor readings may be  taken once every 24 hours, while others are acquried hourly, weekly, and so on. All readings will be synchronized (via extrapolation) behind the scene (in memory not in the database) by the software.