Il presente articolo è stato tradotto automaticamente.

Microsoft StreamInsight

Creazione di una rete Internet per tutti gli usi

Torsten Grabs
Colin Miller

 

C'è un sacco di buzz su "Internet of Things" (IoT) ultimamente e per buoni motivi. Ericsson CEO Hans Vestberg stima 50 miliardi di dispositivi saranno collegati al Web entro il 2020 (bit.ly/yciS7r [Scarica PDF]). Mettere questo numero in prospettiva, in questo momento ci sono circa 1,5 miliardi di PC connesso a Internet e meno di 1 miliardo di telefoni connesso al Web — 50 miliardi è circa sette dispositivi per ogni essere umano sul pianeta! Ricerche di mercato IDC ferma a sua volta stima che più di 16 miliardi di dispositivi saranno collegati a Internet entro il 2015 (vedere Figura 1). Certo, alcune proiezioni più conservatori esistono pure, ma da un numero di chiunque questo rappresenta un enorme cambiamento nel ruolo di Internet — dal fornire informazioni e intrattenimento alle persone per fornire la connettività per una classe emergente di applicazioni che supportano il dispositivo.

Estimating the “Embedded Internet,” from IDC
Figura 1 la stima "Internet incorporato," da IDC

La ragione di questi grandi numeri sono plausibili è così potente driver — opportunità e necessità — sono propulsione un rapido aumento di tali soluzioni. Come degli ultimi numeri di The Economist (economist.com/node/17388368) Note "… il carrozzone non è solo a rotazione a beneficio di aziende di tecnologia e ambiziosi politici. Esso ha acquisito slancio perché c'è un reale bisogno di tali sistemi." Figura 2 mostra la crescita di questo tipo di soluzione dal campo di applicazione. Ad esempio, l'implementazione incaricato di sistemi intelligenti di energia in Europa è guidato dalla necessità. Noi non possiamo costruire la capacità di generazione di energia necessaria se non riusciremo anche uso di energia. Sul lato di opportunità, la semplice, onnipresente Distributore automatico è un buon esempio. Una volta che il dispositivo è collegato, il personale di servizio possono essere indirizzati quando necessario, piuttosto che su qualche programma non ottimale. I prezzi possono persino essere dinamicamente alterati se ci ha aumentato la domanda locale o se i contenuti sono avvicinando la scadenza. Interruzioni di alimentazione possono essere segnalati a innescare la sostituzione degli articoli deperibili immediatamente. In altre parole, la connettività consente un modello di business completamente nuove e più efficienti.

Application Growth by Segment
Figura 2 applicazione crescita dal segmento

Che caratterizzano questo spostamento facendo riferimento al numero di dispositivi collegati è certamente drammatico, ma esso è anche un po ' fuorviante — non si tratta di piena occupazione per le centinaia di migliaia di programmatori incorporati tradizionali. Questi dispositivi sono solo gli endpoint per soluzioni complesse che si integrano altri dispositivi in tutti gli aspetti di Internet, tra cui analytics, nube, applicazioni Web, PC e mobile interfacce e molto altro ancora.

Il modo di guardare a questo è che tutti attualmente costruire applicazioni Web-based si troverà ad affrontare con integrazione di dispositivi e contribuendo a sviluppare nuove imprese e nuovi modelli di business di conseguenza. In altre parole, anche se non sei uno sviluppatore incorporato e non funzionano in un negozio che costruisce i dispositivi embedded, questa è un'opportunità molto interessante per voi di valutare. Tue attuali capacità di Microsoft vi permetterà di riuscire all'IoT.

Esegue analisi sui dati del dispositivo

"Dati sono diventata la nuova moneta," ha affermato Kevin Dallas, general manager del team Windows Embedded in una recente intervista (bit.ly/wb1Td8). Rispetto agli attuali applicazioni di Internet, l'IoT parla di accesso, la gestione e la generazione di informazioni. Confrontiamo le caratteristiche dei dati di una tipica applicazione Internet oggi con un'applicazione Internet degli oggetti. Ti e forse parecchi milioni altri pagare le bollette on-line utilizzando un meccanismo popolare che è condivisa da molti istituti finanziari. Accedere più volte al mese, visualizzare alcune pagine e presentare le informazioni sul pagamento. Tutto questo è disegnata da un database tradizionale con le query di quando si inizia a interagire con il sistema. Le pagine che Scarica possono essere grande, ma le interazioni sono molto scarsa, anche se essi generano informazioni preziose (informazioni di pagamento, gli aggiornamenti delle informazioni personali e così via) che ha bisogno di essere conservati a tempo indeterminato.

