Microsoft StreamInsight

Création de l'Internet des objets

Torsten Grabs Colin Miller

 

« L'Internet des objets » (IdO) a beaucoup fait parler de lui ces derniers temps, et ce pour une bonne raison. Le PDG d'Ericsson, Hans Vestberg, estime que 50 milliards d'appareils seront connectés au Web d'ici à 2020 (bit.ly/yciS7r [PDF à télécharger]). Pour mettre ce chiffre en perspective, sachez qu'il y a aujourd'hui environ 1,5 milliard de PC connectés au Web et moins d'1 milliard de téléphones connectés au Web. Les 50 milliards évoqués signifieraient environ sept appareils pour chaque être humain sur la planète ! IDC, un cabinet d'études de marché, estime que plus de 16 milliards d'appareils seront connectés à Internet d'ici à 2015 (reportez-vous à la figure 1). Il est vrai qu'il existe également des prévisions plus prudentes, mais quels que soient les chiffres, ils représentent un énorme changement dans le rôle qu'occupe Internet, des informations et du divertissement transmis aux utilisateurs à la connectivité pour une catégorie naissante d'applications compatibles avec les appareils.

Figure 1 Estimation de l'« Internet intégré » par le cabinet d'études IDC

La raison pour laquelle ces nombres élevés sont plausibles est que des moteurs puissants, l'opportunité et la nécessité, propulsent une augmentation rapide de ce type de solutions. Comme le remarque un article récent de The Economist (economist.com/node/17388368) : « … le train n'avance pas seulement pour le bénéfice des entreprises spécialisées dans la technologie et des hommes politiques ambitieux. Il a pris de la vitesse parce qu'il existe un réel besoin pour ces systèmes ». La figure 2 illustre la croissance de ce type de solution par domaine d'application. Par exemple, l'implémentation mandatée des systèmes d'énergie intelligents en Europe est une question de nécessité. Nous ne pouvons pas créer la capacité de génération énergétique requise si nous ne gérons pas également l'utilisation de l'énergie. En ce qui concerne l'opportunité, le simple distributeur automatique que l'on trouve partout est un bon exemple. Une fois l'appareil branché, le personnel de service peut être envoyé en cas de besoin plutôt que selon un calendrier contre-productif. Les prix peuvent même être modifiés dynamiquement en cas d'augmentation de la demande locale ou si le contenu arrive à expiration. Les pannes d'électricité peuvent être signalées afin de déclencher immédiatement le remplacement des articles périssables. En d'autres termes, la connectivité permet un modèle commercial totalement nouveau et plus efficace.

Figure 2 Croissance d'application par segment

Il est sans aucun doute spectaculaire de définir cette évolution en faisant référence au nombre d'appareils connectés, mais c'est également quelque peu trompeur. En effet, cela ne signifie que les centaines de milliers de programmeurs en systèmes intégrés traditionnels auront du travail. Ces appareils ne sont que des points de terminaison pour des solutions complexes qui intègrent d'autres appareils dans tous les aspects d'Internet, dont l'analyse, le cloud, les applications Web, les interfaces PC et mobiles, et bien plus encore.

Vous pouvez considérer que tous ceux qui créent actuellement des applications Web seront confrontés à l'intégration des appareils et au développement de nouvelles entreprises et de nouveaux modèles commerciaux en raison de cette évolution. En d'autres termes, même si vous n'êtes pas un développeur de systèmes intégrés et si vous ne travaillez pas dans un service qui crée des appareils intégrés, il s'agit là d'une opportunité indéniable dont il convient de mesurer l'ampleur. Vos compétences Microsoft actuelles vous permettront de réussir dans l'Internet des objets.

Exécution d'analyses sur les données des appareils

Comme l'a déclaré Kevin Dallas, Directeur général de l'équipe Windows Embedded, dans une interview récente : « Les données sont devenues la nouvelle devise » (bit.ly/wb1Td8). Comparé aux applications Internet actuelles, l'Internet des objets concerne la génération et la gestion des informations, ainsi que l'accès à ces dernières. Comparons les caractéristiques des données d'une application Internet type d'aujourd'hui à celles d'une application de l'Internet des objets. Au même titre que plusieurs autres millions de personnes peut-être, vous réglez vos factures en ligne à l'aide d'un mécanisme populaire partagé par de nombreuses institutions financières. Vous vous connectez plusieurs fois par mois, consultez quelques pages et soumettez des informations de paiement. Tout cela est issu d'une base de données traditionnelle avec des requêtes exécutées lorsque vous commencez à interagir avec le système. Les pages que vous téléchargez peuvent être de grande taille, mais les interactions sont très rares, bien qu'elles génèrent des informations précieuses (informations de paiement, mises à jour d'informations personnelles, etc.) qui doivent être conservées indéfiniment.

