FR3101458A1 - Contrôle d’une campagne de déploiement d’une mise à jour logicielle sur un parc de périphériques - Google Patents

Abstract

La présente divulgation concerne le contrôle du déploiement d’une campagne de mise à jour logicielle d’un ensemble (DV TOT) de périphériques connectés à au moins un serveur (SER DM). En particulier on sélectionne un premier sous-ensemble (DV ITN-1) de périphériques de l’ensemble, et on met à jour les périphériques de ce premier sous-ensemble. Ensuite on détermine un pourcentage de périphériques du premier sous-ensemble pour lesquels une erreur de mise à jour est détectée. Si le pourcentage déterminé est inférieur à un premier seuil, dit de tolérance, alors on sélectionne un deuxième sous-ensemble (DV ITN) de périphériques, distinct du premier, ayant une taille supérieure au premier sous-ensemble. On réitère alors les étapes précédentes avec le deuxième sous-ensemble en tant que premier sous-ensemble. Si au contraire le pourcentage déterminé est supérieur ou égal audit premier seuil, alors on sélectionne un troisième sous-ensemble de périphériques, distinct du premier, ayant une taille inférieure au premier sous-ensemble, puis de manière analogue à l’autre alternative, on réitère alors les étapes précédentes mais ici avec le troisième sous-ensemble en tant que premier sous-ensemble. Figure de l’abrégé : Figure 2

Description

Contrôle d’une campagne de déploiement d’une mise à jour logicielle sur un parc de périphériques

La présente divulgation relève du domaine de la gestion de parcs informatiques et notamment du déploiement d’une mise à jour, sur les périphériques d’un tel parc, notamment par exemple pour une mise à jour des logiciels de ces périphériques, également appelé campagne d’opérations massives.

On entend en effet par « campagne d’opérations massives » le déploiement d’une configuration ou d’une mise à jour logicielle sur un ensemble de périphériques connectés à un ou plusieurs réseaux. Des domaines d’applications possibles de ces campagnes d’opérations massives sont des mises à jour de périphériques : dans une ville intelligente (« Smart-City » en anglais), l’industrie 4.0, les grilles intelligentes (« smart-grid » en anglais) ou encore un parc de périphériques déployés chez des particuliers par un opérateur de télécommunications.

Lors du déploiement d’une mise à jour sur un parc de périphériques connectés à un réseau, chaque périphérique à mettre à jour peut se trouver dans des conditions qui rendraient une mise à jour inadéquate. Des contraintes non anticipées peuvent entrainer une perte totale ou partielle des fonctionnalités des périphériques mis à jour.

Les contraintes peuvent être dues aux caractéristiques propres à chaque périphérique. Ces contraintes propres aux périphériques peuvent être, une version logicielle, un type de source d’énergie, des services en exécution incompatibles avec une mise à jour, ou autre.

Ces contraintes peuvent également être liées à l’environnement externe de chaque périphérique. A titre d’exemples illustratifs, on peut citer : des conditions réseaux instables, un signal faible de connexion, une perturbation passagère due à des conditions météo défavorables, des interférences dues à une géolocalisation en zone dense d’un point de vue électromagnétique, ou autres.

Les contraintes de mise à jour étant multiples et protéiformes, elles sont difficiles à anticiper. Un problème pour mener à bien une campagne de mise à jour est donc de l’adapter à ces contraintes, afin de minimiser ses conséquences éventuellement néfastes.

Une solution courante est de réguler manuellement la gestion des campagnes d’opérations massives. Typiquement, des opérateurs d’un système de gestion arrêtent l’opération massive de mise à jour dès lors qu’un service client leur communique (par mail, téléphone ou autre) une augmentation notable du nombre de notifications d’utilisateurs concernant un problème de fonctionnement d’un périphérique suite à sa mise à jour.

Cette solution technique est donc limitée car elle dépend des utilisateurs des périphériques pour faire remonter les dysfonctionnements des périphériques mis à jour. Outre le fait de demander des efforts aux utilisateurs, la solution courante impose de faire un choix entre deux solutions :
-soit, attendre les retours progressifs des utilisateurs au cours de la campagne de mise à jour. Cette solution permet d’éviter de généraliser des erreurs suite à la mise à jour. Cependant elle n’est pas automatisée et est chronophage car elle nécessite d’attendre les retours des utilisateurs pour avancer.
-soit, choisir de mettre à jour en une seule fois de larges portions de périphériques du parc. Cette solution présente le risque que des erreurs suite à la mise à jour se manifestenta post e riorisur de larges portions du parc. Cette solution implique alors un grand nombre d’opérations pour réparer ou remplacer les périphériques rendus défectueux suite à la mise à jour, ce qui peut représenter des coûts de maintenance élevés.

Résumé

La présente divulgation vient améliorer la situation.

Il est proposé un procédé, mis en œuvre par au moins un serveur informatique, pour contrôler un déploiement d’une mise à jour logicielle d’un ensemble de périphériques connectés au serveur, le procédé comprenant :
/a/ mettre à jour les périphériques d’un premier sous-ensemble dudit ensemble;
/b/ déterminer un pourcentage de périphériques du premier sous-ensemble pour lesquels une erreur de mise à jour est détectée ;
/c/ si le pourcentage déterminé est inférieur à un premier seuil, de tolérance :
-sélectionner un deuxième sous-ensemble de périphériques, distinct du premier, ayant une taille supérieure au premier sous-ensemble et réitérer les étapes /a/ à /c/ avec le deuxième sous-ensemble en tant que premier sous-ensemble ;
si le pourcentage déterminé est supérieur ou égal audit premier seuil :
-sélectionner un troisième sous-ensemble de périphériques, distinct du premier, ayant une taille inférieure au premier sous-ensemble et réitérer les étapes /a/ à /c/ avec le troisième sous-ensemble en tant que premier sous-ensemble.

