Traitement edge¶

Traiter les données au plus près du capteur réduit la latence à quelques millisecondes et divise la consommation de bande passante par un facteur 10 à 1 000 selon les cas.

Pourquoi ne pas tout envoyer dans le cloud¶

La question revient régulièrement lors des premières conceptions IoT : pourquoi ne pas simplement streamer toutes les données vers le cloud et faire le traitement là-haut ? Les ressources de calcul y sont élastiques, les coûts de stockage bas, et les outils de data science abondants.

La réalité terrain impose quatre contraintes que le cloud seul ne résout pas.

Latence. Une chaîne de production qui détecte une anomalie mécanique ne peut pas attendre 200 ms d'aller-retour réseau. La décision de déclencher un arrêt d'urgence doit être prise en moins de 5 ms. Le traitement doit être local.

Bande passante. Un capteur vibratoire industriel échantillonne à 25 kHz sur 3 axes en 16 bits. C'est 150 kB/s par capteur. Une ligne de 50 capteurs génère 7,5 MB/s en continu — soit 648 GB/jour. Envoyer tout cela vers le cloud est économiquement insoutenable et techniquement impossible sur un lien LPWAN ou 4G partagé.

Autonomie et résilience. Les connexions réseau tombent. Une gateway déconnectée du cloud doit continuer à opérer localement, à stocker les données, et à les retransmettre quand la liaison est rétablie. Un système qui s'arrête sans internet n'est pas un système industriel.

Confidentialité et conformité. Certaines données de production (cadences, rebuts, paramètres process) sont stratégiquement sensibles. Des contraintes réglementaires (RGPD, normes sectorielles) peuvent interdire leur transmission hors site. Le traitement local maintient les données dans le périmètre de l'entreprise.

Filtrage et agrégation¶

Le premier niveau de traitement edge est le plus simple à implémenter et le plus immédiatement efficace : réduire le volume de données avant toute transmission.

Filtrage par seuil¶

Le cas le plus courant : ne transmettre une mesure que si elle dépasse un seuil ou change significativement. Un capteur de température industrielle ne change pas de valeur chaque seconde dans des conditions normales. Transmettre uniquement les changements supérieurs à 0,5 °C réduit le volume de données de 90 % sur la plupart des scénarios.

/* Exemple : filtrage par deadband sur microcontrôleur */
#define DEADBAND_TEMP   0.5f   /* °C */
#define DEADBAND_PRESS  0.02f  /* bar */

static float last_sent_temp = NAN;

bool should_transmit_temp(float new_value) {
    if (isnan(last_sent_temp)) return true;
    if (fabsf(new_value - last_sent_temp) >= DEADBAND_TEMP) {
        last_sent_temp = new_value;
        return true;
    }
    return false;
}

Agrégation temporelle¶

Plutôt que d'envoyer chaque mesure brute, calculer localement des statistiques sur une fenêtre glissante : min, max, moyenne, écart-type. Une fenêtre de 60 secondes à 100 Hz donne 6 000 points réduits à 4 valeurs — réduction de 99,9 %.

# Exemple : agrégation sur fenêtre glissante (MicroPython / Edge device)
from collections import deque
import math

class WindowAggregator:
    def __init__(self, window_size=60):
        self.window = deque(maxlen=window_size)

    def push(self, value):
        self.window.append(value)

    def stats(self):
        if not self.window:
            return None
        data = list(self.window)
        mean = sum(data) / len(data)
        variance = sum((x - mean) ** 2 for x in data) / len(data)
        return {
            "min": min(data),
            "max": max(data),
            "mean": round(mean, 3),
            "std": round(math.sqrt(variance), 3),
            "count": len(data)
        }

Détection d'anomalies par règles locales¶

Au-delà du simple seuil, on peut implémenter localement des règles multi-variables : détection de dérive lente (trend), corrélation entre capteurs, fenêtre de vote (3 mesures consécutives hors seuil avant alerte). Ces règles réduisent drastiquement les faux positifs sans passer par le cloud.

Décision locale vs délégation cloud¶

La question centrale n'est pas "edge ou cloud" mais "quelle décision à quel niveau". Le diagramme suivant illustre un arbre de décision pour orienter chaque type de traitement.

