Traduit de Anglais vers Français - www.onlinedoctranslator.

com

Validation des données IoT

Guide des meilleures pratiques

Visuels

les erreurs Ris

Outils

Processus Qualité

Analyse Valider

Mads Johansen, Spécialiste des données,

IoT, Innovation Données & Services, Technologie FORCE (majh@forcetechnology.com )

Anders Mynster, (jusqu'en août 2022) Chef de département,

IoT, Data & Services Innovation, FORCE Technology

Alexandre Alapetite, Architecte principal de solutions logicielles,

Laboratoire d'IA et d'analyse de données, Institut Alexandra (alexandre.alapetite@alexandra.dk )

Anders Depner, (Jusqu'en mai 2022) Spécialiste, IoT,

innovation données et services, FORCE Technology

1 / 38
Table des matières
1. Résumé ............................................... .................................. 3

2Introduction ................................................. ...................................................... 4

2.1 Processus de validation des données.................................................. .................................................................. ...................... 4

3 La nature de la validation des données .................................................. ...................... 5

3.1 Qui effectue la validation des données ?............................................ .................................................................. ....... 6

3.2 Charge de travail en amont et en aval ............................................ .................................................................. ...... 6
3.3 Capteurs et données les plus précieux.................................................. .................................................................. ............... 7
3.4 Expertise en la matière .................................................. .................................................................. ...................... 8
3.5 Manuel, semi-automatique et automatisé ............................................ .................................................................. .. 9
3.6 Plan d'expériences – exploration des résultats.................................................. ...................................... 9
3.7 Listes de sensibilisation pour l'inspection des données.................................................. .................................................................. ......... 11
3.8 Traitez les erreurs de données comme des amis et non comme des ennemis.................................. .................................................................. ......... 11

4 Processus de validation des données IoT ............................................ ...................... 12

4.1 Analyse du système IoT................................................ .................................................................. ................................ 12

4.2 Processus de validation .................................................. .................................................................. .................................. 14

5 Outils pour structurer la validation des données IoT.................................................. ..... 16

5.1 Canevas d'analyse du système ............................................... .................................................................. ...................... 16

5.2 Analyse des risques............................................................ .................................................................. ........................................ 18
5.3 Déclaration de qualité des données .............................................. .................................................................. ...................... 20
5.4 Suivi des anomalies.................................................. .................................................................. .................................. 21
5.5 Placer des activités dans une tournée ............................................ .................................................................. ................ 22

6 Outils pour le processus de validation.................................................. ............... 23

6.1 Pile d'outils logiciels................................................... .................................................................. ...................................... 23

6.2 Outils visuels............................................................ .................................................................. ....................................... 24
6.3 Outils experts du domaine .................................................. .................................................................. ........................ 30
6.4 Outils statistiques et algorithmiques.................................................. .................................................................. .............. 32
6.5 Étalonnages ...................................................... .................................................................. ....................................... 36

7. Conclusion ................................................ ...................................................... 38

2 / 38
1. Résumé
Le présent livre blanc décrit les meilleures pratiques en matière de validation des données. La validation des données fait référence au
processus visant à garantir l'exactitude et la qualité des données. Il est mis en œuvre en intégrant plusieurs contrôles dans un système ou un
rapport pour garantir la cohérence logique des données saisies et stockées.

L’importance de la validation des données ne peut être sous-estimée. Dans le rapport McKinsey, « The Internet-of-Things rattrapage une
opportunité accélérée », novembre 2021, il est indiqué :»Nous estimons que la valeur totale captée d’ici fin 2020 (1 600 milliards de dollars),
bien qu’elle soit considérable, se situe dans la partie inférieure de la fourchette des scénarios que nous avons élaborés en 2015. »Par
conséquent, si nous ne garantissons pas que les données sont valides pour prendre des décisions fondées sur les données, nous risquons
1 600 milliards de dollars en mauvaises décisions. Lorsque l’Agence danoise pour le gouvernement numérique a évalué à mi-chemin les projets
phares de l’IA pour relever le défi clé de la mise en œuvre de l’IA dans le domaine public, la réponse sur un portefeuille de 30 millions de dollars
a été : le manque de qualité des données.

Dans cet article, les meilleures pratiques de l'industrie sont présentées sur la manière de valider les données IoT. Les défis organisationnels
sont présentés dans la section « La nature de la validation des données ». Ensuite, comment un processus peut être mis en œuvre pour
améliorer le niveau de qualité des données grâce à la validation des données, puis les outils permettant de structurer et de prioriser le
processus de validation des données sont discutés, avant de présenter des outils pratiques qui peuvent être et sont en cours de mise en œuvre
dans les systèmes opérationnels.

Il est évident que la validation des données peut facilement devenir une tâche chronophage et il est donc important de réitérer que la
tâche la plus essentielle de la validation des données est de définir le moment où les données sont adaptées à leur objectif. La qualité
et l’exactitude des données sont-elles suffisantes pour être utilisées pour des décisions fondées sur les données ? Déterminer cela et
adopter une hiérarchisation très critique des activités dans le processus itératif peut améliorer considérablement la validité et la
qualité des données avec un minimum d'effort.

3 / 38
2 Introduction
Dans ce livre blanc, nous présenterons les meilleures pratiques, un processus et des outils pour la validation des données
IoT. Ces connaissances sont collectées et/ou développées par FORCE Technology en collaboration avec l'Alexandra Institute,
sous leCentre nordique de l'IoT .

Le processus de validation des données est principalement axé sur la validation des données des systèmes IoT, mais le processus de validation
des données sera naturellement également applicable à d'autres types de données, car les systèmes IoT traitent rarement uniquement les
« données IoT », ce que la plupart voient comme mesures de séries chronologiques. La validation des données est un processus itératif qui vise
à garantir un niveau approprié de qualité des données pour un système ou une application.

L’importance de la validation des données ne peut être sous-estimée. Dans le rapport McKinsey « The Internet-of-Things rattrapage une
opportunité accélérée », novembre 2021, il est indiqué : « Nousestimez que la valeur totale capturée d’ici la fin de 2020 (1 600 milliards de
dollars), bien qu’elle soit considérable, se situe dans l’extrémité inférieure de la fourchette des scénarios que nous avons élaborés en 2015. »
Par conséquent, si nous ne garantissons pas que les données sont valides pour prendre des décisions fondées sur les données, nous risquons
1 600 milliards de dollars en mauvaises décisions. Lorsque l’Agence danoise pour le gouvernement numérique a évalué à mi-chemin les projets
phares de l’IA pour relever le défi clé de la mise en œuvre de l’IA dans le domaine public, la réponse sur un portefeuille de 30 millions de dollars
a été : le manque de qualité des données.

Dans le paysage de la gestion et de la gouvernance des données, de nombreux aspects sont inclus, parmi lesquels la qualité des données. Les entreprises
ont souvent tendance à investir dans des logiciels de gestion de données, pour finalement constater que la qualité des données n'est pas au niveau requis
pour qu'elles soient adaptées à leur objectif. En d’autres termes, la qualité des données utilisées n’est pas suffisamment élevée pour répondre au besoin
ou à la tâche pour laquelle elles sont utilisées.

La validation des données est l'acte de mettre en œuvre de bonnes pratiques pour garantir que la qualité des données est conforme
au besoin visé. FORCE Technology et Alexandra Institute ont développé un processus et un ensemble d'outils qui permettent à une
organisation d'effectuer la validation des données pour garantir que la qualité des données requise est atteinte.

Nous tenons à remercier Maersk, Novo Nordisk, NNE, l'Université d'Aarhus, Vitani Energy Systems et tous les autres
qui ont contribué à mieux comprendre leurs recommandations de bonnes pratiques.

2.1 Processus de validation des données

Notre processus de validation des données s'inspire duCycle de vie du processus de validation des donnéestiré de l'article «
Méthodologie pour la validation des données 1.0 » [Marco Di Zio et al., 2016]. Cela passe par un processus itératif, qui commence par
la conception d'une suite de validation (un plan d'action, qui comprend une série de tâches et d'outils, à appliquer aux données afin
d'améliorer la qualité de l'ensemble de données). La suite de validation est mise en œuvre en l'appliquant à des exemples de données
et en affinant les tâches et les outils, avant d'exécuter la suite de validation sur les données réelles. Les résultats de l'application de la
suite de validation sur les données réelles sont évalués, et l'évaluation, qui est comparée aux éventuels commentaires des parties
prenantes, sera utilisée pour la prochaine itération qui démarre par la conception d'une nouvelle suite de validation.

Sur cette base, FORCE Technology a développé un processus en sept étapes. Ce processus en sept étapes est une série
d'étapes et d'actions spécifiques à suivre pour effectuer une validation des données réussie. Les étapes un à trois servent à
un examen approfondi du système, tandis que les étapes quatre à sept constituent la partie itérative de la validation des
données.

Les sept étapes, comme le montre la figure 1, ont été divisées en deux sections principales : « l'analyse du système
IoT » et le « processus de validation ». Le chapitre suivant entrera plus en détail à chaque étape.

4 / 38
 Figure 1 : Processus de validation des données IoT de la technologie FORCE

3 La nature de la validation des données

« Certaines données valent mieux que pas de données », est une affirmation souvent entendue lors de la mise en œuvre de solutions
IoT et du début de la collecte de données sur un problème donné. Cependant, la phrase doit être complétée par"… si les données
fournissent un aperçu fiable du défi que le système tente de résoudre ».

Le tableau 1 montre un exemple d'ensemble de données, fourni gratuitement :

Horodatage T_1 T_2

0100002022 50 45

0104042022 24 34

0104042022 24 34

0105052022 26 32

0200242022 30 30

Tableau 1 : Exemple d'un ensemble de données.

Vous disposez désormais de « quelques données », mais est-ce mieux qu’avant ? Probablement pas. Sans des descriptions
appropriées de l’origine des données et du degré de fiabilité des données, leur valeur est très faible. Pourquoi les horodatages sont-
ils irréguliers, et à quel fuseau horaire se réfèrent-ils, d'où proviennent les données de T_1 et T_2 et qu'indiquent-elles ? L’exemple
peut paraître tiré par les cheveux mais il est malheureusement très courant. Pour garantir que les données sont précieuses, nous
devons les valider, pours'assurer que les données sont adaptées à l'usage prévu, c'est-à-dire qu'il fournit des informations fiables
sur le défi que le système tente de résoudre.

Comme décrit dans « Data Management Body of Knowledge » [Deborah Henderson et al., 2017]. Il est très courant de
mettre en œuvre des solutions IoT comme suit :

1. L'organisation achète ou développe un système capable de collecter et de stocker des données.

2. Une fois que l'organisation commence à utiliser le système, les données sont collectées, mais de plus en plus de problèmes liés à la qualité des
données surviennent.

5 / 38
 3. Une pratique disciplinée pour gérer la qualité des données et effectuer la validation des données est introduite.
4. L'organisation tire parti des avantages de données bien gérées.

En tant qu'experts en validation de données, il est tentant de penser que chaque solution doit commencer par une politique de
gouvernance des données, des procédures de validation des données et des outils pour l'automatiser. Cependant, la réalité est que
cela conduirait généralement à une utilisation excessive des ressources, drainant ainsi les ressources nécessaires au développement
du système lui-même. Par conséquent, il est nécessaire de trouver un bon équilibre entre la validation et la gestion des données en
fonction du ou des défis à résoudre. Par conséquent, la meilleure pratique en quatre étapes décrite ci-dessus constitue généralement
une très bonne approche pour construire le système et obtenir une qualité de données appropriée.

Dans ce livre blanc, nous avons rassemblé les informations de certaines des principales organisations de l'IoT et de la gestion
des données au Danemark, pour décrire leur approche de la validation des données et décrire leurs meilleures pratiques
dans ce domaine.

3.1 Qui effectue la validation des données ?

Très souvent, les personnes qui valident les données ne sont pas les mêmes que celles qui produisent les données. Parfois, ils font partie de la
même organisation, mais à mesure que les données circulent de plus en plus entre les organisations, les personnes qui valident les données
seront souvent également placées dans une organisation externe.

Il est essentiel que la validation ne soit pas considérée comme un obstacle, mais comme une aide à l'organisation ou à l'unité produisant les
données. En cas de validation des données trop rigide ou stricte, les données ne seront ni produites ni partagées. Par conséquent, les
personnes effectuant la validation des données et les processus qu’elles ont mis en œuvre doivent être accessibles et flexibles. Un guide
convivial pour obtenir une meilleure qualité de données.

3.2 Charge de travail en amont et en aval

La validation des données déplace la charge de travail entre les données en amont et les données en aval, c'est-à-dire entre ceux qui génèrent des données et ceux qui

les utilisent. À mesure que le nombre de consommateurs de données augmente, la charge de travail combinée augmente également avec un manque de qualité des

données. À mesure que le nombre de producteurs de données augmente, la charge de travail augmente avec davantage de validation des données. Par conséquent,

l’augmentation de la validation des données diminue la charge de travail des utilisateurs de données mais augmente pour les générateurs de données.

Charge de travail à mesure que la validation des données augmente

Nombre de générateurs de données - En amont

Nombre de consommateurs de données – En aval

Figure 2 : Répartition de la charge de travail en fonction du nombre de générateurs de données et de consommateurs de données.

6 / 38
Par conséquent, avant de décider de l’ampleur du travail à consacrer à la validation des données, il est conseillé de connaître le
nombre de générateurs et de consommateurs de données. S'il existe de nombreux générateurs, les exigences accrues en matière de
validation des données augmenteront considérablement la charge de travail, mais s'il n'y a que quelques utilisateurs, la charge de
travail combinée ne diminuera pas beaucoup, comme le montre la figure ci-dessous.

N'oubliez pas de considérer comment cette répartition changera dans un délai prévisible.

Charge de travail à mesure que la validation des données augmente

Nombre de générateurs de données - En amont

Nombre de consommateurs de données – En aval

Figure 3 : Répartition de la charge de travail en fonction du nombre de générateurs de données et de consommateurs de données.
Le nombre de producteurs augmente et les consommateurs diminuent.

3.3 Capteurs et données les plus précieux

De nombreux systèmes contiennent une grande quantité de données provenant de nombreuses sources de données et garantir une
qualité de données maximale dans toutes ces sources de données nécessite une charge de travail excessive. Par conséquent, les
sources de données et les capteurs MVP doivent être définis. Ce sont des capteurs essentiels pour remplir l’objectif du système. La
plupart des organisations les définissent lors d'une réunion avec les parties prenantes internes et externes les plus importantes, au
cours de laquelle la liste des capteurs MVP est établie. La liste est ensuite révisée chaque année. Les capteurs et sources de données
de la liste sont alors surveillés plus rigoureusement que le reste des capteurs.

Cela peut être fait par exemple en utilisant l'outil SHAP pour Python, qui peut évaluer l'influence des sources de données
individuelles sur la sortie. Il est principalement destiné à des fins d’apprentissage automatique, mais associé à une expertise
appropriée en la matière, il peut constituer un bon point de départ pour la liste des sources de données critiques.

7 / 38
Figure 4 : Exemple de classement des sources de données les plus impactantes lors de la prévision de la consommation énergétique des
une maison.

3.4 Expertise en la matière

Les experts en la matière sont des personnes qui possèdent une expertise dans le domaine sur lequel le système mesure – parfois
également appelés experts du domaine. Il peut s'agir d'opérateurs de machines, de techniciens de réparation, de médecins,
d'infirmières, etc. selon l'orientation du système. En règle générale, les grandes entreprises font appel à un expert en la matière pour
trois développeurs.

Si de nombreux experts en la matière sont disponibles, la quantité de données nécessaire pour résoudre le défi est moindre. Si peu
ou pas d’experts en la matière sont disponibles, la quantité de données augmente de façon exponentielle. Ceci est essentiel à
comprendre, car le fait de disposer de données pour des experts non spécialisés augmente également les exigences en matière de
qualité des données – car ils ont moins d'expérience dans l'identification des erreurs dans les données, et pour cette raison, les
descriptions (métadonnées) doivent être plus précises. détaillé pour éviter les malentendus.

Il convient de souligner que, si vous n’avez pas d’experts en la matière ou si vous n’avez que très peu accès à eux, les objectifs de validation des
données peuvent devenir purement académiques et les conclusions sur les données, même si elles sont validées, peuvent être très fausses. Un
exemple de ceci est celui d’une entreprise qui faisait appel à des data scientists pour effectuer une analyse de l’efficacité opérationnelle des
machines par rapport au temps consacré à la maintenance. Après avoir analysé les données, la conclusion était que l’entreprise ne devrait pas
du tout effectuer de maintenance ! Les experts en la matière ont semblé déconcertés par les données et ont rapidement découvert que la
raison de leur conclusion était que les données étaient constituées de machines nouvelles et anciennes. Les nouvelles n'avaient pas encore fait
l'objet d'entretien et étaient également les plus performantes – d'où une conclusion logique, mais sachant que les machines tombent en panne
si elles ne sont pas entretenues, l'entreprise n'a pas suivi les conseils.

8 / 38
 Figure 5 : Expertise en la matière par rapport aux données nécessaires pour obtenir des informations sur le système. Soyez conscient si vous le faites
Si nous ne disposons pas d’experts en la matière, des conclusions erronées peuvent être tirées en se contentant d’examiner les données.

3.5 Manuel, semi-automatique et automatisé

Il est très tentant de penser qu’il est nécessaire d’automatiser chaque processus de validation des données. Cependant,
l’automatisation n’est pas une tâche triviale et sa mise en œuvre prend du temps. Par conséquent, le guide des meilleures pratiques
est que certains problèmes sont mieux résolus au départ par des processus manuels – l’important est qu’ils soient effectués
régulièrement. Les questions clés à aborder sont les suivantes :

- Qui le fait?
- Qu'est-ce qui devrait être fait?
- À quelle fréquence?

Une fois le problème résolu 10 fois ou plus, les données sont suffisantes pour l’automatisation. De plus, il devient possible d'évaluer
la charge de travail mensuelle pour corriger manuellement cet élément et combien il faudra automatiser. Ici, la dimension de la
criticité temporelle peut également être évaluée : s'agit-il d'une erreur de données qui doit être corrigée en quelques jours ou
quelques secondes ?

Quelques exemples pourraient être :

- Validation des données des capteurs de pluie par comparaison aux données météorologiques de référence.
- État sécurisé automatisé du système lorsque les données sont détectées comme corrompues.
- Inspection visuelle des données sur une base hebdomadaire pour découvrir les erreurs de données inconnues.

3.6 Conception d'expériences – exploration des résultats

Lorsque l'on examine les données de la figure 6, il n'y a aucune structure apparente dans les données et leur validité semble donc
médiocre. Il est très difficile de voir s’il existe une tendance.

9 / 38
 Figure 6 : Données obtenues à partir d'un système en fonctionnement.

Cependant, en augmentant la portée des données, une tendance claire peut être observée dans la figure 7. Souvent, lorsque
les systèmes IoT mesurent des processus, ceux-ci ne vont pas aux extrêmes et, par conséquent, seule une petite partie des
résultats peut être vue. Il est essentiel de concevoir des expériences pour remplir l’espace des résultats, afin de déterminer
les relations entre les intrants et les extrants. Autrement, les relations entre les intrants et les extrants peuvent être difficiles
à déterminer. La complexité augmente à mesure que le nombre d’entrées et de sorties du système augmente.

Figure 7 : Données obtenues à partir d'une gamme de résultats plus large en faisant varier le processus, le carré rouge montre le
données de la figure précédente.

Un outil pratique pour la conception d’expériences estBrowniebee (développé par l'Alexandra Institute et certains
autres partenaires), qui peut aider à déterminer les paramètres d'entrée nécessaires pour explorer l'espace des
résultats.

10 / 38
3.7 Listes de sensibilisation pour l'inspection des données

En fonction de votre organisation et de votre application, différents types d'erreurs se produisent plus fréquemment que d'autres. Par
exemple, dans certains systèmes, les emplacements des appareils IoT sont définis manuellement dans une application, tandis que dans
d'autres, ils sont automatiquement envoyés depuis un GPS. Dans le premier cas, les erreurs de saisie humaine doivent être surveillées. Dans le
second cas, les erreurs de correction GPS sont plus courantes. Le processus de correction des erreurs devrait donc être différent.

Par conséquent, il est recommandé de partager des listes d’erreurs typiques observées dans une application particulière. Comme source d'inspiration
pour les listes de sensibilisation, les listes sont recommandées comme source d'inspiration de «Mauvais guide de données » qui contient les erreurs
typiques observées dans les ensembles de données. Comme guide d'inspection de la qualité, « TimeCleanser : une approche d'analyse visuelle pour le
nettoyage des données orientées temps » est recommandé.

Figure 8 : Gauche : erreurs typiques trouvées dans les données du guide de données incorrectes. À droite : liste des meilleures pratiques en matière d’inspection des données.

3.8 Traitez les erreurs de données comme des amis et non comme des ennemis

Dans de nombreux cas, les erreurs de données dans le système contiennent des informations précieuses. Les erreurs dans les
données révèlent souvent des erreurs dans le processus de conception, les connaissances trouvées dans l'organisation, les processus
utilisés en relation avec les données ou de nombreux autres aspects de l'organisation et du fonctionnement. Il est donc important

11 / 38
non seulement pour éliminer les erreurs trouvées dans le processus de validation des données, mais également pour considérer et analyser la manière dont elles

peuvent être utilisées à des fins d'amélioration.

L’exemple le plus notable est celui des filtres anti-spam dans les e-mails. Si les e-mails étaient filtrés par des algorithmes et signalés par les
utilisateurs, les ressources nécessaires pour créer de nouvelles règles de filtrage du spam seraient bien plus importantes qu'aujourd'hui. Donc,
avant de jeter les erreurs dans vos données, pensez à placer les données dans une base de données distincte.

4 Processus de validation des données IoT

Le processus de validation des données IoT est une combinaison du processus de validation des données plus général décrit dans le
Cycle de vie du processus de validation des donnéesde l'article « Méthodologie pour la validation des données 1.0 » [Marco Di Zio et
al., 2016] et les meilleures pratiques pratiques que nous avons apprises de nos discussions avec d'autres praticiens. Il est représenté
sur la figure 9 comme étant composé de sept étapes. Dans la section suivante, les différentes étapes du processus sont décrites.

Figure 9 : Processus de validation des données IoT.

4.1 Analyse du système IoT

L'analyse du système IoT est la première partie du processus de validation des données et comprend trois étapes. Le but de ces
étapes est d'analyser le système dans son intégralité, d'avoir un aperçu des sous-systèmes et de l'architecture des données en
étudiant comment chaque partie peut affecter la qualité des données.

4.1.1 Analyse du système IoT

Lors de l'analyse du système IoT, l'ensemble du système doit être décomposé et expliqué en détail. Il s’agit de
garantir que toutes les parties internes et externes ont une compréhension approfondie du système.

But
Le but du système IoT est décrit, c'est-à-dire pourquoi les données sont collectées et à quoi elles vont être
utilisées, ainsi que le but de la validation des données, c'est-à-dire quelle est la raison de la validation des
données.

Architecture du système
Dans le cadre de l'analyse du système, les entités physiques du système doivent être décrites en détail. Quelles entités

12 / 38
le système est constitué et comment ils sont interconnectés. Des descriptions détaillées dans cette section permettront à
toute l'équipe de comprendre le système, ce qui facilitera grandement le processus de validation et la communication
générale.

Analyse des parties prenantes

Tout système aura une liste de parties prenantes qui doivent être spécifiées. Les parties prenantes d'un système vont
de l'initiateur et du propriétaire du projet aux fournisseurs de matériel et de logiciels. Il est essentiel de consacrer du
temps à déterminer qui serait affecté par le système ou aurait un impact sur ce système. Certains détails peuvent
avoir été négligés, ce qui entraînera finalement une réduction des performances et de la qualité des données.

Exigences affectant la qualité des données

L'analyse des exigences applicables à la qualité des données doit être traitée à un niveau spécifique au sous-système et à un
niveau élevé, depuis les réglementations réglementaires qui s'appliquent au système, ou à l'utilisation du système, en
passant par les exigences relatives à la sensibilité des capteurs. L'analyse de toutes les exigences aidera à comprendre la
qualité des données pouvant être obtenues.

4.1.2 Analyse de l'architecture des données

L’étape suivante est l’analyse de l’architecture des données, qui est en partie une analyse et en partie un processus
décisif.

Flux de données

Il est conseillé de commencer l'analyse de l'architecture des données en créant un modèle qui spécifie le chemin des données
provenant des phénomènes surveillés. En d'autres termes, ce que les données montreront à l'utilisateur final des données, quelles
installations de stockage les données passeront-elles, si d'autres données sont ajoutées à partir de sources externes, comment les
données sont accessibles partout et tout autre détail qui en fait partie. du flux.

Métadonnées
Les métadonnées (données sur les données) sont un aspect important qui doit être décidé. Les décisions devraient commencer par
analyser quelles métadonnées sont disponibles et éventuellement déjà incluses, et devraient se terminer par un ensemble de lignes
directrices décrivant quelles métadonnées sont nécessaires dans l'ensemble de données pour que les données répondent aux
attentes de la déclaration de qualité des données, qui est décrite plus loin. vers le bas.

Mise en page
En sachant quelles métadonnées inclure, la structure des données peut être décidée. Cette décision fera
partie de l'examen initial, qui déterminera si la structure réelle des données suit les lignes directrices
décidées.

L'acquisition des données

La dernière partie à considérer est la manière dont les données seront transférées aux consultants externes pour le processus de validation des données.

4.1.3 Examen initial

Lors de la revue initiale, un premier regard est porté sur les données à valider, et cela se fait à travers quelques tâches.

L'évaluation des risques

Une évaluation des risques est un outil couramment utilisé dans la plupart des projets. L'évaluation des risques répertoriera tout ce qui
pourrait potentiellement nuire à la qualité des données, en classant différents aspects du risque et, ce faisant, en classant les risques en
fonction de la mesure dans laquelle ils doivent être pris en compte et éventuellement atténués.

« Déclaration sur la qualité des données »

Lorsque le système a été analysé sur une base d'acquisition de données, de sous-systèmes et de haut niveau, avant le début
de la validation, la qualité des données doit être déclarée, en fonction de l'état de la qualité des données, avant toute
validation. D’où la nécessité d’une compréhension approfondie du système.

Si la qualité des données du système actuel est inconnue ou ne peut être déclarée pour une autre raison, une intuition
suffira. Il est essentiel d'indiquer la qualité des données nécessaire pour remplir l'objectif du système. Ce sera le

13 / 38
base de la suite de validation, car il doit y avoir un marqueur pour mesurer la qualité. Autrement, on ne peut
pas savoir où en est le processus de validation.

Ingestion de données (validation de schéma)

La première validation initiale consiste à ingérer les données et ainsi à effectuer une validation de schéma. Le but de la validation du schéma
est de vérifier si les données sont structurées de manière uniforme et que l'ensemble de données est complet, conformément à la définition
du schéma décidée. Lorsque vous travaillez avec des données IoT, les ensembles de données peuvent être si volumineux qu'il est difficile de les
réaliser manuellement. Pour cette raison, l'analyse formelle, la validation et l'ingestion dans une base de données seront utiles, car le
processus d'ingestion peut indiquer si toutes les données sont conformes à la définition.

Visualisation
Une fois les données ingérées dans une base de données appropriée et la validation initiale de la structure effectuée, les
données peuvent être visualisées, ce qui ajoutera une deuxième couche à la validation initiale. La visualisation des données
permet une détermination rapide des problèmes et mènera au processus de validation.

4.2 Processus de validation

Le processus de validation lui-même constitue la deuxième partie du processus de validation des données et comprend quatre
étapes. Le but de cette partie du processus est de faire la validation proprement dite après avoir analysé le système dans la première
partie.

4.2.1 Conception

La première étape consiste à concevoir la suite de validation, ce qui signifie essentiellement déterminer les activités à
effectuer. Une fois le système analysé et les données ingérées dans la base de données, le processus de validation – pour
améliorer la qualité des données – est lancé. Ce processus comprend quatre étapes, un peu comme le « Cycle de vie du
processus de validation des données » mentionné ci-dessus.

Aperçu graphique
Comme décrit ci-dessus, la première étape consiste à obtenir un aperçu des données, afin de détecter les éventuels problèmes
nécessitant une correction. Ainsi, un aperçu graphique aidera à déterminer les fonctionnalités typiques associées à un système IoT :

- Taille du paquet en fonction du temps

- Nombre total de colis

- Nombre d'appareils
- Volume total de données circulant dans le système

Mais plus important encore, la visualisation des données permettra de déterminer facilement les erreurs typiques :

- Données manquantes
- Discontinuités
- Bruit
- Valeurs aberrantes, telles que de grandes valeurs

La recherche d'erreurs est une première étape dans la conception d'une suite de validation.

Conception d'une suite de validation

La conception de la suite de validation consiste essentiellement à planifier les activités nécessaires, nécessaires pour «
nettoyer » les données en analysant les erreurs et en déterminant comment les atténuer et hiérarchiser l'ordre des activités.

La suite comprend ainsi des activités à réaliser, des processus à suivre et des algorithmes/logiciels à utiliser.

Lors de la conception de la suite de validation, il convient de considérer que le processus de validation est un processus itératif et que
les activités décidées seront réexaminées, et qu'il n'est donc pas nécessairement important de corriger toutes les erreurs dès la
première exécution.

14 / 38
Une conception de suite de validation pourrait inclure :

- Revue de l'objectif du système IoT. A-t-il besoin d'une mise à jour ?

- Revue de la finalité de validation des données. Faut-il le redéfinir ?
- Considérations pour les dimensions de la Déclaration de Qualité des Données, avec des activités spécifiques à
réaliser pour améliorer la qualité de chaque dimension afin de répondre aux exigences.
- Considérations relatives aux risques répertoriés dans l'analyse des risques et activités à réaliser pour atténuer les risques.

- Une liste d'anomalies issue de la visualisation et de l'aperçu graphique, qui sera étiquetée avec les dimensions
affectées, et une activité pour corriger ou atténuer l'anomalie.

