Microsoft StreamInsight

  • [アーティクル]

"Internet of Things" (モノのインターネット) をビルドする

Torsten Grabs
Colin Miller

 

最近、"Internet of Things" (IoT: モノのインターネット) に関する多くの話題があふれていますが、それにはもっともな理由があります。Ericsson 社の CEO である Hans Vestberg 氏は、2020 年までに 500 億台のデバイスが Web に接続されるだろうと推計しています (bit.ly/yciS7r [PDF ダウンロード]、英語)。この数字を考えてみると、現時点では 約 15 億台の PC が Web に接続されていて、10 億台近くの携帯電話が Web に接続されています。500 億台ということは、地球上のすべての人がそれぞれ 約 7 台のデバイスを Web に接続することになります。一方、市場調査会社の IDC は 2015 年までに 160 億台以上のデバイスがインターネットに接続されると推計しています (図 1 参照)。もう少し控えめな予測をする向きも確かにありますが、いずれにしても、これらの数字はインターネットの役割の大きな変化を示しています。つまり、インターネットは情報や娯楽を人々に提供することから、これまでにないデバイス対応アプリケーションへの接続を提供する方向へと変化しています。

Estimating the “Embedded Internet,” from IDC
図 1 IDC による「組み込み型インターネット」の推計

このように大きな数字がもっともであると考えられる理由は、ビジネス チャンスと必要性という強力な要因によって、ソリューションの急激な増加が後押しされているためです。最近の Economist 誌 (economist.com/node/17388368、英語) では、「... この趨勢はハイテク企業や政治家の野心を利するだけのものではない。実際にそのようなシステムが必要とされるために勢いが増している」と指摘しています。これらのソリューションについて、アプリケーション分野ごとの成長予測を図 2 に示します。たとえば、欧州におけるスマート エネルギー システムの施行の義務化は必要性に迫られたものです。エネルギーの使用をコントロールしなければ、本当に必要な発電設備の構築はできません。一方、ビジネス チャンスという点での好例は、どこにでもある自動販売機です。この自動販売機というデバイスがいったん Web に接続されれば、決して最適とはいえないスケジュール ベースではなく、各デバイスの必要に応じてサービス担当者を配備できます。その場所で需要が多いとき、中身が賞味期限切れに近いときなど、価格を動的に変えることも可能です。停電があれば、傷んだ商品を入れ替えるよう、直ちに通知を送信することも可能です。つまり、接続することによってまったく新たな効率の良いビジネス モデルが実現します。

Application Growth by Segment
図 2 アプリケーション分野ごとの成長予測

この変化の特徴を接続デバイス数の急増で示すと確かに目覚ましいものがありますが、やや誤解を生むかもしれません。というのは、これによって従来の組み込み型プログラマの何十万人もの雇用が創出されるというわけではありません。これらのデバイスは、分析、クラウド、Web アプリケーション、PC とモバイル インターフェイスなど、インターネットのあらゆる面とさまざまなデバイスを統合する複雑なソリューションが対象とするエンドポイントにすぎません。

そのため、現在 Web ベースのアプリケーションを構築しているすべての開発者は、このようなデバイスを統合する新たなビジネスや新たなビジネス モデルの開発に直面する結果になります。つまり、組み込み型の開発者でない人も、組み込みデバイスの構築に携わっていない人も、このビジネス チャンスについて十分に検討する必要が大いにあります。これまでに習得したマイクロソフト テクノロジのスキルは IoT の時代にも役立ちます。

デバイス データの分析を行う

「データは新たな通貨となった」とは、Windows Embedded チームの ジェネラル マネージャー Kevin Dallas が最近のインタビュー (bit.ly/wb1Td8、英語) で語った言葉です。現在のインターネット アプリケーションと比べると、IoT では情報の生成、管理、およびアクセスが問題になります。今日日常的に使用するインターネット アプリケーションと IoT アプリケーションを、扱うデータの特徴という点で比べてみましょう。おそらく何百万人もの人々が、多くの金融機関が用意したオンラインのしくみを使って各種の支払いや請求を行っています。毎月何度かログオンして、情報を表示し、支払いを行っているでしょう。このようなデータはすべて、システムとの対話を始めるときに従来型のデータベースに照会を行って取得します。ダウンロードするページの内容は重要 (支払い情報、個人情報など) で、サイズが大きい場合もあり、それらのデータを保持し続ける必要がありますが、対話の頻度はそれほど高くはありません。