Comparez cet exemple à un système de gestion de l'énergie comportant 50 millions d'immeubles (commerciaux et résidentiels) qui fournissent des entrées. Ces entrées sont générées par plusieurs points de terminaison locaux situés, par exemple, dans une maison avec une seule vue regroupée publiée sur le serveur principal. Ces données comprennent des informations instantanées sur l'utilisation qui deviennent la base de tarification et de facturation, et éventuellement de contrôles obligatoires, une fois revenues dans l'immeuble. Ce système implique des interactions très fréquentes avec des données d'une valeur relativement faible et qui ne sont pas nécessairement intéressantes une fois que vous avez calculé l'état actuel du système et éventuellement les données de tendance pour ce point de terminaison. Toutefois, le système a besoin d'être capable de réagir instantanément aux situations susceptibles de le menacer, par exemple une brusque augmentation de la demande qui risque de provoquer une surcharge du réseau et des coupures d'électricité. Le cas échéant, la diffusion d'informations peut réduire la consommation d'énergie immédiatement. Un tel système a besoin d'analyser en permanence les données entrantes et de comparer les tendances dans le temps afin d'identifier les modèles qui indiquent un risque plus élevé de coupures d'électricité.

La figure 3 illustre une architecture type pour les applications IdO. Le bas de la pile montre divers appareils ou ressources qui sont instrumentés avec différents types de capteurs selon l'application. Les capteurs produisent généralement des flux de données que l'application doit traiter et analyser rapidement. Selon ses fonctionnalités, l'appareil lui-même peut être capable d'effectuer une partie du traitement localement. C'est ce que l'on nomme l'analyse locale et des outils tels que .NET Micro Framework peuvent vous aider à effectuer ce traitement local avant que l'appareil ne transmette les données. Les applications IdO utilisent des protocoles Internet pour transmettre les données des appareils de façon à ce que l'analyse locale puisse être effectuée sur les données. Les résultats de l'analyse globale, par exemple l'intégrité complète du réseau électrique, sont intéressants pour les utilisateurs qui gèrent les opérations ou pour les décisionnaires en entreprise. L'analyse peut également entraîner une action automatique des systèmes fermés en fonction des conditions révélées par les données entrantes. Ces approches sont particulièrement puissantes si les ressources peuvent recevoir un retour de l'analyse globale, par exemple appliquer un changement de comportement ou améliorer des opérations. Les analyses globales qui mènent ces processus doivent être calculées en permanence et les résultats doivent être communiqués aussi rapidement que possible. En outre, les analyses font souvent référence au temps et aux horodateurs fournis avec les données des capteurs. C'est la raison pour laquelle le simple fait de placer ce type de données dans une base de données et d'exécuter des requêtes périodiques sur cette base de données n'est pas la bonne approche. Heureusement, Microsoft StreamInsight vous permet de mettre en œuvre une approche différente.

Figure 3 Architecture type des applications de l'Internet des objets

Microsoft StreamInsight

Microsoft StreamInsight est conçu de façon à offrir des réactions opportunes aux données qui arrivent constamment sans écrire ces dernières sur un disque en vue de leur analyse et de leur interrogation. De nombreuses applications IdO ont besoin d'analyser les données entrantes presque en temps réel, juste après l'acquisition des données auprès des sources. Pensez à cette application de réseau intelligente dont nous venons de parler et qui a besoin de réagir rapidement à une brusque augmentation de la demande d'électricité afin de rééquilibrer le réseau électrique. La plupart des applications IdO ont les mêmes besoins : le traitement des données qui requiert une analyse continue et une latence incontestable. L'analyse doit être continue parce que les sources de données produisent sans cesse de nouvelles données. En outre, de nombreux scénarios ont besoin d'identifier et de réagir rapidement aux conditions qui deviennent apparentes uniquement grâce à l'analyse des données entrantes. C'est pourquoi ils ont besoin d'une analyse de latence faible avec des résultats disponibles presque immédiatement. Ces exigences rendent impossible le stockage des données dans une base de données relationnelle avant d'effectuer l'analyse.

