FR3103042A1 - Procédés de commande d’un réseau informatique de périphérie à accès multiple - Google Patents

Abstract

La présente divulgation concerne la commande d’opérations dans un réseau comprenant plusieurs architectures informatiques de périphérie à accès multiple. Spécifiquement, la présente divulgation se rapporte à un procédé de commande d’une application de service dans un réseau informatique de périphérie à accès multiple (RMEC), le réseau comprenant une pluralité d’entités (MEC1, MEC2) connectées entre elles, le procédé comportant:- commander (S3 ; S70, S80, S90, S100), par un module plateforme (MEP) que comprend une première entité (MEC1) de ladite pluralité, une exécution d’une application de service installée dans une deuxième entité (MEC2) de la pluralité par l’intermédiaire d’une fonction mandataire (FPROXY) comprise dans ladite deuxième entité, la deuxième entité étant distincte de la première entité. Figure de l’abrégé : Figure 5

Description

Procédés de commande d’un réseau informatique de périphérie à accès multiple

Arrière-plan de l’invention

La présente description se rapporte au domaine des réseaux informatiques de périphérie à accès multiple et, plus précisément, à des procédés de commande d’opérations dans de tels réseaux.

Les domaines de la santé, des transports, de l’énergie, de l’industrie du transport deviendront prochainement des domaines majeurs d’utilisation des standards 5G en télécommunications. En particulier, les standards 5G vont considérablement améliorer les débits, la connectivité, la latence ainsi que la fiabilité des communications dans le domaine de la production industrielle dite « 4.0 », par exemple dans le cadre de la commande de dispositifs connectés, du pilotage de robots, de la coordination entre plusieurs machines-outils, ou encore de la transmission et du partage de données ou de services entre différents opérateurs. Les standards 5G vont également permettre de perfectionner de nombreuses technologies dans le domaine de l’Internet des objets, dans le domaine de la réalité augmentée ou encore de la réalité virtuelle.

Dans ce contexte, une difficulté couramment rencontrée est de pouvoir disposer d’architectures réseaux répondant aux contraintes exigées par les acteurs d’un secteur industriel donné lorsque ceux-ci échangent entre eux des informations ou des applications, par exemple des applications de service. De telles contraintes sont nécessaires pour garantir des débits élevés et des latences faibles lors de la communication de données entre plusieurs sites industriels, pour faire face à des besoins de trafic spécifiques ou encore pour partager l’utilisation de systèmes communs entre différents donneurs d’ordre.

Pour ce faire, il est connu des réseaux informatiques de périphérie à accès multiples, dits réseaux MEC (pour « Multi-Access Edge Computing », en anglais). Le groupe ETSI (« European Telecommunications Standards Institute », en anglais) a défini des spécifications techniques précises et relatives à des architectures réseau compatibles avec les standards de l’informatique de périphérie multi-accès.

Selon ces normes, un réseau MEC fournit un système informatique de périphérie à accès multiple qui héberge des applications de services à un niveau positionné au plus proche du niveau « utilisateur » (« end user », en anglais). Ceci permet de stocker et de traiter des données avec un temps de réponse plus rapide que les infrastructures et les réseaux traditionnels.

En outre, un réseau MEC est conçu pour être compatible avec différents types d’accès mobiles ou fixes, ce qui lui permet d’être installé physiquement et directement à tout niveau d’un réseau fourni par un opérateur, et par exemple dans des stations de base ou dans des infrastructures appartenant à des utilisateurs ou à des industries spécifiques. Les données collectées ou utilisées peuvent ensuite être communiquées via un réseau de niveau supérieur et éventuellement dématérialisé, par exemple un réseau en nuage.

L’utilisation de réseaux MEC permet de répondre aux exigences précitées ; à titre d’exemple, des réseaux MEC permettent d’améliorer le partage de données sur un site industriel au moyen de communications sans fil. L’architecture correspondante définit un espace d’échange et de contrôle de données conformes aux conditions précitées.

Toutefois, les procédés de communication et de commande de réseaux MEC connus présentent plusieurs inconvénients majeurs.

Tout d’abord, les spécifications techniques des réseaux et des architectures MEC, qui seront déployés dans un avenir proche, ne sont actuellement prévues que pour commander des opérations dans un seul domaine, par exemple sur un seul site industriel donné. Il n’est donc pas possible de commander une opération d’un domaine à partir d’un autre domaine.

En outre, les spécifications des réseaux et des architectures MEC ne permettent pas de déployer des applications depuis un domaine vers un autre domaine. Par exemple, un opérateur d’un réseau associé à une architecture MEC d’un premier domaine n’a pas la possibilité d’interagir avec un opérateur associé à une architecture d’un deuxième domaine, en particulier pour exécuter des applications du premier domaine dans ce deuxième domaine ou encore pour mettre en œuvre la commande d’une opération dans d’autres domaines connectés.

De plus, il n’est pas possible de partager ou d’échanger des ressources utiles à l’exécution d’applications par des systèmes informatiques de périphérie à accès multiple localisés dans des domaines différents. Actuellement, les architectures MEC ne permettent donc pas de commander des opérations en mode « inter-domaine ».

Par ailleurs, les architectures et les réseaux MEC actuels ne permettent pas non plus à différentes entités d’exécuter une tâche dans un domaine donné si cette tâche nécessite une ressource qui est absente du système informatique de périphérie à accès multiple déployé dans ce domaine.

Objet et résumé de l’invention

Afin d’améliorer la situation et de répondre à ce ou à ces inconvénients, il est proposé, de façon générale, un procédé de commande d’une application de service dans un réseau informatique de périphérie à accès multiple, le réseau comprenant une pluralité d’entités connectées entre elles, le procédé comportant:
- commander, par un module plateforme que comprend un première entité de ladite pluralité, une exécution d’une application de service installée dans une deuxième entité de la pluralité par l’intermédiaire d’une fonction mandataire comprise dans ladite deuxième entité, la deuxième entité étant distincte de la première entité.

