Titre de l'invention : Procédé de contrôle d’un flux de données associé à un processus au sein d’un réseau mutualisé

1. Domaine technique

L'invention est relative à l’identification et à l’acheminement de données de processus dans un réseau de communication, notamment structurés en chemins de données ayant par exemple des caractéristiques de qualité de service, de sécurité et d’acheminement communes. Il s’agit par exemple de gérer des flux associés à des services spécifiques dans un réseau comprenant des tranches de réseaux, aussi appelées « network slices » en anglais.

2. Etat de la technique

Les entreprises, notamment du secteur industriel, souhaitent, dans le contexte de la digitalisation de leurs processus métiers, une forte intégration des mécanismes de contrôle des performances de leurs services de connectivité avec les mécanismes propres aux processus de leur activité. Le processus se définit comme un ensemble de tâches qui permettent le suivi de la réalisation et de la qualité du service fourni ou du produit délivré.

Le produit ou service délivré est de plus en plus personnalisé, propre à un client ou à un ensemble de clients, requérant un suivi adapté du processus de mise en œuvre du produit ou service.

Un processus peut requérir l’intervention de plusieurs acteurs. Par exemple, un (ou plusieurs) fournisseur(s) d'équipements industriels, un (ou plusieurs) fournisseur(s) de services de connectivité, un (ou plusieurs) fournisseur(s) d'applicatifs métier, un (ou plusieurs) fournisseur(s) d'infrastructure cloud voire un intégrateur du processus faisant intervenir les différents acteurs cités ci-dessus, peuvent ainsi intervenir dans la mise en œuvre du processus.

Un processus peut en outre comprendre une diversité de services qui peuvent être exécutés simultanément ou à la suite. Le processus peut par exemple requérir des appels de groupe entre travailleurs au sein des lignes de production, des communications de type loT (en anglais « Internet of Things ») pour collecter les informations de fonctionnement des machines ou encore des transmissions de données applicatives vers des clients destinataires du produit ou du service issu du processus. Chacun de ces services, associé au processus, a des besoins de connectivité différents en termes de volumétrie, de tolérance à des pertes de paquets, de réactivité par exemple à des commandes de pilotage, ainsi que des exigences de supervision très différentes suivant leur niveau de criticité. La technologie 5G (Cinquième Génération) doit être un facilitateur dans la mise en œuvre de ces exigences à travers notamment le support de services d’acheminement de données qui soient spécifiques à chacun des services cités précédemment. Les tranches de réseaux mises en œuvre dans la technologie 5G sont notamment déployées pour acheminer des données ayant des caractéristiques communes en termes de qualité de service, de sécurité, de gestion. Ainsi, des processus distincts requérant les mêmes caractéristiques de connectivité auront leurs données acheminées au sein d’une même tranche de réseau. Aussi, les flux de données d’un processus qui correspondent à des services distincts seront probablement acheminés sur des tranches de réseaux différentes. En effet, l’opérateur du service de communication organise son réseau de communication en acheminant toutes les données ayant des caractéristiques communes du point de vue du réseau mais possiblement relatives à des clients distincts, dans une même tranche de réseau. L’opérateur déploie par exemple une tranche de réseau pour les données IoT, une tranche de réseau pour les données très critiques, une tranche de réseau pour les données Best-Effort. En outre, l’opérateur de réseau administre son réseau suivant ses propres besoins et déploie des mécanismes de gestion et de suivi de trafic d’une tranche de réseau en fonction de ses propres contraintes. L’entreprise en charge du processus ne dispose pas d’informations de supervision dynamiquement configurées et propres à son processus et ne peut donc pas superviser et adapter le contrôle du processus par exemple pour modifier le processus en question en fonction de ce contrôle. Les architectures des réseaux et les solutions de supervision ne permettent pas en outre de détecter rapidement un problème pouvant survenir sur l’un des services composant le processus, compliquant et retardant les décisions prises pour résoudre le problème.

La présente invention a pour objet d’apporter des améliorations par rapport à l’état de la technique.

3. Exposé de l'invention

L'invention vient améliorer la situation à l'aide d'un procédé de contrôle d’un flux de données associées à un processus et acheminées dans un chemin partagé de données, comprenant une pluralité de flux, d’un réseau de communication, ledit procédé étant mis en œuvre dans un dispositif dudit chemin et comprenant la réception en provenance d’une entité de supervision d’une information d’identification du flux à contrôler, la configuration d’au moins un paramètre de contrôle du flux, ledit paramètre étant relatif au processus correspondant à l’information reçue et l’exécution d’une opération de contrôle du flux de données en fonction d’au moins un paramètre configuré.

Le procédé permet de pouvoir différencier les options de supervision d’un flux au sein d’un chemin partagé de données. Selon la technique antérieure, le chemin de données est supervisé de façon uniforme pour l’ensemble des données du chemin, c’est-à-dire que les données des différents flux au sein du chemin sont contrôlées avec les mêmes caractéristiques ou paramètres de contrôle. Dans les architectures de réseaux mises en œuvre, les flux d’un même chemin de données peuvent avoir les mêmes paramètres d’acheminement, c’est-à-dire que les données des flux sont routées selon des critères de qualité de service et de sécurité comparables.

Cependant, en fonction de la nature de ces flux et notamment des processus associés aux différents flux, le contrôle d’un flux doit pouvoir se différencier du contrôle d’un autre flux, associé à un autre processus, et aussi requérir la mise en œuvre du procédé de contrôle. Le procédé permet en effet de pouvoir configurer de façon dynamique des paramètres de contrôle pour un flux spécifique de données dans un chemin partagé (ou mutualisé) de données, permettant ainsi d’améliorer la supervision du processus. Il est en effet ainsi possible de modifier dynamiquement les paramètres de contrôle d’un flux, de prévoir une remontée d’information de supervision adaptée au flux et d’analyser des caractéristiques spécifiques des données en fonction du type, de la criticité en termes de disponibilité, des exigences en termes de qualité de service d’un processus dont les données sont transmises dans un chemin de données, par exemple en utilisant des méthodes de multiplexage et/ou de structuration en tranches de réseau.

Selon un aspect de l'invention, dans le procédé de contrôle, le chemin partagé de données correspond à une tranche de réseau.

Dans les architectures de réseau en cours de spécification, par exemple de type 5G (Cinquième Génération), les flux de données sont acheminés dans des tranches de réseau, aussi appelées « network slices » (en anglais). Les données d’une tranche de réseau sont acheminées selon des caractéristiques d’acheminement communes et le procédé permet de personnaliser le type de supervision d’un flux en particulier au sein d’une tranche de réseau comprenant une pluralité de flux de données, correspondant possiblement à des processus distincts.

Selon un autre aspect de l’invention, dans le procédé de contrôle, l’information d’identification du flux comprend un identifiant de processus, et optionnellement au moins un identifiant parmi un identifiant du chemin de données partagé, un identifiant du dispositif, un identifiant de l’entité de supervision.

