Schneider Electric augmente la cohérence de sa démarche de conception avec les logiciels d’analyse fonctionnelle et AMDEC

Required Activities of Design to Achieve Robustness: RADAR

« J’ai participé hier au club utilisateur de TDC Software Knowllence, éditeur français spécialisé dans les outils de suivi des méthodologies de conception de nouveaux produits/process, et de maîtrise des risques. Ces logiciels facilitent notamment la traçabilité, la capitalisation et la cohérence méthodologique.
Parmi les différentes présentations, j’ai retenu celle faite par Philippe Raffoux et Philippe Bergin, qui travaillent à la Direction Innovation – R&D Efficiency & Quality de Schneider Electric . Elle a montré comment le géant de l’électricité et de l’automatisme met actuellement en place une méthodologie de conception unifiée pour l’ensemble de ses divisions partout dans le monde, et comment les logiciels de Knowllence lui permettent d’en maîtriser la cohérence.
« Cette démarche fait partie intégrante du projet d’entreprise new² du groupe, qui vise à développer son excellence. Elle porte le nom de Radar , acronyme de Required Activities of Design to Achieve Robustness. Il ne s’agit pas pour le moment de l’imposer à l’ensemble des concepteurs du groupe, mais de leur montrer sur des projets pilotes les gains que cela peut leur apporter », explique d’entrée de jeu Philippe Raffoux, responsable du projet.
Et le problème est de taille. Le groupe Schneider Electric dispose en effet de 25 centres R&D à travers le monde qui emploient plus de 7 000 ingénieurs et chercheurs, ainsi que de nombreux ‘‘centres de solution » dédiés aux grands segments de marché où œuvre le groupe.
« Notre objectif en développant Radar a été de développer des processus de conception de produits et de process de fabrication qui soient de classe mondiale, c’est à dire utilisables dans l’ensemble du groupe. Il s’agissait de mettre en place une démarche de conception ‘‘universelle » qui soit robuste. Elle devait nous permettre : d’optimiser le temps de développement de nos offres ; de mettre à profit nos systèmes d’information existants ; d’augmenter notre capacité à travailler ensemble et vite ; de faciliter la standardisation, tout en favorisant l’innovation. »

Six ans de réflexion sur le processus de conception

L’origine du projet remonte à mi-2002 où un premier travail de convergence avec les responsables des activités majeures du groupe a été mené autour des processus de développement. Cela a débouché fin 2004 sur la définition de l’ossature d’une démarche unifiée de conception robuste en électromécanique. « Nous sommes vite arrivés à la conclusion qu’il nous fallait des outils beaucoup plus spécifiques que la bureautique traditionnelle pour gérer la cohérence d’une telle démarche. C’est pourquoi nous avons passé l’année 2006 à évaluer différents outils méthodologiques dans le contexte de projets pilotes pour finalement retenir la Suite TDC (Robust Engineering Suite) ». L’année 2007 a été passée à industrialiser la démarche de conception robuste Radar à l’aide de ces outils.

Cette démarche de conception, ainsi industrialisée, a été validée par les représentants mondiaux des différentes divisions en début d’année et a commencé à être déployée à partir du mois d’avril. «Il ne s’agit pas de l’imposer aux concepteurs, mais d’aider des équipes volontaires à tester cette approche dans un mode ‘‘project coaching » où nous sommes à leurs côtés pour les assister. De toute manière, il n’y a rien de révolutionnaire. Les outils de base restent les mêmes. On retrouve ainsi l’analyse fonctionnelle, l’analyse de la valeur, les Amdec, les outils d’aide à la créativité, etc. Par contre, Radar formalise et rationalise l’emploi de ces outils, et surtout en assure la cohérence ».

Le cycle en V de la conception

D’ailleurs Radar s’appuie sur le traditionnel cycle en V de la conception qui va de l’expression du besoin du client au produit fini à travers un certain nombre de jalons. « Sur la branche descendante du V, correspondant à la recherche de solutions, les premières étapes de la démarche Radar sont consacrées aux exigences clients. On y retrouve quatre étapes : l’analyse des besoins exprimés par le client permet d’identifier des besoins fonctionnels relativement à un système ou à une de ses parties ; la description fonctionnelle de l’offre permet de transcrire les requêtes clients en fonctions de service, de décrire les étapes du cycle de vie du produit, d’en identifier les performances attendues, ainsi que les besoins de la Supply Chain ; l’analyse préliminaire des risques et priorités permet d’identifier les risques liés à l’utilisation du produit et d’attribuer une gravité à chaque fonction de service en utilisant la pratique AFMEA (Amdec de fonctions) ; enfin le choix d’architecture du produit est fait après pré-dimensionnement simulation, choix des composants et présélection des matériaux », explique Philippe Bergin, qui a participé au développement de Radar.

Ces quatre étapes aboutissent au premier jalon important du cycle en V, le Select , où l’on fixe l’architecture. Durant toute cette partie, c’est l’outil TDC Need , module d’analyse fonctionnelle externe et de cahier des charges de la Suite TDC qui est utilisé pour garantir la cohérence des informations. Il permet de se poser les bonnes questions dès le démarrage d’un projet, en faisant abstraction des solutions, grâce à l’expression fonctionnelle et exhaustive du besoin.