Ceci permet la mise en œuvre d’échanges applicatifs inter-domaines. Ceci permet aussi d’effectuer une transmission d’applications et/ou d’utiliser des services au sein d’une ou de plusieurs entités au sein d’un réseau informatique de périphérie à accès multiple.

Dans les présentes, et de manière générale, un module désigne un composant informatique matériel ou logiciel intégré au réseau.

Dans les présentes, et de manière générale, les appellations « informatique de périphérie à accès multiple » et « MEC » sont utilisées de manière interchangeable. En outre, les appellations « entité » et « architecture » sont utilisées de manière interchangeable. Ainsi, une entité d’un réseau informatique de périphérie à accès multiple est une architecture MEC.

Dans les présentes, et conformément à ces appellations, il est ainsi défini qu’un réseau informatique de périphérie comprend une pluralité d’entités, c’est-à-dire au moins deux architectures MEC.

Dans les présentes, un service exécuté par une application est un service d’application, et de préférence, un service réseau tel qu’un service DNS ou un proxy d’application déployé dans une entité que comprend le réseau. Des exemples de services d’application comprennent, entre autres, des services de contrôle de robots industriels, des services de gestion de conditions environnementales, des services de communication entre des terminaux connectés, des services de collecte de mesures physiques, des services de partage d’informations entre des sites industriels, etc.

Dans une réalisation, le procédé comporte en outre :
- localiser un module parmi une pluralité de modules que comprend la deuxième entité ; et
- installer la fonction mandataire dans le module localisé.

Dans les présentes, et de manière générale, une fonction mandataire désigne une implémentation logicielle apte à permettre une interaction entre une entité hôte et une entité invitée. Par exemple, une fonction mandataire installée dans un module permet de mettre en œuvre une commande ou une action depuis un élément d’un réseau « hôte » qui l’abrite pour le compte d'un élément « invité » qui lui est externe, et ainsi permettre un accès à des services fournis par l’élément hôte.

Dans les présentes, la fonction mandataire peut aussi désigner un service réseau tel qu’un service DNS ou tout autre type de service mandataire pouvant être déployé l’une des entités.

Dans les présentes, le réseau comporte une pluralité d’entités, c’est-à-dire une pluralité d’architectures informatiques de périphérie à accès multiple, dites architectures MEC. La localisation du module dans une entité permet de provoquer la commande de l’exécution du service par une application installée dans une autre entité.

Ceci permet aussi au module localisé, appelé dans les présentes « module mandataire », de remplir un rôle d'intermédiaire entre plusieurs entités d’un réseau informatique de périphérie à accès multiple ou entre des entités de réseaux distincts.

Dans une réalisation particulière, la localisation du module est précédée par une localisation d’une entité courante parmi la pluralité d’entités connectées entre elles, le module à localisé étant compris dans ladite entité courante.

Dans une réalisation, le procédé comporte en outre :
- analyser une topologie du réseau pour identifier une présence d’un module courant dans une plateforme de périphérie à accès multiple du réseau, en vue de la localisation du module ;
- sélectionner ledit module courant en tant que module localisé, en vue de l’installation de la fonction mandataire.

L’identification de la présence d’au moins un tel module permet à celui-ci de servir de module mandataire, c’est-à-dire de définir une instance localisée au sein d’un élément matériel d’une architecture MEC. Cette instance peut être configurée pour servir d'intermédiaire avec une autre architecture MEC. Un tel module « mandataire » peut être un serveur physique ou encore un serveur virtuel instancié dans celui-ci.

Dans les présentes, la localisation d’un module parmi les modules que relie le réseau se fait en fonction d’une topologie du réseau.

Selon différents exemples, cette localisation se fait en fonction de la présence de ce module dans au moins un élément d’une entité du réseau de périphérie du réseau, parmi lesquels une plateforme de périphérie, un gestionnaire de plateforme de périphérie, une infrastructure de virtualisation de réseau virtuel du réseau ou encore un plan de données du réseau. Ces éléments seront décrits dans la suite des présentes en relation avec les figures.

En particulier, ceci permet à une entité d’exécuter à distance ce service d’application dans une autre entité, et plus généralement de la piloter.

Ceci permet aussi à un opérateur ou un donneur d’ordre d’une architecture MEC d’exécuter des services d’applications au sein d’une autre architecture MEC dont il n’est pas un opérateur ou un donneur d’ordre, et réciproquement.

Dans une réalisation, la fonction mandataire installée est configurée pour déléguer la commande de l’exécution de l’application de service à la deuxième entité.

Ceci permet de réaliser une interface entre des composants matériels ou logiciels appartenant à des entités distinctes.

Ceci permet aussi à un opérateur ou à un donneur d’ordre d’une entité d’un réseau informatique de périphérie donné de commander à distance des applications de service par l’intermédiaire d’une autre entité.

En outre, ceci permet l’utilisation et la combinaison de ressources des domaines auxquels chacune de ces entités appartient pour l’exécution de services d’applications.

Dans une réalisation, la localisation du module est mise en œuvre sur réception, par la première entité, d’une réponse de localisation à une requête de localisation correspondante.

Ceci permet de tester la présence et/ou la position du module localisé dans le réseau informatique de périphérie.

Dans une réalisation particulière, la requête de localisation et une réponse à celle-ci sont échangées entre des gestionnaires de plateformes de périphérie de la première et de la deuxième entité.

Dans une réalisation, l’installation de la fonction mandataire est mise en œuvre sur réception, par le module localisé, d’une requête de téléchargement de ladite fonction mandataire.

Ceci permet d’installer une fonction mandataire qui n’est pas initialement présente dans le module localisé.

Dans une réalisation particulière, la requête de téléchargement et une réponse à celle-ci sont échangées entre le module localisé et un gestionnaire de plateforme de périphérie de la première entité.

Dans une réalisation, la fonction mandataire est installée via une application de périphérie à accès multiple de la deuxième entité sur réception, par ladite application, d’une requête d’installation.

