Microsoft StreamInsight

Criando a Internet das coisas

Torsten Grabs
Colin Miller

Ultimamente, muito tem se falado a respeito da "IoT" (Internet das coisas), e com razão. O CEO da Ericsson, Hans Vestberg, estima que 50 bilhões de dispositivos estarão conectados à Web até 2020 (bit.ly/yciS7r [baixe o PDF]). Para colocar esse número em perspectiva, atualmente há cerca de 1,5 bilhão de PCs e quase 1 bilhão de telefones conectados à Web, cerca de sete dispositivos por ser humano do planeta! Por sua vez, a IDC, empresa de pesquisa de mercado, estima que mais de 16 bilhões de dispositivos estarão conectados à Internet até 2015 (consulte a Figura 1). É claro que também existem algumas projeções mais conservadoras, mas pelos números de qualquer fonte, isso representa uma mudança enorme na função da Internet, do fornecimento de informações e entretenimento às pessoas ao fornecimento de conectividades por uma classe emergente de aplicativos habilitados para dispositivos.

Figura 1 Estimando a “Internet inserida”, da IDC

O motivo pelo qual esses grandes números são plausíveis é que drivers poderosos, oportunidade e necessidade, estão impulsionando um crescimento rápido dessas soluções. Como observa uma edição recente de The Economist (economist.com/node/17388368) “… o trio elétrico não está se movendo apenas para o benefício das empresas de tecnologia e de políticos ambiciosos. Ele ganhou força porque há uma necessidade real para esses sistemas”. A Figura 2 mostra o crescimento desse tipo de solução por área de aplicativo. Por exemplo, a implementação obrigatória de sistemas de energia inteligentes na Europa está sendo orientada pela necessidade. Não poderemos criar o potencial de geração da energia necessária, se não gerenciarmos o uso da energia. Do lado da oportunidade, as simples e onipresentes máquinas de venda automática são um bom exemplo. Depois que o dispositivo é conectado, a equipe de serviço pode ser despachada quando necessário, em vez usar um tipo de cronograma de qualidade inferior. Os preços podem até ser alterados dinamicamente, se houver uma demanda local maior ou se o conteúdo estiver próximo da expiração. Interrupções de energia podem ser relatadas para disparar a reposição imediata de itens perecíveis. Ou seja, a conectividade permite um modelo empresarial inteiramente novo e mais eficiente.

Figura 2 Crescimento dos aplicativos por segmento

A caracterização dessa mudança por meio da referência do número de dispositivos conectados é certamente dramática, mas também é um pouco enganosa, não estamos falando de garantia de emprego para as centenas de milhares de programadores inseridos tradicionais. Esses dispositivos são apenas os pontos de extremidade de soluções complexas que integram outros dispositivos em todos os aspectos da Internet, incluindo analítica, a nuvem, os aplicativos, as interfaces de PCs e de dispositivos móveis e muito mais.

Todo mundo que está criando aplicativos baseados na Web atualmente irá enfrentar a integração de dispositivos e precisará de ajuda para desenvolver novos negócios e novos modelos empresariais como resultado. Ou seja, mesmo que você não seja um desenvolvedor inserido e não trabalhe em uma empresa que crie dispositivos inseridos, esta é uma oportunidade muito atraente para ser avaliada. Suas habilidades atuais com produtos Microsoft permitirão que você tenha êxito na IoT.

Executando uma análise dos dados de dispositivos

“Os dados se tornaram a nova moeda”, disse Kevin Dallas, gerente geral da equipe do Windows Embedded em uma recente entrevista (bit.ly/wb1Td8). Em comparação com os aplicativos atuais da Internet, a IoT consiste na geração de informações, gerenciamento e acesso. Vamos comparar as características de um aplicativo de Internet típico atual com um aplicativo de IoT. Você e talvez vários milhões de outras pessoas pagam suas contas online usando um mecanismo popular que é compartilhado por muitas instituições financeiras. Você faz logon várias vezes por mês, exibe algumas páginas e envia informações de pagamento. Tudo isso é extraído de um banco de dados tradicional com consultas executadas quando você começa a interagir com o sistema. As páginas que você baixa podem ser grandes, mas as interações são bastante esparsas, embora gerem informações valiosas (informações sobre pagamento, atualizações de informações pessoais e assim por diante), que precisam ser retidas indefinidamente.