Lorsque la suite de conception est finalisée, les activités doivent être hiérarchisées, en tenant compte de l'objectif de
validation et de l'objectif du système IoT. De plus, l’importance d’une activité et les ressources nécessaires doivent
être prises en compte lors de la priorisation des activités.

Détermination des règles de validation

Les règles de validation doivent être déterminées en comparant le plan d'activité et la « Déclaration de qualité des données ». Les
règles de validation sont un ensemble d'exigences ou de lignes directrices que les données doivent respecter pour être à la hauteur
de la qualité souhaitée, indiquée dans la déclaration de qualité des données. Ces règles de validation seront utilisées dans la phase
d'exécution et de révision, comme base de référence pour analyser la qualité des données traitées avec la suite de validation.

4.2.2 Mise en œuvre

Implémentation de la suite de validation
La mise en œuvre de la suite de validation, à ne pas confondre avec son exécution, est la phase au cours de laquelle la suite de
validation et les règles sont affinées, et la suite de validation est testée sur des exemples de données pour voir comment les données
seront affectées afin de s'assurer que la suite de validation fonctionne comme prévu.

Affinement de la syntaxe de la suite de validation

Lors de la conception de la suite de validation, de nombreux outils différents sont utilisés et de nombreuses notes sont prises, ce qui
peut ne pas être suffisamment structuré. La première tâche de la mise en œuvre est ainsi de structurer la suite de validation et les
règles de validation dans une syntaxe commune, la rendant compréhensible pour tous les membres de l'équipe ainsi que pour les
parties prenantes.

Test sur des exemples de données

Avant d'appliquer la suite sur les données réelles, la suite de validation est appliquée sur certains exemples de données, qui
ressemblent aux données réelles, pour s'assurer que la suite de validation gère les données comme prévu et garantir que les
données ne seront pas corrompues.

4.2.3 Exécution
La suite de validation est appliquée aux données
Lorsqu'il a été testé et approuvé que la suite de validation n'aura pas d'impact négatif sur les données, lors de la phase de
mise en œuvre, la suite de validation est appliquée aux données réelles.

Détection d'une anomalie

Après avoir appliqué la suite de validation des données aux données, qui doit prendre en compte les données manquantes, les valeurs
aberrantes et autres anomalies, les données doivent être visualisées et analysées à nouveau, pour voir quel effet la suite de validation a eu sur
les données réelles.

Est-ce que quelque chose ne semble pas

bien ? Les anomalies typiques seront :

- Valeurs aberrantes

- Contextuel (la valeur correspond-elle au contexte)

- Lacunes

Mais tout ce qui pourrait sembler anormal doit être noté et inclus dans le résumé.

15 / 38
Résumé des données validées
La dernière partie de l'exécution consiste à signaler quelles activités ont été effectuées, quels effets elles ont eu sur les données
réelles et ce qui n'aurait peut-être pas été abordé. Tout comme pour le raffinement de la syntaxe de la suite de validation, le résumé
doit être réalisé avec une syntaxe commune que tous peuvent comprendre.

4.2.4 Révision
Évaluer le résumé de la phase d’exécution et les commentaires des parties prenantes
Après avoir suivi les étapes quatre à six, la suite de validation a été conçue et appliquée aux données
réelles, et le résultat a été résumé. Cette synthèse est discutée et évaluée.

Les parties prenantes doivent fournir des commentaires pendant la phase d’évaluation. La comparaison du résumé de mise
en œuvre et des commentaires des parties prenantes aidera à comprendre quel est l'état des données, compte tenu des
règles de validation, qui ont été formulées sur la base de la déclaration de qualité des données.

Identifier et prioriser les problèmes

L'évaluation servira de base à une réflexion sur la question de savoir si la suite de validation doit être repensée, si elle ne
nécessite que des ajustements mineurs ou si elle a validé avec succès les données et constitue donc une solution robuste.
Tout comme lors de la phase de conception, les problèmes qui pourraient persister doivent être identifiés et un autre plan
d'activité peut être complété. Ce plan d'activité, ainsi que l'évaluation, sont réintégrés dans l'itération, à partir de la
quatrième étape, avec la conception de la suite de validation.

5 outils pour structurer la validation des données IoT

Pour guider le processus d'analyse du système IoT et de validation des données, FORCE Technology a conçu des outils
qui, une fois utilisés, garantiront une analyse approfondie.

5.1 Canevas d'analyse du système

L'outil canevas présenté dans la figure 10 est le premier outil à utiliser, qui guidera l'analyse des deux premières étapes : « Analyse du
système IoT » et « Analyse de l'architecture des données ».

Il a été divisé en trois sections principales, chacune comportant trois sous-sections, qui comprennent toutes des questions
qui aideront à analyser le système. La tâche consiste à remplir chacune des sous-sections, car elles détaillent différents
aspects du système dans son ensemble. Il convient de garder à l’esprit qu’il n’est pas strictement nécessaire de s’en tenir aux
questions présentées dans le canevas, car celles-ci ne sont qu’un guide et une source d’inspiration.

16 / 38
 Figure 10 : Outil de canevas technologique FORCE.

5.1.1 Objectif
La première section détaille pourquoi les données sont collectées et pourquoi elles doivent être validées. De plus,
dans le cadre de la « finalité du système IoT », il est nécessaire d'analyser les parties prenantes du système, puisque
certaines d'entre elles doivent être consultées pendant le processus de validation dans la phase d'examen. Enfin, il
convient de noter si le système ou les données seront affectés par des facteurs réglementaires ou d'assurance qualité
(AQ) internes ou externes.
5.1.2 Système
La deuxième section est l'analyse de l'architecture du système, qui contient une analyse du système et deux tâches de considération
spécifiques à effectuer. L'architecture du système sera réalisée en remplissant les blocs de la figure 11. Bien qu'elle ne s'applique pas
à tous les systèmes IoT, de nombreux systèmes peuvent généralement être divisés en ces blocs.

Figure 11 : Architecture du système IoT généralisé.

17 / 38
La tâche de l'analyse consiste à indiquer quel matériel/logiciel est utilisé dans chaque bloc. Cela mènera à terme à une
carte complète du système IoT.

Une fois l'analyse de l'architecture du système finalisée, une analyse et une cartographie approfondies des phénomènes
mesurés par les capteurs, ainsi que des capteurs eux-mêmes, sont effectuées. Cette analyse fait partie de la formulation des
exigences relatives aux données.

5.1.3 Analyse de l'architecture des données

La dernière section du canevas concerne l’architecture des données.

Métadonnées
Pour garantir la cohérence des données, les métadonnées des ensembles de données sont analysées pour déterminer
quelles métadonnées sont incluses dans les données non validées, et des décisions sont ensuite prises quant aux
métadonnées à inclure. Avoir une définition claire des métadonnées à inclure facilitera le processus de définition de schéma
et donc de validation de schéma, qui est décrit dans les chapitres suivants.

Définition du schéma
Un schéma est une définition de la structure d'un ensemble de données. C'est la définition formelle du formatage, de la division des
données, et pour certaines bases de données, de la relation entre différents champs et tables.

Dans notre cas, le formatage fait référence à la structure des ensembles de données, par exemple les unités à utiliser, le nombre de
décimales pour les nombres, la profondeur de bits des données, etc. Si le schéma est mal défini pour les données et les
métadonnées, ou si les ensembles de données ne respectent pas la définition, cela affectera la qualité des données. Une définition
approfondie du schéma est donc importante.

La tâche de définition du schéma est une tâche de décision, dans laquelle le formatage et le schéma exacts doivent
être décidés.

Flux de données

La dernière sous-section est la description du flux de données. Cela peut être réalisé sous forme graphique ou explicative et doit décrire la manière dont
les données sont traitées dans l'ensemble du système, depuis les phénomènes mesurés jusqu'à l'utilisateur final.

- Quelles données sont collectées via les capteurs et comment les données sont-elles transmises au backend ?
- Quelles données sont appliquées aux métadonnées avant qu'elles n'atteignent le backend ?
- Quelles métadonnées sont appliquées lorsqu'elles atteignent le backend ?
- Comment les données sont-elles stockées tout au long du flux de données ?

- Quelles données externes sont ajoutées à la base de données, et comment sont-elles liées aux phénomènes mesurés ?

Le flux de données doit être décrit de manière approfondie, car cela, tout comme l'analyse de l'architecture du système, éclairera
toute l'équipe et facilitera grandement le processus de validation.

5.1.4 Remarques sur l'analyse du système

Ce que fait l’analyse du système, c’est poser les questions « pourquoi avons-nous besoin de cette validation ? » et « à quoi
servent les données ? », qui aideront à déterminer quand la qualité des données est adaptée à l'objectif.

Ensuite, la question se pose : « qu’est-ce qui est physiquement possible de mesurer ? » et « à quel type de mesures
faut-il s'attendre ? », en tenant compte des éventuelles restrictions et exigences physiques, qui détermineront la
qualité possible des données brutes.

5.2 Analyse des risques

Après avoir effectué le canevas d'analyse du système IoT, l'analyse des risques est un outil de gestion de projet courant, dans
lequel tous les risques connus pour le projet sont décrits, avec leur gravité respective et la manière dont ils doivent être
gérés.

18 / 38
L'outil d'analyse des risques développé par FORCE Technology, présenté ci-dessous, présente un tableau qui montre la corrélation
croisée entre la probabilité d'un risque et la gravité des dommages causés au projet. Il est important de se rappeler que cette analyse
des risques doit être effectuée en gardant à l’esprit la validation des données. Autrement dit, quelle est la probabilité qu'une
défaillance particulière se produise dans le système et quelles sont les conséquences commerciales et stratégiques si cela se produit.
Dans l'outil, les risques sont marqués par :

- Taper
- Description
- La gravité du projet, si le risque devait survenir
- La probabilité que le risque se réalise
- Qui est responsable de la gestion du risque ?
- Quelle action est recommandée ?

Les couleurs des corrélations peuvent être reconsidérées, c'est-à-dire qu'un risque de gravité moyenne/probabilité très faible
pourrait être jaune au lieu de vert, mais il est recommandé d'utiliser ce qui suit :

- Rouge: Un risque inacceptable, qu’il faut éliminer

- Jaune: Un risque acceptable s’il est atténué (réduit)
- Vert: Un risque acceptable, connu mais qui ne nécessite pas de prise en compte