Ceci permet de provisionner, au module localisé, une fonction mandataire qui n’est pas initialement présente dans celui-ci.

Dans une réalisation particulière, la requête d’installation et une réponse à celle-ci sont échangées entre le module localisé et au moins une application de périphérie.

Dans une réalisation, la commande de l’exécution de l’application de service est mise en œuvre sur réception, par la deuxième entité, d’une requête de commande.

Dans une réalisation, la délégation de la commande de l’exécution de l’application de service est mise en œuvre sur réception d’une requête de représentation de la deuxième entité par la première entité.

De préférence, la requête de représentation est reçue par le module localisé.

Dans une réalisation, la commande de l’exécution de l’application de service comporte en outre une émission, par le module localisé et à destination de la première entité, d’une réponse de commande à la requête de commande.

Dans une réalisation, au moins une requête ou une réponse à au moins une requête est transmise via un point intermédiaire de référence connectant la première entité et la deuxième entité.

Il est aussi proposé un programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des réalisations précédentes, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement informatique.

Il est aussi proposé un support de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un processeur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l’une quelconque des réalisations précédentes.

D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :

, la figure 1 représente une vue schématique d’une entité que comprend un réseau informatique de périphérie selon une réalisation ;

, la figure 2, représente une vue schématique d’un réseau comprenant plusieurs entités selon une réalisation;

, la figure 3, représente une vue schématique de différentes réalisations de connexions entre plusieurs entités ;

, la figure 4, représente sous forme d’organigramme, des étapes d’un procédé de commande d’un réseau informatique de périphérie selon une réalisation;

, la figure 5, représente sous forme de diagramme de flux des étapes d’un procédé de commande d’un réseau informatique de périphérie selon une autre réalisation ;

, la figure 6, représente un bloc-diagramme schématique d'un circuit de traitement informatique selon une réalisation.

Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.

Les dessins et la description ci-après contiennent, pour l’essentiel, des éléments de caractère certain. Ils pourront donc servir à mieux faire comprendre la présente divulgation et à contribuer à sa définition, le cas échéant.

Il est maintenant fait référence à la figure 1, qui représente un exemple d’entité, c’est-à-dire une architecture MEC, que comprend un réseau informatique de périphérie à accès multiple selon une réalisation. Ce réseau comprend en particulier deux entités MEC1 et MEC2.

Différents éléments fonctionnels que comprend l’entité MEC1 sont illustrés de manière plus détaillée. Ces éléments fonctionnels sont regroupés en plusieurs niveaux, ou couches, parmi lesquelles un niveau système SL correspondant à une couche supérieure et un niveau hôte HL correspondant à une couche intermédiaire.

Concernant la couche intermédiaire, le niveau hôte HL comprend au moins un module hôte du réseau de périphérie, dit module hôte MECH (ou « Mobile Edge Computing Host », en anglais). Ce module hôte MECH permet, notamment, de fournir un moyen de stockage et de traitement d’informations.

Une module hôte MECH comprend au moins une plateforme de périphérie, dite module plateforme MEP (ou « Mobile Edge Platform », en anglais), une infrastructure de virtualisation de réseau virtuel, dite infrastructure VI (ou « Virtual Network Function Infrastructure », en anglais), ainsi qu’au moins une application de périphérie, dites application MEA (ou « Mobile Edge Applications », en anglais).

Typiquement, une application MEA est exécutable en tant que machine virtuelle sur l'infrastructure VI. Lorsqu’elle est exécutée, l’application MEA interagit avec le module plateforme MEP via au moins un point de référence Mp1, qui peut également être utilisé pour la mise en œuvre de procédures de support supplémentaires.

En outre, le point Mp1 fournit une interface reliant une ou plusieurs applications MEA à un module plateforme MEP, ce qui permet de contrôler l’état de telles applications. Ce contrôle est mis en œuvre de manière internalisée par rapport à un serveur qui héberge cette ou ces applications.

Un exemple d’application MEA est une application configurée pour indiquer les besoins en ressources ou en services du module hôte MECH, ou encore pour renseigner ou mettre à jour des contraintes relatives au module hôte MECH.

L’infrastructure VI fournit des ressources de calcul, de stockage et de réseau pour une ou plusieurs applications MEA. L'infrastructure VI comprend en outre un plan de commutation, dit couche de données, aussi dit plan de données DP (ou « Data Plane », en anglais), configuré pour exécuter les règles de transmission reçues par le module plateforme MEP.

Le plan de données DP est généralement compris dans l’infrastructure VI du module hôte MECH et permet, notamment, d’acheminer des données entre les différents services, applications et services associés à l’architecture.

Le module plateforme MEP que comprend le module MECH fournit un ensemble de fonctionnalités de base pour exécuter des applications sur une entité hôte et pour permettre à ces applications d’utiliser les services associés.

Ces fonctionnalités sont utilisées, par exemple, pour organiser le routage de données entre différentes applications, ou entre des services et/ou des réseaux interagissant avec une architecture MEC.

Le niveau hôte HL comprend en outre d’autres entités externes au module hôte MECH, telles qu’un gestionnaire de plateforme de périphérie à accès multiple de niveau hôte, dit gestionnaire MEPM (ou « Mobile Edge Platform Manager », en anglais), ou encore un gestionnaire d’infrastructure de virtualisation, dit gestionnaire VIM (ou « Virtual Infrastructure Manager », en anglais).

Le gestionnaire d’infrastructure de virtualisation VIM est relié à l’interface VI par le point de référence Mm7, ce qui permet de gérer les ressources virtualisées du module hôte MECH et/ou pour gérer d’éventuelles instanciations. Il est également utilisé pour conserver des informations sur les ressources disponibles.

Le gestionnaire MEPM reçoit les règles de transfert de trafic et gère notamment les cycles de vie des applications de périphérie mobile et des fonctions de gestion.

