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