A complex item is an item with one or more failure modes or failure susceptible components. A simple item has a dominant failure mode, while a complex item has several failure modes. A CBM program, typically, acquires inspection data (e.g. oil analysis, vibration, performance data) for an entire system, such as an engine. Thus, a single system identifier (say “Engine 7483”) labels inspection data records from which more than one failure mode can be deduced[1]. Each failure mode will have its own age-reliability-CMdata[2] relationship, and hence, its own CBM decision model. 

 

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.[3]  A CBM policy must consider all 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[4].

 

The EXAKT software uses the term Marginal Analysis[5] to indicate that a complex item is being analyzed. We develop our CBM decision models within a “working model” database (whose filename is conventionally of the form equipmenttype_WMOD.mdb). We refer to this database as the WMOD (“working model”) database. To that WMOD database we “attach” tables from one or more external databases. By convention, in our tutorial, we use the name equipmenttype_MES.mdb as the name of the database which contains the data for the equipment or fleet under analysis. The “MES” database contains the original data or data that has been transferred or linked from the CMMS and one or more CBM databases.[6]

 

If the table names in the equipmenttype_MES.mdb database have the extension “_MA” (see the table stuctures of Figure1 below), that will tell EXAKT that a complex item is to be modeled and it should set up the model using its “marginal analysis” functionality. Marginal analysis will allow us to build several CBM decision models, each corresponding to a specific component or to a specific failure mode. Figure1 illustrates the strucure of a database to be used for conducting a marginal analysis from which we develop models for multiple failure modes occurring in a single equipment item.

 

Figure 1 Structure of a MES database to be analyzed using "Marginal Analysis"

 

The tables of Figure1 are identical (except for the suffix “_MA” in their table names) to those of the analysis of simple items (as in Tutorials 1, 3 and 4).

 

Three new tables (Figure 2), however, have been added to the MES marginal analysis database structure. Each component or failure mode in a complex item will behave according to its individual risk model. When complex items are to be analyzed (and their failure modes to be modeled) we need a way to tell each model which data in the database applies to it. For example, one component’s failure may occur at a particular time, but another component will still be in good working condition. We need a structured way to describe the event that each component (or failure mode) has undergone. The supplementary tables of Figure 2 fulfill that role.

 

IdentToModel: relates a decision model to specific equipment units of a fleet of similar equipment. It tells the decision agent to which specific equipment units each model should be applied. For example if certain engines of the fleet do not have turbo chargers, then a model predicting the failure of the bearing in the turbo charger should not be applied to the non-turbocharged engines in the fleet.

 

EventToModel: tells the component specific model which events in the common database apply to the failure mode that it is predicting.

 

VarToModel: maps the field names monitored variables in the CBM database to more convenient names used in a specific model.

 

Figure 2 New tables in MES required for mapping to an individual failure mode model

 

At the beginning of the modeling exercise, the IdentToModel, EventToModel, and VarToModel tables are empty. EXAKT populates them automatically when the user performs a mapping operation guided by the EXAKT marginal analysis dialog. The phrases “Input…” and “Output…” appear in several field names of the tables EventToModel and VarToModel. These fields map their values in the general database to their values in a specific model. For example, “failure of suction valve 3” in the database would be mapped to the the event “EF” in the model that was built to predict the failure behavior of  “Valve 3”.

 

In a single equipment (with two failure modes) we may have, for example, two types of failure events, EF1 and EF2. And two types of suspensions, ES1 and ES2 corresponding the the ending events of their respective components. We need to tell a particular model (of a particlular failure mode or component), which event records (for example, those with the values B1 or B2, EF1 or EF2, and ES1 or ES2 in the database) to use as the beginning, failure, and suspension events respectively for the failure mode currently being modeled or predicted. In this exercise, we need to tell the model for Gear1 to use the events B1, EF1, and ES1 as the beginning, failure, and suspension events (B, EF, and ES). We perform this mapping in a data mapping dialog such as that shown in step 6 of this tutorial exercise. EXAKT stores the results of the mappings in the EventToModel, IdentToModel, and VarToModel tables. Althougth this mapping of data is difficult to understand in the abstract, don’t dispair. It will become crystal clear as we work through this exercise.

  

Let us look then at the Events_MA table (Figure 3) for the equipment item GearboxA to be analyzed.

 

Figure 3 Events_MA table for a gearbox with two failure modes.

Note that, in Figure 3, there is no B1 or B2 to distinguish the beginnings of the lifecycles of the individual components (Gear1 and Gear2). But only a single “B” event. Why? Because, in this particular equipment, the maintenance department adheres to a policy that when one gear fails, both are replaced. Therefore we understand that the the event “B” marks the life beginnings of both components in the gearbox.[7] We have chosen to use “EF1” to designate the failure of Gear1 and “EF2” to represent the failure of GearTwo. Now let us examine the the Inspections_MA table of Figure 4.

 

 

