ROCK Documentation : Calculating RKEM Latency

The RKEM latency is calculated for each and every site found in COMS [RKEM Current Moves] table. The valid latency value is set as the median of values in the dataset. 

Example: Calculating RKEM Latency across a set of RKEM moves for a site

Using the below move data, the median of the calculated as (30 + 20) / 2 = 25 min, which is applied in the stock projection cut-off formulas.

ACTDAT, CHDAT Latency
1, Apr-9 10:00, Apr-9 10:20, 20 min
2, May-5 11:00, May-5 11:02, 2 min
3, Apr-15 15:30, Apr-15 15:43, 13 min
4, Apr-7 09:00, Apr-7 10:20, 1 hr 20 min
5, Apr-13 10:00, Apr-13 14:20, 4 hr 20 min
6, Apr-13 11:00, Apr-13 11:30, 30 min


Calculating the latency requires some fine-tuning of the implementation, to handle relevant exception cases. The known exception cases are described below.

CaseDescription
Time Zone

To calculate the latency of the individual moves, ROCK database has to use timezone data to transpose and compare the relevant values in the RKEM move (ACTDAT=local time, CHDAT=GMT, DCDAT=GMT)

If no time zone data can be deducted, 24 hours used as fallback.

Inactive SiteIf no Load move found for a site in COMS RKEM Current Moves table, then 24 hours used as fallback
High LatencyIf the median for a site calculated is greater than 24 hours, 24 hours used as fallback
Slightly Negative Median

If the median latency calculated for the port is negative and less than 1 hour, then 60 minutes (1 hour) is added to the median value and used as cut off time for the port. (e.g. -40 min becomes -40 min + 60 min = 20 min).

The assumption is that in these cases it discrepancy is due to daylight saving changes and ROCK lacks this data.

Negative MedianIf the median latency is calculated as negative number but less than -1 hour, then no interpretation is applied, and 24 hours is used as a fallback.
Data captured before activity dateIf the equipment moves have been inserted in RKEM (data capture date) before the equipment move happened (activity date), we disregard it.