IoT通信プロトコルで押さえるべき「5大ポイント」、導入時は何を重視すべきか？
コメント
注目のコメント
言葉がわからない人向けにこの記事を解釈しましたのでコメント読んで記事を読むと理解しやすいかもしれません。
人で例えると、世界中の人がお互いの考えを伝えようとするが、言語が異なります（＝プロトコル）
英語とポルトガル語は言語は違えど構文が似ており理解ができる（＝プロトコルの互換性）
それぞれの言語には特徴があり、英語は少ない音で意味を端的に表せる、日本語はオノマトペなど複雑な音を使い分けて様々な状況を表現するのが得意（＝プロトコルは状況や要件によって使い分ける必要があるため世界標準がない）
そうなるとDeepLのようないろんな言語を翻訳できるツールの重要性が増している（＝PTC KepwareとMatrikonは最もよく使用されるプロトコル・コンバーターの1つ）
最終的にどんな言語を選べばいいかというとケースバイケース。
経営者は世界でユーザーが多い言語は中国語、英語、ヒンディー語を使いたいというが、現場は運用改善のために意思疎通がしやすい日本語で会話したいという（＝他のプロトコルとの相互運用性とスケーラビリティは大企業にとって重要である一方、シンプルなDevOpsは中小企業に重要になる）
要は機械に設置されたデバイスで取得されたデータを集約する際にプロトコルを使用しなければなりません。
1秒間に膨大な量のデータを処理する必要があるのか、1分間に100MB程度のデータを処理すればよいのかによって使うITインフラサービスのスペックが異なります。
なので設計者もデータ集約において何をゴールとするのかを明確にしておかないと後で修正すると大変な作業になってしまうので特徴を理解した上でプロトコルは選択しましょう。IoTのプロトコル選定は、論理的な直感だけでなく、実環境でベンチマークすることが大切だと思います。
クラウドのIoTハブまで繋がらないとかは当然ですが、一見遅そうなhttpsの方が良かったりするケースもあります。
また、どこにIoTゲートウェイを置いて、その大量メッセージをどの様に処理しきるか、サーバーダウン時にどの様にリカバリするかの検討も大切。
例えば、クラウド迄QoS2(確実に送ったメッセージだけが到達できる方針)を膨大なIoTに求めるのではなく、時にIoTデータを水道水の様に考え、切れたモノはリトライさせずに捨てるQoS0にする、そういう類のデータをどれだけ増やせるかが設計難易度を激減させる方針となります。
一段上からの例えもですがJIT(ジャストインタイム)によるデータより現場を優先させる 疎結合な結果整合のアーキテクチャは、比較的容易にQoS0が選定できる優れた思想です。
QoS0でよければ、DR(災害時の復旧)スコープからリアルタイムのIoTデータを除外でき、復旧設計が簡単に、復旧速度は高速にできます。
この手の方針はベンダー丸投げでは決めきれず(あえて困難に突っ込み徐々に膨大な仕様追加の提案も...)、データ蓄積活用のユーザー部署から方針を明示してあげる必要が生じると思います。
また、アジャイル開発での方針変更も困難(投資バイアス強め)なので、IoTに関してはコミュニケーションコストを嫌わず、知識を集めての検討が肝要です。グローバル標準プロトコルが存在しないからこそ、導入者側にきちんと計画化をした導入が求められるということだと思います。
皆がつながることでこそ価値が得られるわけなので。