Un flux peut avantageusement être identifié par un identifiant de processus auquel il est associé pour faciliter l’exploitation et l’association des données de contrôle reçues. L’identifiant de processus peut être complété par un identifiant de chemin de données, par exemple un identifiant de tranche de réseau, sachant que des données d’un même processus peuvent être acheminées sur des chemins de données différents en fonction par exemple de leur exigence en termes de qualité de service. Dans le cas où certaines données d’un processus doivent transiter par un dispositif spécifique, par exemple pour des raisons de sécurité, un identifiant du dispositif peut être utilisé en complément de l’identifiant de processus et optionnellement de l’identifiant d’un chemin de données. Un identifiant de l’entité de supervision peut en outre être utilisé comme identifiant en complément de l’identifiant de processus, notamment pour vérifier que l’entité de supervision correspond effectivement au processus à contrôler.

Selon un autre aspect de l’invention, dans le procédé de contrôle, l’au moins un paramètre de contrôle du flux est obtenu en provenance de l’entité de supervision préalablement à la configuration dudit paramètre par le dispositif.

L’entité de supervision peut avantageusement transmettre le (ou les) paramètre(s) de contrôle du flux en plus de l’identifiant du flux à superviser. Ces deux informations peuvent être transmises simultanément ou de façon distinctes. Notamment, si l’entité de supervision souhaite modifier le paramètre de contrôle de façon dynamique pour améliorer le suivi du processus, un envoi spécifique du (ou des) paramètres de contrôle peut être émis pour modifier le paramètre alors que des données du flux sont acheminées dans le chemin partagé.

Selon un autre aspect de l’invention, dans le procédé de contrôle, au moins un paramètre de contrôle du flux comprend au moins un paramètre parmi : un champ d’une donnée du flux, une période pendant laquelle le contrôle du flux est exécuté, une fréquence correspondant au nombre d’itérations de l’opération de contrôle par unité de temps, un mode de calcul des données de contrôle, le type d’interface utilisé pour effectuer l’opération de contrôle, une donnée de synchronisation d’opérations de contrôle.

Le paramètre de contrôle peut permettre d’évaluer un champ spécifique d’une donnée du flux, par exemple un champ relatif à la qualité de service. Il peut être avantageux d’indiquer une durée de contrôle dans le cas où le contrôle est effectué pendant une durée limitée, répondant à un besoin spécifique ou à une détection d’un incident dans la mise en œuvre du processus. Il est possible de collecter des données de contrôle à des intervalles spécifiques en fonction notamment du type de processus à contrôler. Un processus requérant une forte disponibilité requiert par exemple une fréquence plus élevée. Le mode de calcul correspond par exemple à un calcul de valeur moyenne d’une donnée contrôlée ou bien à un calcul de valeur instantanée. Le type d’interface peut dépendre du type et de la fréquence de contrôle. Ainsi, une interface de streaming sur le dispositif est privilégiée pour une remontée fréquente de données alors qu’une interface de transfert de fichiers est plus adaptée à une remontée moins fréquente de données de contrôle. Notamment dans le cas où plusieurs flux de données relatifs à un processus sont contrôlés, l’ajout d’une donnée de synchronisation, telle qu’une horloge, permet de corréler les différentes opérations et de pouvoir interpréter les résultats d’opérations de contrôle effectués sur les différents flux. La donnée de synchronisation permet en outre de suivre l’évolution des résultats des opérations de contrôle dans le temps.

Selon un autre aspect de l’invention, le procédé de contrôle comprend en outre l’émission à destination de l’entité de supervision d’un résultat de l’opération de contrôle exécutée.

Une fois le contrôle effectué sur le flux identifié et conformément au paramètre de contrôle configuré, le dispositif émet à destination de l’entité de supervision un résultat du contrôle opéré permettant à l’entité de supervision de prendre une décision en fonction du résultat. La décision peut par exemple consister à requérir que le flux de données du processus soit acheminé sur un autre chemin de données ou que le flux de données soit supervisé conformément à un autre paramètre de contrôle.

Selon un autre aspect de l’invention, le procédé de contrôle comprend en outre la réception en provenance d’un autre dispositif du chemin de données d’un message comprenant une information prise en compte par le dispositif pour configurer le paramètre de contrôle.

Un processus fait le plus souvent intervenir une pluralité de dispositifs pouvant exercer un contrôle sur le flux de données. Un deuxième dispositif, voire plusieurs autres dispositifs, peut influer sur le contrôle exercé par un premier dispositif par exemple en transmettant un résultat d’un contrôle et ainsi modifier un paramètre de contrôle du premier dispositif. Cela permet d’effectuer un contrôle réparti et coordonné du processus sur plusieurs dispositifs, chacun de ces dispositifs pouvant exercer un contrôle d’une partie ou de certaines données du processus. Ces dispositifs peuvent agir sur un même chemin de données ou sur plusieurs chemins de données.

Selon un autre aspect de l’invention, dans le procédé de contrôle, l’opération de contrôle comprend une opération de corrélation d’un résultat d’un contrôle effectué sur un deuxième flux de données, avec un résultat issu du contrôle sur le flux de données.

Un processus peut être associé à plusieurs flux de données, chacun des flux étant par exemple établi pour transporter des données ayant les mêmes caractéristiques d’acheminement. Un processus peut comprendre par exemple un flux de données temps réel et un flux de données de type « best effort », ou des flux de données « audio » et « vidéo », les deux flux étant acheminés sur un même chemin partagé de données ou deux chemins de données distincts. L’opération de contrôle peut consister à obtenir des données issues du contrôle de chaque flux ainsi qu’une opération de corrélation des différentes données reçues pour ensuite transmettre un résultat du contrôle du processus à l’entité de supervision ou à une autre entité.

Selon un autre aspect de l’invention, dans le procédé de contrôle, le deuxième flux de données de l’opération de corrélation est acheminé dans un plan de contrôle du réseau de communication et le flux de données est acheminé dans le plan de transfert du réseau de communication.

Il est avantageux de pouvoir aussi bien contrôler les données d’un processus émises dans le plan de contrôle en plus du contrôle effectué sur les données émises dans le plan de transfert pour identifier les problèmes survenant sur un processus. Les contrôles d’établissement d’une connexion ou de résolution d’un nom de domaine DNS (en anglais « Domain Name System »), effectués dans le plan de contrôle, peuvent en effet être avantageusement utilisés en complément du contrôle des flux dans le plan de transfert pour détecter des anomalies ou des problèmes sur un processus, ces anomalies pouvant indifféremment survenir lors de l’établissement ou lors de la gestion d’un flux comme dans la transmission des données du flux dans le plan de transfert.

Selon un autre aspect de l’invention, dans le procédé de contrôle, le flux de données est transmis dans une tranche de réseau établie dans le chemin partagé de données. Une tranche de réseau permet d’effectuer des traitements spécifiques à des flux ayant des caractéristiques d’acheminement communes. Un flux de données d’un processus peut être transmis dans une tranche de réseau, ou slice, cette tranche de réseau pouvant elle-même être comprise dans une tranche de réseau dans le cas où le chemin partagé de données est une tranche de réseau. L’opération de contrôle du flux de données peut correspondre à un traitement spécifique associé à la tranche de réseau associée au processus. Ainsi, une sous-tranche de réseau peut présenter des paramètres de contrôle spécifiques, propres à un processus, au sein d’une tranche de réseau ayant des paramètres de contrôle génériques indépendants des données des processus acheminées dans cette tranche. Cette configuration est directement applicable au cadre d’une offre de gros où l’opérateur, souscrivant à cette offre de gros, met en œuvre des sous-tranches de réseau.

