Suivi d’actifs autoréparateur : comment l’automatisation a réduit de 80 % les interventions sur site

Les traceurs ne tombent que rarement en panne d’un seul coup. Le plus souvent, ils continuent d’émettre tout en dégradant progressivement la qualité des données dont dépendent les opérations de flotte. Cette étude de cas montre comment un terminal à conteneurs a automatisé la récupération de l’appareil avec le modèle Device Health Check dans Navixy IoT Logic, réduisant de 80 % le travail de récupération manuelle, et comment la même approche peut évoluer en un cadre de surveillance de l’état de l’appareil beaucoup plus complet.

Lorsque les traceurs restent en ligne mais cessent d’être fiables

En télématique, en ligne ne signifie pas toujours en bon état. Un traceur peut continuer à envoyer des données tout en perdant progressivement sa capacité à fournir une position fiable, à signaler une tension stable ou à communiquer régulièrement. Les répartiteurs voient toujours le véhicule. Les équipes de maintenance reçoivent toujours la télémétrie. Pourtant, tôt ou tard, quelqu’un doit répondre à une question familière : ce traceur a-t-il simplement besoin d’un redémarrage ou y a-t-il un véritable problème matériel derrière ces symptômes ?

Répondre manuellement à cette question pour chaque appareil suspect devient vite une tâche de routine dans les grandes flottes. Le problème ne vient pas du fait que les traceurs se comportent mal de temps à autre : tous les déploiements y sont confrontés. Le défi consiste à reconnaître ces situations de manière systématique et à réagir avant qu’elles ne se transforment en tickets de support ou en visites sur le terrain inutiles.

L’automatisation change la donne. La télémétrie entrante peut être évaluée en continu, les appareils défaillants identifiés automatiquement, et la première étape de récupération effectuée sans attendre l’intervention humaine. Les techniciens n’interviennent alors que dans les cas que l’automatisation ne peut pas résoudre, là où leur expertise apporte généralement le plus de valeur.

En savoir plus sur les automatisations prêtes à l’emploi avec IoT Logic :

• Réponse automatisée au ralenti
• Contrôle d’accès conducteur

Automatisation de l’état de l’appareil sans tout reconstruire de zéro

Mettre en place ce type de flux de travail n’est pas particulièrement difficile. C’est cependant répétitif. Chaque mise en œuvre doit recevoir la télémétrie, évaluer l’état de l’appareil, décider si une récupération est nécessaire, exécuter l’action appropriée et poursuivre le traitement.

Le modèle Device Health Check dans Navixy IoT Logic fournit déjà ce flux de travail. Plutôt que de concevoir la logique de zéro, les ingénieurs peuvent adapter les conditions de santé et les actions de récupération à leurs appareils et à leur environnement opérationnel.

Sur le plan général, le flux de travail reste le même, quelle que soit la flotte :

1. Recevoir la télémétrie entrante.
2. Évaluer les conditions de santé configurées.
3. Poursuivre le traitement normal si l’appareil est en bon état.
4. Exécuter les actions de récupération configurées dans le cas contraire.

Le modèle est conçu pour être adapté, pas déployé tel quel. Les flottes rencontrent des pannes différentes, utilisent du matériel différent et définissent « en bon état » de manière variable. Le flux de travail demeure le même tandis que le modèle de santé évolue.

Étude de cas : adapter le modèle pour les véhicules d’un terminal portuaire

Un terminal à conteneurs de taille moyenne exploitait une flotte diversifiée : tracteurs de parc, reach stackers, chariots élévateurs à conteneurs, chariots élévateurs et véhicules de service.

La flotte utilisait des traceurs GPS Teltonika capables de surveiller la tension d’alimentation externe, de configurer la télémétrie, d’intégrer CAN et d’exécuter des commandes à distance. Bien que cette étude de cas se concentre sur le matériel Teltonika, l’approche globale s’applique à tout traceur prenant en charge la gestion à distance.

