Forum: EXAKT

Thanks Martin for this good question.

This tutorial was derived from a CBM project at a Canadian coal mine. We had nine years of monthly oil analysis data on a fleet of 55 wheel motors. The first step in developing a proportional hazard model (PHM) is to find which, if any, significant variables could have predicted failure modes that had previously occurred.

To this end, we make use of whatever engineering or physics knowledge we might have in order to test likely variables. Often a variable in it's raw state will not be significant whereas a transformation of that variable or a combination of one or more variables will. As an example, we might surmise that the failing state of a heat exchanger would be reflected, not by a single temperature at one location, but rather by a temperature differential between points upstream and downstream of the component. We would then use EXAKT to test whether the difference in input and output temperatures correlates with the observed failure rate of that particular failure mode.

EXAKT provides an efficient (but, unfortunately, non-intuitive) scripting language with which to set up such transformations for model testing. Like any computer language, it takes some getting used to. There are several examples in the on-line help guide which helped me understand the language. Let me provide some explanation for the various transformations you are asking about.

1. PrevSed1=Sed-Diff(Sed);
   This is what EXAKT calls a "history transformation".
   Diff(Sed) calculates the difference between the current and previous value for variable Sed.
   With this transformation we have created a new column "PrevSed1" of transformed values. The new variable values are equal to the current value of Sed minus the change in the value of Sed since the previous oil sample. With a little bit of algebra we can see that this transforms the value of the sediment into its previous value. We had a reason for making this transformation, as is apparent from the following:
2. CorrSed1=Sed*(Sed>0)+(Sed=0)*PrevSed1;
   The unintuitive syntax "variable*(condition)" should be read as follows "use the actual value of variable if condition is true". So this transformation returns the current sediment level if it is greater than zero. Otherwise it returns the previous value of sediment reported by the laboratory. In fact. the laboratory was generating nulls (or false zeros) which we knew were impossible. We needed viable values for sediment for the purpose of testing our model. So we told EXAKT (via this transformation) to use the prior value of sediment whenever we had a zero (i.e. no value at all).
3. PrevSed2=CorrSed1-Diff(CorrSed1);
   Similar to before we are setting up a dummy variable PrevSed2 to hold the previous value of CorrSed1. Same idea as in 2 above so that we can again get rid of false null values. (Just because the lab forgot to do the test, does not mean that the value would have been zero. Substituting the prior value for the false zero would be a better bet.)
4. CorrSed=CorrSed1*(CorrSed1>0)+(CorrSed1=0)*PrevSed2;
   Finally we end up with a variable that we can test, one that we know will have no false zeros.
5. The next two transformations LogSed=Log(1+CorrSed); and LogFe=Log(1+Fe); are simple math transformations, and so are easy to understand by mere mortals such as you and me.
6. CorrSi=Si*(Si< >900)+1.2*Fe*(Si=900);
   This is yet another history transformation that tries to compensate for poor quality of laboratory results. Through our investigation of the data using the EXAKT cross graph function, we discovered an unbelievable coincidence - that a large number of values for silicon were exactly 900.0 ppm. Our skepticism led us to call the lab and ask for an explanation for these incredible results. They admitted that over a period of a few years that had the wrong photomultiplier tube in their spectrometer. That one was saturating out at exactly 900 ppm hence falsely reporting any value of silicon over 900 ppm as exactly 900. We needed a way to fix this for purposes of model testing. We made use of the fact that there was a clear linear correlation between Iron and Si with a slope of 1.2. Hence this transformation substitutes the value of Fe x 1.2 for each value of silicon that is exactly 900.

The answer to your question "How are we to know when setting up a new database or project when/where/if an entry of this complexity is needed, and what it should contain?" therefore is:

Trust me. You will know. You will have certain transformations in mind that, based on your engineering knowledge of the particular failure mode, you think are worth testing. This transformation language, although terse and unintuitive, is extremely powerful and can deal with any type of history or mathematical transformations that you need to test.