Selon un autre aspect de l’invention, le procédé de contrôle comprend en outre une reconfiguration d’au moins un paramètre suite à l’exécution de l’opération de contrôle du flux de données.

Le procédé permet de pouvoir reconfigurer un paramètre de contrôle suite à l’exécution du contrôle et ainsi de pouvoir adapter le contrôle en fonction notamment de premiers résultats obtenus une fois l’opération de contrôle initialisée. Ainsi, en fonction des résultats obtenus, il pourra être utile de contrôler d’autres paramètres du flux ou de modifier le paramètre contrôlé initialement, et ainsi améliorer, approfondir ou diversifier l’opération de contrôle effectuée.

Les différents aspects du procédé de contrôle qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.

L’invention concerne également un dispositif de contrôle d’un flux de données associées à un processus et acheminées dans un chemin partagé de données, comprenant une pluralité de flux d’un réseau de communication, mis en œuvre dans un dispositif dudit chemin et comprenant un récepteur, apte à recevoir en provenance d’une entité de supervision une information d’identification du flux à contrôler, un module de configuration apte à configurer un paramètre de contrôle du flux, ledit paramètre étant relatif au processus correspondant à l’information reçue, un contrôleur, apte à exécuter une opération de contrôle du flux de données en fonction du paramètre configuré. Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de contrôle qui vient d'être décrit, est destiné à être mis en œuvre dans une entité de d’une infrastructure de communications, dans une infrastructure virtualisée ou dans une infrastructure basée sur des équipements physiques. Par exemple, le dispositif peut être mis en œuvre dans une entité de type équipement réseau tel que routeur ou serveur applicatif.

L’invention concerne aussi un système de de contrôle d’un flux de données associées à un processus et acheminées dans un chemin partagé de données comprenant une pluralité de flux, d’un réseau de communication, le système comprenant :

- un dispositif de contrôle,

- une entité de supervision apte à émettre à destination du dispositif de contrôle une information d’identification du flux à contrôler.

L'invention concerne aussi un programme d'ordinateur comprenant des instructions pour la mise en œuvre des étapes du procédé de contrôle qui vient d'être décrit, lorsque ce programme est exécuté par un processeur et un support d’enregistrement lisible par un dispositif de contrôle sur lequel est enregistré le programme d’ordinateur.

Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

L’invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions du programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple sur un disque dur.

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

4. Brève description des dessins

D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :

[Fig 1] présente une vue simplifiée d’un environnement dans lequel est mise en œuvre l’invention selon un aspect de l’invention.

[Fig 2] présente une architecture logique d’un environnement dans lequel est mise en œuvre l’invention selon un autre aspect de l’invention.

[Fig 3] présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon un premier mode de réalisation de l’invention.

[Fig 4] présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon encore un deuxième mode de réalisation de l’invention, [Fig 5] présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon encore un troisième mode de réalisation de l’invention. [Fig 6] présente un aperçu du procédé de contrôle selon un quatrième mode de réalisation de l’invention.

[Fig 7] présente un aperçu du procédé de contrôle selon un cinquième mode de réalisation de l'invention.

[Fig 8] présente un exemple de structure d’un dispositif de contrôle selon un aspect de l'invention.

5. Description des modes de réalisation

Dans la suite de la description, on présente des modes de réalisation de l'invention dans un réseau de communication. Ce réseau peut être mis en œuvre dans une infrastructure fixe ou mobile et l’invention peut être destinée à assurer un contrôle de processus industriel, de processus de livraison de service ou tout autre processus lié à la fourniture d’une prestation à destination d’un client ou pour les propres besoins de l’entreprise le déployant.

On se réfère tout d’abord à la [Fig 1] qui présente une vue simplifiée d’un environnement dans lequel est mise en œuvre l’invention selon un aspect de l’invention. Dans cet environnement une entreprise Indus produit un bien industriel à partir d’un processus requérant la contribution d’une pluralité d’acteurs. Le processus, aussi appelé processus métier, se définit comme un ensemble de tâches effectuées par les différents acteurs, le contrôle de la réalisation du processus conduisant à la production du bien industriel s’appuyant sur la supervision de chacune des tâches du processus. Les différents acteurs n’ont cependant pas forcément connaissance du bien industriel et, selon la technique antérieure, transmettent des données de supervision propres à leur environnement et non pas propres au suivi du processus de réalisation du bien industriel produit par Indus. Selon un aspect de l’invention, l’entreprise Indus interagit avec un intégrateur Integ chargé du suivi, de l’articulation des différentes tâches du processus et de l’avancement des tâches permettant la réalisation du bien. Dans certains cas, l’entreprise Indus joue également le rôle de l’intégrateur. La réalisation du processus requiert en outre la contribution d’au moins un fournisseur d’équipement industriel Equipt en charge de la mise en œuvre d’équipements permettant la fabrication du bien industriel. Au moins un fournisseur d’applications métiers App intervient également dans le processus. Ces applications peuvent correspondre par exemple à des serveurs en charge de l’analyse des données de fonctionnement des équipements industriels. Au moins un fournisseur d’infrastructure Infra, par exemple de type Cloud, est également susceptible d’intervenir notamment pour stocker des applications et des données relatives au processus. Le déroulement du processus requiert en outre au moins un fournisseur de connectivité Connect assurant la transmission des différentes données relatives aux étapes du processus entre les différents acteurs intervenant dans le processus. Comme les autres acteurs, selon la technique antérieure, le fournisseur de connectivité assure une supervision du service de connectivité indépendamment du processus pour lequel il transmet des données. Le fournisseur de connectivité Connect s’assure par exemple que les données qu’il achemine ne subissent pas de pertes de paquets, que les classes de qualité de service sont bien respectées pour les différents flux de données acheminés, que les données pour un client donné sont bien comptées et facturées le cas échéant, que les engagements en termes de sécurité pour un client sont bien respectés mais le fournisseur de connectivité Connect, selon l’art antérieur, ne conduit pas de contrôle des données propres au processus de fabrication du produit. Dans l’environnement de la figure 1, selon un aspect de l’invention, le fournisseur de connectivité Connect contrôle les flux de données propres au processus de fabrication en fonction d’une demande émise par un dispositif de supervision de l’acteur Indus voire de l’acteur Integ selon les cas. Selon d’autres exemples, un dispositif de supervision des acteurs Equipt, App, Infra peut également transmettre une demande de contrôle à un équipement de l’acteur Connect par exemple pour corréler les informations de contrôle de l’entité Connect avec leur propre contrôle de données du processus de fabrication. Il est à noter que les entités Equipt, App, Infra voire Integ disposent également de réseaux de communications et peuvent mettre en œuvre le procédé de contrôle selon l’invention comme l’acteur Connect.

En relation avec la [Fig 2], on présente une architecture logique d’un environnement dans lequel est mise en œuvre l’invention selon un autre aspect de l’invention.

