Débit connecteur Nord OIBus

OIBus envoie des valeurs à un application cible via le connecteur Nord de type API REST (OIConnect, OIAnalytics…). Ce connecteur propose deux modes d’envoi : un mode File endpoint et un mode Values endpoint. Les débits à prendre en compte peuvent être estimés en fonction des données à envoyer et du mode d’envoi sélectionné. Ces estimations peuvent également être utilisées pour dimensionner le volume de stockage du cache nécessaire pour assurer le store and forward dans de bonnes conditions.

Envoi de valeurs avec File endpoint (CSV)

Nous allons nous intéresser aux données sous forme de fichiers CSV. Dans ce cas la volumétrie va dépendre de plusieurs paramètres :

  • La fréquence d’échantillonnage des données
  • La fréquence d’envoi du fichier
  • Le format du timestamp
  • Le format des données : nombre de caractères utilisés, donc la précision
  • La taille des références de données
  • Le format du fichier : en lignes ou en colonnes

Dans les exemples suivants, nous allons regarder combien d’espace occupe le fichier CSV généré par OIBus. Nous avons pris les hypothèses suivantes:

  • La fréquence d’échantillonnage : un point par minute.
  • La fréquence d’envoi du fichier : un fichier toutes les 30 minutes.
  • Le format du timestamp : format ISO 8601, d’une taille de 24 octets.
  • Le format des données : 3 chiffres avec un séparateur pour les décimales. Les donnée des exemples suivants ont donc une taille de 4 octets.
  • La taille des références de données : DataXXX, où XXX représente un nombre sur trois caractères. Les références des exemples suivants ont donc une taille de 7 octets.

Fichiers en Colonnes

Ce format est particulièrement adapté aux données répétées sur un même horodatage, ce qui économise de l’espace par rapport à un format « lignes ».

Horodatage Data001 Data002 Data003
2020-02-01T20:04:00.000Z 12,0 10,0 10,0
2020-02-01T20:05:00.000Z 10,0 19,0 10,0
2020-02-01T20:06:00.000Z 10,0 10,0 14,0

Le taille de l’en-tête est ici de 10 + 1 + 7 + 1 + 7 + 1 + 7 + 1 = 35 octets
La taille d’une ligne est ici de 24 + 1 + 4 + 1 + 4 + 1 + 4 + 1 = 40 octets
(les 1 correspondent aux caractères séparateurs de colonnes et aux retours à la ligne)

Le nombre de lignes dépend de la fréquence des données, ici une ligne toutes les minutes. Avec un envoi toutes les 30 minutes le fichier à envoyer aura donc une taille de 35 + 40 x 30 = 1 235 octets. Sur une journée, il y aura 48 fichiers soit un total de 59 280 octets soit 58 ko.

Fichiers en Lignes

Ce format est particulièrement adapté quand les différentes données transmises n’ont pas la même fréquence d’échantillonnage. Dans l’exemple nous supposons que toutes les données ont la même fréquence d’échantillonnage.

Horodatage Référence Valeur
2020-02-01T20:04:00.000Z Data001 12,0
2020-02-01T20:04:00.000Z Data002 10,0
2020-02-01T20:04:00.000Z Data003 10,0
2020-02-01T20:05:00.000Z Data001 10,0
2020-02-01T20:05:00.000Z Data002 19,0
2020-02-01T20:05:00.000Z Data003 10,0
2020-02-01T20:06:00.000Z Data001 10,0
2020-02-01T20:06:00.000Z Data002 10,0
2020-02-01T20:06:00.000Z Data003 14,0

Le taille de l’en-tête est ici de 10 + 1 + 9 + 1 + 6 + 1 = 28 octets
La taille d’une ligne est ici de 24 + 1 + 7 + 1 + 4 + 1 = 38 octets
(les 1 correspondent aux caractères séparateurs de colonnes et aux retours à la ligne)

Le nombre de lignes dépend de la fréquence des données et du nombre de références, ici une ligne toutes les minutes multipliée par 3 références. Soient 3 lignes par minute. Avec un envoi toutes les 30 minutes le fichier à envoyer aura donc une taille de 28 + 38 x 30 x 3 = 3 448 octets. Sur une journée, il y aura 48 fichiers soit un total de 165 504 octets soit 162 ko.

Fichiers en Lignes + Colonnes

Ce format a l’avantage du fichier colonnes et permet de mutualiser les identifiants de données (001, 002, 003) avec les références s’il y en a plusieurs, ce qui n’est pas le cas ici puisque seul Data est utilisé. Cela permet d’obtenir les références Data001, Data002, Data003.