Cette solution propose donc une régulation optimale du rythme de la campagne de mise à jour en fonction des erreurs constatées sur les périphériques mis à jour, avec un asservissement sur le nombre de périphériques mis à jour dans l’itération suivante de mise à jour.

En effet, le procédé de contrôle procède à la sélection successive de sous-ensembles distincts du parc auxquels on applique une mise à jour. La sélection successive de sous-ensembles permet de tester les effets de la mise à jour à chaque itération sur un nombre réduit de périphériques par rapport au parc total. Ensuite l’augmentation ou la diminution de la taille des sous-ensembles permet d’accélérer ou de ralentir la campagne de mise à jour en fonction de ce test. Ainsi, on peut terminer la campagne de mise à jour plus rapidement, ou sinon respectivement limiter la propagation des erreurs de mises à jour au sein du parc de périphériques.

On entend par « campagne de mise à jour » les opérations appliquées itérativement au parc de périphériques comme décrit ci-avant.

On entend par « taille » d’un sous-ensemble de périphériques, le nombre de périphériques dans ce sous-ensemble.

On entend par « mise à jour logicielle » la mise à jour de versions de logiciels auprès des périphériques, ou encore une mise à jour de valeurs de fonctionnement de ces périphériques, ou encore d’une topologie de ces périphériques dans un réseau par exemple, etc. Ainsi, le terme « mise à jour logicielle » est à interpréter au sens large et cette mise à jour peut générer :
- par exemple des erreurs critiques et dans ce cas le premier seuil précité peut être choisi relativement bas, tandis que
- ce premier seuil peut être choisi relativement haut pour des erreurs moins critiques.

Selon un mode de réalisation, le procédé comprend après l’étape /c/ que:
/d1/ on compare le pourcentage déterminé à l’étape /b/ à un deuxième seuil, supérieur au premier seuil, et
/d2/ on arrête la campagne de mise à jour si le pourcentage précité est supérieur au deuxième seuil.

Ce deuxième seuil (dit aussi « seuil critique » plus loin) est une limite fixée permettant d’arrêter la campagne de mise à jour si un pourcentage critique d’erreurs apparait dans le dernier sous-ensemble mis à jour.

Ce seuil peut être plus ou moins élevé en fonction de la criticité de l’erreur qui est vérifiée et plusieurs seuils peuvent être choisis respectivement en fonction des différents types d’erreurs détectées.

Selon un mode de réalisation, le procédé comprend après l’étape /c/:
/e1/ obtenir des résultats d’une pluralité de tests informatiques effectués sur des périphériques du premier sous-ensemble ;
/e2/ déterminer une valeur d’indice de qualité de fonctionnement en fonction desdits résultats ;
/e3/ comparer la valeur déterminée à une valeur seuil prédéfinie d’indice de qualité de fonctionnement ;  et
/e4/ si la valeur déterminée est supérieure à la valeur seuil prédéfinie, arrêter la campagne de mise à jour.

Mener des tests de performances générales, sur des périphériques mis à jour, permet de contrôler l’impact fonctionnel de la mise à jour. En effet, suite à une mise à jour, des périphériques ne présentant pas d’erreur d’un type prédéfini peuvent pour autant voir leurs performances générales de fonctionnement baisser. On peut ainsi stopper la campagne de mise à jour en cas de régression forte des résultats de performances générales (ici si les résultats sont au-dessus d’un seuil maximal).

Selon un mode de réalisation, un pourcentage de périphériques mis à jour parmi l’ensemble des périphériques est comparé à au moins un troisième seuil représentatif d’une phase de déploiement, et :
- si ledit pourcentage de périphériques mis à jour est inférieur au troisième seuil et si le pourcentage déterminé à l’étape /c/ est inférieur au premier seuil, la taille du deuxième sous-ensemble est accrue par une première fonction, relativement au nombre de périphériques dans le premier sous-ensemble, 
- si ledit pourcentage de périphériques mis à jour est supérieur au troisième seuil et si le pourcentage déterminé à l’étape /c/ est inférieur au premier seuil, la taille du deuxième sous-ensemble est accrue par une deuxième fonction, relativement au nombre de périphériques dans le premier sous-ensemble, 
la croissance par la deuxième fonction étant plus rapide que la croissance par la première fonction.

Le taux d’accroissement du nombre de périphériques par sous-ensemble augmente lors de la transition d’une phase de déploiement à la suivante. Cela permet d’accélérer le rythme de la campagne de mise à jour à mesure que la campagne de mise à jour progresse, et ce d’autant plus rapidement si le pourcentage de périphériques qui ont déjà été mis à jour est supérieur au troisième seuil précité.

Selon un mode de réalisation, un pourcentage de périphériques mis à jour parmi l’ensemble des périphériques est comparé à au moins un quatrième seuil représentatif d’une phase de test, le quatrième seuil étant inférieur au troisième seuil, et :
- si ledit pourcentage de périphériques mis à jour est inférieur au quatrième seuil et si le pourcentage déterminé à l’étape /c/ est inférieur au premier seuil, la taille du deuxième sous-ensemble est accrue par une troisième fonction, relativement au nombre de périphériques dans le premier sous-ensemble, 
la croissance par la première fonction étant plus rapide que la croissance par la troisième fonction.

Dans cette phase de test, l’augmentation du nombre de périphériques à mettre à jour est plus lente que dans les phases suivantes et notamment la phase de déploiement précitée. Cela permet de ne mettre à jour qu’un nombre relativement restreint de périphériques afin de tester les effets de la mise à jour progressivement sur de premiers périphériques du parc.

Selon un mode de réalisation, pour chaque fonction parmi la première fonction, la deuxième fonction et la troisième fonction, l’application de cette fonction à un nombre donne un résultat supérieur à ce nombre.