これを、たとえば 5,000 万棟の建物 (商用および住居用) からの入力を受け取る、エネルギー管理システムと比べてみましょう。入力はシステム内部の複数のローカル エンドポイント (たとえば、各家庭) で生成され、バック エンドで 1 つに集約されます。そのデータの中には瞬間的な使用状況の情報もあり、これは課金情報として使われたり、建物に対する法規制に使用されることもあります。こうしたシステムには、そのエンドポイントでの現状や傾向をいったん把握できれば、必ずしも保持し続ける必要はなく、あまり価値の高くないデータを非常に高い頻度でやりとりする対話も含まれます。しかし、問題が発生する可能性のある状況、たとえば需要の急増により電力網の過負荷や停電のおそれがある場合などには、システムは直ちに応答できる必要があります。そのような場合には、情報をブロードキャストしてエネルギー消費を直ちに低減するようなことも考えられます。このようなシステムは受信データを絶えず分析し、時間の経過とともに傾向を比較して、停電のリスクが高まるようなパターンを特定する必要があります。

図 3 は IoT アプリケーションによくあるアーキテクチャを示しています。図の下部は、アプリケーションに対応する各種センサーを備えたさまざまなアセットやデバイスです。センサーは、通常、継続的にデータをフィードし、アプリケーションはそれを直ちに処理および分析します。場合によってはデバイス自体がローカルで処理の一部を行う場合も考えられます。これをローカル分析と呼び、.NET Micro Framework のようなツールを使って、デバイスがデータを送信する前にローカル処理を行えます。IoT アプリケーションはインターネット プロトコルを使ってデバイスのデータを送信し、そのデータを使用して全体分析を行います。全体分析の結果、たとえば電力網全体の正常性などのデータは、運用を管理するエンド ユーザーやビジネス意思決定者に提供されます。分析は、受信データから明らかとなった条件に基づいて自動的に措置を講じるシステムでも活用されます。この方法は、全体分析からのフィードバックをアセットが受信でき、それによりたとえば、挙動を変えたり、動作を改善したりできる場合には特に有効です。これらの対応を行うための全体分析は、結果をできる限り早く利用できるように、絶えず処理する必要があります。さらに、分析では現在時刻とセンサー データが提供するタイムスタンプを頻繁に参照します。したがって、このようなデータを単にデータベースに保存し、周期的に照会するのは、適切な方法ではありません。さいわい、Microsoft StreamInsight をすれば、これとは別のアプローチを採用できます。

Typical Architecture for Internet of Things Applications
図 3 IoT アプリケーションによくあるアーキテクチャ

Microsoft StreamInsight

Microsoft StreamInsight は、分析とクエリのためにデータをディスクに書き込むことなく、継続的な受信データに対してタイムリーな反応を行うように設計されています。多くの IoT アプリケーションは、受信データをソースから取得した後、ほぼリアルタイムに分析する必要があります。先に述べたスマート グリッド (次世代電力網) アプリケーションでは、電力需要の急増に直ちに反応して電力網のバランスを保つ必要があります。多くの IoT アプリケーションには同様のニーズと課題があります。それは絶え間ない分析が必要なデータ処理と、やむを得ない遅延です。データ ソースは絶えず新しいデータを生成するため、分析は途切れることなく行う必要があります。多くのシナリオでは、受信データの分析によってのみ明らかとなる状況を直ちに認識して対応する必要があります。したがって、少ない遅延で分析を行い、ほぼ即時に結果が利用可能になる必要があります。このような要件により、分析前にリレーショナル データベースにデータを保存することは実用的ではありません。