Contrasto questo con un sistema di gestione di energia dove ci potrebbero essere 50 milioni di edifici (commerciale e residenziale) che fornisce input. L'input viene generato da più endpoint locale all'interno, ad esempio, una casa, con un'unica vista aggregata inviata al back-end. Che i dati includono informazioni di utilizzo istantaneo che diventa la base per prezzo e fatturazione, e possibilmente obbligatori controlli, torna a Palazzo. Questo sistema comporta interazioni molto frequente con dati relativamente basso valore che non sono necessariamente interessanti una volta si calcola lo stato corrente del sistema e, possibilmente, i dati di tendenza per quell'endpoint. Tuttavia, il sistema deve essere in grado di rispondere immediatamente alle situazioni che potenzialmente minacciano, come ad esempio i picchi di domanda che possono causare l'overload griglia e interruzioni dell'alimentazione. In tal caso, trasmette le informazioni potrebbe ridurre il consumo energetico immediatamente. Tale sistema deve continuamente analizzare i dati in ingresso e confrontare le tendenze nel tempo per identificare i modelli che indicano un rischio maggiore di interruzioni dell'alimentazione.

Figura 3 illustra un'architettura tipica per le applicazioni Internet degli oggetti. Parte inferiore dello stack mostra vari beni o dispositivi che vengono instrumentati con diversi tipi di sensori dipende l'applicazione. I sensori producono generalmente i feed di dati continui che l'applicazione deve elaborare e analizzare rapidamente. Dipende dalla sua capacità, il dispositivo stesso potrebbe essere in grado di fare un po' del trattamento localmente. Questo è chiamato analisi locale e strumenti come il.NET Micro Framework può aiutarvi a eseguire tale elaborazione locale prima che il dispositivo passa sui dati. IoT applicazioni utilizzano protocolli Internet per passare lungo i dati del dispositivo in modo che analisi globale possono essere eseguite sui dati. I risultati di analisi dei dati globali, quali la salute generale di una griglia di potenza, sono di interesse per gli utenti finali che gestire operazioni o per decisori aziendali. Analytics può guidare anche sistemi chiusi che agire automaticamente in base alle condizioni ha rivelate nei dati in arrivo. Questi approcci sono particolarmente potenti se beni possono ricevere un feedback da analytics globale, ad esempio, per eseguire una modifica nel comportamento o per migliorare le operazioni. L'analisi globale alla guida di questi processi hanno bisogno di essere calcolato continuamente e i risultati resi disponibili più velocemente possibile. Inoltre, l'analisi si riferiscono spesso di tempo e di timestamp forniti con i dati del sensore. Quindi, solo mettendo questo tipo di dati in un database e l'esecuzione di query periodiche su di esso non è l'approccio giusto. Fortunatamente, Microsoft StreamInsight consente un approccio diverso.

Typical Architecture for Internet of Things Applications
Figura 3 tipica architettura per l'Internet delle cose applicazioni

Microsoft StreamInsight

Microsoft StreamInsight è progettato per fornire tempestive reazioni a continuamente che arrivano i dati senza la scrittura dei dati su disco per l'analisi e l'interrogazione. Molte applicazioni IoT necessitano analizzare i dati in arrivo in tempo quasi reale — subito dopo i dati viene acquistati dalle fonti. Pensare di tale applicazione smart grid abbiamo accennato che ha bisogno di reagire rapidamente ad un'impennata della domanda di energia elettrica per riequilibrare la rete elettrica. Molte applicazioni IoT hanno gli stessi bisogni: trattamento dei dati che richiede continue analisi e latenza convincente. L'analisi deve essere continuo, perché le fonti di dati incessantemente producono nuovi dati. E molti scenari bisogno di identificare e di reagire rapidamente alle condizioni che diventano evidenti solo dall'analisi dei dati in ingresso, così essi richiedono l'analisi di bassa latenza con risultati disponibili quasi immediatamente. Questi requisiti rendono impraticabile per memorizzare i dati in un database relazionale, prima di eseguire l'analisi.

