Comprendre les systèmes d'acquisition de données en temps réel

Les systèmes d'acquisition de données en temps réel (DAQ) constituent l'épine dorsale de la surveillance et du contrôle modernes de l'ingénierie. Ils collectent en permanence des signaux analogiques ou numériques des capteurs, des transducteurs et des instruments, les convertissent en données processables et fournissent les résultats aux bases de données de contrôle des boucles, des tableaux de bord ou des bases de données historiques avec une latence limitée. Les applications typiques vont de l'automatisation des processus industriels et de la surveillance du réseau électrique aux essais de soufflerie et aux expériences de physique à haute énergie.

Refaire un système DAQ en direct est par nature risqué car les temps d'arrêt des processus peuvent être coûteux ou même dangereux. Cependant, lorsqu'il est fait systématiquement, il produit un système plus durable, évolutif et résilient. Cet article distillait les meilleures pratiques tirées de l'expérience industrielle, en mettant l'accent sur l'évaluation de l'architecture, la refonte modulaire, les cadres de streaming modernes, l'optimisation du stockage, les essais et les considérations de sécurité.

Évaluation de l'architecture actuelle du système

Avant de toucher une seule ligne de code ou d'échanger un composant matériel, vous devez développer une compréhension complète du système existant. Cette évaluation sert de base à toutes les décisions ultérieures.

Documenter le flux de données et les dépendances

Faites une carte de l'ensemble du chemin de données depuis l'entrée du capteur jusqu'à la consommation finale. Identifiez chaque étape de traitement, tampon, protocole de communication et couche de stockage. Faites une attention particulière aux dépendances implicites – par exemple, un fichier de configuration lu par plusieurs modules, ou un bloc mémoire partagé auquel plusieurs processus accèdent sans verrouillage explicite.

Identification des goulets d'étranglement et de la dette technique