このようなアプリケーションをイベント駆動型アプリケーションと呼び、IoT はこの処理が非常に有用なシナリオの 1 つです。StreamInsight は拡張性が高く、遅延が少ないイベント駆動型アプリケーションを構築するための強力なプラットフォームです。StreamInsight は Microsoft SQL Server 2008 R2 から製品に含まれるようになりました。StreamInsight はイベント駆動型処理と多機能で高速な時間ベースの分析により SQL Server を補完します。StreamInsight を使うと、従来型のデータベースでレポートが作成される速度とは異なり、データの生成と同じ速度でビジネスの見識が提供されます。

分析結果を人間がすぐに利用することもできますが、アプリケーションがイベントに自動対応することも可能です。ビジネスは、よりタイムリーに、より意味のある情報を取得し、運用の一部を自動化することもできます。またセンサーやデバイスのデータから認識された、問題がある状況や、好機、傾向に対してより迅速に反応できます。

開発者は Microsoft .NET Framework、LINQ、Microsoft Visual Studio などの使い慣れたツールを使って、StreamInsight アプリケーションを作成できます。StreamInsight アプリケーションの開発と実行のエクスペリエンスおよびいくつかの重要な概念を図 4 に示します。

StreamInsight Application Development and Runtime
図 4 StreamInsight アプリケーションの開発とランタイム

簡単な IoT アプリケーション

IoT アプリケーションの例をさらに詳しく調べ、次にそれをビルドします。今回の例では、タービンや風車などの回転装置をモーション センサーを使って監視する、エンド ツー エンドの簡単なシナリオに着目します。　振動が多い場合にはすぐに停止しないと、装置の故障や破損などの重大な問題につながる可能性もあるため、これは重要です。こうした状況を確実に検出するため、装置各部の複数のセンサーで動きを追跡します。1 つのセンサーからの動きの急増だけでは、そのセンサーの読み取りの信頼性の問題かもしれません。しかし複数のセンサーが同時に異常な上昇を示す場合は、問題が発生しているとみなすべきです。たとえば、大きなタービンではアラームを鳴らしたり、または装置を自動停止させることを考えます。状況の継続的な監視に加え、オペレーターにダッシュボードを提供し、装置の状況をほぼリアルタイムに表示することも有効です。

このシナリオをビルドするには、次の要件と技術的課題に対応する必要があります。

  • デバイスは何のデータを取得するか
  • データの測定にどのセンサーを使うか
  • デバイスはセンサーの読み取り結果をどのようにインターネットに通信するか
  • 分析のために、デバイスのデータをどのように 1 か所に集めるか
  • どのようにして受信データを継続的に分析し、問題が発生した場合に迅速に反応するか
  • 複数のデバイスからのセンサーの読み取りを合わせて関連性をどのように判断し、全体の状況をどのように判定するか

ここからは、これらの要件にどのように対応し、エンド ツー エンドのシナリオを実装するかを見ていきます。

IoT アプリケーション: 実装の要点

ここまでに説明したように、IoT アプリケーションの実装にはいくつかの重要な手順があります。まず、デバイスについて説明し、次に出力の表示、さらに複数のデバイス間の分析とダッシュボードの設定へと進みます。

デバイス: センサー デバイスとして、128K SRAM を搭載し、.NET Micro Framework が稼働する、よく使われる小さな基盤である Netduino Plus を使います。カスタム PCB 基盤上にセンサーを搭載し、よく使われるホビー用 Wi-Fi 無線である WiFly GSX Breakout を加え、さらに三軸加速度計を追加しました。センサー読み取りの更新を毎秒 Web サービスに送信するようにデバイスをプログラムしました。送信先の Web サービスはすべてのデバイスからのデータを収集して処理するハブとして機能します。