Compare isso com um sistema de gerenciamento de energia onde pode haver 50 milhões de prédios (comerciais e residenciais) fornecendo entrada. A entrada é gerada por vários pontos de extremidade locais dentro, por exemplo, de uma casa, com uma única exibição agregada postada no back-end. Esses dados incluem informações de uso instantâneas que se tornam a base para a definição do preço e a cobrança e, possivelmente controles obrigatórios, de volta para o prédio. Esse sistema envolve interações muito frequentes com dados de valor relativamente baixos, que não são necessariamente interessantes depois que você calcula o estado atual do sistema e, possivelmente, os dados de tendência desse ponto de extremidade. No entanto, o sistema precisa ter a capacidade de responder instantaneamente a situações que o ameaçam potencialmente, como aumentos súbitos na demanda da rede, e podem provocar sobrecarga e interrupções de energia. Nesse caso, a difusão das informações pode reduzir o consumo de energia imediatamente. Esse sistema precisa analisar continuamente os dados de entrada e comparar as tendências ao longo do tempo para identificar padrões que indiquem um risco mais alto de interrupções de energia.

A Figura 3 ilustra uma arquitetura típica para aplicativos de IoT. A parte inferior da pilha mostra vários ativos ou dispositivos que são instrumentados com diferentes tipos de sensores, dependendo aplicativo. Normalmente, os sensores produzem feeds de dados contínuos, que o aplicativo precisa processar e analisar rapidamente. Dependendo de suas funcionalidades, o próprio dispositivo pode ter a capacidade de executar algum processamento localmente. Isso é chamado de análise local, e as ferramentas, como o .NET Micro Framework, podem ajudar a executar esse processamento local antes de o dispositivo passar os dados. Os aplicativos de IoT usam protocolos Internet para passar os dados do dispositivo, de forma que a análise global possa ser executada nos dados. Os resultados da análise global, como a integridade geral de uma rede de energia, são de interesse dos usuários finais, que gerenciam operações, ou para os tomadores de decisões de negócios. A análise também pode orientar sistemas fechados que executam ações automaticamente com base nas condições reveladas nos dados recebidos. Essas abordagens serão particularmente poderosas se os ativos puderem receber comentários da análise global, por exemplo, para produzir uma alteração no comportamento ou para melhorar as operações. A análise global que orienta esses processos precisa ser calculada continuamente, e os resultados precisam ser disponibilizados o mais rapidamente possível. Além disso, habitualmente, a análise consulta a hora e os carimbos de data/hora fornecidos pelos dados do sensor. Portanto, apenas colocar esse tipo de dados em um banco de dados e consultá-los periodicamente não é a abordagem correta. Felizmente, o Microsoft StreamInsight permite uma abordagem diferente.

Figura 3 Arquitetura típica para aplicativos de Internet das Coisas

Microsoft StreamInsight

O Microsoft StreamInsight foi desenvolvido para fornecer reações em tempo hábil para os dados que chegam continuamente sem gravar os dados em disco para análise ou consulta. Muitos aplicativos de IoT precisam analisar os dados de entrada quase em tempo real, imediatamente depois de os dados serem adquiridos das origens. Considere aquele aplicativo de rede inteligente que mencionamos, que precisa reagir rapidamente a uma sobrecarga na demanda da eletricidade para rebalancear a rede de energia. Muitos aplicativos de IoT possuem as mesmas necessidades: processamento de dados que requer análise contínua e latência convincente. A análise deve ser contínua porque as fontes de dados produzem novos dados continuamente. E muitos cenários precisam identificar e reagir rapidamente às condições que se tornam aparentes apenas a partir da análise dos dados recebidos, portanto, precisam de análise de baixa latência com os resultados disponíveis quase que imediatamente. Esses requisitos tornam o armazenamento de dados impraticável em um banco de dados relacional antes da execução da análise.

