情報の生成、管理、およびアクセスが問題になります。アプリケーションを、扱うデータの特徴という点で比べてみましょう。何百万人もの人々が、多くの金融機関が用意したオンラインのしくみを使って各種の支払いや請求を行っています。毎月何度かログオンして、情報を表示し、支払いを行っているでしょう。このようなデータはすべて、システムとの対話を始めるときに従来型のデータベースに照会を行って取得します。サイズが大きい場合もあり、それらのデータを保持し続ける必要がありますが、対話の頻度はそれほど高くはありません。入力を受け取る、エネルギー管理システムと比べてみましょう。そのデータの中には瞬間的な使用状況の情報もあり、これは課金情報として使われたり、建物に対する法規制に使用されることもあります。したシステムには、そのエンドポイントでの現状や傾向をいったん把握できれば、必ずしも保持し続ける必要はなく、あまり価値の高くないデータを非常に高い頻度でやりとりする対話も含まれます。問題が発生する可能性のある状況、たとえば需要の急増により電力網の過負荷や停電のおそれがある場合などには、システムは直ちに応答できる必要があります。そのような場合には、情報をブロードキャストしてエネルギー消費を直ちに低減するようなことも考えられます。このようなシステムは受信データを絶えず分析し、時間の経過とともに傾向を比較して、停電のリスクが高まるようなパターンを特定する必要があります。アプリケーションによくあるアーキテクチャを示しています。図の下部は、アプリケーションに対応する各種センサーを備えたさまざまなアセットやデバイスです。センサーは、通常、継続的にデータをフィードし、アプリケーションはそれを直ちに処理および分析します。場合によってはデバイス自体がローカルで処理の一部を行う場合も考えられます。ようなツールを使って、デバイスがデータを送信する前にローカル処理を行えます。プロトコルを使ってデバイスのデータを送信し、そのデータを使用して全体分析を行います。ユーザーやビジネス意思決定者に提供されます。分析は、受信データから明らかとなった条件に基づいて自動的に措置を講じるシステムでも活用されます。この方法は、全体分析からのフィードバックをアセットが受信でき、それによりたとえば、挙動を変えたり、動作を改善したりできる場合には特に有効です。これらの対応を行うための全体分析は、結果をできる限り早く利用できるように、絶えず処理する必要があります。データが提供するタイムスタンプを頻繁に参照します。したがって、このようなデータを単にデータベースに保存し、周期的に照会するのは、適切な方法ではありません。すれば、これとは別のアプローチを採用できます。分析とクエリのためにデータをディスクに書き込むことなく、継続的な受信データに対してタイムリーな反応を行うように設計されています。アプリケーションは、受信データをソースから取得した後、ほぼリアルタイムに分析する必要があります。アプリケーションでは、電力需要の急増に直ちに反応して電力網のバランスを保つ必要があります。アプリケーションには同様のニーズと課題があります。それは絶え間ない分析が必要なデータ処理と、やむを得ない遅延です。ソースは絶えず新しいデータを生成するため、分析は途切れることなく行う必要があります。多くのシナリオでは、受信データの分析によってのみ明らかとなる状況を直ちに認識して対応する必要があります。したがって、少ない遅延で分析を行い、ほぼ即時に結果が利用可能になる必要があります。データベースにデータを保存することは実用的ではありません。拡張性が高く、遅延が少ないイベント駆動型アプリケーションを構築するための強力なプラットフォームです。製品に含まれるようになりました。使うと、従来型のデータベースでレポートが作成される速度とは異なり、データの生成と同じ速度でビジネスの見識が提供されます。分析結果を人間がすぐに利用することもできますが、アプリケーションがイベントに自動対応することも可能です。ビジネスは、よりタイムリーに、より意味のある情報を取得し、運用の一部を自動化することもできます。センサーやデバイスのデータから認識された、問題がある状況や、好機、傾向に対してより迅速に反応できます。アプリケーションを作成できます。アプリケーションの例をさらに詳しく調べ、次にそれをビルドします。エンドの簡単なシナリオに着目します。振動が多い場合にはすぐに停止しないと、装置の故障や破損などの重大な問題につながる可能性もあるため、これは重要です。した状況を確実に検出するため、装置各部の複数のセンサーで動きを追跡します。つのセンサーからの動きの急増だけでは、そのセンサーの読み取りの信頼性の問題かもしれません。複数のセンサーが同時に異常な上昇を示す場合は、問題が発生しているとみなすべきです。大きなタービンではアラームを鳴らしたり、または装置を自動停止させることを考えます。状況の継続的な監視に加え、オペレーターにダッシュボードを提供し、装置の状況をほぼリアルタイムに表示することも有効です。このシナリオをビルドするには、次の要件と技術的課題に対応する必要があります。エンドのシナリオを実装するかを見ていきます。アプリケーションの実装にはいくつかの重要な手順があります。デバイスについて説明し、次に出力の表示、さらに複数のデバイス間の分析とダッシュボードの設定へと進みます。加え、さらに三軸加速度計を追加しました。サービスに送信するようにデバイスをプログラムしました。サービスはすべてのデバイスからのデータを収集して処理するハブとして機能します。