Les différents acteurs intervenant dans le processus tels que décrits dans la [Fig 1] interviennent également dans le processus de la [Fig 2]. Les acteurs Indus, Integ, Equipt, Infra, Connect et App sont ainsi représentés. Il est à noter qu’une même structure peut tenir le rôle d’un ou plusieurs acteurs. Par exemple, une même structure ou entreprise peut intervenir en tant qu’ Integ et Connect par exemple. Chaque acteur dispose d’au moins une entité de supervision. Ainsi, l’acteur Integ administre une entité de supervision Integ Super, l’acteur Equipt gère l’entité de supervision Eq Sup, et de façon correspondante les acteurs Infra, Connect et App administrent respectivement les entités Infra Sup, Connect Sup et App Sup. Les entités de supervision des différents acteurs contrôlent le fonctionnement des dispositifs propres à l’acteur. Ainsi l’entité Eq sup contrôle le fonctionnement d’un équipement industriel EL Bien entendu, les entités de supervision sont aptes à contrôler chacun plus d’un dispositif, la [Fig 2] n’en représentant qu’un pour chaque entité de supervision. Les entités Infra Sup, Connect Sup et App Sup contrôlent respectivement le fonctionnement des dispositifs Eqt Infra, (Eq Res 1 et Eq Res 2), et l’équipement applicatif EA. Il est à noter que l’entité Connect Sup contrôle le fonctionnement des équipements Eq Res 1 et Eq Res 2, le dispositif Eq Res 1 intervenant dans le plan de contrôle Contrl et le dispositif Eq Res 2 intervenant dans le plan de transfert Transf du réseau de communication géré par l’acteur Connect. Chaque entité de supervision est en outre connectée à une base de données (BdDl, BdD2, BdD3 et BdD4) pour stocker les données issues du contrôle opéré sur les équipements respectifs par les entités de supervision. L’acteur Integ dispose d’une base de données BdDi intégrant les différentes données issues des contrôles opérés par les acteurs Equipt, Infra, Connect, App. Dans cette architecture logique, une entité de supervision est susceptible de solliciter les dispositifs du réseau de communication intervenant dans la mise en œuvre du processus et transmet une information d’identification d’un processus à contrôler. Les dispositifs sollicités configurent un ou plusieurs paramètres de contrôle relatif au processus identifié et exécutent les opérations de contrôle en fonction des paramètres configurés. Ainsi, par exemple, les équipements réseau Eq Res 1 et Eq Res 2 reçoivent des identifiants de flux à contrôler, configurent des paramètres de contrôle pour contrôler les flux de données d’un processus, et exécutent le contrôle. Le dispositif Eq Resl effectue ainsi un contrôle de données propres à un processus dans le plan de contrôle Control et le dispositif Eq Res 2 effectue un contrôle des données acheminées dans le plan de transfert Transf du réseau de Connect pour le processus identifié par l’information transmise précédemment par l’entité Connect Sup. Il est à noter qu’une entité de supervision d’un acteur peut transmettre l’information d’identification du processus à des dispositifs d’autres acteurs intervenant dans le processus. L’entité Integ Sup peut ainsi transmettre directement ou indirectement un identifiant de processus aux dispositifs Eq Res 1 et Eq Res 2 pour que ceux-ci effectuent un contrôle du processus identifié par l’identifiant transmis. Sachant que les flux de données transitent dans un même chemin de données, que ce chemin de données peut être une tranche de réseau, un réseau privé virtuel, une liaison louée ou tout autre technique permettant d’agréger ou de multiplexer des données relatives à des clients ou des processus différents, l’identifiant de processus permet de pouvoir assurer un contrôle des seules données propres au processus. Cela permet de pouvoir les exploiter directement ou de pouvoir les agréger plus facilement pour les transmettre par exemple à l’acteur Indus, chaque acteur intervenant dans le processus mettant en œuvre possiblement le même procédé de contrôle.

En relation avec la [Fig 3], on présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon un premier mode de réalisation de l’invention. Dans ce mode de réalisation, trois processus métiers PMI, PM2, PM3 de l’industrie sont contrôlés. A titre d’exemple, les trois processus sont respectivement un processus PMI de commande d’un produit, un processus PM2 de fabrication d’un produit et un processus PM3 de transport du produit fabriqué au sein d’une usine. Ces trois processus PMI, PM2, PM3 requièrent des échanges de données entre différents équipements, différentes équipes et différentes applications métier. Ainsi le processus PMI requiert des échanges de données entre un équipement industriel Eli de prise de commande et une application métier AMI de gestion des commandes, cet équipement Eli et cette application métier AMI échangeant un flux de données Flux 21 sur une tranche de réseau S2 du plan de transfert Transf d’un réseau de communication. Les flux de données Flux 22 et Flux 23 respectivement échangés entre les équipements Eli et EI2 et l’application métier AM2 sur la tranche de réseau S2 du plan de transfert Transf du réseau de communication, et les flux de données Flux 11 et Flux 12 transmis par les équipements Eli et EI2 sur une tranche de réseau SI du plan de contrôle Contrl du réseau de communication sont propres au processus métier PM2. Les flux de données Flux 31 et Flux 32 transmis par les équipements Eli et E12 sur une tranche S3 du plan de transfert Transf du réseau de communication à destination de l’applicatif métier AM3 sont relatifs au processus métier PM3. Des flux de données peuvent indifféremment être échangés entre des applicatifs métiers ou des équipements physiques ou virtualisés. Dans ce mode de réalisation, le plan de transfert Transf comprend 2 tranches de réseau S2 et S3 établies entre les dispositifs réseau ET1 et ET2 alors que le plan de contrôle Contrl comprend une tranche de réseau S 1 mise en œuvre à partir des dispositifs EC1 et EC2. Les flux de données transmis dans ces tranches de réseau sont propres à des processus distincts et il convient donc de mettre en place le procédé de contrôle pour assurer le contrôle des flux de données associés aux processus respectifs. Par exemple, la configuration d’un paramètre de contrôle d’un flux de données, tel qu’un champ de qualité de service du flux, un nombre de paquets transmis pour un flux ou une durée du contrôle effectué est mise en œuvre à partir d’une information d’identification du flux à contrôler. Cette information, transmise par une entité de supervision non représentée sur la [Fig. 3], correspond au numéro du flux, par exemple Flux 11, Flux 12..., ou bien encore à des attributs d’entrée (Eli, E12, E21, E22, E23, E31, E32) et/ou de sortie (Sll, S12, S21, S22, S23, S31, S32) des flux de données. Ainsi, le flux de données Flux 11 peut être identifié par Flux 11, Ell-Sll ou bien encore par ces identifiants auxquels est ajouté un identifiant de tranche (Flux 11, SI), (Flux 11, Ell-Sll, SI) suivant que le flux de données soit montant (d’un terminal vers un serveur) ou descendant (d’un serveur vers un terminal) au sein de l’infrastructure de connectivité Connect. Un identifiant d’un équipement acheminant les données du flux (EC1, EC2...) et le type de plan (Contrôle, Transfert) peut en outre être utilisé pour identifier le flux ou être ajouté aux paramètres définis précédemment. L’identifiant du Flux 11 pourra par exemple comprendre une donnée parmi les données suivantes en plus de l’identifiant Flux 11 ( Eli, E12, SI, Contrl, EC1, EC2). Un identifiant de l’entité de supervision (comme par exemple Integ Sup ou Connect Sup suivant la [Fig.2]) transmettant l’information sur l’identifiant du flux à contrôler peut en outre être ajouté à l’identifiant de Flux (Flux 11) à des fins d’identification. Dans ce mode de réalisation, le chemin partagé de données est une tranche de réseau.