Web サービスとの接続には、コンマ区切りの名前と値のペアを含む HTTP POST による RESTful 接続を使います。もちろん、これは HTTP をサポートするどのようなデバイスからでも可能ですが、今回は、デバイス、Web サービス、StreamInsight アダプター、Silverlight ダッシュボードなど、すべてのアプリケーションを 1 つのプログラミング モデル (.NET) とツール (Visual Studio) を使って作成できるように、.NET Micro Framework を使うことにしました。.NET のスキルがあれば、新たなスタッフを雇ったり、IoT プロジェクトのパーツを外部の組み込み開発者に外注する必要はありません。必要なスキルは揃っています。たとえば、加速度計のセット アップは、AnalogInput クラスにアクセスし、Read メソッドを呼び出すだけの数行のコードで済みます。

this.analogInputX = new AnalogInput(pinX);
this.analogInputY = new AnalogInput(pinY);
this.analogInputZ = new AnalogInput(pinZ);
...
rawZ = analogInputZ.Read();
rawY = analogInputY.Read();
rawX = analogInputX.Read();

センサー入力を読み取り、HTTP メッセージのコンテンツの書式を設定したら、それを送信します。このために必要な情報はすべて図 5 に含まれています。

図 5 センサー データの送信

protected void submitSensorData(string uri, string payload)
{
  // Message format
  StringBuilder sb = new StringBuilder(256);
  sb.Append(
    "POST /Website/Services/DataService.aspx?method=SaveDeviceData HTTP/1.1\n");
  sb.Append("User-Agent: NetduinoPlus\n");
  sb.Append("Host: 192.168.1.101\n");
  sb.Append("Connection: Keep-Alive\n");
  sb.Append("Content-Length: ");
  sb.Append(payload.Length.ToString());
  sb.Append("\n");
  sb.Append(payload);
  sb.Append("\n");
  try
  {
    HttpResponse response = webServer.SendRequest(uri, 80, request);
  }
  catch
  {
    ...
  }
}

サーバー側では SaveDeviceData メソッドを実装し、これに対してデバイスがメッセージを POST します。メッセージ文字列を分割し、MAC アドレス、タイムスタンプ、および加速度計の動きの読み取りなどのペイロード データを解析します。これらを使って DeviceData オブジェクトにデータを設定 (図 6 参照) し、それを StreamInsight に渡してその後の分析を行います。

図 6 DeviceData オブジェクトの設定

private int SaveDeviceData()
{
...
  List<string> data = record.Split(',').ToList();
  DeviceData deviceData = new DeviceData();
  deviceData.MAC = NormalizeMAC(data[0].Trim());
  deviceData.DateTime = DateTime.UtcNow;
...
  deviceData.Motion = Convert.ToDecimal(data[2].Substring(data[2].IndexOf(":") + 1));
...
  // Communicate each new device data record to StreamInsight           
  DeviceDataStreaming streaming = (DeviceDataStreaming)
    HttpContext.Current.Application[Global.StreamingIdentifier];
    streaming.TrackDeviceData(deviceData);
...
}

ダッシュボード: 装置のオペレーターにセンサー状態を表示するダッシュボードを作成します。ここでは表示の簡素化のため、1 つの装置のみに着目します。ダッシュボードの例を図 7 に示します。まず、左側にあるセンサー データの表示を見てください。

Dashboard for Equipment Monitoring
図 7 装置を監視するダッシュボード

移動平均の表示: 左下の表ではデバイスのセンサー読み取り値を、明るさ、温度、動きの値およびデバイス ID とタイムスタンプと共に示しています。タイムスタンプからわかるように、これらの値は毎秒更新されます。しかし、ダッシュボードはセンサー値そのものを表示するのでなく、センサー データの 10 秒間の移動平均を示しています。つまり、直近の 10 秒間の平均値を毎秒更新します。移動平均の使用は、低価格のセンサーで時折発生する異常値による影響を防ぐために、通常よく行われる簡単な手法です。

トレンドライン表示: ダッシュボードの右下にはセンサーのトレンドラインを表示しています。トレンドライン表示は左側の表に示す移動平均を使っています。

