産業IoTゲートウェイの選び方：プロトコル、上りチャネル、証明書

メーカー名だけ見ると落ちる5つの確認

• プロトコル対応が現場と合わない：資料には Modbus 対応とあるが、現場は独自プロトコルや特定 PLC ポートで、ゲートウェイのドライバ一覧に項目がない
• 点表をゲートウェイから書き出せない：レジスタを手書き転記しており、ライン追加・担当交代・プラットフォーム接続のたびにアドレスがずれる
• 上りチャネルが1本しかない：MQTT か REST のどちらかだけで、プラットフォームや専用線が両方を求めると作り直せない
• 証明書の形が合わない：プラットフォームはクライアント証明書を求めるのに、ゲートウェイは自己署名しか出せない、または証明書管理自体がない
• 通信断のバッファがない：4G や専用線が切れた間のデータが消え、復旧後の履歴曲線に欠落が残る

この5つは、いずれもゲートウェイが納入されたあとに表面化します。確認すべきなのはメーカー名ではなく、プロトコル、点表、チャネル、証明書、バッファの5つの能力が現場条件とプラットフォーム要求に揃っているかどうかです。どの設備でもそのまま繋がるわけではありません。インターフェースと適合条件は事前に確認します。

プロトコルと点表：下向きに何を集め、上向きに何を渡すか

ゲートウェイは下向きには収集口、上向きにはデータの出口です。下向きプロトコルが設備を読めるかを決め、点表が値の名前・アドレス・単位を決めます。「対応プロトコル数」だけ数えて点表の持ち方を見ないと、工事が広がった時点でタグが散らばります。

当社は複数メーカーの IoT ゲートウェイを現場条件に合わせて組み込みます。ゲートウェイ内蔵の Web 設定画面で設備一覧とレジスタアドレスを整え、アドレス表を一操作で書き出せます。このファイルが SCADA とプラットフォームの共通入力になります。工場 IoT でよく使う経路は、Modbus TCP で設備を読み、MQTT と REST の2チャネルでクラウドへ上げることです。老朽設備や特殊設備は、インターフェースと適合条件を先に確認します。

• 下向きプロトコル：設備が実際に開いているプロトコルとポート（Modbus TCP/RTU、メーカードライバなど）を先に確認し、ゲートウェイのドライバ一覧と照合する。合わなければ適合評価に回す
• 点表の構造：各点に設備、アドレス、データ型、倍率、単位、読み書き属性を持たせ、書き出し結果を SCADA とプラットフォームがそのまま参照できるようにする
• 内蔵 Web 設定画面：設備と点の設定をゲートウェイ上で完結させ、外部ネットワークに依存しない。無人エッジ盤や現地調整に向く
• アドレス表の一操作書き出し：書き出したファイルを単一の入力とし、手書き転記でライン間・ゲートウェイとプラットフォーム間の点がずれるのを防ぐ
• 適合の境界：フリープロトコル、生産終了コントローラ、通信ポートのない設備は「選定すれば繋がる」範囲に入らない。個別に確認し、必要なら収集経路を変える

上りチャネル：MQTT、REST、専用線、4G の組み合わせ

チャネルが答えるのは、データを現場からどう出すかです。工場のエッジ盤は専用線があるラインもあれば 4G だけの建屋もあり、両方あっても安定しないことがあります。チャネルは「プロトコルを1つ選ぶ」ことではなく、主経路、予備経路、通信断のあいだのバッファを同時に決めることです。

案件で用いている進め方は、Modbus TCP で収集し、MQTT と REST の2チャネルでクラウドへ上げることです。MQTT は継続的な通知と購読、REST はプラットフォーム側の取得、突合、補完に向きます。専用線と 4G は搬送路であり、この応用チャネルの組の代わりにはなりません。

• MQTT：設備側が継続的に発行し、プラットフォームが購読する。状態、曲線、アラームの継続通知に向く。トピック構造、QoS、セッション維持を先に決める
• REST：プラットフォームが必要に応じて取得するか、ゲートウェイが POST する。突合、補完、既存業務システムとの接続に向く。パス、認証、再試行を決める
• 専用線：遅延と帯域は比較的安定するが、切断は起きる。両側のファイアウォール、固定アドレス、証明書をゲートウェイのチャネル設定と揃える
• 4G：無人エッジ盤や仮設接続をカバーする。通信量、電波、料金はサンプリング周期から見積もる。通信断のあいだはローカルバッファが必要で、復旧後に自動で補完する

証明書と権限：チャネルが通ってもプラットフォームは通さない

チャネルが通ったことは、電文が外に出ることしか意味しません。プラットフォーム側は「どのゲートウェイか、どのクライアントか」を認証することが普通です。証明書と権限を誤ると、クラウドに入れない、権限が広すぎる、期限切れでライン全体が落ちる、といった事態になります。ゲートウェイ証明書、クライアント証明書、自己署名証明書は形が違い、互いに置き換えられません。

• ゲートウェイ証明書：その台の身元を示し、プラットフォームは証明書で拠点を識別する。形式、有効期限、失効、更新手順を確認する。無人盤では遠隔更新ができること
• クライアント証明書：プラットフォームや外部クラウドが相互認証を求めるときに使う。ゲートウェイはクライアント証明書と秘密鍵を取り込み、MQTT と REST のチャネルに結びつける
• 自己署名証明書：構内ネットワークやプライベート基盤でよく使い、導入は速い。ルート証明書の配布と信頼チェーンの管理が要る。パブリッククラウドや組織をまたぐ基盤では通らないことが多い
• 権限と役割：Web 設定画面、点表書き出し、チャネルの開始と停止、証明書の更新は役割で分ける。現地調整用アカウントと運転監視用アカウントを分け、操作を監査できるようにする

現場条件、ゲートウェイの能力、確認しない場合の影響

提案の前に、下表で現場条件とゲートウェイの能力を項目ごとに照合します。合わない項目が適合作業量です。納入後に残さないでください。

老朽設備と特殊設備は、インターフェースと適合条件を先に確認してからゲートウェイを決めます。どの設備でもそのまま繋がるわけではありません。繋がるか、どのプロトコルか、点表を書き出せるかは、現地確認の結果で決まります。