En relation avec la [Fig 4], on présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon un deuxième mode de réalisation de l’invention. Ce mode de réalisation est relatif à un processus d’un service bancaire requérant une forte disponibilité. Le réseau de communication est composé d’un réseau de communication mobile RM et d’un réseau de communication de type optique RO, les deux réseaux étant destinés à assurer une haute disponibilité du service bancaire. Chaque réseau RM et RO dispose d’un plan de contrôle, nommé respectivement Contrl RM et Contrl RO, et d’un plan de transfert, Transf RM et Transf RO. Les flux de données propres au service bancaire, transportés depuis l’équipement bancaire EB1 jusqu’à l’application métier AMI, empruntent différents chemins de données, chaque chemin étant un chemin partagé. Le flux de contrôle Flux 11 est acheminé dans le chemin partagé entre les dispositifs EC1 et EC2 et correspondant à une tranche de réseau SI du réseau de contrôle Contrl RM du réseau mobile RM, le flux de données de transfert Flux 21 est acheminé dans une tranche de réseau S2, entre les dispositifs ET1 et ET2, du réseau de transfert Transf RM du réseau mobile RM. Les flux Flux 31 et Flux 41 de données de contrôle et de transfert du réseau optique RO sont respectivement acheminés dans le VPN3 (en anglais Virtual Private Network) construit entre les dispositifs réseau EC3 et EC4, et VPN4 construit entre les dispositifs ET3 et ET4 du réseau optique RO. Les flux d’un même processus peuvent être acheminés dans des chemins partagés distincts ou communs. Dans la [Fig 4] différents flux de données Flux 11, Flux 21, Flux 31, Flux 41 sont acheminés dans des chemins partagés distincts de types différents puisque ce sont des tranches de réseau pour le Flux 11 et le Flux 21 alors que ce sont des VPNs pour le Flux 31 et le Flux 41. Les différents flux peuvent être identifiés conformément aux possibilités précisées dans la description de la [Fig 3]. Sur la [Fig 4], un seul processus est représenté mais les chemins de données partagés (SI, S2, VPN3 et VPN4) peuvent chacun comprendre une pluralité de flux d’un même processus et/ou de processus distincts. Pour chaque flux (Flux 11, Flux 21, Flux 31, Flux 41) du processus, un paramètre de contrôle est configuré. Il peut s’agir d’une donnée d’un flux à contrôler, par exemple permettant de compter les paquets du flux, une période pendant laquelle le contrôle du flux est exécuté. Le contrôle peut ainsi être mené pendant une période limitée pour résoudre un problème spécifique.

Le paramètre de contrôle peut comprendre une fréquence de l’opération de contrôle lorsqu’il s’agit par exemple de prélever plusieurs fois un indicateur dans une période de temps. Il peut également s’agir d’un mode de calcul des données de contrôle, par exemple le recueil de valeurs instantanées ou des valeurs moyennes. Le paramètre de contrôle peut comprendre également une donnée de synchronisation, telle qu’une horloge, permettant par exemple de synchroniser les informations de contrôle reçues de flux distincts d’un procédé comme cela est le cas pour les Flux Flux 11, Flux 21, Flux 31 et Flux 41 et de pouvoir interpréter les différentes données de contrôle obtenues à un instant donné lors de l’exécution du contrôle sur les différents flux du processus.

En lien avec la [Fig 5], on présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon un troisième mode de réalisation de l’invention.

Ce mode de réalisation s’inscrit dans le cadre d’une offre de gros, par exemple de type Wholesale, d’un opérateur de réseau de communication à un prestataire déployant des processus pour ses besoins et/ou offrant lui-même des services à des clients, susceptibles d’être générés par des processus, sur la base de l’offre de gros contractée auprès de l’opérateur.

L’opérateur de réseau achemine les données de transfert du prestataire dans une tranche WHS2, comprenant les dispositifs ET1 et ET2, du plan de transfert Transf. Les données de contrôle du prestataire sont acheminées dans une tranche WHS 1 du plan de contrôle Contrl du réseau de communication, comprenant les dispositifs EC1 et EC2. Les dispositifs ET1, ET2, EC1 et EC2 contribuent à la mise en œuvre d’au moins une tranche de réseau et un nombre supérieur à deux dispositifs peut être envisagé pour une tranche de réseau donnée. Un deuxième prestataire contractant une offre de gros auprès du même opérateur verrait ses données acheminées dans deux tranches, non représentées sur la [Lig 5], distinctes des tranches WHS1 et WHS2. Le prestataire met en œuvre 3 processus à partir d’un même équipement industriel Eli, chacun des processus générant des flux de données vers les applications métiers respectives AMI, AM2, AM3. Chaque flux de données est acheminé dans le plan de transfert Transf dans une tranche de réseau de la tranche WHS2. Ainsi, le Llux 21 de données du processus PMI échangées entre l’équipement Eli et l’application métier AMI est acheminé sur une tranche de réseau S21 de la tranche de réseau WHS2. De façon identique, le Flux 22 et le Flux 23 de données sont acheminés sur les tranches S22 et S23 de la tranche WHS2. Le Flux 11 du plan de contrôle Contrl du processus PM2 est acheminé sur la tranche WHS1. Dans ce mode de réalisation, les flux de données sont associés à des tranches de réseau, elles-mêmes comprises dans une tranche de réseau, formant une hiérarchie de tranches de réseau. Les flux de données d’un processus sont en effet associés à des tranches de réseau établies au sein de tranche de réseau formant un chemin de données partagé. Selon les processus et le nombre d’acteurs intervenant dans la mise en œuvre dans ces processus, un nombre supérieur à deux niveaux de tranches de réseau peut être envisagé. Cette hiérarchie peut être mise en œuvre à partir d’autres techniques de partage, telles que les VPNs ou des liaisons louées et il est également possible d’envisager une architecture mixte comprenant une hiérarchie de chemins de données partagés basés sur des technologies différentes (tranche de réseau dans un VPN par exemple).

En relation avec la [Fig 6], on présente un aperçu du procédé de contrôle selon un quatrième mode de réalisation de l’invention mis en œuvre dans un réseau 10 de communicaion.

Lors d’une étape 300, un client 100 par exemple de type industriel requiert auprès d’un dispositif 101 de gestion des processus le contrôle d’un processus métier faisant intervenir différents équipements, voire différents acteurs et générant des échanges de données entre des équipements industriels et/ou des applications informatiques. Cette sollicitation du dispositif 101 de gestion est facultative et le client 100 peut solliciter directement le dispositif 102 de supervision s’il connaît le dispositif 102 en charge du contrôle du processus.