Les fonctions précitées sont utilisées pour déterminer la taille des sous-ensembles à mettre à jour en fonction de la taille du sous-ensemble précédemment mis à jour. Ainsi tant que chaque pourcentage d’erreur déterminé est en dessous de son seuil de tolérance, le nombre de périphériques mis à jour à l’itération suivante est supérieur à celui de l’itération précédente.

Par exemple, la première fonction peut être affine avec un coefficient directeur supérieur à un (par exemple y = 2x), alors que la deuxième fonction peut être une fonction puissance d’exposant supérieur à un (par exemple y = x²) et la troisième fonction peut impliquer une fonction logarithme (par exemple y = x + lnx).

Selon un mode de réalisation, un pourcentage de périphériques mis à jour parmi l’ensemble des périphériques est comparé à au moins un troisième seuil représentatif d’une phase de déploiement, et dans lequel :
- si ledit pourcentage de périphériques mis à jour est inférieur au troisième seuil et si le pourcentage déterminé à l’étape /c/ est supérieur au premier seuil, la taille du troisième sous-ensemble est décrue par une quatrième fonction, relativement au nombre de périphériques dans le premier sous-ensemble, 
- si ledit pourcentage de périphériques mis à jour est supérieur au troisième seuil et si le pourcentage déterminé à l’étape /c/ est supérieur au premier seuil, la taille du troisième sous-ensemble est décrue par une cinquième fonction, relativement au nombre de périphériques dans le premier sous-ensemble, 
la décroissance par la cinquième fonction étant plus rapide que la décroissance par la quatrième fonction.

Pour éviter de propager des erreurs de mise à jour aux périphériques restants dans le parc, on restreint ici, pour une itération suivante, le nombre de périphériques à mettre à jour dans le cas où trop d’erreurs ont été détectées à l’itération précédente (nombre d’erreurs supérieur au premier seuil). On évite d’autant plus cette propagation d’erreurs en choisissant la cinquième fonction précitée restreignant davantage (plus que la quatrième) le nombre de périphériques à mettre à jour à la prochaine itération.

En effet la cinquième fonction est active dans une phase de déploiement plus avancée que la phase dans laquelle la quatrième fonction est active. Ainsi, le rythme de la campagne de mise à jour est ralenti plus fortement à mesure que la campagne de déploiement avance.

Typiquement, pour chaque fonction parmi la quatrième fonction et la cinquième fonction, l’application de cette fonction à un nombre donne un résultat inférieur à ce nombre.

Par exemple, la quatrième fonction est affine avec un coefficient directeur inférieur à un (par exemple y=x/2), alors que la cinquième fonction est une fonction puissance d’exposant inférieur à un (par exemple « racine de x »).

Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre du procédé précité lorsque ce programme est exécuté par un processeur.

Selon un autre aspect, il est proposé un support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré un programme pour la mise en œuvre du procédé précité, lorsque ce programme est exécuté par un processeur.

Selon un autre aspect, la présente divulgation vise un serveur informatique comportant un circuit de traitement connecté à un ensemble de périphériques, dans lequel le circuit de traitement est configuré pour la mise en œuvre du procédé précité, pour contrôler un déploiement d’une campagne de mise à jour logicielle des périphériques dudit ensemble. Un exemple d’un tel circuit de traitement est illustré sur la figure 6 relative à un serveur informatique illustré aussi sur la figure 1, lesquelles figures sont commentées en détails dans la description qui suit.

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

Fig. 1

montre un exemple d’un parc de périphériques selon un mode de réalisation dans lequel les périphériques sont de natures différentes AP, ROUT, DV, ces périphériques sont connectés à au moins un serveur SER DM par un réseau NET.

Fig. 2

montre un ensemble total des périphériques du parc DV TOT connectées au serveur SER DM, selon un mode de réalisation dans lequel des sous-ensembles un à un distincts DV IT N-1, N, N+1 de l’ensemble total DV TOT sont mis à jour durant des itérations successives N-1, N, N+1.

Fig. 3

montre un exemple de déploiement d’une campagne de mise à jour sur les périphériques de l’ensemble DV TOT, selon un mode de réalisation dans lequel la campagne de déploiement est divisée en phases de déploiement PHA successives, avec une première phase dite de test TEST, une deuxième phase dite de progression prudente PRUD, et une troisième phase dite de généralisation GEN.

Fig. 4

montre différentes étapes d’un procédé, selon un mode de réalisation, permettant notamment de réguler le rythme de déploiement de la campagne de mise à jour des périphériques de l’ensemble DV TOT, notamment par l’intermédiarité de relations de récurrences entre le taille #DV IT N du sous-ensemble mis à jour à l’itération courante N et la taille #DV IT N-1 du sous-ensemble de l’itération précédente N-1.

Fig. 5

montre une table de décision à double entrée permettant de choisir, selon un mode de réalisation, une fonction Fp établissant une relation de récurrence, la première entrée est la phase de déploiement PHA, la seconde entrée est le pourcentage d’erreur par type d’erreur %ERR/TYP.

Fig. 6

montre schématiquement une structure d’unité de traitement CT pour la mise en œuvre d’une partie des étapes du procédé selon la figure 4 en particulier pour calculer la taille #DV IT N des sous-ensembles à mettre à jour ainsi que pour calculer les pourcentages d’erreur par type d’erreur %ERR/TYP (cette unité de traitement CT étant prévue par exemple dans le serveur SER DM).

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

Il est maintenant fait référence à la figure 1 qui présente un réseau de communication NET contenant au moins un serveur SER DM et un parc de périphériques AP, ROUT, DV, à mettre à jour.

Dans la suite il est fait référence au serveur SER DM, mais il doit être compris qu’un ou plusieurs serveurs distincts, connectés aux périphériques, peuvent être en charge de l’administration et de la mise à jour de l’ensemble de ces périphériques.