Analyser les mesures de performance de la production : utilisation du processeur, consommation de mémoire, latence du réseau, temps d'attente des entrées et sorties sur disque et pauses de collecte des ordures (si l'on utilise des langages gérés).

  • Traitement en série sur un seul fil qui ne peut pas suivre le rythme des débits d'échantillonnage des capteurs.
  • Architectures basées sur la pollution[ qui gaspillent les cycles CPU au lieu d'utiliser des approches axées sur l'événement ou des approches axées sur l'interruption.
  • Les moteurs de stockage surchargés qui bloquent les écritures pendant les rafales de pointe.
  • Un tampon inadéquat qui entraîne une perte de données sous charge transitoire.
  • Raccordement serré entre l'acquisition de données et les routines analytiques, rendant impossible leur échelle indépendante.

Documenter chaque point de douleur avec des preuves concrètes (p. ex., la latence d'écriture médiane dépasse 50 ms pendant les pics d'une minute).

Évaluation des exigences en matière de scalabilité

Le nombre de données futures du projet sera-t-il double? Les taux d'échantillonnage augmenteront-ils? De nouveaux types de données (p. ex. vidéo haute résolution) sont-ils attendus? Le refactoring devrait non seulement résoudre les problèmes actuels, mais aussi fournir une marge de croissance. Par exemple, un système qui gère actuellement 10 000 points de données par seconde pourrait devoir traiter 100 000 en deux ans.

Adopter un modèle modulaire

Une des étapes les plus importantes de la refacturation est de briser un système DAQ monolithique en modules interchangeables et à couplage lâche. Une architecture modulaire bien conçue isole les préoccupations, permet des tests indépendants et vous permet de mettre à niveau les composants un à la fois sans déstabiliser l'ensemble du système.

Séparation des préoccupations

Diviser le système en couches fonctionnelles distinctes:

  • Couche d'acquisition:[ Gère la communication des capteurs, le conditionnement des signaux et l'ingestion de données brutes. Cette couche doit être matériellement-aimée mais présenter une interface uniforme avec les couches supérieures.
  • Couche de traitement:[ Applique le filtrage, la transformation, le chronométrage et éventuellement l'analyse des bords. Ce calque peut être étalonné horizontalement en ajoutant des nœuds de travail.
  • Couche de stockage: Poignées persistance – bases de données de séries temporelles, magasins d'objets ou caches in-memory. Il doit supporter un débit d'écriture élevé et une récupération efficace.
  • Couche de présentation/d'action: Fournit des tableaux de bord, des alertes ou des commandes de contrôle. Ce calque ne devrait jamais bloquer l'acquisition ou le traitement.

Chaque calque communique par des API ou files d'attentes de messages bien définies. Par exemple, vous pouvez utiliser gRPC pour les commandes synchrones et un courtier de messages pour la diffusion de données asynchrones.

Définition des interfaces claires

Chaque module doit exposer un contrat qui spécifie le format de données d'entrée, le format de données de sortie, les codes d'erreur et les garanties de performance. Ce module découple les équipes de développement (ou même la sélection des fournisseurs) et vous permet de remplacer, par exemple, une interface PLC propriétaire par une implémentation OPC‐UA sans toucher la couche de traitement.

Utilisation de l'injection de dépendance et de la configuration

Les dépendances codées en dur (p. ex., un nom spécifique du pilote de capteur dans la logique de traitement) rendent la refacturation douloureuse. Injectez plutôt des dépendances au démarrage en utilisant des fichiers de configuration, des variables d'environnement ou un conteneur de service.

Mise en œuvre de cadres modernes de traitement des données en temps réel

Les systèmes DAQ hérités reposent souvent sur des boucles de vote, des programmes de socket bruts ou des intergiciels écrits sur mesure qui ne tolèrent pas les erreurs ou qui ne peuvent pas être adaptés.

Apache Kafka

Apache Kafka est une plateforme distribuée de diffusion d'événements qui peut traiter des millions de messages par seconde avec durabilité et exactement une fois sémantique (lorsqu'elle est configurée correctement).Dans un contexte DAQ, chaque capteur ou source de données peut produire des enregistrements sur un sujet Kafka, et les processeurs en aval (p. ex. moteurs d'analyse, bases de données, tableaux de bord) les consomment à leur propre rythme.

Pour le contrôle de boucle fermée à faible latence (< 10 ms), vous pouvez avoir besoin d'un canal dédié en temps réel (par exemple, mémoire partagée). Kafka est idéal pour les données -=hot path= qui sont enregistrées, agrégées ou en streaming vers le stockage historique.

MQTT

MQTT est un protocole d'abonnement léger conçu pour les appareils limités et les réseaux à faible bande passante. Il est particulièrement populaire dans les environnements IoT et industriels en raison de sa petite empreinte de code et de ses trois niveaux de qualité de service (au plus une fois, au moins une fois, exactement une fois). De nombreux capteurs industriels parlent MQTT nativement. Pour un système DAQ refactoré, vous pouvez utiliser un courtier MQTT (comme ]Eclipse Mosquitto ou HiveMQ) pour collecter la télémétrie à partir de dispositifs de bord, puis pour relier ces messages à une plateforme de streaming plus puissante (p. ex. Kafka) pour une analyse plus approfondie.

Autres options

Pour les environnements qui nécessitent un timing déterministe (p. ex., contrôle de mouvement, électronique de puissance), il faut considérer un service de distribution de données en temps réel (DDS) tel que RTI Connext ou Eclipse Cyclone DDS. DDS offre des contrôles de qualité de service (délai, budget de latence, priorité de transport) qui ne sont pas disponibles à Kafka ou MQTT.

Optimisation des solutions de stockage de données

Les systèmes DAQ produisent des données de séries chronologiques à des taux qui dépassent rapidement les bases de données relationnelles traditionnelles. La couche de stockage doit supporter un débit d'écriture élevé, gérer des requêtes efficaces à portée de temps et gérer les politiques de conservation des données.

Bases de données de séries chronologiques

Des bases de données dédiées de séries temporelles (TSDB) comme TimescaleDB[] (construits sur PostgreSQL), InfluxDB[, ou VictoriaMetrics[ sont optimisées pour ces charges de travail. Elles compressent les données (souvent en utilisant un stockage axé sur les colonnes), réduisent automatiquement l'échantillon des données plus anciennes et supportent les politiques de rétention pour supprimer ou agréger des données au-delà d'un certain âge. Dans un système refacturé, remplacez une base de données SQL générique qui est en difficulté avec un TSDB. Par exemple, InfluxDB peut gérer des centaines de milliers de points par seconde sur du matériel modeste.

Cachement en mémoire et stockage rapide

Pour la plus faible latence d'écriture possible, utilisez un data store in-memory comme Redis comme tampon à court terme. Publiez les lectures brutes de capteur sur les flux ou les listes de Redis, puis faites-les écrire par lot au consommateur de fond à la TSD. Ceci découple le chemin d'acquisition de la méthode d'entrée/sortie plus lente et offre une résilience contre la contre-pression de stockage. Vous pouvez également utiliser Redis pour des tableaux de bord rapides qui montrent des tendances en temps réel.

Gestion du cycle de vie des données

Il n'est pas nécessaire de conserver toutes les données dans un stockage à chaud.Mettre en œuvre une stratégie de stockage à plusieurs niveaux : les données récentes (p. ex., les 7 derniers jours) dans les systèmes rapides de gestion des données (NVMe), les données plus anciennes (p. ex., les 6 derniers mois) sur les SSD ou les DDH, et les données d'archives dans le stockage d'objets (S3, GCS ou MinIO sur site).

Assurer la tolérance aux fautes et une grande disponibilité

Un système DAQ en temps réel doit continuer à fonctionner même lorsque les composants échouent. La refactoring est l'occasion idéale de durcir le système contre les modes de défaillance courants.

Redondance à chaque couche

Considérez la redondance N+1 (ou 2N) pour les composants critiques : alimentations de capteurs redondantes, double trajets réseau, serveurs d'acquisition miroirs et répliques pour les bases de données et les courtiers de messages. Utilisez un algorithme de bilan de charge ou de maîtrise (par exemple Raft) pour faire automatiquement défaut. Pour Kafka, définissez le facteur de réplication à au moins 3; pour MQTT, déployez plusieurs courtiers derrière un bilan de charge ou utilisez un pontage MQTT-over-TCP. Testez régulièrement les scénarios de décrochage – un veille à froid qui n'a pas été exercé est un passif.

Dégradation gracieuse et prévention de la perte de données

Lorsque le moteur de stockage est inaccessible, la couche d'acquisition doit tamponner les données localement (par exemple dans un tampon à anneaux sur RAM ou une carte SD) et les rejouer une fois la connectivité rétablie. Concevoir le système pour jeter des données non critiques sous une charge extrême plutôt que de planter. Documenter ces modes de dégradation afin que les opérateurs sachent à quoi s'attendre.

Essais et validations pendant la remise en état

Refactoring sans filet de sécurité est imprudent. Mettre en œuvre une stratégie d'essai complète qui couvre les tests unitaires, les tests d'intégration, les tests de performance et l'ingénierie du chaos.

Essais d'unité et d'intégration

Chaque module devrait être équipé d'un harnais d'essai qui exerce son API publique avec des données valides et non valides. Utilisez des maquettes pour les dépendances externes (capteurs, courtiers, bases de données). Les tests d'intégration devraient exécuter une version réduite de l'ensemble du pipeline dans un environnement CI, en envoyant des données de capteur synthétique et en vérifiant le traitement et le stockage corrects.

Performance et tests de stress

Créer un banc de test qui reflète les conditions de production (même matériel, même latence réseau). Générer des données à 2× le taux de pointe prévu pour vérifier que les latences restent dans les limites et aucune perte de données ne se produit. Mesurer le comportement du système sous surcharge prolongée – il ne devrait pas déposer silencieusement des échantillons ou manquer de mémoire.

Génie du chaos

Vérifiez que le système peut encore acquérir des données critiques, que la panne se produit sans intervention manuelle, et que les alarmes s'allument correctement. Documenter le rayon de la blaste de chaque défaillance – combien de capteurs sont affectés quand un seul courtier tombe ? Cette connaissance est inestimable pour les opérateurs.

Considérations de sécurité en matière de retraitement

Les systèmes DAQ en temps réel sont de plus en plus ciblés par les cyberattaques, surtout dans les infrastructures essentielles.

Renforcement des voies de communication

Pour MQTT, faire respecter les certificats clients et éviter l'accès anonyme. Kafka peut utiliser SASL/SCRAM ou l'authentification SSL. Assurez-vous que les interfaces de gestion (API REST, tableaux de bord web) ne sont pare-feu ou accessibles qu'avec VPN.

Validation d'entrée et authentification du capteur

Supposons que les entrées de capteur peuvent être malveillantes (p. ex. paquets UDP vaporisés). Valider la plage de données, la plausibilité de l'horodatage et le format des messages avant le traitement. Utilisez des signatures cryptographiques ou une identité matérielle (TPM) pour authentifier les capteurs lorsque c'est possible.

Planification du déploiement de la refactoration

Les réécritures de systèmes en temps réel par Big-bang sont rarement réussies. Adopter plutôt une approche progressive qui minimise les risques.

Dessin de la figure de l'étrangleur

Construisez le nouveau stockage en parallèle, acheminez les données vers l'ancien et le nouveau stockage simultanément, et après validation, changez le consommateur lit vers le nouveau système. Puis désencombrez l'ancien composant. Ce modèle, connu sous le nom de -strangler fig. , a été utilisé avec succès dans de nombreux projets informatiques industriels.

Déploiements des Canaries

Pour un système avec plusieurs nœuds d'acquisition identiques, mettez à niveau un nœud vers la nouvelle version tandis que d'autres restent sur l'ancienne version. Surveillez ses performances et taux d'erreur pendant une semaine. S'il passe, lancez-le progressivement. Ceci est plus sûr que de mettre à niveau l'ensemble de la flotte à la fois, et il vous donne un point de chute si des problèmes émergent.

Conclusion

En évaluant de façon approfondie l'architecture existante, en adoptant une conception modulaire, en tirant parti des cadres de diffusion modernes tels qu'Apache Kafka ou MQTT, en optimisant le stockage par des bases de données de séries chronologiques et des caches in-memory, en intégrant la tolérance aux erreurs, la sécurité et des tests rigoureux dans le processus, vous construisez un système plus résistant, évolutif et durable. L'investissement dans la planification soignée, le déploiement progressif et la validation continue est rentable grâce à des temps d'arrêt réduits, des ajouts plus faciles et une qualité des données améliorée.