Figure 4 View of the first 23 records of Inspections_MA table

The Inspections_MA table is a single data source from which multiple failure modes in various components of an equipment may be predicted. Hence the decision agent at each CBM inspection will generate individual recommendations and residual life estimates for each component or failure mode covered by a CBM decision model. Each model will refer to a specific failure mode or component. The maintenance manager will be advised, therefore, not only that an equipment failure is imminent, but also which component or failure mode is concerned. This is precisely the information needed to plan maintenance and order parts.

 

Once the decision models have been built and deployed a typical optimized CBM recommendation report covering both failure modes at a point in time might resemble that of  Figure 5.

 

Figure 5 EXAKT output for two failure modes, GearOne and GearTwo

The report of  Figure 5 tells a maintenance planner that Gear1 needs to be replaced, but Gear2 is still in good condition. There is another type of information provided by these decision models that would cause a manager or planner to reconsider the policy of replacing both gears when either one fails. That information is given by the shape of the boundary separating the green and red regions. It is a straight horizontal line. That tells us that, for these gears, the probability of failure at any time is independent of age. Hence there is likely little or no benefit in replacing Gear2 with the objective of prolonging its life relative to the failure mode “tooth fracture”[8].

 

Now let us perform the steps that create and deploy the model that we have just described. Follow these steps using the EXAKT modeling and EXAKT decision programs.