Chaque périphérique du parc peut communiquer avec le serveur SER DM par l’intermédiaire du réseau de communication. Le serveur SER DM est un serveur d’administration à distance des périphériques. Ce serveur est notamment configuré pour :
- détecter et mettre sous inventaire les périphériques présents dans un site client (numéro de série, version matérielle, version logicielle, …) ;
- mettre à jour le logiciel embarqué sur ses périphériques ;
- remonter des informations de supervision et des indicateurs de performance ;
- diagnostiquer au moyen d’opérations distantes les périphériques en cas de dysfonctionnement ;
- installer et configurer de nouveaux services sur ses périphériques.

On entend par « mise à jour logicielle » la mise à jour de versions de logiciel auprès des périphériques, ou encore une mise du logiciel embarqué (« firmware » en anglais), ou encore une mise à jour de valeurs de fonctionnement de ces périphériques, ou encore d’une topologie de ces périphériques dans un réseau par exemple, etc.

Les périphériques connectés à mettre à jour peuvent être similaires ou être différents. Ils peuvent être disposés sur un territoire étendu, comme un pays, ou sur un territoire restreint, comme une usine de production ou un local d’entreprise. Ces périphériques peuvent être par exemple, un parc de routeurs sans fil installés dans un site client, un parc de points d’accès mobiles installés dans une région par un opérateur de télécommunication, une flotte de machines-outils dans une usine, une flotte de capteurs par exemple météorologiques, un parc d’objets connectés ou encore une combinaison de plusieurs types de périphériques possédant par exemple un même logiciel à mettre à jour, ou autres.

Il est maintenant fait référence à la figure 2 dans laquelle le serveur SER DM commande une mise à jour d’un ensemble de périphériques DV TOT du parc précité. La mise à jour progressive du parc s’effectue par itérations successives et comprend :

-Les périphériques d’un premier sous-ensemble DV IT N-1 sont mis à jour à l’itération N-1 sur commande du serveur SER DM par un message via le réseau NET. Durant cette itération, les périphériques déterminent eux-mêmes d’éventuelles erreurs de mises à jour dont ils sont sujets parmi une liste d’erreurs types prédéterminées. Cette liste est transmise aux périphériques du premier sous-ensemble DV IT N-1 dans le message de commande du serveur SER DM. La liste d’erreurs types prédéterminées est stockée en mémoire dans le serveur SER DM. Cette liste d’erreurs types prédéterminées comprend différents dysfonctionnements possibles. Les différents types d’erreur d’un périphérique peuvent être par exemple : un fonctionnement sous optimal (anomalie), un fonctionnement partiel du périphérique (non critique), ou une erreur critique rendant le périphérique irrécupérable (critique), entre autres. Les périphériques du premier sous-ensemble envoient ensuite individuellement au serveur SER DM une série d’informations concernant les erreurs constatées suite aux mises à jour.

- En fonction des informations reçues par le serveur SER DM à l’itération N-1, le serveur SER DM (ou un serveur calculateur) détermine pour chaque type d’erreur un pourcentage d’un type d’erreur %ERR/TYP constaté dans le premier sous-ensemble DV IT N-1. A partir de ce pourcentage le serveur SER DM détermine le succès OK ou l’échec KO de la mise à jour sur le sous-ensemble DV IT N-1. Le succès OK de la mise à jour sur un sous-ensemble correspond à ce que tous les pourcentages d’erreur relatifs à un type d’erreur %ERR/TYP soient chacun individuellement en dessous d’un seuil de tolérance associé %TOL/TYP. A l’inverse, l’échec KO correspond au fait qu’au moins un pourcentage d’un type erreur parmi les différents types d’erreurs %ERR/TYP soit au-dessus de son seuil de tolérance associé %TOL/TYP.

Le serveur SER DM détermine ensuite un deuxième sous-ensemble de périphériques DV IT N, distinct du premier, à mettre à jour à la nouvelle itération N. Le serveur SER DM détermine notamment une taille #DV IT N pour ce deuxième sous-ensemble DV IT N en fonction du succès OK ou de l’échec KO de la mise à jour dans le premier sous-ensemble DV IT N-1 (on entend par « taille » le nombre de périphériques du sous-ensemble). Le choix de la croissance ou de la décroissance lors d’une itération de la taille d’un sous-ensemble par rapport à la taille du sous-ensemble de l’itération précédente dépend du succès OK ou de l’échec KO des mises à jour.

De manière générale, si les informations remontant des périphériques du premier sous-ensemble DV IT N-1 permettent au serveur de déterminer un succès OK de la mise à jour sur les périphériques du premier sous-ensemble, la taille #DV IT N d’un deuxième sous-ensemble à l’itération N est supérieure à la taille #DV IT N-1 du premier sous-ensemble. Dans le cas contraire, si les informations remontant des périphériques du premier sous-ensemble DV IT N-1 permettent au serveur de déterminer un échec KO de la mise à jour sur les périphériques du premier sous-ensemble, la taille #DV IT N d’un troisième sous-ensemble à l’itération N est inférieure à la taille #DV IT N-1 du premier sous-ensemble:

Comme illustré dans l’exemple de la figure 2 les informations remontant des périphériques du premier sous-ensemble DV IT N-1 permettent au serveur de déterminer un succès OK de la mise à jour sur les périphériques du premier sous-ensemble. Dans ce cas, la taille #DV IT N du deuxième sous-ensemble à l’itération N est donc plus grande que la taille #DV IT N-1 du premier sous-ensemble. En conséquence le rythme de la campagne de mise à jour accélère.

Toujours en référence à la figure 2, les informations remontant des périphériques du premier sous-ensemble DV IT N à l’itération N permettent au serveur de déterminer un échec KO de la mise à jour sur les périphériques du premier sous-ensemble, alors la taille #DV IT N+1 d’un troisième sous-ensemble de la prochaine itération N+1 est diminuée par rapport à la taille #DV IT N du second sous-ensemble. En conséquence le rythme de la campagne de mise à jour décélère.