Noi chiamiamo queste applicazioni basate sugli eventi applicazioni, e l'IoT è solo uno scenario dove tali capacità sono molto utili. StreamInsight è una potente piattaforma per la creazione di queste applicazioni altamente scalabili, bassa latenza, basate sugli eventi. A partire dalla versione 2008 R2 è stato parte di Microsoft SQL Server. StreamInsight complementi di SQL Server con l'elaborazione basata su evento e ricco, espressivo analytics basata sul tempo. Con StreamInsight, visione viene consegnato alla velocità che dei dati viene prodotta, in contrasto con la velocità alla quale vengono elaborate relazioni database tradizionale.

Risultati analitici che sono disponibili per il consumo umano subito o che consentono un'applicazione rispondere agli eventi automaticamente aiutano le imprese ottenere una visualizzazione accurata e più rilevante nelle loro operazioni, o automatizzare parti delle loro operazioni. Può reagire più rapidamente anche a situazioni critiche, opportunità o tendenze emergenti dai dati di sensore o dispositivo.

Per scrivere applicazioni StreamInsight, gli sviluppatori di utilizzare strumenti familiari, quali Microsoft.NET Framework, LINQ e Microsoft Visual Studio. Figura 4 raffigura l'esperienza dello sviluppatore e runtime di un'applicazione StreamInsight e presenta alcuni dei concetti chiavi.

StreamInsight Application Development and Runtime
Common Language Runtime e lo sviluppo di applicazioni di StreamInsight figura 4

Un'applicazione semplice IoT

Diamo un'occhiata più in profondità ad una potenziale applicazione Internet degli oggetti; quindi noi costruire fuori. Nel nostro esempio to-end, metteremo a fuoco su uno scenario semplice che utilizza sensori di movimento per monitorare apparecchiature rotanti come turbine o i mulini a vento. Ciò è essenziale perché troppo vibrazione potrebbe puntare a condizioni critiche in cui l'apparecchiatura è suscettibile di abbattere e causare danni significativi se non fermato rapidamente. Per rilevare in modo affidabile questa condizione, ogni singolo macchinario ha sensori multipli, rilevamento di movimento. Un'impennata in movimento da un singolo sensore potrebbe indicare solo letture inaffidabili dati dal sensore di tale, ma anormalmente alto moto da sensori multipli allo stesso tempo è considerata una condizione critica. Per una turbina di grandi dimensioni, ad esempio, si sarebbe probabilmente desidera alzare un allarme o anche spegnere le apparecchiature automaticamente. Oltre a controllare continuamente per queste condizioni, vogliamo anche dare agli operatori una dashboard che fornisce una visualizzazione tempo quasi reale dello status di attrezzature.

Per costruire fuori questo scenario, dobbiamo affrontare le sfide tecniche e requisiti seguenti:

  • Quali dati il dispositivo ha bisogno di catturare?
  • Sensori di quello che si utilizza per misurarla?
  • Come il dispositivo comunicare sue letture sensore a Internet?
  • Come raccogliamo i dati del dispositivo in un unico luogo per analytics?
  • Come possiamo continuamente analizzare i dati in ingresso e reagire rapidamente a condizioni critiche?
  • Come noi correlare letture sensore nel tempo attraverso dispositivi multipli così noi possiamo verificare per condizioni globali?

Diamo un'occhiata a come affrontare questi requisiti e implementare lo scenario end-to-end.

Un'applicazione IoT: Implementazione Highlights

Ecco alcuni dei passaggi chiavi per implementare un'applicazione IoT come descritto nella sezione precedente. Discutere il dispositivo in primo luogo, saltare per la visualizzazione dell'output e quindi spostare l'analisi attraverso dispositivi che popolano il cruscotto.

