STEM help / Calculation framework

10.3.34.10 Time Factor Transformation

A classic situation arises in operational modelling when you wish to link an ongoing activity to a static quantity; e.g., maintenance tasks or fault handling associated with some type of installed equipment. Typically you may wish to use some kind of assumed rate of tasks or faults per month which may then be taken, in conjunction with the duration of the current period, in order to calculate an actual (aggregate) number of tasks or faults in a given month. It was possible to attempt such a calculation in STEM 7.2 by using the periodLen() function within an Expression transformation, but this would not help STEM to actually recognise the output as an aggregate quantity.

The new Time Factor transformation is designed to meet this requirement in such a way as to enable STEM to classify its output as aggregate, in spite of its instantaneous origin, as a consequence of the implicit time factor!

Describing a quarterly failure rate with the new Time Factor transformation

Consider a resource with an assumed failure rate of three per quarter. In addition to a conventional Multiplier input, the Time Factor transformation has a Multiplier Period input which signals to STEM that a given multiplier is actually a rate in time, and on what time scale. When calculating the transformation output for a given period, STEM will scale the Multiplier by the length of the current period compared to the length of the given Multiplier Period. So with Multiplier = 3 and Multiplier Period = Quarter, the input (typically Installed Units of the resource) will be multiplied by:

  • 3 × (360 / 90) = 3 × 4 = 12, when running in years
  • 3 × (90 / 90) = 3 × 1 = 3, when running in quarters
  • 3 × (30 / 90) = 3 × 1/3 = 1, when running in months.

Thus the new Aggregate Count result will always indicate a number of failures in proportion to the length of the current period and any monthly or quarterly results will be correctly consolidated via summation. Such a transformation can then be used to drive a requirement for (consumable) spares, as described below, or an engineer cost which may well be a direct function of tasks (or task hours) if the task is sub-contracted.

Converting (aggregate) events per period to an equivalent (instantaneous) monthly rate

The Time Factor transformation may also be used ‘in reverse’ to infer an effective instantaneous rate from an aggregate measure. The default Output Mode of Aggregate Count can be changed to Instantaneous Rate in order to apply an inverse time factor, so that events accruing in a period can be scaled to an equivalent annual rate (or whatever).

Suppose you wished to compare the cost of employing your own maintenance engineers with an external sub-contractor cost. By taking the aggregate failures each period output calculated above (and potentially repeated for various separate activities) as the input to another Time Factor transformation with Multiplier Period = Month and Output Mode = Instantaneous Rate , STEM can then divide this input by the length of the current period compared to a Month in order to determine the equivalent monthly rate. The Instantaneous Output result can then be mapped onto a conventional persistent engineer resource whose capacity is defined in terms of number of failures resolved per month.

Alternatively, the required time factor may be captured within the resource itself – see 10.3.1.5 Matching (instantaneous) power with (aggregate) energy consumed in time.

Note: the Multiplier input part ‘still multiplies’; it is only the time factor which is inverted (e.g., you might use Multiplier 1.2 to allow for an internal training overhead).

 

© Implied Logic Limited