EP4684516A1 - Procédé de mise à jour d'un modèle opérationnel courant d'un équipement d'un réseau de communication - Google Patents

Procédé de mise à jour d'un modèle opérationnel courant d'un équipement d'un réseau de communication

Info

Publication number
EP4684516A1
EP4684516A1 EP24708823.0A EP24708823A EP4684516A1 EP 4684516 A1 EP4684516 A1 EP 4684516A1 EP 24708823 A EP24708823 A EP 24708823A EP 4684516 A1 EP4684516 A1 EP 4684516A1
Authority
EP
European Patent Office
Prior art keywords
equipment
digital replica
data
training
software function
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24708823.0A
Other languages
German (de)
English (en)
Inventor
Xavier Marjou
Antoine LE BORGNE
Gaël FROMENTOUX
Benoit Radier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4684516A1 publication Critical patent/EP4684516A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication

Definitions

  • the invention is in the field of communication networks. More particularly, the invention relates to the problems of maintaining the continuity and quality of the service provided via such networks, when the software functionalities of a particular piece of network equipment are required to evolve.
  • a communication network is generally based on an infrastructure comprising numerous devices of various origins and natures, which communicate with each other to ensure the operation of the network and the provision of a service.
  • each device is composed of a hardware part and a software part.
  • the present technique makes it possible to propose a solution aimed at remedying certain drawbacks of the prior art.
  • the present technique relates in fact to a method for updating a current operational model of a first device of a communication network, following a modification of at least one software function of a second device of said communication network, with which the first device is interfaced.
  • Such a method comprises, at the level of said first device, the following steps:
  • the generation of an updated operational model of the first equipment can be implemented in parallel with the production operation governed by the current operational model of the first equipment.
  • the production operation according to the current operational model remains maintained as long as the generation of a new model is in progress, then updated as soon as the generation of this new model is completed.
  • said at least one piece of access data to the digital replica of the second equipment takes the form of a container comprising said digital replica.
  • said method comprises a step of instantiating, locally, from said container, said digital replica.
  • the training of the experimental model is carried out locally, within the first equipment or at least within equipment close to the first equipment, thus making it possible to increase the speed of implementation of this training, to secure its execution, and to avoid overloading the communication network thanks to the confinement thus obtained of the data exchanges between the first equipment and the digital replica of the second equipment.
  • said method comprises, prior to said reception step, a step of transmitting a request for access to the digital replica of the second device.
  • said access request is issued:
  • the training of an experimental model with a view to obtaining a new current operational model of the first equipment can in particular be triggered automatically, on the basis of one or more criteria, which makes it possible to obtain an updated operational model more quickly for the first equipment.
  • the duration during which a current operational model of the first equipment remains in force - even if this model has become obsolete or unsuitable following the modification or deployment of at least one software function on a second equipment with which the first equipment is interfaced - is thus significantly reduced.
  • said digital replica is implemented in the form of a reinforcement learning environment.
  • said training step comprises:
  • exploratory step corresponding to a first training phase of the reinforcement learning type, in which at least one exchange between said first equipment and said modified software function implemented by said digital replica is used to train a first experimental model, said exploratory step delivering a data set in which at least part of said exchanges is traced;
  • consolidation step corresponding to a second training phase of the supervised learning type, in which said data set is used to train a second experimental model
  • said consolidation step delivering, at the end of said supervised learning, said updated operational model.
  • each exchange of said at least one exchange comprises:
  • the successive actions sent to the digital replica within the framework of said at least one exchange being determined so as to tend to maximize over time the reward data received in response to these actions, said exchanges being traced within said data set only when a predetermined reward level is reached.
  • the proposed technique allows the implementation of hybrid learning combining the advantages of reinforcement learning and supervised learning: the exploratory step makes it possible to identify without operational impact the best communication sequences between devices, and the consolidation step to deduce the best forced march (i.e. the message sequences closest to the most relevant message sequences tested during the exploratory step) to be implemented in practice in production conditions.
  • the best forced march i.e. the message sequences closest to the most relevant message sequences tested during the exploratory step
  • said training step comprises a curative step of manual and/or automatic processing of said data set, prior to said consolidation step.
  • the present technique also relates to a device for updating a current operational model of a first piece of equipment of a communication network, following a modification of at least one software function of a second piece of equipment of said communication network, with which the first piece of equipment is interfaced.
  • a device for updating a current operational model of a first piece of equipment of a communication network, following a modification of at least one software function of a second piece of equipment of said communication network, with which the first piece of equipment is interfaced.
  • Such a device comprises, within said first piece of equipment:
  • the proposed technique also relates to a computer program product downloadable from a communication network and/or stored on a computer-readable medium and/or executable by a microprocessor, comprising program code instructions for executing a method of updating a current operational model of a first equipment of a communication network as described above in any of its embodiments, when executed on a computer.
  • the proposed technique also relates to a computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing the steps of the method as described above, in any of its embodiments.
  • Such a recording medium may be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a USB key or a hard disk.
  • such a recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the computer program contained therein is remotely executable.
  • the program according to the invention may in particular be downloaded over a network, for example the Internet.
  • FIG-1 illustrates the general principle of a method for updating a current operational model of equipment in a communication network, in a particular embodiment of the proposed technique
  • FIG.2 presents a sequence diagram of the method of updating a current operational model of equipment in a communication network, in a particular embodiment of the proposed technique
  • FIG.3 describes a simplified architecture of a device for implementing the proposed technique, in a particular embodiment.
  • the present technique relates to a method for updating a current operational model of a device of a communication network.
  • current operational model is meant here the set of software rules - implemented in the form of program code instructions executed by at least one processor - which govern the current operation of the device considered, including the management of its interactions with other devices of the communication network with which it is interfaced.
  • a "device" according to the present technique is understood in the broad sense: it can correspond in a conventional manner to a physical resource (e.g. all or part of a machine), but also to a service implemented within a machine such as for example a virtualization service used for the implementation of virtualized architectures.
  • the software rules can then for example correspond to rules associated with instances of virtualized functions of such a virtualized architecture.
  • this method relates more particularly to the updating of the current operational model MOC of a first equipment El of a communication network, following a modification of at least one FL software function of a second E2 equipment of the communication network, with which the first equipment is interfaced.
  • a software modification is part, for example, of corrective and/or evolutionary maintenance operations implemented on the second E2 equipment, and may in particular result from an update of one or more already existing software functions, and/or from a deployment of new software functions within the second E2 equipment.
  • the method according to the present technique is implemented within the first equipment El, and it comprises the steps detailed below, in a particular embodiment.
  • the first device E1 receives, from a third-party device of the communication network (typically from the second device E2, but this example is not limiting), at least one access data to a digital replica RNE2 of said second device E2.
  • digital replica we mean here a digital copy of the physical object that is the second device E2, i.e. a virtual representation designed to faithfully simulate, in software, the states, characteristics and operating dynamics of the second device E2. According to a particular characteristic, this digital replica corresponds for example to a digital twin of the second device E2.
  • the access data to the RNE2 digital replica can take different forms, depending on the implementation mode of this replica.
  • the access data received in step 11 take for example the form of coordinates (e.g. IP address, URL, port number, etc.) allowing the first equipment El to connect to a remote server (which may or may not be integrated into the equipment E2) within which the digital replica RNE2 is deployed: the first equipment El then remotely accesses the digital replica of the second equipment E2, this digital replica being installed on a machine different from the first equipment El.
  • coordinates e.g. IP address, URL, port number, etc.
  • the access data received in step 11 can also take the form of a container (or "package", in English) comprising the digital replica, in other words all the data necessary for the instantiation of such a digital replica.
  • This container is for example received from a remote server, which may or may not be integrated into the equipment E2.
  • the method according to the present technique then comprises a step of instantiating, locally, from the container received, the replica digital of the second E2 equipment: the first El equipment then locally accesses the digital replica of the second E2 equipment, this digital replica RNE2 being installed within the first El equipment itself (for example within a memory of the first El equipment) or at least within a nearby equipment forming part of the same local or private network (eg the same intranet) as the first El equipment, which has the advantage of not unnecessarily overloading the communication network with multiple exchanges of messages between remote network equipment during the subsequent use of the digital replica, in particular when the El and E2 equipment are interfaced via an extended communication network.
  • the first device E1 is able to communicate with the digital replica of the device E2, either because it has the information enabling it to connect to a device within which an instance of such a digital replica is deployed, or because it has itself been able to download and deploy within it an instance of such a digital replica.
  • a verification operation is carried out by the first device before launching such a download, in order to ensure that the digital replica about to be downloaded corresponds to a recent version (i.e. a new, up-to-date version) of the digital replica, and not to an old version which would have already been previously downloaded and installed within the first device (in which case the download is not carried out).
  • a verification can for example be implemented by comparing distinct control hash data identifying the different versions of a digital replica of the same device.
  • the digital replica is used to train an experimental model associated with the first equipment El.
  • “experimental model” it is meant that such training is carried out in an experimental mode (as opposed to an operational mode), that is to say without impact on the current operational operation of the first equipment El within the communication network.
  • the current operational model MOC which governs the operation of the first equipment El remains in force. The training is therefore carried out in parallel with the production operation of the first equipment El, without impact on this operation (there is therefore no interruption of service at the level of the equipment El which would be due to this training).
  • access to the digital replica of the second equipment E2 is therefore used by the first equipment El to determine a new operating model of the first equipment El adapted to the developments of the second equipment E2, i.e. to the modifications previously made to one or more of the software functions of this equipment E2 with which the first equipment El is interfaced.
  • the experimental model is trained on the basis of data exchanged between the first equipment El and the digital replica of the second equipment E2. More particularly, as detailed later in this document, machine learning techniques are implemented, in which on the one hand data associated with requests issued by the first equipment El to the digital replica and on the other hand data obtained from the digital replica (and in particular from the modified software function implemented by the digital replica) in response to these requests are analyzed and used to train the experimental model.
  • a step 13 once the experimental model is considered to be sufficiently trained, it can be deployed as a new current operational model of the first equipment El, thus governing the new operation of this equipment in production conditions. In other words, this new current operational model replaces the operational model previously implemented within the first equipment El.
  • step 11 of receiving access data to the digital replica RNE2 of the second equipment E2 follows the transmission, by the equipment El, of a request for access to such a digital replica.
  • a request is for example transmitted to the second equipment E2, or to a third-party equipment (for example a server dedicated to hosting or providing digital replicas of equipment of the communication network).
  • the access request is for example issued repeatedly, possibly periodically.
  • a request is issued daily by the first device, preferably at a time when traffic on the communication network is reduced (e.g. at night).
  • traffic on the communication network is reduced (e.g. at night).
  • the access data to the digital replica takes the form of a potentially relatively large container to be downloaded from a remote server, it is possible to limit the impact of this download operation on the performance of the communication network, by triggering it preferentially in a period of low load of this network.
  • the access request can also be sent upon receipt, by the first equipment E1, of a command to recover the digital replica, or upon receipt of information representing the availability of a new digital replica (i.e. a recently updated digital replica) from the second equipment E2.
  • a command and/or such information are for example received from the second device E2, or from a third-party device different from the second device.
  • the command to retrieve a digital replica can in particular be forced manually, for example by interaction of a user on a dedicated element of a graphical interface made available to him.
  • the reception of information representative of the availability of a new digital replica can be part of a prior subscription, by the first device, with another device (typically the second device), to a notification service for events of this type.
  • the access request is issued upon detection, by the first equipment E1, of a drop in performance associated with the exchanges between the first equipment E1 and the second equipment E2.
  • a drop in performance is evaluated via the monitoring of at least one dedicated performance indicator (or KPI, from the English “Key Performance Indicator”), such as for example an abnormally high rate of error messages received from the second equipment in response to requests issued to its destination by the first equipment, or any other relevant indicator.
  • the digital replica RNE2 of the second device is implemented in the form of a reinforcement learning environment, thus allowing the implementation of reinforcement learning techniques in this step 12 of training an experimental model.
  • the originality of the proposed technique lies however in the fact that the reinforcement learning implemented here does not have as its primary objective to train a model (as is generally the case in conventional approaches), but to construct a JD data set intended to serve as a learning base for the implementation of another, subsequent learning phase, this time no longer based on reinforcement learning but on supervised learning.
  • training step 12 comprises:
  • a so-called exploratory step 121 corresponding to a first training phase of the reinforcement learning type, in which a succession of exchanges (at least one) between the first equipment El and the modified software function implemented by the digital replica RNE2 of the second equipment E2 is used to train a first experimental model, this exploratory step delivering a data set JD in which at least part of said exchanges is traced;
  • consolidation step 122 corresponding to a second phase supervised learning type training, in which the JD data set obtained at the end of the first phase is used (possibly after control and adaptation by a human operator) to train a second experimental model
  • this consolidation step delivering, once the supervised learning is complete, the updated operational model MOA intended to be deployed as the new current operational model MOC of the first equipment (in accordance with step 13 of [Fig.l]).
  • Each of these exchanges includes, according to the usual vocabulary in reinforcement learning:
  • the state data are representative of a new state of the reinforcement learning environment, i.e. of the digital replica, following the action carried out on this environment.
  • the reward data is representative of one or more metrics of effectiveness of the action performed on the environment, or at least data allowing the first device to calculate such metrics.
  • the successive actions sent to the digital replica are determined by a reinforcement algorithm, so as to tend to maximize over time the reward data received in response to these actions.
  • a reinforcement algorithm so as to tend to maximize over time the reward data received in response to these actions.
  • all subsequent data exchanges carried out during this exploratory step are traced (for example in a trace file, in a database, or any other suitable data structure), thus participating in the construction of a JD data set representative of sequences of actions which can be considered relevant or effective (because associated with high rewards obtained) with respect to the digital replica implementing the modified software function.
  • each sample of such a data set JD comprises salient information relating to a data exchange between the first equipment El and the digital replica RNE2 (and in particular the modified software function) of the second equipment E2.
  • salient information comprises for example:
  • - data relating to the result returned by the digital replica of the second device in response to this action comprising for example state data representative of a consequence of the action on the environment, associated reward data, complementary data (for example data representative of one or more efficiency metrics with regard to the exchange considered), an identifier of the digital replica of the second device (for example also taking the form of a decentralized identifier), and possibly a timestamp representative of the time of receipt of this response.
  • the JD dataset is then used for the implementation of the consolidation step 122, in which it serves as a learning base for the supervised training of a second experimental model (such training may, depending on the case, be carried out on the basis of a blank model, i.e. from scratch, or from a previous version of the model if its architecture allows it - e.g. “Transformer” type model - and if there is no major change in the actions and states associated with the digital replica implementing the modified software function).
  • a blank model i.e. from scratch
  • a previous version of the model if its architecture allows it - e.g. “Transformer” type model - and if there is no major change in the actions and states associated with the digital replica implementing the modified software function.
  • the JD data set obtained at the end of the exploratory step 121 is made available to a user (for example via a dedicated graphical interface provided by the first device) before the consolidation step 122 is performed, for consultation and possible modifications and/or adaptations before the implementation of the supervised training.
  • a curative step of processing the data set prior to its use as a learning base makes it possible to retain human expertise in the process of training the experimental model.
  • FIG.2 a sequence diagram illustrating in time an example of possible interactions between different entities of the first equipment El, including the implementation of the method of updating the current operational model of this equipment, according to some of the particular embodiments described above.
  • the current operational model MOC of the first equipment El governs the operation of this equipment, and is notably requested, in a step 201, to determine an action to be implemented with respect to a second equipment E2, within the framework of a data exchange 202 between these two equipments.
  • a data exchange is established between a communication interface II of the first equipment El, and a communication interface 12 of the second equipment E2 (the communication interface 12 being the only entity of the second equipment E2 represented in [Fig. 2], this equipment being illustrated here as a “black box”).
  • a step 203 At the end of each exchange 202, in a step 203, at least one performance indicator associated with the exchange carried out is sent to a control module CTRL of the first equipment E1.
  • steps 201, 202 and 203 are repeated for all the exchanges between the first equipment E1 and the second equipment E2 in operational mode.
  • control module CTRL detects, on the basis of one of the performance indicators obtained in step 203, a drop in performance associated with the exchanges between the first equipment E1 and the second equipment E2, it requests from the second equipment E2, via its communication interface II, in a step 204, access to a digital replica RNE2 of this equipment E2.
  • a drop in performance may in particular result from the addition and/or modification, within the second equipment E2, of at least one software function FL.
  • the control module CTRL is authorized to download, in a step 205, a container comprising all the data necessary for an installation of the digital replica of the second equipment.
  • control module CTRL then instantiates within a memory of the first equipment El, in a step 206, an instance of the digital replica RNE2 of the second equipment, this digital replica taking the form of a reinforcement learning environment implementing the modified software function FL.
  • the control module CTRL also instantiates, in a step 207, a first experimental model MEXP1.
  • a first reinforcement learning type PHI phase is then implemented, in which the experimental model MEXP1 is trained on the basis of multiple data exchanges 208 (generally a very large number, eg thousands or even millions of exchanges) with the digital replica RNE2, by trial and error, as already described in relation to [Fig.l].
  • the subsequent data exchanges are traced, in a step 209, within a data set.
  • the control module CTRL requests and retrieves, in a step 210, the data set thus constituted.
  • This data set is transmitted to a second experimental model MEXP2 instantiated by the control module CTRL in a step 211.
  • a second phase PH2 of the supervised learning type is then implemented, in which the experimental model MEXP2 is trained on the basis of the samples present in the data set, during numerous iterations of a step 212.
  • a Tissue of the second supervised learning phase PH2 the experimental model MEXP2 is considered to be sufficiently trained to be used as an updated operational model of the first equipment EL II is therefore recovered by the control module CTRL in a step 213, then deployed in production in a step 214, as a new current operational model MOC of the first equipment El, relevant for the implementation of efficient data exchanges with the second equipment E2 implementing the modified software function FL.
  • the implementation of the first reinforcement learning phase makes it possible to avoid the tedious and time-consuming task of manually specifying and writing a set of tests each time a software function is introduced or updated within a device of the communication network.
  • the digital replica of the second device is instantiated locally, for example within a memory of the first device or within a nearby device that is part of the same local or private network (eg the same intranet)
  • the acquisition of experience intrinsic to reinforcement learning is carried out locally, possibly directly on the learning machine (i.e.
  • the update of the operational model of a device, and in particular of its communication model with the other devices of the network can thus be prepared autonomously within this device.
  • the generation of an updated operational model is implemented in parallel with the production operation governed by the current operational model of this device, this operation remaining maintained and not impacted as long as this generation is in progress.
  • the fact of combining two learning methods presents a certain interest, by offering a mechanism allowing, throughout the life cycle of the equipment, by the use of efficiency metrics, to combat the inevitable obsolescence in the long term of an operational model which would result solely from supervised learning (i.e. without taking risks), by allowing an update of the operational model on the basis of new data resulting from reinforcement learning (i.e. non-fixed data, resulting from the exploration of new options and possibilities of dialogue with the equipment of which a software function has been updated).
  • the proposed technique allows, thanks to the exploratory step, to identify without operational impact the best sequences of communications between equipment, then to deduce from it, thanks to the consolidation step, the best forced march (i.e. the sequences of messages closest possible to the most relevant sequences of messages previously tested during the exploratory step) to be implemented in practice in production conditions.
  • the proposed technique is also of interest to the manufacturer or administrator of the equipment of which at least one software function is modified, since he is freed from the constraint of having to systematically document in detail the proposed updates or share their source code.
  • the present technique can indeed be implemented even when the second equipment or its digital replica are implemented in a “black box” mode, with obfuscated or undocumented code for example.
  • the proposed technique can also be applied to the updating of a current operational model of a device of a communication network when not just one but several other devices with which it is interfaced have been the subject of recent software function updates.
  • a reinforcement learning phase is conducted for each of these other devices, in relation to a digital replica of each device, and the different data sets obtained following these reinforcement learning phases are concatenated to form a single set used in the second supervised learning phase to train an experimental model and deliver an updated operational model that is efficient and relevant for multi-device communications.
  • the proposed technique can also be used to select a preferred software function to be deployed within a device from a plurality of available software functions (e.g. developed for testing purposes), by testing (e.g. using different versions of a digital replica of a device) these different possible options in connection with the devices already deployed.
  • testing e.g. using different versions of a digital replica of a device
  • the proposed technique also relates to a device for updating a current operational model of a first device of a communication network, following a modification of at least one software function of a second device of said communication network, with which the first device is interfaced.
  • a device integrated within the first device, is capable of carrying out the method previously described in any of its embodiments. More particularly, such a device according to the present technique comprises:
  • the device according to the proposed technique, implemented within a first device of a communication network, comprises for example a memory 31 consisting of a buffer memory M, a processing unit 32, equipped for example with a microprocessor iiP, and controlled by the computer program Pg 33, implementing steps of the method for updating a current operational model of the first device according to at least one embodiment of the invention.
  • the device also comprises at least one communication interface (for example an Ethernet communication interface), allowing it to receive and transmit messages from and to other devices present in the communication network.
  • the code instructions of the computer program 33 are loaded into the buffer memory before being executed by the processor of the processing unit 32.
  • the processing unit 32 receives as input E, for example, a message indicating the availability of a new digital replica of a second device with which the first device is interfaced.
  • the microprocessor of the processing unit 32 then carries out the steps of the method for updating the current operational model of the first equipment, according to the ins- instructions of the computer program 33. More particularly, the first equipment receives access data to the digital replica of the second equipment, then uses this digital replica to train an experimental model based on data exchanged in particular with a modified software function implemented by said digital replica. This training delivers at its end an updated operational model, which is then transmitted by the processing unit 32 at output S, for deployment in production within the first equipment, in place of the current operational model which has become obsolete.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Databases & Information Systems (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Software Systems (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention se rapporte à un procédé de mise à jour d'un modèle opérationnel courant (MOC) d'un premier équipement (E1), consécutivement à une modification d'au moins une fonction logicielle (FL) d'un deuxième équipement (E2) avec lequel le premier équipement est interfacé. Un tel procédé comprend, au niveau du premier équipement : - la réception (11) d'au moins une donnée d'accès à une réplique numérique (RNE2) du deuxième équipement, ladite réplique numérique implémentant ladite fonction logicielle modifiée; - l'entrainement (12) d'un modèle expérimental associé au premier équipement, en fonction de données échangées entre le premier équipement et ladite fonction logicielle modifiée implémentée par ladite réplique numérique, délivrant un modèle opérationnel actualisé (MOA); - le déploiement (13) dudit modèle opérationnel actualisé en tant que nouveau modèle opérationnel courant du premier équipement.

Description

Description
PROCÉDÉ DE MISE À JOUR D'UN MODÈLE OPÉRATIONNEL COURANT D'UN ÉQUIPEMENT D'UN RÉSEAU DE COMMUNICATION
Domaine technique
[0001] L’invention se situe dans le domaine des réseaux de communication. Plus particulièrement, l’invention se rapporte aux problématiques de maintien de la continuité et de la qualité du service assuré via de tels réseaux, lorsque les fonctionnalités logicielles d’un équipement particulier du réseau sont amenées à évoluer.
Art antérieur
[0002] Un réseau de communication repose généralement sur une infrastructure comprenant de nombreux équipements d’origine et de nature variées, qui communiquent entre eux pour assurer le fonctionnement du réseau et la fourniture d’un service. À cette fin, chaque équipement est composé d’une partie matérielle (« hardware » en anglais) et d’une partie logicielle (« software » en anglais).
[0003] Pour de multiples raisons, il est fréquent que la partie logicielle d’un équipement soit amenée à évoluer. Par exemple dans le cadre d’opérations de maintenance corrective (résolution de problèmes de fonctionnement identifiés au sein de l’équipement, par déploiement de correctifs) ou évolutive (ajout de nouvelles fonctionnalités à l’équipement), des fonctions logicielles existantes sont généralement corrigées ou modifiées, et/ou de nouvelles fonctions logicielles sont régulièrement ajoutées, modifiant ainsi le comportement de l’équipement en question.
[0004] Bien qu’elles visent généralement à améliorer les performances du réseau de communication (et, in fine, du service fourni) dans son ensemble, de telles mises à jour d’un équipement ne sont cependant pas sans risques, notamment parce qu’elles sont susceptibles d’ entrainer des effets de bord sur les autres équipements du réseau de communication, et en premier lieu sur ceux s’interfaçant avec l’équipement mis à jour.
[0005] Les équipements interconnectés d’un réseau de communication étant généralement fournis par différents équipementiers, il n’est pas toujours évident ou possible pour l’opérateur du réseau d’identifier et de gérer en amont les potentiels impacts négatifs et indésirables de la mise à jour de la partie logicielle d’un équipement particulier sur les autres équipements du réseau, et ce d’autant plus que l’opérateur n’a pas toujours la main sur ces opérations de mises à jour, et que les équipementiers eux-mêmes sont parfois peu enclin à détailler sur un plan technique le contenu des mises à jour proposées.
[0006] Il s’en suit que les opérations de mise à jour logicielle d’un équipement du réseau de communication ont parfois un effet contre-productif dans un premier temps, en en- gendrant des baisses de performances voire des interruptions de service qui impactent directement les utilisateurs du réseau de communication. Le temps de détection et de remontée à l’opérateur de ces impacts, ajouté au temps nécessaire pour adapter en conséquence la partie logicielle des autres équipements interfacés avec l’équipement mis à jour, font que ces effets négatifs sont parfois durables, aggravant encore le risque d’engendrer des insatisfactions de la part des utilisateurs face à ce service dégradé.
[0007] Il existe donc un besoin pour une solution permettant de mieux gérer les impacts engendrés par les modifications logicielles d’un équipement d’un réseau de communication sur les autres équipements du réseau.
Résumé de l’invention
[0008] La présente technique permet de proposer une solution visant à remédier à certains inconvénients de l’art antérieur. Selon un aspect, la présente technique se rapporte en effet à un procédé de mise à jour d’un modèle opérationnel courant d’un premier équipement d’un réseau de communication, consécutivement à une modification d’au moins une fonction logicielle d’un deuxième équipement dudit réseau de communication, avec lequel le premier équipement est interfacé. Un tel procédé comprend, au niveau dudit premier équipement, les étapes suivantes :
[0009] - la réception d’au moins une donnée d’accès à une réplique numérique dudit deuxième équipement, ladite réplique numérique implémentant ladite fonction logicielle modifiée ;
[0010] - l’entrainement d’un modèle expérimental associé audit premier équipement, en fonction de données échangées entre ledit premier équipement et ladite fonction logicielle modifiée implémentée par ladite réplique numérique, délivrant à l’issue dudit entrainement un modèle opérationnel actualisé ;
[0011] - le déploiement dudit modèle opérationnel actualisé en tant que nouveau modèle opérationnel courant dudit premier équipement.
[0012] De cette manière, grâce à l’utilisation d’une réplique numérique du deuxième équipement, la génération d’un modèle opérationnel actualisé du premier équipement peut être mise en œuvre en parallèle du fonctionnement en production régi par le modèle opérationnel courant du premier équipement. Ainsi, le fonctionnement de production selon le modèle opérationnel courant reste maintenu tant que la génération d’un nouveau modèle est en cours, puis actualisé dès que la génération de ce nouveau modèle est terminée.
[0013] Dans un mode de réalisation particulier, ladite au moins une donnée d’accès à la réplique numérique du deuxième équipement prend la forme d’un conteneur comprenant ladite réplique numérique. Selon une caractéristique particulière, ledit procédé comprend une étape d’instanciation, localement, à partir dudit conteneur, de ladite réplique numérique.
[0014] De cette manière, l’entrainement du modèle expérimental est réalisé en local, au sein même du premier équipement ou à tout le moins au sein d’un équipement à proximité du premier équipement, permettant ainsi d’augmenter la rapidité de mise en œuvre de cet entrainement, de sécuriser son exécution, et d’éviter de surcharger le réseau de communication grâce au confinement ainsi obtenu des échanges de données entre le premier équipement et la réplique numérique du deuxième équipement.
[0015] Dans un mode de réalisation particulier, ledit procédé comprend, préalablement à ladite étape de réception, une étape d’émission d’une requête d’accès à la réplique numérique du deuxième équipement.
[0016] Selon une caractéristique particulière, ladite requête d’accès est émise :
[0017] - de manière périodique ; ou
[0018] - à réception d’une commande de récupération de ladite réplique numérique ; ou
[0019] - à réception d’une information représentative d’une disponibilité d’une réplique numérique mis à jour dudit deuxième équipement ; ou
[0020] - à détection, via une surveillance d’au moins un indicateur de performance dédié, d’une baisse de performance associée aux échanges entre le premier équipement et le deuxième équipement.
[0021] De cette manière, l’entrainement d’un modèle expérimental en vue d’obtenir un nouveau modèle opérationnel courant du premier équipement peut notamment être déclenché de manière automatique, sur la base d’un ou plusieurs critères, ce qui permet d’obtenir un modèle opérationnel actualisé plus rapidement pour le premier équipement. La durée pendant laquelle un modèle opérationnel courant du premier équipement reste en vigueur - alors même que ce modèle est devenu obsolète ou inadapté consécutivement à la modification ou au déploiement d’au moins une fonction logicielle sur un deuxième équipement avec lequel le premier équipement est interfacé - est ainsi largement diminuée.
[0022] Dans un mode de réalisation particulier, ladite réplique numérique est implémentée sous la forme d’un environnement d’apprentissage par renforcement.
[0023] De cette manière, la tâche fastidieuse et chronophage de spécifier et d’écrire manuellement un jeu de tests à chaque fois qu’une fonction logicielle est introduite ou mise à jour au sein d’un équipement du réseau de communication n’est plus requise, puisqu’un apprentissage de type essai-et-erreur peut être mis en œuvre grâce à la fourniture d’un environnement d’apprentissage par renforcement. Le fabricant ou l’administrateur de l’équipement dont une fonction logicielle est modifiée est ainsi également libéré de la contrainte d’avoir à documenter de manière détaillée les mises à jour déployées, et peut notamment fournir à ses clients un équipement et/ou une réplique numérique dans un mode « boite noire ». [0024] Selon une caractéristique particulière, dans ce mode de réalisation, ladite étape d’entrainement comprend :
[0025] - une étape dite exploratoire, correspondant à une première phase d’entrainement de type apprentissage par renforcement, dans laquelle au moins un échange entre ledit premier équipement et ladite fonction logicielle modifiée implémentée par ladite réplique numérique est utilisé pour entrainer un premier modèle expérimental, ladite étape exploratoire délivrant un jeu de données dans lequel au moins une partie desdits échanges est tracée ;
[0026] - une étape dite de consolidation, correspondant à une deuxième phase d’entrainement de type apprentissage supervisé, dans laquelle ledit jeu de données est utilisé pour entrainer un deuxième modèle expérimental, ladite étape de consolidation délivrant, à l’issue dudit apprentissage supervisé, ledit modèle opérationnel actualisé.
[0027] Dans un mode de réalisation particulier, durant ladite étape exploratoire, chaque échange dudit au moins un échange comprend :
[0028] - l’émission d’une action à destination de ladite réplique numérique ;
[0029] - la réception, en réponse à ladite action, de données d’état et de données de récompense en provenance de ladite réplique numérique ;
[0030] les actions successives émises à destination de la réplique numérique dans le cadre dudit au moins un échange étant déterminées de manière à tendre à maximiser au cours du temps les données de récompenses reçues en réponse à ces actions, lesdits échanges étant tracés au sein dudit jeu de données uniquement lorsqu’un niveau de récompense prédéterminé est atteint.
[0031] De cette manière, la technique proposée permet la mise en œuvre d’un apprentissage hybride cumulant les avantages d’un apprentissage par renforcement et d’un apprentissage supervisé : l’étape exploratoire permet d’identifier sans impact opérationnel les meilleures séquences de communications entre équipements, et l’étape de consolidation d’en déduire la meilleure marche forcée (i.e. les séquences de messages les plus proches des séquences de messages les plus pertinentes testées durant l’étape exploratoire) à mettre en œuvre en pratique en condition de production
[0032] Selon une caractéristique particulière, ladite étape d’entrainement comprend une étape curative de traitement manuel et/ou automatique dudit jeu de données, préalablement à ladite étape de consolidation.
[0033] De cette manière, il est notamment possible de conserver une expertise humaine dans le processus d’entrainement du modèle expérimental, afin par exemple de nettoyer, de filtrer, et/ou d’enrichir le jeu de données obtenu à l’issue de l’étape exploratoire avant qu’il ne soit utilisé comme base d’apprentissage pour la mise en œuvre de l’entrainement supervisé durant l’étape de consolidation.
[0034] Selon un autre aspect, la présente technique se rapporte également à un dispositif de mise à jour d’un modèle opérationnel courant d’un premier équipement d’un réseau de communication, consécutivement à une modification d’au moins une fonction logicielle d’un deuxième équipement dudit réseau de communication, avec lequel le premier équipement est interfacé. Un tel dispositif comprend, au sein dudit premier équipement :
[0035] - des moyens de réception d’au moins une donnée d’accès à une réplique numérique dudit deuxième équipement, ladite réplique numérique implémentant ladite fonction logicielle modifiée ;
[0036] - des moyens d’entrainement d’un modèle expérimental associé audit premier équipement, en fonction de données échangées entre ledit premier équipement et ladite fonction logicielle modifiée implémentée par ladite réplique numérique, délivrant à l’issue dudit entrainement un modèle opérationnel actualisé ;
[0037] - des moyens de déploiement dudit modèle opérationnel actualisé en tant que nouveau modèle opérationnel courant dudit premier équipement.
[0038] Selon un autre aspect, la technique proposée se rapporte également à un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, comprenant des instructions de code de programme pour l’exécution d'un procédé de mise à jour d’un modèle opérationnel courant d’un premier équipement d’un réseau de communication tel que décrit précédemment dans l’un quelconque de ses modes de réalisation, lorsqu’il est exécuté sur un ordinateur.
[0039] La technique proposée vise également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé tel que décrit précédemment, dans l’un quelconque de ses modes de réalisation.
[0040] Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. 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 une clé USB ou un disque dur.
[0041] D'autre part, un tel support d'enregistrement 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, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau, par exemple le réseau Internet.
[0042] Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention. Figures
[0043] D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
[0044] [Fig-1] illustre le principe général d’un procédé de mise à jour d’un modèle opérationnel courant d’un équipement d’un réseau de communication, dans un mode de réalisation particulier de la technique proposée ;
[0045] [Fig.2] présente un diagramme de séquences du procédé de mise à jour d’un modèle opérationnel courant d’un équipement d’un réseau de communication, dans un mode de réalisation particulier de la technique proposée ;
[0046] [Fig.3] décrit une architecture simplifiée d’un dispositif pour la mise en œuvre de la technique proposée, dans un mode de réalisation particulier.
Description détaillée de l’invention
[0047] La présente demande permet de remédier à certains des inconvénients précités.
[0048] Sur toutes les figures du présent document, les éléments et étapes de même nature sont désignés par une même référence numérique. Par ailleurs, dans la description qui suit, les termes « premier » et « deuxième » visent uniquement, sauf mention explicite du contraire, à permettre d’établir une distinction entre deux éléments, et n’impliquent a priori pas l’existence d’une quelconque relation d’ordre entre ces éléments.
[0049] Selon un premier aspect, la présente technique se rapporte à un procédé de mise à jour d’un modèle opérationnel courant d’un équipement d’un réseau de communication. Par modèle opérationnel courant, on entend ici l’ensemble des règles logicielles - mises en œuvre sous la forme d’instructions de code de programme exécutées par au moins un processeur - qui régissent le fonctionnement courant de l’équipement considéré, y compris la gestion de ses interactions avec d’autres équipements du réseau de communication avec lesquels il est interfacé. Dans ce contexte, un « équipement » selon la présente technique est entendu au sens large : il peut correspondre de manière classique à une ressource physique (e.g. tout ou partie d’une machine), mais également à un service implémenté au sein d’une machine tel que par exemple un service de virtualisation utilisé pour la mise en œuvre d’architectures virtualisées. Les règles logicielles peuvent alors par exemple correspondre à des règles associées à des instances de fonctions virtualisées d’une telle architecture virtualisée.
[0050] Le principe général du procédé proposé est illustré en relation avec la [Fig.1]. Dans le mode de réalisation particulier présenté sur cette figure, ce procédé se rapporte plus particulièrement à la mise à jour du modèle opérationnel courant MOC d’un premier équipement El d’un réseau de communication, consécutivement à une modification d’au moins une fonction logicielle FL d’un deuxième équipement E2 du réseau de communication, avec lequel le premier équipement est interfacé. Une telle modification logicielle s’inscrit par exemple dans le cadre d’opérations de maintenance corrective et/ou évolutive mises en œuvre sur le deuxième équipement E2, et peut notamment résulter d’une mise à jour d’une ou plusieurs fonctions logicielles déjà existantes, et/ou d’un déploiement de nouvelles fonctions logicielles au sein du deuxième équipement E2.
[0051] Le procédé selon la présente technique est implémenté au sein du premier équipement El, et il comprend les étapes détaillées ci-après, dans un mode de réalisation particulier.
[0052] Dans une étape 11, le premier équipement El reçoit, en provenance d’un équipement tiers du réseau de communication (typiquement en provenance du deuxième équipement E2, mais cet exemple n’est pas limitatif), au moins une donnée d’accès à une réplique numérique RNE2 dudit deuxième équipement E2. Par réplique numérique, on entend ici une copie numérique de l’objet physique qu’est le deuxième équipement E2, i.e. une représentation virtuelle conçue pour simuler fidèlement, de manière logicielle, les états, les caractéristiques et la dynamique de fonctionnement du deuxième équipement E2. Selon une caractéristique particulière, cette réplique numérique correspond par exemple à un jumeau numérique du deuxième équipement E2. Une telle réplique numérique - dont la création n’est pas l’objet de la présente technique - implémente notamment la fonction logicielle modifiée FL du deuxième équipement E2.
[0053] Les données d’accès à la réplique numérique RNE2 peuvent prendre différentes formes, selon le mode d’implémentation de cette réplique.
[0054] Selon une caractéristique particulière, les données d’accès reçues en étape 11 prennent par exemple la forme de cordonnées (e.g. adresse IP, URL, numéro de port, etc.) permettant au premier équipement El de se connecter à un serveur distant (qui peut être intégré ou non à l’équipement E2) au sein duquel la réplique numérique RNE2 est déployée : le premier équipement El accède alors à distance à la réplique numérique du deuxième équipement E2, cette réplique numérique étant installée sur une machine différente du premier équipement El.
[0055] De manière alternative, selon une autre caractéristique particulière, les données d’accès reçues en étape 11 peuvent également prendre la forme d’un conteneur (ou « package », en anglais) comprenant la réplique numérique, autrement dit toutes les données nécessaires à l’instanciation d’une telle réplique numérique. Ce conteneur est par exemple reçu en provenance d’un serveur distant, qui peut être intégré ou non à l’équipement E2. Dans ce cas, le procédé selon la présente technique comprend alors une étape d’instanciation, localement, à partir du conteneur reçu, de la réplique numérique du deuxième équipement E2 : le premier équipement El accède alors en local à la réplique numérique du deuxième équipement E2, cette réplique numérique RNE2 étant installée au sein même du premier équipement El (par exemple au sein d’une mémoire du premier équipement El) ou à tout le moins au sein d’un équipement proche faisant partie du même réseau local ou privé (e.g. du même intranet) que le premier équipement El, ce qui présente l’avantage de ne pas surcharger inutilement le réseau de communication avec de multiples échanges de messages entre des équipements réseaux distants lors de l’utilisation ultérieure de la réplique numérique, notamment quand les équipements El et E2 sont interfacés via un réseau de communication étendu.
[0056] Quoiqu’il en soit, à l’issue de l’étape 11, le premier équipement El est apte à communiquer avec la réplique numérique de l’équipement E2, soit parce qu’il dispose des informations lui permettant de se connecter à un équipement au sein duquel une instance d’une telle réplique numérique est déployée, soit parce qu’il a pu lui-même télécharger et déployer en son sein une instance d’une telle réplique numérique. Eventuellement, une opération de vérification est effectuée par le premier équipement avant de lancer un tel téléchargement, afin de s’assurer que la réplique numérique sur le point d’être téléchargée correspond bien à une version récente (i.e. une nouvelle version, à jour) de la réplique numérique, et non pas à une ancienne version qui aurait déjà été précédemment téléchargée et installée au sein du premier équipement (auquel cas le téléchargement n’est pas effectué). Une telle vérification peut par exemple être mise en œuvre par comparaison de données de hachage de contrôle distinctes identifiant les différentes versions d’une réplique numérique d’un même équipement.
[0057] Dans une étape 12, la réplique numérique est utilisée pour entrainer un modèle expérimental associé au premier équipement El. Plus particulièrement, par « modèle expérimental », on entend qu’un tel entrainement est réalisé dans un mode expérimental (par opposition à un mode opérationnel), c’est-à-dire sans incidence sur le fonctionnement opérationnel courant du premier équipement El au sein du réseau de communication. En d'autres termes, durant cette étape d’entrainement 12 du modèle expérimental, le modèle opérationnel courant MOC qui régit le fonctionnement du premier équipement El reste en vigueur. L’entrainement est donc réalisé en parallèle du fonctionnement en production du premier équipement El, sans impact sur ce fonctionnement (il n’y a donc pas d’interruption de service au niveau de l’équipement El qui serait dû à cet entrainement). Selon la technique proposée l’accès à la réplique numérique du deuxième équipement E2 est donc utilisé par le premier équipement El pour déterminer un nouveau modèle de fonctionnement du premier équipement El adapté aux évolutions du deuxième équipement E2, i.e. aux modifications préalablement effectuées sur une ou plusieurs des fonctions logicielles de cet équipement E2 avec lequel le premier équipement El est interfacé. À cette fin, le modèle expérimental est entrainé sur la base de données échangées entre le premier équipement El et la réplique numérique du deuxième équipement E2. Plus particulièrement, comme détaillé par la suite ultérieurement dans le présent document, des techniques d’apprentissage automatique sont mises en œuvre, dans lesquelles d’une part des données associées à des requêtes émises par le premier équipement El à destination de la réplique numérique et d’autre part des données obtenues en provenance de la réplique numérique (et notamment de la fonction logicielle modifiée implémentée par la réplique numérique) en réponse à ces requêtes sont analysées et utilisées pour entrainer le modèle expérimental.
[0058] Dans une étape 13, une fois le modèle expérimental considéré comme suffisamment entrainé, il peut être déployé en tant que nouveau modèle opérationnel courant du premier équipement El, régissant ainsi le nouveau fonctionnement de cet équipement en conditions de production. En d'autres termes, ce nouveau modèle opérationnel courant vient remplacer le modèle opérationnel auparavant mis en œuvre au sein du premier équipement El.
[0059] Dans un mode de réalisation particulier, l’étape 11 de réception d’une donnée d’accès à la réplique numérique RNE2 du deuxième équipement E2 fait suite à l’émission, par l’équipement El, d’une requête d’accès à une telle réplique numérique. Une telle requête est par exemple émise à destination du deuxième équipement E2, ou à destination d’un équipement tiers (par exemple un serveur dédié à l’hébergement ou à la fourniture de répliques numériques d’équipements du réseau de communication).
[0060] L’émission par l’équipement El d’une telle requête d’accès peut être déclenchée sous diverses conditions, dans des modes de réalisation complémentaires ou alternatifs de la technique proposée décrits ci-après à titre illustratif et non limitatif.
[0061] Ainsi, la requête d'accès est par exemple émise de manière répétée, éventuellement périodique. Par exemple une telle requête est émise quotidiennement par le premier équipement, de préférence à une heure où le trafic sur le réseau de communication est réduit (e.g. la nuit). De cette manière, en particulier lorsque les données d’accès à la réplique numérique prennent la forme d’un conteneur potentiellement relativement volumineux à télécharger auprès d’un serveur distant, il est possible de limiter l’impact de cette opération de téléchargement sur les performances du réseau de communication, en la déclenchant de manière préférentielle dans une période de creux de charge de ce réseau.
[0062] La requête d'accès peut également être émise à réception, par le premier équipement El, d’une commande de récupération de la réplique numérique, ou à réception d’une information représentative d’une disponibilité d’une nouvelle réplique numérique (i.e. d’une réplique numérique récemment mise à jour) du deuxième équipement E2. Une telle commande et/ou une telle information sont par exemple reçues en provenance du deuxième équipement E2, ou encore d’un équipement tiers différent du deuxième équipement. Selon une caractéristique particulière, la commande de récupération d’une réplique numérique peut notamment être forcée manuellement, par exemple par interaction d’un utilisateur sur un élément dédié d’une interface graphique mise à sa disposition. Par ailleurs, la réception d’une information représentative d’une disponibilité d’une nouvelle réplique numérique peut s’inscrire dans le cadre d’une souscription préalable, par le premier équipement, auprès d’un autre équipement (typiquement le deuxième équipement), à un service de notification des évènements de ce type.
[0063] Selon encore une autre possibilité, la requête d'accès est émise à détection, par le premier équipement El, d’une baisse de performance associée aux échanges entre le premier équipement El et le deuxième équipement E2. Une telle baisse de performance est évaluée via la surveillance d’au moins un indicateur de performance dédié (ou KPI, de l’anglais « Key Performance Indicator »), tel que par exemple un taux de messages d’erreur anormalement élevé reçus en provenance du deuxième équipement en réponse à des requêtes émises à sa destination par le premier équipement, ou tout autre indicateur pertinent.
[0064] On décrit maintenant de manière plus détaillée divers modes de réalisation de l’étape d’entrainement 12. Plus particulièrement, dans un mode de réalisation particulier, la réplique numérique RNE2 du deuxième équipement est implémentée sous la forme d’un environnement d’apprentissage par renforcement, permettant ainsi la mise en œuvre de techniques d’apprentissage par renforcement dans cette étape 12 d’entrainement d’un modèle expérimental. Comme décrit ci-après, l’originalité de la technique proposée réside cependant en ce que l’apprentissage par renforcement mis en œuvre n’a pas ici pour objectif premier d’entrainer un modèle (comme c’est généralement le cas dans des approches classiques), mais de construire un jeu de données JD destiné à servir de base d’apprentissage pour la mise en œuvre d’une autre phase d’apprentissage, subséquente, reposant cette fois non plus sur un apprentissage par renforcement mais sur un apprentissage de type supervisé.
[0065] Ainsi, dans un mode de réalisation particulier de la technique proposée, l’étape 12 d’entrainement comprend :
[0066] - une étape dite exploratoire 121, correspondant à une première phase d’entrainement de type apprentissage par renforcement, dans laquelle une succession d’échanges (au moins un) entre le premier équipement El et la fonction logicielle modifiée implémentée par la réplique numérique RNE2 du deuxième équipement E2 est utilisée pour entrainer un premier modèle expérimental, cette étape exploratoire délivrant un jeu de données JD dans lequel au moins une partie desdits échanges est tracée ;
[0067] - une étape dite de consolidation 122, correspondant à une deuxième phase d’entrainement de type apprentissage supervisé, dans laquelle le jeu de données JD obtenu à l’issue de la première phase est utilisé (éventuellement après contrôle et adaptation par un opérateur humain) pour entrainer un deuxième modèle expérimental, cette étape de consolidation délivrant, une fois l’apprentissage supervisé terminé, le modèle opérationnel actualisé MOA destiné à être déployé en tant que nouveau modèle opérationnel courant MOC du premier équipement (conformément à l’étape 13 de la [Fig.l]).
[0068] Plus particulièrement, durant la première phase d’entrainement par apprentissage par renforcement, selon une approche de type essai-et-erreur, de multiples échanges de données (généralement très nombreux, e.g. plusieurs milliers voire des millions, sans toutefois que ceci soit limitatif, un nombre limité d’échanges, e.g. seulement quelques dizaines ou centaines, pouvant s’avérer suffisant dans certains cas) sont réalisés entre le premier équipement El et la réplique numérique RNE2 du deuxième équipement, dans une perspective de large exploration des résultats obtenus en réponse à différentes valeurs de paramètres transmises au sein d’un message et/ou à différents en- chainements de messages.
[0069] Chacun de ces échanges comprend, selon le vocabulaire usuel en matière d’apprentissage par renforcement :
[0070] - l’émission par le premier équipement de données d’action à destination de la réplique numérique du deuxième équipement ;
[0071] - la réception, en réponse à ladite action, de données d’état et de données de récompense en provenance de ladite réplique numérique.
[0072] Les données d’état sont représentatives d’un nouvel état de l’environnement d’apprentissage par renforcement, i.e. de la réplique numérique, suite à l’action effectué sur cet environnement.
[0073] Les données de récompense sont représentatives d’une ou plusieurs métriques d’efficacité de l’action effectuée sur l’environnement, ou à tout le moins des données permettant au premier équipement de calculer de telles métriques.
[0074] Les actions successives émises à destination de la réplique numérique sont déterminées par un algorithme de renforcement, de manière à tendre à maximiser au cours du temps les données de récompenses reçues en réponse à ces actions. Selon la technique proposée, une fois un niveau de récompense prédéterminé atteint, tous les échanges de données subséquents réalisés durant cette étape exploratoire sont tracés (par exemple dans un fichier de traces, dans une base de données, ou tout autre structure de données adéquate), participant ainsi à la construction d’un jeu de données JD représentatif de séquences d’actions qui peuvent être considérées comme pertinentes ou efficaces (car associées à des récompenses obtenues élevées) vis-à-vis de la réplique numérique implémentant la fonction logicielle modifiée. [0075] Plus particulièrement, dans un mode de réalisation particulier de la technique proposée, chaque échantillon d’un tel jeu de données JD comprend des informations saillantes relatives à un échange de données entre le premier équipement El et la réplique numérique RNE2 (et notamment la fonction logicielle modifiée) du deuxième équipement E2. De telles informations saillantes comprennent par exemple :
[0076] - des données relatives à l’action envoyée par le premier équipement à la réplique numérique du deuxième équipement dans le cadre de l’échange de données considéré, comprenant par exemple une commande transmise et des paramètres associés, un identifiant du premier équipement (prenant par exemple la forme d’un identifiant décentralisé ou DID, pour « Decentralized identifier »), et éventuellement une étiquette temporelle (« timestamp ») représentative du moment d’émission de cette action ;
[0077] - des données relatives au résultat retourné par la réplique numérique du deuxième équipement en réponse à cette action, comprenant par exemple des données d’état représentatives d’une conséquence de l’action sur l’environnement, des données de récompense associées, des données complémentaires (par exemple des données représentatives d’une ou plusieurs métriques d’efficacité eu égard à l’échange considéré), un identifiant de la réplique numérique du deuxième équipement (prenant par exemple également la forme d’un identifiant décentralisé), et éventuellement une étiquette temporelle (« timestamp ») représentative du moment de réception de cette réponse.
[0078] Comme indiqué précédemment, le jeu de données JD est ensuite utilisé pour la mise en œuvre de l’étape de consolidation 122, dans laquelle il sert de base d’apprentissage pour l’entrainement supervisé d’un deuxième modèle expérimental (un tel entrainement pouvant selon le cas être effectué sur la base d’un modèle vierge, i.e. de zéro, ou à partir d’une version précédente du modèle si son architecture le permet - e.g. modèle de type « Transformer » - et s’il n’y a pas de changement majeur des actions et des états associés à la réplique numérique implémentant la fonction logicielle modifiée).
[0079] De manière optionnelle, dans un mode de réalisation particulier, le jeu de données JD obtenu à l’issue de l’étape exploratoire 121 est mis à disposition d’un utilisateur (par exemple via une interface graphique dédiée fournie par le premier équipement) avant que l’étape de consolidation 122 soit effectuée, pour consultation et modifications et/ ou adaptations éventuelles avant la mise en œuvre de l’entrainement supervisé. Une telle étape curative de traitement du jeu de données préalablement à son utilisation comme base d’apprentissage permet de conserver une expertise humaine dans le processus d’entrainement du modèle expérimental.
[0080] Pour plus de clarté, on présente maintenant en relation avec la [Fig.2] un diagramme de séquence illustrant dans le temps un exemple d’interactions possibles entre différentes entités du premier équipement El, incluant la mise en œuvre du procédé de mise à jour du modèle opérationnel courant de cet équipement, selon certains des modes de réalisation particuliers décrits précédemment.
[0081] En condition de production, dans un mode opérationnel OP, le modèle opérationnel courant MOC du premier équipement El régit le fonctionnement de cet équipement, et est notamment sollicité, dans une étape 201, pour déterminer une action à mettre en œuvre vis-à-vis d’un deuxième équipement E2, dans le cadre d’un échange de données 202 entre ces deux équipements. Un tel échange de données est établi entre une interface de communication II du premier équipement El, et une interface de communication 12 du deuxième équipement E2 (l’interface de communication 12 étant la seule entité du deuxième équipement E2 représentée sur la [Fig.2], cet équipement étant illustré ici en tant que « boite noire »). À l’issue de chaque échange 202, dans une étape 203, au moins un indicateur de performance associé à l’échange réalisé est remonté à un module de contrôle CTRL du premier équipement El. De telles étapes 201, 202 et 203 sont réitérées pour tous les échanges entre le premier équipement El et le deuxième équipement E2 en mode opérationnel.
[0082] Lorsque le module de contrôle CTRL détecte, sur la base d’un des indicateurs de performance obtenus en étape 203, une baisse de performance associée aux échanges entre le premier équipement El et le deuxième équipement E2, il requiert auprès du deuxième équipement E2, via son interface de communication II, dans une étape 204, un accès à une réplique numérique RNE2 de cet équipement E2. Une telle baisse de performance peut notamment résulter de l’ajout et/ou de la modification, au sein du deuxième équipement E2, d’au moins une fonction logicielle FL. Dans le mode de réalisation particulier illustré en [Fig.2], suite à cette requête, le module de contrôle CTRL est autorisé à télécharger, dans une étape 205, un conteneur comprenant toutes les données nécessaires à une installation de la réplique numérique du deuxième équipement. Au moyen de ce conteneur, le module de contrôle CTRL instancie alors au sein d’une mémoire du premier équipement El, dans une étape 206, une instance de la réplique numérique RNE2 du deuxième équipement, cette réplique numérique prenant la forme d’un environnement d’apprentissage par renforcement implémentant la fonction logicielle modifiée FL. Le module de contrôle CTRL instancie également, dans une étape 207, un premier modèle expérimental MEXP1.
[0083] Une première phase PHI de type apprentissage par renforcement est alors mise en œuvre, dans laquelle le modèle expérimental MEXP1 est entrainé sur la base de multiples échanges de données 208 (généralement un très grand nombre, e.g. des milliers voire des millions d’échange) avec la réplique numérique RNE2, par essai- et-erreur, comme déjà décrit en relation avec la [Fig.l]. Lorsqu’un niveau de récompense prédéterminé est atteint, les échanges de données subséquents sont tracés, dans une étape 209, au sein d’un jeu de données. [0084] À l’issue de la première phase d’apprentissage par renforcement PHI, le module de contrôle CTRL requiert et récupère, dans une étape 210, le jeu de données ainsi constitué.
[0085] Ce jeu de données est transmis à un deuxième modèle expérimental MEXP2 instancié par le module de contrôle CTRL dans une étape 211.
[0086] Une deuxième phase PH2 de type apprentissage supervisé est alors mise en œuvre, dans laquelle le modèle expérimental MEXP2 est entrainé sur la base des échantillons présents dans jeu de données, lors de nombreuses itérations d’une étape 212.
[0087] A Tissue de la deuxième phase d’apprentissage supervisé PH2, le modèle expérimental MEXP2 est considéré comme suffisamment entrainé pour être utilisé comme modèle opérationnel actualisé du premier équipement EL II est donc récupéré par le module de contrôle CTRL dans une étape 213, puis déployé en production dans une étape 214, en tant que nouveau modèle opérationnel courant MOC du premier équipement El, pertinent pour la mise en œuvre d’échanges de données efficaces avec le deuxième équipement E2 implémentant la fonction logicielle FL modifiée.
[0088] Les modes de réalisation présentés précédemment en relation avec les figures 1 et 2, qui reposent sur la mise en œuvre de deux phases d’apprentissage successives mais de types distincts, offrent de nombreux avantages présentés pour partie ci-après.
[0089] En premier lieu, la mise en œuvre de la première phase d’apprentissage par renforcement permet d’éviter la tâche fastidieuse et chronophage de spécifier et d’écrire manuellement un jeu de tests à chaque fois qu’une fonction logicielle est introduite ou mise à jour au sein d’un équipement du réseau de communication. Par ailleurs, lorsque la réplique numérique du deuxième équipement est instanciée en local, par exemple au sein même d’une mémoire du premier équipement ou au sein d’un équipement proche faisant partie du même réseau local ou privé (e.g. du même intranet), l’acquisition d’expérience intrinsèque à l’apprentissage par renforcement est réalisée en local possiblement directement sur la machine apprenante (i.e. le premier équipement), ce qui permet d’une part d’augmenter la rapidité de mise en œuvre des essais et de garantir une certaine sécurité dans leur exécution (via le confinement en local de ces essais), et d’autre part d’éviter de surcharger le réseau de communication (les milliers ou millions d’échanges de messages réalisés dans le cadre de ces essais ne transitant pas sur le réseau de communication). La mise à jour du modèle opérationnel d’un équipement, et en particulier de son modèle de communication avec les autres équipements du réseau, peut ainsi être préparée de manière autonome au sein de cet équipement. Autrement dit, la génération d’un modèle opérationnel actualisé est mise en œuvre en parallèle du fonctionnement en production régi par le modèle opérationnel courant de cet équipement, ce fonctionnement restant maintenu et non impacté tant que cette génération est en cours. [0090] En deuxième lieu, le fait de combiner deux méthode d’apprentissage présente un intérêt certain, en offrant un mécanisme permettant, tout au long du cycle de vie des équipements, par l’utilisation de métriques d’efficacité, de lutter contre l’obsolescence inévitable à terme d’un modèle opérationnel qui serait issu uniquement d’un apprentissage de type supervisé (i.e. sans prise de risques), en permettant une mise à jour du modèle opérationnel sur la base de nouvelles données issues de l’apprentissage par renforcement (i.e. de données non figées, résultant de l’exploration de nouvelles options et possibilités de dialogue avec l’équipement dont une fonction logicielle a été mise à jour). En d'autres termes, la technique proposée permet grâce à l’étape exploratoire d’identifier sans impact opérationnel les meilleures séquences de communications entre équipements, puis d’en déduire grâce à l’étape de consolidation la meilleure marche forcée (i.e. les séquences de messages les plus proches possibles des séquences de messages les plus pertinentes préalablement testées durant l’étape exploratoire) à mettre en œuvre en pratique en condition de production.
[0091] En troisième lieu, la technique proposée présente également un intérêt pour le fabricant ou l’administrateur de l’équipement dont au moins une fonction logicielle est modifiée, puisqu’il est libéré de la contrainte d’avoir à systématiquement documenter de manière détaillée les mises à jour proposées ou partager leur code source. La présente technique peut en effet être mise en œuvre même lorsque le deuxième équipement ou sa réplique numérique sont implémentés dans un mode « boite noire », avec du code obfusqué ou non documenté par exemple.
[0092] En quatrième lieu, il est intéressant de noter que la technique proposée peut également s’appliquer à la mise à jour d’un modèle opérationnel courant d’un équipement d’un réseau de communication lorsque non pas un seul mais plusieurs autres équipements avec lesquels il est interfacé ont fait l’objet de mises à jour récentes de fonctions logicielles. Dans ce cas, une phase d’apprentissage par renforcement est menée pour chacun de ces autres équipements, en relation avec une réplique numérique de chaque équipement, et les différents jeux de données obtenus suite à ces phases d’apprentissage par renforcement sont concaténés pour former un jeu unique utilisé dans la deuxième phase d’apprentissage supervisée pour entrainer un modèle expérimental et délivrer un modèle opérationnel actualisé efficace et pertinent pour des communications multi-équipements.
[0093] En cinquième lieu, la technique proposée peut également être mise à profit pour sélectionner une fonction logicielle préférentielle à déployer au sein d’un équipement parmi une pluralité de fonctions logicielles disponibles (e.g. développées à des fins de tests), en testant (au moyen par exemple de différentes versions d’une réplique numérique d’un équipement) ces différentes options possibles en lien avec les équipements déjà déployés. De cette manière, il est ainsi possible d’anticiper et/ou de comparer les éventuels impacts de chaque fonction logicielle au regard de différents critères (performance, compatibilité protocolaire, etc.), et de choisir sur cette base la fonction logicielle la plus adaptée.
[0094] Selon un autre aspect, la technique proposée se rapporte également à un dispositif de mise à jour d’un modèle opérationnel courant d’un premier équipement d’un réseau de communication, consécutivement à une modification d’au moins une fonction logicielle d’un deuxième équipement dudit réseau de communication, avec lequel le premier équipement est interfacé. Un tel dispositif, intégré au sein du premier équipement, est apte à réaliser le procédé précédemment décrit dans l’un quelconque de ses modes de réalisation. Plus particulièrement, un tel dispositif selon la présente technique comprend :
[0095] - des moyens de réception d’au moins une donnée d’accès à une réplique numérique dudit deuxième équipement, ladite réplique numérique implémentant ladite fonction logicielle modifiée ;
[0096] - des moyens d’entrainement d’un modèle expérimental associé audit premier équipement, en fonction de données échangées entre ledit premier équipement et ladite fonction logicielle modifiée implémentée par ladite réplique numérique, délivrant à l’issue dudit entrainement un modèle opérationnel actualisé ;
[0097] - des moyens de déploiement dudit modèle opérationnel actualisé en tant que nouveau modèle opérationnel courant dudit premier équipement.
[0098] La [Fig.3] représente, de manière schématique et simplifiée, la structure d’un tel dispositif, dans un mode de réalisation particulier. Le dispositif selon la technique proposée, implémenté au sein d’un premier équipement d’un réseau de communication, comprend par exemple une mémoire 31 constituée d’une mémoire tampon M, une unité de traitement 32, équipée par exemple d’un microprocesseur iiP, et pilotée par le programme d’ordinateur Pg 33, mettant en œuvre des étapes du procédé de mise à jour d’un modèle opérationnel courant du premier équipement selon au moins un mode de réalisation de l’invention. À cette fin, le dispositif comprend également au moins une interface de communication (par exemple une interface de communication Ethernet), lui permettant de recevoir et d’émettre des messages en provenance et à destination d’autres équipements présents dans le réseau de communication.
[0099] À l’initialisation, les instructions de code du programme d’ordinateur 33 sont chargées dans la mémoire tampon avant d’être exécutées par le processeur de l’unité de traitement 32. L’unité de traitement 32 reçoit en entrée E par exemple un message lui signalant la disponibilité d’une nouvelle réplique numérique d’un deuxième équipement avec lequel le premier équipement est interfacé.
[0100] Le microprocesseur de l’unité de traitement 32 réalise alors les étapes du procédé de mise à jour du modèle opérationnel courant du premier équipement, selon les ins- tructions du programme d’ordinateur 33. Plus particulièrement, le premier équipement reçoit des données d’accès à la réplique numérique du deuxième équipement, puis utilise cette réplique numérique pour entrainer un modèle expérimental en fonction de données échangées notamment avec une fonction logicielle modifiée implémentée par ladite réplique numérique. Cet entrainement délivre à son issue un modèle opérationnel actualisé, qui est alors transmis par l’unité de traitement 32 en sortie S, pour déploiement en production au sein du premier équipement, en lieu et place du modèle opérationnel courant devenu obsolète.

Claims

Revendications
[Revendication 1] Procédé de mise à jour d’un modèle opérationnel courant (MOC) d’un premier équipement (El) d’un réseau de communication, consécutivement à une modification d’au moins une fonction logicielle (FL) d’un deuxième équipement (E2) dudit réseau de communication, avec lequel le premier équipement est interfacé, ledit procédé étant caractérisé en ce qu'il comprend, au niveau dudit premier équipement, les étapes suivantes :
- réception (11) d’au moins une donnée d’accès à une réplique numérique (RNE2) dudit deuxième équipement, ladite réplique numérique implémentant ladite fonction logicielle modifiée ;
- entrainement (12) d’un modèle expérimental associé audit premier équipement, en fonction de données échangées entre ledit premier équipement et ladite fonction logicielle modifiée implémentée par ladite réplique numérique, délivrant à l’issue dudit entrainement un modèle opérationnel actualisé (MO A) ;
- déploiement (13) dudit modèle opérationnel actualisé en tant que nouveau modèle opérationnel courant dudit premier équipement.
[Revendication 2] Procédé selon la revendication 1, caractérisé en ce que ladite au moins une donnée d’accès à la réplique numérique du deuxième équipement prend la forme d’un conteneur comprenant ladite réplique numérique.
[Revendication 3] Procédé selon la revendication 2, caractérisé en ce qu'il comprend une étape d’instanciation, localement, à partir dudit conteneur, de ladite réplique numérique.
[Revendication 4] Procédé selon la revendication 1, caractérisé en ce qu’il comprend, préalablement à ladite étape de réception (11), une étape d’émission d’une requête d’accès à la réplique numérique du deuxième équipement.
[Revendication 5] Procédé selon la revendication 4, caractérisé en ce que ladite requête d’accès est émise :
- de manière périodique ; ou
- à réception d’une commande de récupération de ladite réplique numérique ; ou
- à réception d’une information représentative d’une disponibilité d’une réplique numérique mis à jour dudit deuxième équipement ; ou
- à détection, via une surveillance d’au moins un indicateur de performance dédié, d’une baisse de performance associée aux échanges entre le premier équipement et le deuxième équipement.
[Revendication 6] Procédé selon la revendication 1, caractérisé en ce que ladite réplique numérique est implémentée sous la forme d’un environnement d’apprentissage par renforcement.
[Revendication 7] Procédé selon la revendication 6, caractérisé en ce que ladite étape d’entrainement (12) comprend :
- une étape dite exploratoire (121), correspondant à une première phase d’entrainement (PHI) de type apprentissage par renforcement, dans laquelle au moins un échange entre ledit premier équipement et ladite fonction logicielle modifiée implémentée par ladite réplique numérique est utilisé pour entrainer un premier modèle expérimental, ladite étape exploratoire délivrant un jeu de données (JD) dans lequel au moins une partie desdits échanges est tracée ;
- une étape dite de consolidation (122), correspondant à une deuxième phase d’entrainement (PH2) de type apprentissage supervisé, dans laquelle ledit jeu de données (JD) est utilisé pour entrainer un deuxième modèle expérimental, ladite étape de consolidation délivrant, à l’issue dudit apprentissage supervisé, ledit modèle opérationnel actualisé (MOA).
[Revendication 8] Procédé selon la revendication 7, caractérisé en ce que durant ladite étape exploratoire, chaque échange dudit au moins un échange comprend :
- l’émission d’une action à destination de ladite réplique numérique ;
- la réception, en réponse à ladite action, de données d’état et de données de récompense en provenance de ladite réplique numérique ; les actions successives émises à destination de la réplique numérique dans le cadre dudit au moins un échange étant déterminées de manière à tendre à maximiser au cours du temps les données de récompenses reçues en réponse à ces actions, lesdits échanges étant tracés au sein dudit jeu de données uniquement lorsqu’un niveau de récompense prédéterminé est atteint.
[Revendication 9] Procédé selon la revendication 7, caractérisé en ce que ladite étape d’entrainement (12) comprend une étape curative de traitement manuel ou automatique dudit jeu de données (JD), préalablement à ladite étape de consolidation (122).
[Revendication 10] Dispositif de mise à jour d’un modèle opérationnel courant d’un premier équipement d’un réseau de communication, consécutivement à une modification d’au moins une fonction logicielle d’un deuxième équipement dudit réseau de communication, avec lequel le premier équipement est interfacé, ledit dispositif étant caractérisé en ce qu'il comprend, au sein dudit premier équipement :
- des moyens de réception d’au moins une donnée d’accès à une réplique numérique dudit deuxième équipement, ladite réplique numérique implémentant ladite fonction logicielle modifiée ;
- des moyens d’entrainement d’un modèle expérimental associé audit premier équipement, en fonction de données échangées entre ledit premier équipement et ladite fonction logicielle modifiée implémentée par ladite réplique numérique, délivrant à l’issue dudit entrainement un modèle opérationnel actualisé ;
- des moyens de déploiement dudit modèle opérationnel actualisé en tant que nouveau modèle opérationnel courant dudit premier équipement.
[Revendication 11] Produit programme d’ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu’il comprend des instructions de code de programme pour l’exécution d'un procédé selon l'une quelconque des revendications 1 à 9, lorsqu’il est exécuté par un ordinateur.
EP24708823.0A 2023-03-23 2024-03-07 Procédé de mise à jour d'un modèle opérationnel courant d'un équipement d'un réseau de communication Pending EP4684516A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2302725A FR3147029A1 (fr) 2023-03-23 2023-03-23 Procédé de mise à jour d’un modèle opérationnel courant d’un équipement d’un réseau de communication.
PCT/EP2024/055933 WO2024194019A1 (fr) 2023-03-23 2024-03-07 Procédé de mise à jour d'un modèle opérationnel courant d'un équipement d'un réseau de communication

Publications (1)

Publication Number Publication Date
EP4684516A1 true EP4684516A1 (fr) 2026-01-28

Family

ID=86851565

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24708823.0A Pending EP4684516A1 (fr) 2023-03-23 2024-03-07 Procédé de mise à jour d'un modèle opérationnel courant d'un équipement d'un réseau de communication

Country Status (3)

Country Link
EP (1) EP4684516A1 (fr)
FR (1) FR3147029A1 (fr)
WO (1) WO2024194019A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3114713B1 (fr) * 2020-09-30 2023-10-06 Commissariat Energie Atomique Méthode d’association d’équipements d’utilisateurs dans un réseau cellulaire selon une politique d’association transférable
US12047248B2 (en) * 2020-10-26 2024-07-23 Samsung Electronics Co., Ltd. Method of controlling state control parameter for adjusting state of network of base station by using any one of plurality of models and electronic device performing the method

Also Published As

Publication number Publication date
FR3147029A1 (fr) 2024-09-27
WO2024194019A1 (fr) 2024-09-26

Similar Documents

Publication Publication Date Title
US8205215B2 (en) Automated event correlation
FR2745649A1 (fr) Systeme de configuration de logiciels preconfigures sur des systemes ouverts en reseau dans un environnement distribue et procede mis en oeuvre par un tel systeme
US10331427B2 (en) Capturing and deploying an operation system in a computer environment
FR2944117A1 (fr) Procedes et dispositifs de gestion d'evenements lies a la securite des systemes informatiques d'aeronefs
FR3003366A1 (fr) Procede, dispositif et programme d'ordinateur pour l'installation ou la desinstallation automatique de modules logiciels dans des equipements embarques d'un aeronef
EP4684516A1 (fr) Procédé de mise à jour d'un modèle opérationnel courant d'un équipement d'un réseau de communication
EP3454246B1 (fr) Procédé de transmission et de vérification de validité de données de configuration dans un système électronique, système électronique et produit programme d'ordinateur associés
EP3191961A1 (fr) Mecanisme haute performance pour generation d'informations de journalisation d'un processus informatique
EP2210367A1 (fr) Procede de gestion d'operations d'administration, de maintenance et de maintien en condition operationnelle, entite de gestion, et produit programme d'ordinateur correspondant
FR2973131A1 (fr) Procede et dispositif de detection d'incompatibilites d'interfaces logiques d'equipements de systemes embarques
EP3729768B1 (fr) Procédé de construction automatique de scénarios d'attaques informatiques, produit programme d'ordinateur et système de construction associés
FR2873219A1 (fr) Procede de sauvegarde distribuee sur des postes clients dans un reseau informatique
EP3754506A1 (fr) Procédé de validation automatique de cots et dispositif pour la mise en oeuvre du procédé
EP3123314B1 (fr) Procédé et dispositif de contrôle du changement de système d'exploitation dans des noeuds de service d'un calculateur haute performance
EP4206907B1 (fr) Procédé et système de supervision de mise à jour de logiciel de support dans une infrastructure de fourniture de services
EP4579531A1 (fr) Système informatique, procédé de mise en oeuvre et ensemble de produits programme d'ordinateur associés
EP3411821B1 (fr) Procédé de stockage de contenus, procédé de consultation de contenus, procédé de gestion de contenus et lecteurs de contenus
FR3075999A1 (fr) Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique
FR3076634A1 (fr) Procede d'analyse de symptomes de panne de plateformes, et systeme associe
EP2734921A1 (fr) Procede, programme d'ordinateur et dispositif d'aide au deploiement de clusters
FR3035984A1 (fr) Procede de detection d'un logiciel malveillant
FR2888651A1 (fr) Procede pour la prise en compte automatique et le stockage persistant de parametres de personnalisation a priori volatils
FR2825165A1 (fr) Procede et dispositif permettant d'executer automatiquement des operations a distance sur des machines nt
EP2763033A2 (fr) Déploiement d'images systèmes doubles dans une grappe de serveurs
FR2911203A1 (fr) Procede de gestion de l'environnement d'execution sur des postes clients legers

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250904

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR