Méthode TRIZ : Principes de Séparation pour Contradictions Physiques

Afin de vous familiariser avec la Méthode TRIZ (ce que c'est, son histoire, son but et ses avantages/inconvénients), je vous suggère la lecture préalable de cet article. Dans le présent billet, je fais beaucoup référence à des concepts abordés dans un autre article dédié à la Matrice des Contradictions et aux Contradictions Techniques. Je vous recommande également sa lecture avant d'attaquer.

Contradiction entre les 39 Paramètres d'un Système

Les Contradictions correspondent au premier concept créé par Genrich Altshuller et son équipe lorsqu'ils ont mis sur pied la méthode TRIZ.

39 paramètres

39 paramètres permettent de complètement caractériser un Système/Produit. Voir cet article sur les Contradictions Techniques pour en savoir plus sur ces paramètres.

Des contradictions

D'après Altshuller, Des contradictions entre ces paramètres apparaissent toujours en ingénierie.

Et il y a 2 types de contradictions selon TRIZ : Technique et Physique.

Pour ces 2 types de contradictions, on va venir piocher dans la liste des 40 principes ceux qui ont l'air pertinents pour se donner des idées (concepts) de solution. Mais le chemin sera différent. On traite aujourd'hui des contradictions dites "Physiques". Nous avons vu les "Techniques" dans un article précédent.

Contradiction Physique

Contradiction Physique : on veut à la fois qu’un paramètre soit grand et petit dans notre Système.

Exemples :

• je souhaite que mon parapluie soit très grand quand déplié, mais très petit quand je dois le transporter dans mon sac à dos
• je souhaite avoir beaucoup de rétroéclairage sur mon ordinateur pour y voir clair, mais très peu pour ne pas vidanger la batterie

Vous l'aurez compris, le but est d'avoir le beurre et l'argent du beurre, tout en évitant le compromis tiède. Pour ce faire, nous allons utiliser la table de Séparation (cf. image plus haut).

Les "40 Principles"

Voir mon article sur les Contradictions Techniques pour une présentation de ces 40 Principes. Ce sont les mêmes 40 principes qui serviront pour résoudre une contradiction Technique et une contradiction Physique.

Comment utiliser le tableau des Principes de Séparation ? 

L'utilisation de la table de Séparation repose sur le processus usuel de la méthode TRIZ rappelé par le prisme de TRIZ:

• On repère une contradiction appliquée --> C'est notre problème concret, appliqué, qu'on constate sur notre Système
• On en déduit une contradiction générique --> reformuler son problème concret comme une contradiction d'un des 39 paramètres avec lui-même (Concept de problème)
• On réfléchit à la séparation qu'on souhaite adopter --> Séparation en Temps, Espace, Conditions, par le Système ? (Concept de problème davantage avancé)
• On regarde dans le Tableau de Séparation quels sont les Principes d'innovation que l'on retrouve dans les cas de séparations qui nous intéressent. --> on obtient alors les Concepts de Solution‍
• On choisit le Concept de Solution qui nous semble pertinent et, avec les spécialistes Métier de notre Système, on le convertit en une solution concrète pour notre Produit --> on a la Solution Appliquée à notre Problème Concret.

Exemple : la séparation en Temps pointe (là où il y a un petit sablier, cf. image en haut de cet article) vers les principes 1, 7, 9, 10, 11… Ce sont donc ces principes qu’on va tâcher d’appliquer à notre Système pour résoudre notre Contradiction Physique.

Des exemples d'application suivront en fin de cet article.

Comment choisir la Séparation que l'on souhaite ? 

Se demander ce qu'on veut réellement pour notre Produit

Lorsqu'on est face à notre Concept de Problème ("je veux qu'un paramètre soit à la fois grand et petit dans mon Produit"), le but du jeu est de comprendre, en analysant notre système et notre problème, comment on peut « séparer » ce qu’on veut réellement.

Est-ce qu’on veut en fait des paramètres opposés mais à des moments différents ? A des endroits différents ? Dans des conditions différentes ? etc.

En fonction de la séparation qu’on souhaite réellement, le petit tableau des séparations pointe vers plusieurs des 40 principes utilisables pour effectuer notre séparation.

Exemple : je ne veux pas que mon parapluie soit constamment à la fois grand et petit. Je veux qu'il soit grand lorsqu'il est sorti de mon sac et qu'il pleut, et je veux qu'il soit petit quand il ne pleut pas et qu'il est rangé dans mon sac. Je veux donc que la taille de mon parapluie soit grande/petite à des moments différents.

Les Séparations possibles

Séparation en Temps

On veut que le paramètre soit grand à un moment, et petit à un autre.

Exemple : Le parapluie

Séparation en Espace

On veut une chose à un endroit et son contraire à un autre.

Exemple : Je veux que ma tasse de thé soit chaude dedans mais froide dehors pour ne pas me brûler les doigts.

Séparation en Condition

On veut des paramètres opposés au même moment et au même endroit… Mais sous des conditions différentes. A utiliser quand on ne peut pas séparer en temps ni en espace.

Exemple : Je veux que les vitres de ma voiture me permettent de voir dehors depuis l’intérieur, mais qu’on ne puisse pas voir l’intérieur depuis dehors.

Séparation par le Système

A utiliser si aucune des 3 séparations précédentes ne fonctionne. Il y en a 3 types.

Séparation par l’échelle

On veut des paramètres opposés mais pas au même niveau du Système (système de systèmes - système - sous système - composants…).

• Transition au sur-système

NOTA : Le sur-système est l'extérieur de votre Système. Il s'agit de tous les Systèmes qui entourent le vôtre et avec lesquels il interagit potentiellement.

Exemple : Je veux ne pas avoir à me soucier de la fréquence propre d’un building en le construisant mais je ne veux pas qu’il tombe lors d'un tremblement de terre —> je le connecte par un câble amortisseur à tous les buildings environnants.

• Transition au sous système

Exemple : une chaîne de vélo est flexible au niveau système, mais rigide au niveau de ses maillons.

Transition au Système inverse

Essayer (comme le suggère un des 13 Creativity Triggers) d’inverser la situation ("the other way around").

Exemple : Tapis de course --> on veut courir longtemps mais pas loin ? --> On fait se déplacer le sol sous nos pieds plutôt que nous sur le sol.

Transition à une Alternative

Changer le Système par un autre.

Exemple : je veux faire une cascade mais j’ai peur de me blesser —> j’engage un cascadeur.

‍

NOTA : Vous noterez que dans le tableau des principes de séparation, il n'y a que 4 lignes : Space, Time, Condition, Scale. La dernière ligne fait penser à la séparation par "l'échelle" uniquement, mais n'ayez crainte, elle couvre bien toutes les Séparations par le Système (Echelle, dont transition au sur/sous-système + Système inverse + Alternative).

Comment repérer des Contradictions puis les résoudre ? 

Comment détecter une contradiction sur notre Système ? Car ce que je vois, c'est juste un problème ("ça ne marche pas"), et pas spécialement une contradiction. Encore moins une contradiction d'un paramètre avec lui-même.

Repérer une contradiction sur la base d'un problème qu'on a sous les yeux peut demander un peu de pratique. Néanmoins, voici quelques méthodes dans des cas de figure qu'on connaît tous.

Lors d'une résolution de problème : via les Bad Solutions

Pour savoir ce qu'est une Bad Solution, voir cet article sur les Contradictions Techniques.

Ces Bad Solutions vont être le point de départ de la résolution de problème, via le Tableau des Séparations :

• Prenons une première Bad Solution. Est-elle complètement OK ? Résout-elle complètement notre problème ? Si oui, alors pas la peine de pousser plus loin la réflexion, on peut l'appliquer directement.
• Si non, si elle a des défauts, c'est sûrement qu'elle contient une Contradiction
• La repérer (elle est là, c'est sûr)
• Trouver la contradiction générique associée, et définir la Séparation nécessaire (Concept de Problème)
• En déduire via la table des Séparations les Principes à étudier parmi les 40 (Concept de Solution)
• Concrétisez avec vos Experts Métiers le Concept de Solution qui vous semble le plus viable. Vous avez alors votre Solution Appliquée !

Lors d'une conception : Function Maps

Comme vu dans l'article sur les Contradictions Techniques, la méthode TRIZ pousse à modéliser le sujet qui nous occupe par des schémas divers et variés. Je reprends ici le même exemple de Functions Map.

Cela peut s'apparenter en Conception à un travail d'Architecture de son Système. Admettons que vous associez un code couleur à vos flèches représentant les Actions d'un élément Sujet vers un élément Objet : vert si action OK et désirée, rouge si action non désirée.

Exemple de Contradiction Physique dans le graphe ci-dessus (qui n'apparaît pas sur l'image) :

• Action OK définie par une flèche verte : pump moves mixture
• Action rouge : mais pump moves too much mixture (et cela consomme beaucoup d'énergie)

Vous tenez ici une contradiction. Via les Function Maps, repérer une contradiction est assez simple : recherchez là où il y a des actions OK (en vert) et d'autres qui ne sont pas désirées (en rouge) très proches l'une de l'autre, ou concernant la même petite boîte.

Dans notre exemple, on peut en tirer les Contradictions Physiques (Concepts de Problème) suivants :

• Volume of moving Object (Je veux que la pompe mette en mouvement beaucoup de mixture à la fois, mais pas trop sinon elle va consommer trop d'énergie électrique)
• Use of Energy by moving object
• Loss of Energy
• Loss of Substance
• ...

NOTA : si plusieurs paramètres vous semblent convenir pour décrire de manière générique votre problème appliqué, ne vous inquiétez pas. La table des Séparation n'a pas besoin en entrée du paramètre exact qui décrit le mieux votre problème.

Qu'est-ce que je veux réellement ? 

Je veux que ma pompe aspire beaucoup de mixture à la fois, mais pas trop pour ne pas trop tirer sur mon réseau électrique. Je veux donc un fort Volume of Moving object quand le réseau électrique me le permet, et un faible Volume dans le cas contraire. Cela ressemble à une Séparation en Conditions.

Et la table des Séparation nous donne les Concepts de Solution suivants (les Principes) :

• Replace Mechanical System --> Prendre une pompe plus efficace en énergie ?
• Pneumatics and Hydraulics --> Exploiter le poids de la mixture à mettre en mouvement pour faciliter le travail de la pompe ?
• Porous Material --> Les pièces de la pompe peuvent être très grandes, mais creuses et donc les plus légères possible ?
• Colour Change --> Faire tourner la pompe à plein régime lors des heures creuses EDF, ou lorsque le réseau interne de l'usine n'est pas chargé par ailleurs
• Parameter Change --> jouer sur la viscosité de la mixture pour faciliter son déplacement à volume égal
• Phase Transition --> jouer sur des phénomènes de mécanique des fluides très pointus pour faciliter le travail de la pompe (comme pour la conception des hélices de bateaux)
• Accelerate Oxydation --> Je n'ai pas d'idées pour celui-ci !
• Inert Envrionment --> Exploiter utilement l'inertie de la pompe pour entretenir son mouvement et diminuer sa consommation énergétique

Si une solution appliquée semble valable, on n'a plus qu'à l'appliquer et la valider !

Lors d'une analyse de Besoin : Ideal Outcome

La méthode TRIZ pousse à toujours définir clairement ce qu'on veut "dans l'idéal" pour le fonctionnement de notre Système. La littérature anglophone parle d'Ideal Outcome. C'est très comparable, si on est en début de Projet de Conception, à une Analyse de Besoin.

Une fois tous nos besoins listés, on réalise généralement un travail d'Architecture du Système souhaité afin de voir où on mets les pieds (Faisabilité). A quoi va ressembler le Système souhaité ? De quels sous-systèmes sera-t-il composé ? etc.

A ce moment-là, vous pouvez vous rendre compte que votre Système devra potentiellement avoir 1 grande caractéristique qui devra être à la fois très prononcée et très discrète, du fait de 2 Besoins qui s'opposent eux-mêmes. Et vous n'aviez pas vu que ces Besoins s'opposaient avant ! Ni la conséquence sur l'un de vos 39 paramètres Système !

Pas de problème, vous venez de mettre le doigt sur... une Contradiction (Physique) ! Nul besoin de s'affoler :

• Il vaut mieux repérer les contradictions de Besoin au début de son projet que pendant (cela coûte moins cher à résorber)
• Et nous avons la Table des Séparations pour nous aider à concilier ces 2 Besoins qui s'opposent !

In fine, toutes les parties prenantes seront heureuses car le Système répondra aux 2 Besoins initialement opposés.

A n'importe quel moment

Il faut chercher les contradictions partout et tout le temps :

• sur les Besoins (avec les parties prenantes)
• Sur les Spécifications de son Produit
• Sur l'Architecture de son Produit
• Sur le Système qu'on a actuellement
• Sur le Système qu'on veut
• etc.

La pratique aide, c'est sûr, mais se forcer à l'exercice met rapidement le pied à l'étrier.

Que faire si plusieurs contradictions génériques sont possibles pour un même problème appliqué ? 

Comme on l'a vu ci-dessus ce n'est absolument pas un problème car pour utiliser la table de séparation vous avez simplement besoin de connaître la Séparation que vous voulez réellement.

Cela dit, pour être sûr qu'on a bien mis le doigt sur une contradiction Physique il est plus sain de savoir dire lequel des 39 paramètres est en contradiction avec lui-même.

Que faire si on a plusieurs contradictions à gérer dans un même Système ? 

Si nous avons plusieurs contradiction a gérer : résoudre les contradictions par ordre décroissant de gain sur les fonctions importantes (Primary Functions, selon la littérature TRIZ) de votre Système.

Autres exemples d'applications concrètes

Je vais tâcher de trouver des exemples très pointus mais aussi très courants, en plus de ceux déjà exposés ci-dessus. Si vous avez d'autres idées, n'hésitez pas à m'en faire part par l'un des moyens qui se trouvent en bas de page (LinkedIn, Mail, Twitter) !

Exemple 1 : Mécanique (le parapluie)

Problème appliqué

Vous le connaissez, j'en ai parlé plus haut : je veux que mon parapluie soit à la fois grand quand il pleut, et petit lorsque rangé dans mon sac.

Concept de problème (Contradiction générique + Séparation souhaitée)

J'ai bien une contradiction entre 1 paramètre et lui-même. Ce serait le paramètre "area of stationary object".

NOTA : on pourrait aussi choisir "volume of stationary object", ou "shape". Peu importe, il n'est pas essentiel de clarifier quels paramètres sont les meilleurs pour traduire mon problème avec les Contradictions Physiques car la table de Séparation ne requiert pas cette donnée pour être utilisée.

Ce que je veux réellement, c'est que ce paramètre soit grand à un moment, et petit à un autre. C'est donc vers une Séparation en Temps que je m'oriente.

Concepts de Solution : les principes pointés par la table de Séparation

Les principes vers lesquels me pointe le tableau des Séparation sont :

• Segmentation
• Nested Doll
• Prior Counteraction
• Prior Action
• Cushion in Advance
• Dynamics
• Partial or Excessive Action
• Mechanical Vibration
• Periodic Action
• Continuity of Useful Action
• [...]
• Pneumatics and Hydraulics
• [...]
• Thermal Expansion

Solution appliquée

En prenant chaque principe proposé et en voyant quelle idée cela provoquait en moi, quelques éléments sont ressortis :

• Segmentation --> au lieu d'un parapluie classique, chacun transporterait un ensemble de feuillets A4 en plastique rigide et reliés entre eux par un oeuillet unique à une extrêmité (comme un nuancier de peinture). En cas de pluie, il faudrait alors déployer ce nuancier pour former un boucler contre la pluie

• Dynamics --> le Produit serait un manche au bout duquel un moteur ferait pivoter un fil à grande vitesse (comme un petit rotofil). Ce fil viendrait perturber le flux d'air+gouttes au dessus de notre tête de manière à empêcher les gouttes de nous tomber dessus.

• Pneumatics and Hydraulics --> un parapluie gonflable plutôt que dépliable ? 

Exemple 2 : Electronique

J’ai un processeur qui fonctionne en lien avec une mémoire flash sur une carte électronique. Les 2 sont des composants distincts que j’ai approvisionné à 2 endroits différents et que j’ai placé indépendamment sur ma carte dans des empreintes séparées de 5cm, puis entre lesquels j’ai routé des pistes.

Problème appliqué

Dans certains cas de fonctionnement, le processeur démarre plus vite que la mémoire flash et commence à initier une communication avec cette dernière. La mémoire, non correctement initialisée, ne répond pas dans le meilleur des cas; mais fréquemment elle répond n’importe quoi (chaîne de données qui n’a aucun sens car mal formée).

Dans ce 2ème cas, le processeur plante et arrête toutes opérations. Le seul moyen de s’en sortir est un redémarrage complet du processeur (et donc de mon Système).

Concept de problème (Contradiction générique + Séparation souhaitée)

Nous sommes donc ici sur un problème de paramètre Speed pour notre processeur

Quelle séparation voudrais-je effectuer ?

J’aimerais que le processeur soit très rapide à démarrer lorsque la mémoire flash est déjà en route, et un peu moins rapide quand la mémoire flash n’est pas encore en route. On peut s’orienter vers une principe de Séparation par Condition.

Concepts de Solution : les principes pointés par la table de Séparation

Pour la Séparation en Condition, on a les Principes d’innovation suivants :

• Replace Mechanical Systems
• Pneumatics and Hydraulics
• Porous Material
• Colour Change
• Parameter Change
• Phase Transition
• Accelerate Oxydation
• Inert Environment

Solution appliquée

Ces principes me font penser aux solutions concrètes suivantes :

• Replace Mechanical Systems --> Plutôt que d’utiliser une mémoire séparée de mon processeur, utiliser un SoM (System on Module) qui comporte une mémoire directement intégrée (ou quasi) au processeur. Les 2 seront ainsi faits pour fonctionner ensemble en parfaite harmonie (démarrer ensemble, s’attendre l’un/l’autre etc.)
• Pneumatics and Hydraulics --> Ralentir volontairement et électroniquement l’établissement du signal entre le processeur et la mémoire dans le cas où la mémoire n’est pas alimentée et up to work.
• Porous Material --> limiter la taille de la mémoire pour qu’elle démarre plus rapidement
• Colour Change --> à la manière d’un feu rouge, retarder logiciellement l’établissement de la connexion par le processeur à la mémoire en se basant sur une entrée GPIO du processeur pilotée par des composants autour de la mémoire (GPIO up si celle-ci est alimentée et up to work)
• Parameter Change --> limiter la fréquence de communication processeur/mémoire pour laisser une chance à la mémoire de démarrer avant la fin des premiers handshakes initiés par le processeur.
• Phase Transition --> Eviter justement les transitions en laissant la mémoire fonctionner non stop, que le processeur soit fonctionnel ou non.

Rappel :
Vous vous dites que les Principes ne sont pas clairs… Et les solutions appliquées auxquelles ils me font penser n’ont pas forcément de liens évidents avec le principe... Vous avez raison !
Les termes décrivant les Principes d'Innovation sont volontairement très englobants pour regrouper tout un tas de solution qu’Altshuller et son équipe ont vues utilisées pour gérer des contradictions diverses dans des brevets. Cet englobement amène fatalement à l'utilisation de mots très couvrants et très vagues.
Mais ce n’est pas une mauvaise chose ! Cela pousse à penser hors des sentiers battus avec pour seul guide une petite indication.
In fine, cela aide à trouver des solutions appliquées qui peuvent être très proches ou très éloignées des mots contenus ds le principe ("Mechanical Systems" --> j’en déduis qu’il faut changer un composant électronique). Ces principes sont des « prompts », des amorces à idées pour notre esprit. Pas des instructions à exploiter directement.

Exemple 3 : Textile

Problème appliqué

Je suis Judoka, j'ai des kimonos (ou judogi pour les puristes).

A l’usage, un judogi se tâche : il y a du sang et autres salissures diverses. Il est classiquement nécessaire d’effectuer un lavage en machine à l’eau froide pour retirer le sang, et un lavage en machine à chaud pour tout le reste. Cela m’embête : j’aimerais n’avoir à faire qu’un seul lavage en machine !

Concept de problème (Contradiction générique + Séparation souhaitée)

Le paramètre Système avec lequel je suis en conflit est donc la Température (de l'eau du cycle de lavage). J’aimerais que la température de l’eau soit froide sur les taches de sang, et chaude sur tout le reste du vêtement.

C’est donc une séparation en Espace qui semble être mon concept de problème.

Concepts de Solution : les principes pointés par la table de Séparation

Le tableau des Séparation pointe vers les Principes suivants pour la séparation en espace :

• Segmentation
• Taking out
• Local Quality
• Asymmetry
• Nested Doll
• The other way round
• Spheroidality – Curvature
• Another Dimension
• Intermediary
• Copying
• Flexible membranes, thin film
• Composite Material

Solution appliquée

Certains de ces principes me donnent plusieurs idées de solutions appliquées (séparées par des points-virgules):

• Segmentation --> Avoir un kimono « démontable » et laver les parties tâchées de sang à l’eau froide et le reste à l’eau chaude (j'aime l'innovation mais c'est peut-être un peu capilotracté...)
• Taking out --> Un prétraitement (à l’eau froide) pour retirer le sang avant d’aller en machine permettrait d’utiliser ensuite un cycle à température chaude sans se soucier de figer les tâches de sang sur le textile ; Ou l’inverse : faire un cycle à l’eau froide puis faire tremper à l’eau chaude le kimono.
• Local Quality --> Ajouter à mon cycle à l’eau chaude des produits détachants sang qui fonctionnent en eau chaude ; Ajouter à mon cycle à l’eau froide des agents blanchissants pour gérer les tâches autres pendant que l’eau froide se charge de nettoyer le sang ; Un prétraitement chimique avec produit spécialisé en retrait de tâche de sang avant d’aller en machine pour un cycle à l’eau chaude.
• Asymmetry --> La machine à laver réalise un long début de cycle à l’eau froide (pour bien retirer le sang) puis poursuit et termine le cycle à l’eau chaude (pour gérer la saleté autre) ; Le kimono comporte un prétraitement à l’utilisation en entraînement/compétition qui dépose une fine couche anti-tâche de sang, qui empêche ce dernier de s’accrocher ou de coaguler à l’eau chaude.
• The other way round --> Plutôt que de mettre le kimono dans l’eau, mettre l’eau sur le kimono (lavage manuel localisé et dédié des tâches) ; Avoir des kimono noirs plutôt que blancs afin que les tâches de sang ne se voient plus (merci le JJB pour l'astuce);
• Copying --> utiliser des kimono jetables
• Composite Material --> Utiliser pour la confection des kimonos une matière textile qui ne se tâche pas durablement même si le sang coagule ?

NOTA : pour générer ces solutions, j’ai principalement gardé en tête que mon système est l’eau/ma machine à laver ("Que veut dire Taking Out pour mon eau/ma machine ?"). Car la température est un paramètre qui décrit ce système-là. Néanmoins, pour me générer d’autres idées j’ai aussi considéré que le système pouvait être mon kimono (« que veut dire taking out pour mon kimono ? »).

Attention : Certaines solutions appliquées sont en effet des méthodes utilisées par les Judoka. Concernant les autres méthodes, elles ont été générées par mon application de la méthode TRIZ mais je ne les ai pas testées. Ne tentez pas ça chez vous sans un test préalable.‍

Exemple 4 : Traitement du signal

Problème appliqué

J’ai un capteur (de son, d’accélération, de température, …) au sein de mon système. Il est très sensible, ce qui est super car il me permet de capter des variations très fines de ce qu’il doit mesurer. Problème : il est aussi très bruité. Il vient capter toutes les petites variations non significatives que je ne veux pas, et les perturbations environnantes.

Par exemple, pour un capteur son sur mon smartphone : il capte bien le son de ma voix, mais il capte aussi tout l’environnement autour de moi qui vient « bruiter » le signal. Mon interlocuteur ne m’entends pas très bien.
Pour un capteur d’accélération sur une voiture : il capte bien les déplacements du véhicule, mais aussi ses petites vibrations à l’arrêt. La navigation peut être entachée d’erreur et d’incertitude de ce fait.

Tout ceci pénibilise le traitement que je dois faire de ma mesure ensuite afin de l’exploiter.

Concept de problème (Contradiction générique + Séparation souhaitée)

Je veux que le capteur soit sensible à certains signaux (utiles) mais non sensibles à d’autres (non utiles, bruit/perturbation). A priori, nous avons donc un souci avec le paramètre Difficulty of Detecting and Measuring.

La séparation que je souhaite obtenir est une séparation par le Système, car les 3 précédentes (Temps, Espace, Conditions) ne peuvent pas fonctionner. Une Séparation par l’Echelle semblerait convenir, puisqu’une transition au système inverse ou à un système alternatif ne me parlent guère sur cette problématique.

Concepts de Solution : les principes pointés par la Table des Séparations

La table de séparation pointe vers les principes suivants dans la colonne Scale :

• Segmentation
• Local Quality
• Merging
• Universality
• Anti-Weight
• Equipotentiality
• The other Way Round
• Blessing in disguise
• Feedback
• Self-Service
• Cheap Short-living object
• Homogeneity
• Composite Material

Solution appliquée

Voilà les solutions appliquées auxquelles ces Principes me font penser et qui pourraient être mises en œuvre pour résoudre ma problématique :

• Segmentation --> Mettre entre l’environnement à mesurer et le capteur un « filtre » qui empêche le signal non utile de passer (plots amortisseur pour isoler des accéléromètres, parois +/- fine et structurée pour le passage du son à certaines fréquences, petite bonnette sur les micro pour éviter le bruit du souffle…) ; subdiviser a priori lors de la conception Système le signal non utile mesuré en toutes ses composantes, les caractériser et les mitiger 1 par 1 (bruits générés par le produit lui-même, bruit produit par l’extérieur, bruit thermique…)
• Local Quality --> Considérer un capteur sensible aux fréquences et niveaux de signal qui nous intéressent seulement.
• Merging --> Ajouter une autre source de mesure de la même grandeur, moins sensible que la première, qui ne captera pas les petits signaux non utiles, et comparer/hybrider les 2 sources pour en tirer une information utile
• Universality --> Ajouter une autre source de mesure d’une grandeur différente (capteur de son et capteur de pression par exemple) et hybrider les 2 sources pour en tirer une information hybridée qui nous intéresse.
• Anti-Weight --> Considérer que certaines fréquences de votre signal ne peuvent pas correspondre à votre signal utile, et couper ces fréquences lors du traitement logiciel de la mesure ; ou couper ces fréquences par filtrage électronique en sortie du capteur directement
• The other Way Round --> Faire osciller volontairement son capteur (osciller au sens de la mesure qu’on veut faire : son, mouvement, …) pour qu’un antisignal soit présent d’emblée dans la mesure du capteur et viennent annuler le signal non utile qu’on cherche à supprimer par ce biais.
• Blessing in disguise --> Profiter de phases où le signal utile est absent pour mesurer le signal non utile, le caractériser, et ensuite le supprimer (logiciellement) lors des mesures mêlant fatalement signal utile+non utile.
• Feedback --> Etablir un filtre de Kalman pour prédire et mettre à jour le signal utile et ainsi s’affranchir du signal non utile ;
• Cheap Short-living object --> Utiliser un capteur très peu sensible, et combler logiciellement ses manques via traitement du signal. On compense la faiblesse du capteur avec de l’intelligence de traitement.
• Homogeneity --> Faire des hypothèses dans les algorithmes de traitement sur la forme du signal attendu et gommer/limiter les écarts à cette forme.
  

Exemple 5 : Logiciel

Problème appliqué

Je crée un système embarqué pour un client. Top du top de l'IoT. Je le déploie chez lui. Pour me faciliter les diagnostics en cas de problème et améliorer en continu mon Produit, je lui fais loguer dans sa mémoire locale tous les évènements et toutes ses opérations avec une profondeur de logs de plusieurs jours.

Problème: je n’ai pas énormément de mémoire sur mon Système (c'est un petit système embarqué), et je souhaite que la place disponible soit plutôt dédiée à des informations dont le système a besoin pour fonctionner. Si je remplis la mémoire avec des logs qui me serviront peut-être un jour en cas de problème, ce n'est pas terrible.

Concept de problème (Contradiction générique + Séparation souhaitée)

Je souhaite que mon système log au maximum d’informations pour m’aider au mieux lors de mes diagnostics, mais qu’il en log également un minimum pour ne pas surcharger sa mémoire.

Le paramètre en jeu pourrait être Loss of information, ou Volume of Stationnary Object, Quantity of Substance, Ease of Repair (par exemple).

Je mets de côté le cas où on peut augmenter directement la mémoire concernée du système. Qu’est réellement souhaité ici ? Je veux à la fois beaucoup de logs et pas beaucoup de log tout le temps, n’importe où et peu importe les conditions. Une séparation par le Système semble alors pertinente.

Concepts de Solution : les principes pointés par la table de Séparation

La table de séparation pointe vers les principes suivants ds la colonne Scale :

• Segmentation
• Local Quality
• Merging
• Universality
• Anti-Weight
• Equipotentiality
• The other Way Round
• Blessing in disguise
• Feedback
• Self-Service
• Cheap Short-living object
• Homogeneity
• Composite Material

Solution appliquée

Voilà les solutions appliquées auxquelles ces Principes me font penser et qui pourraient être mises en œuvre pour ma problématique :

• Segmentation --> Trier les logs et loguer finement (à haute fréquence) les plus utiles et moins finement les autres ;
• Local Quality --> Le système lui-même analyse ses logs et écrit uniquement les conclusions en mémoire et ne conserve pas les logs sources (à telle heure tous mes paramètres étaient aux vert, je ne logue pas tous les paramètres mais je logue simplement que tout était OK); Anticiper et mitiger les problèmes amonts du Système pour ne pas qu’il ait à écrire de logs d’erreurs (s’il ne rencontre jamais d’erreurs...)
• Merging --> Codifier, Packager et compresser au maximum les logs
• Anti-Weight --> Faire remonter ces logs à un serveur central via internet de temps en temps pour vider ensuite la mémoire des logs remontés
• Equipotentiality --> le système log tout, et quand la capacité mémoire descend en dessous d’un seuil défini, le système efface les logs définis comme les moins importants
• The other Way Round --> un serveur central vient interroger régulièrement notre système embarqué avec les informations nécessaires au monitoring. C’est ce serveur central qui emmagasine alors les informations, plus besoin de logs en local sur le produit embarqué.
• Blessing in disguise --> Ne faire loguer des informations au système que s’il y a un problème (nécessite des Built-in Tests en continu pour que le système se monitore lui-même et sâche dire s'il est en défaut)
• Feedback --> ne faire loguer au système ses informations, en local, que s’il n’a pas de connexion vers son serveur central qui emmagasine les logs lui-même
• Cheap Short-living object --> le système logue très peu de temps ses logs et les évacue par impression papier.
• Homogeneity --> Remplacer les logs possibles et intéressants par des allumages de LEDs visibles à l’extérieur du Système. On a alors potentiellement 40 LEDs positionnées sur une façade du système. Quand un évènement a lieu ponctuellement et/ou est maintenu, la LED correspondante s’éclaire 1s et/ou est maintenue éclairée. Cette façade du système est filmée via vidéo. C’est la mémoire vidéo qui remplace la mémoire logs…
• Composite Material --> Le système écrit vers autre zone mémoire (dite de masse) ses logs pour qu’il les évacue de sa mémoire utile (OK, j'avais dit qu'on ne pouvait pas augmenter la mémoire du Système...!)

Quelques commentaires pour terminer

Encore une fois on voit la grande force de la méthode TRIZ : des outils construits sur plusieurs décennies pour être utilisés en quelques minutes par les ingénieurs d'aujourd'hui. Il ne faut pas s'en priver !

Vous voyez, d'après les précédents exemples, que cela peut vous aider à résoudre des problèmes très globaux (laver votre linge) comme très pointus (la relation Processeur/Mémoire dans votre Système, logs logiciels, traitement du signal). Qu’il s’agisse de problèmes du quotidien ou très techniques, cela ne prend que peu de temps à appliquer et génère tout de suite pas mal d’idées !

Ne soyez pas effrayés par le côté "vague" des 40 Principes ou 39 Paramètres. C'est au contraire une force à exploiter pour ne pas brider votre réflexion.

Avec de la pratique de TRIZ, on se rend compte que toute Contradiction Technique peut se redéfinir comme une Contradiction Physique. Les maîtres de TRIZ préfèrent d'ailleurs raisonner en contradiction physique car cela amène souvent à une plus grande abstraction du problème appliqué, et donc à une réflexion plus ouverte et in fine un plus grand ensemble de concepts de solutions.

Aurélien NARDINI