La ligne sort une pi\u00e8ce toutes les X secondes, et le poste EOL en demande quelques-unes de plus. \u00c0 chaque \u00e9quipe, une file de modules finis s'accumule devant le testeur. Quelqu'un propose la solution \u00e9vidente : supprimer les tests les plus lents. Trois mois plus tard, un retour terrain r\u00e9v\u00e8le un d\u00e9faut qu'un de ces tests \u00ab lents \u00bb d\u00e9tectait. C'est le pi\u00e8ge du temps de cycle EOL : la pression porte sur le chrono, mais la facture tombe sur la couverture.<\/p>\n
Cet article explique notre approche sur les postes de test de production : mesurer o\u00f9 passe vraiment le temps, supprimer l'attente avant de supprimer des tests, puis seulement retravailler le contenu, avec une carte de couverture qui rend chaque compromis visible.<\/p>\n
Le poste n'a pas besoin d'\u00eatre rapide. Il doit suivre le takt time<\/a>de la ligne, c'est-\u00e0-dire le temps disponible par pi\u00e8ce pour satisfaire la demande.<\/p>\n Si un poste EOL demande 42 s par pi\u00e8ce, manutention comprise, il ne suit pas. Deux options :<\/p>\n Budg\u00e9tez toujours le cycle complet du poste<\/strong>, pas seulement la s\u00e9quence de test :<\/p>\n En pratique, la partie hors test p\u00e8se souvent lourd dans le cycle, et c'est l\u00e0 que viennent les premiers gains.<\/p>\n Avant toute modification, instrumentez la s\u00e9quence. Chaque \u00e9tape doit enregistrer un horodatage de d\u00e9but et de fin dans le fichier de r\u00e9sultats, avec l'horloge du poste. Apr\u00e8s quelques centaines de pi\u00e8ces, vous obtenez une distribution, pas seulement une moyenne.<\/p>\n Imaginez une barre horizontale par \u00e9tape, align\u00e9e sur un axe de temps commun, comme un diagramme de Gantt : chargement, bridage, mise sous tension, d\u00e9marrage du calculateur, session de diagnostic, v\u00e9rification du flash, mesures analogiques, E\/S num\u00e9riques, contr\u00f4les CAN\/LIN, consommation, rapport, d\u00e9chargement. Les barres se suivent bout \u00e0 bout, car la s\u00e9quence est s\u00e9rie. Les espaces entre les barres sont de l'attente pure : stabilisation des relais, temporisations fixes, changements de calibre, timeouts de communication.<\/p>\n Ce qu'il faut chercher :<\/p>\n Une temporisation fixe doit couvrir le pire cas ; elle gaspille donc du temps sur chaque pi\u00e8ce typique. Attendez plut\u00f4t une condition mesurable, avec un timeout qui couvre le pire cas.<\/p>\n Exemple :<\/em> un filtre RC sur une entr\u00e9e de mesure atteint 0,1 % de sa valeur finale apr\u00e8s environ 7 constantes de temps (e^-7 \u2248 0,09 %). Avec R = 10 k\u03a9 et C = 100 nF, \u03c4 = 1 ms : la stabilisation prend donc environ 7 ms. Un ancien Il en va de m\u00eame pour le produit test\u00e9 : interrogez une trame \u00ab pr\u00eat \u00bb ou une r\u00e9ponse de diagnostic plut\u00f4t que d'attendre le temps de d\u00e9marrage maximal. Pour le diagnostic sur CAN, les temporisations des sessions UDS<\/a> et de la couche transport ISO-TP<\/a> fixent de vrais minima ; tout ce qui d\u00e9passe est un choix.<\/p>\n Ordonnez les \u00e9tapes pour faire toutes les mesures de tension continue ensemble, puis toutes les mesures de r\u00e9sistance, puis toutes les mesures de courant. Chaque changement de calibre ou de fonction d'un multim\u00e8tre co\u00fbte du temps ; trier par configuration r\u00e9duit le nombre de changements. C'est un simple r\u00e9ordonnancement, sans aucune perte de couverture, \u00e0 condition que la logique de test ne d\u00e9pende pas de l'ordre (v\u00e9rifiez-le).<\/p>\n Un multim\u00e8tre qui int\u00e8gre sur plusieurs p\u00e9riodes secteur rejette bien le bruit du r\u00e9seau, mais il est lent. Beaucoup de limites EOL sont assez larges pour qu'une ouverture plus courte garde une r\u00e9solution suffisante. La r\u00e8gle : l'incertitude de mesure doit rester faible devant la tol\u00e9rance. Un rapport de 10:1 est la r\u00e8gle pratique classique ; 4:1 est souvent accept\u00e9. Choisissez le r\u00e9glage le plus rapide qui respecte ce rapport, et confirmez-le par une \u00e9tude de r\u00e9p\u00e9tabilit\u00e9 (analyse du syst\u00e8me de mesure<\/a>).<\/p>\n Les \u00e9tapes qui utilisent des ressources diff\u00e9rentes peuvent se chevaucher :<\/p>\n Exemple de gain, valeurs d'illustration :<\/em> si le d\u00e9marrage prend 3 s et le contr\u00f4le de contact 2 s, l'ex\u00e9cution s\u00e9rie co\u00fbte 5 s et l'ex\u00e9cution parall\u00e8le 3 s. La loi d'Amdahl<\/a> rappelle la limite : si seule la moiti\u00e9 du cycle est parall\u00e9lisable, le cycle ne descendra jamais sous la moiti\u00e9 s\u00e9rie restante, quelles que soient les ressources ajout\u00e9es.<\/p>\n R\u00e8gle : ne parall\u00e9lisez que des \u00e9tapes qui ne partagent ni chemin \u00e9lectrique, ni instrument, ni trafic bus susceptible de perturber une mesure. Documentez chaque association.<\/p>\n Une fois l'attente supprim\u00e9e, le contenu des tests peut \u00eatre revu. C'est ici que la couverture se perd si l'on proc\u00e8de sans m\u00e9thode.<\/p>\n Listez les classes de d\u00e9fauts que le poste doit d\u00e9tecter, une par ligne : mauvais composant, composant manquant, broche ouverte, court-circuit entre broches voisines, mauvais logiciel, mauvaise calibration, mauvais codage de variante, connecteur endommag\u00e9, fuite, d\u00e9faut de communication. Placez les \u00e9tapes de test en colonnes. Cochez quelle \u00e9tape d\u00e9tecte quel d\u00e9faut.<\/p>\n Les questions deviennent alors pr\u00e9cises :<\/p>\n Un d\u00e9faut n'a pas \u00e0 \u00eatre d\u00e9tect\u00e9 en fin de ligne si un poste pr\u00e9c\u00e9dent le d\u00e9tecte de fa\u00e7on fiable. Les tests au niveau carte (in-circuit, boundary scan, test fonctionnel de la carte assembl\u00e9e) peuvent couvrir les d\u00e9fauts composants. L'EOL se concentre alors sur ce que seul le produit assembl\u00e9 peut montrer : int\u00e9grit\u00e9 des connecteurs, probl\u00e8mes li\u00e9s au bo\u00eetier, logiciel et codage finaux, comportement syst\u00e8me. La carte de couverture doit indiquer, pour chaque classe de d\u00e9fauts, o\u00f9 elle est d\u00e9tect\u00e9e.<\/p>\n Apr\u00e8s une p\u00e9riode de production stable, les donn\u00e9es de mesure montrent la distance de chaque param\u00e8tre \u00e0 ses limites. Un param\u00e8tre avec une grande marge et une forte capabilit\u00e9 proc\u00e9d\u00e9<\/a> est candidat \u00e0 un mode de mesure plus rapide, pas automatiquement \u00e0 la suppression. Ne resserrez ni ne rel\u00e2chez jamais une limite sans l'accord du responsable de la sp\u00e9cification de test, et gardez une trace du changement.<\/p>\n Pour les contr\u00f4les de faisceaux et de connecteurs, une matrice de continuit\u00e9 peut co\u00fbter cher en temps si chaque paire est test\u00e9e une \u00e0 une. Un balayage par groupes (une broche contre toutes les autres reli\u00e9es ensemble) d\u00e9tecte les courts-circuits en moins d'\u00e9tapes (les broches qui doivent \u00eatre reli\u00e9es sont regroup\u00e9es en un seul r\u00e9seau), puis isole la paire fautive seulement quand un court-circuit est trouv\u00e9. La continuit\u00e9 de chaque liaison attendue reste v\u00e9rifi\u00e9e une par une. Les mesures de faible r\u00e9sistance sur les chemins de puissance demandent une mesure quatre fils<\/a> pour rester pr\u00e9cises. Notre guide sur le contr\u00f4le de continuit\u00e9 et d'isolement des faisceaux<\/a> d\u00e9taille la m\u00e9thode.<\/p>\n Quand un poste ne peut pas atteindre le takt time, testez deux pi\u00e8ces ou plus par cycle.<\/p>\n Imaginez une platine avec deux nids c\u00f4te \u00e0 c\u00f4te. Chaque nid a son propre bloc de pointes \u00e0 ressort et son interface connecteur. Derri\u00e8re la platine, une matrice de commutation dirige les instruments partag\u00e9s (multim\u00e8tre, mesure de l'alimentation) vers le nid A ou le nid B. Les bus de communication sont doubl\u00e9s, une interface par nid, pour que les deux pi\u00e8ces d\u00e9marrent et communiquent en m\u00eame temps.<\/p>\n Exemple, valeurs d'illustration :<\/em> une s\u00e9quence de 40 s avec 25 s d'\u00e9tapes ind\u00e9pendantes (d\u00e9marrage, communication, autotests) et 15 s de mesures sur instrument partag\u00e9. En double : 25 s en parall\u00e8le plus 2 \u00d7 15 s d'\u00e9tapes partag\u00e9es = 55 s pour deux pi\u00e8ces (temps de chargement et de d\u00e9chargement exclus, ou masqu\u00e9s par l'autre nid), soit 27,5 s par pi\u00e8ce, sous le takt time de 30 s de la section 1. Ajouter un second multim\u00e8tre ram\u00e8nerait \u00e0 40 s pour deux, soit 20 s par pi\u00e8ce (m\u00eame hypoth\u00e8se sur le chargement et le d\u00e9chargement). Le calcul indique quel instrument doubler.<\/p>\n Compromis \u00e0 peser :<\/p>\n Tout ce qui pr\u00e9c\u00e8de est bien plus simple quand le programme de test s\u00e9pare la s\u00e9quence, les limites, les pilotes d'instruments et les r\u00e9sultats. R\u00e9ordonner des \u00e9tapes, changer un mode de mesure ou r\u00e9partir une s\u00e9quence sur deux nids revient alors \u00e0 modifier une configuration, pas \u00e0 r\u00e9\u00e9crire du code. Notre guide du script au s\u00e9quenceur<\/a> pr\u00e9sente cette structure, et l'article ATP vs QTP<\/a> explique en quoi les tests d'acceptation de production diff\u00e8rent des tests de qualification : c'est pr\u00e9cis\u00e9ment la fronti\u00e8re \u00e0 ne pas brouiller quand on all\u00e8ge une s\u00e9quence EOL.<\/p>\n Les m\u00eames principes s'appliquent en amont, au banc : un ensemble HIL compact comme notre Mini HIL test bench<\/a> permet de d\u00e9velopper et de chronom\u00e9trer les s\u00e9quences avant leur arriv\u00e9e sur la ligne, et les breakout boxes<\/a> donnent un acc\u00e8s direct aux signaux quand il faut v\u00e9rifier le timing d'une \u00e9tape \u00e0 l'oscilloscope.<\/p>\nExemple chiffr\u00e9 (valeurs d'illustration)<\/h3>\n
\n
\n
cycle poste = chargement + bridage + contr\u00f4le de contact + mise sous tension\/d\u00e9marrage + \u00e9tapes de test + \u00e9criture des donn\u00e9es + d\u00e9bridage + d\u00e9chargement<\/code><\/p>\n2. Mesurer avant de couper : la d\u00e9composition du temps<\/h2>\n
Sch\u00e9ma d\u00e9crit : la cascade des temps<\/h3>\n
\n
wait(2000)<\/code>) ajout\u00e9es en d\u00e9veloppement \u00ab par s\u00e9curit\u00e9 \u00bb et jamais revues.<\/li>\n3. Supprimer l'attente avant de supprimer des tests<\/h2>\n
3.1 Remplacer les temporisations fixes par des conditions<\/h3>\n
wait(500 ms)<\/code> sur cette voie gaspille environ 493 ms par mesure. Sur 20 mesures de ce type, cela repr\u00e9sente pr\u00e8s de 10 s par pi\u00e8ce. La physique du circuit RC<\/a> donne l'attente r\u00e9elle ; le code doit l'utiliser, avec une marge document\u00e9e.<\/p>\n3.2 Regrouper les mesures par configuration d'instrument<\/h3>\n
3.3 Ajuster le temps d'int\u00e9gration au besoin r\u00e9el<\/h3>\n
3.4 Parall\u00e9liser ce qui n'interagit pas<\/h3>\n
\n
4. Retravailler le contenu des tests, avec une carte de couverture<\/h2>\n
4.1 Construire d'abord la carte de couverture<\/h3>\n
\n
4.2 D\u00e9placer les tests en amont, pas les supprimer<\/h3>\n
4.3 Utiliser les statistiques pour ajuster les limites, avec prudence<\/h3>\n
4.4 Tests de c\u00e2blage et de faisceaux<\/h3>\n
5. Montages multi-postes et organisation du poste<\/h2>\n
Sch\u00e9ma d\u00e9crit : montage double<\/h3>\n
\n
6. Erreurs fr\u00e9quentes<\/h2>\n
\n
7. Check-list : revue du temps de cycle<\/h2>\n
\n
8. La structure logicielle rend tout cela possible<\/h2>\n
\n