OEE · RAM · EMS 자주 묻는 질문
OEE·RAM·EMS 는 규칙이 많습니다. 이 페이지는 현장에서 자주 헷갈리는 것만 질문과 짧은 답으로 모았습니다. 화면 사용법은 ISO 데이터 및 분석 (OEE / RAM / EMS), 워크오더는 생산 관리 를 보세요.
2026.10 출하본 기준입니다. 숫자를 정하는 규칙은 플랫폼 코어가 정본이며, 이 페이지는 그것을 사람 말로 옮긴 것입니다.
한눈에
| 지표 | 무엇을 보나 | 무엇으로 세나 | 언제 계산하나 |
|---|---|---|---|
| OEE | 설비가 계획 시간을 얼마나 잘 썼나 | 설비 상태(RUN·STOP·FAULT…) · 생산 수량 | 진행 중인 워크오더가 있을 때만 |
| RAM | 얼마나 자주 고장 나고 얼마나 빨리 고치나 | 고장 신호 · 사람이 «설비 원인» 으로 분류한 정지 | 워크오더 · 기간 단위 |
| EMS | 에너지를 얼마나 쓰고 CO2 를 얼마나 냈나 | 전력량계 kWh · 연료 사용량 | 진행 중인 워크오더가 있을 때만 |
1. 플러그인은 모든 설비에 꼭 넣어야 하나요?
아니요. 설비마다 고릅니다. OEE·RAM·EMS 는 설비에 붙이는 선택 플러그인입니다. 팩토리 관리의 에셋 화면에서 설비를 고르고 레지스트리 탭의 [ISO 플러그인] 으로 붙입니다.
붙일 때 대화상자의 감시할 태그 칸에서 템플릿마다 태그를 고릅니다. 태그가 필요한 줄을 비워 두면 적용되지 않습니다.
템플릿은 태그 ID 에 _CODE · _CAUSE 를 붙여 다른 태그를 찾지 않으므로, 코드가 든 템플릿은 그 태그를 직접 고릅니다.
RAM_FAILURE_CODE_TAG— 신호 태그가 아니라 고장 코드 태그를 고릅니다.OEE_CODED의OEE_PRODUCT_BAD_COUNT_CODED— 줄이 하나 더 나옵니다. 거기서 불량 원인 태그를 고릅니다.
이미 설비에 붙인 스테이트먼트는 템플릿이 바뀌어도 문장이 그대로입니다.
- 플러그인이 없는 설비는 화면에 «미적용» 으로 나옵니다. 0 이나 오류가 아닙니다.
- 설비 대시보드: «이 설비에 OEE(RAM·EMS) 플러그인이 없습니다 — 설비 플러그인 화면에서 적용하면 여기에 나옵니다»
- RAM 카드: «RAM 미적용 (RAM 플러그인 없음)»
- 라인·영역·사이트의 RAM 합계에는 플러그인이 있는 설비만 들어갑니다. 플러그인 없는 설비의 운전 시간이 MTBF 를 늘리지 않습니다.
- 플러그인을 붙이라고 자동으로 권하지는 않습니다.
RAM 은 응답에 ram_plugin 이 실립니다 — APPLIED(적용) · NOT_APPLIED(미적용, 숫자 칸은 null) ·
REMOVED(뗐지만 그 기간에 고장 기록이 있음). NOT_APPLIED 를 0 으로 바꿔 읽지 마세요 — «고장 0건» 과
«재지 않음» 은 다릅니다.
2. RAM 은 무엇을 «고장 한 건» 으로 세나요?
설비마다, 기간마다 아래 순서로 정합니다.
| 순서 | 규칙 | 결과 |
|---|---|---|
| ① | 고장 신호가 0→1 이 되면 고장 시작, 1→0 이 되면 수리 끝 | 고장 한 건 · 수리 시간 = 끝 − 시작 |
| ② | 그 고장의 원인이 자재·공정·작업자·품질·외부 로 분류돼 있으면 | 세지 않습니다 — 설비 고장이 아닙니다 |
| ③ | 계획 정지 중에 고장 신호가 1 이 되면 | 고장이 아닙니다. 계획 정지가 끝났는데도 1 이면 그 끝부터 고장입니다 |
| ④ | 고장 중에 신호가 끊기면(3분 넘게 값이 안 옴) | 수리 시간을 마지막 신호에서 멈춥니다. 고장은 열린 채로 둡니다 |
| ⑤ | 사람이 정지 사유를 설비 원인으로 고른 정지 | 고장으로 셉니다 |
| ⑥ | ①의 신호 고장과 ⑤의 정지가 시간이 겹치면 | 한 건으로 합칩니다(가장 이른 시작 ~ 가장 늦은 끝). 맞닿기만 하면 두 건입니다 |
그 밖에 알아 둘 것:
- OEE 의 FAULT 상태는 RAM 에 넣지 않습니다. 같은 고장을 두 번 세지 않기 위해서입니다. 화면이 «자동» 으로 제안한 사유도 넣지 않고, 사람이 저장한 분류만 넣습니다.
- 알람은 고장을 만들지 않습니다. 알람은 이미 열린 고장에 «연결» 될 뿐입니다.
- 옛 고장 코드(
BEARING·MOTOR… 11개)는 대응표로 사전 원인으로 읽습니다(7번 질문). - 플러그인을 떼어도 그 기간에 고장 기록이 있으면 과거 고장은 보입니다(
REMOVED). - 운전 시간은 OEE 의 RUN 시간을 씁니다. MTBF·MTTR 은 이 건수와 시간으로 계산합니다.
3. 계획 정지와 고장이 겹치면요? 정지 사유는 누가 정하나요?
계획 정지가 이깁니다.
- RAM: 계획 정지 중의 고장 신호는 고장이 아닙니다. 계획 정지가 끝난 뒤에도 신호가 남아 있으면 그때부터 고장입니다(2번 ③).
- OEE: 설비가 계획 정지에 들어가면 계획 시작 신호가 올 때까지 다른 상태(RUN·FAULT·STOP…)를 받지 않습니다. 그 시간은 계획 정지로만 남습니다.
정지 사유는 사람이 고릅니다. 워크오더 상세의 정지 사유 카드에서 정지 한 건마다 원인 하나를 한 번 클릭으로 고릅니다.
- 사람은 원인 하나만 고르면 됩니다. 그 원인이 어떤 고장 모드·메커니즘·부위에 해당하는지는 사전이 압니다(7번 질문).
- 아무도 고르지 않은 정지는 «모름» 으로 남습니다. 플랫폼이 제안한 사유는 회색 «자동» 배지로 보일 뿐, RAM 에는 들어가지 않습니다.
- 메뉴는 정지 상태에 맞춰 순서가 바뀝니다 — 계획 정지면 계획정지 유형이, 고장(FAULT)이면 설비 원인이 먼저 나옵니다.
2026.10 의 원인 사전 이름은 영어뿐입니다(예: «Bearing wear», «Recipe error»). 계획정지 유형(유지보수·식사 등)은 한국어입니다.
4. OEE 는 어떻게 계산하나요?
OEE = 가동률 × 성능 × 품질 이고, 각 값은 0~100% 로 자릅니다.
| 요소 | 식 | 뜻 |
|---|---|---|
| 가동률 | RUN 시간 ÷ 계획 생산 시간 | 계획한 시간 중 실제로 돈 비율 |
| 성능 | (이상 사이클 시간 × 총 생산 수) ÷ RUN 시간 | 도는 동안 얼마나 빨랐나. 이상 사이클 시간은 워크오더의 «단위 생산 시간» |
| 품질 | 양품 수 ÷ 총 생산 수 | 만든 것 중 양품 비율 |
계획 생산 시간에서 빠지는 것:
- 셋업·계획 정지·계획 시작 시간
- 작업자가 워크오더를 일시중지한 시간 — 설비가 잃은 시간이 아니기 때문입니다
- 설비에 교대 패턴이 있으면 교대 밖 시간, 휴일, 취소된 교대, 휴식, 사람이 등록한 계획 정지도 뺍니다. 계획 생산 시간 = 교대 시간 − 계획 휴식입니다. 패턴이 없는 설비는 워크오더 시간 그대로 씁니다.
계획 정지로 잡히는 근무표 유형은 지금 휴식·식사(그 사이트 설비 전부)와 유지보수(그 설비만)입니다. 품목교체·교정·청소·공구교환·휴일은 근무표에 등록해도 OEE 계획 정지로 잡히지 않습니다(교대 패턴이 있는 설비는 위처럼 계획 시간에서 빠집니다).
워크오더가 없으면 OEE 를 계산하지 않습니다. OEE 는 «워크오더의 계획 시간» 에 대한 비율이라, 진행 중인 워크오더가 없는 시간은 OEE 에 들어가지 않습니다. 기간 OEE(분석 화면)는 기간과 겹친 워크오더들을 겹친 비율만큼 합쳐 계산합니다.
5. EMS 에너지는 워크오더·설비에 어떻게 붙나요?
- 설비 단위로 쌓입니다. EMS 플러그인이 있는 설비의 전력량계(kWh)·연료 유량이 그 설비의 에너지 기록으로 저장됩니다.
- 워크오더에는 시작 시각부터 붙습니다. 진행 중인 워크오더가 있으면 그 워크오더 시작 ~ 지금의 사용량으로 지표를 계산합니다. 진행 중인 워크오더가 없는 시간의 사용량은 기록만 남고 워크오더 지표에는 들어가지 않습니다.
- 라인·영역·사이트는 설비 값을 모읍니다 — 에너지·CO2·운전 시간은 합, 평균 전력·효율은 평균, 피크 전력은 최대입니다.
| 지표 | 식 |
|---|---|
| 단위 생산당 에너지 | 총 에너지(kWh) ÷ 양품 수 |
| CO2 (전력, Scope 2) | kWh × 0.4594 kg/kWh |
| CO2 (연료, Scope 1) | LNG m³ × 2.176 · 경유 L × 2.601 · LPG L × 1.536 · 휘발유 L × 2.168 |
| 에너지 효율 | 평균 전력 ÷ 피크 전력 (부하율) |
6. 규칙이 바뀌면 지난 기간도 다시 계산되나요?
아니요. 규칙 변경은 그 뒤에 일어난 사건부터 적용합니다.
- 이미 계산해 저장한 워크오더 결과(끝난 워크오더, 이력)는 다시 계산하지 않습니다. 예: «자재·공정 원인 고장은 빼기»(2번 ②)는 앞으로만 적용합니다.
- RAM 플러그인이 없는 설비에 예전에 0 으로 쓰인 RAM 행은 지우지 않고 그대로 둡니다.
- 교대 패턴·예외를 바꾸면 저장한 시각 이후의 계획만 다시 만듭니다. 지난 계획은 바뀌지 않습니다.
- 옛 고장 코드를 사전 원인으로 읽는 것도 켠 시각 이후의 사건에만 적용합니다(관리자 설정
PP_RAM_LEGACY_FAULT_CODE_FROM, 비우면 «지금부터»).
그래서 같은 기간을 규칙 변경 전후에 보면 숫자가 다를 수 있습니다 — 지난 숫자가 틀린 것이 아니라 그때의 규칙으로 센 것입니다.
7. 고장 원인 사전과 옛 코드는 어떤 관계인가요?
원인 사전은 고장 원인의 목록이고, 원인 하나가 ISO 14224 의 네 축을 묶어 가지고 있습니다. 축은 원인마다 채워진 만큼만 있습니다(비어 있는 칸은 «—»).
| 축 | 뜻 | 예 (원인 BEARING_WEAR 일 때) |
|---|---|---|
| 고장 모드 | 어떻게 드러났나 | 진동 (VIB) |
| 고장 메커니즘 | 무엇이 일어났나 | 마모 (MECH_WEAR) |
| 고장 원인 | 왜 일어났나 | — |
| 정비 부위 | 어디를 고치나 | — |
- 출하 사전은 38개입니다 — 설비 32 · 공정 2 · 자재 2 · 작업자 2. 품질·외부 범주는 있지만 출하 항목은 없습니다.
- 사람은 원인 하나만 고르고, 축은 사전이 채웁니다(3번 질문).
- 옛 고장 코드 11개는 대응표로 사전 원인에 연결됩니다.
| 옛 코드 | 사전 원인 |
|---|---|
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 (유압유·압축공기 = 유틸리티 매체 누설) |
- 장치가 내는 원래 코드(
E102,ALM_0457등)는 고장 코드 매핑표로 원인 하나에 연결합니다. 출하 때는 비어 있고 운영자가 API 로 등록합니다. 매핑은 그 설비 → 자산 클래스 → 장비 클래스 → 옛 코드표 순서로 찾고, 먼저 찾은 것을 씁니다. - 사전의 ISO 축은 공개 2차 자료로 만들었고 ISO 원문과 대조하지는 않았습니다.
관련 문서
- ISO 데이터 및 분석 (OEE / RAM / EMS) — 화면 사용법과 지표 정의
- 생산 관리 — 워크오더 · 근무표
- 팩토리 관리 — 에셋 화면 — 설비에 ISO 플러그인 붙이기
- 상태 코드 정의 — 설비 상태(RUN·STOP·FAULT…)