送信先とパスフィルター - AWS IoT SiteWise
送信先を理解するパスフィルターを理解する

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

送信先とパスフィルター

AWS IoT SiteWise Edge の送信先は、産業用データがエッジデバイスからクラウドにどのように流れるかを管理するための柔軟で効率的な方法を提供します。このセクションでは、送信先を設定し、パスフィルターを使用して特定のデータストリームをルーティングし、ユースケースに適した送信先タイプを選択する方法について説明します。

でホストされている AWS IoT SiteWise Edge アプリケーションと組み合わせて使用するセルフホスト MQTT 対応、V3 ゲートウェイ、およびゲートウェイで、送信先とパスフィルターを使用できますSiemens Industrial Edge。送信先とパスフィルターは Classic Streams、V2 ゲートウェイでは機能しません。

トピック

AWS IoT SiteWise Edge の送信先を理解する

AWS IoT SiteWise Edge の送信先を使用して、ソースデータの送信先を決定します。コスト効率、低レイテンシー、ストレージ要件など、必要な特定の特性に基づいてデータ送信先を選択できます。、当社のパートナー AWS IoT SiteWise、またはカスタムアプリケーションによってキャプチャされたデバイスデータを統合して、エッジでパスフィルター (トピック) を発行およびサブスクライブします。その後、デバイスデータをモデル化、転送、クラウドに保存できます。

注記

セルフホストゲートウェイのすべての送信先機能を最大限に活用するには、最新バージョンの IoT SiteWise パブリッシャーと IoT SiteWise OPC UA コレクターにアップグレードします。ストリームのサポートは、既存のセットアップとの互換性を維持するために、 Classic ストリーム、V2 ゲートウェイで継続されます。詳細については、AWS IoT SiteWise Edge のクラシックストリーム、V2 ゲートウェイを参照してください。

SiteWise Edge の送信先がデータ管理を強化する方法

エッジから AWS IoT SiteWise にリアルタイムで、または Amazon S3 を使用してバッチでデータをエクスポートします。

送信先により AWS IoT SiteWise 、環境の柔軟性とスケーラビリティが向上します。送信先は、一元化されたデータ管理モデルを実装し、ソースはデータを中央システムに発行します。送信先は、パスフィルターを使用してデータの送信先を決定します。送信先は複数のパスフィルターをサブスクライブできます。

MQTT 対応ゲートウェイは、セルフホスト型か で実行されているかにかかわらずSiemens Industrial Edge、ローカル通信に MQTT を使用し、フィルターが に設定されたデフォルトのリアルタイム送信先が付属しています#。つまり、デフォルトでは、すべてのトピックのすべてのメッセージが AWS IoT SiteWise リアルタイム送信先に発行されます。詳細については、「AWS IoT SiteWise Edge 送信先のパスフィルターを理解する」を参照してください。各ゲートウェイに 1 つのリアルタイム送信先を追加できます。

送信先タイプ

ゲートウェイの送信先を設定する場合、2 つの主なオプションがあります。 を使用したリアルタイム設定と AWS IoT SiteWise、Amazon S3 を使用したバッファ設定です。各送信先タイプには、独自の設定と考慮事項のセットがあります。

AWS IoT SiteWise リアルタイム設定

これを選択すると、データを AWS IoT SiteWise ホット階層ストレージに直接送信し、リアルタイムでデータの取り込みとモニタリングを容易にします。リアルタイム設定は、特にゲートウェイでクラウドとの接続の問題が発生した場合に、データフローを管理します。接続が失われると、データはゲートウェイに一時的にローカルに保存されます。接続が再確立されると、保存されたデータは自動的にクラウドに送信されます。

データ発行プロセスのさまざまな側面を調整できます。例えば、ローカルに保存されるデータの最大量、再接続時にクラウドにデータを送信する速度、ストレージが容量に達した後にデータを削除するタイミングなどです。

AWS IoT SiteWise ストレージ階層の詳細については、「」を参照してくださいでデータストレージを管理する AWS IoT SiteWise。

AWS IoT SiteWise Amazon S3 設定を使用してバッファリング

この送信先タイプを使用すると、ゲートウェイでローカルにデータをバッファし、定期的に Amazon S3 バケットにバッチで送信できます。データは効率的な Parquet 形式で保存され、分析ワークロード用に最適化されています。データが Amazon S3 に保存されたら、そのデータを にインポートして AWS IoT SiteWise 保存、処理、分析できます。

データをバッチで取り込み、履歴データを費用対効果の高い方法で保存するには、このオプションを選択します。任意の Amazon S3 バケットの場所と、Amazon S3 にデータをアップロードする頻度を設定できます。 AWS IoT SiteWiseへの取り込み後にデータを処理する方法を選択することもできます。SiteWise と Amazon S3 の両方でデータを使用できるようにするか、Amazon S3 から自動的にデータを削除するかを選択できます。