Il s'agit d'applications basées sur les événements et l'application IdO est un scénario parmi d'autres dans le cadre duquel de telles fonctionnalités sont extrêmement utiles. StreamInsight est une plate-forme puissante de création de ces applications basées sur les événements, de faible latence et extrêmement évolutives. Il fait partie de Microsoft SQL Server depuis la version 2008 R2. StreamInsight complète SQL Server avec un traitement basé sur les événements, ainsi qu'une analyse riche, expressive et reposant sur le temps. Grâce à StreamInsight, une vue d'ensemble de votre activité est transmise aussi rapidement que les données sont produites, par opposition à la vitesse à laquelle les rapports de base de données traditionnels sont traités.

Les résultats analytiques qui sont disponibles immédiatement pour un traitement humain, ou qui permettent à une application de répondre automatiquement aux événements, aident les entreprises à avoir une vision plus pertinente et plus ponctuelle de leurs opérations, ou même d'automatiser certaines parties de leurs opérations. Ces entreprises peuvent également réagir plus rapidement aux situations critiques, aux opportunités ou aux tendances qui sont révélées par le capteur ou les données des appareils.

Pour écrire des applications StreamInsight, les développeurs utilisent des outils connus, tels que Microsoft .NET Framework, LINQ et Microsoft Visual Studio. La figure 4 décrit l'expérience de développement et d'exécution d'une application StreamInsight et présente quelques concepts clés.

Figure 4 Développement et exécution d'une application StreamInsight

Une application IdO simple

Observons plus en détail une application IdO potentielle, puis nous passerons à sa création. Dans le cadre de notre exemple complet, nous nous concentrerons sur un scénario simple qui utilise des capteurs de mouvement afin de surveiller un équipement rotatif, tel que des turbines ou des éoliennes. Cette opération est vitale car des vibrations trop élevées pourraient révéler une condition critique dans laquelle l'équipement risque de se rompre et de provoquer des dommages important s'il n'est pas arrêté rapidement. Pour détecter cette condition de façon fiable, chaque équipement comporte plusieurs capteurs qui suivent les mouvements. Un accroissement brusque des mouvements signalé par un seul capteur peut simplement indiquer des relevés de données peu fiables provenant de ce capteur. En revanche, des mouvements anormalement élevés détectés par plusieurs capteurs en même temps sont considérés comme une condition critique. Dans le cas d'une grande turbine, par exemple, il serait probablement nécessaire de donner l'alarme, voire d'arrêter l'équipement automatiquement. Outre la vérification continue de ces conditions, il est également important de fournir aux opérateurs un tableau de bord offrant une vue presque en temps réel de l'état de l'équipement.

Pour créer ce scénario, nous devons nous occuper des exigences et des défis techniques suivants :

• Quelles données l'appareil doit-il capturer ?
• Quels capteurs utilisons-nous pour les mesurer ?
• Comment l'appareil communique-t-il ses relevés de capteur à Internet ?
• Comment allons-nous collecter les données des appareils dans un seul emplacement en vue de leur analyse ?
• Comment pouvons-nous analyser les données entrantes en permanence et réagir rapidement face aux conditions critiques ?
• Comment relions-nous à temps les relevés des capteurs de plusieurs appareils afin de pouvoir détecter les conditions globales ?

Voyons comment nous pouvons satisfaire à ces exigences et implémenter le scénario complet.

Une application IdO : points clés de l'implémentation

Voici quelques-unes des étapes clés permettant d'implémenter une application IdO, comme indiqué à la section précédente. Nous commencerons par aborder l'appareil, puis nous passerons à la visualisation de la sortie avant de voir l'analyse de tous les appareils qui figurent sur le tableau de bord.