On entre ensuite dans le domaine de l’analyse des conditions fonctionnelles, qui comporte lui aussi quatre étapes. La première est innover et développer . Il s’agit de commencer à proposer des solutions physiques. On utilise alors les outils traditionnels de CAO, ainsi que de calcul et de simulation, et l’on gère les données dans le système d’information global basé sur Windchill de PTC dans le cas de Schneider Electric. C’est aussi à ce moment que l’on décide si le produit sera développé en interne ou confié à un prestataire d’ingénierie. La deuxième étape est la description des fonctions techniques . Il s’agit, à l’aide de la méthode bloc diagramme pour la mécanique ou SADT pour l’électronique, de décomposer l’architecture du produit pour en identifier les fonctions techniques de flux et de contact, ainsi que d’en extraire les conditions fonctionnelles liées à la solution étudiée. La troisième étape est une analyse poussée par la méthode Amdec . Il s’agit d’évaluer et de garantir la fiabilité en levant les risques, en attribuant une gravité aux conditions fonctionnelles et en réduisant la criticité des défaillances potentielles à la fois sur le produit et sa Supply Chain . « Mais attention, ne nous y trompons pas, l’Amdec doit être en permanence à l’esprit des concepteurs », prévient Philippe Bergin. La dernière étape conduit à la réalisation d’un tableau des conditions fonctionnelles . Celui-ci liste toutes les conditions fonctionnelles liées aux besoins et à la solution étudiée. Il fait apparaître la gravité, issue de l’Amdec, liée à chacune d’entre-elles.

Cette dernière étape est cruciale car elle débouche sur le jalon Do où l’on prend la décision de poursuivre ou non le projet. Durant les quatre étapes que nous venons de décrire c’est essentiellement le module TDC FMEA , axé sur l’Amdec de fonctions, qui est mis à contribution.

Valider les solutions

Du côté de la branche montante du cycle en V, qui correspond à la vérification et la validation des solutions, on retrouve l’ensemble des étapes traitant les paramètres produits et composants. « On y retrouve en premier lieu la vérification fonctionnelle de la conception dont le but est de démontrer que la conception du produit remplit les exigences décrites dans la spécification produit. Un plan de vérification que l’on traite à l’aide de TDC FMEA », explique Philippe Bergin. Viennent ensuite le choix des intervalles de tolérance capables qui sont fonctionnellement, technologiquement et économiquement viables ; le calage des conditions fonctionnelles à l’aide d’un modèle proche de la réalité permettant de spécifier les valeurs nominales des paramètres, afin de pouvoir les utiliser pour effectuer des simulations ; la spécification du contrôle qualité des composants et du produit ; l’Amdec Process , afin d’identifier et d’évaluer les conditions fonctionnelles liées au process de production, lui aussi traité à l’aide de TDC FMEA ; l’analyse des risques sur les composants et sous-ensembles, en vue de préparer leur plan de contrôle qualité et d’orienter l’élaboration des processus et outillages ; enfin la revue de contrat fournisseur, afin de fixer leurs engagements et de définir les échanges d’information en fonction du contexte. Ces sept étapes aboutissent au jalon Implement qui marque la décision d’investir.

La branche remontante du V se poursuit avec cinq autres étapes. Le rapport de vérification des composants et sous-ensembles, qui permet de réaliser les moyens et les outillages, puis de vérifier physiquement les composants et les sous-ensembles ; on passe ensuite aux prototypes industriels et à la production des produits pilotes , d’abord avec les moyens industriels existants, pour vérifier les performances des produits, puis avec les moyens de production de série pour vérifier et valider l’ensemble produit/process ; vient ensuite la vérification produit où l’on vérifie les conditions fonctionnelles du produit fabriqué à partir des prototypes ou des produits pilotes ; on termine par la validation produit et la qualification des processus , qui permettent de valider l’ensemble des critères demandés par le client sur le produit industrialisé ; puis par les plans de contrôle qualité des composants et des produits, qui permettent de maîtriser l’ensemble de la production des composants, sous-ensembles et produits. On arrive alors au dernier jalon Produce , qui marque la décision de lancer la production.

Découvrez l’enchainement de ces méthodes de conception dans Robust Engineering Suite
à l’occasion d’un webinaire « Fil rouge du processus de conception« 

Adapter la démarche de conception au projet

« La première réaction de beaucoup de concepteurs est de dire cette démarche est très complète, même trop complète pour ce que j’ai à concevoir. Ne pourriez-vous pas en dériver une démarche allégée correspondant mieux à mon besoin ? La bonne solution n’est pas de supprimer des étapes, mais d’en adapter la profondeur au challenge projet à relever », estime Philippe Raffoux.
L’un des challenges actuels de l’équipe de Philippe Raffoux est de ‘‘ne pas laisser retomber le soufflé ». « La démarche Radar a suscité beaucoup d’intérêt de la part de nos équipes de conception. Il faut maintenant que nous les aidions à la déployer sur des projets pilotes pour qu’ils puissent en mesurer les gains concrets et se l’approprier ».
Concernant le choix des outils de TDC Software, Philippe Raffoux est clair : «il n’y a rien de miraculeux. Ils permettent de juste de matérialiser des processus et d’en assurer la cohérence tout au long de la chaîne de conception. Ils sont le garant de la robustesse de notre démarche Radar».
Une cohérence qui sera d’autant plus facile à garantir que TDC Software a commencé à lever le voile sur TDC System, sa plate-forme collaborative d’ingénierie issue du projet CoDeKF, élaboré dans le cadre du pôle de compétitivité Véhicule du Futur. Celle-ci simplifiera et automatisera grandement la communication entre les différents modules de la Suite TDC. Nous aurons l’occasion d’en reparler.»

2010 / Reproduit avec l’aimable autorisation de l’auteur, @ Industrie et Technologies

Jean-François Prevéraud, journaliste à Industrie & Technologies et l’Usine Nouvelle, suit depuis plus de 26 ans l’informatique industrielle et plus particulièrement les applications destinées au monde de la conception (CFAO, GDT, Calcul/Simulation, PLM…). Il a été à l’origine de la lettre bimensuelle Systèmes d’Informations Technologiques, qui a été intégrée à cette lettre Web hebdomadaire, dont il est maintenant le rédacteur en chef.