Tous droits réservés

La télé-information client envoie-t-elle les trames de manière régulière ?

Analyse de l'horodatage des trames

Dans le cadre d’un projet personnel, je m’intéresse à la télé-information client (TIC) de mon compteur électrique. Il s’agit d’une sortie du compteur fournissant des informations sur l’état du compteur. On peut y retrouver le numéro du compteur, la consommation totale, la puissance consommée à un instant donné, etc. La prise TIC se présente sous forme de deux terminaux accessibles facilement et elle envoie les données selon un protocole simple et bien documenté, à base de trames émises régulièrement par le compteur.1

Pour de nombreux traitements (filtrage notamment), il est bien plus simple de considérer que les trames sont parfaitement régulières. Cependant, ce n’est pas tout à fait le cas. Aussi pour ne pas fausser complètement les calculs, il faut répondre à la question suivante : à quel point les trames sont-elles régulières ?


  1. On retrouve toutes les informations utiles sur la documentation fournie par Enedis et son complément dédié aux compteurs Linky.

Horodatage des trames

Je dispose d’un compteur Linky, qui sait communiquer selon un protocole qui contient l’horodatage des trames (mode standard). Cependant, il n’est pas configuré dans ce mode-là, mais selon le mode dit historique dont les trames ne contiennent pas d’information d’horodatage. J’ai donc ajouté à mon enregistreur un système qui effectue l’horodatage lors de l’acquisition de la trame. 1

Les horodatages se présentent sous la forme d’un grand fichier texte où chaque ligne représente la date d’arrivée sous la forme d’un temps exprimé en millisecondes. En voici un extrait ci-dessous.

52562
54119
55675
57232
58790
60347
61907
63464
65020
66577

Il me faut maintenant analyser la régularité de ces réceptions de trames.


  1. Il suffit normalement de contacter son fournisseur d’énergie pour faire changer la configuration du compteur. Je ne l’ai pas fait, d’abord par paresse, mais aussi parce que cela me forcerait à réécrire une partie de l’enregistreur et que je préfère me concentrer sur l’aspect analyse de données pour le moment.

Analyse de la régularité des trames

L’analyse se fonde sur les écarts entre les trames successives : si ces écarts sont tous identiques, les trames sont parfaitement régulières. S’ils ne le sont pas, alors les trames seront irrégulières.

Évidemment, la réalité n’est pas aussi manichéenne, et il est possible d’observer la répartition des écarts entre trames.

Écarts entre trames.
Écarts entre trames.
import matplotlib.pyplot as plt
import numpy as np
import scipy.stats as ss

filename = "data/data_4/time.txt"
time_values = []
with open(filename, "r") as f:
    for l in f.readlines():
        time_values.append(int(l))

time_diff = np.diff(time_values)

stats = ss.describe(time_diff)
print(stats)

start = 1556.5 - 3
stop = 1559.5 + 3
bins = np.arange(start, stop, 1)
plt.hist(time_diff, bins=bins, density=True)
plt.ylabel("Fréquence")
plt.xlabel("Écart à la trame précédente (ms)")
plt.title("Régularité de l'arrivée des trames")
plt.show()

Les écarts sont donc bien concentrés autour de 1557 et 1 558 ms (plus de 80 % des échantillons). En rajoutant les quelques millisecondes de part et d’autre, on obtient la quasi-totalité des échantillons.

On peut également demander un peu d’infos supplémentaires sans trop se fatiguer :

Donnée Valeur Unité
Moyenne 1557.68 ms
Minimum 1553 ms
Maximum 2135 ms
Variance 24.26 ms2

On voit que le maximum est bien plus élevé que ce que montre l’histogramme. Il y a en fait un effet de longue traîne, comme le montre la figure ci-dessous, avec un petit nombre d’échantillons qui se répartissent sur une longue durée après le pic principal.

Longue traîne.
Longue traîne.

Cette longue traîne pourrait aussi affecter la variance, qui semble relativement élevée par rapport à la finesse du pic principal. Cependant, je n’ai pas effectué l’analyse en éliminant la longue traîne.


Il semblerait que l’envoi des trames soit très régulier en général, avec parfois de gros retards dans l’envoi ou la réception des trames.

Ces retards étant rares, je ne m’en inquiète pas, et les données justifient que prendre la moyenne comme période d’échantillonnage pour mes différents traitements est acceptable (au moins dans un premier temps). Cela tombe bien, parce que j’avais déjà fait cette hypothèse avant l’analyse détaillée des durées entre trames. :D

L’origine de ces retards reste cependant mystérieuse. Est-ce qu’il s’agirait de mon enregistreur ou du compteur ?

1 commentaire

Bonjour,

Je dirais que ces latences sont possiblement liées aux latences induites par la couche de communication réseau et/ou le microcontrôleur, qui n’utilise probablement pas un système multitâche très complexe.

Je te conseille l’analyse de CPC Hardware pour des détails techniques sur le fonctionnement de Linky : https://www.cpchardware.com/download/hw28_linky.pdf

On y lit notamment :

  • « Ce compteur Linky est constitué d’un microcontrôleur principal STM32F103RF de STMicroelectronics (caché par l’afficheur sur la photo). Il s’agit d’un SoC embarqué basé sur un cœur Cortex-M3 32-bits à 72 MHz qui embarque 768 Ko de mémoire flash et 96 Ko de SRAM. »
  • « le CPL G3 de Linky offre une "portée" de plusieurs kilomètres en utilisant une bande de fréquences de l’ordre de 35 à 90 KHz (en France grâce à la bande CENELEC-A dédiée à cet usage) et un codage OFDM (orthogonal frequency-division multiplexing) à correction d’erreurs multiples. Son débit effectif ne dépasse toutefois pas 1 Ko/s dans le meilleur des cas ! »
  • « On trouve ensuite une couche MAC puis 6LoWPAN (IPv6 over Low-power Wireless Personal Area Network) qui permet l’interface avec une couche réseau en IPv6 classique. À noter que la couche MAC utilisée dans le CPL G3 de Linky supporte un mode gestion dit "Full Mesh" qui permet d’opter pour le meilleur chemin afin que les données atteignent le concentrateur même en cas d’environnement très perturbé. Un compteur peut ainsi relayer le signal de son voisin pour lui permettre d’atteindre le concentrateur indirectement. Au-dessus de la couche réseau, au niveau "transport", c’est l’UDP (et pas le TCP) qui est utilisé. Enfin, la couche application devait initialement exploiter les protocoles SNMP (pour la surveillance d’état), TFPT (pour la mise à jour de firmware), mais elle se limitera au final à COSEM, un ensemble de spécifications normalisées dédiées à la mesure de l’énergie. »

Si la bande passante est très réduite, l’environnement est perturbable et en plus les porteuses sont potentiellement mutualisées, le système embarqué n’est peut-être pas temps réel et la pile réseau n’est pas minimale, ça peut faire cinq causes potentielles pour tes latences.

À noter que les Linky sont sourcés par plusieurs fabricants, il me semble.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte