To ensure that the KPI data can be presented on the displays within an acceptable amount of time (a few seconds), regardless of whether the users are asking for the KPIs for a day or for a year, RTPPM has different mechanisms to pre-calculate the KPIs. The primary mechanism is “KPI Engine”. Each time an event (production, downtime, waste, product change, job order change or , shift change) is modified (start and end time, quantity, reason, product, work order, and so on…), the KPI Engine is flags the corresponding data as “to be recalculated” and will reprocess all of the impacted KPIs during its next execution. If there are many recalculations queued up, the updates can require several executions of the KPI Engine to complete. This all happens in the background and is transparent for users.

For example, on a given day, a line manager needs to change the reason that was assigned to a downtime which happened the day before. This means that the Availability and OEE KPIs are no longer valid for Yesterday, This Week(unless the week changed that day, in which case Last Week is impacted), This Month unless the month changed on that day, in which case Last Month is impacted), This Quarter (Unless the quarter changed on that day, in which case Last Quarter is impacted), This Year (unless the year changed on that day), Last 24 Hours (unless the change was made to a downtime earlier than the previous 24 hours), and finally Last 60 Days.If this done only when a user asks for KPIs, , it would require a lot of recalculations and processing. Having the KPI Engine perform that pre-processing in the background provides much better performance when receiving user requests as the calculations are ready.

The second mechanism in place is a KPI cache. For example, 10 different users open the KPI Dashboard (or some other display showing KPIs) and are looking for the OEE on Work Unit 1 for Yesterday. Instead of reprocessing that query and asking the KPI Engine to retrieve the data 10 times, we use a cache that already contains the answer (OEE value) given the exact same filter criteria (Work Unit 1, Yesterday). This eliminates the need for multiple calls to the KPI Engine for data retrieval.Using a cache (with an expiration time, as explained below) provides faster results to the user.

The KPIs that are involved in the OEE/OOE (Availability, Quality, Performance) as well as the OEE/OOE KPI itself are not meant to be tracked in real time. The raw data collected behind the scenes is happening near real-time, but there is no point in tracking the OEE every minute, or every 5 minutes. For this reason, the minimum “time slice” that the KPI Engine is handles is one hour. This means that even if the KPI Engine is looking to reprocess any updated data every minute, the final KPIs will be available once a “One Hour” time slice is closed. The exception to this is if you have a product change event, a job order change event, or a shift change event during that one- hour time slice. The time of the event would then be considered the end of the corresponding slice. Consider the following example:

In this example, the KPIs are calculated for each one-hour slice, but the time period during which Product A was running was also a slice, as is the time period for Product B, Job Order A, Job Order B, Job Order C, Job Order D, Shift 1 and Shift 2. KPIs must be calculated of these slices, so that when the user selects the criteria, for example from the Advanced Filter Panel on the KPI Dashboard, then the KPI Engine already has the KPIs pre calculated.

When there is an active cache for the criteria selected by the user, the pre-calculated KPIs that are associated to that cache are returned directly. Each cache has an expiration period, so that out-of-date data is not returned This means that if the same criteria are selected and a request is sent, if the expiration time of a cache is reached, the existing cache is considered outdated and will be refreshed before sending back new data to the user. Depending on the selected time period, the delay before a cache expires will be different. If you ask for KPIs for This Shift, the cache needs to be refreshed more frequently than when you select This Year. The following table lists the time intervals that are available with the corresponding expiration period for each.

When there is no cache found for the selected criteria, a new cache is created, however the data first needs to be queried from the KPI Engine (Fact Tables). By the time some data is modified for example, a change of reason on a downtime, or a new production quantity received, this will be processed the next time the KPI Engine processes the waiting data, as previously explained. Then, the data needs to be pre-aggregated in the Fact Tables, and finally, the cache can be refreshed and be available. This means that when the cache is not readily available, there can be an interval of a few minutes (typically 1-5 minutes) before the KPI information is available on the different displays. The goal is always to have the right balance between near real time data and good performance on the displays. The operator display shows most of its information much closer to real-time, except for the OEE section.