Lors d’une étape 301, le dispositif 101 de gestion identifie le dispositif de supervision à contacter pour qu’un contrôle du processus soit effectué. Cette identification est par exemple effectuée à partir d’un identifiant du processus, et/ou d’une description du processus, et/ou d’une table d’association des processus et des dispositifs de supervision. Lors d’une étape 302, l’entité 101 de gestion émet à destination de l’entité 102 de supervision identifiée lors de l’étape 301, une requête pour effectuer un contrôle des données relatives au flux du processus à contrôler. Dans le cas où plusieurs acteurs interviennent dans le processus, l’entité 101 peut identifier et solliciter plusieurs entités de supervision. Les échanges entre l’entité 101 et l’entité 102 peuvent être réalisés par un protocole de type HTTP (en anglais HyperText Transfer Protocol) ou SNMP (en anglais Simple Network Management Protocol) ou bien encore par un protocole spécifique. Lors de l’étape 302, l’entité 101 peut également indiquer à l’entité 102 la fréquence de collecte de données de données de contrôle, le taux de disponibilité des dispositifs de l’infrastructure de connectivité ou des applications propres au processus, ainsi que d’autres informations propres à déterminer le type de contrôle et les paramètres de ce contrôle. Lors d’une étape 303, l’entité de supervision 102 détermine les dispositifs à solliciter pour exécuter un contrôle des données du processus conformément à la requête reçue de l’entité 101 de gestion ou du client 100. Pour déterminer les équipements, l’entité 102 de supervision peut utiliser une table associant les processus avec les flux de données. Par exemple, l’entité 102 maintient une table associant les processus avec les identifiants de tranche de réseau et possiblement avec des identifiants de chemins partagés, tel qu’un identifiant de tranche de réseau, de VPN. L’entité 102 peut également détenir une table associant les processus et les dispositifs acheminant les données des processus et elle peut également associer un type de processus (IoT (en anglais « Internet Of Things »), Streaming, Best Effort...) avec des identifiants de dispositifs impliqués dans le transport de données de ces types de processus. Par exemple, lorsqu’un nouveau processus est mis en œuvre par un client, celui-ci indique à l’opérateur en charge du dispositif 102 de supervision, les types de flux générés par le processus et leurs caractéristiques (qualité de service, débit, criticité, localisation des équipements et applications générant les données du flux...) et l’opérateur en charge de l’acheminement des données affecte un ou plusieurs chemins de données dans lequel (ou lesquels) seront acheminées les données des flux du processus en fonction des caractéristiques de ces flux. A partir de cette identification du (ou des) chemins, l’opérateur identifie les dispositifs du (ou des) chemins intervenant dans l’acheminement des données du (ou des) flux. L’information d’identification du flux de données à contrôler comprend un identifiant de processus générant les données du flux, et optionnellement au moins un identifiant parmi :

- un identifiant du chemin de données partagé, tel que l’identifiant de tranche de réseau ou de VPN,

- un identifiant du dispositif effectuant le contrôle, tel que l’identifiant 105 ou 106,

- un identifiant de l’entité de supervision tel que l’identifiant 102 de l’entité de supervision. Lors de l’étape 304, l’entité 102 de supervision transmet aux dispositifs 105 et 106 identifiés lors de l’étape 303 une information d’identification d’un flux à contrôler. L’information d’identification comprend les identifiants décrits précédemment.

Selon une alternative, l’entité 102 de supervision transmet en outre aux dispositifs 105 et 106 des paramètres de contrôle du flux. Ces paramètres ont pour objet de qualifier le contrôle et de définir quels sont les paramètres du flux à configurer par les équipements 105 et 106 pour effectuer le contrôle. Les paramètres de contrôle du flux transmis aux dispositifs 105 et 106 peuvent être différents selon le rôle tenu par le dispositif dans l’acheminement des données. Par exemple, si le dispositif 105 intervient dans l’acheminement des flux de contrôle et le dispositif 106 intervient dans l’acheminement des données de transfert, les paramètres de contrôle pourront être différents. Les paramètres de contrôle tels que décrits dans la [Fig 3] peuvent ainsi être transmis, selon un exemple, par l’entité 102 de supervision aux dispositifs 105 et 106 lors de l’étape 304.

Lors de l’étape 305, les dispositifs 105 et 106 configurent un ou plusieurs paramètres de contrôle du flux de données généré par le processus à contrôler. Le paramètre de contrôle à configurer peut avoir été transmis par l’entité 102 de supervision lors de l’étape 304 ou bien il peut s’agir de paramètres de configuration déterminés par les dispositifs 105 et 106 en fonction notamment des données du processus à contrôler. Par exemple, à partir des identifiants du flux à contrôler, les dispositifs 105 et 106 peuvent déterminer les paramètres de contrôle à configurer. S’il s’agit de flux critiques d’un processus, les dispositifs pourront par exemple configurer un calcul du taux de perte de paquets. S’il s’agit de flux de données temps réel, les dispositifs pourront configurer un suivi régulier des paramètres de qualité de service des paquets. S’il s’agit de processus confidentiels, les dispositifs pourront configurer un contrôle des paramètres d’intégrité des paquets du flux de données. Dans le cas de flux de données chiffrés, un dispositif de type applicatif pourra accéder aux données alors qu’un routeur du réseau de communications ne disposera pas nécessairement des clés pour déchiffrer le flux de données chiffré. Les dispositifs 105 et 106 peuvent donc configurer des paramètres de contrôle distincts mais toutefois, il peut être nécessaire de synchroniser ces contrôles en configurant par exemple une horloge commune identifiant le moment où les contrôles doivent être effectués par les deux dispositifs 105 et 106.

Lors de l’étape 306, les dispositifs 105 et 106 exécutent le contrôle du flux de données conformément au paramètre de contrôle configuré lors de l’étape 305. Dans le cas où un processus comprend plusieurs flux de données, chaque flux peut être contrôlé avec des paramètres de contrôle spécifiques au flux du processus. Les paramètres de contrôle, selon un exemple, sont donc spécifiques au flux de données et/ou au dispositif en charge du contrôle du flux en plus d’être spécifique au processus.

Selon un exemple, l’opération de contrôle exécutée lors de l’étape 306 comprend une opération de corrélation d’un contrôle effectué sur un deuxième flux avec un résultat issu du contrôle sur le flux à contrôler. Par exemple, le dispositif 105 peut acheminer des données issues d’une pluralité de flux d’un même processus ou de processus distincts. La transmission des données d’un flux peut influer sur la transmission des données d’un autre flux ou un problème détecté sur deux flux distincts peut permettre d’identifier un problème sur le dispositif 105 par exemple. Notamment, si tous les flux de données acheminés par le dispositif 105 subissent une dégradation de qualité de service ou une perte de paquets, alors cela peut indiquer un problème du dispositif 105. La possibilité de corréler, de comparer ou d’agréger des résultats de contrôle permet d’identifier plus facilement un problème.

