IAP は、スマート ビルディング向けのより優れた LoRaWAN ソリューションを作成します

商業ビルの居住者は、施設にある程度のインテリジェンスと自動化を期待しており、不動産所有者は IoT による提供を急いでいます。 おそらくそれが、ビルの自動化および制御市場の複合年間成長率が、 21年までに2028%. 結局のところ、ファシリティ IoT は約束された未来のオフィスに到達する方法であり、最近のトレンドでは、スマート ビルディングは特権というよりも要件になっています。 

企業にはエネルギー目標があります。 IoT は、HVAC、照明などを自動制御することで、それらを満たすのに役立ちます。 リモートワークの台頭により、多くの未使用の施設スペースが生じています。 IoT は、これらのスペースを特定し、一時的なユーザー向けにパーソナライズして、すべての平方フィートを最適化する方法に関するデータを提供できます。  

これらの市場の力を考えると、問題はスマート ビルディング テクノロジに投資するかどうかではなく、その投資に対して大きな利益をもたらし、有線通信と無線通信の両方を使用するデバイスをサポートする方法です。 Long Range Wide Area Network (LoRaWAN) プロトコルは、WIFI デバイスよりも電力を必要とせず、Bluetooth デバイスよりも範囲が広いワイヤレス デバイスにとって有望なソリューションです。 オープンな非営利団体によって管理されています LoRaアライアンス, LoRaWAN は、低コスト、低電力、長距離ワイヤレス接続を作成します スマート ビルディング デバイスとそれらが動作するプラットフォームの間。 

問題は、インテグレーターが LoRaWAN デバイスを従来の有線ビルディング オートメーションおよび制御システム (BACS) に接続するのに苦労していることです。 新しい IoT アクセス プロトコル (IAP) がこの問題を解決します。 方法は次のとおりです。    

LoRaWAN デバイスをレガシー BACS に接続するための苦労

中規模以上の建物には、有線通信を使用するデバイスを備えた BACS が設置されている可能性が高く、BACS は IoT のイノベーションのペースに追いつくようには設計されていません。 何十年もの間、オペレーターはこれらのレガシー BACS プラットフォームを使用して、建物内のすべてのテクノロジー (HVAC、照明、アクセス制御、セキュリティ、エレベーターなど) を管理してきました。IoT を追加することで、これらすべてのシステムがかなりの有用性を獲得しています。 

ビルディング オートメーションを拡張したい場合は、個々の IoT デバイスから BACS にデータを送信する必要があります。 しかし、LoRaWAN 標準と一般的な BACS ネットワーク プロトコルの間には不一致があります。 BACS が認識する接続プロトコル (BACnet や LON など) は、非常に充実した規格です。 これらは豊富なデータ モデルを持ち、ネットワーク サービスを指定し、コマンド アンド コントロール機能を提供します。これらはすべて、BACS アーキテクチャ内で厳密に定義されています。 

LoRaWAN は、これらすべての BACS 定義にネイティブに対応していないため、強力な統合を作成するのは困難です。 最近まで、スマート ビルディング インテグレーターは、次の XNUMX つのアプローチのいずれかを使用して LoRaWAN デバイスをレガシー BACS に接続していましたが、どちらも理想的ではありません。 

• 手動データ ポイント マッピング。 まず、LoRaWAN デバイスを LoRa ネットワーク サーバーに接続します。 次に、サーバー内の各データ ポイントを BACS 内の対応するポイントにマップします。 BACS 側では、データ ポイントの基本的な意味の定義と構成を含め、自動化アルゴリズムを手動で構成する必要があります。 たとえば、温度の読み取り値が室内空間の温度読み取り値であることを BACS に伝え、そのデータ ポイントをどう処理するかをシステムに伝えるアルゴリズムを作成する必要があります。 これは、ビル システム インテグレーターによる多くのリソース集約型で時間のかかる手動構成です。 
• 静的コンテキスト ヘッダー圧縮 (SCHC) プロトコル。 BACS 側でデータ マッピングをハードコーディングしたくない場合は、SCHC が役立つ可能性があります。 この圧縮フレームワークは、LoRa パケット内に BACnet メッセージ全体を詰め込みます。 これにより、完全なエンドツーエンドの BACnet オブジェクト プロパティがデバイスから BACS に転送されます。 データ ポイントの定義は組み込まれています。問題が 6 つだけあります。インテグレータは独自に SCHC を実装できません。 プロトコルはデバイスに組み込む必要があります。つまり、デバイス メーカーだけがそれを実現できます。 さらに悪いことに、SCHC のスマート ビルディング デバイスは単純な LoRaWAN センサーよりも複雑であるため、最初に誰かが製造していると仮定すると、より高価になります。 製造業者が少数の場合、今日のサプライ チェーンの混乱により、そのような希少なデバイスのリード タイムは 12 ～ XNUMX か月になる可能性が非常に高くなります。