Chamamos esses aplicativos de aplicativos controlados por eventos, e o IoT é apenas um cenário onde essas funcionalidades são extremamente úteis. O StreamInsight é uma plataforma poderosa para criar esses aplicativos controlados por eventos altamente escalonáveis e de baixa latência. Ele faz parte do Microsoft SQL Server desde a versão 2008 R2. O StreamInsight complementa o SQL Server com processamento controlado por eventos e análise sofisticada, expressiva e baseada em tempo. Com o StreamInsight, a visão dos negócios é fornecida na velocidade em que os dados são produzidos, ao contrário da velocidade na qual os relatórios tradicionais de bancos de dados são processados.

Os resultados analíticos, que estão disponíveis para consumo humano imediatamente ou que permitem que um aplicativo reaja aos eventos automaticamente, ajudam as empresas a obter uma visão mais imediata e mais relevante de suas operações ou mesmo a automatizar partes de suas operações. Elas também podem reagir mais rapidamente a situações críticas, oportunidades ou tendências que surgem dos dados do sensor ou do dispositivo.

Para escrever aplicativos do StreamInsight, os desenvolvedores usam ferramentas familiares, como o Microsoft .NET Framework, o LINQ e o Microsoft Visual Studio. A Figura 4 descreve a experiência do desenvolvedor e do tempo de execução de um aplicativo do StreamInsight e apresenta alguns dos principais conceitos.

Figura 4 Desenvolvimento e tempo de execução de aplicativo StreamInsight

Um aplicativo simples de IoT

Vamos nos aprofundar mais em um aplicativo potencial de IoT e, em seguida, o criaremos. Para todo o nosso exemplo, focalizaremos um único cenário que usa sensores de movimento para monitorar equipamentos rotativos, como turbinas ou moinhos de vento. Isso é vital, pois a existência de muita vibração pode indicar uma condição crítica na qual o equipamento tem probabilidade de quebrar e provocar danos significativos se não for interrompido rapidamente. Para detectar essa condição de maneira confiável, cada peça do equipamento precisa ter vários sensores para controlar os movimentos. Um oscilação no movimento de um único sensor pode indicar apenas leituras de dados não confiáveis do sensor, mas um movimento anormalmente alto de vários sensores ao mesmo tempo é considerado uma condição crítica. Em uma grande turbina, por exemplo, você provavelmente irá desejar disparar um alarme ou até mesmo desligar o equipamento automaticamente. Além de verificar continuamente essas condições, também desejamos fornecer aos operadores um painel que mostre uma visão quase em tempo real do status do equipamento.

Para criar esse cenário, precisamos abordar os seguintes requisitos e desafios técnicos:

• Quais dados o dispositivo precisa capturar?
• Quais sensores usamos para medi-los?
• Como o dispositivo comunica as leituras do sensor para a Internet?
• Como coletamos os dados do dispositivo em um único local para análise?
• Como podemos analisar continuamente os dados recebidos e reagir rapidamente às condições críticas?
• Como correlacionamos as leituras dos sensores ao longo do tempo em vários dispositivos para que possamos verificar as condições globais?

Vamos examinar como resolver esses requisitos e implementar o cenário completo.

Um aplicativo de IoT: destaques da implementação

As seguintes são algumas das etapas principais da implementação de um aplicativo de IoT conforme descrito na seção anterior. Primeiro, discutiremos os dispositivos, saltaremos para a virtualização da saída e, em seguida, moveremos para a análise entre os dispositivos que populam o painel.

