現在のところ既存の製造工場・設備をIoT化しようとすると高いハードルがあります。それは、工場の制御系とビジネス系システムは同じリアルタイムと言う言葉を使っていても全く違う時間間隔で動作しており、間を繋ぐ装置がゲートウエイとして必要となるためです。
また、工場に設置されている設備の制御装置として納入されているPLCは多種多様な、それも年代の異なるものが入っており、簡単に通信が出来ないのです。
ここでは、その辺りをご説明しています。
ゲートウエイ機器が必要となる理由
こちらでは、特に日本の製造業において工場をIoT化しようとした場合に起きる様々な問題点と、その対処方に関してお伝えしました。
その中で、インターネット、特にクラウド環境に工場の制御機器を接続する場合にどうしても、その間をつなぐゲートウエイが必要となると説明しました。ここでは、そのIoTゲートウエイが必要となる理由についてご説明していきたいと思います。
最新のクラウド環境と直接コミュニケーション出来ない
工場のIoT化を考えた時に、単にインターネット経由でモバイル監視を行うのではなく、どうしてもクラウド環境を使うことになる点をこちらでご説明していますが、そのクラウド環境へのデータ連携において問題があるのです。
最新のクラウド環境では、アメリカの巨大IT企業（アマゾン、マイクロソフト、IBM、Googleなど）が共同でIoTに特化した通信プロトコルの規格を決め、ほぼその通信手順でなければクラウド環境にデータをインターフェース出来ないか、従頼のHTTPなどで連携していたのでは、非常に効率が悪くセキュリティー面でも脆弱なものになってしまうのです。
考えてみれば当然の事なのですが、そこが特に日本の製造業の現場に入っている古いPLC（プログラマブル・ロジック・コントローラー）と最新のクラウド環境の通信において、非常に高いハードルとなっています。
IoTプロトコルの特徴
IoT用のプロトコルは、AMQP、MQTTなど複数が現時点では存在していますが、基本的な考え方、その特徴は然程変わりません。それは、次のような特徴を持っています。
◆ シンプル
従来のプロトコルはコンピュータとコンピュータを接続する為のものでしたので、通信される情報量が多いほうが相手側でのハンドリングに都合が良かったため、ヘッダーやフッターなどに多くの情報を載せて送っていました。
しかし、IoTではMtoMとは言ってもマシンtoマシンのイメージではなく、非常に小さな小箱に太陽電池とセンサーだけのような機器も想定する必要があるため、非常にシンプルな構造となっています。
- ヘッダサイズは「HTTP：50バイト～」「「MQTT」：2バイト～」と数十分の一のイメージです。
◆ 軽量
また、今後あらゆる機器がインターネットに接続され、データを送り続けることを考えると、１点１点の通信を軽くする必要があると考えられています。
よって、そのトラフィックは、皆さんが見ているウエブブラウザーなどで使われているHTTPに比べると10分の1程度となっています。
◆ 低遅延
外部の情報をインターネット回線を通してリアルタイムで情報入手し、コントロールしていくことを考えると、そのネットワーク遅延は重大な問題となってしまう事が想定されます。
よってネットワーク遅延が発生し難い構造を目指したプロトコルとなっています。
◆ 双方向
これも、離れた場所の状況をインターネット経由で確認するだけではなく、ある程度の遠隔操作や設定値の変更などを行うとすれば、双方向の通信必要となってきます。
セキュリティーを考慮
また、これまでは工場内のFA（Factory Automation）機器をつなぐFAネットワークにのみ接続されていたいましたので、正直言ってFAネットワークは全くセキュリティ面の考慮がなされていません。
しかし、IoTとなると、それらの工場内の制御機器を外部のインターネットに接続していく事になりますので、通常のオフィス回線と同様にセキュリティー面を考慮する必要が生じてきます。
AWS（Amazon）やAzure（Microsoft）などのメジャーなクラウドベンダー環境であれば、セキュリティーに関する専用の機能を提供していますし、最近は上記のMQTTプロトコルにセキュリティーを考慮したSMQTTなども提供されています。
言うまでも無いかとは思いますが、IoT（インターネット）を経由して、工場の操業状態を監視したり、どこまであり得るかは検討が必要ですが、ある種の操作を外部操作、設定変更まで行うとすれば、悪意のある外部侵入者は大きな脅威と言えます。
リアルタイム性の違い
言うまでもなく、工場の生産設備はPLC等のリアルタイム制御機器によってコントロールされています。それは、少なくともミリ秒単位の制御が出来ないと上手く装置は動きません。
しかし、ビジネスの世界は通常、人間が毎日朝出勤し夕方までの間に行われ日単位、もしくは人間が感じる１時間、30分程度の時間の進み方です。
ERPなどの説明でそのリアルタイム性を説明することがよくありますが、あくまで人間が行うビジネスの進み方・時間感覚で言うリアルタイムであって、制御系で言うミリ秒、ナノ秒と言う世界ではありません。
通常殆どの会社は月次で売上、原価の認識をし、PLを管理していきます。電気代やオフィースの賃料、社員の人件費も月単位で支払われます。よってビジネスの世界は殆ど月単位で動いていると言えます。
明らかにビジネスの世界の時間の進み方・時間感覚と、工場のリアルタイム制御の世界の時間感覚は異なっていますので、その間を埋める必要があるのです。
インターネットはご存知の通り、相手に情報が届くタイミングを約束されていない通信です。月曜の朝はネットが遅くなる、昼休みの時間帯は遅くなる、等皆さんも感覚的に理解できるものと思います。
この約束されていない応答と工場設備のリアルタイム制御を単純に繋げるとPLC等の制御装置に意味のない遅延の影響がでたり、うまくコントロール出来ない、又はインターネット側が遅くなっている間に工場の制御機器からのデータが送信し続けられ、溜まってしまうようなことが発生してしまうのです。
ファイル渡しはナンセンス
そうは言っても、IoTの世界を真剣に考えると応答速度が約束されていないインターネット経由であっても、極力リアルタイムに現場の状況を確認したい、コントロールしたいと考えるのが当然と言えます。
ここで、従来の古いIT会社やSEに相談すると、多くの場合次のような提案を持ってきます。
工場現場のデータをCSVなどのファイル渡しする
ナンセンスです。これらの古い考え方のSEにとっては、このファイル渡しが当然に思えるのですが、リアルタイムの世界とは程遠いものです。その理由は以下のようなものです。
データの切れ目がない
数時間、数日、数か月間動作し続ける工場の設備を考えると、通常のコンピュータにデータを渡してファイルに書き始めてから、そのファイルをクローズするタイミングが無いのです。
そうすると、数日なのか数週間なのか、１ロットの生産が修了したタイミングにやっとファイルをクローズして初めてデータを送れることになってしまいます。
もしくは、クラウド側にデータを送るタイミングを1秒毎などと決め、そのタイミングでファイルをクローズして送信する事になります。大量のファイル数です。
リアルタイムにならない
こう考えると、CSV等のファイル渡しはリアルタイムとは程遠いものになる事が理解できると思います。
データは流れている
生産現場の制御装置からのリアルタイムデータは、流れとして出てきます。ダラダラと。そのデータをCSVなどのファイルでクラウド側に渡して、クラウド側でそのファイルを読み、分析していたのでは完全にバッチ処理の世界感に逆戻りしてしまいます。
まとめ
ここまでご説明してきた通り、現時点で工場・設備をIoT化しようとする場合には、どうしても間にゲートウエイ機器が必要となりそれなりの設計をする必要があります。
そして、IT・設備会社、ユーザー企業の双方が、制御系とビジネス系のシステムを完全に分離してきた過去の経緯があり、制御系システムとビジネス系システムの両方を理解しているエンジニアが極めて少ないのが大問題なのです。