これらのアプローチはいずれも、IoT エッジ デバイスのインテリジェンスをサポートしていません。 すべてのデータ操作は BACS レベルで行われます。 また、ビルの自動化と制御における主要な通信プロトコルである BACnet のみをサポートしています。 IoT インフラストラクチャの一部が、照明制御用の LON、Modbus、または DALI、または工場用の産業用イーサネット プロトコルに依存している場合は、うまくいきません。 幸いなことに、現在 XNUMX 番目のオプションが利用可能であり、スマート ビルディング インテグレーターの仕事をより簡単にする態勢が整っています。  

BACS との LoRaWAN 統合のための IoT アクセス プロトコル (IAP) に対応

IAP、最近 ANSIとCTAで標準化は、産業用 IoT デバイスの情報、データ モデル、およびサービスの定義を一般化する、プラットフォームに依存しないデータおよびサービス アクセス プロトコルです。 簡単に言えば、スマート ビルディング インフラストラクチャ内のすべての要素を接続するデータおよびサービス ファブリックを作成します。これには、ビルディング オートメーションおよび制御ネットワーク内のエッジ デバイスによって提供される情報およびサービスの共通モデルが含まれます。 IAP を備えたエッジ サーバーをインストールして、LoRaWAN デバイスからのデータを BACnet、LON、Modbus、または事実上その他の BACS プロトコルを備えたシステムに変換および正規化し、BACnet、LON、または OPC を使用してワークステーションからすべてのデバイスのデータとサービスにアクセスします。 UA。 

IAP は デジタルツイン あなたのデバイスの。 各ツインは、選択した任意の BACS プロトコルを介して BACS によってアクセスされ、LoRa を BACS が理解できる言語に変換します。 BACnet サーバーを含むように IAP サーバーを設定すると、BACS は LoRaWAN デバイスを BACnet デバイスとして認識します。 それはとても簡単です。 煩雑な手動の統合、ハード コーディング、またはデバイス メーカーに SCHC のサポートを懇願する必要はもうありません。 今日の IAP エッジ サーバーの一部では、インテグレーターは、シンプルなユーザー インターフェイスとドラッグ アンド ドロップ ツールを使用して、ローコード環境で LoRaWAN と BACS の統合を作成することさえできます。 

さらに良いことに、IAP は非常にスケーラブルです。 施設の 33 つにインストールすると、IAP エッジ サーバーをインストールするだけで、すべての施設で同じデバイスとデータ ポイント構成を使用できます。 そして、IAP を備えたエッジ サーバーが結果を取得します。 英国の家具小売業者 DFS に聞いてみてください。同社は、IAP エッジ サーバーを使用して環境センサーなどを複数の施設の BACS プラットフォームに接続しました。 オープンなマルチプロトコル システムは、DFS のエネルギー使用量を削減するのに役立ち、このシステムを導入した典型的な小売店では、電気代を約 26%、ガス代を XNUMX% 節約しました。 同様の結果を探していて、レガシー BACS を手動で構成してハードコーディングしたくない場合は、IAP を調べてください。 あなたが待ち望んでいた LoRaWAN/BACS 統合ツールになるかもしれません。

ソース: https://www.iotforall.com/iap-creates-a-better-lorawan-solution-for-smart-buildings