Comprendre les données IoT dans les villes intelligentes

Les villes intelligentes génèrent des quantités massives de données à partir d'appareils Internet des objets (IoT) - capteurs de trafic, moniteurs environnementaux, compteurs intelligents, caméras de surveillance, capteurs de poubelles, etc. Ces appareils produisent en permanence des flux de données télémétriques qui nécessitent une collecte, un traitement et une analyse immédiates.

Dans un déploiement typique de la ville intelligente, les capteurs génèrent des lectures toutes les quelques secondes – température, humidité, niveaux de bruit, indices de qualité de l'air, comptage des véhicules, consommation d'énergie et débit d'eau. Ces données de la série chronologique doivent être ingérées, normalisées, filtrées, agrégées et souvent corrélées entre plusieurs types de capteurs.

Caractéristiques des données et exigences en matière de traitement

Les données IoT dans les villes intelligentes présentent plusieurs caractéristiques distinctes qui influent sur la conception des pipelines :

  • Vélécité et volume élevés: Une seule ville peut avoir des dizaines de milliers de capteurs, chaque générateur de paquets toutes les quelques secondes, ce qui entraîne des millions d'événements par heure.
  • Variété des formats:[ Les appareils utilisent différents protocoles (MQTT, CoAP, HTTP) et schémas de données (JSON, binaire, CSV).
  • Sensibilité au temps :[ De nombreux cas d'utilisation – comme une intervention d'urgence ou un contrôle du feu de circulation – exigent une latence de milliseconde.
  • Connectivité intermédiaire :[ Les périphériques bord peuvent perdre la connectivité réseau, de sorte que les pipelines doivent gérer les données tamponnées et les duplications.
  • Qualité des données: Les défaillances du capteur, le bruit et la dérive nécessitent une validation et un nettoyage précoces.

Les architectures sans serveur répondent à ces défis en offrant une évolutivité induite par les événements : chaque événement entrant déclenche des ressources précisément au besoin, sans capacité de ralenti.

Avantages du traitement de données sans serveur

L'adoption d'une approche sans serveur pour les pipelines de données IoT présente plusieurs avantages concrets:

  • Écaillage automatique: Les fonctions Cloud (AWS Lambda, Azure Functions, Google Cloud Functions) font tourner des instances en réponse au volume d'événement. Pendant les heures de pointe ou un festival de ville, les pics de données de capteur sont gérés sans aucune planification de capacité.
  • Paiement à l'usage:[ Pas de frais pour les ressources inutilisées. Ceci est particulièrement utile pour les projets de villes intelligentes où les budgets sont limités et les volumes de données fluctuent de façon saisonnière.
  • Reduced operating topear:[ Aucun serveur à corriger, gérer ou entretenir. Les équipes se concentrent sur la logique de transformation des données plutôt que sur l'infrastructure.
  • Itération rapide:[ Les fonctions peuvent être mises à jour indépendamment, permettant des améliorations progressives aux règles de nettoyage des données ou aux algorithmes d'agrégation sans redéployer des applications entières.
  • Écosystà ̈me intégré: Les plates-formes sans serveur se connectent nativement aux services d'ingestion d'IoT, aux bases de données, aux bus événements et aux outils d'analyse, simplifient la construction de pipelines.

Cependant, sans serveur n'est pas une balle d'argent. Les démarrages à froid, les délais d'exécution et les contraintes de gestion d'état nécessitent une architecture soignée. De nombreux déploiements de villes intelligentes utilisent une approche hybride : sans serveur pour les tâches de traitement variables, à courte durée de vie et les services conteneurisés pour les calculs complexes et à long terme.

Concevoir un pipeline de données IoT sans serveur

Un pipeline de données IoT sans serveur bien architecturé comprend plusieurs étapes logiques, chacune exploitant les services gérés par le cloud.

1. Ingestion des données et gestion des appareils

Couche d'ingestion: Les capteurs IoT communiquent par des protocoles comme MQTT (publication légère-abonnement) ou AMQP. Points d'entrée Cloud tels que AWS IoT Core[, Azure IoT Hub[, ou Google Cloud IoT Core[ authentifie chaque appareil, impose le chiffrement TLS et fait suivre les messages vers le traitement en aval.

Capacités clés :

  • Registre des appareils:[Enregistrez chaque capteur avec des métadonnées (emplacement, type, date d'étalonnage).
  • Sécurité:[ X.509 certificats ou jetons API pour l'authentification des appareils.
  • Renvoi de messages:[ Règles qui orientent la télémétrie vers des fonctions de traitement spécifiques basées sur des propriétés (p. ex., toutes les données de qualité de l'air vers une fonction Lambda, les données de trafic vers une autre).
  • Les appareils peuvent continuer à collecter des données lorsqu'ils sont déconnectés; les messages sont livrés une fois que la connectivité reprend.

2. Traitement en temps réel avec fonctions sans serveur

Couche de traitement: Fonctions animées par l'événement (AWS Lambda, Azure Functions, Google Cloud Functions) exécutent des transformations courtes et apatrides.

  • Normalisation des données: Convertissez les charges utiles entrantes à partir de différents formats de capteurs en un schéma standard. Par exemple, les valeurs de température dans Fahrenheit à partir d'un appareil et Celsius à partir d'un autre sont unifiées.
  • Validation et filtrage:[ Jeter les paquets malformés, les valeurs aberrantes ou les données redondantes. Un filtre peut ignorer les lectures en dehors des plages plausibles (p. ex., capteurs de température lisant 999°C).
  • Enrichissement:[ Joindre les données du capteur avec les données de référence statiques (par exemple, coordonnées SIG pour un capteur) ou les tables de recherche (par exemple, densité de population de la zone).
  • Agrégation: Calculer les moyennes mobiles, les sommes ou les comptages au cours des fenêtres temporelles. Par exemple, les valeurs agrégées par minute de la qualité de l'air sont exprimées en moyennes de 15 minutes.
  • Agrément:[ Générer des notifications lorsque les seuils sont dépassés (p. ex. concentration de PM2,5 > 150 μg/m3).

Les fonctions sans serveur sont déclenchées par des messages IoT directement, ou via un bus d'événements intermédiaire comme Amazon EventBridge ou .Ce découplage permet à plusieurs abonnés de répondre au même événement.

Considérations concernant l'exécution des fonctions

  • Démarrages à froid :[ Minimiser l'impact en utilisant la concordance fournie pour les alertes sensibles à la latence, ou garder les fonctions au chaud en utilisant des événements de contrôle de santé périodiques.
  • Délai d'exécution: La plupart des fonctions ont une limite de 15 minutes. Pour un traitement majestueux sur des fenêtres plus longues, considérez les services de streaming comme AWS Kinesis Data Analytics ou Azure Stream Analytics.
  • Mesure de mémoire:[ Allouer la mémoire en fonction de la taille d'entrée typique; plus de mémoire alloue aussi plus de processeur, accélérant le traitement.

3. Stockage des données et persistance

Couche de stockage : Les données traitées doivent être maintenues pour l'analyse historique, la conformité et les tableaux de bord. Le choix dépend des modèles de requête et des besoins de rétention.

  • Bases de données de séries temporelles: Amazon Timestream, InfluxDB, TimescaleDB – optimisé pour les requêtes à haute écriture et à faible latence sur les données de capteurs horodatées. Idéal pour la surveillance en temps réel.
  • NoSQL bases de données: Amazon DynamoDB, Azure Cosmos DB – bon pour l'état des périphériques IoT (valeurs actuelles), métadonnées et préférences spécifiques à l'utilisateur.
  • Laques de données: Amazon S3, Azure Blob Storage, Google Cloud Storage – stockage rentable pour les données brutes ou agrégées destinées à l'analyse par lots, à l'apprentissage automatique ou à la rétention à long terme.
  • Bases de données relationnelles:[ Utilisez les services compatibles PostgreSQL pour obtenir des données structurées qui nécessitent des renvois complexes, comme les tableaux de gestion des actifs.

De nombreux pipelines de villes intelligentes combinent plusieurs magasins : une base de données série-temps pour les tableaux de bord en direct, un lac de données pour l'archivage et un magasin NoSQL pour les registres et les configurations des appareils.

4. Analyse et visualisation

Couche analytique: Transforme les données stockées en aperçus.

  • Managed BI tools: Amazon QuickSight, Microsoft Power BI, Tableau—connectez-vous aux bases de données ou aux lacs de données pour créer des tableaux de bord interactifs pour les urbanistes.
  • Les tableaux de bord web personnalisés: Construits avec des cadres comme Réaction ou Vue, consommant des données via les API REST ou les paramètres GraphQL. Les moteurs sans serveur (par exemple AppSync, API Gateway + Lambda) peuvent servir des requêtes agrégées à la demande.
  • Machine learning:[ Utilisez les services de ML en nuage (Amazon Sagemaker, Azure Machine Learning) pour prédire la congestion du trafic ou la consommation d'énergie en fonction des modèles historiques.
  • Analyse géospatiale:[ Beaucoup de questions de ville intelligentes sont basées sur l'emplacement: - Quelles intersections ont la pire qualité d'air?- Des outils comme Amazon OpenSearch avec le support GeoJSON ou PostGIS activent les requêtes spatiales.

Mise en oeuvre d'un échantillon de pipeline : surveillance de la qualité de l'air

Laissez-vous guider par une mise en œuvre concrète pour un système de surveillance de la qualité de l'air – un cas commun d'utilisation intelligente de la ville.

Aperçu de l'architecture

  1. Senseurs: Capteurs de particules à faible coût (PM2,5, PM10) et de gaz (NO2, CO) déployés à 100 emplacements, chaque message MQTT publiant toutes les 60 secondes à AWS IoT Core.
  2. Ingestion: IoT Core transmet chaque message à une règle Amazon EventBridge, qui conduit à deux cibles: une fonction Lambda pour l'alerte en temps réel et une règle Amazon Kinesis Data Firehose pour le stockage par lots.
  3. Traitement en temps réel: Une fonction Lambda valide la charge utile JSON, convertit des unités (p. ex., ppb en μg/m3), et écrit le document enrichi à Amazon Timestream[. Si une lecture dépasse un seuil (p. ex., PM2,5 > 250 μg/m3), la fonction publie une alerte sur un sujet du SNS, qui envoie des SMS et des notifications par courriel aux responsables de la ville.
  4. Stockage par lots: Kinesis Firehose tampons entrants et écrit des fichiers de parquet compressés dans un Amazon S3 data lake, organisé par la date de partition. Une seconde fonction Lambda déclenchée par de nouveaux objets S3 met à jour des tableaux agrégés dans Amazon Athena.
  5. Visualisation:[ A QuickSight le tableau de bord affiche des mesures de qualité de l'air en temps réel et historique sur une carte de ville, avec des forages par emplacement de capteur. Le tableau de bord se rafraîchit toutes les 5 minutes, tirant de Timestream pour les données en direct et Athena pour l'analyse des tendances à long terme.
  6. Alerte tableau de bord:[ Une application sans serveur React hébergée sur Amplifier consomme des données de API Gateway[ soutenue par une fonction Lambda qui interroge les alertes récentes d'une table DynamoDB (écrite par la fonction alerte).

Optimisation des coûts

  • Utilisez DynamoDB TTL pour faire disparaître automatiquement les anciens enregistrements d'alerte après 90 jours.
  • Compresser et partition Données S3 pour réduire les coûts de la requête Athena.
  • Réservez la concordance sur Lambda uniquement pour la fonction d'alerte (critique de latence).La fonction de lot peut tolérer les démarrages à froid.
  • Utilisez les politiques du cycle de vie pour transférer les données de S3 de Standard à Glacier Deep Archive après un an.

Défis et considérations

Alors que les pipelines sans serveur simplifient de nombreux aspects, les déploiements de villes intelligentes posent des défis uniques qui doivent être abordés à l'avant.

Sécurité des données et confidentialité

  • Encryptage au repos et en transit:[ Tous les messages IoT doivent utiliser TLS 1.2+. Les tables de base de données et les objets S3 doivent être chiffrés avec des clés gérées par le client.
  • Identification de l'appareil:[ Utiliser des certificats par appareil avec de courtes périodes de validité pour minimiser le rayon de bouffée d'un capteur compromis.
  • Anonymisation des données:[ Pour les applications qui recueillent des informations d'emplacement ou d'identification personnelle (p. ex., reconnaissance des plaques d'immatriculation), les étapes de pipeline doivent appliquer le masquage ou l'agrégation des données pour se conformer à des règlements comme le RGPD.
  • Isolation du réseau:[ Déployer des fonctions et des bases de données à l'intérieur d'un VPC sans IPs publics; utiliser des paramètres VPC pour les services en nuage.

Exigences en matière de latence et de temps réel

  • Latence de bout en bout:[ Les fonctions sans serveur ajoutent des frais généraux de démarrage à froid de 50 à 500ms. Pour les cas d'utilisation de sous-100ms (p. ex., contrôle du signal de circulation), envisager d'utiliser des périphériques IoT Edge qui traitent les données localement et n'envoyer que des résumés dans le cloud.
  • Services de streaming:[ Pour un très haut débit, utilisez le traitement de flux géré (AWS Kinesis Data Analytics, Azure Stream Analytics) au lieu de fonctions individuelles par message. Ces services peuvent traiter des millions d'événements par seconde avec une faible latence.

Cohérence et commande des données

  • Événements hors-commande :[ Les retards réseau peuvent causer des données de capteur d'arrivée tardive. Utilisez l'horodatage de l'appareil (pas le temps d'ingestion) pour les requêtes de la série chronologique.
  • Détection du double: Les appareils IoT peuvent retransmettre des messages. Assignez des ID de message uniques (par exemple UUID) et utilisez le traitement idémpotent : vérifiez DynamoDB pour l'ID avant d'écrire.

Intégration avec les systèmes hérités

De nombreuses villes disposent de systèmes SCADA, de plateformes de gestion du trafic ou de systèmes de gestion de bâtiments. Ils utilisent souvent des protocoles propriétaires (Modbus, BACnet) ou des bases de données sur site. Un pipeline sans serveur peut les relier via API Gateway avec authentification personnalisée, ou en utilisant des connecteurs gérés comme AWS Transfer Family pour l'ingestion de fichiers FTP/SFTP.

Surveillance et observation

  • Retraçage distribué:[ Utilisez AWS X-Ray ou Azure Monitor pour tracer un seul message de capteur à travers tout le pipeline – de IoT Hub à fonction à base de données.
  • Alerter sur la santé des pipelines:[ Surveiller les taux d'erreur de Lambda, les files d'attente pour les messages en panne et la fraîcheur des données (p. ex., si aucune donnée d'un capteur pendant 10 minutes).
  • Suivi des coûts :[ Étiquette toutes les ressources par environnement et fonction; utilisez l'explorateur des coûts du cloud pour attribuer les dépenses à des composantes spécifiques du pipeline.

Relèvement et résilience en cas de catastrophe

  • Déploiement multi-régions:[ Pour les services urbains intelligents critiques (p. ex., intervention d'urgence), l'ingestion et le traitement répétés dans deux régions nuageuses avec configuration active.
  • Replication des données: Utilisez la réplication trans-région pour les tables S3 et DynamoDB.
  • Mécanismes de recul:[ Si une région nuageuse échoue, les périphériques de bord peuvent tamponner les données localement pendant des heures jusqu'à ce que la connectivité soit rétablie.

Exemples et pratiques exemplaires dans le monde réel

Plusieurs villes ont mis en place avec succès des pipelines IoT sans serveur:

  • BarcelonaS smart city plate-forme utilise Azure IoT Hub et Azure Functions pour traiter les données de capteurs à partir de 20 000 appareils, alimenter les tableaux de bord pour l'optimisation de la collecte des déchets, la disponibilité du stationnement et la surveillance du bruit.
  • Un réseau d'eau intelligent à Singapour utilise AWS Lambda et Kinesis pour détecter les profils de fuites de centaines de capteurs d'écoulement, réduisant ainsi la perte d'eau de 15%.
  • La gestion de la congestion routière à Los Angeles fait appel aux fonctions Google Cloud pour ingérer les données Waze en temps réel et ajuster le calendrier des signaux de trafic.

Les meilleures pratiques distillées de ces mises en œuvre sont notamment les suivantes:

  • Commencez par un pipeline minimum viable qui traite les données d'un type de capteur, puis élargissez.
  • Utiliser infrastructure comme code (AWS CDK, Terraform) pour la version et la réplique du pipeline à travers les environnements.
  • Mettre en œuvre dégradation progressive[ : si le pipeline échoue, les capteurs devraient continuer à utiliser et à tamponner les données localement.
  • Essais de bout en bout avec simulation de données de capteur (p. ex., en utilisant une fonction Lambda qui génère des charges utiles aléatoires).

Conclusion

En mettant à profit les services cloud gérés pour l'ingestion, le traitement, le stockage et l'analyse, les villes peuvent se concentrer sur la fourniture de valeur aux citoyens plutôt que sur la gestion des infrastructures. Bien que les défis demeurent autour de la sécurité, de la latence et de l'intégration des anciens, la flexibilité des architectures sans serveur, combinée avec l'informatique de pointe pour les tâches critiques dans le temps, en fait une base idéale pour les opérations modernes de la ville intelligente.

Les pipelines sans serveur fournissent la base élastique nécessaire pour transformer ces données en intelligences actionnables, aidant les villes à devenir plus efficaces, durables et réceptives aux besoins de leurs résidents.