IoTをMES、ERP、CMMSと連携すべきタイミングと、アラートを作業指示にすべきタイミング
DBR77 Team · 公開日
IoTの連携は、設備の状態と停止理由が数週間安定してから、まずCMMSと行い、次にMES、最後にERPと行います。アラートを作業指示にするのは、部品や計画が必要な場合、繰り返し発生する場合、または設定した制限時間を超える場合だけです。それ以外は、シフト内の簡単なタスクとして処理します。
連携が早すぎると、信頼できないデータを三つのシステムにコピーすることになります。遅すぎると、保全担当者は停止を手で入力し続けます。以下では、たいていうまくいく順序、切り離しておくべきもの、作業指示のルールを説明します。
IoTはMES、ERP、CMMSに対してどこに位置するか
ISA-95規格は便利な地図になります。この規格は、各レベルで行われる活動によって工場をレベルに分けています。レベル3は製造オペレーションで、MESなどのシステムが生産を管理します。レベル4は事業運営で、ERPが位置します。ISA-95は主にレベル3とレベル4の間のインターフェースを扱います。
設備、PLC、センサーはその下のレベル0〜2にあります。IoTはそれらを読み取り、生の信号を事象に変換します。稼働、停止、停止理由、個数などです。ほとんどの工場では、CMMSはオペレーションのレベルでMESの隣に位置し、そこで保全作業が計画されます。IoTは信頼できる事象を上位に送るものであり、上位のシステムを置き換えるものではありません。
数週間待つことが報われる理由
ラインにIoTを入れた最初の数週間はノイズが多くなります。理由リストは変わり、閾値は調整されます。2週目にERPをつなぐと、修正のたびに二か所を直さなければなりません。この安定化期間については、記事既存設備の工場におけるIoT導入の最初の30日間で説明しています。
次の条件がそろえば、ラインは連携の準備ができています。
- 生産と保全が、稼働、停止、計画停止について同じ定義を使っている。
- 理由リストが2〜3週間変わっていない。
- 「不明」が少ない。たとえば停止時間の10%未満。
- すべてのアラートに担当者がいて、確認までの時間も決まっている。
- IT/OTがインターフェースとセキュリティモデルに合意している。通常はISA/IEC 62443を参照します。
たいていうまくいく連携の順序
CMMSから始めます。最も少ない項目（設備、故障、時刻、担当者）で、最も多くの手作業を減らせます。次はMESです。IoTからの個数とリアルタイムOEEがラインの実際の生産量と一致すれば、指図ごとの手入力を置き換えられます。ERPは最後です。ERPには集計済みで締められた記録が必要で、それはラインのデータが安定して初めて存在します。
| システム | IoTが送るもの | 連携のタイミング | 典型的なトリガー |
|---|---|---|---|
| CMMS | 故障イベント、稼働時間、サイクル数、状態値 | 最初。アラートの経路と理由が安定したら | 制限時間を超える停止、繰り返す故障、カウンターが点検周期に到達 |
| MES | 設備状態、良品数と不良数、停止理由、リアルタイムOEE | 2番目。IoTの個数がラインの実際の生産量と一致してから | 指図の開始と終了、段取り替え、指図ごとの個数 |
| HSE | カメラやセンサーからのヒヤリハットイベント | 安全チームが区分を定義したとき | 立入制限区域への人の侵入、運転中の安全カバー開放 |
| ERP | 集計した生産量、設備の稼働時間、消費量 | 最後。MESやCMMSが締めた記録を持ってから | 指図またはシフトの締め、月次の設備原価計算 |
連携すべきものと切り離しておくべきもの
役に立つ切り分け方は次のとおりです。
- 設備リストは一つに統合する。 設備IDはIoT、CMMS、MESで同じでなければなりません。
- 作業指示の発行と完了を連携する。 作業指示が完了したら、IoTの停止記録にその番号が残るようにします。
- 指図ごとの個数をMESと連携する。 信頼できるようになってからです。
- 生の信号はエッジに置いておく。 高頻度の電流値や振動値はIoTにとどめ、ERPには集計値だけを送ります。
- チョコ停と理由の選択はIoTに置いておく。 頻繁に変わるものなので、ERPのリリースを待つべきではありません。
オープンなインターフェースを使ってください。設備側はOPC UAとMQTT、業務側は通常REST APIでカバーできます。McKinseyは企業に対し、相互運用性を購買基準として明記するよう助言しています。対応しているコネクターは連携のページに掲載しています。
アラートを作業指示にすべきとき
Vorneは、チョコ停は通常1〜2分で、保全担当者なしで解消されると指摘しています。そのすべてをCMMSの記録にすると、計画担当者はチケットに埋もれてしまいます。
次のうち少なくとも一つに当てはまる場合、アラートから作業指示を発行します。
- 部品や資材が必要。 発注またはピッキングが必要なもの。
- 計画が必要。 停止時間帯、外部業者、作業許可、別シフトなど。
- 繰り返す。 たとえば1台の設備で7日間に同じ故障が3回。
- 設定した制限時間を超える。 たとえば20分を超える停止。
- 正式な記録が必要。 安全、品質、監査のため。
それ以外はすべて、シフト内の簡単なタスクとして扱います。IoTの中で記録し、担当者を決め、時間を計り、完了させます。説明用の例として、一般的な2シフトの包装ラインで、3分で解消した詰まりは簡単なタスクです。同じ詰まりが1シフトに4回起きた場合は、ガイドレールを点検する作業指示を1件だけ発行します。制限値は保全と一緒に文書にし、毎月見直してください。
DBR77 IIoTとIRISでの仕組み
DBR77 IIoTでは、すべてのアラートが担当者付きのタスクになり、対応にはタイムスタンプが付きます。ある段ボール包装ラインでは、このルールにリアルタイムの状態表示と理由入力を組み合わせることで、停止への平均対応時間が24分から9分に短縮しました。この仕組みがないと何が起きるかは、設備のアラートが現場で機能しない理由で説明しています。
DBR77 IRISでは、設備やカメラのイベントが他のすべてと同じデータモデルに届きます。そこからCMMSの作業指示を発行したり、HSEのヒヤリハットを記録したり、OEEに反映したりでき、それぞれに個別のインターフェースは必要ありません。
整った状態と個数は、ラインのデジタルツインに送って、変更を現場に適用する前に試すこともできます。信号がその後どのように優先順位や計画を変えるかは、可視化からクローズドループの対応へで扱っています。
よくある質問
経理部門が先にERPのデータを求めています。そこから始めるべきですか？
通常は違います。ERPには締められた記録が必要で、それが信頼できるのはラインのデータが安定してからです。それまでは、IoTから週次でデータを出力して経理部門に渡してください。
IoTを始める前にMESが必要ですか？
いいえ。多くの中規模工場は、1ラインのIoTと既存のCMMSから始めています。MESが導入されるまでは、IoTがリアルタイムOEEと停止理由を提供できます。
CMMSがチケットであふれるのを防ぐにはどうすればよいですか？
上記の作業指示のルールを使い、毎月保全と一緒に見直してください。計画担当者が多くの作業指示を「対応不要」として閉じているなら、制限値が低すぎます。
どのようなインターフェースが必要ですか？
設備側はOPC UA、Modbus、またはMQTT、業務側は標準的なAPIです。セキュリティ審査では通常ISA/IEC 62443が参照され、処理は現地にとどめることができます。
まとめ
理由リストが最も長く変わっていないラインを選び、設備、故障、時刻、担当者の4項目だけでCMMSにつないでください。最初の作業指示が流れる前に、たとえば20分を超える停止や、7日間に同じ故障が3回といった制限値を保全と文書で決めておきます。1か月後、計画担当者が「対応不要」として閉じた作業指示の数を数え、その結果をもとに制限値を調整してください。
連携の順序を1回の打ち合わせで描く
CMMS、MES、ERPなど、お使いのシステムの一覧をお持ちください。30分で、どのデータをどこへ、どの順序で送るか、どのアラートルールから始めるかを描きます。
出典
- ISA, ISA-95 Standard: Enterprise-Control System Integration
- ISA, ISA/IEC 62443 series of standards
- OPC Foundation, OPC Unified Architecture, 2008
- OASIS, MQTT Version 5.0, 2019
- McKinsey & Company, IoT value set to accelerate through 2030, 2021
- Vorne, The Six Big Losses
- DBR77 IIoTパイロットデータ、段ボール包装ライン（顧客名非公開）、2026