今日のオリジナル番組


詳細を確認
どこでも栽培可能!?「農業イノベーション」
本日配信
159Picks
Pick に失敗しました

人気 Picker
IoTのプロトコル選定は、論理的な直感だけでなく、実環境でベンチマークすることが大切だと思います。

クラウドのIoTハブまで繋がらないとかは当然ですが、一見遅そうなhttpsの方が良かったりするケースもあります。

また、どこにIoTゲートウェイを置いて、その大量メッセージをどの様に処理しきるか、サーバーダウン時にどの様にリカバリするかの検討も大切。

例えば、クラウド迄QoS2(確実に送ったメッセージだけが到達できる方針)を膨大なIoTに求めるのではなく、時にIoTデータを水道水の様に考え、切れたモノはリトライさせずに捨てるQoS0にする、そういう類のデータをどれだけ増やせるかが設計難易度を激減させる方針となります。

一段上からの例えもですがJIT(ジャストインタイム)によるデータより現場を優先させる 疎結合な結果整合のアーキテクチャは、比較的容易にQoS0が選定できる優れた思想です。

QoS0でよければ、DR(災害時の復旧)スコープからリアルタイムのIoTデータを除外でき、復旧設計が簡単に、復旧速度は高速にできます。

この手の方針はベンダー丸投げでは決めきれず(あえて困難に突っ込み徐々に膨大な仕様追加の提案も...)、データ蓄積活用のユーザー部署から方針を明示してあげる必要が生じると思います。

また、アジャイル開発での方針変更も困難(投資バイアス強め)なので、IoTに関してはコミュニケーションコストを嫌わず、知識を集めての検討が肝要です。
グローバル標準プロトコルが存在しないからこそ、導入者側にきちんと計画化をした導入が求められるということだと思います。
皆がつながることでこそ価値が得られるわけなので。