Figure 12 : Exemple de tableau d’analyse des risques pour la validation des données.

Il est en outre recommandé soit de réaliser deux analyses de risques, soit de créer un système au sein de la même analyse de risques
pouvant gérer deux types de risques.

1. Risques affectant le projet ou l'entreprise si la qualité des données est faible

2. Risques pouvant affecter la qualité des données

Par exemple : les risques qui affectent le projet pourraient être marqués comme des risques « Axe », et les risques pour la qualité des données pourraient être

marqués comme des risques « Boîte ».

Risque Description Gravité Probabilité Impact du risque Responsable Action

Mauvais données
Effectuer des données
serait signifier Risque moyen Projet
A1 Très sérieux Faible validation
personnes obtenir (ROUGE) propriétaire
Processus
inondé

Revérifier
Emplacement du capteur- Quelques Risque Matériel intégré
B1 Moyen Faible placement de
la situation est mauvaise (Jaune) installateur
tous les capteurs

Tableau 2 : Exemple d’analyse des risques de validation des données.

19 / 38
5.3 Déclaration de qualité des données
Sur la base de l'adéquation des données (si les données sont adaptées à l'objectif), décrite lors de l'analyse du système, la
qualité des données doit être déclarée.

Premièrement, la qualité des données doit être déclarée en fonction de la qualité des données fournies par le système au moment de
l'analyse du système. Deuxièmement, la qualité souhaitée des données doit être déclarée.

La déclaration de qualité des données est divisée en quatre dimensions :

- exhaustivité
- Exactitude
- Actualité
- Réutilisabilité

La déclaration de qualité des données utilisée est à l'origine basée sur les onze dimensions de la qualité, mentionnées dans
le matériel d'apprentissage du « Data Management Body of Knowledge » [Deborah Henderson et al., 2017].

Exactitude, exhaustivité, cohérence, actualité, intégrité des données, précision, confidentialité, caractère raisonnable,
actualité, unicité, validité et accessibilité. Ces onze dimensions sont regroupées en quatre dimensions1, qui sont utilisés pour
notre déclaration de qualité des données. Le tableau 3 montre ce que chaque dimension prend en compte.