flowchart TD
    A[Donnée capteur] --> B{Latence requise\n< 10 ms ?}
    B -- Oui --> C[Traitement\nédge obligatoire]
    B -- Non --> D{Connexion réseau\ndisponible ?}
    D -- Non --> E[Traitement local\n+ buffering]
    D -- Oui --> F{Volume > 100 kB/s\npar device ?}
    F -- Oui --> G[Agrégation locale\npuis envoi résumé]
    F -- Non --> H{Données sensibles\nou hors périmètre ?}
    H -- Oui --> I[Traitement local\nexclusivement]
    H -- Non --> J[Envoi cloud\nadmissible]

    C --> K[Actionneur local\ndéclenché en < 5 ms]
    E --> L[Retransmission\nbatch dès reconnexion]
    G --> M[5-10 valeurs/min\nau lieu de 100 kB/s]
    I --> N[Agrégats anonymisés\nenvoyés si besoin]
    J --> O[Traitement ML\net analytics cloud]

Inférence ML locale — TinyML¶

Le traitement edge ne se limite pas aux règles statiques. Les techniques TinyML permettent d'embarquer des modèles d'apprentissage automatique directement sur des microcontrôleurs ou des SBC (Single Board Computers), sans connexion cloud.

Cas d'usage typiques¶

TensorFlow Lite Micro (TFLite Micro)¶

TFLite Micro est le runtime d'inférence de Google conçu pour les environnements sans OS, sans allocation dynamique, avec aussi peu que 16 KB de RAM. Le workflow comprend :

1. Entraîner le modèle sur PC (TensorFlow / Keras)
2. Convertir en .tflite avec le convertisseur TFLite
3. Quantifier en int8 pour réduire la taille (typiquement ÷4) et accélérer l'inférence
4. Intégrer le runtime C++ dans le firmware embarqué

// Squelette d'inférence TFLite Micro sur Arduino/mbed
#include "tensorflow/lite/micro/all_ops_resolver.h"
#include "tensorflow/lite/micro/micro_interpreter.h"
#include "model_data.h"  // tableau C généré par xxd

// Arène mémoire statique — allouée à la compilation
constexpr int kTensorArenaSize = 32 * 1024;
alignas(16) uint8_t tensor_arena[kTensorArenaSize];

tflite::AllOpsResolver resolver;
const tflite::Model* model = tflite::GetModel(g_model_data);
tflite::MicroInterpreter interpreter(model, resolver,
                                     tensor_arena, kTensorArenaSize);
interpreter.AllocateTensors();

// Inférence
TfLiteTensor* input = interpreter.input(0);
memcpy(input->data.f, sensor_buffer, sizeof(float) * INPUT_SIZE);
interpreter.Invoke();
TfLiteTensor* output = interpreter.output(0);
float confidence = output->data.f[CLASS_ANOMALY];

Edge Impulse¶

Edge Impulse est la plateforme la plus utilisée pour le TinyML industriel. Elle automatise la chaîne complète :

• Collecte de données depuis le device (USB, Bluetooth, Wi-Fi)
• Labellisation et augmentation
• Conception du pipeline de traitement signal (DSP blocks)
• Entraînement et benchmarking multi-cibles
• Export en bibliothèque C++ prête à flasher

Le benchmark automatique indique pour chaque modèle : taille flash, RAM utilisée, latence d'inférence sur la cible choisie — ce qui permet de valider la faisabilité matérielle avant même de flasher le device.

Limites et précautions¶

L'inférence locale n'est pas gratuite. Les contraintes à respecter :

• La quantification int8 dégrade légèrement la précision (typiquement 1 à 3 % de F1-score)
• Le modèle doit être re-entraîné et re-déployé quand la distribution des données change (drift)
• Les MCU bas de gamme (< 64 MHz, < 64 KB RAM) ne peuvent pas héberger de réseaux convolutifs complexes
• La validation sur données terrain est indispensable avant déploiement en production

Stratégie de traitement en couches¶

Une architecture robuste combine plusieurs niveaux de traitement, chacun à la granularité appropriée.

Ce qu'il faut retenir¶

• Traiter en local est impératif quand la latence est critique, le réseau indisponible, le volume trop élevé ou les données sensibles.
• Le filtrage par deadband et l'agrégation temporelle sont les premiers gains à implémenter — simples et très efficaces.
• TFLite Micro et Edge Impulse permettent d'embarquer une inférence ML compétente sur des MCU modestes (ARM Cortex-M4/M7).
• L'architecture en couches (MCU → concentrateur → edge server → cloud) distribue le traitement selon les contraintes de chaque niveau.

Chapitre suivant : Gateway multi-protocoles — comment faire coexister Zigbee, LoRa, BLE et MQTT sur une seule infrastructure.