Para criar um dispositivo sensor, começamos com o Netduino Plus, uma pequena placa popular com SRAM de 128 K, que executa o .NET Micro Framework. Adicionamos uma radioamador Wi-Fi comum chamado WiFly GSX Breakout e montamos os sensores reais, incluindo um acelerômetro de três eixos, em uma placa PCB personalizada. Programamos o dispositivo para enviar uma atualização das leituras do sensor a cada segundo para um serviço Web que funciona como o hub para coletar e processar os dados de todos os dispositivos.

Estamos usando uma conexão RESTful com o serviço Web, apenas um HTTP POST contendo pares de nome-valor separados por vírgulas. É claro que isso pode ser feito de qualquer tipo de dispositivo que dê suporte a HTTP. Optamos por usar o .NET Micro Framework para que todo o aplicativo, incluindo os dispositivos, o serviço Web, os adaptadores StreamInsight, o painel do Silverlight, etc., pudessem ser escritos usando um único modelo de programação (.NET) e cadeia de ferramentas (Visual Studio). Obviamente, se você tiver experiência com o .NET, não precisará contratar uma nova equipe ou delegar seu projeto de IoT para uma empresa inserida externa, você terá as habilidades para fazer tudo. Por exemplo, a configuração do acelerômetro requer apenas algumas linhas de código para acessar a classe AnalogInput e chamar o método 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();

Quando a entrada do sensor for lida e o conteúdo da mensagem HTTP estiver formatado, tudo o que será necessário para enviá-la está incluído na Figura 5.

Figura 5 Enviando dados do sensor

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

No lado do servidor, implementamos o método SaveDeviceData, no qual os dispositivos fazem POST de suas mensagens. Dividimos a cadeia de caracteres da mensagem e analisamos o endereço MAC, o carimbo de data/hora e os dados da carga, como as leituras dos movimentos no acelerômetro. Usamos tudo isso para popular um objeto DeviceData (consulte a Figura 6) que passamos para o StreamInsight para análise subsequente.

Figura 6 Populando o objeto 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);
...
}

O painel - Agora queremos criar um painel que permita que o operador do equipamento exiba o status atual dos sensores no equipamento. Para facilitar a apresentação, focalizaremos apenas uma única parte do equipamento. A Figura 7 mostra um exemplo desse painel. Vamos começar pela esquerda e examinar as diferentes exibições dos dados dos sensores.

Figura 7 Painel para monitoramento do equipamento

Exibição das médias móveis: a grade de dados na parte inferior esquerda mostra as leituras dos sensores do dispositivo com valores de luz, temperatura e movimento, bem como a ID do dispositivo e um carimbo de hora. Como você pode ver nos carimbos de hora, esses valores são atualizados a cada segundo. Mas, em vez de exibir os valores brutos do sensor, o painel mostra as médias móveis equivalentes a 10 segundos dos dados do sensor. Isso significa que a cada segundo os valores são atualizados com a média do equivalente aos últimos 10 segundos de dados. O uso de uma média móvel é uma técnica simples e comum para proteção contra o efeito de dados discrepantes e inadequados que ocorrem ocasionalmente com sensores de baixo custo.

Exibição da linha de tendências: na parte inferior direita, o painel mostra as linhas de tendências dos sensores. A exibição das linhas de tendências é controlada pelas médias móveis mostradas na grade de dados à esquerda.

Exibição de alarmes: A exibição na parte superior direita exibe uma grade de dados de alarmes. Se uma condição crítica for detectada, será gerado um alarme mostrando a hora e informações adicionais, como severidade e status.

Análise - Agora vamos dar uma olhada por trás dos bastidores e discutir as analíticas que estão processando os dados recebidos do sensor e calcular os resultados visualizados pelo painel. Usamos o StreamInsight para fazer a análise. A classe a seguir representa os dados do dispositivo, incluindo o endereço MAC, um carimbo de data/;hora e os valores do sensor:

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

Essa classe define a forma de um único evento, mas queremos começar a raciocinar sobre muitos eventos. Para fazer isso, definimos uma fonte de dados Observable para o StreamInsight. Essa é simplesmente uma fonte de dados que implementa a interface System.IObservable:

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