Selon une alternative, lors de l’étape 307, le dispositif 106 du chemin de données transmet au dispositif 105 un message comprenant une information prise en compte par le dispositif 106 pour configurer un paramètre de contrôle. Cette condition peut correspondre à un résultat d’un contrôle que le dispositif 106 a effectué sur le flux de données lors d’un contrôle précédent ou au cours du contrôle effectué. Par exemple, si le dispositif 106 détecte une perte de paquets, il peut indiquer cette information pour que le dispositif 105 configure le paramètre de contrôle de perte de paquets également. Il peut également s’agir d’une donnée de synchronisation pour que les contrôles par les dispositifs 105 et 106 soient effectués aux mêmes moments. Selon un exemple, cette information est transmise par l’entité 106 via l’entité de supervision 102 pour répondre à la situation où les dispositifs du chemin de données ne se connaissent pas ou ne peuvent échanger des données directement.

Selon une autre alternative, lors de l’étape 308, le dispositif 105 reconfigure un ou plusieurs paramètres de contrôle du flux de donnés. Cette reconfiguration, selon un exemple, est consécutive à l’information reçue lors de l’étape 307 et/ou elle résulte de l’opération de contrôle effectuée de façon autonome par le dispositif 105. Ainsi, si le dispositif 105 détecte une variation anormale d’un paramètre de qualité de service, elle peut reconfigurer des paramètres de contrôle par exemple pour contrôler d’autres champs du protocole utilisé pour transmettre les données du flux du processus.

Selon une autre alternative, les dispositifs 105 et 106 transmettent lors d’une étape 309 un résultat du contrôle exécuté sur le flux de données conformément aux paramètres de contrôle configurés. Ce résultat peut permettre à l’entité 102 de supervision de déterminer un nouveau contrôle à opérer sur le même flux de données ou sur un flux distinct du processus et également à informer l’entité de gestion 101 et possiblement le client 100 des résultats de contrôle obtenus. Dans le cas d’un contrôle périodique, l’entité 102 de supervision peut sauvegarder les résultats obtenus pour évaluer l’évolution de l’acheminement des données du flux d’un processus dans un chemin partagé du réseau de communication.

En relation avec la [Fig 7], on présente un aperçu du procédé de contrôle selon un cinquième mode de réalisation de l'invention dans un réseau 10 de communication. L’architecture du réseau de communication dans laquelle est mis en œuvre ce mode de réalisation est celle présentée dans la [Fig 3].

Deux équipements industriels El 1 et El 2 sont connectés au plan de contrôle et au plan de transfert d'un réseau de communication mobile.

Le plan de contrôle est constitué de 2 équipements réseau EC1 et EC2 ; le plan de transfert est composé de 2 équipements de réseau ET1 et ET2.

Les plans de transfert Tranf et de contrôle Contrl sont interfacés pour permettre notamment la configuration du plan de transfert par le plan de contrôle. Cette interface « Interface_CT» correspond typiquement à l'interface N4 du 3GPP pour l'architecture « Service-based Architecture» du cœur de réseau 5GC (en anglais « 5G Core »). Il y a création de flux de données suivant la nature d’un processus métier (associé à l'applicatif métier). Il y a donc des flux qui sont relatifs au plan de contrôle et des flux relatifs au plan de transfert. Typiquement, pour la supervision des évènements relatifs à l'attachement d'un équipement industriel au réseau ou à sa mobilité, il y aura création d'au moins un flux au niveau du plan de contrôle. Ainsi, les flux (du plan de transfert et du plan de contrôle) sont déterminés à partir de la nature du processus métier (associé à l'applicatif métier) et en considérant l'équipement industriel impliqué dans ce processus métier. Pour chaque flux (du plan de transfert et du plan de contrôle), il y a alors un attribut d'entrée unique et un attribut de sortie unique.

Selon cet exemple, comme présenté dans la [Fig 3],

- pour le plan de contrôle : pour chaque équipement industriel qui initie une communication avec le plan de contrôle, il y a création d'au moins un flux auquel sont associés un attribut d'entrée unique et un attribut de sortie unique au niveau de l'entité de supervision du fournisseur de connectivité. Dans le cas présent, nous faisons les hypothèses que le plan de contrôle : i) est commun pour les équipements industriels (Eli et EI2) de l'outil industriel du client ii) est mis en œuvre via une tranche unique SI. Pour cette tranche SI, il y a création

- du flux Fluxl 1 et des 2 identifiants Eli et SI 1 comme attributs d'entrée et de sortie pour l'équipement industriel Eli,

- du flux Fluxl2 et des 2 identifiants E12 et S 12 comme attributs d'entrée et de sortie pour l'équipement industriel EI2.

Les flux Fluxl 1 et Fluxl2 participent au processus métier PM2 relatif à des échanges de données loT. Les Flux 11 et Flux 12 permettent alors de fournir des informations sur l'état d'attachement au réseau pour les équipements industriels Eli et EI2 durant la supervision du processus métier PM2. Pour le plan de transfert, l'équipement industriel Eli participe à 3 processus métiers PMI, PM2 et PM3. La connectivité au plan de transfert se fait via 2 tranches du réseau de communications (ou « slices » en anglais) S2 et S3 pour différencier la nature des données transférées via le réseau de communication mobile. La tranche S2 est utilisée pour les échanges de données loT entre les équipements industriels et les applications métiers AMI, AM2, AM3. La tranche S3 est utilisée pour la gestion des mises à jour des logiciels de chaque équipement industriel. Typiquement, la tranche S3 demandera plus de bande passante que la tranche S2, la tranche S2 aura un trafic plus continu que la tranche de réseau S3. Les flux du plan de transfert sont déterminés à partir de la nature du processus métier (associé à l'applicatif métier) et en considérant l'équipement industriel impliqué dans ce processus métier. Pour chaque flux du plan de transfert, il y a alors un attribut d'entrée unique et un attribut de sortie unique.

Bien que les processus métiers PMI et PM2 puissent avoir des exigences similaires vis-à-vis des propriétés du plan de transfert (volumétrie de trafic, niveau de rapidité de la connectivité ou latence, niveau de disponibilité de la connectivité...), leur différenciation, via la mise en œuvre de flux différents, permet une configuration différente des paramètres de contrôle qui devront être remontés par le dispositif réseau pour chaque processus métier.

Dans ce mode de réalisation il est considéré que le processus métier loT PMI de l'application métier AMI est plus critique que le processus métier loT PM2 de l'application métier AM2. Dans ce cas, les équipements réseaux ET1 et ET2 seront configurés de manière à ce que:

