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