Il est maintenant fait référence à la figure 3 qui présente une nouvelle fois l’ensemble total DV TOT des périphériques du parc. Selon un mode de réalisation l’ensemble total DV TOT est découpé en une pluralité de phases de déploiement PHA par lesquelles va passer la campagne de mise à jour.

Ici, la figure 3 comprend trois phases successives définies par des seuils représentatifs : une phase de test TEST (0%-5% du parc), une phase de progression prudente PRUD (5%-20% du parc), et une phase de généralisation GEN (20%-100% du parc).

Chacune de ces trois phases est successivement active durant la mise à jour d’une portion de l’ensemble total DV TOT. Dès que le pourcentage de périphériques mis à jour parmi l’ensemble des périphériques DV TOT dépasse un seuil représentatif, par exemple 20% pour la phase de progression prudente PRUD, cela signifie que la phase de progression prudente PRUD s’achève et que la suivante débute. Le seuil représentatif d’une phase PHA représente la limite supérieure d’une phase de déploiement PHA.

Ces phases de déploiement PHA sont mises en place pour adapter le rythme des mises à jour à l’avancement de la campagne. A chaque phase de déploiement PHA correspondent des taux de croissance et de décroissance de la taille des sous-ensembles.

Selon un mode de réalisation ces taux de croissance et de décroissance du nombre de périphériques entre chaque itération sont de plus en plus forts au cours de la campagne. Chaque phase de déploiement PHA possède des taux de croissance et de décroissance en valeur absolue plus grands que les taux de la phase PHA précédente.

Le taux de croissance augmente entre chaque phase PHA successive de manière à accélérer une campagne de mise à jour rencontrant des succès de mise à jour (%ERR/TYP en dessous du seuil de tolérance %TOL/TYP), ce qui permet de terminer la campagne au plus vite.

Complémentairement dans le cas où un pourcentage d’erreur %ERR/TYP est supérieur à son seuil de tolérance associé %TOL/TYP la décroissance du nombre de périphériques mis à jour à chaque itération doit permettre de ralentir sensiblement la campagne de mise à jour. Or plus la campagne est avancée et plus la taille des sous-ensembles mis à jour à chaque itération est grande. Ainsi pour pouvoir éventuellement stopper la campagne de mise à jour en un minimum d’itérations, le taux de décroissance est de plus en plus fort à mesure que la phase de déploiement PHA est avancée.

Toujours à propos de la figure 3 :
-durant la phase de test TEST, en cas d’augmentation de la taille des sous-ensembles à mettre à jour, l’augmentation évolue moins rapidement entre deux itérations que durant la phase de progression prudente PRUD ;
-de même, durant la phase de progression prudente PRUD, en cas d’une augmentation de la taille des sous-ensembles à mettre à jour, l’augmentation évoluera moins rapidement entre deux itérations que durant la phase de généralisation GEN ;
-complémentairement, en cas de diminution de la taille du sous-ensemble à mettre à jour suite à un échec : durant la phase de progression prudente PRUD, la diminution de la taille des sous-ensembles à mettre à jour évoluera moins rapidement entre deux itérations que durant la phase de généralisation GEN.

Il est aussi bien-sûr possible, dans un mode de réalisation plus minimaliste, que la campagne de mise à jour soit réalisée en en seule et unique phase de déploiement.

Il est maintenant fait référence à la figure 4 qui présente selon un mode de réalisation les étapes d’une itération durant une phase de déploiement comprenant notamment la mise à jour d’un sous-ensemble de périphériques.

Les étapes de la figure 4 peuvent être ordonnées dans un ordre différent que celui exposé.

Le procédé ci-après fait référence aux équipements illustrés dans la figure 1 à titre d’exemple. Néanmoins, on comprend que ce procédé peut être alternativement mis en œuvre par d’autres équipements que ceux illustrés sur la figure 1.

A l’initialisation, des périphériques sont choisis de manière aléatoire afin de constituer un premier sous-ensemble de périphériques de l’itération N=1. Dans un autre mode de réalisation, des périphériques sont sélectionnés de manière à être représentatifs des différents profils des périphériques à mettre à jour. La taille de ce premier sous-ensemble est définie par l’opérateur de réseau.

A l’étape S1, une itération courante N débute. Le serveur SER DM évalue tout d’abord si l’intégralité des périphériques du parc DV TOT a été mise à jour ou non à l’itération N-1. Si l’intégralité des périphériques du parc a été effectivement mise à jour, alors la campagne de mise à jour est terminée et l’itération s’arrête. L’étape S2 s’effectue pour stopper la campagne. Dans le cas contraire l’itération se poursuit à l’étape S3.

A l’étape S3 le serveur SER DM évalue un pourcentage de périphériques déjà mis à jour DV UPT par rapport à l’ensemble total des périphériques DV TOT du parc à mettre à jour. Le serveur SER DM compare ce pourcentage au seuil représentatif de chaque phase de déploiement de manière à déterminer la phase de déploiement PHA en cours à l’itération courante N.

A l’étape S4 le serveur SER DM calcule la taille #DV IT N du sous-ensemble de périphériques DV IT N à mettre à jour à l’itération N courante. La taille #DV IT N du sous-ensemble de périphériques à mettre à jour à l’itération courante est calculée par une fonction Fp.

La fonction Fp prend en entrée le nombre de périphériques #DV IT N-1 mis à jour à l’itération N-1 et donne en sortie le nombre de périphérique #DV IT N. La fonction Fp établit une relation de récurrence d’une suite S#DV IT. Cette suite est composée des tailles #DV IT N successives des sous-ensembles mis à jour à chaque itération. La somme jusqu’à l’itération courante N de la suite S#DV IT donne le nombre de périphériques mis à jour au total depuis le début de la campagne de mise à jour.

La suite S#DV IT entre chaque itération est, soit croissante, soit décroissante en fonction de l’échec KO ou du succès OK de la mise à jour du sous-ensemble précédent, comme expliqué dans la description en relation avec la figure 2.

