フューチャー 2 Advent Calendar 2019の 16日目の記事です。
15日はtomo-wbさんのhttps://qiita.com/tomo-wb/items/928c3db9942baa9ea2ffでした。
はじめに
ここ2,3年、業務系システムのIoTを設計構築することが自分と周囲で増えてきました。例えば工場IoTなどがその際たるものです。それらを通して毎回これ考慮しているな？と思ったことがでてきたので、自分なりにパターン化して整理しておきます。
もっと汎化できるぞ、これもあるぞ、などがあればコメントで教えて下さい。
対象について
- 業務系(主に工場系) IoTに興味がある方
- コンシューマ向けIoT（家電など）の観点は経験がないので語れません、すいません
よく話にあがること
- 拠点（デバイス/エッジ）からクラウドへの転送方法
- IoTアプリケーションデプロイ
- IoTデバイスの監視（デバイス管理）
- 通信経路（無線/有線）
- PLC
- DownLink（デバイスへの制御コマンドの発行）
順番に説明していきます。
1. デバイス(設備)側とゲートウェイの機能配置
設備からクラウドへのUpload側の手法については、本当にいつも話している気がします。
デバイスが工場の生産設備の場合はよくGateway機器（Windowsベース、Linuxベース色々）があり、そちらを経由してクラウドへ送信するケースです。
このときは、以下のように幾つかのバリエーションがあります。
- Gatewayから設備へPullする
- 設備からGatewayへPushする
オプションとしては、FTP Client/Serverや Windowsならファイル共有、Socketを開いて独自プロトコルでガンバルなど色々あります。
ここで重要になるのは、 設備 の先端（エッジ）になればなるほど、アプリケーショのデプロイライフサイクルが遅くなる ということです。
そのため、多少処理がヘビーになっても 機能をなるべくGatewayやクラウドに寄せたほうが賢い選択肢になる ことが多いです。もちろん、設備側にもある程度のプログラムを仕込むことが可能なケースも多いですが、多くはIoT接続台数を増やす足かせになります。
しかし、クラウド側に各設備デバイス固有のロジックに対応したくないものです。
そこでGatewayにかなり固有のロジックを組み込むことも増える設計を考えるかと思います。これは設計上よく思いつくのですが、なんやかんやこのGatewayが問題になることが多く、テストも大変なので結局クラウド側で、標準化処理のレイヤを入れることが多いなと思います。
Gatewayは言ってみれば組み込み～オンプレミスに近い領域ですので、そういったエンジニアが確保しやすい場合は別ですが、一般的にはクラウド側に寄せたほうが、デプロイ・ログ・モニタリングその他のエコシステムが優秀ですので生産性が上がりやすいと思います。
2. IoTアプリケーションのデプロイ
デプロイはハッキリ言って大変です。場合によっては現地の工場にいって作業することも多いです。
言うて現地でデプロイするだけでしょ。観光気分で良いやん。現場面白そうだし
...と思ったときもありましたが、2回目移行は苦痛な場合が多いです。現場は何度行ってもワクワクしますが、アプリケーションのデプロイはかなり緊張しますし、実際にしくじると影響度も大きいです。
現地作業の問題はたくさんあり...
- そもそも作業スペースが無いので座って作業する
- 限られたメンバーで特殊な作業をするので連携が取りにくい（電波がそもそも弱いなどもありえる）
- 予期せぬトラブル（回線がおかしかったりHW側の不備などもある）
があり、とてもパフォーマンスが出ないです。
逆にオフィスの4Kディスプレイや外部キーボードなどの環境は非常に生産的だなと気づくキッカケにもなります。
現地作業をしないために...
拠点側のデバイスやゲートウェイに、SSH接続できる環境であれば問題ない事が多いです。
ただ、セキュリティ的に（いくらLAN内であっても）SSH接続は許可することができないポリシーを持つことも多いです。そもそも外出でLANに接続できないケースもあるでしょう。
こういった時に革命的だったのが、今年2019年に初めて存在を知った SORACOM Napeter でした。なんと、SIMで接続されたサーバに対して、Webコンソールから設定すると、その瞬間だけSSHポートをRDPポートを指定時間（1時間のみなど）開放することができます。
（SORACOM Napterページより）
実際に利用した時間のみの開放ですし、操作ログも残ることもあり、これを導入してからはかなり快適でした。
こういったリモートでSWのデプロイができる仕組みを、開発初期から整えることが重要です。
3. IoTデバイスの監視（デバイス管理）
デバイスの監視はかなり難しいです。
拠点側の特性によっては接続するデバイスが突然、切断することもままあります。
例えば工場ですと、ライン変更で関連する設備がNWレベルで接続断になることが通常業務であります。こういった生産技術的なライン変更のスケジュールをIoTシステム側に連携してもらうのは中々敷居が高く難しいものです。
必ず1日に1度、クラウド側にデータを送信すると行ったルールが決まっているのであればチェック可能ですが、仮にそういった制約が無い場合は、HealthCheck用の信号をデバイス側から適時送る処理を追加してもらうことも考慮が必要です。（もちろん、これがIoT接続台数を増やす足かせになる可能性もあるので、場合によっては上位のクラウド側から信号をPushすることも十分考慮してください。クラウドがデバイスに依存することを避けたいし、デバイスのポートは閉じている事がほとんどだと思いますが、それでもなるべくデバイスにロジックを追加することを避けた方が良いです）
4. 通信経路（無線/有線）
通信経路ですが、LTEはもとより5Gも注目が集まりだしましたが無線はどうでしょうか？
結論を言うと、配線は面倒ですが結論は有線が通信も安定しますし楽です。そのため、SWエンジニアの立場では有線でできる部分は全て有線でいくのが良いプラクティスになると思います。
もし、無線であればほぼLTE通信の選択になることが多いでしょう。WiFiであれば有線引けるでしょ、となる。
LTEの場合は、通信量やバッテリの制約に直面するため、通信頻度をどう下げることが許容できるかといったトレードオフを考えることになります。
もし、有線の場合はデータ転送量をそこまで気にしなくて良くなるので、HTTP(s)で富豪的に通信可能になるでしょう。MQTTもIoT系だとよく利用されますが、構成要素が増える関係で（HTTPサーバで済むところが、MQTTブローカ＋後続のSubscriberが必要）、障害点や運用ポイントが増えるので私の見解としては非推奨です。
5. PLC
PLCについては↓のスライドをぜひ参考ください！
スライドに色々と記載していますが、生産設備系ですとPLCは避けては通れない存在です。
通常はPLCといっても、PLCにSocket通信でデータを取得できる！といった簡単な話ではなく、直接は怖いので中継用のPLCを用意して、その中継機に対してSocket通信でデータを取得することが多いです。
とは言え、場合によっては設備PLCに読み取りにいくこともあります。このあたりはどのような用途にPLCを使っているかや、通信処理量や頻度に依存することも多いです。現場の生産技術の方と仲良くなって信頼を勝ち取りつつ、最適な配置をディスカッションしていくことが大事だと思っています。
6. DownLink（デバイスへの制御コマンドの発行）
デバイス側へのDownlink（何かしらの制御コマンドの送信）は常に行いたくなる要望です。
これが上手くハマると、現場の方としてはかなり未来を感じてもらえるので、何かしら早期に実現したいポイントの一つだと思っています。
一方で、設備デバイス側にポートをリッスンさせて開放するのはかなりリスキーな行為です。通常は許されないでしょう。
この時、よくあるのがデバイス側からのUploadのついでに制御信号を送ったり、デバイス側からポーリングする手法や、MQTTやWebSocketのようにデバイス側からサーバへアウトバウンドで通信してもらって、そのサーバが制御信号をプッシュする方法です。
結局はどの方法もサーバを経由して制御コマンドをデバイスに渡すことになります。
MQTTやWebSocketを利用するケースは、命令が瞬時（といっても数秒かかることもある）に伝播されるので、人間系へのプッシュ通知に利用したい場合によく利用されることが多いと思います。
言うまでもないですが、制御系は仕組みとしては非常に面白いですが振り下ろし先のデバイスによっては物理的な制御が伴う可能性があり、セキュリティを始めとしてSWの信頼性はかなり高める必要があります。まずはパトランプを光らせるなど、人間系への通知から始めるなどステップアップしていくことがオススメです。
まとめ
業務系のIoTシステムの設計上、よく話題になることをまとめました。
ほぼ工場系を例にしていますが、中には汎用的な内容も多いと思います。
他にも以下のようなネタがあるので、余裕があれば追記していきたいと思います。
- 可用性レベル（特に工場）
- 鍵の管理
- 機能配置
- 可視化
ここまで読んでくれてありがとうございます。
明日は、rkyymmt@githubさんの「Edge AI か Scala ではない何か」です。お楽しみに！