L'appareil - Pour créer un dispositif de capteur, nous avons commencé par le Netduino Plus, une petite carte populaire avec 128 K de SRAM qui exécute le .NET Micro Framework. Nous avons ajouté une radio Wi-Fi amateur nommé WiFly GSX Breakout et nous avons montés les véritables capteurs, dont un accéléromètre à trois axes, sur une carte PCB personnalisée. Nous avons programmé l'appareil de façon à ce qu'il envoie une mise à jour des relevés du capteur toutes les secondes vers un service Web qui joue le rôle de hub pour collecter et traiter les données provenant de tous les appareils.

Nous utilisons une connexion RESTful avec le service Web ; il s'agit d'un simple HTTP POST qui contient des paires nom/valeur séparées par une virgule. Vous pouvez bien évidemment mettre cela en œuvre depuis n'importe quel appareil prenant en charge HTTP. Nous avons choisi d'utiliser le .NET Micro Framework afin que toute l'application (dont les appareils, le service Web, les adaptateurs StreamInsight, le tableau de bord Silverlight, etc.) puisse être écrite à l'aide d'un seul modèle de programmation (.NET) et d'une chaîne d'outil (Visual Studio). Il est évident que si vous avez des compétences en .NET, vous n'avez pas besoin de recruter de nouveaux employés ou d'envoyer des parties de votre projet IdO à un service externe de systèmes intégrés ; vous disposez de toutes les compétences nécessaires pour mettre tout ce projet en place. Par exemple, la configuration de l'accéléromètre requiert simplement quelques lignes de code pour accéder à la classe AnalogInput et appeler la méthode 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();

Une fois les entrées de capteur lues et le contenu du message HTTP mis en forme, tout ce qui doit être envoyé est inclus dans la figure 5.

Figure 5 Envoi des données de capteur

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

Côté serveur, nous implémentons la méthode SaveDeviceData, sur laquelle les appareils POST leurs messages. Nous fractionnons la chaîne de message et analysons l'adresse MAC, l'horodateur et les données de charge utile, par exemple les relevés de mouvement provenant de l'accéléromètre. Nous utilisons tout cela pour remplir un objet DeviceData (consultez la figure 6) que nous passons à StreamInsight en vue d'une analyse ultérieure.

Figure 6 Remplissage de l'objet 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);
...
}

Le tableau de bord - Nous allons maintenant créer un tableau de bord permettant à l'opérateur de l'équipement de visualiser l'état actuel des capteurs de l'équipement. Afin de faciliter la présentation, nous allons uniquement nous concentrer sur un équipement. La figure 7 illustre un exemple d'un tableau de bord de ce type. Commençons par la gauche et observons différentes vues des données des capteurs.

Figure 7 Tableau de bord de surveillance de l'équipement

Affichage des moyennes mobiles : la grille de données située en bas à gauche représente les relevés de capteur de l'appareil avec des valeurs pour la lumière, la température, les mouvements, ainsi que l'identificateur de l'appareil et un horodateur. Comme vous pouvez le voir d'après les horodateurs, ces valeurs sont mises à jour toutes les secondes. Toutefois, au lieu d'afficher les valeurs brutes des capteurs, le tableau de bord montre les moyennes mobiles sur 10 secondes de données de capteurs. Cela signifie que les valeurs sont mises à jour toutes les secondes avec la moyenne des 10 dernières secondes de données. L'utilisation d'une moyenne mobile est une technique simple et courante qui permet de se protéger contre l'effet des valeurs hors norme et des mauvaises données qui se produisent parfois avec des capteurs bon marché.

Affichage des courbes de tendance : dans la partie inférieure droite, le tableau de bord affiche les courbes de tendance des capteurs. L'affichage de ces courbes repose sur les moyennes mobiles affichées dans la grille de données à gauche.

Affichage de l'alarme : l'affichage situé dans la partie supérieure droite comporte une grille de données pour les alarmes. Si une condition critique est détectée, une alarme est émise avec l'heure et des informations complémentaires, telles que la gravité et l'état.

Les analyses - Observons maintenant ce qui se passe en arrière-plan et discutons des analyses qui traitent les données entrantes des capteurs et calculent les résultats affichés par le tableau de bord. Nous utilisons StreamInsight pour ces analyses. La classe suivante représente les données des appareils, dont l'adresse MAC, un horodateur et les valeurs du capteur :

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

Cette classe définit la forme d'un seul événement, mais nous allons chercher à analyser de nombreux événements. Pour cela, nous définissons une source de données Observable pour StreamInsight. Il s'agit simplement d'une source de données qui implémente l'interface System.IObservable :

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