Building the CBM Optimal Decision Model
		Detailed Explanation			Steps to follow
		Install the required database files from the CD (menu item “CBM Optimization” or from this (link) if you are connected to the internet.
1		Open the EXAKT for modeling program (EXAKTm).			Start, “EXAKT Tools”, “EXAKT for Modeling”
2		The databases ComplexItemsDemo_MES.mdb and ComplexItemsDemo_WMOD.mdb are to be used for this tutorial. If installed from the menu on the CD they will be in the folder “C:\Program Files\Exakt\tutorial2”			File, Open, navigate to /…/ComplexItemsDemo_WMOD.mdb, Open
3		After execting the instructions on the right, the required tables are now accessible in the left pane of the EXAKT (for modelling) window.			Activate left pane by clicking on it. Modelling (on the Menu bar), Data setup, type in the attachment script (actually it is already keyed in for you), Execute, Save
4		Initiate the project by giving it a title, and naming the first model (failure mode) to be analyzed, as “Gear1”.			Data Preparation, Enter General Data, Project Title: “GearboxA 2 failure modes”, CBM Model: “Gear1”, Description: “Tooth failure on Gear1”, Time Unit: “Hrs.”, OK
5		After executing the instruction on the right the dialog “Marginal Analysis Data Sheet” (shown in step 6) appears. In this dialog we set up the mappings in the tables of Figure 2.			Marginal Analysis
6		By executing the instructions on the right, we will assign: Idents (that tell EXAKT which idents, i.e. units are to have their data included in the predictive model that we are currently building). Events (that tell EXAKT which named events in the database the model should use internally as B, EF and ES respectively) Variables (that tell EXAKT which variables to use and how to rename them for the model we are building. (This allows the decision agent to display short meaningful names in the optimal decision graph.) These mappings for the CBM Model “Gear1” are shown in the dialog reproduced below.			Idents, Check GearboxA, Events Selection, B, Select Event: B, Precedence: 6, Apply, EF1, Select Event: EF, Precedence: 2, Apply, EF2, Select Event: ES, Precedence: 3, Apply, Variable Selection, Health_Indicator1, Select Variable: H1, Apply, Health_Indicator2, Select Variable: H2, Apply,OK.   [In the above you may be wondering why we are mapping EF2 to ES. The reason is that EF2 is a failure mode of Gear2 (to be modeled next). The current policy is to replace Gear1 preventively when Gear2 fails. Hence the failure of Gear2 marks the suspension (ES) of Gear1.   The variable name Health_Indicator1 in the database is mapped to the variable name H1 used by the model. Shorter names are more convenient in building the model.]
After completing the previous step, seven new tables appear in the left pane: “CMI_Events”, “CMI_Inspections”, “Events”, “Inspections”, “Histories”,”EventsDescription”, and “VarDescription”
7		We will now proceed to build the model for Gear1. After executing the instrucitons on the right a report appears. “Shape” is reported as non-significant “N”.			Modelling (on flow diagram), Weibull PHM, Select Covariates, sub-model Name: H1, H1à, OK, X
8		By rejecting “Shape”, the software is telling us that age is not a significant risk factor for the fracture of a tooth on Gear1. Therefore we will remove age from the model by fixing the shape parameter to “1”.			Select Covariates, sub-model Name: HI_B1, Fix shqpe parameter=1: check, OK (in warning message box), X
8		Build the decision model. The dialogs for the Transition Probability Model (“Covariates Bands and Groups”) and the Decision Model Parametesr are shown below.			Transition Probability Model, Transition Rates, OK, Decision Model, Decision Model Parameters, Replacement (C): 1000, Failure (C+K): 6000, Cost Unit: $, Inspection Interval: 30, OK, Full Report Icon , scroll down to “Summary of Cost Analysis” table, X
9	Executing the instructions on the right displays this report. The report indicates that the gear has failed, but that the failure would have been predicted two sample intervals ago (60 hours) had the model been available.				Decisions, GearboxA, All Histories, Select “GearboxA[1]” to  “GearboxA[9]”, Report, Full Report Icon , PgDn, PgDn, PgDn … X, All Histories, X
10	We have created and tested a decision model for Gear1. We may now, in the same way, generate a decision model for Gear2.				Repeat steps 4 to 9, making obvious changes for the modeling of Gear2.
11	Create a new database “ComplexItemsDemo_DMDR.mdb” with seven tables: 1. DecCovariatesOnEvent 2. DecEventsDescription 3. Decisions 4. UnitToModel 5. DecModels 6. DecVarToModel 7. DecEventToModel				For this tutorial, ComplexItemsDemo_DMDR.mdb has already been created for you. So you do not have to do anything for this step.   However, this can be easily done using the EXAKT tool: Data Preparation for EXAKT. The procedures is: Start, EXAKT tools, Data Preparation for EXAKT, File, Build Corporate Database, Use Predefined Template, Decision Models (DMDR), Filename: ComplexItemsDemo_DMDR.mdb, Save, Enter Covariate Name: H1, Enter, H2, Enter, Marginal Analysis Format: Check, OK File, Exit
11	Attach the 7 tables from ComplexItemsDemo_DMDR.mdb by following the instructions to the right. The attached tables will appear in the tree view in EXAKT’s left pane.				Activate the left pane Window by clicking on it, ModelDBase (on the Menu bar), Connect to Model Database Script, type or copy and paste the following script into the editing window that appears. (Actually it is already keyed in for you.)   DATABASE = "ComplexItemsDemo_DMDR.mdb"; ATTACH DecCovariatesOnEvent, DecEventsDescription, UnitToModel, DecEventToModel, DecVarToModel, Decisions, DecModels   hit Save.
12	Assuming you have previously completed building the model for Gear2 (Step 10), execute the instructons on the right. This will save this model to the DMDR database.				Activate left pane, ModelDBase, Store
13	Make the model for Gear1 the current model.				Modeling (on the menu bar), Select current model, CBM Model: Gear1, Submodel:H1_B1,OK
14	Now Store the model for Gear1 to the DMDR database.				Activate left pane, ModelDBase, Store Decision Model
15	Congratulations. You have created and exported two decision models for a complex item.				Close the EXAKTm program.
Deploying the CBM Optimal Decision Model as an Intelligent Agent
		Detailed Explanation			Steps to follow
1		In this section we will manually run the “agent” so that it applies the two models that we have created to the current data. (It can also be set up to run automatically). After you execute the steps on the right the user interface of the EXAKTd decision agent appears.			Start, Programs, “Exakt Tools”, “Exakt for Decisions”
2		Execute the steps on the right, to open ComplexItemsDemo_WDEC.mdb.			File, Open, navigate to …, ComplexItemsDemo_WDEC.mdb, Open
3		Attach the 7 tables from ComplexItemsDemo_DMDR.mdb.  The left pane will show both models, and the list of equipment to which these models will be applied. In this case there is only one equipment, “GearboxA”. However if there had been a fleet of similar equipment, they would have been listed below each model.			Setup, Connect to Model Database Script, type (or copy and paste) this script into the window: DATABASE="ComplexItemsDemo_DMDR.mdb"; ATTACH  DecModels, UnitToModel, DecEventsDescription, DecCovariatesOnEvent, Decisions, DecEventToModel, DecVarToModel hit Save
4		Select the model “Gear One” and execute the decision agent.			Gear1, Reports, Create reports, Calculate time to replace
5		Repeat step 4 for the model “Gear2”.			Gear2, Reports, Create reports, Calculate time to replace
6		The prognostic results are now available for GeaboxA. Examine the results using any of the 3 ways on the right.			1.       Click on “Gear1” or “Gear2”. 2.       Expand “Gear One” or “Gear Two” and click on the gear unit that you are interested in (only GearboxA in this example). 3.       Click on a gear unit, View, View Model Report.
7		Create a report for all gearboxes and all models.This report provides an automated summary of the state of all units and failure modes. Display this report at each new set of CM data, or periodically.			4.       Reports, Create new report list, New Report List Name: All gearboxes and models, Gear 1, ctrl-c, All gearboxes and models, ctrl-v, (repeat for Gear 1)