Search Results eam_runtime_interval_v




Overview
Explore in AI Chat

Overview

EAM_RUNTIME_INTERVAL_V is an APPS-owned database view within the Enterprise Asset Management (EAM) module of Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. Its documented purpose is to retrieve runtime rule information together with the associated meter details for preventive maintenance scheduling. In the EAM preventive maintenance model, runtime rules allow a maintenance activity to be triggered by accumulated equipment usage — for example, the number of operating hours, cycles, or miles recorded against a meter — rather than by a fixed calendar interval alone. This view assembles that runtime rule configuration, the governing meter attributes, and the last recorded service reading into a single denormalized result set.

Because the object is a view rather than a base table, it holds no data of its own and is intended purely for read access. It serves as a reporting and integration surface for maintenance planners, custom concurrent programs, and external systems that need to interrogate runtime-based PM scheduling without reconstructing the underlying joins manually. It is equally useful as a diagnostic tool when validating why a runtime-driven PM activity has or has not fired.

Underlying Base Objects

The view is defined over the following documented base objects: EAM_PM_SCHEDULING_RULES, EAM_METERS, EAM_PM_LAST_SERVICE, and EAM_PM_SCHEDULINGS. The documented view metadata for 12.2.2 also lists CSI_COUNTERS_B, CSI_COUNTERS_TL, CSI_COUNTER_TEMPLATE_B, CSI_COUNTER_TEMPLATE_TL, and the EAM_METERS_UTIL package as referenced objects, reflecting the meter and counter infrastructure that EAM leverages from the Install Base schema. The EAM tables are exposed to APPS through synonyms.

The view text is a UNION of two queries. The first joins the PM scheduling rule to its PM schedule, activity association, and last-service record, and then to the meter, filtering on the meter's effective date range using NVL(FROM_EFFECTIVE_DATE, SYSDATE-1) and NVL(TO_EFFECTIVE_DATE, SYSDATE+1). The second query handles schedule templates (EPS.TMPL_FLAG = 'Y'); it has no activity association at this stage and therefore returns TO_NUMBER(NULL) in the LAST_SERVICE_READING position. Both branches apply the same effective-dating predicate, so only currently effective meters are returned.

Key Columns

Common Use Cases and Queries

Typical uses include auditing runtime-based PM setup, calculating remaining usage before the next service, and feeding external condition-monitoring systems. Because the view already resolves the meter and last-service joins, queries are concise. A representative example listing active runtime rules with remaining interval:

  • SELECT pm_schedule_id, activity_association_id, meter_name, runtime_interval, last_service_reading FROM apps.eam_runtime_interval_v WHERE rule_type = 'RUNTIME';
  • SELECT meter_name, runtime_interval - (current_reading - last_service_reading) remaining FROM apps.eam_runtime_interval_v WHERE activity_association_id = :activity_association_id;
  • SELECT rule_id, pm_schedule_id, meter_name, runtime_interval, last_service_reading FROM apps.eam_runtime_interval_v ORDER BY pm_schedule_id, meter_name;

Consumers should account for the UNION behavior: rows without an activity association are template rows and return a null LAST_SERVICE_READING, so any arithmetic on that column must tolerate nulls. Filtering on the documented columns keeps queries on supported, effective-dated data.