Une fois que vous avez une séquence .NET Framework comme Enumerable ou Observable similaire à ce que nous venons de voir, vous pouvez commencer à écrire des requêtes StreamInsight sur ces collections. Observons rapidement certaines de ces requêtes clés. La première prend l'Observable comme entrée et produit un flux d'événements de points StreamInsight à l'aide du champ DateTime dans les données des appareils, comme l'horodateur pour l'événement StreamInsight. Nous prenons ce flux comme entrée de la prochaine instruction LINQ et nous regroupons les données par adresse MAC. Pour chaque groupe, nous appliquons ensuite un créneau récurrent (un sous-ensemble d'événements reposant sur le temps) avec un créneau de 10 secondes et nous laissons ce créneau recalculer toutes les secondes. Dans le cadre de chaque créneau, nous calculons les moyennes de température, de lumière et de mouvement. Cela donne une moyenne mobile par appareil qui est recalculée toutes les secondes. La figure 8 montre le code correspondant à ce que nous venons de voir encapsulé dans une fonction qui retourne le résultat comme flux d'événements StreamInsight.

Figure 8 Obtention des moyennes mobiles

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

C'est le moment idéal pour réfléchir à l'implémentation de la requête d'alarme. N'oubliez pas que l'alarme doit être déclenchée lorsque plusieurs capteurs de mouvements passent au-dessus du seuil de mouvement en même temps. Nous pouvez gérer cela simplement avec deux instructions LINQ StreamInsight pour les moyennes regroupées qui viennent d'être calculées. La première requête, q3, applique une astuce intéressante en représentant les modifications du seuil d'alarme comme flux d'événements nommé AlarmThresholdSignal. La requête joint les seuils au flux des moyennes provenant de la requête précédente, puis filtre simplement les événements situés au-dessus du seuil :

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 requête suivante utilise la fenêtre d'instantané StreamInsight pour identifier les moments où l'état des événements change. Si un nouvel événement provient de la requête de filtre précédente, il s'agit d'un nouvel instantané et l'opération d'instantané produit une nouvelle fenêtre contenant tous les événements qui coïncident ou chevauchent l'événement ayant déclenché la fenêtre d'instantané. Le code suivant compte les événements au-dessus du seuil d'alarme lorsque la fenêtre d'instantané est créée :

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

L'étape finale vérifie si le compte montre que plusieurs appareils indiquent des 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
                   };

À ce stade, il ne nous reste qu'à obtenir les flux de sortie avec les valeurs de capteurs moyennes et les alarmes, qui vont de StreamInsight vers l'interface utilisateur.

Obtention du flux vers l'interface utilisateur

Avec StreamInsight qui produit les flux de résultats côté serveur, nous avons besoin d'une méthode pour communiquer ces flux aux consommateurs. Les consommateurs ne seront probablement pas habitués au processus de serveur et utiliseront peut-être une application Web légère pour visualiser les résultats. Si vous utilisez Silverlight, le protocole de duplex est pratique car il prend en charge une distribution push continue du serveur vers le client. Les sockets Web HTML5 sont une alternative très intéressante également. Quelle que soit soit l'option choisie, il doit être simple d'ajouter de nouvelles analyses côté serveur et de les connecter à l'interface utilisateur, sans diviser les interfaces côté client entre l'interface utilisateur et StreamInsight qui héberge les processus. Si votre charge entre l'interface utilisateur et le serveur est modérée, vous pouvez sérialiser les résultats côté serveur dans XML et les désérialiser côté client. De cette façon, vous avez uniquement besoin de vous préoccuper du XML de la transmission et des interfaces client-serveur, sans oublier un cookie supplémentaire permettant d'indiquer à quels types s'attendre pour la désérialisation. Voici deux des morceaux de code clés.

Le premier extrait de code est le contrat WCF (Windows Communication Foundation) permettant de faire circuler les données d'événements sous forme de chaîne sérialisée XML, avec un GUID pour indiquer le type :

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

Nous pouvons maintenant annoter les structures d'événements des résultats avec un contrat de données afin de les rendre sérialisables, comme illustré à la figure 9.

Figure 9 Annotation des structures d'événements

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