Il dispositivo per costruire un dispositivo sensore, abbiamo iniziato con il Netduino Plus, un popolare piccolo bordo con 128 KB SRAM che corre il.Micro NET Framework. Abbiamo aggiunto un hobbysta comune radio Wi-Fi chiamato il WiFly GSX Breakout e montati i sensori reali, tra cui un accelerometro a tre assi, su una tavola di PCB personalizzato. Abbiamo programmato il dispositivo di inviare un aggiornamento delle letture sensore ogni secondo a un servizio Web che funge da hub per raccogliere ed elaborare i dati da tutti i dispositivi.

Stiamo usando una connessione riposante con il servizio Web — solo un HTTP POST contenente coppie nome-valore separate da virgole. Naturalmente, è possibile farlo da qualsiasi tipo di dispositivo che supporta HTTP. Abbiamo optato per utilizzare il.NET Framework Micro affinché l'intera applicazione — tra cui i dispositivi, il servizio Web, le schede di StreamInsight, il cruscotto di Silverlight e così via — potrebbe tutti essere scritto utilizzando un unico modello di programmazione (.NET) e strumento di catena (Visual Studio). Chiaramente, se avete.Abilità di netta, non hai bisogno di assumere nuovo personale o fattoria le parti del vostro progetto IoT a un negozio esterno incorporato; si hanno le competenze necessarie per fare tutto. Ad esempio, impostare l'accelerometro richiede solo poche righe di codice per accedere alla classe AnalogInput e chiamare il metodo di lettura:

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

Una volta l'input del sensore viene letto e il contenuto del messaggio HTTP formattato, tutto ciò che ha richiesto di inviare esso è incluso nel Figura 5.

Figura 5 presentare dati di sensore

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
  {
    ...
}
}

Sul lato server, abbiamo implementare il metodo SaveDeviceData, a cui i dispositivi di inviare i loro messaggi. Abbiamo diviso la stringa del messaggio e analizzare i MAC address, il timestamp e il payload di dati, come ad esempio le letture di movimento dall'accelerometro. Tutto ciò che usiamo per compilare un oggetto DeviceData (vedere Figura 6) che abbiamo passato a StreamInsight per analisi successive.

Figura 6 popolamento dell'oggetto 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);
...
}

Il DashboardNow ci vogliono costruire un cruscotto che consente di visualizzare lo stato corrente dei sensori sulle attrezzature l'operatore dell'attrezzatura. Per semplicità di presentazione, metteremo a fuoco su un pezzo di attrezzature. Figura 7 mostra un esempio di tale un dashboard. Iniziamo a sinistra e guardare i diversi punti di vista dei dati sensore.

Dashboard for Equipment Monitoring
Figura 7 Dashboard per apparecchiature di monitoraggio

Vista medie in movimento: La griglia dei dati sul fondo a sinistra mostra le letture del sensore dal dispositivo con i valori per la luce, temperatura e movimento, così come l'ID del dispositivo e un timestamp. Come si può vedere dai timestamp, questi valori vengono aggiornati ogni secondo. Ma, invece di visualizzare i valori di sensore crudo, dashboard mostra medie mobili oltre 10 secondi la pena di dati dei sensori. Questo significa che ogni secondo i valori vengono aggiornati con la media degli ultimi 10 secondi la pena di dati. Utilizzando una media mobile è una tecnica comune, semplice per proteggere contro l'effetto dei valori erratici e cattivi dati che si verificano occasionalmente con sensori a basso costo.

Trendline vista: In basso a destra, il cruscotto mostra le linee di tendenza per i sensori. La vista di linea di tendenza è guidata dalle medie mobili mostrate nella griglia dei dati sulla sinistra.

Vista di allarme: La vista nella parte superiore destra consente di visualizzare una griglia di dati per allarmi. Se viene rilevata una condizione critica, viene generato un allarme che mostra il tempo e le informazioni aggiuntive come la gravità e lo stato.

Analytics ora diamo un'occhiata dietro le quinte e discutere l'analisi che sono di elaborazione dei dati del sensore in arrivo e calcolo dei risultati Visualizza il cruscotto. Utilizziamo StreamInsight per fare l'analisi. La classe seguente rappresenta i dati del dispositivo, compreso l'indirizzo MAC, un timestamp e i valori del sensore:

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; }
}