Un taux de croissance ou de décroissance de la suite S#DV IT est fixé par la fonction Fp. Dans un mode de réalisation comprenant plusieurs phases PHA de déploiement, la fonction Fp est différente d’une phase de déploiement PHA à l’autre.

A l’étape S5 le serveur SER DM commande la mise à jour des périphériques du sous-ensemble DV IT N, dont la taille #DV IT N a été déterminée à l’étape S4. Les périphériques de ce nouveau sous-ensemble sont distincts des périphériques déjà mis à jour, de manière à ne pas mettre à jour des périphériques déjà à jour. Le serveur SER DM envoie donc une commande de mise à jour aux périphériques concernés via le réseau NET. Cette commande contient des instructions pour la mise à jour, comme par exemple comme il sera vu plus tard une liste d’un ensemble de tests à mener suite à la mise à jour.

A l’étape S6, à la suite de la mise à jour des périphériques du sous-ensemble DV IT N de l’itération courante N, chaque périphérique du sous-ensemble courant envoie un rapport de fonctionnement au serveur SER DM, par exemple sous la forme d’un ou plusieurs fichiers comprenant du texte.

Dans le cas où un périphérique fonctionne correctement, après la mise à jour, le rapport de fonctionnement est un simple accusé de réception envoyé par le périphérique au serveur SER DM. Dans le cas où un périphérique présente un ou plusieurs types d’erreurs, le rapport de fonctionnement envoyé par un périphérique au serveur SER DM comprend au moins le type de l’erreur détectée (anomalie, non critique, critique, ou autre). L’absence d’information à propos d’un périphérique au-delà d’un certain délai depuis l’envoi de la commande de mise à jour par le serveur peut être considérée comme une erreur critique.

Le rapport de fonctionnement envoyé au serveur SER DM par un périphérique peut comprendre aussi des résultats d’un ou plusieurs tests de qualité de fonctionnement QoF effectués suite à cette mise à jour.

Le résultat d’un test de qualité de fonctionnement peut être par exemple le débit binaire (ou « bitrate » en anglais) d’une caméra embarquée, ou la puissance d’un signal radio émis, entre autres. Un catalogue de test de qualité de fonctionnement peut être défini pour une mise à jour donnée. Le catalogue regroupe un ensemble de tests de qualité de fonctionnement QoF que chaque périphérique effectue à la suite d’une mise à jour, et dont les résultats sont centralisés dans le rapport de fonctionnement qui est envoyé au serveur SER DM.

A l’étape S7, suite à la réception des rapports de fonctionnement des périphériques du sous-ensemble DV IT N, le serveur SER DM détermine :
- un pourcentage d’un type d’erreur %ERR/TYP parmi le sous-ensemble DV IT N ;
- un indice de qualité de fonctionnement QoF IDX.
L’indice de qualité de fonctionnement QoF IDX peut être basé sur au moins une partie des résultats de tests de fonctionnement obtenus à l’étape S6 de l’itération courante N. La construction de cet indice de qualité de fonctionnement QoF IDX peut être par exemple une somme pondérée des moyennes des résultats relatifs à chaque test de l’ensemble des périphériques du sous-ensemble DV IT N mis à jour à l’itération courante N.

A l’étape S8, le serveur SER DM compare chaque pourcentage d’un type d’erreur %ERR/TYP calculé à l’étape S7, à un seuil critique associé à ce type d’erreur %CRIT/TYP. Ces seuils critiques peuvent être différents pour chaque type d’erreur, par exemple 1% pour les erreurs critiques, 10% pour les erreurs non critiques, et 25% pour les anomalies. En termes de valeur, chaque seuil critique %CRIT/TYP par type d’erreur est supérieur à son seuil de tolérance associé %TOL/TYP.

Si un seul pourcentage d’un type d’erreur %ERR/TYP dépasse son seuil critique %CRIT/TYP, la campagne de mise à jour est arrêtée.

A l’étape S9, suite à l’arrêt de la mise à jour à l’étape S8 (ou à l’étape S11 décrite ultérieurement), un fichier texte LOG peut être envoyé au serveur SER DM par chaque périphérique du dernier sous-ensemble mis à jour durant l’itération courante. Alternativement tous les périphériques déjà mis à jour dans le parc DV TOT peuvent envoyer un fichier texte LOG au serveur SER DM, cette alternative permettant de pouvoir étudier l’intégralité des périphériques mis à jour. Chaque fichier texte LOG reprend par exemple de manière chronologique les instructions exécutées par un périphérique suite à la réception de l’ordre de mise à jour envoyé par le serveur SER DM.

A l’étape S10, selon un mode de réalisation, le serveur SER DM envoie un ordre d’annulation de la mise à jour (ou stratégie de retour arrière ou « rollback » en anglais) aux périphériques du dernier sous-ensemble, mis à jour durant l’itération courante N. Alternativement le serveur SER DM peut envoyer un ordre d’annulation de la mise à jour à tous les périphériques déjà mis à jour dans le parc DV TOT, depuis la première itération jusqu’à l’itération courante N. Cette manœuvre peut être avantageuse par exemple pour garantir l’unicité de la version logicielle installée sur les périphériques du parc.

A l’étape S11, le serveur SER DM compare l’indice de qualité de fonctionnement QoF IDX calculé à l’étape S7 à un seuil critique de qualité de fonctionnement IDX CRIT. Cet indice est construit de telle manière que si l’indice de qualité de fonctionnement QoF IDX dépasse son seuil critique IDX CRIT, la campagne de mise à jour est arrêtée. Dans le cas où la campagne de mise à jour est arrêtée, les prochaines étapes peuvent être l’étape S9 puis S10, comme vu précédemment permettant de stopper la campagne et d’annuler les mises à jour.

En revanche si les seuils %CRIT/TYP et IDX CRIT ne sont pas dépassés aux étapes S8 et S11, alors l’itération courante N continue.

