Terminology explained: What is the difference between Calendar and Operational time?
For this week’s Terminology explained: What is the difference between Calendar and Operational time? We’ve got one of the most experience Asset Performance Consultants, Kuhan Sivathasan, to explain!
Different failures modes have different causes
For example, a bearing may wear out when operating but can’t wear out when it’s not running – hence the wear out failure mode is a function of operational time. Conversely, a vessel will have external corrosion irrespective of whether it’s in service or not hence the external corrosion failure mode is purely calendar time dependent.
Our clients collect a lot of data from their facilities and try to use this to create reliability data. The accuracy of which depends on the extent of the data collected. Usually the Computerized Maintenance Management System (CMMS) is used for maintenance tasks and related work order generation. The data that is captured will be things like:
- When the item failed (not always captured)
- When the work order was created
- When the work order was closed out
- Maintenance duration or man-hours (not always captured)
This data only allows you to assess the failure frequency as a function of calendar time as there is no record of operational time. It can also be unreliable – I remember a case with a client where they created reliability data using the number of work orders collected over a 5-year period for frequency and the delta between work order creation and closeout as the repair time. The frequencies were reasonable but the repair duration calculations were complete out of scale – sometimes 6 months or more for repairs that should have been completed in a shift or two. On closer investigation, we found that the operators were closing out the work on 31st December each year to avoid having outstanding work orders carry over! This is representative of the blind trust placed on the accuracy of computerized systems – data must always be validated, irrespective of the source.
How to get the operational time?
To get operational time either the CMMS needs to be recording the runtime of the unit (which is unlikely) or this data can be extracted from another system measuring runtime (e.g. PI Historian) and then aligned with the CMMS. Just using the runtime data for reliability is also prone to error as you have no definition on whether an item stopped due to a planned event, unplanned failure or an operational decision (e.g. loss of an upstream or downstream system). For example, I recently received the production history from a LNG plant and reduction in throughput was seen every day. If used blindly, there would be slowdowns happening on an hourly basis! Fortunately, there was also a separate record showing the events that caused the losses allowing for filtering of losses due to temperature fluctuations, feed variations, planned activities, upstream shutdowns and tank tops. Once filtered, the slowdown/shutdown data was much more realistic.
Failure pattern of units operating in stand-by
Another challenge presents itself in in the context of performance forecasting when describing the failure pattern of units operating in stand-by. In the Maros and Taro, the failure probability of a stand-by/passive unit is only sampled when the unit is activated (through failure of the primary unit). This method works well for operational time dependent failure modes as failures can only occur when the unit is being run. However, non -time dependent failure modes will not be correctly accounted if left in the passive unit. Consider an active pump which is supposed to operate for 10 years with a failure rate of 1 failure per year and a Mean Time To Repair (MTTR) of 24 hours. In this case, the passive pump will be operated when the active pump fails which is only for 240 hours (as opposed to 87576 hours; 10 years of production). This works well for operational time dependent failure modes but calendar time failure modes will not be accounted for. Since a calendar time failure mode will not typically manifest itself until the unit is started, the model should use a “failure to start” probability for the passive unit to more accurately represent the likelihood of these calendar time dependent failures being experienced by passive units. Typically, operators will try to match operating times of active/passive block, Maros and Taro for example uses the function to “Remain with last operating unit” to model this scenario however “fail to start” is still required for the passive unit.
ISO:14224 (Collection and exchange of reliability and maintenance data for equipment) fails to define Operational and Calendar time when describing the process of collecting reliability data – there are three entries in the entire standard. OREDA provides both calendar and operational time failure; as mentioned before, in this case the operational time may be considerably less for equipment that is normally on standby (e.g. firewater pumps). Thus, it is important to use the reliability data with extra caution. OGP has a great document discussing the use of Reliability data but it is very risk-focused (Guide to finding and using reliability data for QRA).
It is very important that the analyst knows the difference between what is been used so the model doesn’t suffer from the old motto: “Garbage in, Garbage out”. If the process of collecting and assessing reliability data is consistent in one of the options (calendar OR operational), the model will generally yield good results.
In the end, we typically use calendar data because it’s easiest and we have greater confidence in the data sources. While operational time data may be more accurate, to use it properly you would have to split the operational time dependent failure modes from the calendar time dependent failures modes and then include logic to delay the occurrence of other operational time dependent failures when another failure occurs or the equipment stops running for other reasons (e.g. planned maintenance, operational upset or failure of another equipment item). This is complex and unlikely to add value commensurate with the effort involved in getting it right!