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 8601pointId
: 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 deDataXXX
) - 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 |