保全管理システム(CMMS)

典型的な入力データは、META Smart I/Oデバイスまたは既存のPLCからのセンサーデータで、振動、温度、電流、サイクルカウントなどです。

はい、作業指示、チェックリスト、機械履歴はスマートフォン、タブレット、MSFパネルで利用できます。

はい。MESに記録された停止理由から、保全通知が自動的に作成されます。

日付基準・カウンター基準の予防保全計画、作業指示、スペアパーツの引当、機械履歴は、すべて記録だけで回りますので、センサー入力は一切不要です。最初の数か月で故障コード、計画遵守率、停止履歴が貯まり、これが後から予知保全を入れたときに効果を判定する基準にもなります。自社の突発停止を12か月分きちんと分類して初めて、どの設備に加速度センサーを付ける価値があるのかが見えてきます。

徐々に劣化せず、測定できる予兆も出さずに壊れるものです。制御基板、I/Oカード、多くのオンオフ式センサーはほぼランダムに故障しますし、衝突、段取りミス、オペレーターによる破損は進行するプロセスとは違う単発の事象です。安全弁やインターロックのような保護機器は、守るべき事象が起きるまで何の信号も出しませんので、一定間隔の機能試験で確認します。振動や電流では回転機械の機械的摩耗はよく見えますが、これらのモードはまったく見えません。

モデルありきの提案が前提にするほどは要りません。最初に役に立つしきい値は、履歴データがなくても工学から決められるからです。軸受の欠陥周波数は幾何形状と軸回転数から、フィルタは差圧から、温度は同じ負荷におけるその機械自身の平常値からの上昇で見ます。異常検知には、製品・速度・シフトによる正常なばらつきを覆うだけの正常運転データが必要です。余寿命(RUL)推定には故障まで走らせた実例が必要ですが、これは多くの工場にそもそもありません。

保全側に専任の担当者を立てる前提で見てください。重いのは立ち上げ時に集中します。設備階層、実態に合った予防保全計画、そして一度合意して決める故障コード体系です。稼働後の定常業務は、アラートの一次判定と、構造化された所見・使用部品・カウンター値を入れて作業指示をクローズすることです。アラートの量は一人が実際に調べきれる範囲に調整してください。そうしないと、そのうち誰も開かなくなります。

MTBFは稼働時間を故障件数で割った値、MTTRは総修理時間を修理件数で割った値で、いずれも作業指示の項目、つまり通知時刻、修理開始、修理完了から組み立てます。稼働時間計やMESの稼働信号がないと故障と故障の間のカレンダー時間しか取れませんので、あまり動いていない設備ほどMTBFが良く見えてしまいます。修理時間も、通知起点(待ち時間と部品調達を含む)か、修理開始起点(実作業時間)かで意味が変わります。

いいえ、単独で動きます。オペレーターはHMIまたはブラウザから通知を上げられますし、保全計画、作業指示、スペアパーツまわりは他に何も入れる必要がありません。APSが加わると、合意した保全枠がスケジュール上の制約として計画担当者に届くようになり、現場の立ち話で決めた枠が忘れられることもなくなります。無ければ生産側と手作業で枠を握ることになりますが、多くの工場はそこから始めますし、そのまま続けても不都合はありません。

それ単独で減ることはまずありません。予兆が役に立つのは、その部品の調達リードタイムを安定して上回って出る場合だけで、故障時期が読めないことは安全在庫を持つ理由の一つにすぎません。リードタイムのばらつき、最小発注数量、一つの品番が複数の設備を兼ねていることは、どれも残ります。本モジュールは作業指示に対して部品を引き当て、在庫が足りなければ発注を起こします。まず予兆を計画停止の枠に変えて、一年分の実績が貯まってから在庫水準を見直してください。