ゲートウェイバージョン間で送信先機能を比較する

MQTT 対応ゲートウェイの送信先機能は、データフロー管理を合理化します。送信先は、さまざまなエンドポイントへのデータルーティングを一元的に設定することで、データ管理を簡素化します。このアプローチにより、複雑な個別のストリーム設定が不要になり、システム全体の柔軟性と管理が容易になります。

これに対して、Classic ストリーム、V2 ゲートウェイ、SiteWise Edge AWS IoT Greengrass は、データソースからパブリッシャーにストリーム経由でデータを送信し、データソースごとにデータ送信先を個別に設定します。

AWS IoT SiteWise 送信先機能を使用すると、パブリッシャーのルーティング設定が統合されます。送信先設定を使用すると、送信先とパスフィルターを一元的に管理できます。必要に応じて、送信先の追加、パスフィルターの管理、不要なフィルターや送信先の削除を簡単に行うことができます。

さらに、送信先機能は、産業用 IoT アプリケーションで広く使用されている業界標準のプロトコルである MQTT (Message Queuing Telemetry Transport) を使用します。この MQTT の導入により AWS IoT SiteWise 、さまざまなデバイスやシステムとの統合が容易になります。

送信先の制限

SiteWise Edge ゲートウェイの送信先に関する現在の制限は次のとおりです。

  • データ処理パックは MQTT 対応ゲートウェイではサポートされていません。

  • データ型のサポートは AWS IoT SiteWise データ型に制限されています。データ型変換を有効にする方法については、「」を参照してくださいサポートされていないデータ型の変換。

SiteWise Edge 送信先のユースケース

SiteWise Edge の送信先は、さまざまなアプリケーションで使用されます。主な例をいくつか示します。

産業用オートメーション
リアルタイムモニタリングと予測メンテナンス

産業環境では、ファクトリーフロアのセンサーとデバイスが SiteWise Edge にデータを発行できます。送信先は、関連するデータをフィルタリングしてルーティングするように設定できるため、マシンのパフォーマンスをリアルタイムでモニタリングおよび分析できます。パスフィルターを使用して関連する MQTT トピックにサブスクライブし、データを処理してから、処理されたデータを公開できます。このようにして、処理されたデータを AWS クラウド分析サービスまたはオンプレミスシステムに選択的にルーティングできます。その後、製造元は予測メンテナンス戦略を実装し、生産プロセスを最適化して、ダウンタイムを短縮できます。

スマートビル
エネルギー効率と稼働率の最適化

ビルディングオートメーションシステムは、データストリームを生成して、HVAC システム、照明、アクセスコントロールなど、ビルディングのさまざまな側面を監視および制御します。SiteWise Edge を使用すると、これらのデータストリームを取り込み、処理し、さまざまな送信先にルーティングできます。施設マネージャーは、関連するデータをフィルタリングして転送するように送信先を設定できます。これにより、データのプライバシーとコンプライアンスを確保しながら、エネルギー効率の測定や占有率の最適化などの高度な機能が可能になります。

これらのユースケースは、SiteWise Edge の Destinations 機能をどのように活用して、データを効率的に取り込み、処理し、ルーティングできるかを示しています。これにより、データのプライバシーとコンプライアンスを確保しながら、リアルタイムモニタリング、予測メンテナンス、エネルギー効率、リモート診断などの高度な機能が可能になります。

AWS IoT SiteWise Edge 送信先のパスフィルターを理解する

各送信先は、 AWS IoT SiteWise または Amazon S3 にデータをルーティングするように設定されています。パスフィルターを使用すると、送信先の MQTT メッセージを受信するときにフィルタリングする特定のデータを選択できます。パスフィルターは、データストリームの論理名を表し、目的の MQTT トピックのサブスクリプションとして機能します。

MQTT では、データはトピックに編成されます。トピックは、スラッシュ () で区切られた階層文字列です/。たとえば、デバイスは温度データをトピック に発行する場合がありますhome/livingroom/sensor1/temperature。ここで、 home/livingroom/sensor1はセンサーのパスまたは論理名を表し、 temperatureは発行されるデータ型を表します。

パスフィルターを使用して、ワイルドカード (+ および ) を使用して特定のトピックまたはトピックの範囲をサブスクライブできます#。+ ワイルドカードは、トピック階層の 1 つのレベルに一致します。たとえば、 home/+/sensor1/temperatureは home/livingroom/sensor1/temperatureと に一致しますhome/bedroom/sensor1/temperature。# ワイルドカードは、フィルターの最後に使用すると、複数のレベルに一致します。

パスフィルター名内の MQTT 仕様では通常許可されていないさまざまな文字を使用することもできます。これらの文字は、名前内で使用する場合、ワイルドカードとして機能しません。 は、元の命名構造を維持しながら MQTT コンプライアンスを確保するために、エンコードを使用してこれらの文字を AWS IoT SiteWise 変換します。この機能は、他のシステムからの既存の命名規則に対応するために特に役立ちます。詳細については、「パスフィルター名の特殊文字」を参照してください。

