FR 3164553 A1 20260116 FR 2407643 A 20240712 L’invention concerne une méthode de collecte de données industrielles au sein d’une usine (100) qui comprend un équipement industriel qui exécute un processus au sein d’une station (ST01, ST02) incluse dans une opération (OP600 ; OP630). Selon l’invention, la méthode comprend les étapes suivantes : - instanciation d’un modèle de données physique sur un serveur local (120), le modèle présentant une structure hiérarchisée, avec une première classe, respectivement une seconde classe, respectivement une troisième classe, comprenant des variables liées au processus, respectivement à la station, respectivement à l’opération, la première classe dépendant de la seconde, qui dépend de la troisième, chaque variable présentant un type et une adresse physique d’allocation d’une valeur de la variable sur l’équipement industriel ou la station ou l’opération, les variables étant issues d’une base de données des variables, - collecte des données selon ledit modèle de données, pour chaque variable, le serveur local est connecté à son adresse physique afin d’enregistrer sa valeur, - stockage des données sur un serveur à distance (140). Figure pour l’abrégé : Fig.1 Méthode de collecte de données industrielles Domaine technique de l'invention La présente invention concerne de manière générale l’exploitation des données numériques dans le cadre de l’industrie. Elle concerne plus particulièrement un procédé de collecte de données industrielles sur une chaîne de production industrielle selon des modèles de données, et de stockage de ces données industrielles collectées vers un serveur de données. L’invention trouve une application particulièrement avantageuse pour de nombreux cas d’exploitation et d’analyse de la donnée – surveillance des processus, traçabilité, maintenance conditionnelle et prédictive – à une échelle industrielle de grande envergure, en répondant à des contrainte d’interopérabilité, notamment pour l’industrie automobile. Etat de la technique La quatrième révolution industrielle, ou industrie 4.0, vise à implémenter de nouvelles façons d’organiser les moyens de production, en exploitant notamment l’Internet Industriel des Objets (IIoT). L’IIoT permet notamment de connecter les systèmes informatiques, les équipements industriels, et les capteurs, et ce sur des chaînes industrielles, de fabrication, de montage et/ou de production. Des données, dites données industrielles sont ainsi captées directement sur les chaînes industrielles, et acheminées sur des serveurs en temps réel. L’industrie 4.0 repose notamment sur l’analyse, voire l’exploitation des données ainsi captées. Par exploitation des données, il est ainsi entendu des cas d’utilisation tels que : la surveillance des processus, la traçabilité, ou la maintenance conditionnelle et prédictive. Ces cas d’utilisation de la donnée permettent par exemple d’optimiser, de fluidifier et/ou de simplifier les opérations, et ce depuis l’échelle d’une ligne de production jusqu’à une échelle globale, comprenant les différentes usines d’un groupe industriel, par exemple un groupe industriel automobile. Néanmoins, un des défis majeurs auquel la quatrième révolution industrielle est confrontée, est l’interopérabilité. Celle-ci, telle que définie par l’ European Interoperability Framework comprend quatre niveaux, et vise à harmoniser l’écosystème industriel. En effet, ce dernier, souffre de l’approche « en silo », où chaque domaine présente une sémantique et des protocoles qui lui sont propres. Ainsi, les chaînes de production se retrouvent segmentées en une multitude de protocoles et/ou standards (ModBus, BAC-NET, 3964R, FlexRay, S7, Cc-link, TPC, CAN Open, etc…), le plus souvent incapables d’échanger directement des données, et/ou à communiquer en utilisant des normes techniques communes. De même, la prolifération du vocabulaire et processus en fonction des corps de métier au sein d’une organisation industrielle engendre des redondances, et une sous-optimisation des moyens de production. En particulier, l’hétérogénéité des données industrielles collectées contrarie l’instauration de l’industrie 4.0. En effet, les flux de données collectées sont de tailles très importantes, notamment à l’échelle d’un groupe industriel. L’organisation et l’exploitation de ces données hétérogènes constitue une perte de temps et de ressources, avec notamment des redondances, augmentant les coûts d’accès aux serveurs sur lesquels les données sont usuellement stockées. Ainsi, l’interopérabilité vise à rendre possible la communication et les échanges d’information entre deux systèmes, par exemple, entre deux protocoles de communication, comme le protocole Open Platform Communication Unified Architecture , et le protocole Message Queing Telemetry Transport . Rendre ces protocoles interopérables implique notamment une compatibilité des formats, de la qualité des données, ou de la préservation sémantique. Une solution proposée a été d’opérer une médiation des données, c’est-à-dire, opérer des traductions vers une forme compréhensible pour un système cible. Cependant, cette solution s’avère peu applicable à une échelle importante, car elle engendre des coûts d’accès importants aux serveurs de données, mais également des coûts de traitement élevés. Or, certains industriels automobiles récoltent environ 800 gigaoctet de données industrielles par jour, sur plus de 60 types d’équipements qui comptabilisent au total près de 8500 machines. Par ailleurs, la médiation des données dégrade la qualité des données collectées. De plus, la qualité des données industrielles récoltés se retrouve également dégradée par les traductions multiples, nécessaires pour la médiation des données. On connaît également dans l’état de la technique une approche par standardisation. Une telle approche via un standard, destiné aux industriels, appelé OPC UA (pour Unified Architecture ), développé par la fondation OPC. Néanmoins, ce standard adopte une vision équipement – c’est-à-dire, se focalisant sur des informations associées aux équipements industriel –, qui s’avère peu adaptée à l’aspect orienté processus industriels adopté par certains industriels, notamment la demanderesse. En particulier, le standard OPC UA, notamment, la logique de structuration des modèles de données de la fondation OPC UA ne permet pas de récolter de manière optimales les informations liées aux processus industriels, pourtant nécessaires aux l’industriels. Présentation de l’invention Afin de remédier aux l’inconvénient précité de l’état de la technique, la présente invention propose une méthode de collecte des données suivant une structure standardisée, grâce à l’application d’un modèle de données unique sous la forme d’une chaîne numérique de modélisation, qui débouche sur une instanciation du modèle de données sur les systèmes informatiques. Plus particulièrement, on propose selon l’invention une méthode de collecte des données industrielles au sein d’une usine, l’usine comprenant au moins un équipement industriel adapté pour exécuter au moins un processus industriel au sein d’une station, incluse dans une opération, dans laquelle il est prévu les étapes suivantes : - instanciation d’un modèle de données physique sur un serveur local, le modèle de données physique présentant une structure hiérarchisée dans laquelle au moins une première classe comprend des variables liées au processus industriel, une deuxième classe comprend des variables liées à la station, et une troisième classe comprend des variables liées à l’opération, la première classe étant hiérarchiquement liée à la seconde classe, et la seconde classe étant hiérarchiquement liée à la troisième classe, chaque variable présentant un type et une adresse physique d’allocation d’une valeur de la variable sur l’au moins un équipement industriel ou la station ou la opération, les variables étant issues d’une base de données des variables, - collecte des données industrielles selon le modèle de données physique, pour chaque variable, le serveur local est connecté à la adresse physique d’allocation de la variable, afin d’enregistrer une valeur de la variable, - stockage des données industrielles au sein d’un serveur à distance. Ainsi, grâce à l’invention, et notamment, grâce à la conception et l’exploitation de modèles de données standards, il est possible de mettre en œuvre une collecte des données industrielles selon un modèle de données standardisé. De manière avantageuse, des liens logiques hiérarchiques sont établis entre les différents variables collectées grâce aux modèles de données standards, dans le but de représenter le procédé industriel (aussi appelé process selon la terminologie anglo-saxonne). Les données sont ainsi contextualisées dès leur collecte. Un tel modèle de données instancié sous une forme physique permet un protocole d’échange de données standardisé avec un serveur de stockage, peu importe le processus, la station, ou l’opération considérée. Cette standardisation répond à un besoin d’interopérabilité, nécessaire à la gestion d’un flux de données important et provenant de sources diversifiées, représentative de la complexité industrielle. Cette solution est aisément mise à l’échelle, c’est-à-dire aisément applicable à un nombre croissant d’équipements, de processus, de stations, d’opérations et d’usine. Cette mise à l’échelle est notamment facilitée par un format standard de la donnée industrielle, limitant de manière avantageuse une multiplication de données hétérogènes, et de l’alignement sémantique à travers les différents processus industriels, facilitant l’exploitation de la donnée par la couche IT – c’est-à-dire les départements des technologies de l’information – de l’entreprise ou de l’industriel. Notamment, une variété de modèle de données différents est limitée, par exemple en mutualisant les variables possibles, grâce à la base de données des variables. La qualité des données collectée est également préservée, car ces données demeurent sous le format sous lequel elles sont récoltés depuis la collecte, jusqu’à une exploitation par un client. Ainsi, les coûts d’accès aux serveurs, ainsi que des coûts de traitement sont avantageusement diminués. D’autres caractéristiques avantageuses et non limitatives de la méthode conforme à l’invention, prises individuellement ou selon toutes les combinaisons techniquement possibles, sont les suivantes : - l’étape d’instanciation du modèle de données physique génère au moins un fichier d’instanciation sur le serveur local et l’étape de collecte est opérée selon un format et une structure hiérarchisée et standardisée à l’aide de l’au moins un fichier d’instanciation définissant le modèle de données, - la base de données des variables est une base de données répertoriant des variables préexistantes, - les variables préexistantes comprennent des variables préexistantes génériques et des variables préexistantes spécifiques, les variables préexistantes génériques sont utilisées par une pluralité de modèles de données physique, - les variables préexistantes spécifiques sont regroupées en une pluralité de briques spécifiques et les variables préexistantes génériques sont regroupées en une pluralité de briques génériques, le modèle de données physique est construit par assemblage des briques génériques et des briques spécifiques, afin de créer la structure hiérarchisée, - le serveur local sur lequel est instancié le modèle de données physique est un serveur OPC Unified Architecture, - l’adresse physique d’allocation de la valeur de l’au moins une variable est donnée par un pilote de configuration, le pilote de configuration générant un script d’adressage entre une base de données des adresses physiques et l’au moins une variable instanciée sur le serveur local, - la base de données des adresses physiques est établie compte tenu de l’au moins équipement industriel de l’usine (par exemple en fonction du logiciel de contrôle de chaque équipement, lequel stocke les données qu’il mesure ou génère à des adresses différentes de celles des autres équipements lorsque ces derniers ne sont pas identiques ; typiquement, deux perceuses de marques différentes stockent leurs données de manières différentes), - la collecte des données industrielles se fait en trois points de collecte de la donnée industrielle, chacun de ces points de collecte correspondant à une zone mémoire, où des variables liées hiérarchiquement par le modèle de données physique sont combinées et collectée simultanément depuis cette zone mémoire, les trois points de collecte de la donnée industrielle comprenant un point de collecte correspondant aux variables de la première classe, un point de collecte correspondant aux variables de la seconde classe et un point de collecte correspondant aux variables de la troisième classe, - les données industrielles sont collectées et stockées sous un format série temporelle, - la méthode comprend en outre une étape d’exploitation des données industrielles par un client, - l’étape d’exploitation de la donnée comprend une étape de suivi et d’identification de pièces produites par l’au moins un processus industriel, - l’étape d’exploitation de la donnée comprend une étape de maintenance conditionnelle sur l’au moins un équipement industriel mettant en œuvre l’au moins un processus industriel et/ou de rappel de pièces produites par l’au moins un processus industriel, - l’au moins un processus industriel permet de fabriquer une pièce de véhicule automobile. Bien entendu, les différentes caractéristiques, variantes et formes de réalisation de l'invention peuvent être associées les unes avec les autres selon diverses combinaisons dans la mesure où elles ne sont pas incompatibles ou exclusives les unes des autres. Description détaillée de l'invention La description qui va suivre en regard des dessins annexés, donnés à titre d’exemples non limitatifs, fera bien comprendre en quoi consiste l’invention et comment elle peut être réalisée. Sur les dessins annexés : FIG. 1 est une représentation d’un système de collecte des données industrielles, tel proposé dans la présente invention. FIG. 2 illustre par un organigramme, une méthode de collecte des données industrielles utilisant le système de la FIG. 1 . FIG. 3 illustre un exemple d’instanciation de données selon l’organigramme de la FIG. 2 . FIG. 4 représente l’architecture globale mise en œuvre dans la méthode de la FIG. 2 . FIG. 5 est un exemple de courbe établie à partir de données industrielles collectées selon la méthode de la FIG. 2 . Sur la FIG. 1 , on a représenté un système 1 de collecte des données industrielles. Un tel système 1 est implémenté au sein de plusieurs usines 100 (dont une seule d’entre elles est représentée), par exemple, des usines de fabrication et/ou d’assemblage de pièces mécaniques, par exemple des pièces automobiles. Ce système 1 comprend un serveur de stockage des données, ainsi que des moyens de pilotage et de communication entre le serveur de stockage des données, et des équipement ou machines de fabrication (typiquement des machines d’usinage ou d’assemblage, de moulage…). Ces machines de fabrication, ou machines industrielles, comprennent par exemple des capteurs, qui sont fonctionnellement connectés aux moyens de pilotage ou contrôleur, ces derniers étant ensuite fonctionnellement connectés au serveur de stockage des données. Les usines 100 intègrent en leur sein de multiples d’actifs industriels physiques, dont les machines industrielles, des systèmes de contrôle industriels, des automates programmables industriels ou des commandes numériques par ordinateurs. Ces actifs industriels physiques font partis des technologies opérationnelles, et mettent en œuvre des processus industriels. Ces processus industriels permettent ensuite la fabrication et/ou l’assemblage des pièces mécaniques, ici des pièces automobiles, et créent de la valeur ajoutée. En particulier ici, il est considéré, de manière non-limitative, l’exemple d’un processus industriel de vissage. La mise en œuvre de ce processus nécessite des équipements ou machines industrielles, en particulier, des machines de vissage ou visseuses 101, 102, 103. Par exemple, il peut s’agir de visseuses robotisées, ou de visseuses manuelles. Par ailleurs, dans le cas de visseuses robotisées, ces visseuses peuvent être automatisées, et être programmées pour exécuter une série de tâches prédéfinies, ou bien être pilotées par un opérateur. Ici, on considère un processus industriel de vissage mettant en œuvre par exemple, trois types de visseuses 101, 102, 103 différentes. Il s’agit dans cet exemple d’une visseuse manuelle, opérée à la main par un opérateur, d’un robot visseur automatisé, et d’un robot visseur opéré par un opérateur. Par la suite, il est fait référence respectivement, à la première visseuse 101, deuxième visseuse 102 et troisième visseuse 103. Ces visseuses 101, 102, 103 proviennent par exemple de fournisseurs différents ou d’un même fournisseur, mais sont de modèles différents. Pour la description, il est également considéré que les trois visseuses 101, 102, 103 sont situées au sein d’une même usine 100. Néanmoins, des visseuses 101, 102, 103 implémentées dans des usines 100 géographiquement éloignées les unes des autres sont également envisageables. Ces visseuses 101, 102, 103 sont reliées à des contrôleurs 111, 112, 113, par exemple, chacune des visseuses 101, 102, 103 est reliée à un contrôleur spécifique. Ainsi, il y a donc des premier, deuxième et troisième contrôleurs 111, 112, 113 associés respectivement aux première, deuxième et troisième visseuse 101, 102, 103. Ces contrôleurs, notamment pour les visseuses 102, 103 robotisées, permettent de contrôler et/ou piloter des actions réalisées par la visseuse. Dans le cas de la visseuse automatisée, le contrôleur permet par exemple de lui appliquer un couple et/ou un angle de vissage choisi, ou de contrôler des séquences de vissage, etc. Les visseuses 101, 102, 103 comportent en outre des capteurs, ces capteurs étant spécifiques au type de machine industrielle. Ainsi, les première, deuxième, et troisième visseuses 101, 102, 103 comprennent des capteurs, tels que des capteurs de température, des capteurs d’angle, des capteurs de vitesse, et des capteurs de couple, etc. Ces capteurs peuvent également être externes à la machine industrielle sur laquelle une mesure est relevée. Dans cet exemple, il est considéré que chacune des visseuses 101, 102, 103 comprend à la fois un capteur de température, un capteur d’angle, un capteur de vitesse, et un capteur de couple. Ces différents capteurs sont connectés aux contrôleurs 111, 112, 113, c’est-à-dire que les capteurs sont susceptibles d’envoyer des informations au contrôleurs 111, 112, 113, par exemple, par le biais d’une connexion filaire ou sans fil. Le contrôleur 111, 112, 113 reçoit des données (des données industrielles), que mesurent les capteurs. Ces données industrielles sont stockées dans un espace mémoire alloué de manière permanente ou non. Un emplacement de cet espace mémoire, aussi appelé adresse physique ou adresse physique d’allocation, et un format de la donnée industriel dépend de la visseuse considérée, mais aussi du contrôleur qui lui est associé, notamment d’un logiciel installé sur le contrôleur et du protocole de communication utilisé. On comprend en effet que deux fabricants de visseuse n’utilisent malheureusement pas un même format de données qui serait standard. Par ailleurs, des données telles que la date et l’heure sont également stockées dans un espace mémoire alloué sur chacun des contrôleurs 111, 112, 113. Ainsi, Les données industrielles collectées sont horodatées. Par exemple, sur la deuxième visseuse 102, le capteur d’angle mesure une donnée (ou une valeur) de l’angle de vissage appliqué par la visseuse, et transmet la donnée mesurée au deuxième contrôleur, et ce à un intervalle temporel régulier. Ainsi, chaque valeur de l’angle mesurée sur la deuxième visseuse 102 est associée à une donnée temporelle, par exemple la date et l’heure de mesure. Une liste, par exemple sous format Extensible Markup Language (XML), comprenant, dans une première colonne, une donnée temporelle, correspondant à la date et à l’heure, donnée par exemple sous la norme ISO 8601, et dans une deuxième colonne, la donnée de l’angle de vissage envoyée par le capteur d’angle, est enregistrée par le contrôleur. Des données industrielles, notamment, des données identifiant la machine industrielle sur laquelle les mesures effectuées par le capteur ont été acquises, sont également préenregistrées, ou enregistrées par le contrôleur, de la même manière que les exemples précédents. Il s’agit par exemple des informations quant au modèle et/ou à la marque, au numéro de série etc., de la machine industrielle considérée. Par ailleurs, les actifs industriels, par exemple, les visseuses 101, 102, 103 présentent une certaine organisation, afin de mettre en œuvre un processus. Dans le cadre de l’industrie automobile notamment, ces processus visent à créer de la valeur ajoutée autour de véhicules automobiles, en fabricant des pièces mécaniques à intégrer sur celle-ci. Ainsi, le processus de vissage industriel utilisant les trois visseuses 101, 102, 103 décrites précédemment peut intervenir à plusieurs stades par exemple d’un assemblage d’un véhicule automobile. Ces stades sont ici décrits par le terme d’opération. Notamment, la réalisation d’un véhicule automobile comprend une succession de plusieurs opérations OP600, OP630, chacune de ces opérations correspondant à la fabrication d’une pièce. Par exemple, une première opération OP600 consiste en la fabrication du moteur, et une deuxième opération OP630 correspond à la mise en place des tonneaux de roues. Chaque opération présente ensuite au moins une station, qui correspond à une étape de mise en œuvre d’une opération. Par exemple, il peut s’agir d’une station de vissage des roues, ayant lieu durant la seconde opération, ou alors d’une station de remplissage d’huile pour la première opération OP600. Enfin, chaque station comprend au moins un processus. Ces processus, par exemple, dans le cas de la station de remplissage d’huile, comprend un processus de pesage, un processus de remplissage, et un processus de vissage. Chacun de ces processus fait intervenir des actifs industriels, dont les équipements industriels et les contrôleurs. Le plus souvent, chacun des processus implique des actifs industriels qui lui sont propres. Ici, il est considéré que ces deux opérations OP600, OP630 mettent en œuvre les processus de vissage industriels utilisant au moins une des trois machines industrielles décrites précédemment, c’est-à-dire, la première, la deuxième et la troisième visseuse 101, 102, 103. Par exemple, la première opération OP600 comprend une station ST01 de remplissage d’huile. Cette station ST01 comprend une série de processus mécanique, dont par exemple un processus de vissage du bouchon d’huile, mettant en œuvre la première visseuse 101 par exemple. La deuxième opération OP630, liée à la mise en place des tonneaux de roues, comprend quant à elle deux stations, une station de vissage rapide, identifiée comme la station ST01 et une station de vissage au couple, identifiée cette fois comme la station ST02. Chacune de ces stations ST01 et ST02 fait intervenir un processus de vissage industriel. Par exemple, la station ST01 comprend le processus de vissage rapide, mis en œuvre par la deuxième visseuse 102 ici. La station ST02 comprend quant à elle, le processus de vissage au couple souhaité, mis en œuvre par la troisième visseuse 103 précédemment présentée. Ainsi, au fil des opérations OP600, OP630 réalisées par les technologies opérationnelles, dont la structuration a été décrite ci-dessus, les différents processus mis en œuvre par les différents actifs industriels (les machines industrielles notamment), viennent générer des données industrielles, que vient collecter le système 1 de collecte des données. Les technologies opérationnelles (connu sous le terme OT) que renferment l’usine 100 de fabrication et/ou d’assemblage au sein duquel s’applique le système 1 de collecte des données illustré sur la FIG. 1 , sont complétées par des technologies de l’information (connu sous le terme IT). Une fois générées par les capteurs à partir de mesures physiques, les données industrielles existent sous forme numérique et dématérialisée. Elles sont alors gérées par les technologies de l’information. Ces technologies de l’information permettent le contrôle, la gestion et/ou la sécurisation des données industrielles. Ainsi, suite à leur collecte par les contrôleurs 111, 112, 113 associés aux différentes visseuses 101, 102, 103, les données industrielles sont acheminées jusqu’à un serveur informatique associée à au moins une base de données, afin de pouvoir y être stockées et exploitées. Différents exemples d’exploitation des données industrielles ainsi collectées sont décrits en parallèle d’une méthode de collecte des données dans la suite de la description. Par exemple, les données industrielles sont acheminées jusqu’à un serveur, plus spécifiquement un serveur à distance 140, ici, une plateforme Cloud (ou serveur Cloud) aussi appelé plateforme Nuage en français, et en utilisant des outils de l’informatique en nuage (plus connu sous le terme anglo-saxon de Cloud computing ). Néanmoins, l’utilisation d’un serveur informatique et au moins une base de données implémentés de manière local à l’usine 100 est également possible dans d’autres modes de réalisation du système 1 de collecte des données industriels ici décrit. D’après la FIG. 1 , le Cloud comprend un ensemble d’infrastructures physiques, dont des serveurs informatiques à distance, configurés pour communiquer avec des infrastructures informatiques propres à chacune des usines 100, via un réseau informatique, par exemple un réseau internet privé. Ainsi, des données industrielles peuvent être échangées entre l’usine 100 et le serveur à distance 140. Par exemple, dans le premier mode de réalisation, les contrôleurs 111, 112, 113, notamment le premier contrôleur, le deuxième contrôleur et le troisième contrôleur, associés respectivement à une des trois visseuses 101, 102, 103, sont reliés à serveur local 120 implémenté dans l’usine 100. Une usine 100 peut présenter une multitude de serveurs locaux 120. Ici, un seul serveur local 120 est représenté sur la FIG. 1 . Ce serveur local 120 est ainsi représenté sur la FIG. 1 . Un protocole de communication entre le serveur local 120 et les contrôleurs 111, 112, 113 reliés aux visseuses 101, 102, 103 dépend du contrôleur 111, 112, 113 et/ou de la visseuse 101, 102, 103. Il peut s’agir par exemple d’un protocole Modbus TCP/IP, FTP, TGC, OPC DA ou de protocoles propriétaires, en fonction par exemple du logiciel installé sur le contrôleur. Du fait de l’hétérogénéité dans les machines industrielles, ces protocoles de communication variés ne sont pas nécessairement interopérables. Ce serveur local 120 est par exemple un serveur OPC UA, en particulier, un serveur OPC UA avec un pilote de communication. On parle notamment ici d’un serveur OPC UA appelé par exemple serveur UDC, pour Unified Data Collector . Ce serveur local 120 est ensuite connecté à un agrégateur local 130, par l’intermédiaire d’un réseau, par exemple un réseau local. En particulier, l’agrégateur local 130 correspond ici, à un serveur central de l’usine 100. Ce serveur central est chargé de l’agrégation des flux de communication provenant des différents serveurs UDC situés en aval. Par ailleurs, l’agrégateur local 130 a également pour rôle de s’abonner, via des règles d’abonnement, aux variables d’intérêt, afin de les acheminer vers le serveur à distance 140. Ces variables d’intérêt, c’est-à-dire, les données collectées, sont ensuite exploitées depuis le serveur à distance 140, selon diverses modalités d’exploitation de la donnée. Ainsi, grâce aux règles d’abonnement définies sur l’agrégateur local 130, seules les données effectivement nécessaires à un ou des client(s) sont remontées au serveur à distance 140. En pratique, l’abonnement ou la souscription à des données d’intérêt est prise en charge par le protocole OPC UA. L’agrégateur local 130 de chacune des usines 100 est connectée à la plateforme Cloud ou serveur à distance 140 décrit précédemment. Notamment, cette connexion est réalisée au moyen du réseau internet, par exemple via des moyens fibrés (e.g. fibres optiques). En effet, une quantité de donnée industrielle collectée à l’aide du système 1 ainsi décrit atteint des volumes conséquents, même à l’échelle d’une usine 100. Par exemple, environ 800 gigaoctets de données industrielles sont collectés par jour. L’ensemble du système 1 décrit, comprenant à la fois une partie opérationnelle, liée à la mise en œuvre de processus ou procédés industriels, et une partie informatique, liée à l’infrastructure nécessaire à la collecte des données industrielles générés au sein des processus, permet la mise en œuvre de la méthode de collecte des données industrielles. Cette méthode de collecte des données industrielles vise notamment à rendre interopérable les données industrielles collectées dès leur acheminement vers la plateforme Cloud, en les standardisant dès leur collecte. Cette interopérabilité présente plusieurs avantages techniques. En effet, l’interopérabilité par standardisation permet de rendre facilement échangeables des données industrielles collectées sur un divers panel de machines industrielles, présentant chacune des protocoles de communication, et/ou formats de données différents. De plus, l’interopérabilité représente un gain en qualité des données récoltées, puisqu’une traduction postériori de celles-ci, pour les rendre compatibles avec un système et/ou un appareil et/ou un protocole n’est pas nécessaire. Or, ces traductions ou transferts, engendrent une corruption de la qualité des données collectées. Ensuite, l’acheminement, le stockage et un accès aux données industrielles sur la plateforme Cloud ou serveur à distance 140 est facilité. En effet, l’acheminement des données collectées selon la méthode proposée se fait en des points d’accès ou point de collecte de la donnée limités. Une organisation hiérarchisée des données industrielles grâce aux modèles de données 3, permet de venir collecter les données industrielles sur des point de collecte en amont, de manière à collecter simultanément toutes les données industrielles en aval. Dit autrement, des données présentant des liens logiques entre elles peuvent être collectée simultanément. Cela permet une augmentation importante de la quantité de données pouvant être collectée par un industriel au sein de ses usines 100. Un débit de collecte des données, est également augmenté, permettant par exemple, une exploitation en temps réel des données, et/ou un suivi temporel plus fin des différents processus industriels. De plus, la méthode permet de réduire d’éventuelles redondances autour des données, ce qui se traduit par une diminution des espaces mémoires de stockage nécessaires au sein de la plateforme Cloud. Par ailleurs, des coûts d’accès des clients, c’est-à-dire des exploitants des données industrielles collectées, à la plateforme Cloud se retrouve avantageusement réduit grâce à la mise en œuvre de la méthode. La méthode de collecte des données industrielles est illustrée sur la FIG. 2 . Cette méthode comprend une étape préliminaire S0, une première étape S1, une seconde étape S2 et une troisième étape S3. Des détails de la mise en œuvre des étapes S0 et S1 sont représentées sur la FIG. 4 . Notamment, des liens sont établis avec les éléments physiques du système 1 de collecte des données et/ou des moyens logiciels utilisés. A des fins de description, cette méthode est appliquée dans un premier mode de réalisation, à la collecte de données industrielles sur un des processus de vissage industriels décrits précédemment. En particulier, on s’intéresse ici à la collecte des données industrielles liées à la première opération OP630 de mise en place des tonneaux de roues, et aux deux stations comprises dans cette opération. Ces deux stations mettent en œuvre la deuxième visseuse 102 et la troisième visseuse 103. La méthode proposée afin de collecter les données industrielles de manière organisée et standardisée repose sur l’implémentation technique au sein des infrastructures informatiques de l’industriel d’un modèle de données 3. Comme le montre la FIG. 3 , ce modèle de donnée 3 permet de présenter les données industrielles sous une forme définie, notamment en les hiérarchisant. Le modèle de données 3 structure donc les données industrielles de manière optimisée, en vue de leur collecte et leur stockage sur la plateforme Cloud. Cette méthode consiste donc à appliquer le modèle de données au sein d’une usine 100 ou d’un parc d’usines 100, à travers le système 1 de collecte des données. Ce modèle de données 3, une fois instancié physiquement, c’est-à-dire programmé de manière à en spécifier les paramètres tels que le type et/ou une adresse, au sein de l’infrastructure informatique du parc d’usines 100 du fabricant industriel, permet la collecte des données industrielles de manière structurée, standardisée, et contextualisée. Pour cela, l’instanciation physique du modèle de données 3 au sein de l’infrastructure informatique rend compte de règles établies en amont pour structurer une chaîne numérique de modélisation. Cette chaîne numérique de modélisation assure une transformation d’un modèle de données conceptuel 30 au modèle de données physique 32, c’est-à-dire le modèle de données 3 instancié physiquement au sein de l’infrastructure informatique. La chaîne numérique de modélisation présente deux fonctions, une fonction de conception des modèles, à travers le modèle conceptuel et un modèle logique, puis une fonction d’implémentation des modèles, à travers un modèle physique. Ce dernier, étant instancié sur la structure informatique, permet la mise en œuvre de la méthode 2 proposée. La fonction de conception des modèles établit un ensemble de règles conceptuelles, tenant compte des processus et/ou station et/ou opération, et leur intégration au sein d’usines 100. Ces règles tiennent également compte des opérateurs et des équipes d’opérateurs mettant en œuvre ou pilotant ces processus et/ou stations et/ou opérations. Pour cela, la fonction de conception des modèles présente deux aspects, l’aspect conceptuel (à travers le modèle de données conceptuel 30) et l’aspect logique (à travers le modèle de données logique 31). Etablir le modèle de données conceptuel 30, ou modèle conceptuel constitue une étape préliminaire S0 de la méthode, puisque le modèle de données conceptuel 30 affecte l’implémentation technique du modèle de données 3 instancié au sein des technologies informatiques. Le modèle de données conceptuel 30 permet d’établir un modèle de données 3 tenant compte à la fois des spécificités de chaque processus et/ou stations et/ou opération. D’autre part, le modèle de données conceptuel 30 réduit à un minimum des variables nécessaires au modèle de données 3. Ces variables permettent pour au moins une partie d’entre elles de représenter différentes données industrielles, qui sont parfois communes sur plusieurs processus et/ou stations et/ou opérations, comme par exemple, une variable de vitesse de rotation, ou une variable d’angle de vissage. Ainsi, dans l’étape préliminaire S0, il est défini une logique ou norme de structuration des données industriel. Celle-ci répond à une vision orientée processus, plutôt qu’à une vision orientée équipement. Cette norme de structuration détermine une structure hiérarchique des données industrielles collectées, et cette structure est conservée jusqu’à l’acheminement des données industrielles au serveur à distance 140, i.e. la plateforme Cloud. La gestion de la hiérarchisation des données industrielles à l’échelle du serveur local 120 et de l’agrégateur local 130 est prise en charge par le protocole OPC UA. En effet, ce protocole lie les différents nœuds grâce à des informations de référence, et des identifiants. Ici, il est donné au terme « nœud », le sens technique en usage dans le protocole OPC UA. Notamment, les nœuds correspondent par exemple à des objets, notamment des à des variables, des classes, des références. Chaque nœud correspond à une brique d’information de base au sein de ce protocole OPC UA. Entre l’agrégateur local 130 et le serveur à distance 140, la conservation de la structure hiérarchique des données est faite par exemple grâce à un système de préfixage. En effet, un préfixage des variables (i.e. des données industrielles collectées) permet de conserver la hiérarchie établie dans le protocole OPC UA au sein du protocole MQTT mise en œuvre au sein du serveur à distance 140. La norme de structuration reprend une organisation similaire à celle utilisée dans la partie opérationnelle, décrite précédemment. Ainsi, les données industrielles sont organisées de la manière suivante, d’un point de vue conceptuel : Une troisième classe, correspondant à une classe opération ou type opération, permet de représenter des opérations, comme par exemple la première opération OP600 ou la deuxième opération OP630. Cette classe opération est liée par un lien logique de hiérarchie à une deuxième classe ou plusieurs deuxième classes (ou type) représentant des stations ST01 ou ST02. Chacune des classes stations est ensuite liée à une troisième classe ou plusieurs troisièmes classes, correspondant à des classes processus, qui une fois instanciées, vont correspondre par exemple, à l’un des processus de vissage décrit précédemment. Enfin, chaque classe processus est lié, par un lien logique de hiérarchie, à une ou plusieurs classes de phase. Ces classes ou types définissent des modèles sur la base desquels des objets sont instanciés. Chacune de ces classes hiérarchiquement organisées par des liens logiques entre elles, est ensuite rattachée à différentes données complémentaires, représentant par exemple des machines industrielles ou des outils, des informations sur une pièce fabriquée, une localisation, ou encore des contrôleurs 111, 112, 113. La hiérarchisation des classes, afin de reproduire la hiérarchie existante sur les procédés industriels. Cette hiérarchisation des classes permet ensuite de hiérarchiser des objets instanciés sur la base de ces classes. La transformation de cette structure hiérarchisée conceptuelle à une instanciation physique est décrite dans la suite. Par ailleurs, durant cette étape préliminaire S0 de conception du modèle de données 3, il est également instauré des règles de nommage standardisées pour les variables ou données collectées. Cet effort de standardisation des noms de variables a pour effet technique de contribuer à l’interopérabilité des données techniques collectées, et ainsi de faciliter leur exploitation par des clients accédant au serveur à distance 140 (plateforme Cloud). De plus, cet effort permet de limiter d’éventuelles redondances de variables, ce qui représente un gain en termes de coût d’accès pour les clients. Notamment, ces derniers ne souscrivent ou ne s’abonnent (i.e. sont connectés) qu’à des variables spécifiquement choisies, comme il est d’usage dans le fonctionnement de tels serveurs à distance 140. La souscription (ou abonnement) des clients est rendue plus aisées grâce à la standardisation des noms de variable. L’effort de standardisation se traduit par l’établissement d’un dictionnaire unique de variables 40. L’établissement d’un tel dictionnaire unique de variables 40 nécessite des ateliers de modélisation. Ces ateliers de modélisation réunissent des experts en modélisation et des experts en processus industriels, qui ont pour fonction de sélectionner et de formaliser les variables à inclure dans le modèle de données physique 32 instancié. Ces variables sélectionnées doivent répondre aux besoins des clients de la donnée, c’est-à-dire des exploitants des données industriels collectés suivant cette méthode 2. Ces variables sélectionnées sont ensuite ajoutées à une liste de variables préexistantes. Durant les ateliers de modélisation, la formalisation des variables consiste à trouver un nom pour chaque variable à intégrer à un modèle de données 3. Ce nom de variable doit être unique, et aisément compréhensible pour l’exploitation ultérieur de la variable. L’utilisation de préfixe permet par exemple de clarifier un contexte autour de la variable considérée. Afin d’éviter la duplication des noms de variable, il est également vérifié que le nom de variable choisi n’existe pas déjà au sein du dictionnaire unique de variables 40. Ainsi, les opérations OP600, OP630, comprenant des processus de vissage, sont décrites par des variables spécifiques à ce type de processus, comme par exemple les variables correspondant à un couple ( Couple ), un angle ( Angle ), clef d’identification ( Idkey ) numéro de série de l’outil ( ToolSerialNumber ), dernière date de calibration ( LastCalibrationDate ), etc. D’autres variables sont communes à d’autres opérations et/ou stations et/ou processus, et sont donc réutilisées. Par exemple, les variables Speed , Tolerance , Cycle , sont partagés entre les processus de vissage et les processus de fraisage. Le nommage de ces variables communes est défini durant les ateliers de modélisation, en particulier, lors de de la formalisation des variables. Par ailleurs, des préfixes et des suffixes peuvent être ajoutés aux noms des variables sélectionnées, afin de permettre la contextualisation des données. Cette contextualisation des données est redondante avec la structuration hiérarchique, qui assume également ce rôle. Cependant, cette contextualisation des données via des règles de nommage spécifiques permet avantageusement d’assurer la conservation de la hiérarchie imposée aux données collectées par le modèle de données, même lorsque le protocole utilisé ne le permet pas, par exemple au niveau du serveur à distance 140. Par exemple, la variable sélectionnée Speed peut être suffixés et/ou préfixée par les préfixes et/ou suffixes suivants : CMD (pour des variables de commande), Min , Max , Final (pour des variables correspondant à une valeur finale mesurée), Act (pour des variables correspondant à une valeur actuelle), etc. Ces règles de préfixage et/ou suffixage présentent l’intérêt de pouvoir opérer une agrégation des données, même en amont de l’application de la méthode 2. Par exemple, pour connaître des variables issues d’un outil appartenant à un processus spécifique, les variables peuvent être préfixées de la manière suivante : Station_ _Process_ _Tool_ _ID, où les valeurs sont substitués par des codes d’identification des processus, des stations et des opérations. Ce préfixage des variables collectées permet avantageusement de conserver la structure hiérarchique établie, et notamment les dépendances entre les différentes variables, afin de les contextualiser. La conception du modèle de données 3, ayant lieu dans une étape préliminaire S0 de la méthode 2 proposée, comprend également l’établissement des règles de modularité. Ces règles de modularité, une fois instanciées et appliquées au sein de la méthode 2 de collecte des données, facilitent la mise à l’échelle de celle-ci. En effet, les règles de modularité permettent de limiter le nombre de type (c’est-à-dire, de classe) de modèles de données 3 différents. Lors de la conception d’un modèle de données 3 pour une opération choisie, les variables, notamment les variables sélectionnées et formalisées lors des ateliers de modélisation, sont classées selon deux catégories distinctes. On distingue alors dans le modèle conceptuel deux types de variables : des variables génériques et des variables spécifiques. Les variables génériques sont des variables réutilisables pour d’autres processus, ou d’autres stations, ou d’autres opérations. Typiquement, les variables utilisées pour le remplissage d’un carter d’huile d’un moteur (vitesse de remplissage, volume maximum…) peuvent être réutilisées pour le remplissage de tout autre contenant par tout autre liquide (carburant, liquide de refroidissement…). Les variables spécifiques, à l’inverse, sont spécifiques à un processus, une station, ou à une opération, et ne peuvent être utilisées ailleurs. Par exemple, dans le cadre du processus de vissage, les variables telle que l’angle ou la température sont applicables à de nombreux autres processus. A l’inverse, des variables, telles que celles liées à la visseuse sont spécifiques au processus de vissage, et ne peuvent pas être réutilisées ailleurs. Afin de faciliter davantage la modularité, il est également proposé dans l’étape préliminaire S0 de mise en place des modèles de données, de diviser ces derniers en briques, ces briques correspondant soit à des briques générique, soit à des briques spécifiques. Ces briques contiennent des variables issues du dictionnaire unique des variables, et on distingue des briques spécifiques, contenant des variables spécifiques, et des briques génériques, contenant des variables génériques. Les variables utilisées au sein de plusieurs processus sont incluses dans des briques génériques, tandis que les variables spécifiques à un processus sont intégrées dans des briques spécifiques. Cette répartition des variables selon ces deux catégories permet avantageusement de réduire la complexité de modélisation des données, en particulier, la création de nouveaux modèles de données. En effet, les variables nécessaires pour la modélisation d’un processus industriel sont regroupées selon des catégories réutilisables pour d’autres processus industriels présentant des similarités. Ainsi, pour modéliser un processus industriel au sein d’une usine 100, un modèle de données est créé par agglomérations de briques génériques et de briques spécifiques. De plus, un accroissement d’échelle est plus facile à opérer, puisque pour construire un nouveau modèle de données, pour de nouveaux processus, des briques déjà établies peuvent être utilisées. De manière avantageuse, les modèles de données 3 sont établis à partir des briques spécifiques et/ou génériques, celles-ci contenant des variables qui proviennent d’un dictionnaire unique de variables 40, et sont organisées hiérarchiquement en fonction d’une structure orientée processus, offrent une grande modularité. Ainsi, avantageusement, une grande diversité de processus industriels peut être représentés par des modèles de donnés établis suivant la chaîne numérique de modélisation. Un nombre de type de modèles différents est néanmoins limité, ce qui permet de réduire le besoin de créer de nouveaux modèles de données pour tenir compte de nouveaux processus, mais aussi d’avoir des modèles de données plus facile à maintenir et/ou à actualiser, et plus facile à mettre à l’échelle. Par exemple, pour modéliser la première et la deuxième opérations OP600, OP630, des briques génériques, partagés par les deux classes opérations correspondantes, sont les suivantes : Une brique contenant les variables d’une librairie OPC UA, une brique interne à l’industriel contenant une librairie de variables communes à tous les processus de l’industriel, une brique dit « Atout industriel » ou actif industriel, liée aux usines 100 par exemple véhicules et mécanique. Ensuite, la classe opération associée à la première opération OP600 présente des briques qui lui sont propres, c’est-à-dire des briques spécifiques. Par exemple des briques contenant des variables liées au moteur, notamment, au remplissage d’huile. De même, la classe opération associée à la seconde opération OP630 présente des briques spécifiques, telles qu’une brique liée au vissage. Une fois sa forme conceptuelle établie, le modèle de données 3, obéissant aux règles conceptuelles définies plus hauts, est instancié sur les infrastructures, pour la mise en œuvre de la méthode de collecte de données. L’instanciation comprend l’intégration des modèles dans l’infrastructure informatique, la définition de types des variables et la connexion des variables aux adresses physiques correspondantes sur les différentes machines industrielles, qui constitue la partie opérationnelle. Le modèle de données physique 32 mis en œuvre présente l’avantage de remédier à la pluralité des protocoles de communication utilisés au sein de la partie opérationnelle, et permet d’acheminer les données industrielles collectée par les contrôleurs 111, 112, 113, à la plateforme forme, sous un format unique, qui est celui du protocole OPC UA. Ce protocole, déjà évoqué précédemment, permet de conserver la sémantique et la structure hiérarchique des objets, notamment des variables (i.e., des nœuds, dans le vocabulaire technique associé à ce protocole OPC UA). Le passage d’un modèle de données conceptuel 30 à un modèle de données logique 31, dans un format compréhensible par un système informatique est fait à l’aide d’un standard, via un outil de modélisation. Par exemple, le format choisi correspond par exemple au format XLM, et le standard ou la norme correspond à la norme de modélisation OPC UA. De manière alternative, dans d’autres modes de réalisation, d’autres standards peuvent être adoptés, bien que les standards existants dans l’état de la technique s’avèrent pour l’instant, moins optimisés que le protocole OPC UA. L’outil de modélisation correspond quant à lui à un outil informatique permettant d’implémenter les modèles de données conceptuel 30 sur le serveur local 120. Dit autrement, cet outil informatique permet de définir les types (ou classes) nécessaires dans le protocole OPC UA, comme par exemple les classes opérations, les classes stations, et les classes processus. Durant cette étape de mise en place du modèle de données logiques 31, l’outil de modélisation définie également des liens hiérarchiques entre les classes établies. Par exemple, il est décidé d’imposer une règle selon laquelle une classe processus est nécessairement contenue dans une classe station, et qu’une classe station est nécessairement contenue dans une classe opération. L’outil de modélisation désigne par exemple un logiciel informatique de modélisation et de conception UML (pour Unified Modeling Language en anglais) commercial. Ainsi, pour chaque modèle de données conceptuel 30, correspondant par exemple à un processus spécifique, un modèle logique est créé. Dans ce modèle logique, les variables, leur type, les structures sont établies. Par exemple, dans la première station ST01 de la première opération OP630, la deuxième visseuse 102 est utilisée dans un processus. Ainsi, dans le modèle logique, le processus, ici de vissage, est défini en tant que classe. Cette classe comprend des attributs (ou variables), tel qu’un identifiant, un couple, et une vitesse de rotation. Les attributs présentent chacune un type (par exemple, une chaîne de caractère ou string en anglais, un flottant ou float en anglais…), et une ou des valeurs (flottant) pour l’identifiant, le couple et la vitesse de rotation respectivement. Les variables utilisées pour le modèle de données logique 31 sont notamment issues d’une base de données des variables, reprenant le dictionnaire unique des variables 40 établi précédemment. Au sein de cette base de données informatiques, par exemple, mémorisée dans un espace mémoire du serveur local 120, les variables préexistantes sont mémorisées et classées en variables génériques et spécifiques. Ces variables sont agrégées en briques modulables, comprenant des briques spécifiques et des briques génériques. Le modèle de données logiques 31 est construit par assemblage de ces briques, en fonction des besoins de modélisation de chaque processus industriel. De la même manière, une classe station est définie, et comprend des variables présentant un type. Par exemple, la classe station comprend ici des variables liées à une pièce fabriquée, par exemple, un identifiant unique, sous la forme d’une chaîne de caractère. Idem pour les opérations OP600, OP630, également représentées sur le serveur local 120 par une classe opération, comprenant des variables, comme par exemple une variable de localisation, sous la forme d’une chaîne de caractère. Afin de conserver de conserver la norme de structuration définie pour le modèle de données conceptuel 30 dans le modèle de données logiques 31, la hiérarchie conceptuelle établie entre les classes processus, les classes stations et les classes opérations est conservée, afin de refléter l’organisation des technologies opérationnelles. Pour cela, des liens logiques sont créés entre les classes opérations, les classes stations et les classes processus. Par exemple, un lien logique possible est la notion de hiérarchie, comme il est d’usage dans le protocole OPC UA. Ainsi, il est défini dans le serveur local 120 qu’une classe processus est liée à une classe station, la classe station étant liée elle-même à une classe opération. Dans le protocole OPC UA, ces liens logiques de hiérarchie entre les nœuds, comprenant notamment les classes, les objets, variables etc., sont gérés par le biais d’information de référence et des identifiants liant les nœuds les uns aux autres. Le modèle logique est implémenté dans l’infrastructure informatique de l’usine 100, notamment au sein du serveur OPC UA dans le premier mode de réalisation. En vue de collecter des données industrielles, la première étape S1 de la méthode 2 comprend une instanciation du modèle de données conceptuel 30 sur l’infrastructure informatique du fabricant industriel. Dit autrement, l’instanciation du modèle consiste notamment à faire un lien entre des variables du modèle de données logique 31 et une adresse physique correspondant à ces variables. Une première sous étape S11 consiste à tenir compte des contraintes physiques ou matérielles . Les variables, dont le type et la structure ont été définis dans le modèle logique, sont ainsi associées à leur adresse physique, c’est-à-dire l’adresse physique de la variable correspondante allouée dans une mémoire du contrôleur. Cette adresse physique, aussi appelée ici adresse physique machine indique un emplacement où est stockée une variable dans une machine d’une marque et d’un modèle spécifique. Ainsi, pour un même procédé industriel, donc modélisé par un même modèle de données 3, une instance peut être différente d’une marque de machine industrielle à une autre, car les adresses physiques peuvent être différentes. Afin de réaliser l’adressage, c’est-à-dire l’association entre une variable et son adresse physique afin d’aboutir à l’instanciation du modèle de données physique 32 sur le serveur local 120, des outils logiciels mise en œuvre par l’infrastructure informatique de l’industriels sont ici utilisés. C’est cet adressage, reliant physiquement une variable organisée et contextualisée selon une structure ordonnée par le biais du modèle de données conceptuel 30 et du modèle de données logique 31, avec son adresse physique, qui rend possible la remontée de la donnée depuis les machines industrielles de manière structurées par exemple par le protocole OPC UA. La première étape S1 fait intervenir un outil logiciel de configuration des actifs ou des moyens industriels. En pratique, lorsqu’un modèle de données logiques 31 est défini, il est chargé dans un projet qui est exporté sur le serveur local 120, c’est-à-dire le serveur OPC UA. L’outil logiciel de configuration des actifs vient aider à l’instanciation du modèle de données logique 31, en le transformant en modèle de donnée physique 32, en tenant compte des exigences matérielles présentes au sein de l’usine 100. Lors de l’instanciation, l’outil logiciel de configuration des actifs est utilisé afin de sélectionner le type de modèle de données à charger sur le serveur local 120, quel protocole utiliser, etc. Cet outil logiciel de configuration des actifs crée pour chacun des modèles associés à une opération, des pilotes de configuration 41. Ces pilotes de configuration 41 gèrent le mapping d’adressage (ou mappage d’adresses d’après le terme francophone). Cet outil logiciel de mappage d’adresse réalise de manière automatique le mappage des variables issues des modèles de données et les adresses physiques sur les machines industrielles. En l’absence de ces pilotes, un développement spécifique pour chaque type de processus doit être réalisé. Ces pilotes de configuration 41 connectent, pour un équipement spécifique utilisé dans un des processus d’une opération, les variables du modèle instancié sur le serveur local 120 (i.e. le serveur OPC UA), et l’adresse physique des variables requises. Ces pilotes de configuration 41 sont spécifiques aux équipements industriels, par exemple à leur type, leur marque, leur modèle, etc. Ils permettent notamment de réaliser automatiquement la connexion entre les variables et les adresses physiques. Pour cela, les pilotes de configuration 41 s’appuient sur une bibliothèque informatique 42 contenant l’information d’adressage pour les différents équipements industriels de la partie opérationnelle. Cette bibliothèque informatique 42 est également appelée base de données des adresses physiques. Un contenu de cette base de données des adresses physiques répertorie notamment l’information d’archivage pour différentes marques, modèles, etc…, des différents équipements industriels de la partie opérationnelle. Le contenu est ainsi établi en fonction des équipements industriels de l’usine 100. A partir de cette bibliothèque informatique 42, le pilote de configuration 41 renvoie un script d’adressage. Ce script d’adressage contient pour une variable recherchée sur un équipement donné, une adresse physique d’allocation. Par exemple, dans le système 1 décrit précédemment, la bibliothèque informatique 42 contient les informations d’adressage, pour la première visseuse 101, la seconde visseuse et la troisième visseuse 103. Le gestionnaire de valeur 41, pour la première, la deuxième et la troisième visseuse 101, 102, 103, indique pour chacune des variables, l’adresse physique associée (laquelle dépend du contrôleur utilisé dans chaque visseuse). Par exemple, pour la première visseuse 101, le gestionnaire de valeur 41 renvoie entre autres, une adresse physique 1A de la variable identifiant, une adresse physique 2A de la variable couple, une adresse physique 3A de la variable vitesse de rotation. Il en va de même pour la deuxième visseuse 102, où les adresses physique 1B, 2B, et 3B sont renvoyés, et la troisième visseuse 103, avec les adresses physiques 1C, 2C et 3C. Enfin, le modèle de données 3 est instancié sur le serveur local 120, sous sa forme physique. En particulier, dans le mode de réalisation décrit, et en adéquation avec le système 1 détaillé précédemment, le modèle de données 3 est instancié sur le serveur OPC UA local, situé en amont de l’agrégateur de données 130. La première étape S1 d’instance comporte donc une seconde sous-étape S12 se concentrant sur l’instanciation du modèle dans le serveur OPC UA. Cette étape consiste à créer une instance du modèle de données 3 correspondant à la machine sur laquelle on collecte de la donnée. En pratique, cela consiste par exemple à instancier des objets correspondants aux classes opération, station et processus pour le processus industriel concerné. Cette instanciation se fait au moyen d’un outil logiciel. Ce dernier est ici appelé outil logiciel de configuration 50 du serveur, ou configurateur d’instance. L’outil logiciel de configuration 50 du serveur réalise notamment des paramétrages, tels qu’un choix de localisation, un choix de modèle de donnée en fonction de l’opération/station/processus à modéliser, ainsi qu’un choix des pilotes de configuration 41 selon les machines industrielles mise à l’œuvre dans l’opération à modéliser. Par choix de localisation, il est notamment entendu une localisation géographique de l’usine 100. Cet outil logiciel de configuration du serveur local 120 prend en entrée un modèle de données physique 32, c’est-à-dire, le modèle de données logique 31, dont les adresses physiques des variables sont indiquées par l’intermédiaire des pilotes de configuration 41 pré-enregistrées, ainsi que de scripts d’adressage, ou scripts de connexion. Ces scripts de connexion ou script d’adressage sont générés à partir de la bibliothèque informatique 42 contenant l’information d’adressage. L’outil logiciel de configuration 50 du serveur local 120 génère l’instanciation du modèle de données 3 sur l’infrastructure informatique du fabricant industriel, plus particulièrement, l’instanciation sur le serveur local 120 à une usine 100 donnée. L’instanciation est faite sur le serveur local 120, ici, un serveur OPC UA, qui vient donc charger les modèles de données et permettre la collecte des données selon le protocole OPC UA correspondant. Ce serveur OPC UA vient alors collecter de manière structurée, les données sur les différents contrôleurs 111, 112, 113 associés aux différents équipements. Des fichiers (ici, deux) sont générés lors de l’instanciation, pour une opération donnée. Cette instanciation est opérée en amont de la collecte des données, et demeure fonctionnelle tant que l’opération pour laquelle est instancié le modèle de donnée ne subit pas de modification. Par ailleurs, lors de l’instanciation, une classe est personnalisée selon les besoins du processus en question. Par exemple, une classe processus, correspondant à un processus de vissage peut être instanciée dans une opération correspondant au vissage du bouchon d’huile, puis la même classe correspondant à un processus de vissage peut être instanciée pour une autre opération, par exemple une opération de vissage des tonneaux de roues. Il en résulte deux instances de classe personnalisées afin de collecter des données sur deux opérations distinctes, mais présentant des similarités. Les fichiers générés par l’outil logiciel de configuration 50, aussi appelés fichiers d’instanciation 51, sont exploités par le serveur local 120 pour la collecte des données, faisant l’objet de la deuxième étape S2 de la méthode 2. Pour les opérations d’un fabricant industriel, ces fichiers d’instanciation 51 partagent tous un même format et sont communiqués au serveur local 120 via un même standard de communication. Ici, les fichiers d’instanciation 51 sous tous au format XLM. Dans cet exemple, un premier fichier d’instanciation est désigné sous le terme NodeSet d’instance, selon la dénomination courante dans le protocole OPC UA. Ce premier fichier d’instanciation contient la configuration de l’instance du modèle de données de la machine sur laquelle on collecte la donnée. Ce premier fichier d’instanciation est chargé par le serveur local 120, ici le serveur OPC UA. En particulier, ce fichier de NodeSet d’instance utilisé par le serveur OPC UA, spécifie la structure est des caractéristiques de données. Ceci facilite l’interopérabilité et la communication entre différents dispositifs et applications, en standardisant la représentation des informations. Le second fichier est un fichier de configuration permettant de connecter physiquement les variables instanciées dans le serveur local 120 et les machines industrielles. La connexion se fait par l’intermédiaire de protocoles de communication propres à chacune des machines industrielles, et via des moyens de connexion adaptés. Par exemple, dans le cas du processus de vissage, la première visseuse 101 est connectée au premier contrôleur. Celui-ci est ensuite connecté au serveur local 120, comme décrit dans pour le système 1 associé. La deuxième étape S2 de la méthode comprend la collecte des données industrielles à proprement dite. Cette deuxième étape S2 est illustrée par l’exemple de la seconde opération OP630, de mise en place des tonneaux de roues. Le modèle de données 3 d’un tel exemple a été décrit précédemment. Cette seconde opération OP630 comprend une première et une deuxième station ST01, ST02, chacune de celles-ci inclue un processus de vissage, utilisant néanmoins deux machines industrielles différentes. Les deux stations ST01, ST02 interviennent successivement dans le temps. Une pièce, par exemple, ici, un véhicule quasi-assemblé, passe de la première à la seconde station par l’intermédiaire d’une luge, c’est-à-dire une plateforme sur laquelle repose le véhicule. Cette plateforme se déplace de manière automatisée d’une station à l’autre. Ainsi, à la première station ST01, intervient la seconde visseuse 102, dans le cadre d’un processus de vissage. Les données sont ensuite collectées suivant le modèle de données physique 32 instancié, permettant de hiérarchiser les données acquises suivant ces modèles lors de leur remontée au serveur local 120. En effet, dans le protocole OPC UA, la hiérarchisation des objets selon une arborescence est gérée par des références liant les objets les uns aux autres. Cette arborescence de données comporte par exemple des embranchements définissant des niveaux de la structure hiérarchique. Ainsi, il est possible dans l’architecture OPC UA, de venir collecter les données industrielles au niveau des embranchements, qui correspondent à des points de collecte de la donnée. Ces points de collecte de la donnée correspondent par exemple à des zones mémoire. Sur un point de collecte donnée, des variables, logiquement liées par une relation hiérarchique définie par le modèle de données 3, sont combinées selon un ensemble ou un agrégat, afin de pouvoir être collectées simultanément depuis une zone mémoire correspondante. Les données collectées sur un même point de collecte de la donnée, sont des données dépendantes hiérarchiquement d’un même objet, i.e., d’une même branche de l’arborescence. Dit autrement, les données ou variables combinées afin de former l’ensemble sont liées hiérarchiquement les unes aux autres. Ici, les données industrielles sont collectées selon trois niveaux ou point de collecte : un niveau ou point de collecte correspondant à l’opération, un niveau ou point de collecte correspondant à la station et un niveau ou point de collecte correspondant au processus. Par point de collecte correspondant à une opération ou une station, ou un processus, il est entendu une zone mémoire combinant les variables dépendantes d’une classe opération, ou d’une classe station, ou d’une classe processus donnée. Dit autrement, ces variables qui sont combinées en vue de leur collecte, sont celles contenues au sein d’une même classe. Ainsi, des données associées à un point de collecte ou niveau opération, contenant notamment des données liées aux variables contrôleur, moyen de production, et localisation géographique, sont remontées au serveur local 120, par l’intermédiaire des moyens de connexion dédiés. Notamment, cette donnée peut être collectée régulièrement, par exemple dès qu’elle change de valeur. La collecte et le stockage des données industrielles se fait sous un format unique, par exemple, sous un format série temporelle. Des données correspondant au niveau ou point de collecte station sont également remontées au serveur local 120 de la même manière. Une station contient par exemple un objet instancié correspondant à une pièce fabriquée. Cet objet comprend des variables telles que son numéro d’identification unique. La station contient également un objet instancié correspondant à une unité de ressource. Cette unité de ressource représente une alimentation en eau, et comprend ainsi des variables telle que le débit et la température de l’eau. Enfin, une donnée liée à un niveau ou point de collecte processus est remontée au serveur local 120. Ici, le processus de vissage, comprend les variables suivantes : identifiant, couple, vitesse de rotation. Les adresse physique des différentes variables étant connues du serveur, les variables sont collectées de manière organisée aux adresses indiquées, et organisées selon les nœuds. Ainsi, les données collectées sont organisées, contextualisé, mais également interopérables. Ces données sont remontées à un rythme régulier, par exemple en fonction des performances du protocole utilisé ou langage de communication utilisé (interrogation périodique, notification automatique sur changement d’état provenant du contrôleur sur lequel on collecte de la donnée) ou dès qu’un changement de valeur est détecté. Les données remontées sont associées à une information temporelle par le serveur local 120, synchronisé sur un serveur de temps. Une fois les différents processus de la première station exécutées, la luge (ou plateforme de déplacement) déplace le véhicule automobile jusqu’à la deuxième station. Là aussi, des données industrielles sont collectées lors de l’exécution des processus. Notamment, pour le processus de vissage opéré par la troisième visseuse 103, les données industrielles suivantes sont remontées, toujours selon les points de collecte définis : - Une donnée liée à un point de collecte opération, contenant notamment des données liées aux variables contrôleur, moyen de production, et localisation géographique, est remontée au serveur local 120, par l’intermédiaire des moyens de connexion dédiés, - Une donnée liée au point de collecte station ainsi que des variables correspondant à une pièce usinée, et une unité de ressource, - Une donnée liée au point de collecte processus comprenant les variables suivantes : identifiant, couple, vitesse de rotation. La structure et le contenu du modèle de données 3 est identique par rapport à la première station. Néanmoins, l’adresse physique des actifs industriels diffèrent, ainsi que l’information temporelle. Les données collectées sous la forme de modèle de données 3 sont ensuite acheminées dans une troisième étape S3 depuis le serveur local 120 jusqu’au serveur à distance 140, en passant par l’agrégateur local 130. Comme mentionné précédemment, cet agrégateur local 130 agrège les flux de communication issu du serveur local 120. Par ailleurs, l’agrégateur local 130 gère également des abonnements aux variables d’intérêt, afin de les communiquer aux serveurs à distance. L’agrégateur local 130 permet aussi d’opérer un tri préliminaire des données à envoyer au serveur à distance 140, en ne venant s’abonner qu’aux données requises par les clients de la donnée. En effet, le stockage des données dans le serveur à distance 140 représente un coût de stockage non-négligeable. Ainsi, bien que toutes les données collectées soient acheminées au serveur local 120, c’est-à-dire, le serveur OPC UA, un tri est opéré au niveau de l’agrégateur local 130, afin d’éviter d’inonder le serveur à distance 140 de données non-utilisées par des clients. Ce tri est opéré par le biais des abonnements qui sont définis par des règles d’abonnement, et géré par l’agrégateur local 130. Cependant, la collecte de toutes les données par le serveur local 120 s’avère avantageuse en cas d’apparition d’un nouveau cas d’usage. En effet, l’agrégateur local 130 peut à ce moment-là, s’abonner à de nouvelles variables, puisqu’elles sont déjà existantes, et collectées par les serveurs OPC UA locaux. Par ailleurs, le préfixage des variables collectées selon les règles établies lors de l’élaboration du modèle de données conceptuel 30, permet de conserver la structure hiérarchique définie entre les variables, précédemment prise en charge par le protocole OPC UA. Ainsi, même si le serveur à distance 140 utilise un protocole de communication différent, par exemple, un protocole MQTT, les variables collectées demeurent contextualisées. Des usages ou applications possibles de cette méthode sont multiples. Notamment, et de manière non-limitative, une application de maintenance prédictive, ou de maintenance conditionnelle, une application de traçabilité, ou une application de suivi des performances. Dans un premier mode de réalisation d’usage de la méthode, un cas de contrôle qualité grâce à la méthode 2 de collecte des données proposée est décrite. Dans ce premier mode de réalisation, la méthode est utilisée afin de recueillir à intervalle de temps régulier des données industrielles. Ici, on s’intéresse notamment à la première station de la première opération OP630 décrite précédemment. Le processus de vissage industriel mis en œuvre au sein de la première station ST01 utilise la deuxième visseuse 102. Comme décrit précédemment, le serveur local 120 vient collecter à intervalle de temps régulier, via l’application de la méthode proposée, des données industrielles. En particulier, il s’agit ici des données de vitesse de rotation, mesurées par un capteur de visseuse dédiée. Ces données de vitesse de rotation, horodatées, sont collectées par serveur local 120, agrégées par l’agrégateur 130, avant d’être envoyées au serveur à distance 140. Ces données sont ensuite analysées, notamment grâce à une exploitation sous forme graphique. Un exemple d’une courbe temporelle de la vitesse de rotation mesurée sur la deuxième visseuse 102 est reproduit sur la FIG. 5 . Cette courbe représente pour la deuxième visseuse 102, la valeur de la vitesse moyenne sur plusieurs vissages successivement opérés par la deuxième visseuse 102. Une telle courbe présente durant une plage temporelle, un défaut de vitesse de rotation. Les véhicules automobiles concernées par ce défaut de vitesse de rotation sont aisément identifiables, grâce à la structure appliquée par le modèle de données 3. En effet, les données sont contextualisées, et une information sur la pièce est rattachée à la vitesse, à la station, à l’instrument etc. Il est ainsi aisé d’opérer facilement un suivi des véhicules concernés par le défaut de vitesse de rotation. Une quatrième étape S4 de la méthode consiste en le retrait des véhicules identifié car défectueux grâce au suivi. Cela se traduit par un gain financier, du fait de la réduction des coûts de blocage et/ou rappel. En effet, une maintenance prévisionnelle peut être opérée de manière ciblée sur les machines sensibles, avant la panne, ce qui permet de diminuer, voire d’éviter le temps d’arrêt. Par ailleurs, une anomalie est plus facilement détectée durant le cycle de production, en amont de la commercialisation des véhicules. Des rappels, coûteux et négatifs pour l’image du fabricant sont ainsi évités. Ces opérations de suivi ont par exemple lieu en temps réel, et sont contextualisées par le modèle de données 3. En effet, cette contextualisation lors de la collecte diminue les coûts d’accès aux données. Le modèle de données standardisé permet également d’augmenter leur vitesse de déploiement sur une grande diversité de processus industriels, d’usines, mais aussi sur différents contrôleurs et composants d’automatisme. De manière plus général, tous les cas d’usage mettant en œuvre la méthode 2 proposée présentent une exploitation de la donnée simplifiée. En effet, les données étant acheminées sous forme interopérable aux différents clients, il est alors possible d’élaborer des algorithmes génériques, valables pour tout type de données, peu importe l’opération concernée. La présente invention n’est nullement limitée au mode de réalisation décrit et représenté, mais l’homme du métier saura y apporter toute variante conforme à l’invention. Méthode de collecte de données industrielles au sein d'une usine (100), ladite usine (100) comprenant au moins un équipement industriel adapté pour exécuter au moins un processus industriel au sein d’une station (ST01), incluse dans une opération (OP600 ; OP630), ladite méthode comprenant les étapes suivantes : - instanciation d’un modèle de données physique (32) sur un serveur local (120), ledit modèle de données physique (32) présentant une structure hiérarchisée dans laquelle au moins une première classe comprend des variables liées au processus industriel, une deuxième classe comprend des variables liées à la station (ST01, ST02), et une troisième classe comprend des variables liées à l’opération (OP600, OP630), ladite première classe étant hiérarchiquement liée à ladite seconde classe, et ladite seconde classe étant hiérarchiquement liée à ladite troisième classe, chaque variable présentant un type et une adresse physique (1A, 2A, 3A) d’allocation d’une valeur de ladite variable sur l’au moins un équipement industriel ou ladite station ou ladite opération, lesdites variables étant issues d’une base de données des variables, - collecte des données industrielles selon ledit modèle de données physique (32), pour chaque variable, ledit serveur local (120) étant connecté à ladite adresse physique (1A, 2A, 3A) d’allocation de ladite variable, afin d’enregistrer une valeur de ladite variable, - stockage des données industrielles au sein d’un serveur à distance (140). Méthode de collecte de données industrielles selon la revendication 1, dans laquelle, ladite étape d’instanciation du modèle de données physique (32) génère au moins un fichier d’instanciation sur ledit serveur local (120) et ladite étape de collecte est opérée selon un format et une structure hiérarchisée et standardisée à l’aide dudit au moins un fichier d’instanciation définissant ledit modèle de données (3). Méthode de collecte de données industrielles selon l’une quelconque des revendication 1 à 2, dans laquelle ladite base de données des variables est une base de données répertoriant des variables préexistantes. Méthode de collecte de données industrielles selon la revendication 3, dans laquelle lesdites variables préexistantes comprennent des variables préexistantes génériques et des variables préexistantes spécifiques, lesdites variables préexistantes génériques étant utilisées par une pluralité de modèles de données physique (32). Méthode de collecte de données industrielles selon la revendication 4, dans laquelle lesdites variables préexistantes spécifiques étant regroupées en une pluralité de briques spécifiques et lesdites variables préexistantes génériques étant regroupées en une pluralité de briques génériques, ledit modèle de données physique (32) est construit par assemblage des briques génériques et des briques spécifiques, afin de créer ladite structure hiérarchisée. Méthode de collecte de données industrielles selon l’une quelconque des revendications 1 à 5, dans laquelle le serveur local (120) sur lequel est instancié ledit modèle de données physique (32) est un serveur « OPC Unified Architecture ». Méthode de collecte de données industrielles selon l’une quelconque des revendication 1 à 6, dans laquelle ladite adresse physique (1A, 2A, 3A) d’allocation de ladite valeur de ladite au moins une variable est donnée par un pilote de configuration (41), ledit pilote de configuration (41) générant un script d’adressage entre une base de données des adresses physiques et ladite au moins une variable instanciée sur ledit serveur local (120). Méthode de collecte de données industrielles selon la revendication 7, dans laquelle la base de données des adresses physiques est établie compte tenu dudit au moins un équipement industriel de l’usine (100). Méthode de collecte de données industrielles selon l’une quelconque des revendication 1 à 8, dans laquelle la collecte des données industrielles se fait en trois points de collecte de la donnée industrielle, chacun de ces points de collecte correspondant à une zone mémoire, où des variables liées hiérarchiquement par le modèle de données physique (32) sont combinées et collectée simultanément depuis cette zone mémoire, les trois points de collecte de la donnée industrielle comprenant un point de collecte correspondant aux variables de ladite première classe, un point de collecte correspondant aux variables de ladite seconde classe et un point de collecte correspondant aux variables de ladite troisième classe. Méthode de collecte de données industrielles selon l’une quelconque des revendication 1 à 9, dans laquelle les données industrielles sont collectées et stockées par le serveur local (120) sous un format série temporelle. Méthode de collecte de données industrielles selon l’une quelconque des revendications 1 à 10, dans laquelle la méthode comprend en outre une étape d’exploitation des données industrielles par un client. Méthode de collecte de données industrielles selon la revendication 11, dans laquelle l’étape d’exploitation de la donnée comprend une étape de suivi et d’identification de pièces produites par l’au moins un processus industriel. Méthode de collecte de données industrielles selon la revendication 11 ou 12, dans laquelle l’étape d’exploitation de la donnée comprend une étape de maintenance conditionnelle sur l’au moins un équipement industriel mettant en œuvre l’au moins un processus industriel et/ou de rappel de pièces produites par l’au moins un processus industriel. Méthode de collecte de données industrielles selon l’une quelconque des revendications 1 à 13, dans laquelle l’au moins un processus industriel permet de fabriquer une pièce de véhicule automobile.