Murray

Hi Murray,

Thanks for the explanation, the example of the heat exchanger is one to which I relate easily. I don't have any problems with the concept of transformations in this sense, using differentials and parameter relationships is something I am comfortable with. My concerns are with use of the scripting language, my programming experience is limited to very basic SQL queries in MS Access and so I found it rather daunting. The way forward initially will be to try to work through the problem by referring to the help screens, and then to seek assistance with the syntax if I get hopelessly stuck.

thanks again

Martin

Hi Martin:

I agree with you that the history transformations in EXAKT's scripting language are daunting. But no more so than any other new set of definitions and symbols. After you use them a couple of times they become just another method in your bag of tricks.

I find one transformation described in the EXAKT guide particularly interesting. Most of us in maintenance have wondered, at one time or another, whether the age of the oil influences the component's failure rate. One might speculate that as oil gets older the additive package depletes resulting in a greater chance of failure due to lubrication problems. In EXAKT, we can test whether an oil's age is a significant risk factor.

The problem is, however, that CMMSs rarely provide the oil age explicitly. Therefore we require a transformation based on the date and working age at which an oil change event occurs. (These are usually available.) The explanation for the appropriate transformation follows:

1. First we need to know the real working age of the lubricated component (say, a gearbox or transmission on a truck).
2. Let's call this working age the "History Working age" (meaning the working age of the component's current life cycle) denoted by HWAge.
3. There is no dedicated hour meter or odometer on the transmission so we must use the parent's (i.e. the truck's) "WorkingAge" as a reference. We perform the transformation:
   HWAge = WorkingAge-First(WorkingAge);
   where the function First(WorkingAge) returns the working age at the time of component installation.
4. Next we caculate the OilAge using the transformation:
   OilAge = HWAge-NonDecr(HWAge*(Precedence = precedence for OC))
   where:
   HWAge*(Precedence = precedence for OC) returns HWAge in the current record if the event is an oil change."
   NonDecr(x) returns the highest value of the argument "x" up to the current record.
   Hence this transformation subtracts the current working age of the component from the working age at the last time the oil was changed. This gives us the oil's age.

Not difficult, just an unfamiliar syntax.

We have often, in response to queries from maintenance people, tested the oil age as a covariate (a possible risk variable) in a number of PHM models. We haven't yet found a case where an oil's age correlates with an item's propensity to fail. I conclude from this that lubricating oil is, generally speaking, of high quality and robust.

Murray

>
> Hi Murray and Martin

I agree with Martin, the need to write script in the application is over complicating the process. smarter tools such as look up brousers and drop downs to tables needs to be added to all EXAKT tools.

The easier it becomes the more accepted the product and the more uses can be found. Humans will revert to the easy escape that it is all to hard, and revert back to the norm.

Please consider these requests as a need for future sales not engineering brilliance!

Regards
Russell Harland
Equipment Management International P/L

Hi Russel:

Yes an automated generator for pointing EXAKT to the relevant databases and tables is a great idea and will be added to a future release.

Transformations, however, are a different story because they contain both SQL and math formulas. I am afraid we're still a few years from UIs that can do that.

Murray

I'm late to the discussion here.

Note that there are some transformations that have been automated in the "Add Derived Covariates" option included since version 4.0.

The user selects the desired transformation using the graphical interface, and the code is written to the Output Var Script. This option was developed because I was too lazy to write out the same transformations over and over.

I have a list of others we'd like to add sometime.

Regards,
Neil (from C-MORE, where EXAKT was created)

Hi Gents

Neil has added some feedback from the developers point of view which needs further discussion I feel. My question, is there a list of development changes to EXAKT that is scheduled for the next version?

Who is managing the future development/improvements/bug fixes and is there a register where we can add feedback to the next version?

If so what are they, where are they posted and when will the next version be released?

regards
Russell