PLC (Programmable logic controller) は生産設備や検査機器などの制御に多く利用されており、そうした機器の 遠隔監視 は製造業における IoT の主要なテーマのひとつです。SORACOM を利用した PLC の 遠隔監視 システムの代表的な構成パターンについて、既存の運用との変更点をテーマに 3 つのパターンを解説します。
PLC の遠隔監視 (遠隔保守・可視化・制御) の背景と目的、課題
背景と目的
PLC の遠隔監視を検討する背景や目的には以下のようなものがあります。
- 保守担当者が、全国各地に納品している自社製品や、複数拠点に点在する自社工場などの設備保守を担当しており、各拠点の製品 (PLC) のメンテナンスの都度、状況を確認するためだけに現地を訪問する人手や費用、時間や工数に悩んでいる。
- トラブル発生時のリードタイムを削減したり、トラブルを未然に防止したりするために、できる限りタイムリーに対応したい。
- 顧客に自社製品に対するリモートメンテナンス (遠隔保守) サービスを提供して、新たな付加価値を提供したい。
- 生産ラインをデジタル化して可視化し、無駄を把握して生産性を向上したい。
- 顧客に納品している自社製品の稼働データを分析し、新たな価値提供につなげたい。
既存の運用の課題
一方で、既存の運用の仕組みについては、担当者共通の課題と、担当者ごとに異なる課題があります。
担当者に共通する課題
- 製品の設備点検や制御が現場でなければ実施できない。遠隔から安全に (セキュアに) 設備点検や制御が実施できない。
- 社内のポリシーで、簡単には社外 (インターネット) に接続できない。
- 現在実施している製品 (PLC) の運用保守の仕組みが難しい。
- データ活用のための費用や人員を捻出するのが難しい。
担当者ごとに異なる課題
コストや人手に関して:
- 自社の持ち出しなので費用は抑えたい ←→ 収益化を狙ってコスト設計したい
- 人手不足なので新たな仕組みを自社で構築するのではなく他社サービスを利用したい ←→ これを DX 人材を育成する機会にしたい
既存の運用に関して:
- 既存の運用は変えられない ←→ 新たな運用 (運用保守、遠隔からの PLC の制御や常時監視など) を導入したい
- 素早く手軽にパッケージを導入したい ←→ 自社の分析基盤を構築しさまざまなデータを統合したい
既存の運用をどう変えたいか？で構成パターンを分類する
経営環境や事業戦略で変動しやすい「コストや人手をどう変えられるか？」という観点と比べると、「既存の運用をどう変えられるか？」という観点は、比較的案件ごとに調整しやすい傾向があります。たとえば、既存の組織体制、設備投資、あるいは顧客との関係性などを調整することが考えられます。
ここでは「既存の運用をどう変える？（または変えない？）」という観点で、検討しやすい構成パターンについて類型化します。以下のフローチャートで、3 つの構成パターンを効果的に検討できます。
現場の LAN を事業所まで延伸し、現在実施している運用保守をそのまま遠隔で実現する方式です。
デバイスからクラウドまでオールインワンなパッケージサービスを利用し、遠隔から PLC の常時監視や可視化、あるいは遠隔制御を実現する方式です。
「PLC や産業機器のデータを収集し任意のサーバーに転送できる特化型の IoT ゲートウェイデバイス」を利用し、自社クラウドなどで構築した分析基盤に接続する方式です。
フローチャートのように、2 つのシンプルな問いだけですべての検討課題を上手く分類できるわけではありません。しかし多くのケースでは「既存の運用を変えずに維持するか？変える場合は、どのような仕組みで変えるか？」について考えることで、進むべき遠隔監視 (遠隔保守・可視化・制御) の方向性を形にしやすくなります。
たとえば以下のようなケースが考えられます。
現状の仕組み:
- PLC メーカーが提供するソフトウェア (ラダープログラム) を利用して PLC の状態を点検したり、HMI で目視確認していた。
理想の仕組み:
- 遠隔でも状況を確認できるように、PLC の状態の可視化や計測値を常時監視する。
- 上記監視環境を関係各社で共有する 新たな運用監視の仕組みを導入する。
このケースでは、パターン 2 (運用監視の仕組みをパッケージサービスで素早く立ち上げる) か、パターン 3 (じっくり工数をかけて自社の分析基盤に統合していく) の採用を検討します。
また、複数パターンを同時に実現したいケース (フローチャートのとおりにパターンを決められないケース) も考えられます。たとえば、パターン 2 やパターン 3 のように新たな仕組みを導入しつつ、同時にパターン 1 のように従来どおりにラダープログラムを監視・編集するようなケースです。その場合は、ぜひソラコムの セールスチーム にお問い合わせください。
自社とベンダー、運用の責任範囲でみる各パターン
パターンごとに、IoT システム自体の運用保守に自社がどれだけ関わるか、つまり自社でどこまで運用保守の稼働を割いていく必要があるかも見てみましょう。
IoT システムは、現場側の「デバイス」と、クラウドやデータセンターにある「サーバー」、そしてその間をつなぐ「ネットワーク」が主な要素です。ここでは、それらの要素の初期設定や構築を誰が行い、初期設定後の運用や保守を誰が担うか、という点で整理します。
- デバイス (4G LTE ルーターなどの通信機器) の設置と運用保守は自社で実施します。
- ネットワークは自社で契約し、必要な設定は SORACOM で行います。
- SORACOM でよく相談を受けるケースに限定すると、デバイス (IoT SIM) 間通信の要件はありますが、クラウドやデータセンターは使用しません。
自社データセンターを使用することもできます
自社データセンターと SORACOM を VPN で接続し、デバイスが社内システムとネットワーク接続する要件がある場合は、VPN ルーターなどのネットワーク関連設備の設定・運用は自社で対応する必要があります。
デバイス、ネットワーク、クラウドのすべての要素で、ソラコムを含むベンダー側でパッケージされています。そのため、デバイスの設置以外の工数は発生しません。運用保守が最も少なく、素早い IoT システムの立ち上げが期待されるパターンです。
パターン 2 とは逆に、デバイスからクラウドまで自社で管理するパターンです。つまり、デバイスの運用保守はもちろん、デバイスとクラウドの接続設定や、クラウドで必要なサーバー設計と構築・運用なども自社で実施します。
このパターンの派生パターンとして、クラウドの部分で、データ保存と可視化のための SaaS サービスを利用することもあります。自社システムのみの場合と比べるとシステム構成の自由度は下がりますが、より工数をかけずに IoT システムを完成させる 1 つの選択肢となるでしょう。
以上のように、それぞれのパターンで設置からその後の運用保守を担うのが、ソラコムを含むベンダーなのか、自社なのかを事前に把握しておくことは検討段階の重要な要素です。
ネットワークやクラウドの運用保守を、ソラコムを含むベンダーが実施するケースであっても、それらを利用するための設定や運用については自社となることがあります。その場合は、サービスを利用するためのコスト (学習時間、人員の配置) も事前に検討できると良いでしょう。
なお SORACOM では、お客様ができる限りセルフサービスで通信やネットワークなどのサービスを利用できるよう、サービスの改善やユーザードキュメントの整備に継続的に取り組んでいます。たとえば、すべてのお客様が利用できる SORACOM ユーザーコンソール (管理画面) では、生成 AI が素早く回答する SORACOM Support Bot の機能が提供されています。詳しくは、SORACOM Support Bot に問い合わせる (Public beta) を参照してください。
本件に限らず、お気づきの点や改善のご要望は セールスチーム に気兼ねなくお伝えいただけると幸いです。