Quando você tem uma sequência do .NET Framework, como um Enumerable ou um Observable como esse, você pode começar a escrever consultas StreamInsight nessas coleções. Vamos examinar rapidamente algumas das principais consultas. A primeira usa o Observable como uma entrada e produz um fluxo de eventos pontuais do StreamInsight, usando o campo DateTime nos dados do dispositivo como o carimbo de data/hora para o evento do StreamInsight. Usamos esse fluxo como entrada na próxima instrução LINQ e agrupamos os dados pelo endereço MAC. Para cada grupo, aplicamos uma janela de salto (um subconjunto de eventos baseado em tempo) com uma janela de 10 segundos e permitimos que a janela seja recalculada a cada segundo. Em cada janela, calculamos as médias de temperatura, luz e movimento. Isso fornece uma média móvel por dispositivo que é recalculada a cada segundo. A Figura 8 mostra o código para isso encapsulado em uma função que retorna o resultado como um fluxo de eventos do StreamInsight.

Figura 8 Obtendo as médias móveis

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

Este é um bom local para pensar em implementar a consulta de alarmes. Lembre-se de que o alarme deve ser disparado quando vários sensores se movem acima do limite de movimento ao mesmo tempo. Podemos manipular isso com apenas duas instruções LINQ do StreamInsight sobre as médias agrupadas que acabaram de ser calculadas. A primeira consulta, q3, aplica um truque perfeito representando as alterações do limite de alarme como um fluxo de eventos chamado AlarmThresholdSignal. A consulta une os limites com o fluxo de médias da consulta anterior e apenas filtra os eventos que estão acima do limite:

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

A próxima consulta usa a janela de instantâneos do StreamInsight para identificar pontos no tempo onde os status dos eventos foram alterados. Se um novo evento resultar da consulta de filtro anterior, esse será um novo instantâneo e a operação do instantâneo produzirá uma nova janela contendo todos os eventos que coincidem ou se sobrepõem com o evento que disparou a janela de instantâneos. O código a seguir conta os eventos que estão acima do limite de alarme quando a janela de instantâneos é criada:

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

A etapa final verifica se a contagem mostra que vários dispositivos estão indicando alarmes:

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

Agora, precisamos colocar os fluxos de saída com os valores médios do sensor e os alarmes do StreamInsight para a interface do usuário.

Colocando o fluxo na interface do usuário

Com o StreamInsight produzindo os fluxos de resultados no lado do servidor, precisamos de uma maneira para comunicar esses fluxos para os consumidores. Os consumidores, provavelmente, não executarão o processo do servidor e podem usar um aplicativo Web leve para visualizar os resultados. Se você estiver usando o Silverlight, o protocolo duplex será conveniente pois ele dá suporte à entrega baseada em envio por push contínuo do servidor para o cliente. Os soquetes Web HTML5 também são uma alternativa atraente. Em qualquer um dos casos, você deseja facilitar a adição de novas análises no lado do servidor e poder transferi-las de forma eletrônica e fácil com a interface do usuário, sem separar as interfaces cliente-servidor entre a interface do usuário e o processo que hospeda o StreamInsight. Se a carga entre a interface do usuário e o servidor for moderada, você poderá serializar os resultados no servidor em XML e desserializá-los no cliente. Dessa maneira, você precisa se preocupar apenas com o XML na transferência eletrônica e com as suas interfaces de cliente-servidor, além de um cookie adicional para indicar quais tipos esperar para desserialização. Estas são duas das partes principais do código.

O primeiro trecho do código é o contrato do Windows Communication Foundation para o fluxo dos dados de eventos como uma cadeia de caracteres serializada por XML, junto com um GUID para indicar o tipo:

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

Agora você pode anotar nossas estruturas de eventos do resultado com um contrato de dados para torná-las serializáveis, conforme mostrado na Figura 9.

Figura 9 Anotando as estruturas de eventos

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

