Brevet FR2962829A1 — publié le 20120120

PROCEDE ET SYSTEME PERMETTANT D'OPERER, UN SYSTEME OU UN EQUIPEMENT EN FONCTIONNEMENT L'objet de la présente invention concerne un procédé et un système associé pour gérer des services d'opération, d'exploitation et de support d'un système ou d'un équipement en vue le cas échéant de garantir son retour à un état opérationnel pouvant correspondre notamment à un niveau de Qualité de Service (QoS ou Quality of Service) défini suite, par exemple, à une déviation, une anomalie ou à un incident de fonctionnement. L'invention permet notamment d'anticiper, de gérer les problèmes de fonctionnement d'infrastructures comportant, par exemple, des sites « statiques » ou « mobiles ». Les clients et utilisateurs d'équipements, de systèmes exigent 15 généralement de leurs fournisseurs ou partenaires un niveau très élevé d'engagement de résultat en termes : - d'opération, - de disponibilité opérationnelle, - de capacité, 20 - de probabilité de réussite de mission - de Qualité de Service (QoS) (en terme par exemple de taux d'erreur bit, de couverture radio,...) avec bien souvent de fortes contraintes opérationnelles, budgétaires et une incertitude élevée de la mise en oeuvre (profil d'emploi, 25 heures effectives de fonctionnement, organisation de l'opération, de l'exploitation et du soutien, réalité du besoin opérationnel « in situ »). Cet état de fait entraîne pour les industriels une nécessité de mener des analyses de sûreté de bon fonctionnement et de résilience des systèmes conduisant à des sommes de risques qui résultent d'incertitudes ou d'un nombre 30 d'équations indéterminées. Durant ces analyses et par la suite en phase d'exploitation, l'un des problèmes techniques est l'allocation de ressources de manière optimale, selon la « criticité » de la déviation ou de l'incident correspondant à l'enjeu opérationnel, la « mission », et cela de façon sécurisée. Pour cela, il faut donc connaître les positions et les disponibilités des ressources de manière sécurisée, transférer ou accéder à des informations de manière sécurisée, effacer des données sensibles en cas de problèmes ou de suspicions, aider les personnes en « opération/exploitation /maintenance » en Back Office notamment à prendre les bonnes décisions (aide à la décision, aide au pronostic et au diagnostic). La figure 1 schématise un processus généralement mis en oeuvre selon l'art antérieur pour l'exploitation par l'utilisateur final et l'opération et/ou la maintenance d'un système. L'échange entre le client et l'industriel se fait, bien qu'un certain nombre d'outils soient de plus en plus mis en oeuvre, pour : indiquer s'il y a dysfonctionnement du système ou de l'équipement par l'intermédiaire d'une fiche incident, par mail ou encore par portail web I, par l'aide au diagnostic (assistance téléphonique, téléassistance, ..) II, par la capitalisation du RETEX ou RETour d'EXpérience III. Le Système d'Information Logistique SIL permet de stocker toutes les informations échangées nécessaires à cette capitalisation. L'un des objectifs de la présente invention consiste donc à proposer un procédé et système qui permet d'optimiser de façon significative des moyens mis en oeuvre, dès la phase d'analyse initiale d'étude et de conception d'un système ou d'un équipement, pour son exploitation, son opération ou son soutien durant tout son cycle de vie . La figure 2 schématise le procédé et le système permettant d'optimiser le processus de l'art antérieur. L'échange entre le client et l'industriel se fait au travers d'outils pour indiquer une déviation ou un dysfonctionnement de son système ou équipement au travers d'un module d'observabilité/contrôlabilité ou d'une fiche d'incident. Cette déviation ou ce dysfonctionnement est analysé dans le module d'observabilité/contrôlabilité de manière automatique ou semi-automatique pour des ressources en fonction de la planification des ressources et des moyens dans l'ERP (bloc n° 54 sur la Fig. 7) ou d'effectuer l'action (modes correctifs) prévue et pré-chargée. Glossaire utilisé dans la description - RETEX : RETour d'EXpérience. - IVVQ : Intégration, Vérification, Validation et Qualification. - FIT : Fiche d'Intervention Technique. - FEX : Fiche d'EXploitation . - OCC : Organe de Contrôle Central. - SIL : Système d'Information Logistique. - GMAO : Gestion de la Maintenance Assisté par Ordinateur. - PDA : Personal Digital Assistants. - CR : Compte-Rendu - GPS : Global Positionning System. - BASE DE DONNEES SIL : base de données du Système d'Information Logistique. - Base de données GMAO: base de données de la Gestion de la Maintenance Assistée par Ordinateur. - SMI : Service, Maintenance et Intervention. - ERP : Enterprise Ressource Planning. - COL : Customer OnLine - service en ligne L'idée mise en oeuvre dans le procédé selon l'invention repose notamment sur un apprentissage incrémentai hiérarchisé, étudié dans les principes dès la phase d'étude, démarrant dès la phase d'Intégration, Vérification, Validation et Qualification (dite phase d'IVVQ) et entretenu tout au long du cycle de vie du système ou de l'équipement ; provoquant un 30 déclenchement automatique ou semi-automatique, hiérarchisé au même titre que l'apprentissage d'actions correctives « intégrées », désignées « autocicatrisation » dans le reste de la description, ou d'allocation de ressources strictement pertinentes (compétences et moyens, outillages) « à temps » du fait de l'élaboration de vecteurs d'état pouvant « signer » la situation et évoluant selon l'apprentissage incrémentai ; une diffusion quasi immédiate des apprentissages/modes correctifs à l'ensemble des équipements ou des systèmes de configurations équivalentes relativement à un retour d'Exploitation, d'Opération et d'Expérience. L'invention concerne un procédé pour gérer des services ~o d'exploitation, d'opération et/ou de support à un système ou à un équipement en vue de leur retour en mode opérationnel ainsi que la diffusion d'un auto apprentissage (agissant comme les modèles biologiques tels que l'auto immunisation et la vaccination) suite à une déviation, une anomalie ou à un incident de fonctionnement caractérisé en ce qu'il comporte au moins 15 les étapes suivantes : - Une étape de définition préalable de paramètres à surveiller dans ledit système ou ledit équipement, l'ensemble des paramètres définis comportant une signature ou un vecteur d'état associé, permettant de piloter un dispositif d'auto cicatrisation ou, à défaut, de transmettre 20 automatiquement cette signature afin de déclencher une intervention ad hoc (télé-opération, envoi d'une ressource dûment qualifiée) selon la criticité dudit incident, - Une première étape de recherche, a priori, de l'organisation optimale (traduite par une architecture physique, logicielle ou humaine) pour les 25 services nécessaires au fonctionnement correct dudit système ou dudit équipement, - Une deuxième étape, de recherche d'un optimum en terme d'organisation matérielle, logistique, du soutien au moyen d'identifications de singularités ou de « pivots » et d'analyses de 30 sensibilités associées mettant en évidence un maximum de relations de cause à effet ou de « vraisemblances » classées par ordre d'efficacité décroissante, c'est-à-dire qu'il y a une recherche des singularités du système, - Une troisième étape d'utilisation d'un outil d'émulation classiquement utilisé a posteriori, utilisé en anticipation depuis les étapes de définition du système précitées, permettant de simuler des incidents, des pannes, des anomalies, des dysfonctionnements et d'enrichir les visions qualitatives et quantitatives obtenues lors de la première et de la deuxième étape conduisant à un optimum relativement à l'architecture et de créer, en conséquence, les maquettes virtuelles ou physiques nécessaires et suffisantes, à la lumière des analyses précédentes, dès les phases de validation du système, de validation ou de qualification dudit système ou dudit équipement. Celaafin de pouvoir, d'une part, entraîner des mémoires présentes dans lesdits dispositifs d'auto cicatrisation qui pourront être émulées, etgénéralisées en déploiement des dispositifs sur l'ensemble de l'architecture physique livrée à l'utilisateur, puis, d'autre part, d'effectuer un pré chargement de toutes les hypothèses et données associées dimensionnant dans tous les outils du Client et ceux des Industriels, essentiellement dans les outils de Gestion de Maintenance Assistée par Ordinateur, conformément à l'architecture du système ou de l'équipement, - Une étape de déploiement sur l'ensemble de l'architecture livrée à l'utilisateur, - Une quatrième étape de remontée des données opérationnelles où ledit procédé alimente « au fil de l'eau » l'outil de « rejeu » / émulation à partir des données opérationnelles dimensionnantes observées, - Une cinquième étape d'analyses et de caractérisations, statistiques, effectuées sur l'ensemble des informations compilées sur les mises en vraie grandeur des équipements et des systèmes lors de la quatrième étape, l'ensemble desdites étapes permettant de créer une boucle de contre réaction qui temporellement est décroissante du fait dudit dispositif global d'optimisation permanente d'auto apprentissage local, de diffusion de déviation, d'anomalie, d'incidents ou d'évènements et de mécanismes associés de retour en mode opérationnel, o Soit ces résultats sont conformes aux résultats attendus, o Soit, il y a divergence et le procédé déclenche automatiquement ou semi-automatiquement, des actions correctives intégrées ou des allocations de ressources afin de corriger la divergence, et/ou des phases de redéfinition de l'architecture de l'équipement, - Une sixième étape de transmission des informations à intégrer dans une base d'apprentissage et de diffusion quasi-instantanée de la solution à divergence constatée et résolue à l'ensemble des sites de configurations identiques. L'objet de l'invention concerne aussi un système permettant de gérer les déviations, les anomalies ou les dysfonctionnements dans un système ou un équipement caractérisé en ce qu'il comporte au moins les éléments adaptés pour exécuter les étapes du procédé décrit précédemment : - Un ou plusieurs capteurs associés à un paramètre de fonctionnement dudit équipement ou dudit système, les informations lues sur lesdits capteurs étant transmises à un organe de contrôle central, - Ledit organe de contrôle central ayant notamment pour fonction de décider ou non d'une intervention à effectuer sur les sites en fonctionnement, au-delà de toute action automatique du fait du dispositif d'auto cicatrisation - Ledit organe de contrôle central comprenant au moins un organe d'observation recevant les différentes données en provenance des capteurs positionnés sur chaque équipement d'un système, ledit organe d'observation étant en liaison avec une base de données SIL, et avec un organe de contrôle local relié à une base d'apprentissage, ledit organe de contrôle local transmettant les données à un organe de génération de commandes, ledit organe de génération de commande recevant aussi les données validées par un utilisateur. D'autres caractéristiques et avantages du dispositif selon l'invention apparaîtront mieux à la lecture de la description qui suit d'un exemple de réalisation donné à titre illustratif et nullement limitatif annexé des figures qui représentent : - La figure 1, un exemple d'architecture d'un système de soutien en maintenance selon l'art antérieur, - La figure 2, un exemple de système selon la présente invention, - La figure 3A, un logigramme des étapes mises en oeuvre dans le procédé et la figure 3B la possibilité de reconsidérer l'architecture du système, - La figure 4, une représentation temporelle des activités avant/après la 15 mise en oeuvre du procédé selon l'invention, - La figure 5, un exemple de synoptique pour une architecture globale système selon l'invention, - La figure 6A, un exemple d'architecture fonctionnelle d'un réseau de télécommunications supervisé pour des sites fixes, et la figure 6B pour 20 des sites mobiles, - La figure 7, une vue de l'architecture du système d'informations ou SMI selon l'invention, - La figure 8, un exemple de couplage du service en ligne ou « Customer Online » -ou « service en ligne », 25 - La figure 9, un exemple de processus de gestion des incidents d'une supervision chez l'industriel, - La figure 10, une représentation de processus de gestion des incidents de la supervision, - La figure 11, la représentation du processus de l'action, 30 - La figure 12, le schéma d'écriture du rapport d'intervention, - La figure 13, le processus de gestion des écritures client, - La figure 14, le processus de saisie des FIT client lors de la maintenance, - La figure 15 et la figure 16, le processus de gestion des stocks, - La figure 17, un exemple des étapes mises en oeuvre pour la réallocation des stocks, - La figure 18, le processus de gestion des stocks et l'arrivée de pièces ou de nouveaux équipements, et - La figure 19, une représentation macroscopique du procédé mis en oeuvre selon l'invention. Afin de mieux comprendre le fonctionnement du procédé selon l'invention, la description qui suit est donnée à titre illustratif et nullement limitatif dans le cas de l'exploitation/maintenance d'un réseau de télécommunications. L'objet de l'invention consiste, notamment à utiliser successivement, de la phase d'analyse initiale et durant tout le cycle de vie des équipements et systèmes, plusieurs procédés d'analyses classiques, enchaînés entre eux et dans le temps, intégrant du RETEX afin de pouvoir lever ces indéterminations par réductions d'incertitudes et imprécisions de tous ordres et conduire ainsi à un optimum de moyens à mettre en oeuvre afin de garantir l'atteinte du résultat recherché. Ces procédés d'analyses globaux peuvent avantageusement exploiter des dispositifs d'enregistrement automatiques ou manuels, installés soit au sein des équipements ou systèmes étudiés ou être mis à disposition des personnels opérations, exploitants ou en charge du soutien de la maintenance ou industriels sur toute la chaîne de valeur service. En résumé du procédé selon l'invention, le concept général mis en oeuvre repose sur les idées suivantes : - La couverture d'observation/contrôlabilité au strict nécessaire et suffisant (pertinence) en termes d'architecture physique implémentée relativement à l'objectif à atteindre de performance à ressources données au moyen d'ateliers couplés. Le terme « atelier » est un mot utilisé dans différents domaines techniques et connu de l'Homme du métier. - Dès la phase de conception du système selon l'invention, le procédé prend en compte les états fonctionnels nominaux, les déviations, les anomalies ou les défaillances potentielles selon les analyses conduites au moyen des outils de la figure 5 et les retours d'expériences en terme d'incidents de fonctionnement et les intègre dans une mémoire de connaissance, dont le contenu sera diffusé à tous les utilisateurs du système présent ou à venir. Le procédé apprend et capitalise, dès les phases d'IVVQ et donc bien avant la mise en oeuvre en vraie grandeur, ce qui conduit à limiter l'intervention humaine pour les tâches éligibles à l'automatisation et sur tout le cycle de vie. A défaut, la situation du système à un instant donné sera signée afin de converger au plus vite vers un retour vers le bon fonctionnement opérationnel, qui correspond à un état nominal ou acceptable ou encore fonctionnel avec, à chaque fois, reconsidération de la possibilité d'automatiser ce retour à la normale ou à l'acceptable dans le cas d'un fait mineur. Cette signature permet lorsqu'il est nécessaire ou utile d'alimenter une approche prédictive (sensibilité aux signaux faibles notamment anomalies ou déviations dans l'optique « dégradation »). Dans tous les cas, l'enseignement retiré (« auto cicatrisation », signature associée à un évènement...) peut être instantanément ou quasi- instantanément diffusé à l'ensemble des sites d'infrastructure « fixes » ou « mobiles » de configurations équivalentes. L'ingénierie Système « Back Office », de fait, avec le retour d'expérience résultant de l'innovation dispose de tous les éléments d'information pour définir les évolutions en termes d'architecture et d'exploitation pour reconcevoir ou concevoir les systèmes : soit par une redéfinition profonde du schéma si la technologie a atteint ses limites, soit a contrario, par implantation de nouvelles fonctionnalités faisant ainsi évoluer progressivement, par paliers, mais à l'essentiel l'architecture implémentée à l'origine. La figure 3A schématise un logigramme comprenant les différentes étapes mises en oeuvre par le procédé selon l'invention. Initialement 1, le système est en fonctionnement normal. Lorsqu'un dysfonctionnement « physique » ou « logiciel » apparaît, il y a génération d'un vecteur d'état, 2, qui conduit au processus d'auto cicatrisation 3. Le système pour cela comporte un ou plusieurs capteurs Ci associés à un paramètre de fonctionnement d'un équipement ou d'un système. Les informations lues sur le ou les capteurs vont être transmises à un organe de contrôle central ayant notamment pour fonction de décider ou non le déclenchement d'une intervention à effectuer sur des sites en fonctionnement au-delà de toute action automatique du fait du dispositif d'auto-cicatrisation. L'organe de contrôle central comprenant au moins un organe d'observation recevant les différentes données en provenance des capteurs Ci associés à un équipement d'un système, ledit organe d'observation est en liaison avec une base de données SIL et avec un organe de contrôle local relié à une base d'apprentissage. L'organe de contrôle local transmet, par exemple, les données à un organe de génération de commandes, cet organe recevant lui-même des données validées par un utilisateur. Le procédé va vérifier 4 si l'auto cicatrisation est possible. Si oui, 5, alors il y a mise en oeuvre automatique d'actions qui vont permettre de corriger les défauts de fonctionnement, de réallouer la ressource et d'apprendre. Si l'auto cicatrisation n'est pas possible, 6, c'est-à-dire que le système n'apprend plus et qu'il n'est pas possible à ce stade de modifier l'architecture physique ou organisationnelle du système, alors le procédé génère un « statut » signalant au moyen d'une signature la situation (vecteur d'état), puis le procédé va générer un signal pour activer le procédé de correction du dysfonctionnement, par exemple, en mettant en oeuvre des actes d'opération, d'exploitation ou de maintenance selon l'art antérieur. Le procédé va ensuite vérifier s'il est possible d'enrichir l'auto cicatrisation 7, si oui, alors le procédé injecte dans le procédé d'auto cicatrisation 8, les informations qu'il a acquises, si non alors le procédé va vouloir mettre à jour l'architecture par exemple en réexaminant l'architecture et les possibilités de la modifier, 9. Cette figure 3A fait apparaître avantageusement un apprentissage hiérarchisé, démarrant dès la phase d'IWQ et entretenu tout au long du cycle de vie du système ou du réseau, un déclenchement automatique ou semi-automatique, hiérarchisé au même titre que l'apprentissage, d'actions correctives « intégrées » (auto cicatrisation) ou d'allocation de ressources strictement pertinentes (compétences et moyens, outillages) « à temps » du fait de l'élaboration de vecteurs d'état pouvant « signer » la situation et évoluant selon l'apprentissage incrémentai, une diffusion quasi immédiate des apprentissages/ modes correctifs à l'ensemble des équipements ou des systèmes relativement à un RETEX d'un site spécifique. L'ensemble étant sous-tendu par la mise en oeuvre initiale, idéalement dès la conception du réseau ou du système. La figure 3B représente une représentation temporelle des activités avant / après la mise en oeuvre de l'innovation est donnée à la figure 4 où le schéma en haut de figure représente les actions entreprises selon l'art antérieur et la partie basse de la figure représente les actions entreprises en mettant en oeuvre le procédé selon l'invention. II est à noter que ce phénomène de réduction des interventions humaines, du fait de l'invention, se produit dès la mise en service, du fait qu'un certains nombres d'incidents de fonctionnement auront peut-être été identifiées lors des analyses initiales et observés, qualifiés dès les phases d'IWQ et auront, en conséquence, donné lieu à des phases d'apprentissages préalables avec dispositifs actionnés corrélativement. Sur la partie basse de cette figure 4 est représenté un effet de « diffusion » des solutions correctives automatiques sur l'ensemble des sites, annihilant de ce fait un ensemble de déplacements inopportuns dans la suite de l'année d'exploitation/opération après le 1 er incident désigné incident x. La figure 5 représente un exemple de synoptique d'architecture pour le système selon l'invention. 11 - Dans un premier temps, il y a une recherche, a priori, de l'organisation optimale pour garantir le résultat escompté. Les outils/ateliers individuels ou regroupés utilisés lors de cette étape peuvent correspondre à ceux du type SIMLOG commercialisé par la société APSYS (liste non limitative). 12 - Dans un deuxième temps, il y a une recherche d'un optimum plus absolu en terme d'organisation du soutien que lors de l'étape précédente 11 au moyen d'analyses de sensibilités mettant en évidence un maximum de relations de cause à effet classées par ordre d'efficacité décroissante. Les outils permettant de mettre en oeuvre cette étape sont connus de l'art antérieur et ne seront donc pas détaillés. A cette étape, il y a définition, en accord avec le Client, de l'organisation de l'exploitation ou du soutien « bout en bout » à mettre en oeuvre pratiquement afin de garantir le résultat visé. 13 - Dans un troisième temps, l'utilisation d'outil d'émulation (« réalité virtuelle » sur base d'automates asynchrones), classiquement utilisé a posteriori, permet, lorsqu'il est utilisé en anticipation dès la phase initiale (soit a priori), de simuler des pannes, des anomalies, des dysfonctionnements et d'enrichir les visions qualitatives et quantitatives obtenues lors des phases 11 et 12 conduisant à un optimum relativement à l'architecture correspondante à la présente invention. II y a alors pré chargement de toutes les hypothèses et données associées dimensionnant dans tous les outils du Client et ceux des Industriels (Industriel «mandataire » plus toute la chaîne de partenaires et/ou des sous-traitants impliqués dans l'opération ou le soutien), essentiellement dans les outils de Gestion de Maintenance Assistée par Ordinateur, conformément à l'architecture. L'organisation complète passe alors, au temps initial To du contrat associé, à la mise en oeuvre opérationnelle. 14 - Dans un quatrième temps, il y a alimentation « au fil de l'eau » (par couplages, interfaçage, enregistrements, diffusion par mise en réseau...) d'outil de « rejeu » / émulation à partir des données opérationnelles dimensionnant observées. Cet outil va permettre de lancer des analyses a posteriori. 15 - Dans un cinquième temps, les analyses et caractérisations, statistiques notamment, effectuées sur l'ensemble des informations compilées sur les mises en vraie grandeur des équipements et des systèmes lors de la quatrième étape 14 peuvent être rapprochées des hypothèses organisationnelles des étapes 1 & 2 et, ainsi, conduire à des analyses d'explications d'écarts résultant du RETEX optimisant ainsi la pertinence des vecteurs d'état. Soit ces résultats sont conformes aux attendus, soit, il y a divergence. Dans ce dernier cas, le rapprochement des écarts et leurs justifications pourront donner lieu à une démarche d'identification de maximum de vraisemblance permettant de donner des explications formelles quant aux causes conduisant à ces écarts en termes d'organisation, de profil d'emploi ou de fiabilité des équipements ou systèmes mis en oeuvre. Des décisions impactant chacune de ses composantes pourront être prises, en accord avec tout ou partie des acteurs impliqués dans le soutien ou l'exploitation, afin de repartir dans une nouvelle phase du soutien toujours plus optimisé. Le processus pourra ainsi être reconduit de phase en phase successive durant tout le cycle de vie des équipements ou systèmes concernés. Plus généralement, l'invention permet de créer une architecture fonctionnelle globale tirant profit du passé plus ou moins proche afin de prévoir de façon toujours plus pertinente le futur, agissant comme une ligne à retard. Afin de pouvoir exploiter au mieux le procédé selon l'invention et son efficacité, il convient d'automatiser au maximum du possible la constitution des bases de données d'informations probantes qui serviront aux analyses décrites précédemment, tout au long du cycle de vie des équipements ou des systèmes étudiés. Ces informations pourront provenir : - de capteurs Ci encapsulés dans les équipements, les sous-systèmes et de façon hiérarchisée, incrémentale et cohérente constituant les vecteurs d'état ; - d'outils « terrains » tels que des PALM, PDA (Personal Digital Assistants), etc. qui auront pu être renseignés par les opérationnels, les exploitants, les personnes chargées de la maintenance, les ~o utilisateurs finaux ou les spécialistes industriels selon des formulaires stricts et codifiées contenant des informations associées (photographies, vidéos, etc.) ; - de toutes connaissances envisageables des composantes précédentes porteuses de sens pouvant contribuer à augmenter la 15 pertinence des informations remontées après nettoyage du « bruit » (erreurs humaines, traitements pour augmenter le rapport signal à bruit, filtrages...). Ainsi, toute la somme des informations utiles et partageables se trouve stockée afin de conduire l'ensemble des étapes du processus selon 20 l'invention. Toute fiche d'intervention technique FIT ou fiche d'exploitation FEX relative aux équipements ou systèmes concernés sera automatiquement émise. Du fait de cette automatisation de FIT ou FEX, certains champs 25 pouvant eux-mêmes être renseignés quasi-automatiquement pourront ainsi : - "robustifier" les routines et processus de l'invention, par la garantie de la fidélité et de la complétude du renseignement des bases de données ainsi obtenues, indispensables aux analyses conduites dans le cadre de l'invention, 30 - permettre l'allocation quasi-immédiate de la ressource technique et/ou humaine permettant de rétablir en mode de fonctionnement opérationnel les équipements ou le système en cas de survenue de panne grave, critique ou majeure. Notamment, la présence dans le système d'un module autorisant la localisation d'une ressource permettra de décréter si elle est optimale ou non afin de l'allouer en conséquence. Les allocations pourront se faire à partir de l'ingénierie système central (niveau national) ou encore régional (responsable régional) selon l'organisation de maintenance retenue avec le client. Enfin, après l'apprentissage cette tâche sera éligible à une automatisation complète à partir de l'automate de contrôle de l'hyperviseur central. Ce procédé de constitution de FIT/FEX, de renseignements de bases de données et d'allocations de ressources automatiques pourra s'inscrire dans la boucle complète d'analyse et profiter également de l'effet d'expérience et/ou d'apprentissage. La figure 6A schématise un exemple d'architecture fonctionnelle d'un réseau de télécommunications supervisé, à des fins de soutien ou d'exploitation appliquée au cas de site de terminaux dans le cas d'un site dit statique, c'est-à-dire dans lequel les équipements ne sont pas mobiles. Sur cette figure 6A, la référence 10 correspond aux outils nécessaires pour la mise en oeuvre de l'invention, outils également représentés sur la Fig. 5. Dans cet exemple, le système comporte plusieurs réseaux support 21 qui vont permettre aux différents éléments et équipements formant le système de communiquer entre eux, de s'échanger des informations ou des données. Il comporte un organe de contrôle central 22 (OCC) qui comprend les différents modules permettant l'exécution des étapes selon l'invention. Ainsi, il comprend les outils 10, une base de stockage 23 de données en provenance d'un organe d'observation 24 recevant des informations de la part des différentes régions ou sites reliés au réseau support, l'organe d'observation transmettant des Fiches d'Exploitation vers une base de données SIL/GMAO (système informatique logistique/maintenance assistée par ordinateur). Les observations sont transmises de l'organe d'observation 24 qui comprend par exemple des capteurs Ci vers un organe de contrôle local 25 qui va transmettre des informations à la base d'apprentissage 26, et simultanément remonter les informations vers un organe de génération de commandes 27 dont une des fonctions est de générer les commandes vers un module de validation 28 qui va recevoir les données validées par un client. La figure 6B représente deux exemples de mode opérationnel selon les exigences du client. Dans les deux cas, un compteur de temps 35 mesure le fonctionnement (mise sous tension, veille) des différents modules pour le calcul du Retour d'Expérience ou RETEX. Un module de communication 30 comprend une antenne RF 32, par exemple, qui va permettre la transmission des données entre les différents dispositifs, plateforme, client participant au système selon l'invention. Le module de communication comprend un microprocesseur 33, un module fournissant l'énergie 34, et une interface 31. Dans un premier cadre apparaît le processus d'auto-cicatrisation du fonctionnement d'un système selon l'invention tel qu'il a été mentionné en 20 relation avec la figure 6A. Il est possible d'utiliser le module de transmission 31 permettant aux différents éléments de s'échanger des informations ou des données. Dans le cas contraire, il est possible de s'échanger des informations au retour à un lieu précis (par exemple, base de maintenance), par l'interface 25 30, grâce à une console informatique 36. Une fois ces opérations finies, cette console 36 peut soit télétransmettre à l'OCC 38 au travers d'une valise de transmission au module 39 de l'OCC 38 ou se connecter directement au module 35' de l'OCC 38'. La figure 7 représente une vue de l'architecture du système 30 d'information SMI (Service, Maintenance et Intervention) mis en place à l'organe de contrôle central ou OCC . L'architecture comporte un module observation et de contrôlabilité 40, un module de télé-administration 41, un module GPS 42 ou tout dispositif de géo-localisation, les 3 modules étant reliés à une plateforme ou « HUB » de communication 43, lui-même relié à une mémoire de stockage 44. Cette architecture comprend un portail d'accès 45 en liaison avec des métiers, des partenaires, des clients 46. - Le HUB de communication 43 est en liaison avec : - un SIL/GMAO 48 qui comprend une GMAO 49, une base de stockage 50. - une base de connaissance 51, - un module 52 comprenant les outils précités. - un système d'information géographique 53, - un ERP 54. - un annuaire 55 de gestion des droits disposé entre le « hub » de 15 communication 43 et le portail d'accès 45. L'ERP et le SIL/GMAO sont couplés, par exemple au travers de la technologie Webservices permettant d'avoir accès aux informations requises dans chaque base de données. Le client utilisateur dialogue à travers une interface de service comprenant un contrat de service vers une base de 20 données dédiée au service métier. Le couplage SIL/GMAO à l'utilisateur en ligne est décrit à la figure 8. Le « Customer on line » et le SIL/GMAO sont couplés par exemple, au travers de la technologie Webservice. Le service consommateurs en ligne ou COL est simplement un portail d'accès à l'information de la base de 25 données de la gestion de maintenance assistée par ordinateur ou « GMAO » ainsi que les principales actions réalisées au travers du système : - La consultation des données gérées, - La formulation de demandes essentiellement par le client, - Le traitement automatique des demandes formulées afin d'en 30 déterminer les impacts sur les différents interlocuteurs, - La génération d'alerte ou de notifications des interlocuteurs avec une gestion des flux et de validation de type flux d'activités ou « workflow » - Le traitement ou la validation des demandes, - Le retour d'information vers l'émetteur de la demande, - La validation de certaines actions. Les clients 60 communiquent avec le « COL » 61 via un portail d'accès 62, qui permet d'accéder à une base de données 63, elle-même reliée à une vue 64 du parc des appareils dans le système à surveiller, à un module de sollicitation de l'industriel 65, un module de notification de l'information vers le client 66, un module pour la notification industriel et transfert de la demande 67. L'ensemble est synchronisé par un module de synchronisation 68 qui est en communication avec un Hub de communication 69 en liaison avec un Hub de communication 70 de la GMAO. Ce hub de communication 70 est en relation avec le module d'observation et de contrôlabilité 71 et au sein de la GMAO avec une base de données 72 un module de création FEX 73, un module de création FIT, 74, un module d'analyse 75, un module de notification 76 et un module de communication 77. Ces deux derniers modules sont en liaison avec un portail d'accès 78 qui communique avec la partie industriels, à savoir l'ingénierie système 80, le personnel d'exploitation 81. Le couplage ERP/GMAO met en oeuvre les fonctionnalités suivantes : - les informations récupérées de la base de données de la gestion de maintenance assistée par ordinateur - le planning des fiches d'intervention et la re-planification, - les fiches d'intervention et leurs contenus, - l'état des éléments de soutien et leur localisation, - l'état des stocks et leur localisation, - la localisation des ressources et leur état, - la gestion et la préemption de tâche, - la simulation d'impact au travers des outils selon l'invention. - les informations récupérées de la base de données de l'ERP - la liste des sociétés possibles, - la liste du personnel rattaché aux sociétés, - les paramètres du contrat de service, - la gestion des achats de pièces, - la gestion de la location, - la gestion de la facturation. A partir de ces informations, il est possible d'échanger des 10 données entre les deux applications. La figure 9 présente un exemple de couplage ERP 54 et de la GMAO. Les clients 60 communiquent avec le portail 62 pour récupérer l'état du contrat, les factures associées et des bons de commandes qu'ils doivent validés grâce au module 90. Dès qu'un client valide un bon de commande, le 15 module « gestion des contrats » 90 envoie l'information d'une commande d'achat au module 91A, 91B. Celui-ci définit la ou les fabrications d'éléments 94 dans le temps (par exemple, pièce, carte électronique, équipement, radio...) grâce à la nomenclature 92, le planning 95 et effectue une commande des approvisionnements au fournisseur 91B. Le tout est stocké 20 dans une base de données 93. Les industriels ont accès à la gestion de stock 98-1 et à la gestion de parc 98-2 et peuvent ainsi gérer la distribution 98-3. Le logigramme des opérations processus des anomalies, déviations ou incidents de la supervision est donné ci-après dans l'exemple 25 d'un client déclarant un incident technique. La figure 10 représente le processus de gestion des anomalies, déviations ou incidents de la supervision qui s'exécute entre l'industriel, le client et le procédé cyclique qui met en oeuvre le module d'observabilité. Lorsque le code erreur incident existe 100, l'incident est enregistré 30 101, le procédé vérifie ensuite si l'incident est codifié, 102, si oui, le procédé 103 va analyser les diagrammes ou « patterns », il enregistre ensuite l'action 104, et simultanément sauvegarde 105 les informations pour une mise à jour dans la base d'apprentissage ; après enregistrement de l'action, il demande la validation au client, si le client valide l'action à accomplir pour corriger l'incident, alors le procédé le notifie 106 au client qui va accepter 107 ou non 108. Dans le cas où le client accepte le procédé va procéder à l'action de correction 109, puis le notifier 110 au client. Toutes personnes (partie prenante au programme ayant un accès au système - par exemple, chargé d'affaire du contrat côté client) peuvent accéder à ces informations en fonction de leurs droits d'accès et d'usage. Elles peuvent visualiser 111 les actions effectuées, les traitements en cours, les demandes de validation, les FIT, les FEX, les comptes-rendus ou «CR » d'avancement, bilan, tableau de bord, suivi d'indicateurs. Dans le cas où il n'existerait pas de code erreur incident, alors 115, le procédé vérifie s'il y a un impact sur la maintenance planifiée. Si oui, 116, le procédé va entamer un processus de re-planification, si non, alors il ne fait rien et retourne vers le module d'observabilité. Dans le cas où l'incident ne serait pas codifié, après la notification 120 au procédé, l'industriel va traiter l'incident 121a, 121 b. Le traitement de l'incident 121 prend en compte des patterns du module d'observabilité. L'industriel reporte le résultat de ces analyses et le processus continu de manière automatique et identiquement à une opération codifiée. Si le client refuse l'action de correction de l'industriel. L'industriel reçoit la notification de ce refus et ses motivations (justification du refus, le motif, etc.) pour que l'industriel trouve une autre solution dans ce contexte à ces problèmes ou aux autres incidents. Le processus reboucle comme décrit dans le paragraphe précédent. La figure 11 présente le processus de l'action. Après codification de l'action 130, dans le cas où il y aurait déplacement du personnel 131, alors l'ERP va rechercher le personnel adéquat 132a, filtrer 132b puis cette information va être transmise vers le module GPS 133 qui va notifier à l'industriel le traitement de demande 134, dans le cas où la mission serait acceptée 135 par le personnel, alors 136, l'industriel traite le problème, puis 137 il va mettre à jour le parc et la configuration du système, puis il va y avoir 138 écriture du rapport d'intervention, avant une notification 139 au système selon l'invention et une visualisation 140 au niveau du client. Dans le cas où il n'y a pas de personnel disponible 132, le procédé va vérifier si la résolution est OK, 142, 143, 144 si oui, alors le procédé notifie la résolution de l'incident au client qui le visualise 140. S'il n'y a pas de résolution alors, le procédé va le notifier 145 à l'industriel qui va essayer de traiter le problème de manière différente 146. Dans tous les cas, il y a une remontée de l'information (façon dont le problème a été résolu ou non) vers le client. Le diagramme illustré à la figure 12 schématise les étapes d'écriture du rapport d'intervention. Le point de départ se situe au niveau de l'industriel, qui va saisir 150 l'intervention, puis 151 saisir le type d'intervention, puis rechercher 152 dans le cas d'une intervention « matérielle » les pièces de rechange, il va pour cela consulter 153, les stocks qui sont disponibles, valider 154 les pièces de rechange, finir la saisie 155, avant de notifier 156 au procédé qui va mettre à jour les stocks 157. Le procédé va ensuite visualiser si le stock est suffisant 158. Si oui, alors le procédé va le notifier 159 au client qui peut le visualiser 160. Si non, alors l'ERP du système selon l'invention va vérifier 161 si la quantité est suffisante. Si oui, alors 162, il y a gestion de la distribution, si non 163, alors le procédé va attribuer un ordre de fabrication et/ou achats+planification, avant l'étape de gestion de la distribution. Dans le cadre d'une intervention logicielle, le même procédé peut être mis en oeuvre pour gérer des processus de contournement en cas d'urgence au moyen de patch ou de moyens connus sous l'abréviation anglo-saxonne ghost. Il est possible de télé-administrer des équipements à logiciels prépondérant en ajoutant des serveurs de dépôt et des applications logiciels connus de l'Homme du métier de type VNC ou KVM commutateur IP au réseau de support. En effet, le réseau de support est modulable pour répondre à différentes problématiques. Grâce à des moyens intégrés à ce réseau, il est possible d'appliquer soit des correctifs (patchs) ou de réinstaller une nouvelle version du logiciel (connus sous les abréviations anglo-saxonnes firmware, ghost, master, dépôt avec méta-packetage..) au moyen d'un dispositif relatif à l'invention, au même titre que les actions menées au niveau des composantes matérielles. Processus de qestion des incidents « client » La figure 13 schématise le processus en cas d'un client déclarant un incident technique. Dans le cas où un client déclarerait un incident technique, alors le procédé exécute les étapes suivantes. Le client va solliciter 170 l'industriel. Le procédé va enregistrer 171 l'incident. Le procédé va vérifier 172 si l'incident est codifié. Si non, alors il notifie 173 le traitement de l'incident 187 à l'industriel. Si l'incident est codifié, alors le procédé 175 analyse les patterns, et en parallèle il mémorise 176 ces informations pour mise à jour dans la base d'apprentissage. Le procédé 177 enregistre l'action puis demande la validation au client 178. S'il n'y a pas de validation du client, alors le procédé notifie 179 l'incident à l'industriel, qui traite 180 le motif du refus ou problèmes et cherche une solution comme décrit précédemment. Y-a-t-il acceptation 181 ? Si oui, alors le procédé va engager l'action 182 et le notifier 183 à l'industriel avant une visualisation du résultat 184, au niveau du client et de l'industriel. S'il n'y a pas acceptation, alors il y a notification 185 à l'industriel puis le traitement 186 du motif et le traitement de l'incident 187 au niveau de l'industriel. Processus de saisie des FIT « client » quand il réalise sa maintenance La figure 14 présente le processus de saisie des FIT client lorsqu'il réalise la maintenance. Le point de départ se situe au niveau d'un client qui va 200 saisir l'intervention. Ensuite, le client saisit le type d'intervention 201 puis recherche 202 les pièces de rechanges. Pour cela le procédé va consulter les stocks 203 avant de valider 204 les pièces de rechange, puis finir la saisie 205 avant de notifier 206 au procédé la mise à jour des stocks 207. Si le stock est suffisant, alors le procédé va le notifier à l'industriel 208. si le stock est insuffisant, alors, le procédé va regarder si la quantité est suffisante 209. Si oui, alors il va y avoir gestion de la distribution des stocks 210 par I'ERP. Si non, alors il va y avoir 211 émission d'un ordre de fabrication et/ou d'achats +planification au niveau de I'ERP. Le résultat des différentes actions est visualisée à tout moment par l'industriel 212. Processus de gestion de stock Le processus comporte, par exemple, quatre services (figure 15): - la consultation des stocks, 300 - la réallocation si nécessaire, - la gestion d'un équipement en panne, l'entrée de pièces ou d'équipement en stock, le suivi des stocks 301 est effectué soit par le client, soit par l'industriel. Les informations de suivi sont remontées au niveau de la consultation de parc du procédé selon l'invention. La figure 16 représente les différentes étapes mises en oeuvre pour la réallocation des stocks lors du procédé mis en oeuvre selon l'invention. Cette figure représente le processus de gestion de stock et la réallocation des stocks. Au niveau du client, un module de suivi de stock 400, est en liaison avec le processus module de consultation du parc 401 du procédé selon l'invention et le parc 402 à mettre à jour chez le client. Ce module 402 est relié à un module de mise à jour 403 du procédé selon l'invention, qui émet un signal vers un module de notification 404 qui transmet l'information vers un module 405 d'information sur la mise à jour du parc chez l'industriel qui transmet l'information à un module de validation et/ou le traitement 406 , qui transmet à un module de mise à jour du parc 407 du processus selon l'invention. Le procédé transmet ensuite l'information 408 sur la mise à jour du parc au niveau du client. Le client valide et/ou traite cette information 409 et l'envoie à un module d'accord 410, s'il n'y a pas d'accord de la part du procédé, alors le procédé retourne à l'étape 403. S'il y a accord par le procédé, alors l'information est diffusée à tous 411, 412 (mise à jour du parc). Les étapes mises en oeuvre au niveau d'un industriel sont illustrées sur la partie droite de la figure et sont identiques à celles explicitées pour le client. La figure 17 représente le processus de gestion de stock et la gestion d'un équipement en panne. Sur cette figure 17, le procédé selon l'information reçoit les caractéristiques de la panne de l'équipement, 500, puis transmet cette information au module de mise à jour du parc 501. Ce dernier notifie 502 au client la mise à jour du parc des pièces de rechange, puis à l'industriel la mise à jour 503 du parc des pièces de rechanges. Le module de mise à jour du parc, va distribuer 504 cette information à tous. La figure 18 schématise le processus de gestion de stock et l'arrivée de pièces ou équipements. Un nouvel équipement est proposé. Le procédé va saisir ses caractéristiques 701, puis transmettre ces informations au module de mise à jour des stocks 702, puis envoie une notification pour le paiement fournisseur 703. Le module de mise à jour des stocks va notifier cette information au procédé 704, qui transmet l'information au niveau du client et de l'industriel 705, 706 . En parallèle, le module de distribution 707 représentant un processus de distribution interne à toute industrie permet de livrer ou de distribuer du matériels, des logiciels, des consommables, des moyens, etc., à une adresse donnée. Processus de gestion de parc et sa localisation Ce service permet la mise à jour d'informations de localisation, des caractéristiques et de configuration appliquée du parc. La mise à jour s'effectue grâce au domaine de gestion de la maintenance, par exemple, lors d'un remplacement d'un matériel (pose/dépose). La gestion de la configuration applicable est possible par la mise à jour, de l'industriel, des révisions de la configuration, du client. L'activité parc à mettre à jour comprend un paramètre de localisation de la 30 mise en place d'un équipement/de la configuration, etc. Processus de gestion des mises à iour ou « updates » de son parc/équipements (rénovation) La gestion des équipements dans « SMI » facilite le suivi par le client ainsi que la visibilité par l'industriel du parc d'équipements installé chez le client. Le partage des informations concernant la rénovation et le parc est réalisé en « temps réel » sur le portail des données connues par l'industriel, ainsi que par des fonctions de mises à jour encadrées et par un processus collaboratif ou non. A cette fonction s'ajoute aussi les fonctionnalités du service ou processus de ~o la gestion de parc standard. Processus de suivi de l'avancement des maintenances planifiées (préventives ou prédictive). Le client consulte le planning et l'état d'avancement des maintenances planifiées ainsi que celles des industriels. Scenario de combinaisons des informations du Customer on-line et de 15 l'OCC. Saisie d'un incident Chaque chaine d'observation est codifiée (1 code unique par site) et chaque site est affecté à 1 région et une région à un pays. Chaque site a sa propre appartenance, un site appartenant à un 20 client. Ainsi un site a ses propres attributs : site (Identité, Référence Site, Référence Client, Désignation du site) Une région a aussi ses attributs (Identité, Désignation de la Région) ; un client possède par exemple les attributs suivants : Identité client, Désignation client. Dans le cas du COL, il y a le même principe avec une réf. Site 25 identique à celle de la gestion de maintenance par ordinateur GMAO (En réalité, la GMAO prend les références de site du portail Customer on-line et les transfère aux différents modules). Ainsi, il est possible grâce à cette construction technique, de retrouver le ou les patterns des sites en questions et de corréler l'information venant du 30 COL et de la chaîne d'observation. Enfin, il y a une ou des listes déroulantes, au niveau de l'affichage d'un écran de saisie, par exemple, contenant les codes d'erreurs pour un dysfonctionnement clair, ou expliquant un problème opérationnel. Si le client n'a pas trouvé le code erreur se rapprochant de son problème/dysfonctionnement dans cette liste, il a la possibilité de saisir manuellement son problème pour qu'il soit traité par l'équipe IS (Ingénierie Système). En se connectant au système, au moyen d'un login et d'un mot de passe, il est possible de connaître la référence client. A partir de là, il est possible de faire un filtre en utilisant une requête pour avoir des sites qui y sont rattachés. Comme il est nécessaire, sur certains sites que le client donne son accord pour l'auto-cicatrisation, il est possible au travers de Customer on-line de valider des solutions aux problèmes en fonction des numéros uniques pour chaque FIT. Une FIT contient la référence d'un site et donc du client (cf. figure ci-après). La figure 19 représente une vue macroscopique du processus et des moyens mis en oeuvre par l'invention. En cas d'un dysfonctionnement constaté sur un équipement ou système d'un site par le module d'observabilité ou contrôlabilité 900, celui-ci remonte l'information pour la traiter. Ainsi, il est créé une FIT 902 puis il est vérifié qu'il est possible d'auto-cicatriser 903. Si oui, l'accès est lancé 904 et une demande client de validation est demandé ou non 905. Si tout est conforme aux spécifications , on applique l'action au module 901 de contrôlabilité. Dans le cas contraire, du personnel industriel résout le problème 906. Si le personnel industriel trouve une solution ; celle-ci est appliquée et est lancé en 906. Ce cheminement continue comme décrit précédemment. Cas de la validation d'une action de résolution d'incident A chaque FIT créée qui demande une validation du client, un mail est envoyé automatiquement à la ou aux personnes concernées pour valider la résolution de l'incident. Pour valider ou refuser une action, le client doit se connecter sur le Customer on-line pour donner son acceptation ou non à l'action pour certains sites. Remarque : dès qu'une FIT est crée, un mail est envoyé_pour l'informer de cet événement FIT, même, si cela ne requière pas son approbation. II reçoit 5 un message différent. La diffusion peut : - soit être programmée à une date ou à instant donné (c'est le système qui le gère) - par exemple, toutes les 60s ou toutes les 30 FIT ; - soit par action manuelle, par exemple, la mise à jour des bases 10 d'apprentissage à cause d'une mise à jour critique et urgente. Le système transfert les bases d'apprentissages à tous les sites après la confirmation de l'équipe d'ingénierie système comme il est montré sur la figure ci-après. On transfère une base d'apprentissage type 1 à tous les sites de 15 type 1, la base d'apprentissage de type 2 à tous les sites de type 2 etc. par exemple. Les fonctionnalités de la partie ERP L'ERP selon l'invention sera personnalisé et est conçu comme un système hiérarchisé et pyramidal permettant d'aborder les aspects suivants : 20 - Centre de gestion (chargé du suivi général et de la facturation), des agences (ou centres techniques) qui suivent des dossiers clients spécifiques, des techniciens salariés des agences qui interviennent. - Traitement des donneurs d'ordres et des sous-traitants. - Gestion de techniciens avec gestion des congés, emailings, 25 statistiques. - Gestion des contrats de maintenance avec contrats types, périodicités modifiables, et suivi intégral de la vie des contrats. Possibilité de reports, entre contrats, des surconsommés ou non-consommés. - Gestion des prix de revient salariaux des techniciens, y compris lors 30 des déplacements. - Affichage en temps réel des prix de revient salariaux et des déplacements des contrats de maintenance. - Envoi des copies de contrats en pièces jointes aux clients. - Gestion de la sous-traitance, soit avec des donneurs d'ordres et de leurs propres techniciens, soit avec des sous-traitants et leurs techniciens. Edition des bons de travail pour les sous-traitants avec rapports de travail indépendant des interventions. Gestion des spécialités par sous-traitant et statistiques associées. - Relevés de parc entièrement modulaire pour permettre un suivi précis des parcs matériels et logiciels des clients - Gestion d'articles pour pouvoir établir des rapports d'intervention chiffrés, avec familles produits et statistiques, prise en compte des TVA et taxes parafiscales individuelles ou globales. - Suivi de dossiers (techniques, commerciaux, ou autres) permettant une traçabilité sur des études, des projets, ou des propositions. - Affichage en temps réel des prix de revient des temps passés sur les contrats, les déplacements et les prix de revient des techniciens sous- traitants étant inclus. - Gestion des achats : de pièces détachées ou de services (sous- traitance, forfait ou régie), cycle devis / demande d'achat / commande / réception & retour fournisseur, facturation, etc. - Gestion des coûts et budget : de main d'ceuvre, de stocks, d'achat, de location de matériel, etc., préparation des budgets, suivi périodique, rapports d'écart, etc. - Gestion des achats et des contrats associés, - Gestion du personnel, - Gestion des approvisionnements et des commandes, - Gestion des coûts, - Gestion de la fabrication et des nomenclatures des pièces. 30 Les fonctionnalités de la partie GMAO La Gestion de Maintenance Assistée par Ordinateur (ou GMAO) est une méthode de gestion assistée d'un logiciel destiné aux services de maintenance d'une entreprise afin de l'aider dans ses missions. Une GMAO vise en premier lieu à assister les services maintenance des entreprises dans leurs missions. Rappelons qu'un service maintenance, selon la définition de l'AFNOR, cherche à maintenir ou rétablir un bien (équipement) dans un état spécifié afin que celui-ci soit en mesure d'assurer un service déterminé. Une GMAO peut également être un outil intéressant dans d'autres services de l'entreprise, comme la production ou l'exploitation (afin de fournir des informations sur l'état des équipements), en fournissant ou non, des indicateurs facilitant les prises de décisions en matière de renouvellement de parc, par exemple. II permet d'aborder les fonctionnalités suivantes : - En standard : o Gestion des équipements : inventaire des équipements, localisation, gestion d'information dédiée par type d'équipement (production, bâtiments, véhicules, réseaux, ordinateurs, etc.) o Gestion de la maintenance : corrective (avec OT : ordre de travaux, ou BT : bon de travaux, ou ODM : ordre de maintenance), préventive (systématique, conditionnelle, prévisionnelle), etc. Ce module inclut souvent des fonctionnalités ouvertes à des utilisateurs au-delà du service maintenance, comme une gestion des Demandes d'Intervention (Dl), permettant à toute personne autorisée de l'entreprise de signaler une anomalie devant être prise en compte par la maintenance. o Gestion des stocks : magasins, quantités minimum, maximum, de réapprovisionnement, analyse ABC, pick-lists, référencement et recherche, articles de rechange, catalogue fournisseurs, etc. 25 30 o Gestion du personnel et planning : activités, métiers, planning de charge, prévisionnel, pointage des heures, etc. o KPI (Key Performance Indicators) : cockpit de pilotage ou tableau de bord pour le manager (requêtes de base de données concernant des statistiques, des alertes, etc.) - En plus : - Pré-affectation de techniciens sur des interventions. - Gestion des interventions, avec possibilité de liaison avec des contrats et/ou des relevés de parc, suivi détaillé des temps d'intervention, etc., plus statistiques. - Classement des interventions par catégories. - Envoi direct des rapports d'intervention en pièces jointes PDF aux clients. - Saisie des temps estimés pour les interventions. - Gestion des constructeurs et éditeurs, avec fiches contacts et liens web - Gestion des retours de produits auprès des fabricants, éditeurs, ou distributeurs. - Gestion des prêts et des locations, avec prise en compte de barèmes multiples, des pénalités, et de consommables rattachés, avec prise en compte des coûts de réparation ou de remise en état. - Gestion des tâches « techniciens », agences, sous-traitants, ou administrateur. - Possibilité de téléchargement de fichiers - Prise en compte des puces RFID et/ou des codes barres. Sans sortir du cadre de l'invention, le procédé peut être utilisé au sein d'un réseau de télécommunications avec des équipements statiques, mais également par exemple dans le cas d'un réseau d'équipements ou sites mobiles. La partie « mobile » se base sur le même principe que la partie statique avec les mêmes objectifs et la même démarche sauf qu'il n'est pas toujours possible de transmettre des ordres de commandes à distance. Par contre, la validation des ordres de pilotage/commande peut être effectuée, si nécessaire, par l'équipe de bord. En effet, le système d'observabilité/contrôlabilité est implanté sur une plateforme (véhicule, avion, navire, sous-marin, hélicoptère...) soit dans une carte électronique, soit dans un calculateur embarqué ou dans un PC. Ce système permet d'effectuer des auto-cicatrisations à partir de sa propre base d'apprentissage. Le système est constitué des ressources « d'auto-immunisation » nécessaires aux commutations d'équipements, aux commutations d'interfaces, et aux modifications de configuration permettant d'activer des moyens de résiliences utiles au rétablissement du service. Ces ressources sont soit intégrées lors de la conception initiale soit des équipements dédiés à la fonction de maintenance. L'intelligence embarquée dans ces ressources permet de prendre automatiquement et instantanément des décisions par rapport à des vecteurs d'état de défaut préenregistrés à la conception et surtout par rapport à des vecteurs d'état de défaut rencontrés durant la vie du système et ayant étés résolus. Ces mécanismes permettent une auto-cicatrisation par l'enrichissement automatisé, la décentralisation et la diffusion de la mémoire événementiel dans ces ressources « d'auto-immunisation ». Ce processus crée une boucle courte de contre-réaction. Cette boucle courte est de part ce principe en optimisation permanente par l'auto apprentissage local, la diffusion d'événements et des mécanismes associés de retour en mode opérationnel de constituant similaire du système. La base d'apprentissage de ces ressources « d'auto-immunisation » est ainsi constituée d'informations provenant du monde aval « terrain » et du monde amont ou back-office (monde de l'expert base arrière). Exemple de mécanisme : Cas de machines tournantes : Radar , Générateur... Les systèmes sont équipés de double moteur de commande instrumentée de capteurs. Les capteurs transmettent en permanence les signatures vibratoires à un processeur d'analyse/commande local. - Soit les signatures captées dérivent vers des signatures types révélatrices de dysfonctionnements connus ce qui induit un vecteur d'état et une action de remise en état local si nécessaire (basculement de moteur) ainsi que la diffusion d'un compte-rendu CR vers la supervision centrale. - Soit la dérive des signatures n'est pas connu et ne provoque que l'émission du CR vers la supervision centrale. Si l'analyse en base arrière donne lieu à une action elle sera automatiquement qualifiée, transmise, et prise en compte dans les processeurs d'analyse/commande locale de chaque élément système similaire. Cette nouvelle signature crée une nouvelle boucle de contre réaction courte. - Soit la dérive des signatures n'est pas connue et ne provoque que l'émission du CR vers la supervision centrale. Dans le temps la dégradation converge vers une dégradation connue provoquant la contre-réaction associée à ce dernier vecteur. Cette suite d'événement crée un nouveau vecteur d'état et une nouvelle boucle de contre réaction permettant une auto-cicatrisation proactive (réparation avant apparition de la panne). Ce mécanisme est applicable à tout système des lors que 30 l'instrumentation est apte à capter les événements révélateurs de l'état de santé du système. Il se peut que le pattern ne soit pas connu dans sa base (un statut « Unknown » est remonté par le système). Deux possibilités existent alors : - Le personnel à bord de la plateforme effectue des manoeuvres (toutes les actions sont stockées dans une base de capitalisation - base de stockage) - Stockage des données sans actions car personne ne connaît le pattern qui reporte un statut "unknown". Dans tous les cas, les données (actions, pattern, commande d'auto-cicatrisation...) sont stockées dans la base de capitalisation (base de stockage dans la figure 8 (72)). A la fin de la mission ou de retour sur la base arrière (soit sa base d'exploitation) on peut récupérer les données capitalisées et recharger une nouvelle base de données d'apprentissage. Cette nouvelle base a été créée chez l'industriel en utilisant les bases de capitalisation de toutes les plateformes de même type. II est possible au sol de télé transférer/télé transmettre les données acquises en base arrière directement à l'organe de contrôle central ou OCC de manière sécurisée en utilisant les réseaux publics (satellite, ADSL, XDSL, GSM, EDGE abréviations connues de l'Homme du métier). A partir des données stockées à l'OCC de toutes les plateformes, il est possible, grâce aux outils, de réapprendre les patterns avec la codification mise en place (c.à.d. créer une nouvelle base d'apprentissage) pour pouvoir la réimporter dans le système d'observabilité/contrôlabilité. De plus, à partir de ces patterns, il est possible de remplir automatiquement la base de données du SIL (Système d'information Logistique)/GMAO (Gestion de la Maintenance Assistée par Ordinateur)) par la création de FIT et de FEX précités. Le client pourra accéder aux données stockées à partir de l'OCC. Les principes exposés précédemment concernent aussi bien des faits techniques que logiciels, ces derniers pouvant être résolus par patch ou 30 ghost tels que décrits précédemment. Exemple détaillé et description de vecteurs d'états possibles En fonction des analyses réalisées sur un bloc fonctionnel d'un site en terme de taux de panne et en fonction du type de paramètres à surveiller associé, ces paramètres ayant généralement été identifiés lors de la mise en oeuvre des ateliers (mettre le renvoi ad hoc dans le document) et/ou qualifiés/caractérisés lors des phases d'IWQ, conformément au procédé de l'invention, il est possible de créer des vecteurs d'état tel que présenté ci-après. Ce qui conduit à l'organe d'observation (OBS) générant les vecteurs d'état. Fonctions Equipements clés Type de capteurs Sonde température / humidité, Sonde de champ électrique BITs en SNMP BITs en SNMP ou ping, Sonde température / humidité BITs en SNMP ou ping, Sonde température / humidité Sonde humidité, MIBS des trames SNMP ou ping réguliers MIBS des trames SNMP ou ping réguliers MIBS des trames SNMP ou ping réguliers Pylône Contact sec, Luxmètre, Capteur sismique, thermo couple Shelter Contact sec Détection d'intrusion, Camera avec détection IF Energie Groupe Electrogène Sonde température / humidité, Sonde ultra son, Contact sec, compteur Onduleur Sonde tension / courant Radio Baie Radio Commutateur Commutation Routeur Multiplexeur Infrastructure FH Fibre Optique Liaison Louée Tableau distribution Transformateur Supervision Automate (SW) Serveur PC exploitationdeSonde température / humidité, Sonde tension / courant Sonde tension / courant MIBS des trames SNMP MIBS des trames SNMP MIBS des trames SNMP Climatisation Climatiseur AIR/AIR Sonde température / humidité Climatiseur AIR/EAU Sonde température / humidité Ventilateur Sonde O2/CO2/Azote Extracteur Sonde ultrason Répartition des capteurs par type d'équipement pour une région Ces vecteurs d'état, constitués au niveau de chaque site élémentaire (statique ou dynamique), vont permettre la mise en oeuvre de l'apprentissage à des fins d'auto cicatrisation automatique ou d'allocation à temps selon la criticité de ressources ad hoc comme il a été décrit précédemment. Exploitation automatique des vecteurs d'état Une fois constitué un vecteur d'état au moyen de l'organe OBS, tel que décrit précédemment, il convient de bâtir, les éléments : - de contrôle local (OCL) incluant le mode apprentissage, - de génération de commande (CRTL), - d'interface (INT) entre l'OCC et l'OCL, tels que décrits précédemment. Généralement, l'ensemble de ces fonctions est accueilli au sein d'un automate, d'une carte électronique ou d'un ordinateur industriel situé sur le site lui-même et dépend de la complexité de la structure fonctionnelle fine du site en question. Cette architecture est : - élaborée à l'issue de l'étude initiale du réseau (ou, dans le cas d'un réseau existant, à l'issue des études menant à l'architecture 20 d'exploitation et du soutien), - mise en oeuvre dès la phase d'IVVQ pour valider le chemin de données, de commande et alimenter ainsi, corrélativement, la base de l'apprentissage. A noter que dans le cas d'un réseau existant, le processus est 5 conduit à l'identique mais profite d'un retour d'expérience opérationnel qui servira à la constitution de la base d'apprentissage. L'architecture en question met en oeuvre de façon générale des algorithmes de classification (réseau de neurones, fonctions radiales de base, fonctions d'apprentissage). Par exemple, il est possible d'utiliser 10 l'algorithme « RCE » commercialisé par la société NESTOR inc basé sur des fonctions radiales de base et contenu dans le produit ILB 25 commercialisé par la société ROVI-TECH, qui utilise des vecteurs d'état élémentaires codés sur 255 octets. Cette dimension est donnée à titre indicatif pour illustrer le principe mis en oeuvre. 15 Pour cet exemple d'architecture, deux possibilités sont envisageables : - soit, la complexité de la problématique ne nécessite pas des vecteurs d'état de plus de 255 octets et des classes fonctionnelles pour tout site n'excédant pas 255 états, cela étant vrai pour l'ensemble des 20 sites du réseau ; - soit, la complexité de la problématique conduit à des vecteurs d'état excédant 255 octets. Il convient alors de paralléliser et hiérarchiser aussi bien les chemins de 255 octets pour les vecteurs d'état que les 255 états pour les mots de commande associés. 25 Ainsi, dans le cadre de la mise en oeuvre de l'ILB-25 précité, le dimensionnement de la mémoire neuronale apte à apprendre l'ensemble des états qui conviendra d'observer et de contrôler par site et dans le temps, pourra conduire, soit : 30 à une architecture élémentaire consistant à mettre : une mémoire identique, par site, apprenant des vecteurs d'état de 255 octets, intégrant implicitement les éventuelles disparités (bruit) de chaque site et générant 255 états vers le CTRL et/ou l'OCC ; une mémoire, également de 255 octets en entrée, gérant 5 l'ensemble des sites au niveau de l'OCC ; à une architecture élémentaire bâtie : sur N mémoires élémentaires par site, telles que décrites ci-dessus et mises en parallèles et hiérarchisées de type « Divide and Conquer » afin de conduire à un statut par site de 255 états ; 10 sur N mémoires élémentaires, telles qu'également décrites ci-dessus et mises en parallèles et hiérarchisées de type « Divide and Conquer» afin de conduire à un statut au niveau de l'OCC de 255 états ou plus. Généralisation 15 Dans le cas d'un grand nombre de mesures à faire, il est possible d'agréger des codes ensembles et aussi d'utiliser moins de capteurs pouvant former plusieurs vecteurs d'état de 255 bits. Solution de vecteur d'état dans une architecture globale. Pour illustrer un vecteur d'état, le tableau ci-après présente le 20 vecteur d'état considéré, en entrée, dans le cas de l'amplificateur d'un sous-système radio. Température Humidité Sonde CEM BITE Code erreur site 12 bits 8 bits 32 bits 128 bits 4 octets Tableau 1: Exemple de vecteur d'état d'entrée pour un 25 amplificateur du sous-système radio En fonction de ce vecteur d'état, il générera les codes suivants : 0001 car tout est ok ; 0002 quand la température est trop importante ; 0003 quand les conditions environnementales sont hors spécification et critique ; 0004 quand l'humidité est trop importante ; 0005 quand l'un des amplificateurs est en panne ; 0006 quand l'un des amplificateurs est presque en fin de vie ; 0007 quand la dégradation des performances est acceptable ; 0008 quand la dégradation des performances est inacceptable ; 0009 quand la dégradation constatée provient d'un autre élément de la chaîne et que l'état de l'équipement est ok. ~o Note : A ce code, une entête composée de x digits et/ou x lettres seront rajoutées afin de référencer le site concerné, par exemple : 0001 pour le site référencé 1 et ainsi de suite. REVENDICATIONS1 - Procédé pour gérer des services d'exploitation, d'opération et/ou de support à un système ou à un équipement en vue de leur retour en mode opérationnel suite à une déviation, une anomalie ou un incident de fonctionnement caractérisé en ce qu'il comporte au moins les étapes suivantes : Une étape de définition préalable de paramètres à surveiller dans ledit système ou ledit équipement, l'ensemble des paramètres définis comportant une signature ou un vecteur d'état associé, permettant de piloter un dispositif d'auto cicatrisation ou, à défaut, de transmettre automatiquement cette signature afin de déclencher une intervention ad hoc (télé-opération, envoi d'une ressource dûment qualifiée) selon la criticité dudit incident, Une première étape de recherche, a priori, de l'organisation optimale (traduite par une architecture physique, logicielle) pour les services nécessaires au fonctionnement correct dudit système ou dudit équipement, Une deuxième étape, de recherche d'un optimum en terme d'organisation matérielle, logistique, du soutien au moyen d'identifications de singularités ou de « pivots » et d'analyses de sensibilités associées mettant en évidence un maximum de relations de cause à effet ou de « vraisemblances » classées par ordre d'efficacité décroissante à ce stade, il y a une recherche des singularités du système, Une troisième étape d'utilisation d'un outil d'émulation classiquement utilisé a posteriori, utilisé en anticipation dès la phase initiale, permettant de simuler des incidents, des pannes, des anomalies, des dysfonctionnements et d'enrichir les visions qualitatives et quantitatives obtenues lors de la première et de la deuxième étape conduisant à un optimum relativement à l'architecture et de créer, en conséquence, les maquettes virtuelles ou physiques nécessaires et suffisantes, à la lumière des analyses précédentes, dès les phases de validation du système, devalidation ou de qualification dudit système ou dudit équipement, afin d'entraîner des mémoires présentes dans lesdits dispositifs d'auto cicatrisation qui pourront être émulées, et généralisées en déploiement des dispositifs sur l'ensemble de l'architecture physique livrée à l'utilisateur, puis un pré chargement de toutes les hypothèses et données associées dimensionnant dans tous les outils du Client et ceux des Industriels, essentiellement dans les outils de Gestion de Maintenance Assistée par Ordinateur, conformément à l'architecture du système ou de l'équipement, Une étape de déploiement sur l'ensemble de l'architecture livrée à l'utilisateur, Une quatrième étape de remontée des données opérationnelles où ledit procédé alimente « au fil de l'eau » l'outil de « rejeu » / émulation à partir des données opérationnelles dimensionnante observées, Une cinquième étape d'analyses et de caractérisations, statistiques, effectuées sur l'ensemble des informations compilées sur les mises en vraie grandeur des équipements et des systèmes lors de la quatrième étape, l'ensemble desdites étapes permettant de créer une boucle de contre réaction qui décroit temporellement du fait dudit système global d'optimisation permanente d'auto apprentissage local, de diffusion d'incidents ou d'évènements et de mécanismes associés de retour en mode opérationnel, Le procédé vérifie (4) si l'auto-cicatrisation est possible, Si oui (5), le procédé met en oeuvre de manière automatique des actions qui vont permettre de corriger les défauts de fonctionnement, et de réallouer la ressource Si l'auto cicatrisation n'est pas possible, (6), alors le procédé génère un « statut » signalant au moyen d'une signature la situation ou vecteur d'état, puis ledit procédé va générer un signal pour activer le procédé de correction du dysfonctionnement, Une sixième étape de transmission des informations à intégrer dans une base d'apprentissage et de diffusion quasi-instantanée de lasolution à divergence constatée et résolue à l'ensemble des sites de configurations identiques. 2 - Système permettant de gérer les déviations, anomalies ou dysfonctionnements dans un système ou un équipement caractérisé en ce qu'il comporte au moins les éléments adaptés pour exécuter les étapes du procédé selon la revendication 1 : Plusieurs réseaux support (21) adaptés pour que les différents éléments et équipements formant le système communiquent entre eux, et des échanges d'informations ou de données, et un module de communication (30), Un ou plusieurs capteurs Ci associés à un paramètre de fonctionnement dudit équipement ou dudit système, les informations lues sur lesdits capteurs étant transmises à un organe de contrôle central OCC, Un dispositif d'auto-cicatrisation, Ledit organe de contrôle central OCC (22) ayant notamment pour fonction de décider ou non d'une intervention technique à effectuer sur les sites en fonctionnement, au-delà de toute action automatique du fait du dispositif d'auto cicatrisation, Ledit organe de contrôle central OCC (22) comprenant au moins un organe d'observation recevant les différentes données en provenance des capteurs Ci positionnés sur chaque équipement d'un système dont les dysfonctionnements sont à gérer, ledit organe d'observation (23) étant en liaison avec une base de données SIL, et avec un organe d'observations (24) relié à une base d'apprentissage (25), ledit organe de contrôle local (24) recevant des informations de la part des sites reliés au réseau support et transmettant les données à un organe de génération de commandes (26), ledit organe de génération de commande (26) recevant aussi les données validées et mémorisées dans un module de génération de commandes (27) générant des commandes vers un module (28) de validation. 3 - Système selon la revendication caractérisé en ce qu'un module de communication (30) comprend une antenne RF (32) adaptée à la transmission des données entre les différents dispositifs, plateforme, client participant au système selon l'invention, ledit module de communication comprend un microprocesseur (33), un module fournissant l'énergie (34), et une interface (31).