Questa classe definisce la forma di un singolo evento, ma vogliamo avviare il ragionamento di molti eventi. Per fare questo, abbiamo definire un'origine dati osservabili per StreamInsight. Questo è semplicemente un'origine dati che implementa l'interfaccia System.IObservable:

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

Una volta che hai un.Sequenza quadro netto come un Enumerable o un osservabile come questo, è possibile avviare la scrittura di query di StreamInsight sopra queste collezioni. Diamo una rapida occhiata a alcune delle domande chiave. Il primo si prende osservabili come input e produce un flusso di StreamInsight punto eventi, utilizzando il campo DateTime nei dati dispositivo come il timestamp per l'evento StreamInsight. Prendiamo questo flusso come input nel gruppo e istruzione LINQ successiva i dati dall'indirizzo MAC. Per ogni gruppo, quindi applicare una finestra di salto (un sottoinsieme basati sul tempo di eventi) con una dimensione di finestra di 10 secondi e lasciare che la finestra ricalcolare ogni secondo. All'interno di ogni finestra, calcoliamo le medie per temperatura, luce e movimento. Che ci dà una media mobile per dispositivo che viene ricalcolata ogni secondo. Figura 8 viene illustrato il codice per questo avvolti in una funzione che restituisce il risultato come un flusso di StreamInsight eventi.

Figura 8 ottenere medie mobili

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;
  }

Questo è un ottimo posto per pensare sull'implementazione della query di allarme. Ricordate, l'allarme deve essere attivata quando i sensori di movimento più muovono sopra la soglia del movimento allo stesso tempo. Possiamo trattare questo con solo un paio di dichiarazioni di LINQ StreamInsight sopra le medie raggruppate appena calcolate. La prima query, q3, si applica un trucchetto rappresentando le modifiche della soglia di allarme come un flusso di eventi chiamato AlarmThresholdSignal. La query si unisce alle soglie con il flusso di medie dalla query precedente e quindi soli i filtri per gli eventi sopra la soglia:

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",
         };

La query successiva utilizza la finestra snapshot StreamInsight per identificare i punti in tempo quando cambia status di evento. Se un nuovo risultati evento da query filtro precedente, questo è un nuovo snapshot e l'operazione istantanea produce una nuova finestra contenente tutti gli eventi che coincidono, o si sovrappongono con l'evento che ha scatenato la finestra snapshot. Il codice seguente conta eventi sopra la soglia di allarme quando viene creata la finestra snapshot:

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

Il passaggio finale controlla se il conteggio mostra che più dispositivi di indicare gli allarmi:

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
                   };

Ora abbiamo solo bisogno di ottenere i flussi di output con i valori medi di sensore e allarmi da StreamInsight all'interfaccia utente.

Ottenere il flusso per l'interfaccia utente

Con StreamInsight producendo i flussi risultato sul lato server, abbiamo bisogno di un modo per comunicare questi flussi ai consumatori. I consumatori, probabilmente, non verrà eseguito nel processo server e potrebbero utilizzare una leggera applicazione Web per visualizzare i risultati. Se si sta utilizzando Silverlight, il protocollo duplex è conveniente perché sostiene continua basata su push consegna dal server al client. HTML5 Web prese sono un'alternativa convincente, troppo. In ogni caso, si vuole rendere più facile per aggiungere nuovo analytics sul lato server e di essere in grado di collegare facilmente li fino con l'interfaccia utente — senza lacerando le interfacce client server tra l'interfaccia utente e il processo di hosting StreamInsight. Se il carico tra UI e server è moderato, è possibile serializzare i risultati sul lato server in XML e deserializzare li sul lato client. In questo modo, è solo necessario preoccuparsi di XML in tutto il filo e nel vostro interfacce client / server, oltre a un cookie aggiuntivo per indicare quali tipi di aspettarsi per la deserializzazione. Qui ci sono un paio di pezzi di codice chiave.

Il primo frammento di codice è il contratto di Windows Communication Foundation per scorrere i dati dell'evento come una stringa XML serializzato, insieme con un GUID per indicare il tipo:

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

Ora noi possiamo annotare le nostre strutture evento risultato con un contratto dati per rendere serializzabile, come mostrato nella Figura 9.

Figura 9 l'annotazione delle strutture dell'evento

[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; }
}