Le gestionnaire MEPM peut être une fonction soit locale soit centralisée dans une architecture MEC. Le gestionnaire MEPM permet de fournir des informations détaillées sur un ou plusieurs modules hôtes MECH déployés en différentes localisations, par exemple pour permettre de renseigner par exemple les adresses IP des serveurs qui les abritent.

Le gestionnaire MEPM est connecté au module plateforme MEP via le point de référence Mm5 qui lui permet de transmettre des instructions. Ces instructions peuvent être transmises du module plateforme MEP à l’interface VI via le point de référence Mp2.

Le point de référence Mp2 fournit une interface reliant la plateforme MEP au plan de données DP pour lui permettre de communiquer et transmettre des données.

Les points de référence Mp1 et Mp2 permettent d’échanger et de gérer des flux de données entre différentes entités du module hôte MECH, par exemple des signaux passant par le plan de données DP.

Le module plateforme MEP prend aussi en charge la configuration d’un éventuel serveur local, par exemple un serveur DNS, qui peut être utilisé pour diriger le trafic utilisateur vers des applications de périphérie souhaitées.

Le module hôte MECH de l’entité MEC1, et, en particulier, le module plateforme MEP du module hôte MECH, sont configurés pour échanger des données avec une autre architecture, ici représentée par l’entité MEC2.

Spécifiquement, une interface peut être réalisée entre les entités MEC1 et MEC2 au moyen d’un point de référence Mp3.

Comme illustré, ce point de référence Mp3 peut connecter le module hôte MECH de l’entité MEC1 à un deuxième module hôte MECH2 que comprend l’entité MEC2. En particulier, cette connexion peut être établie entre le module plateforme MEP du module hôte MECH de la première entité MEC1 et un autre module plateforme MEP2 du module hôte MECH2 que comprend la deuxième entité MEC2.

Au moins un module plateforme parmi MEP et MEP2 est une plateforme locale, c’est-à-dire une plateforme intégrée dans la topologie de l’entité correspondante MEC1 ou de celle de MEC2.

Le point de référence Mp3 permet d’échanger et de gérer des flux de données entre plusieurs entités, et en particulier, entre les architectures MEC que comprend le réseau RMEC.

La couche supérieure de l’entité MEC1, qui correspond au niveau système SL, comprend un système de support d’opérations, dit système OSS (ou « Operations Support System », en anglais), un proxy LCM (ou « Life Cycle Manager », en anglais) et un orchestrateur multi-accès, dit orchestrateur MEO (ou « Mobile Edge Orchestrator », en anglais), qui est configuré pour exécuter des applications de périphérie mobile.

De manière générale, le système OSS comprend au moins un système OSS, un système BSS (ou « Business Support System », en anglais) et/ou un système OSS/BSS.

L’orchestrateur MEO est agencé pour communiquer avec des applications installées sur un équipement utilisateur, dites applications UEA (ou « User Equipment Applications », en anglais), ou avec un portail CFS (ou « Customer-Facing Service », en anglais) qui sert de point d’entrée pour une application tiers.

Dans les présentes, une application UEA est une application web, c’est-à-dire une application manipulable directement en ligne grâce à un navigateur web. Typiquement, une telle application UEA ne nécessite pas d'installation sur une machine cliente.

Une application UEA permet de déplacer des applications entre des réseaux externes, par exemple des réseaux en nuage, et le réseau de périphérie. En particulier, une application UEA peut être une application de périphérie qui est instanciée dans un élément du niveau hôte HL en réponse à une demande d'un équipement.

Dans les présentes, le proxy LCM est un proxy de gestion du cycle de vie des applications utilisateur, et permet en outre aux applications de requérir l’intégration, l’instanciation, la résiliation d’applications utilisateur ou encore la relocalisation d’applications utilisateur à l’intérieur et à l’extérieur du réseau de périphérie mobile.

Au niveau système SL, une exécution d’une application de périphérie mobile peut être initiée par un équipement tiers par l’intermédiaire d’un point de référence situé entre une application UEA et le proxy LCM. L’exécution d’une telle application peut aussi être initiée par l’intermédiaire d’un autre point de référence situé entre le portail CFS et le système OSS.

Selon différents exemples, les différents éléments du niveau SL permettent de mettre en œuvre une ou plusieurs instanciations d’applications spécifiques dans le module hôte MECH, et en particulier, des instanciations effectuées sur demande d’une ou de plusieurs applications UEA d’un équipement utilisateur.

L’orchestrateur MEO est configuré pour avoir connaissance de la topologie de l’architecture MEC, de tous les modules hôte déployés dans l’architecture, ainsi que des services et des ressources disponibles dans chaque module hôte.

Le système OSS est quant à lui relié au niveau hôte NL via un point de référence Mm2 le connectant au gestionnaire MEPM et conçu pour déclencher l'instanciation et la fermeture d’applications de périphérie mobile du module hôte, par exemple.

Le point de référence Mm2 peut aussi être utilisé pour la gestion des pannes, de la configuration et des performances du module plateforme MEP.

L’orchestrateur MEO est connecté au gestionnaire MEPM via un point de référence Mm3, et est en outre connecté au gestionnaire VIM via un point de référence Mm4.

Il est maintenant fait référence à la figure 2, qui représente une vue schématique d’un réseau comprenant plusieurs entités ou architectures MEC selon une réalisation.

En particulier, un réseau RMEC comprend deux entités MEC et MEC2. Par exemple, l’entité MEC1 correspond à une architecture MEC d’un premier domaine, c’est-à-dire connectée à un premier réseau R, et qui est interfacée avec une architecture d’un deuxième domaine, c’est-à-dire connectée à un deuxième réseau R2, ce deuxième domaine étant distinct et éventuellement éloigné du premier domaine.

L’entité MEC1 comprend des éléments identiques à ceux décrits dans la figure précédente. L’architecture MEC correspondante comprend en outre un module de services MECS connecté au gestionnaire MEPM ainsi qu’à un premier espace industriel de données IDS-A. Le plan de données DP que comprend cette architecture MEC est connecté au premier réseau R, qui est par exemple un réseau en nuage d’une première usine du premier domaine.

