OEE · RAM · EMS FAQ
OEE, RAM, and EMS have many rules. This page collects the most common points of confusion from the field into questions and short answers. For screen operations, see ISO Data and Analysis (OEE / RAM / EMS), and for work orders, see Production Management.
Based on the October 2026 release. The Platform core is the authoritative source for the rules defining the numbers; this page translates those rules into plain language.
At a Glance
| Metric | What is observed | How it is counted | When it is calculated |
|---|---|---|---|
| OEE | How well the equipment utilized planned time | Equipment state (RUN, STOP, FAULT…) · Production quantity | Only when there is an active work order |
| RAM | How often failures occur and how quickly they are repaired | Failure signals · Downtime classified by humans as «Equipment Cause» | By work order · By period |
| EMS | How much energy was used and how much CO2 was emitted | Power meter kWh · Fuel consumption | Only when there is an active work order |
1. Do plugins have to be added to all equipment?
No. You choose for each piece of equipment. OEE, RAM, and EMS are optional plugins attached to equipment. Select the equipment in the asset screen of Factory Management and attach them via the [ISO Plugin] in the Registry tab.
When attaching, select the tags for each template in the Tags to Monitor field of the dialog box. If a line requiring a tag is left blank, it will not be applied. Since the template does not search for other tags by appending _CODE · _CAUSE to the tag ID, you must select the tags directly for templates containing code.
RAM_FAILURE_CODE_TAG— Select the Failure Code tag, not the signal tag.OEE_PRODUCT_BAD_COUNT_CODEDofOEE_CODED— One additional line appears. Select the Defect Cause tag there.
Statements already attached to equipment remain unchanged even if the template changes.
- Equipment without a plugin is displayed as «Not Applied» on the screen. This is not 0 or an error.
- Equipment Dashboard: «OEE (RAM · EMS) plugin is not applied to this equipment — apply it in the equipment plugin screen to see it here»
- RAM Card: «RAM Not Applied (No RAM Plugin)»
- Only equipment with plugins is included in the RAM totals for lines, areas, or sites. Operating time of equipment without a plugin does not increase MTBF.
- The system does not automatically recommend attaching plugins.
RAM responses include ram_plugin — APPLIED (Applied) · NOT_APPLIED (Not Applied, numeric field is null) · REMOVED (Removed, but failure records exist for that period). Do not read NOT_APPLIED as 0 — «0 failures» and «not measured» are different.
2. What does RAM count as «one failure»?
For each piece of equipment and period, it is determined in the following order:
| Order | Rule | Result |
|---|---|---|
| ① | Failure starts when the failure signal goes 0→1, and repair ends when it goes 1→0 | One failure · Repair time = End − Start |
| ② | If the cause of that failure is classified as material, process, operator, quality, or external | Not counted — not an equipment failure |
| ③ | If the failure signal becomes 1 during planned downtime | Not a failure. If it remains 1 after planned downtime ends, it is a failure starting from that end time |
| ④ | If the signal is lost during a failure (no value for over 3 minutes) | Repair time stops at the last signal. The failure remains open |
| ⑤ | Downtime where a human selected the reason as equipment cause | Counted as a failure |
| ⑥ | If the signal failure in ① and the downtime in ⑤ overlap in time | Merged into one incident (earliest start ~ latest end). If they only touch, they are two incidents |
Other things to note:
- The FAULT state in OEE is not included in RAM to avoid double-counting the same failure. Reasons suggested «automatically» by the screen are also excluded; only classifications saved by humans are included.
- Alarms do not create failures. Alarms are simply «linked» to an already open failure.
- Old failure codes (
BEARING,MOTOR… 11 types) are read as dictionary causes via a mapping table (Question 7). - Even if a plugin is removed, past failures are visible if failure records exist for that period (
REMOVED). - Operating time uses the RUN time from OEE. MTBF and MTTR are calculated using these counts and times.
3. What if planned downtime and failure overlap? Who determines the downtime reason?
Planned downtime takes precedence.
- RAM: Failure signals during planned downtime are not failures. If the signal persists after planned downtime ends, it is a failure from that point (2-③).
- OEE: When equipment enters planned downtime, it does not accept other states (RUN, FAULT, STOP…) until a planned start signal is received. That time remains only as planned downtime.
Downtime reasons are selected by humans. In the Downtime Reason card of the work order details, select one cause for each downtime incident with a single click.
- Humans only need to select one cause. The dictionary knows which failure mode, mechanism, or part that cause corresponds to (Question 7).
- Downtime that no one selects remains as «Unknown». Reasons suggested by the Platform appear as a gray «Auto» badge and do not enter RAM.
- The menu order changes according to the downtime state — planned downtime types appear first for planned downtime, and equipment causes appear first for failures (FAULT).
In the 2026.10 cause dictionary, names are only in English (e.g., «Bearing wear», «Recipe error»). Planned downtime types (Maintenance, Meal, etc.) are in Korean.
4. How is OEE calculated?
OEE = Availability × Performance × Quality, and each value is clipped between 0~100%.
| Element | Formula | Meaning |
|---|---|---|
| Availability | RUN time ÷ Planned Production Time | Proportion of planned time actually spent producing |
| Performance | (Ideal Cycle Time × Total Production) ÷ RUN time | How fast it ran while operating. Ideal Cycle Time is the «Unit Production Time» of the work order |
| Quality | OK count ÷ Total Production | Proportion of good units among produced units |
Items excluded from Planned Production Time:
- Setup, planned downtime, and planned start times
- Time the operator paused the work order — as this is not time lost by the equipment
- If the equipment has a Shift Pattern, off-shift time, holidays, cancelled shifts, breaks, and human-registered planned downtime are also excluded. Planned Production Time = Shift Time − Planned Breaks. Equipment without a pattern uses the work order time as is.
Work schedule types captured as planned downtime currently include Break/Meal (all equipment at that site) and Maintenance (only that equipment). Product changeover, calibration, cleaning, tool exchange, and holidays are not captured as OEE planned downtime even if registered in the work schedule (though they are excluded from planned time for equipment with shift patterns).
OEE is not calculated if there is no work order. Since OEE is a ratio against «work order planned time», time without an active work order is not included in OEE. Period OEE (analysis screen) is calculated by summing work orders that overlap the period by their overlapping proportions.
5. How is EMS energy linked to work orders and equipment?
- Accumulated by equipment unit. Power meter (kWh) and fuel flow of equipment with the EMS plugin are stored as that equipment's energy records.
- Linked to work orders from the start time. If there is an active work order, indicators are calculated based on consumption from work order start ~ now. Consumption during time without an active work order is recorded but not included in work order indicators.
- Lines, areas, and sites aggregate equipment values — energy, CO2, and operating time are summed, average power and efficiency are averaged, and peak power is the maximum.
| Indicator | Formula |
|---|---|
| Energy per Unit Production | Total Energy (kWh) ÷ OK count |
| CO2 (Power, Scope 2) | kWh × 0.4594 kg/kWh |
| CO2 (Fuel, Scope 1) | LNG m³ × 2.176 · Diesel L × 2.601 · LPG L × 1.536 · Gasoline L × 2.168 |
| Energy Efficiency | Average Power ÷ Peak Power (Load Factor) |
6. If rules change, are past periods recalculated?
No. Rule changes apply only to events occurring after the change.
- Work order results already calculated and stored (completed work orders, history) are not recalculated. Example: «Exclude failures caused by material/process» (2-②) applies only forward.
- RAM rows previously written as 0 for equipment without a RAM plugin are kept as is, not deleted.
- If shift patterns or exceptions are changed, only plans after the saved time are recreated. Past plans remain unchanged.
- Reading old failure codes as dictionary causes also applies only to events after the activation time (Admin setting
PP_RAM_LEGACY_FAULT_CODE_FROM; if empty, «from now»).
Therefore, numbers for the same period may differ before and after a rule change — the past numbers were not wrong, but were counted according to the rules of that time.
7. What is the relationship between the cause dictionary and old codes?
The Cause Dictionary is a list of failure causes, and each cause groups the four axes of ISO 14224. Axes are filled only as far as applicable for each cause (empty fields are «—»).
| Axis | Meaning | Example (when cause is BEARING_WEAR) |
|---|---|---|
| Failure Mode | How it manifested | Vibration (VIB) |
| Failure Mechanism | What happened | Wear (MECH_WEAR) |
| Failure Cause | Why it happened | — |
| Maintenance Part | Where to repair | — |
- The shipping dictionary contains 38 items — Equipment 32 · Process 2 · Material 2 · Operator 2. Quality and External categories exist, but there are no shipping items.
- Humans select one cause, and the dictionary fills the axes (Question 3).
- 11 old failure codes are linked to dictionary causes via a mapping table.
| Old Code | Dictionary Cause |
|---|---|
BEARING | BEARING_WEAR |
MOTOR | MOTOR_BREAKDOWN |
SENSOR | SENSOR_FAULTY_SIGNAL |
ELECTRICAL | ELECTRICAL_FAILURE |
MECHANICAL | MECHANICAL_FAILURE |
OVERLOAD | OVERLOAD |
OVERHEAT | OVERHEATING |
SOFTWARE | SOFTWARE_FAILURE |
UNKNOWN | UNKNOWN_EQUIPMENT_FAILURE |
HYDRAULIC · PNEUMATIC | SEAL_LEAK_UTILITY (Hydraulic Oil · Compressed Air = Utility Medium Leak) |
- Original codes produced by the device (
E102,ALM_0457, etc.) are linked to one cause via the Failure Code Mapping Table. This is empty upon shipping and is registered by the operator via API. Mapping is searched in the order of Equipment → Asset Class → Equipment Class → Old Code Table, and the first match is used. - The ISO axes in the dictionary were created using public secondary sources and were not cross-referenced with original ISO texts.
Related Documents
- ISO Data and Analysis (OEE / RAM / EMS) — Screen usage and indicator definitions
- Production Management — Work orders · Work schedules
- Factory Management — Asset Screen — Attaching ISO plugins to equipment
- Status Code Definition — Equipment states (RUN, STOP, FAULT…)