Le déploiement couvrait des véhicules alimentés qui rapportent en continu leur télémétrie et peuvent recevoir des commandes à distance. Les traceurs autonomes fonctionnant sur batterie en mode sommeil profond nécessitent une autre stratégie de surveillance.

Le défi opérationnel

L’équipe de maintenance rencontrait sans cesse la même situation. Un traceur semblait se comporter de manière inhabituelle. Il était toujours en ligne, mais quelque chose n’allait pas. La réception GNSS se dégradait entre les piles de conteneurs. L’alimentation externe devenait instable après un entretien. Parfois, le traceur cessait simplement de fournir une position fiable tout en restant connecté à la plateforme.

Chaque incident suivait essentiellement le même processus. Quelqu’un passait en revue la télémétrie, décidait s’il valait la peine d’essayer un redémarrage à distance, envoyait la commande, puis vérifiait si l’appareil revenait à un fonctionnement normal ou nécessitait une inspection sur site.

Aucun de ces cas ne justifiait à lui seul un projet logiciel. Mais mis bout à bout, ils représentaient un flux constant de travaux de maintenance de routine, consommant du temps d’ingénierie sans réelle valeur ajoutée.

Commencer avec le modèle Device Health Check standard

Plutôt que de créer un flux de travail personnalisé, l’équipe a démarré avec le modèle Device Health Check standard fourni avec Navixy IoT Logic.

Par défaut, le modèle évalue quatre conditions de santé de base :

latitude != null &&
longitude != null &&
satellites >= 4 &&
board_voltage >= 11.5

Si l’expression est TRUE, la télémétrie poursuit le chemin de traitement normal.