L’autre entité MEC2 comprend des éléments analogues à ceux de l’entité MEC1, et notamment, un module hôte MECH2 comportant un module plateforme MEP2, au moins une application MEA2 et un plan de données DP2 connecté au deuxième réseau R2, par exemple un réseau en nuage d’une deuxième usine qui est éloignée de la première usine.

Ces entités sont connectées entre elles via des points Mp1’, Mp2’ et Mp3’ semblables aux points Mp1, Mp2 et Mp3 précédemment décrits.

L’entité MEC2 comprend en outre un gestionnaire MEPM2 connecté à un autre module de services MECS2, lui-même connecté au gestionnaire MEPM2 ainsi qu’à un deuxième espace industriel de données IDS-B.

Dans l’exemple représenté ici, le plan de données DP est utilisé pour commander un robot via le réseau R de la première usine, tandis que le plan de données DP2 est utilisé pour commander un autre robot via le réseau R2 de la deuxième usine.

En général, des robots de même type ou d’un même constructeur sont configurés de sorte qu’un même système cyber-physique peut être utilisé pour piloter ces robots en vue d’effectuer une tâche. En particulier, deux robots connectés à deux réseaux R et R2 distincts sont pilotables à distance par des donneurs d’ordre différents, ici par les deux espaces industriels de données IDS-A et IDS-B disposant du même système cyber-physique.

Le pilotage d’un robot via un réseau donné peut nécessiter des ressources absentes de l’architecture MEC connectée à ce réseau. Par exemple, un donneur d’ordre correspondant à l’espace industriel IDS-A ne pourra pas piloter un robot connecté au réseau R2 si ce pilotage nécessite une application présente dans MEA, mais absente de MEA2.

Par exemple, le site industriel du premier domaine ne dispose pas nécessairement des applications nécessaires pour effectuer un pilotage d’un robot sur le site industriel du deuxième domaine, même si le premier domaine comprend un robot similaire ou identique.

Pour échanger des informations, les entités MEC1 et MEC2 disposent d’interfaces inter-domaines. Il est décrit dans la suite comment améliorer leurs architectures correspondantes et les procédés associés pour permettre la transmission et l’exécution de ces applications.

Une interface entre les deux entités MEC1 et MEC2 est par exemple possible au moyen du point de référence Mp3 pour permettre à le module plateforme MEP de communiquer avec d’autres plates-formes, et notamment avec le module plateforme MEP2 du module hôte MECH2 que comprend la deuxième architecture MEC2.

Comme illustré, cette interface et cette communication se fait via le point de référence Mp3, qui connecte les modules plateforme MEP et MEP2. Le point de référence Mp3 est représenté comme appartenant à l’entité MEC1, mais celui-ci est équivalent au point de référence Mp3’ correspondant dans l’autre entité MEC2.

Comme décrit précédemment, l’interface réalisée au moyen du point intermédiaire Mp3 entre les entités MEC1 et MEC2 ne permet pas à elle seule de partager ou de transmettre une application exécutable d’une architecture MEC à une autre.

Par exemple, bien que le point de référence Mp3 permettant une interface entre deux architectures MEC rende possible un provisionnement d’une application de pilotage d’un robot d’une architecture à une autre, Mp3 ne permet pas à lui seul une exécution à distance d’une commande de pilotage de ce robot.

Une solution fournie par les présentes réalisations prévoit de créer une nouvelle interface.

Il est maintenant fait référence à la figure 3, qui représente une vue schématique de connexions entre deux entités, et plus précisément entre deux entités MEC1 et MEC2.

Un module MEPROXY est présent dans l’entité MEC2. Ce module est soit situé à l’extérieur du module plateforme MEP2 et relié à celle-ci et/ou au gestionnaire MEPM2, par exemple au moyen d’une connexion dans l’entité MEC2, soit installé directement dans le module plateforme MEP2.

Selon différentes variantes pouvant être combinées entre elles, au moins une interface entre les deux entités MEC1 et MEC2 est mise en œuvre au moyen de points de référence dits points de référence intermédiaires, pour permettre un échange applicatif inter-domaine.

Dans une première de ces variantes, une interface est définie par un point de référence intermédiaire MpId relie les gestionnaires MEPM et MEPM2 des deux architectures. Le point de référence intermédiaire MpId permet ainsi une communication directe ou indirecte entre les deux entités MEC1 et MEC2. Le point Mpid peut par exemple être situé dans un niveau hôte HL de la première architecture MEC ou de la deuxième architecture MEC qui correspondent aux entités.

Dans une deuxième de ces variantes, une interface est définie par un autre point de référence intermédiaire Mp1Id qui relie le module plateforme MEP de l’entité MEC1 au module MEPROXY de l’autre entité MEC2.

Dans une troisième de ces variantes, une interface est définie par encore un autre point de référence intermédiaire MpId’ relie le gestionnaire MEPM de l’entité MEC1 au module MEPROXY de l’autre entité MEC2.

De manière générale, une interface directe ou indirecte peut être mise en œuvre entre au moins trois architectures MEC au moyen de points de référence semblables à ceux précédemment décrits.

Il est maintenant fait référence à la figure 4, qui représente sous forme d’organigramme des étapes d’un procédé de commande d’un réseau informatique de périphérie à accès multiple selon une réalisation.

Une première étape S1 concerne la localisation du module MEPROXY au sein de l’entité MEC2. Par exemple, cette localisation est mise en œuvre au moins par l’échange d’une paire requête-réponse de localisation échangée entre deux entités MEC1 et MEC2 avec pour résultat de fournir la position du module au sein de MEC2, par exemple en renseignant son adresse IP.

Une deuxième étape S2, qui suit l’étape S1, concerne l’installation d’une fonction mandataire FPROXY dans au moins un module dont la localisation est connue. Par exemple, cette installation comprend un échange d’une paire requête-réponse d’installation de la fonction FPROXY. Par exemple, ladite paire requête-réponse d’installation est échangée entre le module MPEROXY localisé lors de l’étape S1 et au moins une application MEA2.