Possiamo ora facilmente serializzare eventi risultato sul lato server e comunicarli al client, come Figura 10 mostra.

Figura 10 l'invio di eventi risultato dal Server

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());
    }
  }

Sul lato client, abbiamo deserializzare l'evento nel metodo di callback per il servizio duplex e poi ramo in diversi metodi basati sul tipo di evento ricevuto, come mostrato nella Figura 11.

Figura 11 ricezione e deserializzazione l'evento sul Client

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();
    }
  }
}

Con queste query e la comunicazione all'applicazione Web in luogo, potete ora raccogliere numerosi dispositivi e li agitare fino a quando alcuni sono sopra la soglia di allarme.L'interfaccia utente poi produrrà uno di quegli allarmi rossi bello come quello mostrato in Figura 12.

Equipment Dashboard with Alarms
Figura 12 attrezzature Dashboard con allarmi

Perché nuovi dati costantemente sta arrivando in con un cruscotto in tempo quasi reale, ObservableCollections sono estremamente utili per aggiornare l'interfaccia utente.Se si basare le griglie dei dati e linee di tendenza su queste collezioni osservabile, non è necessario preoccuparsi per la parte di aggiornamento nel codice.Le collezioni stanno facendo questo per voi automaticamente dietro le quinte.

L'Outlook

In questa implementazione, i dispositivi di comunicano con un servizio Web regolare che potrebbe essere in esecuzione su un normale PC connesso a Internet.Ma di cloud computing è un'alternativa attraente; voi non necessariamente bisogno di possedere l'hardware e utilizzare il software per server Web.Invece, un servizio nella nube può servire come hub dove viene raccolto tutti i dati del dispositivo per la vostra applicazione.Questo rende anche molto facile per voi scalare elasticamente la potenza di elaborazione, mentre cresce il numero di dispositivi o distribuire ulteriori analisi sui dati di dispositivo.Microsoft sta progettando offrire funzionalità di StreamInsight come un servizio in Windows Azure (StreamInsight progetto Codename "Austin").Fornendo gli endpoint di comunicazione predefiniti e protocolli, Austin renderà più facile per collegare i dispositivi a funzionalità di elaborazione analitica ricco nella nube di Microsoft.Se si distribuiscono applicazioni delle IOT in Windows Azure, avrete automaticamente i benefici della nube di scala elastico e pay-as-you go per gestire le connessioni dei dispositivi e di eseguire ricca analisi sui dati del dispositivo.

Un altro cambiamento importante sta accadendo con lo sforzo di standardizzazione recenti dal W3C.Le iniziative più importanti per le applicazioni Internet degli oggetti sono prese HTML5 e Web.HTML5 fornisce la piattaforma per applicazioni Web ricche come il cruscotto che abbiamo implementato.WebSocket a sua volta semplifica la comunicazione full-duplex tra il browser e il server Web su TCP, in particolare per il modello push di consegna di risultati che richiede l'elaborazione continua dei dati dei sensori.

Dispositivi collegati si stanno aprendo un nuovo mondo emozionante delle applicazioni e gli strumenti per la costruzione di queste applicazioni IoT oggi sono disponibili da Microsoft.Qui abbiamo dimostrato come utilizzare vostro.Abilità di NET Framework a livello di dispositivo, utilizzando interfacce familiari e dati feed attraverso servizi Web nelle funzionalità potente analitica del StreamInsight.Per iniziare la costruzione di applicazioni Internet degli oggetti utilizzando dispositivi collegati ora!

Torsten Grabs è un lead program manager della divisione di Microsoft SQL Server. Ha ha più di 10 anni di esperienza di lavoro con i prodotti Microsoft SQL Server e ha conseguito un Ph.d. in scienze informatiche presso l'Istituto federale svizzero di tecnologia, Zurigo, Svizzera.

Colin Miller ha lavorato per 25 anni (tra cui 15 presso Microsoft) sul software del PC, compresi i database, desktop publishing, prodotti di consumo, parola, Internet Explorer, passaporto (LiveID) e servizi online. Egli è il product manager di unità della.Micro NET Framework.

Grazie ai seguenti esperti tecnici per la revisione di questo articolo: Rafael Fernandez Moctezuma e Lorenzo Tessiore