Nous pouvons maintenant sérialiser facilement les événements de résultats côté serveur et les communiquer au client, comme illustré à la figure 10.

Figure 10 Envoi des événements de résultats depuis le serveur

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

Côté client, nous désérialisons l'événement dans la méthode de rappel pour le service de duplex, puis nous utilisons différentes méthodes en fonction du type d'événement reçu, comme illustré à la figure 11.

Figure 11 Réception et désérialisation de l'événement sur le 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();
    }
  }
}

Maintenant que ces requêtes et la communication avec l'application Web sont en place, vous pouvez choisir plusieurs appareils et les bousculer jusqu'à ce qu'ils dépassent le seuil d'alarme. L'interface utilisateur génère ensuite l'une de ces belles alarmes rouges, comme celle illustrée à la figure 12.

Figure 12 Tableau de bord de l'équipement avec alarmes

Étant donné que de nouvelles données arrivent constamment avec un tableau de bord presque en temps réel, les ObservableCollections sont extrêmement utiles pour mettre à jour votre interface utilisateur. Si les grilles de données et les courbes de tendance reposent sur ces collections observables, vous n'avez pas besoin de vous préoccuper de tout ce qui concerne la mise à jour du code. Les collections s'en chargent automatiquement en arrière-plan.

Les perspectives

Dans cette implémentation, les appareils communiquent avec un service Web standard susceptible d'être exécuté sur un PC standard connecté à Internet. Toutefois, le cloud computing est une solution intéressante puisque vous ne devez pas nécessairement posséder le matériel ni exécuter le logiciel pour votre propre serveur Web. En revanche, un service du cloud peut jouer le rôle de hub dans lequel les données des appareils sont collectées pour l'application. Cela vous permet également d'adapter très facilement et avec souplesse la puissance de traitement à mesure que le nombre d'appareils augmente ou que vous déployez des analyses supplémentaires des données des appareils. Microsoft a l'intention de fournir des fonctionnalités StreamInsight comme service dans Windows Azure (projet StreamInsight dont le nom de code est « Austin »). En fournissant des protocoles et des points de terminaison de communication prédéfinis, Austin facilite la connexion des appareils à des fonctionnalités de traitement analytique riches dans le cloud Microsoft. Si vous déployez les applications IdO dans Windows Azure, vous aurez automatiquement accès aux avantages du cloud, à savoir une adaptabilité souple et le paiement à l'utilisation, pour gérer les connexions d'appareils et effectuer des analyses riches des données des appareils.

Une autre évolution importante est en cours avec l'effort de normalisation récent fourni par le W3C. Les initiatives les plus importantes pour les applications IdO sont le HTML5 et les sockets Web. HTML5 offre la plate-forme destinée aux applications Web riches, telles que le tableau de bord que nous venons d'implémenter. En ce qui concerne les sockets Web, ils simplifient la communication duplex intégral entre le navigateur et le serveur Web via TCP, notamment pour le modèle push de distribution des résultats requis par le traitement continu des données provenant des capteurs.

Les appareils connectés ouvrent la voie à un nouveau monde d'applications fantastique et les outils permettant de créer ces applications IdO sont désormais disponibles auprès de Microsoft. Dans cet article, nous vous avons montré comment utiliser vos compétences en matière de .NET Framework au niveau des appareils, à l'aide d'interfaces connues, et comment transmettre ces données via des services Web aux fonctionnalités d'analyse puissantes offertes par StreamInsight. Commencez à créer vos premières applications IdO à l'aide d'appareils connectés dès maintenant !

Torsten Grabs est responsable de programme principal au sein de la division Microsoft SQL Server. Il travaille depuis plus de 10 ans avec les produits Microsoft SQL Server et il est titulaire d'un doctorat en informatique de l'Institut fédéral suisse de technologie, à Zürich en Suisse.

Colin Miller travaille depuis 25 ans (dont 15 chez Microsoft) sur les logiciels pour PC, notamment les bases de données, la publication de bureau, les produits de consommation, Word, Internet Explorer, Passport (LiveID) et les services en ligne. Il est le directeur d'unité produit de .NET Micro Framework.

Merci aux experts techniques suivants d'avoir relu cet article : Rafael Fernandez Moctezuma et Lorenzo Tessiore