アラーム表示: 右上にはアラームを表示します。問題となる状態が検出されると、重要度、状況などの情報と時刻を示すアラームが上がります。

分析: この背後ではセンサーからの受信データを処理し、ダッシュボードが表示するための結果の計算を行う分析が行われています。この分析を行うのが StreamInsight です。次のクラスは、MAC アドレス、タイムスタンプ、センサー値など、デバイスのデータを表します。

public class DeviceData
{
  public string MAC { get; set; }
  public DateTime DateTime { get; set; }
  public decimal? Light { get; set; }
  public decimal? Temperature { get; set; }
  public decimal? Motion { get; set; }
}

このクラスは 1 つのイベントの形状を定義しますが、多数のイベントのことを考慮する必要があります。そのため StreamInsight の Observable データ ソースを定義します。このデータソースは、単に System.IObservable インターフェイスを実装するデータ ソースです。

public class DeviceDataObservable : IObservable<DeviceData>
  {
    ...
  }

このように Enumerable や Observable などの.NET Framework シーケンスを使うと、そのコレクションに対して StreamInsight のクエリを作成できます。ここでは、いくつかのクエリを取り上げ、その使用法について簡単に説明します。最初のクエリでは Observable を受け取り、StreamInsight イベントのタイムスタンプとしてデバイスの DateTime フィールドを使用して、StreamInsight のポイント イベントのストリームを生成します。次の LINQ ステートメントではこのストリームを入力として、データを MAC アドレスでグループ化します。グループごとに 10 秒ずつのホッピング ウィンドウ (時間に基づくイベントのサブセット) を適用し、それで毎秒再計算を行います。各ウィンドウで温度、明るさ、動きの平均を計算します。これでデバイスごとの移動平均が毎秒求めらます。結果を StreamInsight イベントのストリームとして返す関数にラップしたコードを図 8 に示します。

図 8 移動平均の算出

public static CepStream<AverageSensorValues> GroupedAverages(
              Application application,
              DeviceDataObservable source)
  {
    var q1 = from e1 in source.ToPointStream(application,
      e => PointEvent.CreateInsert(
        new DateTimeOffset(
          e.DateTime.ToUniversalTime()),e),
      AdvanceTimeSettings.StrictlyIncreasingStartTime,
      "Device Data Input Stream")
             select e1;
    var q2 = from e2 in q1
             group e2 by e2.MAC into groups
             from w in groups.HoppingWindow(
               TimeSpan.FromSeconds(10),
               TimeSpan.FromSeconds(1))
             select new AverageSensorValues
             {
               DeviceId = groups.Key,
               Timestamp = null,
               AvgTemperature = w.Avg(t => t.Temperature),
               AvgLight = w.Avg(t => t.Light),
               AvgMotion = w.Avg(t => t.Motion)
             };
    return q2;
  }

次に、アラームのためのクエリの実装について考えます。先に述べたとおり、アラームは複数のモーション センサーで同時にしきい値を超える動きあった場合にトリガーされます。これはグループの平均の計算値に対していくつかの StreamInsight LINQ ステートメントを使うだけで処理できます。最初のクエリ q3 ではちょっとした技を使って、アラームのしきい値の変化を AlarmThresholdSignal というイベント ストリームとして表しています。このクエリではまず、しきい値を前のクエリでの平均のストリームと結合し、次にしきい値を超えるイベントをフィルターします。

var q3 = from sensor in GroupedAverages(application, source)
         from refdata in AlarmThresholdSignal(application, alarmsthresholds)
         where (sensor.AvgMotion !=
           null && (double) sensor.AvgMotion > refdata.Threshold)
         select new
         {
           AlarmDevice = sensor.DeviceId,
           AlarmInfo = "This is a test alarm for a single device",
         };