Agora podemos serializar facilmente os eventos do resultados no servidor e comunicá-los ao cliente, conforme mostrado na Figura 10.

Figure 10 Enviando eventos do resultado do servidor

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

No cliente, desserializamos o evento no método callback do serviço duplex e, em seguida, ramificamos em diferentes métodos com base no tipo de evento recebido, conforme mostrado na Figura 11.

Figura 11 Recebendo e desserializando o evento no cliente

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

Com essas consultas e a comunicação com o aplicativo Web definidas, você agora pode escolher vários dispositivos e agitá-los até que alguns estejam acima do limite de alarme. A interface do usuário irá então produzir um daqueles bons alarmes vermelhos, como o mostrado na Figura 12.

Figura 12 Painel dos equipamentos com alarmes

Como novos dados são recebidos constantemente em um painel quase em tempo real, ObservableCollections são extremamente úteis para atualizar sua interface do usuário. Se você basear suas grades de dados e linhas de tendências nessas coleções de Observable, não precisará se preocupar com a parte de atualização de seu código. As coleções estão fazendo isso para você automaticamente por trás dos bastidores.

A previsão

Nesta implementação, os dispositivos se comunicam com um serviço Web normal que pode estar em execução em um PC comum conectado à Internet. Mas a computação na nuvem é uma alternativa atraente. Você não precisa necessariamente possuir o hardware e executar o software para seu próprio servidor Web. Em vez disso, um serviço na nuvem pode funcionar como o hub onde todos os dados dos dispositivos estão sendo coletados para seu aplicativo. Isso também facilita o dimensionamento elástico de sua força de processamento à medida que o número de dispositivos cresce ou você implanta análises adicionais nos dados dos dispositivos. A Microsoft está planejando fornecer as funcionalidades do StreamInsight como um serviço no Windows Azure (StreamInsight Project Codename “Austin”). Com o fornecimento de pontos de extremidade e protocolos de comunicação predefinidos, o Austin facilitará a conexão de seus dispositivos às funcionalidades sofisticadas de processamento analítico na nuvem da Microsoft. Se você implantar seus aplicativos de IoT no Windows Azure, obterá automaticamente os benefícios de dimensionamento elástico e de uso pré-pago da nuvem para gerenciar as conexões dos dispositivos e para executar análises sofisticadas dos dados dos dispositivos.

Está ocorrendo outra mudança importante com o recente esforço de padronização do W3C. As iniciativas mais importantes para aplicativos de IoT são os soquetes Web e HTML5. O HTML5 fornece a plataforma para aplicativos Web sofisticados, como o painel que implementamos. Por sua vez, o WebSocket simplifica a comunicação full duplex entre o navegador e o servidor Web sobre TCP, principalmente para o modelo envio por push da entrega de resultados necessário para o processamento dos dados dos sensores.

Os dispositivos conectados estão abrindo um novo mundo estimulante de aplicativos, e as ferramentas para criar esses aplicativos de IoT estão disponíveis na Microsoft atualmente. Mostramos aqui como você pode usar suas habilidades em .NET Framework no nível de dispositivos, usando interfaces familiares e dados de feed por meio de serviços Web para os poderosos recursos de análise do StreamInsight. Comece a criar seus aplicativos de IoT usando dispositivos conectados agora mesmo!

Torsten Grabs é gerente-chefe de programa na divisão do Microsoft SQL Server. Ele tem mais de 10 anos de experiência de trabalho com produtos Microsoft SQL Server e é doutor em ciência da computação pelo Swiss Federal Institute of Technology, Zurique, Suíça.

Colin Miller trabalha há 25 anos (incluindo 15 na Microsoft) com software de PC, incluindo bancos de dados, editoração eletrônica, produtos de consumo, Word, Internet Explorer, Passport (LiveID) e serviços online. Ele é gerente da unidade de produtos do .NET Micro Framework.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Rafael Fernandez Moctezuma e Lorenzo Tessiore