exhaustivité Indique dans quelle mesure l'ensemble de données comprend les éléments de données attendus, en ce qui
concerne les spécifications des données, et présente deux aspects :
Intégralitéest l'exhaustivité quant à savoir si l'ensemble de données comprend les entités attendues (que
toutes les entités – qu'elles soient concrètes ou abstraites – sontinscrit)
Couvertureest exhaustif quant à savoir si l'ensemble de données comprend les informations attendues
sur les entités enregistréespropriétés (dans une base de données relationnelle dont les attributs
nécessaires ont des valeurs)

Exactitude Indique dans quelle mesure les valeurs des données sont conformes aux valeurs réelles, sous deux
aspects :
Sémantiquel'exactitude est s'il y a conformité entre les valeurs enregistrées et les
valeurs physiques réelles
Syntaxel'exactitude est si les règles de syntaxe sont respectées, c'est-à-dire les règles
d'orthographe et de structure

Actualité Indique dans quelle mesure les données sont représentatives en temps opportun par rapport à la réalité qu'elles
représentent (les données sont-ellesdépassé)

(Par exemple, si des données en temps réel sont nécessaires, un délai de 10 minutes pourrait ne pas être acceptable, mais
pour modéliser et surveiller le mouvement de la glace, des données datant de 6 mois suffiraient)

Réutilisabilité Indique dans quelle mesure les données sont compréhensibles et peuvent être utilisées par d'autres, et
présente deux aspects :
Compréhensionest de savoir si les données sont représentées d'une manière facilement lisible pour les
utilisateurs (uniforme, lisibilité, documentée parmétadonnées)
Cohérenceest de savoir si les données présentent des contradictions et sont cohérentes avec d'autres données
(indubitable, cohérence entre les données de l'ensemble de données, cohérence avec la spécification)

Tableau 3 : Les quatre dimensions de la qualité.

1cf. « Fælles sprog for datakvalitet » [Digitaliseringsstyrelsen, 2019, en danois]

20 / 38
Chaque dimension doit être marquée d'un classement de zéro à cinq, exprimant si les données sont utiles ou non, en
utilisant le classement suivant :

Impropre à l'usage prévu

Peu utilisable pour l'usage prévu

Utilisable, mais avec de nombreuses erreurs/résultats involontaires

Utilisable, mais avec des erreurs/résultats involontaires

Utilisable, mais avec un petit nombre d'erreurs/résultats involontaires

Peut être utilisé sans autre considération

Comme indiqué ci-dessus, il est important de remplir deux déclarations, car la première clarifiera le statut du système actuel et la
seconde décrira la qualité des données souhaitée, pour que les données soient adaptées à leur objectif.

La différence entre les deux déclarations facilitera la phase de conception du processus de validation, car elle peut révéler
certaines erreurs connues nécessitant des actions correctives, et fournira en outre une orientation pour la conception de la
suite et des règles de validation.

5.4 Suivi des anomalies

Dans la plupart des systèmes IoT observés, même dans les grandes organisations, il existe de nombreuses erreurs dans les données une fois
que l'on commence à les rechercher. La première chose est d’identifier les erreurs et ensuite de faire quelque chose pour y remédier. Si vous
commencez à travailler avec la première erreur que vous rencontrez, vous ne trouverez probablement pas les plus critiques. Par conséquent,
c'est une bonne pratique de conserver une feuille de suivi des anomalies lors de la validation des données. Cela peut être basé sur n'importe
quel format que vous souhaitez, mais chez FORCE Technology, nous travaillons avec deux formats différents : les diapositives et les tableaux.
Les diapositives fonctionnent comme un outil pour documenter ce qui a été trouvé. Généralement, avec une simple capture d'écran de l'erreur
et des identifiants pour pouvoir la retrouver et déterminer rapidement quel était le problème.

Suite à cela, les anomalies peuvent être priorisées et traitées en fonction de leur classement et des ressources
disponibles.

21 / 38
 Figure 13 : Exemple de slide pour suivre les anomalies.

5.5 Mettre des activités dans une tournée

Comme mentionné précédemment, la validation des données est un processus itératif. Le défi lorsque l’on démarre la
validation des données est que, généralement, vous constatez qu’il n’y a pas un, mais plusieurs problèmes à résoudre. Il est
donc essentiel de prioriser les activités pour garantir le progrès et de consacrer les ressources uniquement aux défis les plus
essentiels.

C'est un outil simple mais efficace sous forme de tableau avec les colonnes :

- ID : Identifiant pour suivre l'activité

- Description : Une brève description de l'activité
- Responsable de l'activité : Qui est le responsable de l'activité
- Priorité métier : Importance du résultat par rapport aux besoins métier notée de un à cinq
- Durée estimée : les jours, semaines et mois calendaires nécessaires à la réalisation de l'activité.
- Coût estimé à corriger : coût des heures et du matériel pour réaliser l'activité noté de un à cinq

- Priorité totale : la multiplication de la priorité métier et du coût estimé

Veuillez noter que certaines de ces activités sont des actions répétitives, destinées à piloter l'effort global de validation des données. Ceux-ci
pourraient être :

- Effectuer la revue et la mise à jour trimestrielles du processus et du document de validation des données
- Recherche visuelle hebdomadaire des anomalies et mise à jour de la fiche de suivi des anomalies
- Mise à jour annuelle de la liste des données et capteurs les plus précieux

De cette manière, le document sert également de liste principale indiquant comment le processus itératif de validation des données est
organisé et qui en est responsable.

22 / 38
6 outils pour le processus de validation
Parcourir l'analyse du système fournit un aperçu complet du système dans son intégralité ainsi qu'une analyse des risques,
deux déclarations de qualité des données (en l'état et à venir), un document de suivi des anomalies et une liste de
priorisation des activités. Sur cette base, la partie itérative du cycle de validation des données peut commencer, où des outils
sont conçus et mis en œuvre pour valider les données. Les outils peuvent être divisés en cinq catégories :

- Pile d'outils logiciels

- Outils experts de domaine
- Outils d'analyse visuelle
- Outils statistiques et algorithmiques
- Calibrages

Tout au long du cycle, certains outils de gestion des données sont utilisés. Les outils exacts à utiliser dépendent de la façon dont la
suite de validation des données est conçue et différeront en fonction du système exact, mais un exemple de boîte à outils de
validation est décrit dans les sections suivantes.

6.1 Pile d'outils logiciels

Une pile commune d'outils communs aux systèmes IoT peut également être utilisée pour la validation des données. Cependant, la
valeur ajoutée réside dans la manière d’utiliser ces outils. La pile d'outils typique utilisée par FORCE Technology en collaboration avec
l'Alexandra Institute pour la validation initiale des données est la suivante :

Nœud-ROUGE

Node-RED est une interface de programmation low-code, visuelle et basée sur des flux, facile à utiliser et open
source. Note-RED est utilisé pour plusieurs étapes de validation, depuis l'ingestion des données jusqu'à
l'exécution de diverses opérations sur les données pour corriger ou atténuer les erreurs.

PostgreSQL

PostgreSQL est une base de données open source riche en fonctionnalités. Il peut à la fois stocker des données
structurées (relationnelles, basées sur des colonnes) et des données semi-structurées telles que des blobs JSON ou
même des blobs texte ou binaires. L'extension Timescale permet une gestion efficace des séries temporelles, ce qui
constitue une fonctionnalité essentielle pour les données IoT. Enfin, l'extension PostGIS ajoute des fonctionnalités pour
les données géographiques.

Grafana

Grafana est une application de visualisation de données qui utilise des requêtes SQL pour extraire des données d'une
base de données et les visualiser dans un tableau de bord interactif. Ceci est utilisé pour créer un aperçu visuel des
données.

Carnet Jupyter

Jupyter Notebook est un environnement de programmation interactif, principalement pour Python, qui peut être
utilisé pour exécuter des statistiques et d'autres analyses sur les données. Il dispose d'une fonctionnalité
Notebook, ce qui facilite le mélange de notes et de programmation. Grâce à cela, on peut avoir du code qui est
immédiatement suivi d'un texte explicatif ou similaire.

Cette pile est suffisamment polyvalente pour être déployée de différentes manières, par exemple dans un cloud ou un
serveur privé, ou sur l'ordinateur personnel de la ou des personnes effectuant l'analyse, ou même sur site ou en périphérie si
les données doivent rester à proximité du lieu où il est produit.

23 / 38
6.1.1 Utilisation de la pile
Comme indiqué ci-dessus, ces outils ne sont qu'un exemple de pile pouvant être utilisée pour la validation des données, et leur
utilisation ou non doit être déterminée lors de la phase de conception. Des outils logiciels similaires sont disponibles, mais nous
contribuons avec des modules open source principalement pour la pile d'outils ci-dessus.

Par exemple, ces outils pourraient être utilisés lors de la première validation des données dans les étapes suivantes :

1. Les données sont fournies dans un certain format de données, cela peut être soit sous forme de fichier dump au format CSV, soit sous
forme d'accès via une API REST.
2. Les données sont ingérées via Node-RED dans Timescale (PostgreSQL), avec la possibilité d'effectuer une
validation de schéma avant ou après l'insertion dans la base de données. S'il y avait des erreurs dans le
schéma et le format des données, Node-RED serait en mesure de trouver les erreurs déjà à cette étape.
3. Une fois les données ingérées avec succès dans Timescale, Grafana est capable d'afficher les données dans un tableau de bord visuel,
où les valeurs aberrantes, les écarts entre les paquets de données ou d'autres problèmes peuvent être identifiés et hiérarchisés.

4. Une suite de validation et un ensemble de règles de validation peuvent être conçus, par exemple en effectuant une analyse
statistique des données, à l'aide de Jupyter Notebook.
5. Node-RED est utilisé pour effectuer les opérations décidées sur les données. D’abord sur des exemples de données, dans le cadre de
la phase de mise en œuvre, ensuite sur les données réelles dans le cadre de la phase d’exécution.
6. Les données peuvent à nouveau être visualisées à l'aide de Grafana et, si nécessaire, les données peuvent être à nouveau
analysées à l'aide de Jupyter Notebook.
7. L'évaluation est examinée et les questions restantes sont identifiées et classées par ordre de priorité.
8. Une nouvelle suite de validation et un ensemble de règles de validation sont conçus, au fur et à mesure que le processus est itéré.

Enfin, il y a le défi que les données en cours de validation ne soient qu'une copie de la base de données originale du système. Par conséquent,
la dernière étape du processus de validation des données devrait consister à concevoir comment intégrer les outils de validation des données
dans le système principal en fonctionnement (l'environnement de production).

6.2 Outils visuels

Les outils visuels sont d’une grande aide pour vous aider à étudier les données manuellement. Ils sont généralement utilisés pour trouver les
anomalies et les problèmes de données pour le système étudié. Nous présentons ici quelques outils intégrés dans la pile d'outils logiciels et
des ressources supplémentaires qui peuvent être combinées avec la pile d'outils pour prendre en charge des activités supplémentaires.

6.2.1 Tableau de bord

Le plus important est de pouvoir avoir une vue d'ensemble du système, où se trouvent les défis les plus évidents en matière de
données à l'échelle du système, puis de l'explorer plus en détail. Pour cela, un tableau de bord est une excellente solution. Les
données initiales doivent inclure des données sur une longue période, par exemple un an, à titre de première vue.

La première chose souvent étudiée est un simple aperçu du nombre d’appareils connectés et du nombre de paquets reçus dans le
système. Cela peut donner un premier aperçu si, par exemple, il y a des problèmes de connectivité ou des changements dans la base
d'installation. Il s’agit également de voir si la mise à l’échelle deviendra un problème dans un avenir proche.

24 / 38
 Figure 14 : Appareils et taille des paquets.

L'outil suivant consiste à utiliser des nuages de points de carte thermique pour visualiser le nombre de paquets (codage couleur) pendant une
période de temps (axe des x) entre certaines tailles (axe des y). Ici, les changements de formats, de contenus de charge utile et les anomalies
temporelles peuvent être rapidement identifiés.

Figure 15 : Nuage de points regroupés sur la carte thermique pour la visualisation des données.

Les tableaux sont également un outil utile dans le tableau de bord, par exemple pour afficher la longueur de la charge utile de chaque
appareil.

Figure 16 : Tableau avec la longueur de la charge utile et le nombre de paquets.

25 / 38
Il peut également être utilisé pour afficher les délais d'arrivée entre les paquets et le nombre d'appareils en ligne. Veuillez noter que
ceux-ci peuvent être difficiles à calculer s'il existe de nombreux capteurs déclenchés par des événements par rapport aux capteurs
utilisant un modèle de transmission programmé.

Figure 17 : Délais interarrivées et indication en ligne.

Il est également recommandé de visualiser toutes les données mesurant le même paramètre sur un seul tracé. Veuillez noter
que cela peut être une bonne idée de les segmenter en fonction de ce que mesurent les capteurs. Par exemple, le cas de
l'humidité de la figure 18 pourrait être segmenté en mesures dans l'air, sur le béton et dans les réfrigérateurs.

Figure 18 : Visualisation des valeurs de séries chronologiques de toutes les mesures d’humidité.

Dans Grafana et dans de nombreux autres outils, il est très avantageux d'explorer les séries individuelles en cliquant et en
examinant une seule variable, à la recherche d'anomalies particulières. La meilleure stratégie consiste à partir de l'aperçu et
à inspecter les sources individuelles en fonction de ce qui peut être observé à partir de l'aperçu, mais aussi d'enquêter au
hasard sur certains des capteurs qui semblent corrects. Par exemple, des capteurs signalant la même valeur encore et
encore peuvent être une source d’erreur à rechercher. L’inspection peut révéler bien d’autres types d’erreurs telles que :

- Données manquantes
- Transitoires et discontinuités physiquement impossibles
- Bruit dans les données
- Valeurs aberrantes, par exemple petites ou grandes valeurs

Figure 19 : Visualisation d'une trace de données unique - ici une discontinuité dans une valeur de capteur.

26 / 38
Une mise en garde particulière consiste à être très conscient de l’agrégation temporelle des données. Dans de nombreuses solutions IoT, les
données sont mesurées beaucoup plus fréquemment qu'elles ne peuvent être visualisées. Par exemple, si un capteur mesure des données
chaque minute pendant une année complète, cela devient 525 600 points de données. Par conséquent, les données sont généralement
agrégées avant la visualisation pour accélérer le système. Cette agrégation est souvent la moyenne d'une période de temps, par exemple un
jour lorsqu'on visualise une année complète. Cela peut masquer et masquer les valeurs manquantes et les valeurs aberrantes. Par conséquent,
modifier l’agrégation temporelle est une bonne pratique. Une autre façon consiste à modifier les fonctions d'agrégation pour inclure le
maximum, le minimum, l'écart type, en plus de la moyenne pour la période.

La liste des visualisations des données peut s'allonger encore et encore, et elles dépendront de l'application du système. Les outils ci-dessus sont
généraux et devraient être trouvés dans tous les systèmes IoT. Une dernière remarque importante concerne les visualisations géographiques, qui
peuvent être très utiles pour déterminer s'il existe des problèmes de qualité des données spécifiques à un emplacement. Cela peut afficher les valeurs
moyennes, le pourcentage de données manquantes ou la variation temporelle des données dans une zone spécifique.

Figure 20 : Visualisation géographique des données.

6.2.2 Visualisations alternatives

Changer les visualisations peut être un bon moyen d’étudier les données d’une nouvelle manière. Parfois, changer la
visualisation peut aider à voir de nouveaux défis.

En modifiant les types de visualisation, de nouveaux modèles d'erreurs peuvent devenir apparents et être inclus dans la
représentation globale. Treevis.net est un site contenant une multitude de techniques de visualisation de structures arborescentes –
cela peut être une grande source d’inspiration. Le lien en haut à gauche contient également d'autres types de visualisations.

27 / 38
 Figure 21 : Exemples de visualisations de données.

Une visualisation particulière qui peut être utilisée pour des variables uniques, c'est-à-dire les données provenant d'un seul capteur,
est le tracé statistique à variable unique. La figure 22 montre une visualisation dupackage simplifié de GitHub , bien que la
documentation soit meilleure àstreamlit.io . L’avantage est que les tracés peuvent être configurés rapidement pour explorer les
données. Autrement dit, quelle source de données étudier et quelles valeurs statistiques doivent être affichées.

La couleur de fond indique l'état du système, dans ce cas si le navire est en manœuvre, en navigation régulière ou dans un
port. Le noir est méchant, le rouge est le maximum et le bleu est le minimum.

Figure 22 : Graphique statistique à variable unique.

Une autre visualisation intéressante est le tracé de l’espace des phases. Ici, l'utilisateur peut sélectionner les trois sources de données
qui doivent être comparées en les traçant sous forme de x, y et couleur. Cela donne l'opportunité de voir si une anomalie spécifique
dans la relation entre les deux variables s'est produite à un certain endroit ou à un moment donné, puisque celle-ci sera mise en
évidence par une couleur spécifique.

28 / 38
Une façon d'ajouter des détails supplémentaires à cette visualisation consiste à utiliser Scagnostics, qui est une méthode permettant de
déterminer la distribution d'un nuage de points par rapport à des caractéristiques telles que périphérique, asymétrique, grumeleux, convexe,
maigre, strié, filandreux, droit et monotone.

Figure 23 : Tracé de l’espace des phases.

Semblable à l’implémentation simplifiée, le cadre de visualisation Vega peut également être suggéré. Il fournit une manière
uniforme de décrire les visualisations. En particulier, legraphique de voyage L'interface utilisateur fournit des fonctionnalités
intéressantes intégrées dans un navigateur Web similaires au tracé de l'espace de phase et au tracé statistique à variable
unique mentionnés ci-dessus.

Figure 24 : Visualisation des données basée sur Voyager 2 Vega.

29 / 38
Un dernier point concernant la validation graphique consiste à utiliser également l'interface utilisateur. Parfois, les outils graphiques de
visualisation des données pour les utilisateurs des données IoT intègrent des fonctions qui modifient les données que les utilisateurs voient
par rapport aux données de la base de données. Cela pourrait par exemple être :

- Étiquetage et unités pour les données.

- Ajustement de l'échelle de l'axe y.
- Correction du décalage et du gain.
- Conversion d'un paramètre en un paramètre dérivé, par exemple pression atmosphérique en altitude.
- (Dé)emballage des données de non signé à signé.
- Agrégation temporelle.

L'exercice consiste tout simplement à explorer si la visualisation des données utilisée dans le processus de validation des données s'aligne sur
les données de l'interface utilisateur graphique.

6.3 Outils experts du domaine

L'un des principaux défis lors de la validation des données est de savoir ce qui est normal et ce qui ne l'est pas et cela peut être défini
par l'expert du domaine, mais afin d'éviter de déranger l'expert en la matière/domaine à chaque fois que les données doivent être
validées, certains outils viennent très pratique pour le responsable de la validation des données.

6.3.1 Comprendre le système physique

Comprendre le système physique est essentiel pour valider les données. Ici, les modèles physiques sont un outil essentiel.
Par modèles physiques, nous n'entendons pas des représentations à l'échelle, mais plutôt un diagramme du modèle
physique. Celles-ci peuvent être d'une très grande complexité, mais l'essentiel est de créer un modèle qui décrit les relations
et les contraintes entre plusieurs éléments de données. Ils doivent être créés en collaboration avec un expert en la matière
(SME). Il y a une tendance à exagérer ces modèles, l’essentiel est de commencer simple et de construire à partir de là. Même
une simple description peut être très utile. A titre d'exemple, un navire est utilisé :

- Quelles sont les vitesses typiques, minimales et maximales lors de la navigation/manœuvre ?

- À quelle vitesse peut-il changer de direction ou accélérer ?
- Quelle serait la consommation de carburant, le régime moteur et la température d'huile typiques ?
- Quelle est la différence entre les classes de navires A, B et C ?

Avoir un dessin brut (modèle physique) d'un navire avec de tels paramètres notés améliore considérablement la compréhension des
contraintes de données pour le processus de validation des données.

De manière générale, il peut être formulé selon les cinq étapes suivantes :

1. Identifiez l’objectif du modèle.

2. Dessinez un diagramme schématique incluant les variables de données (et la liste des contraintes).
3. Déterminez les dépendances physiques.
4. Écrire des équilibres et des relations dynamiques (masse, énergie, chaleur, flux, géométrie).
5. Vérifiez par comparaison avec les données réelles (simulées/mesurées/observées).

À titre d'exemple simple, prenons un système qui surveille l'eau de pluie dans un réservoir d'eau de pluie pour compenser les fortes pluies
dues au changement climatique. Les experts du domaine sont capables de faire des estimations raisonnables de paramètres tels que la
capacité pluviométrique, le débit entrant et sortant du réservoir, cf. Graphique 25.

30 / 38
 Figure 25 : Exemple de modélisation très basique d'un système physique surveillé.

S'il s'avère qu'il n'y a pas d'alignement satisfaisant entre les attentes du modèle physique et les données mesurées à partir
du système, l'étape suivante peut consister à améliorer le modèle en utilisant des modèles plus avancés, tels que des
simulations de système ou des outils de simulation multiphysique 3D tels que :

- Débit de fluide et transfert de chaleur

- Mécanique des structures
- Procédés chimiques
- Acoustique
- Électromagnétique

Cela peut être utilisé pour déterminer si le placement du capteur est correct, si les estimations de débit effectuées par des experts du domaine
sont correctes, et bien d'autres encore. Un exemple pourrait être l’emplacement de capteurs thermiques pour mesurer la température des gaz
d’échappement d’un moteur. Ici, la répartition de la chaleur peut être simulée dans l'échappement pour déterminer l'emplacement le plus
précis du capteur.

Figure 26 : Exemples de simulations système et multiphysiques pour améliorer la précision du modèle.

À titre d'exemple de la complexité, le lecteur est encouragé à consulter l'article« Mesure non invasive de la
température des écoulements turbulents de solutions aqueuses et de gaz dans les canalisations » J. Gebhardt, 2020 ,
où la mesure de la température dans un tuyau est liée à la position du capteur et à l'incertitude liée aux dimensions
du tuyau.

31 / 38
6.3.2 Validation de l'installation
La validation de l'installation est effectuée pour vérifier la validité des positions et de l'installation du capteur par rapport aux
structures physiques qu'il mesure.

Mieux décrit par un exemple simple de jauges de contrainte montées sur un bâtiment (mesurant la contrainte dans le béton), car les
activités effectuées peuvent varier considérablement.

- Position des capteurs de validationsont inspectés pour être installés à l’emplacement du bâtiment indiqué par leurs
métadonnées (ou convention de dénomination).
- Exactitude de l'installation du capteurdétermine si les capteurs sont installés conformément à leurs spécifications.
Par exemple, si un débitmètre d'eau n'est pas monté directement après un coude à 90 degrés.
- Effet physique sur la validation de la sortie du capteurgarantit que les capteurs sont correctement montés. Par exemple, si
les jauges de contrainte ne sont pas correctement collées au bâtiment, protégées par une infiltration d'eau, etc. Elles
mesureront la déformation, mais les valeurs seront incorrectes. Ici, les capteurs peuvent être soit inspectés physiquement,
comparés à une référence, soit démontés et remontés.
- Surveillance des conditions de fonctionnementIl s'agit d'un cas particulier, où les paramètres associés sont mesurés pour vérifier qu'ils
n'ont pas d'impact sur les mesures - par exemple, en surveillant les vibrations à proximité d'un capteur de rotation.

Il est important de noter que ces activités seront généralement basées sur une stratégie d'échantillonnage de telle sorte que seules certaines
installations de capteurs seront validées, à moins que de nombreuses erreurs ne soient détectées.

6.3.3 Comparaisons avec les données de référence

Dans certains systèmes IoT, les données de référence peuvent être disponibles via d'autres ensembles de données accessibles au public. Souvent, les
experts du domaine en sont conscients et peuvent vous guider dans la bonne direction. Cela pourrait être :

- Données météorologiques.

- Informations sur le trafic (ou données partielles, par exemple bus).

- Comptage validé d'électricité, de chaleur, de gaz, d'eau, etc.

Il convient de souligner que ces ensembles de données peuvent,ou peut-être pas,être déjà validé. Il n’est donc pas garanti que la
comparaison soit effectuée avec une source de données valide, mais l’accord entre deux ensembles de données indépendants est un
bon indicateur. Le processus peut être effectué manuellement ou via des algorithmes. Sachez que la synchronisation temporelle des
ensembles de données peut poser des défis à l'approche algorithmique.

6.4 Outils statistiques et algorithmiques

Les outils statistiques et algorithmiques sont essentiels pour automatiser la validation des données, mais aussi pour l'inspection manuelle des
données. Cela va des simples histogrammes de capteurs individuels aux statistiques bayésiennes et aux modèles d'apprentissage automatique
de réseaux neuronaux pour détecter les anomalies.

6.4.1 Validation du schéma

La première approche à utiliser consiste à évaluer le schéma des données. Un schéma est une définition des champs dans les
données envoyées, y compris le format et les plages de ces formats. Par exemple, une mesure de température doit contenir
un identifiant de l'appareil, et celui-ci est signalé sous forme d'entier, la température est une chaîne contenant uniquement
des nombres et des points décimaux. Le processus de validation du schéma est utilisé pour vérifier que les données entrant
dans le système sont conformes. Différents schémas existent déjà, mais dans la mesure du possible, il est recommandé
d'utiliser des schémas standards, et au moins d'utiliser une syntaxe sous-jacente telle que JSON-LD favorisant
l'interopérabilité. Un bon point de départ estsmartdatamodels.org , mais l'aspect le plus important est d'avoir un schéma.

32 / 38
 Figure 27 : Exemples de schémas.

L'Institut Alexandre a réalisé un validateur de schéma open source pour Node-RED,noeud-rouge-contrib-json-

multischéma .

6.4.2 Détection de valeur constante

Une erreur très courante observée dans les ensembles de données concerne les valeurs constantes. Cela pourrait être aussi simple que de
définir une fenêtre de dix valeurs dans laquelle les données de la source sont constantes. Cela pourrait indiquer que le micrologiciel d'un
capteur ou la connectivité est perdu et que les valeurs des données sont remplacées par la dernière valeur connue.

6.4.3 Niveaux de confiance

L'analyse du niveau de confiance a été introduite par « Validation de la qualité des données pendant la surveillance par temps humide des
influents des usines de traitement des eaux usées » J. Alferes, et. Al., 2013. Ici, le concept est de définir quatre niveaux pour chacun des quatre
paramètres pour une seule source de données. Les quatre niveaux sont :

- Le minimum
Le niveau minimum qui doit apparaître dans les données – par exemple, la température zéro absolue de -
273 °C
- Faible
La valeur la plus basse des données – comme -15 °C pour le liquide de refroidissement d'une voiture

- Haut
La valeur la plus élevée des données – comme par exemple +95 °C pour le liquide de refroidissement d'une voiture

- Maximum
La valeur maximale qui devrait apparaître dans les données – par exemple +115 °C pour le liquide de refroidissement d'une voiture

Chacun d'entre eux est converti en un score de niveau de confiance, de telle sorte que la confiance inférieure au minimum ou
supérieure au maximum reçoit la valeur 0, entre faible et élevé le score est de 100, et entre minimum et faible, et élevé et
maximum, la valeur est la interpolation linéaire entre les deux valeurs comme le montre la figure 28.

Les quatre paramètres où cela doit être évalué sont :

- Combler les lacunes

Nombre de valeurs manquantes dans la source de données sur une période donnée.
- Vérification de la portée

Les valeurs réelles dans les données.

- Taux de changement
La vitesse à laquelle le signal peut changer.
- Écart courant
Dans quelle mesure un point de données peut varier par rapport aux points de données proches.

33 / 38
Par exemple, le liquide de refroidissement de la voiture peut augmenter de 10 °C par minute (élevé) et diminuer de -5 °C par
minute (faible), mais jamais de +/- 50 °C par minute (minimum et maximum).

Par conséquent, la confiance dans chaque paramètre est obtenue et le score global est simplement le minimum de chacun des
quatre scores de paramètres distincts. Cela donne une indication rapide de la confiance que l’on peut avoir dans le point de données.
Pour analyser un capteur au fil du temps, un histogramme peut ensuite être utilisé, indiquant le nombre de points inférieurs à un
seuil (par exemple, 75) acceptés sur une période de temps donnée.

Figure 28 : Calcul du niveau de confiance.

6.4.4 Test de la loi de Benford

La loi de Benford est généralement utilisée pour détecter la fraude dans les systèmes. Lorsqu'une série de nombres apparaît, le
premier chiffre suit la distribution décrite par Benford (les nombres inférieurs sont plus fréquents que les nombres élevés).

Pour la validation des données, la loi de Benford peut être utilisée pour détecter des erreurs dans le système ou pour évaluer si les mises à niveau ont
entraîné une amélioration significative de la validité de l'ensemble de données.

Dans le journal« Sur l'utilisation de la loi de Benford pour évaluer la qualité des données fournies par les systèmes de localisation par
foudre » par E. Mansouri, 2022 , les données suivaient de mieux en mieux la loi de Benford à mesure que les systèmes de détection
de la foudre étaient améliorés. Ainsi, nous avons pu donner une estimation de l'amélioration des coups de foudre détectés par le
système.

6.4.5 Détection de biais et de valeurs aberrantes pour un groupe de capteurs

Vérifier si certains capteurs sont aberrants ou présentent un décalage par rapport à d'autres capteurs qui devraient avoir des
données similaires est un bon moyen de valider les données. La meilleure façon d’y parvenir est de calculer la moyenne de
tous les capteurs et de soustraire cette valeur des données de chaque capteur. Il est ensuite possible d'évaluer s'il y a des
écarts par rapport à la moyenne et à l'étalement des capteurs sur une période de temps donnée. Dans la figure 29, toutes les
données provenant des capteurs de température des capteurs de stationnement intégrés dans le tarmac sous les places de
stationnement sont tracées. Après correction de la moyenne, il est possible de constater que les variations de température
de mars à septembre sont très importantes à travers les capteurs. Mais entre novembre et février, la situation est très stable.
Le but de l'utilisation des données était de détecter si le salage des routes pour éviter le gel était nécessaire. Cela a été jugé
possible après l’évaluation. De plus, quelques capteurs (courbes marron et orange) présentaient un décalage négatif par
rapport au reste des capteurs.

Il convient de mentionner que les variations importantes étaient principalement causées par le rayonnement solaire sur les capteurs de
stationnement, qui conduisait à une lecture de température plus élevée que la température de l'air ambiant.

34 / 38
 Figure 29 : Données provenant des capteurs de température des capteurs de stationnement intégrés dans le tarmac sous le parking
des taches. En haut : données brutes, en bas : données brutes avec soustraction de la valeur moyenne de tous les capteurs pendant cette période.

6.4.6 Algorithmes de correction des données

Un aspect essentiel de la validation des données est également la gestion des versions des données. Le scénario idéal est d’avoir deux bases de
données distinctes avec les mêmes données, sauf que la première contient les données brutes et la seconde les données nettoyées.
Cependant, dans la pratique, cela entraînerait dans certains cas un besoin supplémentaire important en capacité de stockage. Comme les
données doivent être corrigées, par exemple pour corriger le décalage illustré dans la figure 29, ou des données supplémentaires associées au
point de données, telles que les seuils de niveau de confiance – voir la section 0, l'historique de mise à jour des données doit être documenté. .

L'historique des versions peut être un objet contenant l'intégralité de la ligne de données précédente, une référence à l'algorithme
qui l'a corrigé et à la date à laquelle il a été corrigé. L'indicateur corrigé peut également être intégré dans l'objet historique des
versions et/ou contenir des informations plus riches telles que le type de correction(s) appliquée(s).

35 / 38
 Figure 29 : Objet historique des versions ajouté dans une base de données.

Les corrections de données peuvent être divisées en deux catégories pour les systèmes IoT, les métadonnées et les données de séries temporelles.

Les métadonnées sont généralement des entrées utilisateur ou des données importées d'autres systèmes. Voici les corrections

- Modifications de format

Cpasse d'un type de format à un autre – par exemple, le format de date.

- Alignement des données

Un ensemble de données de référence est utilisé pour trouver les bonnes valeurs, telles que les erreurs de frappe dans les noms de rues.

- Alignement du schéma
Les données sont alignées sur le schéma, par exemple pour ne pas autoriser de caractères spéciaux dans les noms de rues.

Après les évaluations des données, comme lors des calculs du niveau de confiance, les avertissements et les erreurs ont été signalés dans
l'ensemble de données. Sur la base de ces évaluations, de nouvelles valeurs peuvent être insérées dans les données de séries chronologiques
(tout en suivant l'historique des modifications). Cela peut reposer sur plusieurs règles :

- Régularisation d'échelle
Conversion des valeurs comprises entre 0 et 1 – pour aligner sur 0-100 %.
- Changement d'unité

Conversion de la valeur d'une unité à une autre – par exemple, tension de la batterie ou pourcentage restant.
- Insertion de valeur
Si la valeur se situe dans la plage d'erreur, par exemple si elle est manquante en raison d'une perte de signal ou d'une impossibilité physique, plusieurs options existent.

- Interpolation
Valeur issue de l'interpolation entre les deux valeurs adjacentes ou basée sur une régression linéaire sur les points
précédents – peut être basée sur des algorithmes plus avancés tels que le polynôme local.
- Lissage
Une variante spécifique d'interpolation où les données sont lissées pour détecter les anomalies.
- Calcul d'inférence
Valeur calculée à partir de mesures associées basées sur le modèle physique du système, par exemple, niveau d'eau dans le
réservoir calculé à partir de mesures de précipitations.
- Correction d'étalonnage
Correction de la valeur après qu'un capteur a été calibré par rapport à. gain et compensation.
- Insertion de données externes
L'insertion de points de données provenant d'une source externe pourrait être des données météorologiques au lieu de données de capteurs de
pluie.

Les règles appliquées différeront d’un cas à l’autre, mais « l’historique des modifications » doit toujours être documenté.

6.5 Étalonnages
Les étalonnages sont essentiels pour valider les données dans un système IoT. Un étalonnage détermine la précision de la valeur
mesurée du capteur par rapport à la véritable valeur physique. Cependant, veuillez rappeler les notes de la section 0 concernant la
validation de l'installation.

Si un capteur n’est pas fiable en termes de précision, il peut être (re)calibré et la validité des données de la source peut être
utilisée. Les étalonnages se répartissent en deux catégories principales :

- Étalonnages en laboratoire: Réalisé dans un laboratoire accrédité.

- Étalonnages sur le terrain ou in situ: Réalisé sur le site de l'installation.

36 / 38
6.5.1 Étalonnages en laboratoire

Les étalonnages en laboratoire peuvent être effectués en interne ou dans un laboratoire externe. La caractéristique
importante est que l'étalonnage relie les mesures du capteur à une référence traçable connue. Cela peut sembler très
coûteux, et cela peut parfois l’être, mais peut également être réalisé à moindre coût. Par exemple, en disposant d’un capteur
de température calibré, puis d’une procédure pour comparer ce capteur à tous les autres capteurs. La norme ISO 17025
fournit des lignes directrices sur ce qui est requis pour ce faire. Les résultats d’un étalonnage doivent être

- Incertitude des mesures

- Linéarité des mesures
- Plage de mesures valide

Dans certains cas, le temps de réponse, c'est-à-dire le temps nécessaire avant qu'une mesure soit stable lorsque l'environnement a
changé, ainsi que d'autres paramètres peuvent également être les résultats d'un étalonnage.

Figure 30 : Résultats d'étalonnage en laboratoire d'un capteur de CO2. Gauche : Bleu clair : Référence d'exposition, Bleu foncé : Mesure
valeur mesurée, à droite : linéarité du capteur.

Presque toutes les grandeurs physiques peuvent être étalonnées. Il s'agit plutôt de trouver le laboratoire qui peut le faire et de
réfléchir à la manière d'optimiser les coûts, car souvent l'étalonnage du capteur peut coûter le même prix que le capteur lui-même.

6.5.2 Étalonnages in situ

Les étalonnages in situ ne sont pas effectués en laboratoire, mais à l'emplacement du capteur. Ici, la référence
connue est amenée au capteur et conserve une source de données parallèle, traçable à une référence connue,
jusqu'au capteur qui doit être calibré. Ceux-ci sont le plus souvent utilisés comme recalibrages.

En particulier pour les étalonnages IoT, les données du backend pendant l'étalonnage peuvent également servir de référence
pour la validité d'autres capteurs à proximité de ce capteur. Il continuera à effectuer des étalonnages in situ pour les autres
capteurs non calibrés. Un bon exemple de ceci pourrait être d'avoir cinq capteurs calibrés connus dans les données
présentées dans la figure 29.

6.5.3 Fusion de capteurs

La fusion de capteurs fait référence au fait que d'autres capteurs mesurent des quantités physiques différentes ou identiques à celles
du capteur d'origine, afin d'améliorer les données de ce capteur d'origine. Cela peut être un avantage pour valider les données. Par
exemple, avoir un capteur d'irradiation solaire à côté des capteurs de température de la figure 29 peut créer une trace de données
secondaires qui peut déterminer si l'irradiation solaire au niveau de ce capteur rend la mesure invalide. De même, le capteur de
stationnement, qui est monté dans le même capteur, indiquerait qu'une voiture est garée au-dessus du capteur et qu'elle ne sera
donc pas frappée par le soleil. Cela pourrait également être utilisé pour améliorer la validité des données des capteurs de
température.

37 / 38
7. Conclusion
Le présent livre blanc a décrit les meilleures pratiques en matière de validation des données. Il est évident que la validation des
données peut rapidement devenir une tâche très chronophage et il est donc important de réitérer que l'activité la plus essentielle de
la validation des données est la définition des exigences auxquelles les données doivent répondre pour être adaptées à leur objectif.
La qualité et la précision sont-elles suffisantes pour être utilisées comme données pour les décisions fondées sur les données ? Après
avoir déterminé cela et adopté une hiérarchisation très critique des activités dans le processus itératif, vous pouvez améliorer
considérablement la validité et la qualité de vos données avec un minimum d'effort.

38 / 38