A l’étape S12, le serveur SER DM compare chaque pourcentage d’un type d’erreur %ERR/TYP à son seuil de tolérance associé %TOL/TYP. L’étape S12 est découpée en deux étapes S121 et S122 sélectionnées alternativement en fonction du résultat de la comparaison précitée.

L’étape S121 est choisie si au moins un pourcentage d’un type d’erreur %ERR/TYP, parmi les pourcentages des types d’erreurs calculés à l’étape S7, est supérieur à son seuil de tolérance associé %TOL/TYP. L’étape suivante est alors l’étape S13, l’étape S14 n’étant donc pas effectuée durant cette itération.

L’étape S122 est choisie si chaque pourcentage d’un type d’erreur %ERR/TYP est en dessous de son seuil de tolérance associé. L’étape suivante est alors l’étape S14, l’étape S13 n’est pas effectuée à cette itération.

Les étapes S13 et S14 consistent dans le choix d’une fonction Fp pour l’itération suivante N+1 en fonction de la phase de déploiement courante PHA.

A l’étape S13, suite à la comparaison de l’étape S121, le serveur SER DM choisit une fonction préenregistrée Fsp dans une table de décision pour être la nouvelle fonction Fp. La fonction Fsp assure la diminution de la taille du sous-ensemble #DV IT N+1 de l’itération suivante N+1 par rapport à la taille du sous-ensemble #DV IT N de l’itération courante N. Une telle fonction Fsp permet de diminuer le rythme de mise à jour dans le cas où le pourcentage d’erreur obtenu à l’étape S7 indique un dysfonctionnement de la campagne de mise à jour dans le sous-ensemble de périphériques de l’itération courante.

A l’étape S14, de manière analogue à l’étape S13, suite à la comparaison de l’étape S122, le serveur SER DM choisit une fonction préenregistrée Fqp dans une table de décision pour être la nouvelle fonction Fp. La fonction Fqp assure l’augmentation de la taille du sous-ensemble #DV IT N+1 de l’itération suivante N+1 par rapport à la taille du sous-ensemble #DV IT N de l’itération courante N.

L’étape S15 consiste finalement au passage à l’itération suivante par l’incrémentation du nombre N.

Il est maintenant fait référence à la figure 5 qui présente un exemple de table de décision permettant au serveur SER DM de choisir la fonction Fp. A chaque itération deux options pour la fonction Fp sont possibles, la fonction Fsp et Fqp. Le choix de la fonction Fp dépend d’un part de la phase de déploiement PHA, et d’autre part des pourcentages d’erreur %ERR/TYP par type d’erreur. Les fonctions Fp, (Fsp et Fqp) sont des relations de récurrence de la suite S#DV IT.

Les lignes 1 à 3 de la table représentent les phases déploiement PHA successives. Chronologiquement la phase de test TEST, puis la phase de progression prudente PRU, et enfin la phase de généralisation GEN.

Les colonnes A et B représentent les deux possibilités alternatives S121 ou S122 présentés à l’étape S12 de la figure 4. La colonne A présente des situations dans lesquelles, au moins un pourcentage d’un type d’erreur %ERR/TYP, parmi les pourcentages des types d’erreur calculés à l’étape S7, est supérieur à son seuil de tolérance associé. Complémentairement la colonne B présente des situations dans lesquelles chaque pourcentage d’un type d’erreur %ERR/TYP est en dessous de son seuil de tolérance associé.
Les cases A1, A2, A3 présentent des exemples de fonctions Fsp pour chaque phase de déploiement PHA successive. Dans ces exemples, les fonctions Fsp sont positives et inférieures à la fonction identité (f(X)=X). Il peut s’agir progressivement de fonctions affines avec des coefficients directeurs inverses de nombres plus grands que 1 (e, puis f), voire ensuite de fonctions « exposant 1/g » (avec g>1). Dans un exemple de réalisation présenté plus haut, e=f=2 et g=2 (de sorte que f(X)=X/2, puis f(X)=racine carrée de X). Ainsi, les valeurs d’images des fonctions Fsp associées et des valeurs d’antécédents supérieurs à un, sont inférieures à la fonction identité. De plus, comme il a été vu précédemment, plus la phase de déploiement est avancée (proche de la fin de la campagne de mise à jour), et plus le taux de décroissance de la suite S#DV IT, défini par la fonction Fsp, est important.

Les cases B1, B2, B3 présentent des exemples de fonctions Fqp pour chaque phase de déploiement PHA successives. Dans ces exemples, les fonctions Fqp sont positives et supérieures à la fonction identité (f(X)=X). Il peut s’agir progressivement de fonctions de type A ln(X) + B X (par exemple avec A=B=1), puis affine avec un coefficient directeur C supérieur à 1 (par exemple f(X)=2X), voire ensuite d’une fonction « exposant d » (avec d>1, par exemple f(X)=X²). Ainsi, les valeurs d’images des fonctions Fqp associées et des valeurs d’antécédents supérieures à un, sont supérieures à la fonction identité. De plus, comme il a été vu précédemment, plus la phase de déploiement est avancée (proche de la fin de la campagne de mise à jour), et plus le taux de croissance de la suite S#DV IT, défini par la fonction Fqp, est important.

Il est désormais fait référence à la figure 6. Selon un mode de réalisation le serveur SER DM comporte le circuit de traitement CT, lequel peut comporter typiquement, comme illustré dans l’exemple de la figure 6 :
- une interface d’entrée IN, pour recevoir au moins les messages issus des périphériques mis à jour,
- une unité de mémoire MEM pour stocker au moins la table de correspondance permettant au serveur SER DM de choisir la fonction Fp, ainsi que des données d’instructions d’un programme informatique selon un aspect de la présente divulgation. Cette mémoire peut aussi contenir la liste des types d’erreurs prédéterminées.
- un processeur PROC pour :
* coopérer avec la mémoire MEM, et ainsi exécuter les instructions du programme pour mettre en œuvre le procédé selon au moins certaines étapes illustrées sur la figure 4.