Horodatage Référence 001 002 003
2020-02-01T20:04:00.000Z Data 12,0 10,0 10,0
2020-02-01T20:05:00.000Z Data 10,0 19,0 10,0
2020-02-01T20:06:00.000Z Data 10,0 10,0 14,0

Le taille de l’en-tête est ici de 10 + 1 + 9 + 1 + 3 + 1 + 3 + 1 + 3 + 1 = 33 octets
La taille d’une ligne est ici de 24 + 1 + 4 + 1 + 4 + 1 + 4 + 1 + 4 + 1 = 45 octets
(les 1 correspondent aux caractères séparateurs de colonnes et aux retours à la ligne)

Le nombre de lignes dépend de la fréquence des données et du nombre de références, ici une ligne toutes les minutes multipliée par une référence. Soit une lignes par minute. Avec un envoi toutes les 30 minutes le fichier à envoyer aura donc une taille de 33 + 45 x 30 = 1 383 octets. Sur une journée, il y aura 48 fichiers soit un total de 66 384 octets soit 65 ko.

Envoi de valeurs avec Values endpoint (JSON)

Lorsque des valeurs sont récupérées par le connecteur Nord puis envoyées par un Values endpoint, ces dernières sont formatées dans un tableau de cette manière :

[
{"timestamp": "2020-02-01T20:04:00.000Z","pointId": "Data001","data": {"value": "12.0","quality": "192"}},
{"timestamp": "2020-02-01T20:04:00.000Z","pointId": "Data002","data": {"value": "10.0","quality": "192"}},
{"timestamp": "2020-02-01T20:04:00.000Z","pointId": "Data003","data": {"value": "10.0","quality": "192"}},
]

  • timestamp : indique l’horodate de la valeur au format ISO 8601
  • pointId : référence de la valeur
  • Le champ data est un objet contenant la valeur relevée (value) et la qualité (quality)
  • .

Nous allons nous intéresser aux données sous cette forme de fichier JSON. Dans ce cas la volumétrie va dépendre de plusieurs paramètres :

  • La fréquence d’échantillonnage des données
  • La nombre de points regroupés par envoi (Défini par le paramètre Group Count)
  • La fréquence d’envoi (Définie par le paramètre Send Interval)
  • Le format des données et de la qualité: nombre de caractères utilisés, donc la précision
  • La taille des références de données

Il est alors possible d’estimer l’espace occupé par une valeur.

  • Le timestamp est représenté par "timestamp": "2020-02-01T20:00:00.000Z", soient 39 octets
  • Le pointId est représenté par "pointId": "DataXXX", soient 13 octets plus le nombre d’octets de la référence (ici les 7 octets de DataXXX)
  • Le champ data représenté par "data": {…} soient 10 octets plus son contenu
    • Le champ value représenté par "value": "10.0", soient 11 octets plus le nombre variable d’octets sur lesquels est codée la valeur (ici 4 octets)
    • Le champ quality représenté par "quality": "192", soient 13 octets plus le nombre variable d’octets sur lesquels est codée la qualité (ici 3 octets)

Le taille de l’objet représentant une valeur peut être décomposé en :

  • La taille fixe de l’objet = 39 + 13 + 10 + 11 + 13 + 6 = 92 octets (le 6 correspondant aux séparateurs des différents éléments)
  • La taille de la référence = 7 octets
  • La taille de la valeur = 4 octets
  • La taille de la qualité = 3 octets

On a donc 106 octets pour un valeur envoyée.

Si l’on repart sur une fréquence d’échantillonnage de 1 point par minutes, et 3 données et que Group Count vaut 1000 et Send Interval de 1000ms, alors OIBus transmettra un JSON toutes les minutes avec 3 données soit 318 octets. Sur une journée, cela représentera 318 x 24 x 60 = 457 920 octets, soit 447 ko.

Conclusion et Comparaison

Dans les conditions définies dans le cadre de l’exemple, il ressort que le mode de transmission et le format des données vont avoir un impact important sur les volumes transmis. Cela sera d’autant plus critique que le nombre de données et leur fréquence d’échantillonnage seront plus élevés que ce qui est décrit dans cet exemple.

CSV
Colonnes
CSV
Lignes
CSV
Lignes + colonnes
JSON
Volume quotidien 58 ko 162 ko 65 ko 447 ko
Volume par valeur 13,7 o 38,3 o 15,4 o 106 o