メインコンテンツまでスキップ

OEE · RAM · EMS よくあるご質問

OEE・RAM・EMS には多くのルールがあります。このページでは、現場で間違いやすい点だけを質問と短い回答としてまとめました。画面の使用方法は ISOデータおよび分析 (OEE / RAM / EMS)、ワークオーダーについては 生産管理 を参照してください。

基準版

2026.10 出荷版基準です。数値を決定するルールは Platform コアが正本であり、このページはそれを分かりやすく説明したものです。

一覧​

指標確認内容計測方法計算タイミング
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 を増加させることはありません。
  • プラグインの適用を自動的に推奨することはありません。
APIで確認する場合

RAM はレスポンスに ram_plugin が含まれます — APPLIED(適用) · NOT_APPLIED(未適用、数値欄は null) · REMOVED(解除したがその期間に故障記録あり)。NOT_APPLIED を 0 として読み替えないでください — «故障0件» と «計測なし» は異なります。

2. RAM は何を «故障1件» としてカウントしますか？​

設備および期間ごとに、以下の順序で決定します。

順序ルール結果
①故障信号が 0→1 になると故障開始、1→0 になると修理完了故障1件 · 修理時間 = 完了 − 開始
②その故障の原因が 資材・工程・作業員・品質・外部 に分類されている場合カウントしません — 設備故障ではないため
③計画停止中に故障信号が 1 になった場合故障とは見なしません。計画停止終了後も 1 であれば、その終了時から故障となります
④故障中に信号が途切れた場合(3分以上値が届かない)修理時間を最後の信号時点で停止させます。 故障はオープン状態のままにします
⑤人が停止事由を設備原因として選択した停止故障としてカウントします
⑥①の信号故障と ⑤の停止が時間を重複している場合1件として統合します(最も早い開始 ～ 最も遅い完了)。接しているだけの場合は2件となります

その他の注意事項:

  • OEE の FAULT 状態は RAM に含めません。 同じ故障を二重にカウントすることを防ぐためです。 画面が «自動» で提案した事由も含めず、人が保存した分類のみを計上します。
  • アラームは故障を生成しません。 アラームは既にオープンしている故障に «接続» されるだけです。
  • 旧故障コード(BEARING·MOTOR… 11種類)は、対応表を用いて辞書原因として読み取ります(質問7)。
  • プラグインを解除しても、その期間に故障記録があれば過去の故障は表示されます(REMOVED)。
  • 運転時間は OEE の RUN 時間を使用します。MTBF・MTTR はこの件数と時間で計算します。

3. 計画停止と故障が重複した場合はどうなりますか？停止事由は誰が決定しますか？​

計画停止が優先されます。

  • RAM: 計画停止中の故障信号は故障として扱いません。計画停止終了後も信号が残っている場合、その時点から故障となります(2番 ③)。
  • OEE: 設備が計画停止に入ると、計画開始信号が来るまで他の状態(RUN·FAULT·STOP…)を受信しません。 その時間は計画停止としてのみ記録されます。

停止事由は人が選択します。 ワークオーダー詳細の 停止事由 カードにて、停止1件ごとに原因を一つ、ワンクリックで選択します。

  • 人は原因を一つだけ選択します。その原因がどの故障モード・メカニズム・部位に該当するかは辞書が判別します(質問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 の4軸をまとめて保持しています。軸は原因ごとに記入されている分だけ存在し、空欄は «—» となります。

軸意味例 (原因 BEARING_WEAR の場合)
故障モードどのように現れたか振動 (VIB)
故障メカニズム何が起きたか摩耗 (MECH_WEAR)
故障原因なぜ起きたか—
整備部位どこを修理するか—
  • 出荷辞書は 38種類 です — 設備 32 · 工程 2 · 資材 2 · 作業員 2。品質・外部カテゴリは存在しますが、出荷項目はありません。
  • 人は原因を一つだけ選択し、軸は辞書が補完します(質問3)。
  • 旧故障コード11種類は、対応表を通じて辞書原因に紐付けられます。
旧コード辞書原因
BEARINGBEARING_WEAR
MOTORMOTOR_BREAKDOWN
SENSORSENSOR_FAULTY_SIGNAL
ELECTRICALELECTRICAL_FAILURE
MECHANICALMECHANICAL_FAILURE
OVERLOADOVERLOAD
OVERHEATOVERHEATING
SOFTWARESOFTWARE_FAILURE
UNKNOWNUNKNOWN_EQUIPMENT_FAILURE
HYDRAULIC · PNEUMATICSEAL_LEAK_UTILITY (油圧油・圧縮空気 = ユーティリティ媒体漏洩)
  • 装置が出力する元コード(E102, ALM_0457 など)は、故障コードマッピング表で一つの原因に紐付けます。 出荷時は空欄となっており、運用者が API で登録します。マッピングは その設備 → アセットクラス → 設備クラス → 旧コード表 の順に探索し、最初に見つかったものを適用します。
  • 辞書の ISO 軸は公開二次資料に基づいて作成されており、ISO 原文との照合は行っていません。

関連ドキュメント​