Si elle est FALSE, la télémétrie est toujours transmise et le flux de travail exécute également l’action de récupération configurée. Le modèle standard inclut des actions de redémarrage pour les appareils Teltonika (cpureset) et Jimi/Concox (RESET#), lui permettant de prendre en charge divers types de matériels dès le départ.

Comme la flotte du terminal se composait uniquement d’appareils Teltonika, l’équipe a simplement supprimé le nœud de redémarrage Jimi et conservé l’action de récupération Teltonika.

Le contrôle de santé a nécessité seulement trois ajustements. Le paramètre générique board_voltage a été remplacé par l’attribut spécifique à Teltonika external_voltage. Le seuil de satellites est passé de quatre à cinq. Enfin, l’équipe a ajouté une condition HDOP pour améliorer la validation GNSS dans un environnement où les grues, les piles de conteneurs et beaucoup d’acier rendent toujours la réception satellite, comme tout ingénieur portuaire le sait, un peu imprévisible.

La condition de santé finale est donc devenue :

external_voltage >= 11.5 &&
latitude != null &&
longitude != null &&
satellites >= 5 &&
(hdop == null || hdop < 2.5)

Le reste n’a pas changé.

Quel résultat ?

La phase d’essai de 90 jours a réduit d’environ 80 % les interventions manuelles de récupération des traceurs. Plus important encore, cela a transformé le flux de travail de maintenance lui-même. Les appareils répondant aux critères de récupération prédéfinis redémarraient automatiquement, souvent avant que quiconque ne remarque le problème. Les équipes de maintenance n’intervenaient que lorsque la récupération automatisée échouait ou lorsque les conditions de santé indiquaient un problème matériel plutôt qu’un simple dysfonctionnement logiciel.

Les demandes de redémarrage de routine ont pratiquement disparu. Les techniciens passaient moins de temps à examiner une télémétrie qui aboutissait finalement à la même action de récupération, tandis que les visites sur le terrain se concentraient de plus en plus sur de véritables défauts matériels, tels que des antennes endommagées, un câblage instable ou des problèmes d’alimentation. L’automatisation n’a pas supprimé les travaux de maintenance. Elle a supprimé ceux qui ne nécessitaient pas de jugement humain.

La mise en œuvre décrite ici est volontairement simple, et pour de nombreuses flottes ce niveau d’automatisation suffit déjà à apporter une valeur immédiate.

Cependant, les terminaux portuaires comptent parmi les environnements les plus exigeants pour les appareils de télématique. Un examen plus approfondi de ces conditions d’exploitation révèle des possibilités de développer des modèles de santé de l’appareil bien plus complets, tout en conservant le même flux de travail sous-jacent.

Concevoir un modèle de santé plus complet

Comme indiqué, l’étude de cas ci-dessus illustre une mise en œuvre volontairement simple. Avec seulement quelques ajustements aux conditions de santé par défaut, le terminal a automatisé une part importante des interventions de récupération de routine.

Cela amène naturellement la question suivante : si l’on obtient autant de valeur en surveillant quatre ou cinq paramètres, que se passe-t-il lorsque le modèle de santé reflète plus en détail l’environnement opérationnel ?

Les terminaux portuaires en fournissent un bon exemple.

Les véhicules passent leurs journées entre des piles de conteneurs, des grues, des entrepôts et d’imposantes structures métalliques. Les conditions GNSS changent en permanence. Le câblage est exposé aux vibrations. Des interruptions d’alimentation se produisent pendant l’entretien. La communication CAN peut être perdue alors que le traceur lui-même reste en ligne.

Aucun de ces exemples ne signale forcément un traceur défectueux. Pris ensemble, ils fournissent toutefois un tableau bien plus complet de l’état de l’appareil que la simple latitude, longitude, le nombre de satellites et la tension. Plutôt que de repenser le flux de travail, les ingénieurs enrichissent simplement le modèle de santé.

Un modèle courant évalue quatre groupes de paramètres.

Zone de santé	Paramètres typiques
GNSS	Nombre de satellites, HDOP, validité du fix, âge de la dernière position valide
Alimentation	Tension externe, batterie de secours, état du contact, stabilité de la tension
Communication	Qualité du signal, nombre de reconnexions, fréquence des paquets, temps depuis la dernière communication
Interface véhicule	Disponibilité CAN, fraîcheur des données moteur, entrées numériques

Ces groupes ne constituent pas une norme universelle. Ils représentent une manière pratique de décrire les aspects du comportement de l’appareil qui importent pour ce type de flotte.

Élaborer la logique de santé

Une fois la télémétrie nécessaire disponible, il existe deux méthodes courantes pour définir le contrôle de la santé.

La première consiste à définir à quoi ressemble un traceur en bon état.

Le nœud If-then évalue simplement si la télémétrie entrante correspond aux conditions de fonctionnement prévues.

Par exemple :

external_voltage >= 11.5 &&
communication_status == "stable" &&
gnss_quality == "good" &&
can_available == true

Si l’expression est TRUE, le flux de travail se poursuit normalement.

Si elle est FALSE, le traceur s’écarte de son état de fonctionnement attendu et la branche de récupération se déclenche.

La seconde approche part de l’idée opposée.

Plutôt que de décrire un comportement sain, elle décrit des signatures de panne spécifiques qui doivent déclencher une action.

Par exemple :

external_voltage >= 11.5 &&
communication_status == "stable" &&
gnss_quality == "poor" &&
gnss_bad_duration_min > 10

Ici, le traceur est encore alimenté et reste connecté, mais la qualité GNSS est mauvaise depuis suffisamment longtemps pour suggérer que le module de positionnement a besoin d’une intervention.

En pratique, les deux approches se complètent très bien.

Le contrôle de santé répond d’abord à une question simple :

« Le traceur est-il en bon état ? »

Si la réponse est non, des règles supplémentaires déterminent pourquoi et sélectionnent l’action de récupération la plus appropriée. Séparer ces deux décisions rend le flux de travail plus facile à comprendre et à étendre à mesure que de nouveaux schémas de panne apparaissent.

Quand la télémétrie ne suffit pas

La conception du modèle de santé révèle souvent une autre réalité.

Les paramètres souhaités ne sont pas toujours ceux que le traceur fournit.

Certains appareils rapportent le nombre de satellites mais pas une indication utile de la qualité de positionnement. D’autres donnent la tension mais pas la stabilité de l’alimentation. Un troisième peut indiquer chaque horodatage de communication mais jamais nous dire que la communication est devenue peu fiable.

C’est là que le nœud Initiate Attribute devient utile.

Plutôt que de créer des expressions de plus en plus complexes dans le contrôle de santé lui-même, les ingénieurs peuvent créer des attributs opérationnels de plus haut niveau avant que le modèle Device Health Check n’évalue la télémétrie.

Le flux de travail devient :

Incoming telemetry
        │
        ▼
Initiate Attribute
(create operational attributes)
        │
        ▼
Device Health Check
        │
        ▼
Recovery actions

Considérez le nœud Initiate Attribute comme une couche de traduction.

La télémétrie brute décrit ce que le traceur rapporte.

Les attributs opérationnels décrivent ce que ces mesures signifient.

Exemple : dériver la qualité GNSS

Supposons que le traceur envoie :

• latitude, • longitude, • satellite count, • HDOP.

Plutôt que d’évaluer ces quatre mesures dans tout le flux de travail, le nœud Initiate Attribute peut les combiner en un seul attribut :

gnss_quality

Par exemple :

Télémétrie d’entrée	Valeur dérivée
Coordonnées manquantes	Poor
Satellite count en dessous de 5	Poor
HDOP ≥ 4	Poor
HDOP entre 2,5 et 4	Degraded
Autrement	Good

Désormais, le contrôle de santé évalue :

gnss_quality == "good"

plutôt que d’interpréter plusieurs valeurs de télémétrie à chaque nouveau message.

Le même principe s’applique à la qualité de communication, à la stabilité de l’alimentation, à la disponibilité CAN ou à tout autre indicateur opérationnel. Une fois ces attributs créés, la logique de santé devient plus lisible, plus facile à maintenir et bien plus simple à adapter lorsque la définition d’un traceur « en bon état » évolue.

C’est une différence importante.

Le flux de travail ne devient pas plus compliqué.

La compréhension de l’état de l’appareil devient plus sophistiquée, tandis que le flux de travail lui-même reste globalement identique.

Une autre façon de penser la santé de l’appareil

Le résultat le plus marquant de ce projet ne se limite pas à la réduction de 80 % du travail de récupération manuelle. C’est plutôt la transition entre se demander si un traceur est en ligne et se demander si ses données sont toujours fiables.

Cette nuance est importante parce que la télématique moderne intervient dans la répartition, la maintenance, la conformité, l’analyse de l’utilisation et la planification opérationnelle. Un appareil connecté peut continuer à émettre tout en fournissant des données incomplètes ou peu fiables. Du point de vue de la plateforme, il est en ligne. Du point de vue opérationnel, il a déjà entamé sa défaillance.

La surveillance de l’état de l’appareil change cette perspective. Plutôt que de réagir après que quelqu’un remarque un problème, les opérateurs définissent ce que « en bon état » signifie pour leur flotte, surveillent ces conditions de manière continue et automatisent la première réponse lorsqu’un traceur s’écarte de ces standards. Le modèle Device Health Check offre un point de départ pratique pour cette approche. À mesure que les besoins évoluent, le modèle de santé devient plus sophistiqué tandis que le flux de travail sous-jacent reste familier.

La leçon la plus large va bien au-delà des terminaux portuaires. Chaque flotte a sa propre définition d’un appareil en bon état, car chaque flotte dépend de données différentes pour fonctionner efficacement. La technologie continuera d’évoluer, mais le principe reste le même. De meilleures décisions opérationnelles commencent par une télémétrie fiable, et une télémétrie fiable commence par comprendre l’état de l’appareil.

Si vous envisagez une surveillance automatisée de l’état de l’appareil pour votre flotte, contactez notre équipe pour discuter de votre cas d’usage et voir comment cette approche pourrait s’intégrer à vos flux de télématique.