Une troisième étape S3, qui suit l’étape S2, concerne la commande d’une opération du réseau, en particulier d’une exécution d’une application de service. Par exemple, cette commande comprend un échange d’une paire requête-réponse de commande, ladite paire requête-réponse de commande étant échangée entre la première architecture MEC et le module MEPROXY qui comprend la fonction FPROXY installée au cours de l’étape S2.

Il est maintenant fait référence à la figure 5, qui représente sous forme de diagramme de flux d’étapes S10, S20, S30, S40, S50, S60, S70, S80, S90 et S100 d’un procédé de commande d’un réseau informatique de périphérie selon une autre réalisation.

Ces flux peuvent être des flux de données et/ou des flux de contrôle, aussi dits flux de commande. La transmission ou l’échange de flux de commande est rendue possible grâce aux réalisations décrites dans les présentes.

Comme illustré, le module MEPROXY et la fonction mandataire FPROXY sont représentés comme étant distincts et séparés du module plateforme MEP2. Cependant, ceci n’exclut pas que le module MEPROXY et la fonction mandataire FPROXY soient installés dans le module plateforme MEP2.

En lien avec les étapes décrites précédemment, l’étape S1 de localisation comprend les étapes S10 et S20, l’étape S2 d’installation comprend les étapes S30, S40, S50 et S60 et l’étape S3 de commande d’une opération du réseau, en particulier d’une exécution d’une application de service, comprend les étapes S70, S80, S90 et S100.

Comme illustré, lors de l’étape S10, le gestionnaire MEPM de l’entité MEC1 transmet une requête de localisation RQ-LOC vers le gestionnaire MEPM2 de l’entité MEC2. Ceci permet de requérir l’adresse du module MEPROXY. La requête de localisation RQ-LOC est transmise de préférence via le point de référence intermédiaire MpId.

Lors de l’étape S20, sur réception de la requête RQ-LOC, un message d’acquittement de localisation ACK-LOC est renvoyé depuis le gestionnaire MEPM2 à destination du gestionnaire MEPM. Ce message d’acquittement permet de renseigner la localisation du module MEPROXY à l’entité MEC1. Le message d’acquittement ACK-LOC est, de préférence, lui aussi transmis via le point de référence intermédiaire MpId.

L’accusé de réception ACK-LOC comprend une adresse IP du module MEPROXY localisé, par exemple l’adresse IP du serveur hébergeant celui-ci. Selon un autre exemple, et renseignée par le gestionnaire MEPM2.

Une fois l’adresse du module MEPROXY renseignée au gestionnaire MEPM de l’entité MEC1, le gestionnaire MEPM initie l’installation d’une ou de plusieurs applications dans l’entité MEC2, via la point de référence Mp1, le point de référence Mp3 ou encore le point de référence intermédiaire MpId. Cette installation est mise en œuvre au cours des étapes S30 à S60, afin de préparer l’installation de la fonction mandataire FPROXY dans le module MEPROXY.

L’étape S30 comprend la transmission d’une requête de téléchargement RQ-UP depuis le gestionnaire MEPM vers MEC2, en particulier vers le module MEPROXY de MEC2.

Selon différents exemples, la requête de téléchargement RQ-UP peut être transmise depuis un point central intégré à l’architecture MEC correspondant à MEC1 ou depuis un autre point tel qu’un serveur ou de tout autre type de dispositif relié à MEC1.

De préférence, l’étape S30 est mise en œuvre sur réception du message d’acquittement de localisation ACK-LOC, sur réception d’une information de localisation du module MEPROXY ou encore d’une instruction d’installation d’une application ou d’une fonction dans le module MEPROXY si la localisation de celui-ci est renseignée dans l’instruction d’installation.

En pratique, et par exemple, l’installation de la fonction mandataire FPROXY est mise en œuvre par un donneur d’ordre associé à l’entité MEC1, par exemple par un donneur d’ordre ayant accès à l’espace industriel de données IDS-A. Une installation ou une mise à jour de cette fonction peut être mise en œuvre au moyen d’un orchestrateur MEO ou d’un système OSS de l’une ou l’autre des entités MEC1 et MEC2.

Lors de l’étape S40, le module MEPROXY transmet une requête d’installation RQ-INST vers au moins une application MEA2 que comprend l’entité MEC2. Cette requête est de préférence transmise via le point Mp1’.

Selon différents exemples, le module MEPROXY et/ou la fonction FPROXY sont instanciés. Par exemple, le ou les systèmes OSS que comprennent les entités MEC1 et MEC2 sont connectés à la plateforme MEPM, et en outre configurés pour déclencher l'instanciation ou la fermeture de la fonction FPROXY.

Sur réception de la requête d’installation RQ-INST, la fonction mandataire FPROXY est installée dans la deuxième entité MEC2 lors de l’étape S40. Cette installation est mise en œuvre par au moins une application de périphérie MEA2. De préférence, la fonction FPROXY est installée directement dans le module MEPROXY.

Toujours sur réception de la requête d’installation RQ-INST, et faisant suite à l’installation de la fonction FPROXY, un message d’acquittement d’installation ACK-INST est envoyé lors de l’étape S50 par la deuxième entité MEC2 vers la première entité MEC1. En particulier, le message d’acquittement d’installation ACK-INST est transmis par le module MEPROXY vers le gestionnaire MEPM de l’architecture MEC.

De préférence, le message d’acquittement d’installation ACK-INST est transmis via le point de référence Mp1’.

Sur réception du message d’acquittement d’installation ACK-INST, et lors de l’étape S50, un message d’acquittement de téléchargement ACK-UP est transmis par le module MEPROXY vers le gestionnaire MEPM.

De préférence, le message d’acquittement d’installation ACK-INST est transmis via le point de référence intermédiaire MpId’.

