IoTテクノロジーとスマート スペースは新たな技術革命のきっかけとなることが期待されていますが、数十億のIoTデバイスが存在する一方で、これらのデバイス間の統一性が欠如していることが、業界の足かせとなっています。IoTデバイスはどのような課題に直面し、どのようなソリューションが役立つでしょうか。エンジニアは何ができるでしょうか。
IoTの最大の敵：断片化
現在、世界中にIoTデバイスがどれだけあるかを知ると本当に驚きます。現在の推定では、その総数は140億を超えており、2024年までに200億に達すると予想されています。世界中のデバイスの数を把握することさえ難しいだけでなく、生成されるデータの量も非常に膨大です。IoT技術の発展と生成されるデータの量のおかげで、AIや機械学習などの業界は急速に成長し、急速に拡大し、AIは日常生活に当たり前のものとなりました。
しかし、 多くのIoTデバイス 市場には数多くのスマートホームオプションが存在しますが、家庭で使用されるIoTデバイスのほとんどはスマートとは程遠いものです。実際、家庭で使用されているほとんどのIoTデバイスは、インターネット接続を形成できるという理由だけでIoTとして分類されており、他のシステムとデータを共有できないため、まったくスマートなことはできず、リアルタイムでイベントにインテリジェントに応答することもできません。さらに、ほとんどの家庭ではデフォルトでスマートテクノロジーが組み込まれておらず、ほとんどの家庭がスマートではない状態になっています。
IoTと家庭の統合を困難にしている要因は数多くありますが、これまでのところ最大の原因は断片化にあります。
IoTの断片化とは何ですか?
IoT業界には、断片化によって直面する問題を完璧に表現したジョークがあります。 簡単に言うと、エンジニアはIoT標準が14種類あることを認識し、誰もが使用できる標準を作成することを決定しました。これで標準は15種類になりました。
残念ながら、このジョークは現実と非常によく似ており、IoTデバイスを設計および製造する何百 (何千ではないにしても) ものIoT企業やエンジニアがまさにこれを行っています。これらの企業の多くは、独自の標準を作成するだけでなく (自分たちが最高だと考えている)、カスタム フレームワーク内で機能するソリューションのエコシステム全体を作成することもよくあります。これは、IoTソリューションに1つのメーカーのみを使用する人にとっては良いことかもしれませんが、スマート スペースの統合を妨げる多くの課題をもたらします。
これによって生じる最初の課題は、 異なるメーカーのデバイスを組み合わせた複雑なIoTソリューションを作成することの難しさ です。たとえば、スマートホームには、スマートドアベル、スマート電源ソケット、スマートライトからスマートサーモスタットコントロールに至るまで、多数のスマートデバイスが必要になります。市場にはこれらすべてのデバイスが存在しているにもかかわらず、これらすべてのデバイスを製造する単一の製造元、または共通のプロトコルをサポートする複数の製造元を見つけるのはほぼ不可能です。
IoTの断片化によって生じる2番目の課題は、スマート ホームに対するソフトウェア サポートの不足です。各メーカーが独自の標準を作成するのと同様に、デバイスの制御やデータの読み取りに使用する独自のソフトウェア プラットフォームも作成することがよくありますが、他のメーカーが使用できるようにAPIを公開することはほとんどありません。したがって、IoTデバイスのソフトウェア側も断片化され、他の開発者から隔離される可能性があります。
最後に、IoTソリューションに単一のメーカーを使用することを余儀なくされた顧客は、そのブランドに縛られてしまう可能性があり、さらに悪いことに、そのブランドが下したあらゆる決定に縛られることになります。たとえば、Hiveは最近、セキュリティ カメラや漏水検知器を含むHomeShield製品群の提供を終了すると発表しました。これらのデバイスの更新とサービスが停止されると、顧客は完全に使用可能なIoTデバイスを削除して廃棄するしか選択肢がなくなります。
物質とは何か？
IoTデバイスが直面している数多くの課題を認識し、大手テクノロジー企業のグループが集結し、もう十分だと声を上げ、新しいIoTプロトコル「Matter」を開発しました。Matterのリリースは、新しい標準を作成するという以前のジョークに従っていますが、多くの大手テクノロジー企業 (Google、Metaなど) がプラットフォームをサポートしているため、関与するテクノロジー企業の規模の大きさにより、メーカーは基本的に標準に参加することを余儀なくされます。
本質的には、 Matter はホームオートメーションの独自規格であり、認証費用のみでメーカーにロイヤリティフリーのライセンスを提供します。認証にはコストがかかりますが、Matterは完全にオープンソースとして公開されているため、ユーザーはコードの動作を確認したり、編集やバグ修正の提案を行ったりすることができます。認証を取得せずにMatterを使用した場合の罰則がどのようなものかは明らかではありませんが、製品にMatterの名前とロゴを付けることができない可能性があります (つまり、製品はMatterと互換性があるかもしれませんが、そのように宣伝することはできません)。
Matterプロジェクトは2019年に開始され、IKEA、Amazon、Google、Apple、Zigbee Allianceなど、多数のメーカーや企業が公にサポートを表明しています。ただし、このプロトコルは2022年10月に正式にリリースされたばかりであるため、まだ主流になったり、より広いコミュニティに採用されたりしていません。さらに、Matterの現在のバージョンは、照明製品、主電源スイッチ、サーモスタット、ドアロック、暖房システム、換気、セキュリティ センサー、テレビ、ブラインドなどの一般的な家庭用デバイスをサポートしています。2024年3月にリリース予定の次期バージョンでは、サポート対象デバイスのリストが拡大され、ロボット掃除機、COセンサー、煙探知機、エネルギー管理、Wi-Fi、カメラ、その他の主要家電製品が含まれるようになる。
物質に代わるものはあるのでしょうか?
現時点では、Matterと同程度の支持を得ているIoT標準規格は存在しませんが、エンジニアが接続性に優れたデバイスを作成するのに役立つ他の標準規格が存在しないというわけではありません。
これまでのところ、IoT通信で最もよく使用される方法はRESTとHTTPです。これは、ほとんどのWebサーバーが自然にこれらをサポートしているためです。つまり、IoTデバイスは、PHPまたはNode.jsでコーディングされた標準のWebサーバーにデータ パケットを送信できます。また、これらのプロトコルのもう1つの利点は、Webサイトを動かすために使用されるデータベースをIoTデータの保存にも使用できるため、データの表示が非常に簡単になるということです。したがって、理論上は、IoTソリューション全体を1つのWebサーバーに統合できます。
HTTPとRESTの代替として、Webソケットの使用があります。PHP、HTML、JavaScriptはすべてWebソケットをサポートしているため、IoTデバイスに最適です。ただし、HTTPとRESTは単一パケット メッセージであり、完了すると接続が閉じますが、Webソケットは開いたままにできるため、大量のデータをストリーミングするのに最適です。
最後に、 MQTT は、世界中の何百万ものデバイスで使用されているもう1つの一般的なプロトコルです。当初は石油・ガス業界向けに開発されたMQTTにより、デバイスのネットワーク全体で特定の変数を公開およびサブスクライブすることが可能になり、MQTTの軽量な性質により、低エネルギーおよびローエンドのマイクロコントローラーに最適です。さらに、プロトコルがシンプルなため、MQTTのカスタム実装は簡単に行うことができ、採用できる例がオンラインで多数あります。
エンジニアは何をすべきでしょうか?
HTTPとMQTTの両方において、設計者はAPIを公開して、少なくとも他のメーカーがデバイスとインターフェースするためのオプションを提供できます。さらに、2つの異なる標準規格を接続できるブリッジング ソフトウェアを作成することもできます。これにより、製品を他のメーカーと連携させることが容易になります。
しかし、これに加えて、Matter自体が非常に新しく、ドキュメントが非常に詳細かつ複雑であり、MatterがすべてのIoT製品にとって最適なソリューションではない可能性があるため、エンジニアが具体的に何をすべきかを言うのは困難です。もちろん、新しい標準を作成しても何の役にも立たないことは明らかであるため、エンジニアは可能な限り新しい標準の作成を避ける必要があります。
考えられる解決策の1つは、エンジニアが現場で簡単に変更できるオープンソース設計に重点を置くことです。 たとえば、無線による更新をサポートするLinuxシステムからIoTデバイスを作成すると、理論的には、将来Matterがプロトコルとして確立されたときにMatterをサポートするように更新できます。
もう1つの解決策は、エンジニアがHTTPやRESTなどの主流のソリューションに固執し、APIを一般に公開することでMatterが自社製品をある程度サポートできるようになることを期待することです。実際、IoTデバイスとMatterサーバーの間に位置し、両者の間でメッセージを翻訳できるWebインターフェイスを作成できる可能性があります。
しかし、物質が存在するからといって、それを使用すべきだというわけではありません。設計上不可欠でない限り、単にMatterをサポートする目的で統合すると、特に未知のバグがMatterに蔓延している場合は、メリットよりもデメリットの方が大きくなる可能性があります。