Claims (9)

1. Procédé, mis en œuvre par au moins un serveur (SER DM) informatique, pour contrôler un déploiement d’une mise à jour logicielle d’un ensemble (DV TOT) de périphériques connectés au serveur, le procédé comprenant :
   /a/ mettre à jour (S5) les périphériques d’un premier sous-ensemble (DV ITN-1) dudit ensemble ;
   /b/ déterminer (S6) un pourcentage (%ERR/TYP) de périphériques du premier sous-ensemble pour lesquels une erreur de mise à jour est détectée ;
   /c/ si le pourcentage déterminé est inférieur (S122) à un premier seuil (%TOL/TYP) :
   -sélectionner (S14) un deuxième sous-ensemble (DV ITN) de périphériques, distinct du premier, ayant une taille supérieure au premier sous-ensemble et réitérer les étapes /a/ à /c/ avec le deuxième sous-ensemble en tant que premier sous-ensemble ;
   si le pourcentage déterminé est supérieur ou égal (S121) audit premier seuil :
   -sélectionner (S13) un troisième sous-ensemble de périphériques, distinct du premier, ayant une taille inférieure au premier sous-ensemble et réitérer les étapes /a/ à /c/ avec le troisième sous-ensemble en tant que premier sous-ensemble.
2. Procédé selon la revendication 1, comprenant après l’étape /c/ :
   /d1/ comparer (S8) le pourcentage déterminé (%ERR/TYP) à l’étape /c/ à un deuxième seuil (%CRIT/TYP) supérieur au premier seuil (%TOL/TYP) ;
   /d2/ arrêter (S9, S10) la campagne de mise à jour si le pourcentage déterminé est supérieur au deuxième seuil.
3. Procédé selon l’une des revendications 1 ou 2, comprenant après l’étape /c/ :
   /e1/ obtenir (S6) des résultats d’une pluralité de tests informatiques effectués sur des périphériques du premier sous-ensemble (DV ITN-1) ;
   /e2/ déterminer (S7) une valeur (QoF IDX) d’indice de qualité de fonctionnement en fonction desdits résultats ;
   /e3/ comparer (S11) la valeur déterminée à une valeur seuil (IDX CRIT) d’indice de qualité de fonctionnement; et
   /e4/ si la valeur déterminée est supérieure à la valeur seuil, arrêter (S9, S10) la campagne de mise à jour.
4. Procédé selon l'une des revendications précédentes, dans lequel un pourcentage de périphériques mis à jour (%DV UPT) parmi l’ensemble (DV TOT) des périphériques est comparé à au moins un troisième seuil représentatif d’une phase de déploiement (PHA), et dans lequel :
   - si ledit pourcentage de périphériques mis à jour est inférieur au troisième seuil et si le pourcentage (%ERR/TYP) déterminé à l’étape /c/ est inférieur au premier seuil (%TOL/TYP), la taille du deuxième sous-ensemble (DV ITN) est accrue par une première fonction, relativement au nombre de périphériques dans le premier sous-ensemble (DV ITN-1), 
   - si ledit pourcentage de périphériques mis à jour est supérieur au troisième seuil et si le pourcentage déterminé à l’étape /c/ est inférieur au premier seuil, la taille du deuxième sous-ensemble est accrue par une deuxième fonction, relativement au nombre de périphériques dans le premier sous-ensemble, 
   la croissance par la deuxième fonction étant plus rapide que la croissance par la première fonction.
5. Procédé selon la revendication 4, dans lequel le pourcentage de périphériques mis à jour parmi l’ensemble (DV TOT) des périphériques est comparé à au moins un quatrième seuil représentatif d’une phase de test (PHA TEST), le quatrième seuil étant inférieur au troisième seuil, et dans lequel :
   - si ledit pourcentage de périphériques mis à jour (%DV UPT) est inférieur au quatrième seuil et si le pourcentage (%ERR/TYP) déterminé à l’étape /c/ est inférieur au premier seuil (%TOL/TYP), la taille du deuxième sous-ensemble (DV ITN) est accrue par une troisième fonction, relativement au nombre de périphériques dans le premier sous-ensemble (DV ITN-1), 
   la croissance par la première fonction étant plus rapide que la croissance par la troisième fonction.
6. Procédé selon l'une des revendications précédentes, dans lequel le pourcentage de périphériques mis à jour (%DV UPT) parmi l’ensemble (DV TOT) des périphériques est comparé à au moins un troisième seuil représentatif d’une phase de déploiement (PHA), et dans lequel :
   - si ledit pourcentage de périphériques mis à jour (%DV UPT) est inférieur au troisième seuil et si le pourcentage (%ERR/TYP) déterminé à l’étape /c/ est supérieur au premier seuil (%TOL/TYP), la taille du troisième sous-ensemble est décrue par une quatrième fonction, relativement au nombre de périphériques dans le premier sous-ensemble (DV ITN-1), 
   - si ledit pourcentage de périphériques mis à jour est supérieur au troisième seuil et si le pourcentage déterminé à l’étape /c/ est supérieur au premier seuil, la taille du troisième sous-ensemble est décrue par une cinquième fonction, relativement au nombre de périphériques dans le premier sous-ensemble, 
   la décroissance par la cinquième fonction étant plus rapide que la décroissance par la quatrième fonction.
7. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications précédentes lorsque ce programme est exécuté par un processeur.
8. Support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré un programme pour la mise en œuvre du procédé selon l’une des revendications 1 à 6, lorsque ce programme est exécuté par un processeur.
9. Serveur informatique comportant un circuit de traitement connecté à un ensemble de périphériques, dans lequel le circuit de traitement est configuré pour la mise en œuvre du procédé selon l’une des revendications 1 à 6, pour contrôler un déploiement d’une campagne de mise à jour logicielle des périphériques dudit ensemble.