モニタリング・OEE1 分で読める

現場で機械アラートが機能しない理由:誤報、エスカレーション、対応時間

DBR77 Team · 公開日

現場で機械アラートが機能しないのは、数が多すぎるとき、個人ではなくグループに送られるとき、そして発報後に何が起きたかを誰も追跡しないときです。各アラートが実際の事象であり、一人の担当者を持つタスクになり、文書化されたルールでエスカレーションされるようになれば、アラートは機能します。

ある段ボール包装ラインでは、停止から対応までの空白を埋めたことで、停止への平均対応時間が24分から9分に短縮しました。

現場で機械アラートが機能しない理由:誤報、エスカレーション、対応時間

24分の内訳

変更前、停止は見慣れた経路をたどっていました。機械が止まると、誰かがいずれ気づいて班長を探しに歩き、班長が保全に無線で連絡します。保全担当者は、何がどこで止まったのかを確認しなければなりません。

その時間の大部分は、機械が止まったことを誰かが知るまでに費やされていました。変更後は次のとおりです。

  1. 停止が起きた瞬間に、アラートが発生します。
  2. アラートは、機械、時刻、理由が添付された、現在のシフトの担当者付きタスクになります。
  3. 対応はシステムで追跡されます。いつ確認されたか、いつ作業を始めたか、いつ機械が再稼働したかが記録されます。

短縮できた15分は、停止をより早く把握できたことによるもので、修理そのものにかかる時間は変わりませんでした。したがって、力を注ぐべきは、停止から適切な担当者がそれを知るまでの遅れを縮めることです。このパイロットについてはリアルタイムデータでダウンタイムを減らす方法で詳しく紹介しています。

DBR77プラットフォームのスクリーンショット:IoTアラームとアラームルールDBR77プラットフォームのスクリーンショット:IoTアラームとアラームルール
DBR77プラットフォームの画面:IoTアラームとアラームルール(デモ工場のデータ)

アラートが無視される理由

機械アラートを導入した工場は、しばしばノイズに悩まされます。シフト中ずっと携帯が鳴り続け、ほとんどのアラートは対処を必要としません。1週間もすると、人はもう見なくなります。

プロセス産業の制御室では、こうした問題は以前から知られていました。エネルギー協会は、アラームをオペレーターの注意と対応を必要とする問題を示す信号と定義しています。同協会の解説書は、EEMUAの推奨である「平均して約10分に1件」という水準と、オペレーターが1分に1件に直面していた石油化学工場の事例を引用しています。

アラーム管理の規格は、この考え方を体系化しています。ANSI/ISA-18.2は、基本方針の策定、合理化から監視・監査に至るまで、アラームをライフサイクルとして管理します。ISAは、バッチ・個別生産プロセス向けの技術報告書も発行しており、迷惑アラームの削減を目的としています。もう一つの広く使われている指針はEEMUA 191です。同じ原則は現場にも当てはまり、対応を必要としないアラートは削除すべきです。

よくあるアラートの問題と対策

個別生産ラインのアラートの失敗は、いくつかの原因に集約されます。以下の閾値は目安です。お使いの機械に合わせて調整してください。

アラートの問題 原因 対策
自然に復旧した停止でもアラートが出る 最低停止時間が設定されていない 例えば2分を超えた停止のみアラートを出す(デバウンス処理)
同じ停止のアラートが何度も出る 信号が稼働と停止の間で不安定に切り替わる 状態が再度変わるまで保持時間を設ける
1つの問題に5件のアラートが出る 上流の停止により後工程が飢餓または閉塞になる ラインごとにアラートをまとめ、根本となる停止のみを通知する
休憩中や段取り替え中にもアラートが出る 計画停止がシステムに登録されていない シフトカレンダーと計画停止でアラートを抑制する
誰も見ないアラート グループや共有画面に送られている 役割ごとに、現在のシフトの担当者を一人決める
担当者が何を持っていけばよいか分からないまま現場に来る アラートが「機械停止」としか示さない アラートに機械、場所、停止時間、オペレーターの理由を記載する

短時間の停止には特別な注意が必要です。Vorneは軽微な停止を5分未満で、保全を必要としないものと説明しています。件数を数えて毎日確認し、1件ごとに技術者を呼び出すことはしないでください。

アラートが担当者付きのタスクになる仕組みを見る

30分のデモでは、実際のラインの設定で、DBR77 IIoTにおける稼働状況のリアルタイム表示、停止理由の記録、アラートの振り分けとエスカレーションをご紹介します。

デモを予約する

有効なエスカレーションルール

エスカレーションのルールがなければ、確認されないアラートはそのまま放置されます。以下は、開始点として使える設定例です(閾値は説明用の値です)。

  • 5分以内に確認されない場合: 班長にアラートを送ります。
  • 確認されたものの、20分経っても機械が停止したままの場合: 保全リーダーに連絡します。
  • ボトルネックの機械が30分を超えて停止した場合: シフト計画が危うくなるため、生産マネージャーに連絡します。
  • 同じ停止理由が1シフト中に3回発生した場合: 翌日の見直しのためのフォローアップタスクを作成します。

担当者だけでは判断できない決定が必要な場合は、上司にエスカレーションします。たとえば、人員の移動、計画の変更、外部業者の手配などです。担当者が通常の修理時間内にすでに対応中であれば、エスカレーションは不要です。ルールは稼働開始の前に文書化してください。

すべてのアラートをタスクにする

何かが起きたことを伝えるだけの通知とは異なり、タスクには担当者、ステータス、完了時刻があります。包装ラインで対応時間を短縮したのは、アラートをタスクに変えたことでした。

DBR77 IIoTでは、オペレーターが設備の前で約2秒で停止理由を選択すると、アラートがオペレーターアプリのタスクとして担当者に届きます。確認と完了はタイムスタンプで記録されます。次のステップを求める工場には、IRISが検知から、割り当てられた対応とフォローアップまで、ループをさらに閉じます。

アラートにはコンテキストも必要です。段取り替え中の停止と、稼働中の停止は意味が違います。この点は、機械データは文脈がなければ役に立たない理由を扱った記事で詳しく説明しています。すでにCMMSを運用しているなら、アラートから作業指示書を作るかどうかは後で判断してください。IoTをMES、ERP、CMMSと連携するタイミングをご覧ください。

アラートが機能しているかを確認する方法

班長と毎週、次の数値を確認してください。

  • シフトごと・担当者ごとのアラート件数。 一人が何十件も受け取っている場合は、閾値や一括化の見直しが必要です。
  • 5分以内に確認されたアラートの割合。 この割合が下がるのは、疲労の最初の兆候です。
  • 停止への平均対応時間。 これが成果を示し、ほかの3つの数値がその理由を説明します。
  • 対応なしで閉じられたアラート。 1件ごとに削除の候補になります。

Siemensは、世界の売上上位500社が計画外のダウンタイムにより年間売上の約11%を失っていると試算しています。停止から適切な人が把握するまでの数分間は、この損失の中で最も安く取り除ける部分です。

よくある質問

シフトあたり何件のアラートが多すぎますか?

現場に共通の数値はありません。制御室のガイドラインでは、10分に約1件を基準としています。担当者が対応できる速度より速くアラートが来るなら、まず閾値と一括化を調整してください。

どのくらいの停止時間でアラートを出すべきですか?

機械の通常の微小停止に応じて、1〜3分から始めてください。それより短い停止も記録し、毎日確認すべきですが、誰かを呼び出す必要はありません。

アラートはグループチャットや共有画面に送ってもよいですか?

周知のためなら構いません。しかし、担当者は別の問題です。すべてのアラートには、現在のシフトの担当者を一人、名指しで決める必要があります。そうしないと、誰もが他の誰かが対応すると考えてしまいます。

オペレーターはすべての停止で理由を入力する必要がありますか?

アラートの閾値を超える停止については、はい。約2秒で済み、シフト終わりのメモよりずっと確実です。

CMMSと連携しなくてもアラートは機能しますか?

はい。担当者付きタスクとしてのアラートだけで、対応時間の短縮効果は得られます。CMMSとの連携は後から進めることができます。

まとめ

新しいアラートを追加する前に、1つのラインを選び、上記の4つの数値を使って1週間分のアラートを班長と一緒に見直してください。対応なしで閉じられたアラートを見れば、最低停止時間や一括化が欠けている箇所が分かります。まずそこを直し、そのうえで残ったアラートのエスカレーションルールを文書化してください。

班長が信頼できるアラートを設定する

デモを予約してください。お使いのラインの一つについて、閾値、一括化、エスカレーションのルールを一緒に確認します。

デモを予約する

出典