- les métriques de performance du Flux 21 (comme le nombre de paquets transférés via la tranche S2 soient transmises toutes les 10 minutes vers l'entité de supervision (non représentée sur la [Fig 3] et pouvant être l’entité Connect Sup décrite dans la [Fig 2]),

- les métriques de performance des flux 22 et 23 (comme le nombre de paquets transférés via la tranche S2 soient transmises toutes les 30 minutes vers l'entité de supervision. Ainsi, le paramètre de contrôle configuré est la fréquence des remontées des métriques de performance et sera déterminé en fonction des besoins du processus métier à superviser.

Les paramètres de contrôle associés aux différents flux des processus métiers dont la nature des interfaces utilisées pour l’exécution des opérations de contrôle sont présentés en lien avec les étapes de la [Fig 7]. Seules les étapes sollicitant l'entité de supervision ou un dispositif du réseau de communication en charge de l’exécution du contrôle sont détaillées à l'exception de l'étape initiale 300.

Etape 300 : L’entité cliente 100 transmet à une entité 101 de gestion la liste des processus métiers à superviser et la performance globale attendue pour chaque processus métier. Les données suivantes sont ainsi transmises :

{Processus Métier: PMI ; volume de paquets à transférer : 2 Mbits/heure ; fréquence de remontée des métriques de performances vers l'outil de supervision: 10 minutes} {Processus Métier: PM2 ; volume de paquets à transférer: 2 Mbits/heure ; fréquence de suivi des performances: 30 minutes}

{Processus Métier: PM3 ; taux de perte de paquets: 0% ; fréquence de suivi des performances: à la fin de chaque transfert complet}

Etape 302 : envoi, vers l’entité 102 de supervision, des identifiants des dispositifs en charge du contrôle, de la liste des équipements industriels et de la performance attendue par processus métier. Envoi des données suivantes :

{Processus Métier : PMI ; Equipement industriel : Eli ; volume de paquets à transférer : 2 Mbits/heure ; fréquence de suivi des performances: 10 minutes} {Processus Métier: PM2 ; Equipement industriel: Eli, EI2 ; volume de paquets à transférer: 2 Mbits/heure ; fréquence de suivi des performances: 30 minutes} {Processus Métier: PM3 ; Equipement industriel: Eli, EI2 ; taux de perte de paquets : 0% ; fréquence de suivi des performances: à la fin de chaque transfert complet} Etape 304 : envoi aux dispositifs 105 représentant ET1 et 106 représentant ET2 des informations d’identification des flux à contrôler et des paramètres de contrôle relatifs aux métriques de performances qui devront être exécutés puis transmis par le dispositif pour chaque flux.

A cette étape, le gestionnaire envoie les paramètres de contrôle pour les métriques de performances attendues à chaque dispositif du réseau de communication intervenant dans la transmission de données du flux à contrôler dont il a la supervision.

Pour le plan de contrôle, il y a transmission des identifiants de flux Flux 11 et Flux 12 et de paramètres de contrôle aux équipements EC1 et EC2 pour la gestion des flux Fluxl 1 et Fluxl2. Les dispositifs EC1 et EC2 ne sont pas représentés sur la [Fig 7]. Pour le plan de transfert, il y a transmission des identifiants de flux et de paramètres de contrôle aux équipements 105 ET1 et 106 ET2 pour la gestion des flux Flux21, Flux22, Flux23, Flux31 et Flux32.

Les 3 exemples suivants portent sur les flux Flux21, Flux22 et Flux23 pour le dispositif 105 ET1 du réseau de transfert Transf. Les données identiques sont transmises au dispositif 106. Il est à noter que l'on propose d'utiliser : i) l'interface de streaming pour superviser les flux demandant une remontée fréquente des métriques de performance par le dispositif réseau concerné et ii) l'interface de transfert de fichiers dans le cas contraire à savoir pour superviser les flux ne nécessitant pas une remontée fréquente.

Les informations suivantes sont ainsi transmises lors de l’étape 304 au dispositif 105 ET1 : {Equipement Réseau: ET1 ; Flux: Flux21, Attribut d'entrée: E21 ; Attribut de sortie: S21 ; Equipement industriel : Eli ; volume de paquets à transférer: 2 Mbits/heure; fréquence de suivi des performances: 10 minutes; valeur: valeurs instantanées; interface: interface de streaming}

{Equipement Réseau: ET1 ; Flux : Flux22, Attribut d'entrée : E22 ; Attribut de sortie : S22 ; Equipement industriel : Eli ; volume de paquets à transférer: 2 Mbits/heure ; fréquence de suivi des performances : 30 minutes; valeur: valeurs moyennées; interface: transfert de fichiers}

{Equipement Réseau: ET1 ; Flux: Flux23, Attribut d'entrée: E23 ; Attribut de sortie: S23 ; Equipement industriel : EI2 ; volume de paquets à transférer : 2 Mbits/heure ; fréquence de suivi des performances : 30 minutes; valeur: valeurs moyennées; interface: transfert de fichiers}

Dès qu’un équipement industriel El se connecte au réseau de communication et communique avec un des domaines des applicatifs métiers d’un processus métier, alors l’entité de supervision renseigne, notamment en base de données de son domaine technique, les attributs d'entrée et de sortie du flux avec respectivement: l'adresse IP allouée à l'équipement industriel et l'adresse IP utilisée par l'application métier pour communiquer avec cet équipement industriel.

Les étapes 305 à 309 sont analogues aux étapes identiques de la [Fig 6].

Etape 310 : l’entité 102 de supervision détecte un problème sur le flux de données du processus métier PMlet le suivi des performances doit désormais être configuré à 10 secondes (et non plus 10 minutes).

- Etape 311 : notification par l’entité 102 de supervision vers les dispositifs 105 ET1 et 106 ET2 concernés, du processus métier identifié et demandant une supervision coordonnée.

La mise en œuvre du processus métier PMI implique en effet les équipements 105 ET1 et 106 ET2 au niveau du réseau. L’entité 102 de supervision envoie alors les 2 commandes de reconfiguration de paramètres de contrôle pour le flux Flux21 du processus PMlvers respectivement les dispositifs 105 ET1 et 106 ET2 :

{Equipement Réseau: ET1 ; Flux: Flux21, Attribut d'entrée: E21 ; Equipement industriel: Eli ; volume de paquets à transférer: 2 Mbits/heure ; fréquence de suivi des performances: 10 secondes; valeur: valeurs instantanées; interface: interface de streaming}

{Equipement Réseau: ET2 ; Flux : Flux21; Attribut de sortie : S21 ; Equipement industriel: Eli ; volume de paquets à transférer: 2 Mbits/heure ; fréquence de suivi des performances: 10 secondes; valeur: valeurs instantanées; interface: interface de streaming}

Les étapes 312 à 314 correspondent aux étapes 305, 306, 309 décrites ci-dessus avec les paramètres de contrôle modifiés lors de l’étape 310.

En relation avec la [Fig 8], on présente un exemple de structure d’un dispositif de contrôle selon un aspect de l'invention.

Le dispositif 105 de contrôle met en œuvre le procédé de contrôle, dont différents modes de réalisation viennent d'être décrits.

Un tel dispositif 105 peut être mis en œuvre dans une entité de d’une infrastructure de communications, dans une infrastructure virtualisée ou dans une infrastructure basée sur des équipements physiques. Par exemple, le dispositif peut être mis en œuvre dans une entité de type équipement réseau tel que routeur ou serveur applicatif. Par exemple, le dispositif 105 comprend une unité de traitement 430, équipée par exemple d'un microprocesseur mR, et pilotée par un programme d'ordinateur 410, stocké dans une mémoire 420 et mettant en œuvre le procédé de détermination selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 410 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 430.

Un tel dispositif 400 comprend : un récepteur 403, apte à recevoir en provenance d’une entité de supervision une information d’identification Ident du flux à contrôler, - un module 401 de configuration apte à configurer un paramètre de contrôle du flux, ledit paramètre étant relatif au processus correspondant à l’information reçue, un contrôleur 402, apte à exécuter une opération de contrôle du flux de données en fonction du paramètre configuré.