Selon un autre exemple non représenté, le message d’acquittement de téléchargement ACK-UP peut être transmis lors de l’étape S50 et plus généralement sur réception de la requête de téléchargement RQ-UP, lorsque celle-ci permet de procéder directement à l’installation de la fonction FPROXY dans le module MEPROXY.

Le message d’acquittement d’installation ACK-INST permet d’indiquer au gestionnaire MEPM, et donc à l’entité MEC1, que l’installation de la fonction mandataire FPROXY est bien complétée.

Une fois l’installation de la fonction mandataire FPROXY terminée, le module plateforme MEP initie la commande d’une exécution d’une application de service au moyen de la fonction mandataire installée.

En particulier, cette commande comprend plusieurs étapes S70 à S100 permettant de garantir que la commande est initiée par un donneur d’ordre externe à l’entité MEC2, par exemple un donneur d’ordre ayant accès à l’espace industriel de données IDS-A plutôt qu’à l’espace industriel de données IDS-B.

Pour ce faire, une étape S70 est mise en œuvre et comprend la transmission d’une requête de commande RQ-CTRL depuis le module plateforme MEP vers l’entité MEC2, et en particulier vers le module MEPROXY que comprend MEC2.

Par exemple, cette requête peut correspondre à une demande provenant d’un donneur d’ordre associé à l’espace industriel de données IDS-A connecté à l’entité MEC1, afin de pouvoir exécuter une application dans l’entité MEC2.

Ainsi, si le gestionnaire MEPM2 est initialement configuré pour n’exécuter une application que sur la base de commandes provenant d’un donneur d’ordre associé à l’espace industriel de données IDS-B, l’installation de la fonction FPROXY dans le module MEPROXY permet de déléguer cette exécution au donneur d’ordre associé à l’espace industriel de données IDS-A.

De préférence, l’étape S70 est mise en œuvre sur réception du message d’acquittement de localisation ACK-UP, ou plus généralement sur réception d’une confirmation selon laquelle la fonction FPROXY est bien téléchargée et/ou installée dans le module MEPROXY.

Sur réception de la requête de commande RQ-CTRL, une mise en cache d’une application présente dans MEA2 est effectuée. Par « mise en cache » on entend ici que l’exécution de cette application, initialement permise à un premier donneur d’ordre, par exemple un donneur d’ordre associé à l’espace industriel de données IDS-A, est déléguée à un deuxième donneur d’ordre, par exemple un autre donneur d’ordre qui, lui, est associé à l’espace industriel de données IDS-B plutôt qu’à IDS-A.

En particulier, l’étape S80 met en œuvre cette mise en cache sur réception, par MEA2, d’une requête de mise en cache RQ-PROXY, cette requête de mise en cache étant transmise par le module MEPROXY, de préférence par l’intermédiaire du point Mp1’.

Lorsque la délégation de l’application est appliquée de sorte que son exécution soit désormais permise par le deuxième donneur d’ordre au lieu du premier donneur d’ordre uniquement, un message d’acquittement de mise en cache ACK-PROXY est transmis par MEA2 vers le module MEPROXY, afin de confirmer que la délégation de l’exécution de l’application concernée est bien effective.

Sur réception du message d’acquittement de mise en cache ACK-PROXY, et faisant suite à la délégation de l’exécution de l’application, un message d’acquittement de commande ACK-CTRL est envoyé lors de l’étape S100 par l‘entité MEC2 vers l’entité MEC1. En particulier, le message d’acquittement de commande ACK-CTRL est émis par le module MEPROXY depuis l’entité MEC2 vers le module plateforme MEP de l’entité MEC1.

Ce message d’acquittement de commande ACK-CTRL permet d’indiquer à l’entité MEC1 qu’une exécution d’une application de service peut être commandée au moyen de la fonction mandataire installée.

Lors de l’étape S100 ou lors d’une ou plusieurs étapes ultérieures à l’étape S100, une commande d’une exécution d’une ou de plusieurs applications de service au moyen de la fonction mandataire installée dans MEPROXY. Une telle commande comprend par exemple l’exécution d’une application permettant le contrôle d’un dispositif connecté, le pilotage d’un robot, la coordination d’un mouvement entre plusieurs machines-outils, ou encore la transmission d’informations ou de signaux vers un opérateur.

A titre illustratif, un espace industriel de données IDS-A est initialement client des services fournis par une architecture MEC appartenant à un premier domaine, ce client souhaitant se voir permettre l’utilisation d’un robot connecté dans un deuxième domaine associé à une autre architecture MEC.

Pratiquement, en un premier instant t1, le robot effectue des tâches pour un espace industriel de données IDS-B client des services fournis par l’entité MEC2. En un deuxième instant t2, la mise en œuvre des étapes S1 à S3 permet de mettre à disposition, via le premier domaine, depuis l’espace industriel de données IDS-A, une ou plusieurs ressources utilisables par celui-ci. Le premier domaine se charge ainsi d’exécuter une tâche qu’il ne pouvait pas exécuter initialement.

L’entité MEC1 est ainsi capable d’aller chercher des ressources ou des services pour le compte d’IDS-A dans un autre domaine.

En outre, chacun des domaines peut également exposer ou partager ses ressources de manière indépendante, de manière à les rendre disponibles à plusieurs autres domaines.

La figure 6 représente un bloc-diagramme schématique d'un circuit de traitement informatique selon un exemple de mise en œuvre des réalisations décrites.

Selon un exemple, ledit circuit de traitement informatique est un processeur. De préférence, un tel circuit de traitement informatique est un système sur puce 1000 agencé pour mettre en œuvre un procédé de commande d’un réseau informatique de périphérie. En particulier, ce circuit de traitement informatique peut correspondre à un élément matériel définissant le module MEPROXY, un module plateforme MEP ou encore un gestionnaire MEPM.

De manière non limitative, le système sur puce 1000 comporte un bus de communication connecté, par exemple, à une unité centrale de traitement 1010, tel qu'un processeur ou un microprocesseur, et notée CPU.

