前回までで、IoTシステムのアーキテクチャのパターンや特徴、またそれぞれの考慮ポイントを説明しました。IoTシステムにどのようなアーキテクチャが求められるか、大枠のイメージを掴んでいただいたのではないかと思います。

今回は、そのアーキテクチャが実際のシステムでどのように利用されているのかを、幾つかの適用シーンをもとに紹介していきます。

事例を使って具体的に説明することで、どのシステムでどのアーキテクチャを選ぶのか、どのようにアーキテクチャを適用していくのか、より深くイメージをしていただけるのではないかと思います。

適用シーン[1] リモートメンテナンス

建設機器や工作機械をインターネットとつなぎ、遠隔から状態監視をしたり、メンテナンスを行ったりするようなIoTシステムです。

IoTシステムとしては早い段階から取り組みがされていたタイプのシステムで、コマツの「KOMTRAX」などが代表例になります。

コマツは「KOMTRAX」という名称でIoTを活用した車両管理ソリューションを提供している(コマツのWebサイトから)

リアルタイム性の高い機器制御については、以前よりM2Mとしてシステム化が進んでいましたが、クラウド化が進んだ結果、新たにメーカーが顧客のデバイスを監視するような、対象が多くまたオープンな環境で監視を行うシステムが増えてきています。

このシステムでは、比較的デバイスが高価で大型なことが多く、またインテリジェンスで自立して稼働するものが多い点が特徴です。そのため、デバイス自身にOSを搭載しており、そのOS上から稼働状況やログを直接取得できる場合がほとんどです。仮にOSを搭載していなくても、外付けでIoTゲートウェイを取り付ければよく、移動体のようなものを監視する場合は、この方法で対応します。

この適用シーンの特徴をまとめると以下になります。

  • デバイス、もしくはゲートウェイが高性能でOSを搭載している場合が多い
  • 扱うデータの量が多く、データ転送時のセキュリティ要求が高い
  • ネットワーク環境は3G/LTE回線を利用する場合が多い

OSが存在するケースがほとんどであるため、システムアーキテクチャは、直接デバイスからデータを転送する「Device to Cloud」のタイプになります。データ転送に関してはいくつか方法がありますが、大きく分けるとデバイスから随時データをプッシュしてクラウド側で収集/見える化を行うタイプと、デバイス側でデータを集約してまとめてクラウド側に送るタイプの2種類になります。

随時データをプッシュするタイプは、プロトコルとしてはMQTTが適しています。ある程度データをロストしてしまっても、大枠の状態がつかめればよしと考えれば、データ制御も細かく考える必要はありません。

データをまとめて送るタイプは、一度ファイル化してFTPなどのファイル転送のプロトコルを利用するのが一般的でしょう。その場合は、転送途中にエラーが発生した時の再送処理や転送が完了したことをクラウド側のアプリケーションに通知する仕組みが必要になります。

  • 利用されるアーキテクチャ :  Device to Cloud、Using Gateway
  • 利用されるプロトコロル : MQTT、FTP、HULFT

適用シーン[2] 画像検査

製造品の品質検査や加工状態の確認に、熟練工の目視ではなく、画像を利用するシステムが徐々に普及しつつあります。機械学習やDeepLearningなどを利用して、従来は難しかった熟練工のノウハウをアルゴリズム化し、人力では限界のあった全品検査にチャレンジする取り組みも出てきています。

画像検査ソリューションはオムロンなどが提供している(オムロンフィールドエンジニアリングのWebサイトから)

このようなシステムの場合、処理速度の観点からデバイス側にアプリケーションを配置して完結させてしまうことも多いですが、判定結果の分析のためにデータをクラウドへアップして蓄積したいというニーズもよくあります。

そういったケースでは、高画質な画像データをクラウド上へもれなく転送する必要があります。また、画像をただ送るのではなく、どの製品の写真かが後からわかるようにメタデータと組み合わせて送るような処理も必要になります。

この適用シーンの特徴をまとめると以下になります。

  • 画像を一旦ゲートウェイやPLCで処理してから転送する場合が多い
  • 画像は転送時だけ圧縮をしたい
  • ネットワーク環境はLAN、WANなどを利用する場合が多い

カメラ単体でクラウドに接続できるような機種も存在しますが、画像処理などを行ってから転送することが多いので、システムアーキテクチャは「Using Gateway」、もしくは「Using Server」のタイプになります。データ転送はファイルそのものを転送するため、FTPのようなファイル転送用プロトコルが利用されます。

圧縮はもちろんしますが、特徴にも記載しているとおり、デバイス側でまとめて圧縮するとデバイスの負荷が大きくなるので、転送時だけ圧縮をするDeflate圧縮ができると非常に効果的です。また、クラウド上へ転送後、後々の処理をしやすくするために解凍してから保管をしたいというニーズも多く、その場合は転送後に圧縮したファイルを解凍する処理を実行する機能が求められます。

  • 利用されるアーキテクチャ : Using Gateway、Using Server
  • 利用されるプロコトル : FTP、HULFT

適用シーンはさまざま

今回は、前回までに紹介したアーキテクチャやプロトコルの利用方法をイメージしてもらうために、具体的な適用シーンをベースに説明しました。

ただ、今回紹介したシーンはほんの一例で、実際はもっと複雑なアーキテクチャを利用して複数のプロトコルを使い分けていることの方が多いでしょう。それでも、今回の分類を用いることでシステム全体を細分化でき、理解のスピードを早めることができるのではないかと思います。

IoTシステムもこれからさまざまなニーズに答えるために多様化していくでしょう。そうなればまた新たなアーキテクチャやプロトコルが生み出されるかもしれません。トレンドは引き続きチェックをする必要があります。

著者紹介

友松哲也 (TOMOMATSU Tetsuya)
- 株式会社セゾン情報システムズ IoT担当マネージャー / 株式会社アプレッソ プロダクトストラテジスト

データ連携ミドルウェアのフィールドエンジニアとして、数多くのデータ連携、データ統合の現場を経験。2016年にセゾン情報システムズにて、安心・安全、確実なファイル転送ミドルウェア「HULFT」をIoTにも適用できるように進化させた最新プロダクト「HULFT IoT」の企画立案を行い、製造業を中心にIoT案件を推進。主にIoTのデータ転送の課題を解決すべく奔走中。