CNC工作機械の監視：収集すべき信号・接続経路・OEE定義
CNC工作機械の稼働監視は、コントローラが持つ稼働状態・プログラム番号・主軸負荷・アラーム番号に、工具寿命と加工数を加えて収集し、比較できる稼働率とOEEの口径に落とし込む仕組みです。問いに答えるのは「機械が動いていたか」ではなく、「この機械が直近8時間でなぜ97分止まったのか、その時間はどの原因に属するのか」です。接続経路と定義は、プラットフォームの選定より先に決めます。
まず収集する信号を決める
工作機械をつなぐ最初の作業は、プラットフォームの選定ではなく信号リストの確定です。マシニングセンタのコントローラは数百のフィールドを公開しますが、後の分析に効くのは五つのグループです。加工しているか、何を加工しているか、負荷はどの程度か、どこでアラームが出たか、工具はどれだけ残っているか。この五つを決めておけば、後でプラットフォームを替えてもデータは使えます。
- 稼働状態と運転モード：自動運転・一時停止・停止・アラーム・段取り。時間の切り分けに使う
- 実行中のプログラム番号とワーク番号：加工記録をプログラムとロットに紐づける
- 主軸負荷・送りオーバーライド・主軸回転数：空転・軽負荷・異常負荷を見分ける
- アラーム番号とアラーム文言：機械・電気・プログラム・操作の原因に分類する
- 工具寿命・工具交換回数・加工数：工具管理とタクト算出を支える
接続経路は三つから選ぶ
同じラインでもコントローラの世代は揃いません。接続経路は、収集ソフトが読みたいものではなく、コントローラがどこまで開放されているかで決まります。三つの層でほとんどの現場は足ります。直接読める場合は標準プロトコル、ベンダー製ツールでしか読めない場合は公式の収集ソフト、どちらも無い場合は電気側から信号を取ります。
| 接続経路 | 適用条件 | 発注側に用意いただくもの |
|---|---|---|
| OPC UA・MTConnect などの標準インタフェース | コントローラにEthernetがありプロトコルが開放されている | プロトコル仕様書、IPとポートの設計、アクセス権限 |
| コントローラベンダーの収集ソフトまたはSDK | 公式のデータサービスがある | ライセンス、取得可能フィールド一覧、バージョンの対応関係 |
| 電気側信号とマクロ変数 | 旧型で開放インタフェースが無い | 電気図面、IO点リスト、マクロ変数のアドレス資料 |
稼働率とOEEの定義を揃える
同じ工場で稼働率が二つ出てくるのはよくある話で、原因は収集ではなく定義にあります。OEEの三つの因子は ISO 22400-2:2014 で定義されていますが、計画停止を損失に数えるか、段取り時間をどこへ置くか、工具交換を停止とみなすかは、規格が決めてくれません。現場で文章にして決める必要があります。
六つの損失は中島清一が1988年に示したTPMの枠組みで、加工現場では現場の呼び方に置き換える作業が要ります。故障、段取り替え、空転・小停止、工具交換、試し削り、手直しを一つずつ対応づけます。定義を先に固めないまま自動収集を進めると、精度の高いデータが議論を画面の上へ移すだけになります。
- 時刻はコントローラの時計に統一し、定期的に時刻同期する。ゲートウェイ時刻でシフトを切らない
- 状態判定は固定ルールにする。どのアラーム番号を故障停止、どれを部材待ち、どれを段取りとするか
- 損失分類は班長が一度確認し、以降は毎月見直す。同じ原因が二つの表で別分類にならないようにする
稼働開始前の受け入れ確認
加工現場の監視プロジェクトが失敗するのは、データが取れないからではなく、取れたデータを誰も信用しないからです。受け入れ時に次の四つを実地で確認するほうが、十台つなぐより価値があります。
- 完全性の抽出確認：三つのシフトを無作為に選び、手集計とシステム集計を機械ごとに突き合わせる
- 状態判定の再確認：一日分の停止明細を出し、班長に一件ずつ分類を確認してもらう
- アラームの再現：アラーム番号から当時のプログラム・負荷・操作記録をたどり、部位まで特定できるか見る
- 通信断と補送：ゲートウェイのLANケーブルを十分外し、復旧後に欠測とタイムスタンプの飛びが無いか確認する
まとめ
工作機械の監視で価値があるのは画面の数ではなく、データが具体的な判断を支えられるかどうかです。この機械がなぜ止まったのか、この段取り替えがなぜ超過したのか、この工具がなぜ早く寿命になったのか。信号リスト、接続経路、定義、受け入れ確認の四つを固めて初めて現場は使います。予知保全や工具寿命予測は開発中の領域で、共同検証として進めるものであり、納品の約束ではありません。