Le système sur puce 1000 comporte en outre une mémoire à accès aléatoire 1020, notée RAM, apte à mémoriser le code exécutable du procédé de commande ainsi que les registres adaptés à enregistrer des variables et des paramètres nécessaires pour la mise en œuvre du procédé selon des modes de réalisation, la capacité de mémoire de celui-ci peut être complétée par une mémoire RAM optionnelle connectée à un port d'extension, par exemple.

En outre, le système sur puce 1000 comporte une mémoire morte 1030, notée ROM, pour stocker des programmes informatiques pour la mise en œuvre des réalisations décrites précédemment, ainsi qu’une interface réseau 1040 qui est normalement connectée à un réseau de communication sur lequel des données numériques à traiter sont transmises ou reçues.

L'interface réseau 1040 peut être une seule interface réseau, ou composée d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans fil, interfaces ou différents types d'interfaces filaires ou sans fil).

Des paquets de données sont envoyés sur l'interface réseau pour la transmission ou sont lues à partir de l'interface de réseau pour la réception sous le contrôle de l'application logiciel exécuté dans le processeur ou le microprocesseur 1010.

Par ailleurs, le système sur puce 1000 comporte une interface utilisateur 1050 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur, un support de stockage optionnel 1060 noté HD, et un module d’entrée-sortie 1070, noté IO, pour la réception, l'envoi de données depuis ou vers des périphériques externes tels que disque dur, support de stockage amovible ou autres.

Dans un exemple présenté ici, le code exécutable peut être stocké dans une mémoire morte 1030, sur le support de stockage 1060 ou sur un support amovible numérique tel que par exemple un disque.

Selon une variante, le code exécutable des programmes peuvent être reçu au moyen d'un réseau de communication, via l'interface réseau 1040, afin d'être stocké dans le support de stockage 1060, avant d'être exécuté.

L'unité centrale de traitement 1010 est adaptée pour commander et diriger l'exécution des instructions ou des portions de code logiciel du programme ou des programmes selon l'un des modes de réalisation, instructions qui sont stockées dans l'un des moyens de stockage précités. Après la mise sous tension, le CPU 1010 est capable d'exécuter des instructions stockées dans la mémoire RAM principale 1020, relatives à une application logicielle, après que ces instructions aient été chargées de la ROM par exemple.

Dans l’exemple présenté ici, le système sur puce 1000 est un appareil programmable qui utilise un logiciel. Toutefois, à titre subsidiaire, la présente description peut être mise en œuvre dans n’importe quel type de matériel (par exemple, sous la forme d'un circuit intégré spécifique ou ASIC).

Claims (13)

1. Procédé de commande d’une application de service dans un réseau informatique de périphérie à accès multiple (RMEC), le réseau comprenant une pluralité d’entités (MEC1, MEC2) connectées entre elles, le procédé comportant:
   - commander (S3 ; S70, S80, S90, S100), par un module plateforme (MEP) que comprend une première entité (MEC1) de ladite pluralité, une exécution d’une application de service installée dans une deuxième entité (MEC2) de la pluralité par l’intermédiaire d’une fonction mandataire (FPROXY) comprise dans ladite deuxième entité, la deuxième entité étant distincte de la première entité.
   
2. Procédé selon la revendication 1, comportant en outre:
   - localiser (S1 ; S10, S20) un module (MEPROXY) parmi une pluralité de modules que comprend la deuxième entité (MEC2) ; et
   - installer (S2 ; S30, S40, S50, S60) la fonction mandataire (FPROXY) dans le module localisé.
   
3. Procédé selon la revendication 2, comportant en outre :
   - analyser une topologie du réseau pour identifier une présence d’un module courant dans une plateforme de périphérie à accès multiple du réseau, en vue de la localisation du module ; et
   - sélectionner ledit module courant en tant que module localisé, en vue de l’installation de la fonction mandataire.
   
4. Procédé selon l’une quelconque des revendications 2 à 3, dans lequel la fonction mandataire (FPROXY) installée est configurée pour déléguer la commande de l’exécution de l’application de service à la deuxième entité (MEC2).
   
5. Procédé selon l’une quelconque des revendications 2 à 4, dans lequel la localisation du module est mise en œuvre sur réception (S20), par la première entité (MEC1), d’une réponse de localisation (ACK-LOC) à une requête de localisation correspondante (RQ-LOC).
   
6. Procédé selon l’une quelconque des revendications 2 à 5, dans lequel l’installation de la fonction mandataire est mise en œuvre sur réception (S30), par le module localisé, d’une requête de téléchargement (RQ-UP) de ladite fonction mandataire.
   
7. Procédé selon l’une quelconque des revendications 2 à 6, dans lequel la fonction mandataire (FPROXY) est installée via une application de périphérie à accès multiple (MEA2) de la deuxième entité (MEC2) sur réception (S40), par ladite application, d’une requête d’installation (RQ-INST).
   
8. Procédé selon l’une quelconque des revendications 2 à 7, dans lequel la commande de l’exécution de l’application de service est mise en œuvre sur réception (S70), par la deuxième entité (MEC2), d’une requête de commande (RQ-CTRL).
   
9. Procédé selon l’une quelconque des revendications 2 à 8, dans lequel une délégation de la commande de l’exécution de l’application de service est mise en œuvre sur réception (S90) d’une requête de représentation (RQ-PROXY) de la deuxième entité (MEC2) par la première entité (MEC1).
   
10. Procédé selon l’une quelconque des revendications 8 à 9, dans lequel la commande de l’exécution de l’application de service comporte en outre une émission (S100), par le module localisé et à destination de la première entité (MEC1), d’une réponse de commande (ACK-CTRL) à la requête de commande (RQ-CTRL).
11. Procédé selon l’une quelconque des revendications 5 à 10, dans lequel au moins une requête ou au moins une réponse à une requête est transmise via un point intermédiaire de référence (Mpid, Mp1id) connectant la première entité (MEC1) et la deuxième entité (MEC2).
    
12. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 11, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement informatique.
    
13. Support de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un processeur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 11.