PLCからの異常通知：安く実戦投入するための方法と落とし穴
設備が止まっていることに気づかない。夜勤明けや休日に停止していたら復旧に時間がかかり、生産計画に大打撃です。SCADAを導入すれば解決しますが、数十万円〜数百万円はかかります。本記事では、PLCの異常ビットをトリガーにメールやTelegramで通知する低コストシステムの現実を解説します。
3パターンから最適を選ぶ
システム構成は3パターンあります。PLCさえ対応していれば、パターンBが最も簡単です。
パターンB（PLC直結Ethernet）：PLC → Ethernet → SMTPサーバ。三菱FX5UやキーエンスKV-7500/8000シリーズなら、PLC単体でSMTPメール送信が可能です。設定もKV STUDIOのウィザードを使えば簡単です。
パターンA（ESP32経由）：PLC → RS-232C → ESP32 → WiFi → SMTP/Telegram。1番安い（500円〜）ですが、古い装置や新しく自作した装置でPLCが対応していない場合、予算の都合で搭載できない場合に使います。
パターンC（ラズパイ経由）：PLC → RS-485 → Raspberry Pi → Telegram。Modbus対応の旧PLCでも接続可能です。コストはラズパイ 5,000円程度。
パターンAで使うESP32開発ボードやRS-232C変換モジュールは Amazon でも入手できます。
実戦投入：私がパターンAを選んだ理由
私の現場では古い設備が多く、PLCのEthernet対応ができませんでした。予算もない。そこで、最も安いパターンA（ESP32）を選択しました。
システム構成
PLCの異常出力（リレー接点）→ ESP32のGPIO → WiFi → Gmail SMTPで自分にメール。コストはESP32で500円程度。
プログラムの仕組み
// ESP32側（Arduino IDE）
#include <WiFi.h>
#include <SMTPClient.h>
#define ALARM_PIN 4
void setup() {
Serial.begin(115200);
pinMode(ALARM_PIN, INPUT_PULLDOWN);
WiFi.begin("SSID", "PASSWORD");
}
void loop() {
if (digitalRead(ALARM_PIN) == HIGH) {
// デバウンス：2秒継続したら通知
delay(2000);
if (digitalRead(ALARM_PIN) == HIGH) {
sendMail("設備異常発生", "ラインAが停止しました。至急確認してください。");
}
}
delay(100);
}このシンプルな仕組みで、設備停止時にメールが届くようになりました。
現実は甘くなかった：パターンAの落とし穴
しかし、人材不足の中、メンテ人員がいない現場にパターンAを導入したことで、全ての停止対応が自分の仕事になるという打撃を食らってしまったのです。
具体的には：
- 夜中にメールが来て、一人で復旧に向かう
- ESP32のWiFiが定期的に落ちる → 深夜に設定をやり直す
- SMTP認証の期限切れでメールが止まる → 夜中にアプリパスワードを再発行
- Gmailのセキュリティ制限でブロックされる → 朝一で解除
パターンAは安い代わりに、「安い分だけ自分でメンテナンスしなければならない」という現実があります。
結局、パターンBを導入した
限界を迎えて、PLCをEthernet対応の新機種に更新し、パターンBに移行しました。
パターンBのメリット：
- PLC単体でメール送信 → ESP32という故障ポイントが消える
- ラダープログラムで完結 → 外部デバイスのメンテが不要
- 安定稼働 → 夜中に起きる必要が減った
ただ、PLCの機種更新に費用がかかりました。安さだけを追求すると、後で高くつく例です。
現場の状況に合わせた選び方
| 状況 | おすすめ | 理由 |
|---|---|---|
| PLCがEthernet対応 | パターンB | 最も簡単・安定、外部デバイス不要 |
| PLC非対応・予算なし | パターンA | 500円から始められるが自分でメンテ必須 |
| 古PLC・RS-485のみ | パターンC | ラズパイでModbus接続、Aより高くて安定 |
私の教訓：安いシステムの本当のコスト
パターンAを経験して学んだのは、「安いシステムほど、運用コスト（自分のかかる時間）が高い」ということです。
ESP32は500円ですが、夜中に3回起きてトラブル対応したら、そのダメージは500円では済みません。
逆にパターンBはPLCの機種更新に数万円かかりましたが、運用にかかる自分の時間は激減しました。トータルコストで考えれば、パターンBの方が安かったというのが結論です。
まずは今日からできること
あなたの現場がどのパターンに向いているか、以下の診断で確認してください。
- PLCの型番を確認 → Ethernetポートがあるか？
- なければ → 予算は確保できるか？
- 確保できない → パターンAで実証（ただし覚悟が必要）
- 運用できる余力がある → パターンBがベスト
設備が止まってから気づく不安。このシステムを取り除くだけで、夜も休日も安心して過ごせるようになります。
次の課題：通知から「自律対応」へ
現状のシステムは「通知をする」だけです。今後は指示に対して装置が自律対応できればと考えています。
例えば：
- 「異常停止検知→リモートで再起動」
- 「温度上昇検知→冷却ファン起動」
- 「エラーコード001検知→自動復旧シーケンス実行」
ただし、現実は厳しいです。装置の安全状況を遠隔で確認できない操作は多く、無判断で自動操作すると重大事故につながりかねません。
私が想定しているのは、あくまで「人間の判断を前提とした自律サポート」です。AIが「この異常はリモート復旧可能ですか？」と聞き、人間が「はい」を押したら自動で復旧シーケンスを動かす。この「人間とAIの協調」が、現場の安全を守りながら省力化を進める次のステップだと模索しています。
出典・参考
- ESP32 Arduino 公式ドキュメント
- 三菱電機 MELSEC FX5U マニュアル
- キーエンス KVシリーズ マニュアル：KV STUDIOメール設定ウィザード
- Telegram Bot API 公式ドキュメント
当サイトはAmazonのアソシエイトプログラムに参加しています。
コメント