Hyundai Kefico standardise les tests en production ECU avec le matériel NI PXI
Points clés de l’étude de cas
Hyundai Kefico a réduit la dépendance du développement à l’égard des testeurs spécifiques aux produits en déployant une plate-forme PXI réutilisable pilotée par script sur plusieurs types d’ECU.
La plate-forme de test commune a permis un déploiement plus rapide pour les nouveaux produits grâce à une réponse rapide aux modifications des spécifications de test et à une réutilisation améliorée de la logique de test.
« Après être passé à une architecture NI PXI unifiée, le matériel et les logiciels sont devenus cohérents entre les projets, et beaucoup de ces incertitudes ont disparu. Nous pouvons maintenant nous concentrer sur les exigences de test au lieu de nous occuper des différences entre systèmes. »
Win-Kyung HAM, Ph.D., Manufacturing Engineering Team 1, Hyundai Kefico
Le défi
L’électronique complexe des véhicules nécessite des interactions matérielles, logicielles et d’interface de communication croissantes sur une large gamme d’ECU. Il ne suffit plus de tester les composants indépendamment, nous devons nous assurer que le système se comporte de manière cohérente dans de nombreux cas périphériques. Le défi n’est pas seulement la complexité technique, mais aussi la stabilité de l’architecture de test pendant que le produit évolue rapidement.
La solution
Un système de test commun permet à une plate-forme unique de tester de nombreux produits grâce à une flexibilité pilotée par script. En construisant un système de test fonctionnel générique et évolutif, Hyundai Kefico a standardisé la manière dont les procédures de test sont définies, exécutées et maintenues, réduisant ainsi la dépendance à l’égard des testeurs spécifiques aux produits et améliorant l’efficacité du développement et l’évolutivité de la production.
Pourquoi standardiser les équipements de test ?
Hyundai Kefico est responsable de la recherche, du développement, de la validation et de la production d’une gamme de composants électroniques automobiles.
Alors que les véhicules deviennent plus complexes, les équipements de test que nous développons doivent gérer des volumes de données plus élevés, davantage de protocoles de communication et des exigences de fiabilité plus strictes. Cette exigence signifie que les équipes de test en production se concentrent non seulement sur la vérification au niveau matériel, mais également sur la garantie que nos systèmes de test peuvent supporter des ECU de plus en plus intégrées et logicielles. Cela a poussé mon rôle à combiner une compréhension technique plus approfondie avec une coordination plus étroite entre les personnes impliquées dans le développement et la production.
De plus, à mesure que les groupes motopropulseurs des véhicules évoluent, la gamme des composants requis pour supporter les véhicules électriques, hybrides, à pile à combustible et à combustion, sans oublier les infrastructures de charge et les modules de contrôle de la carrosserie, s’est considérablement étendue. Cette complexité crée un défi pour les équipes de test car chaque type de produit nécessite des procédures de test fonctionnelles différentes, mais le développement d’équipements de test spécifiques au produit n’est pas évolutif.
Dans ce contexte, notre équipe de Hyundai Kefico devait concevoir une architecture de test standardisée capable de répondre aux exigences suivantes :
Support de plusieurs types de produits avec un système de test flexible
Permettre aux ingénieurs de développer des procédures de test une fois
Appliquer directement ces procédures aux équipements de test en production
L’objectif était de standardiser l’exécution, d’isoler les dépendances matérielles et de garder une logique de test spécifique au produit tout en étant indépendante de l’équipement.
Spécifications de l'architecture
Nos objectifs clés pour une architecture de système de test adaptable et réutilisable comprenaient :
Flexibilité du type de produit : supporte plusieurs composants électroniques automobiles avec différentes procédures de test telles que le système de contrôle du véhicule, le système de gestion de la batterie, le contrôle de l’alimentation électrique, le système d’alimentation en hydrogène, l’unité de contrôle du moteur et le contrôle de la transmission
Séparation des préoccupations — Dissocier le développement des procédures de test du matériel des équipements de test
Applicabilité directe : les procédures de test développées par l’ingénieur doivent s’exécuter telles quelles sur les équipements de test en production
Réutilisabilité — Les procédures de test doivent être réutilisables pour tous les produits et toutes les lignes de production
Approche
Nous avons conçu une plate-forme commune (PC) autour de trois piliers centraux, comme le montre la figure 1 :
Développement de scripts — Les ingénieurs définissent les méthodes de test, les séquences et les spécifications comme des scripts de test standardisés
Gestion centralisée : les scripts de test sont gérés et distribués de manière centralisée
Abstraction matérielle : l’équipement de test en production exécute des scripts sur une plate-forme de test standardisée
Figure 1. Concept commun de flux de travail de plate-forme
La couche script de test fournit un script de test standardisé pour définir la logique de test spécifique au produit : méthodes de test, séquences d’exécution, spécifications et critères. Cette logique de test est dissociée de la configuration et du matériel de test, comme le montre la figure 2.
Le framework d’exécution de test sert de moteur d’exécution commun partagé entre tous les produits. Ce framework interprète les scripts de test, contrôle le flux d’exécution des tests, gère les mesures et l’évaluation des résultats, et gère la gestion des erreurs et l’enregistrement, le tout indépendamment du type de produit.
Figure 2. Architecture du framework d’exécution de test
Enfin, la couche d’abstraction matérielle fournit des interfaces de contrôle standardisées entre le framework d’exécution de test et le matériel physique, quel que soit le type de périphérique ou le fournisseur, permettant aux mêmes scripts de test et framework d’exécution de s’exécuter sur différentes configurations matérielles, comme le montre la figure 3.
Figure 3. Abstraction matérielle
L’abstraction matérielle permet une flexibilité matérielle sans rompre la standardisation des tests.
Nous avons déployé le CP-Tester basé sur PXI en standardisant l’architecture de base et en utilisant la structure matérielle modulaire du PXI, ce qui a rendu les changements de configuration beaucoup plus faciles. La plate-forme PXI offrait également une couche d’interface logicielle propre, de sorte que l’intégration de nouvelles fonctions ou protocoles nécessitait une refonte minimale. Par conséquent, nous avons pu soutenir des projets de véhicules électriques majeurs en réutilisant la même architecture et en ne mettant à jour que les modules nécessaires.
Aujourd’hui, le CP-Tester teste une large gamme d’unités de contrôle électronique dans les sites de production de Hyundai Kefico via plusieurs variantes de cette plate-forme standardisée. Pour standardiser le test de divers types d’ECU avec moins de 200 broches, plusieurs modules matriciels NI PXI sont largement utilisés. Dans une configuration typique, deux châssis PXI sont connectés dans une topologie en série. Outre la matrice, les autres modules sont constitués d’instruments modulaires PXI et de modules PXI d'E/S reconfigurables multifonctions. La liste suivante fournit des exemples de configurations de testeur.
CP : unité de contrôle générale
DUT: principales unités de contrôle du groupe motopropulseur (ECU, TCU, PCU) et unités de contrôle des véhicules électriques (VCU, SCU, CVMS, etc.)
Matériel NI PXI: matrices de commutation, DMM, DAQ, SMU, CAN, résistance variable
Matériel supplémentaire: alimentation, charges factices, générateur de fonctions
CP : test de capacité RF sans fil
DUT : BMU et CMU sans fil
Matériel: Système de test sans fil, alimentation, débogueur F/Q avec module UART
CP: unités de commande moteur
Matériel NI PXI: matrice switch, DMM, DAQ, CAN, résistance variable
Valeur et impact
Avant d’utiliser le matériel standardisé basé sur PXI, tout ressemblait à une boîte noire. Chaque intégrateur de système a construit des testeurs différemment ; même la standardisation des fonctions de base était difficile, et chaque projet partait de zéro. Un bon exemple est le commutateur matriciel. Avant, chaque fournisseur avait une façon différente de construire la matrice, donc le routage semblait incohérent. Il était difficile de standardiser des fonctions simples. Après le passage au commutateur matriciel PXI, le routage et le comportement des voies sont devenus identiques pour tous les testeurs, de sorte que la standardisation des fonctions est finalement devenue simple.
La valeur de la normalisation sur le CP-Tester comprend les avantages suivants :
Déploiement plus rapide pour les nouveaux produits
Réponse rapide aux modifications des spécifications de test
Réduction de la dépendance aux équipements de test spécifiques aux produits
Réutilisation améliorée de la logique de test
Séparation claire de la logique de test, de l’exécution et du matériel
Après que le matériel et les logiciels standardisés se sont avérés fiables pour plusieurs projets, le développement est devenu beaucoup plus facile et nous avons pu nous concentrer sur le test réel au lieu de construire un nouveau système à chaque fois. Au fil du temps, nous avons réalisé que la standardisation n’est pas un objet unique, c’est une culture. C’est un système vivant qui se brise si nous ne continuons pas à le mettre à jour. Maintenant, toute l’équipe reste impliquée pour continuer à fonctionner et à s’améliorer dans tous les projets.
Avec un matériel évolutif et des méthodes de test claires, je suis convaincu que nous pouvons étendre le système existant, je me concentre donc sur la manière d’intégrer de nouvelles exigences sans causer de problèmes dans l’ancienne architecture. Mon état d’esprit est passé du remplacement de la configuration à la recherche de moyens contrôlés et évolutifs de la mettre à niveau.