次のクエリでは StreamInsight のスナップショット ウィンドウを使って、イベントの状態が変化する時点を特定します。新しいイベントが前のフィルター クエリによるものである場合、それが新しいスナップショットとなり、スナップショット操作によって、スナップショット ウィンドウのトリガーとなったイベントと同じかまたは部分的に重複するすべてのイベントを含む新しいウィンドウを作成します。次のコードは、スナップショット ウィンドウが作成されたときに、アラームのしきい値をこえるイベントをカウントします。

var alarmcount = from win in q3.SnapshotWindow()
                 select new
                 {
                   AlarmCount = win.Count()
                 };

最後に、カウントが複数のデバイスからのアラームを示しているかどうかをチェックします。

var filteralarms = from f in alarmcount
                   where f.AlarmCount >= 2
                   select new AlarmEvent
                   {
                     AlarmTime = null,
                     AlarmInfo = "Now we have an alarm across multiple devices",
                     AlarmKind = 0,
                     AlarmSeverity = 10,
                     AlarmStatus = 1
                   };

これであとは StreamInsight からのセンサーの値の平均とアラームの出力ストリームを UI に出力するだけです。

ストリームを UI に出力する

StreamInsight は、結果のストリームをサーバー側で生成するため、このストリームをユーザーに伝える方法が必要です。ユーザーは、通常、サーバー プロセスを実行しないため、結果を表示する簡単な Web アプリケーションを使うことにします。Silverlight を使う場合には、サーバーからクライアントへの連続的なプッシュ ベースの配信をサポートしている二重化プロトコルを使用すると便利です。HTML5 の WebSocket も有力な方法です。いずれにしても、UI と StreamInsight をホストするプロセスの間のクライアント サーバー インターフェイスを分断せずに、サーバー側で新しい分析を簡単に追加し、それを簡単に UI に結び付けるようにします。UI とサーバー間の負荷が通常レベルであれば、結果をサーバー側で XML にシリアル化し、クライアント サイドでシリアル化を解除します。そうすれば、クライアントとサーバー間のインターフェイスで使う XML と、シリアル化の解除に想定する型を示す Cookie のみの通信を考慮すればよいことになります。いくつかの主要コードを以下に示します。

最初のコード スニペットはイベント データを XML シリアル化文字列として、型を示す GUID と一緒に送信するための Windows Communication Foundation コントラクトです。

[ServiceContract]
public interface IDuplexClient
{
  [OperationContract(IsOneWay = true)]
  void Receive(string eventData, Guid guid);
}

図 9 に示すように、これで結果のイベント構造をシリアル化するために、データ コントラクトにより注釈を付けることができます。

図 9 イベント構造の注釈

[DataContract]
public class AverageSensorValues : BaseEvent
{
  [DataMember]
  public new static Guid TypeGuid =
    Guid.Parse("{F67ECF8B-489F-418F-A01A-43B606C623AC}");
  public override Guid GetTypeGuid() { return TypeGuid; }
  [DataMember]
  public string DeviceId { get; set; }
  [DataMember]
  public DateTime? Timestamp { get; set; }
  [DataMember]
  public decimal? AvgLight { get; set; }
  [DataMember]
  public decimal? AvgTemperature { get; set; }
  [DataMember]
  public decimal? AvgMotion { get; set; }
}

これで図 10 に示すように、サーバー側で結果イベントを容易にシリアル化し、クライアントに通信できるようになります。

図 10 結果イベントのサーバーからの送信

static public void CallClient<T>(T eventData) where T : BaseEvent
  {
    if (null != client)
    {
      var xmlSerializer = new XmlSerializer(typeof(T));
      var stringBuilder = new StringBuilder();
      var stringWriter = new StringWriter(stringBuilder);
      xmlSerializer.Serialize(stringWriter, eventData);
      client.Receive(stringBuilder.ToString(), eventData.GetTypeGuid());
    }
  }

クライアント側では、図 11 に示すように、まず二重化サービスのためにコールバック メソッドでイベントのシリアル化を解除し、次に受信したイベントの型によってそれぞれ異なるメソッドに分岐します。

図 11 クライアントでのイベントの受信とシリアル化解除