適切なパスフィルターを慎重に選択することで、特定の宛先に送信されるデータを制御できます。パスフィルターを使用して、データフローを IoT システムの要件に合わせて調整します。

パスフィルターの要件

を使用してパスフィルターを入力するときは AWS IoT SiteWise コンソール、次の点に注意してください。

  • パスフィルターは新しい行で区切られ、各行は個別のパスフィルターを表します。

  • 個々のパスフィルターは 1～65,535 バイトです。

  • パスフィルターを空白にすることはできません。

  • Null 値 (U+0000) は使用できません。

  • 一度に最大 100 個のパスフィルターまたは 65,535 文字を入力できます。いずれか早い方の制限に達しています。

  • 全体的な制限は、ゲートウェイ上のすべての送信先の合計で 20,000 パスフィルターです。

  • パスフィルター名内で %、#、+、および $文字を使用できますが、 AWS IoT SiteWise は自動的に URI エンコーディングに変換します。

パスフィルターのベストプラクティス

AWS IoT SiteWise 送信先のパスフィルターを作成するときは、データを効果的に管理するために以下の戦略を検討してください。

  • デバイス階層をミラーリングするようにフィルターを構造化します。例えば、製造設定 では、 は異なる生産ラインのすべてのマシンからデータをfactory/+/machine/#キャプチャします。

  • デバイスタイプ、場所、または関数に特定のレベルを使用します。例えば、factory/assembly-line/robot/temperature。または、スマート農業では、 を使用してfarm/+/crop/+/moisture、さまざまな分野のさまざまな作物の湿度レベルをモニタリングします。

  • ワイルドカードを戦略的に活用する: 1 つのレベルでバリエーション+に を使用し、それ以降のすべてのレベル#をキャプチャします。例えば、 はbuilding/+/+/energy-consumption、建物内のさまざまなゾーンや床のエネルギー使用量を追跡します。これは、最初の がすべてのフロアを+キャプチャし、2 番目の がすべてのゾーンを+キャプチャすることを前提としています。

  • 関連するデータをキャプチャするのに十分なだけ、将来の変更に対応するのに十分な柔軟性を持つフィルターを作成して、特異性と柔軟性のバランスを取ります。たとえば、 site/+/equipment-type/+/measurementでは、フィルター構造を変更せずに新しいサイトや機器タイプを追加することができます。

フィルターを徹底的にテストして、意図したデータをキャプチャし、IoT システムのアーキテクチャと目標に沿っていることを確認します。

OPC UA サーバーのパスフィルター

OPC UA サーバーの場合、パスフィルターは OPC UA タグ名に対応している必要があります。パスフィルターの最終レベルは、OPC UA タグ名と完全に一致する必要があります。たとえば、OPC UA タグが の場合Device1.Temperature、パスフィルターは になりますfactory/line1/Device1.Temperature。などの前述のレベルでワイルドカードを使用して、複数の本番稼働用ラインでタグをfactory/+/Device1.Temperatureキャプチャできます。パスフィルター名に特殊文字がある場合は、パスフィルター名の特殊文字「」を参照してください。

パスフィルター名の特殊文字

AWS IoT SiteWise は、OPC UA などの産業用プロトコルで一般的に使用される文字に対応しています。通常、標準 MQTT トピック名では許可されません。この機能により、産業システムと MQTT ベースのアーキテクチャのスムーズな統合が容易になります。

注記

特殊文字の処理は統合と移行に役立ちますが、互換性を高めるために、可能であれば新しい実装の標準の MQTT 命名規則に従うことをお勧めします。

産業ソースからデータを受信すると、 は特殊文字の URI エンコードを使用してトピック名を AWS IoT SiteWise 正規化します。

  • % は になります %25 (最初にエスケープ文字としてエンコードされます）

  • # が %23 になります

  • + が %2B になります

  • $ は になります %24 (トピックの開始時にのみ）

このエンコーディングにより、これらの特別な MQTT 文字を含むソースデータを MQTT トピック名として安全に使用できると同時に、元の産業命名規則を保持できます。

例 : パスフィルター名の特殊文字

産業トピック名が AWS IoT SiteWise パスフィルターにどのように表示されるかの例を次に示します。

  • Factory1/Line#2/Sensor+3 が Factory1/Line%232/Sensor%2B3 になります

  • Plant%A/Unit$1/Temp が Plant%25A/Unit%241/Temp になります

  • Site1/#Section/+Node が Site1/%23Section/%2BNode になります

でサブスクリプションを作成したり、トピック名を表示したりすると AWS IoT SiteWise、エンコードされていない元のバージョンが表示されます。エンコードは自動的に処理され、MQTT コンプライアンスが確保されます。