void proxy_ReceiveReceived(object sender, ReceiveReceivedEventArgs e)
{
  if (e.Error == null)
  {
    if (AverageSensorValues.TypeGuid == e.guid)
    {
      ProcessAverageSensorValues(Deserialize<AverageSensorValues>(e.eventData));
    }
    else if (AlarmEvent.TypeGuid == e.guid)
    {
      ProcessAlarms(Deserialize<AlarmEvent>(e.eventData));
    }
    else
    {
      ProcessUnknown();
    }
  }
}

クエリと Web アプリケーションへの通信がすべて揃ったので、さっそくデバイスをつかんで、アラームのしきい値を超えるまで振ってみましょう。図 12 に示すように、UI に赤いアラームが表示されます。

Equipment Dashboard with Alarms
図 12 装置ダッシュボードとアラーム

ダッシュボードにほぼリアルタイムで常に新しいデータが入ってくるため、UI 更新用の Observable コレクションは非常に有用です。この Observable コレクションのデータの表とトレンドラインを表示する場合、コードでこれらの更新について心配する必要はありません。コレクションが自動的に行います。

今後の展望

今回の実装ではデバイスは、インターネットに接続された普通の PC で稼働する通常の Web サービスと通信しています。もう 1 つ興味深いのがクラウド コンピューティングです。ハードウェアを所有して、自身の Web サーバー上でソフトウェアを実行する必要はありません。クラウド上のサービスがハブとして機能し、アプリケーション向けのすべてのデバイス データがそのハブで収集されます。またこれにより、デバイスの数が増えた場合や、デバイスのデータに別の分析を追加する場合に、処理能力の柔軟な拡張が非常に容易です。マイクロソフトは StreamInsight の機能を Windows Azure のサービスの 1 つとして提供することを計画しています (StreamInsight プロジェクトのコードネームは "Austin" です)。Austin はあらかじめ定義された通信のエンドポイントとプロトコルを提供し、マイクロソフトのクラウド上の豊富な分析処理機能にデバイスを容易に接続できます。IoT アプリケーションを Windows Azure で配置すれば、柔軟な拡張性と使用量に応じた課金というクラウドのメリットを享受しながら、デバイス接続を管理しデバイスのデータの豊富な分析を行えます。

最近の W3C の標準化作業に、もう 1 つの重要な動向があります。IoT アプリケーションにとって最も重要な構想は HTML5 と WebSocket です。HTML5 は今回実装したダッシュボードのような、リッチな Web アプリケーション向けプラットフォームを提供します。一方、WebSocket はブラウザーと Web サーバー間で TCP 経由の全二重通信を容易にします。特に、絶え間ないセンサー データの処理に必要な結果の送信を、プッシュ モデルで簡単に実現できるようになります。

接続型のデバイスはアプリケーションに非常に興味深い、新しい世界を開こうとしています。マイクロソフトではこれらの IoT アプリケーションをビルドするために、今すぐに活用できるツールを提供しています。今回は、使い慣れたインターフェイスを使って、.NET Framework のスキルをデバイス レベルで活用し、Web サービスを使ってデータを StreamInsight の強力な分析機能にフィードする方法を説明しました。接続型のデバイスを使って IoT アプリケーションのビルドを始めてみてください。

Torsten Grabs は Microsoft SQL Server 部門のリード プログラム マネージャーです。10 年以上にわたって Microsoft SQL Server 製品に携わっています。彼はスイスのチューリッヒのスイス連邦工科大学でコンピューター サイエンスの博士号を取得しました。

Colin Miller は 25 年間にわたり PC ソフトウェアに携わり、そのうち 15 年はマイクロソフトに勤務しています。データベース、デスクトップ パブリッシング、コンシューマー製品、Word、Internet Explorer、Passport (Live ID)、オンライン サービスなどを担当してきています。彼は .NET Micro Framework の製品部門のマネージャーです。

この記事のレビューに協力してくれた技術スタッフの Rafael Fernandez Moctezuma と Lorenzo Tessiore に心より感謝いたします。