Hyundai Kefico standardisiert ECU-Produktionstests mit PXI-Hardware von NI

​Warum Testgeräte standardisieren? 

​Hyundai Kefico ist verantwortlich für Forschung, Entwicklung, Validierung und Produktion einer Reihe von Automobilelektronikkomponenten.  

​Da Fahrzeuge immer komplexer werden, müssen die von uns entwickelten Testgeräte höhere Datenmengen, mehr Kommunikationsprotokolle und strengere Zuverlässigkeitsanforderungen bewältigen. Diese Anforderung bedeutet, dass sich die Testteams nicht nur auf die Verifizierung auf Hardwareebene konzentrieren, sondern auch sicherstellen, dass unsere Testsysteme zunehmend integrierte und softwareorientierte ECUs unterstützen können. Es hat meine Rolle vorangetrieben, ein tieferes technisches Verständnis mit einer stärkeren Koordinierung zwischen den an Entwicklung und Produktion beteiligten Personen zu verbinden. 

​Darüber hinaus hat sich im Zuge der Weiterentwicklung der Fahrzeugantriebsstränge die Palette der Komponenten zur Unterstützung von Elektro-, Hybrid-, Brennstoffzellen- und Verbrennungsfahrzeugen sowie der Ladeinfrastruktur und der Karosseriesteuerungsmodule dramatisch erweitert. Diese Komplexität stellt Testteams vor eine Herausforderung, da jeder Produkttyp unterschiedliche funktionale Testverfahren erfordert, aber die dedizierte, produktspezifische Testausrüstungsentwicklung nicht skalierbar ist. 

​Vor diesem Hintergrund musste unser Team von Hyundai Kefico eine standardisierte Testarchitektur entwickeln, die folgende Anforderungen erfüllt:  

• ​Unterstützung mehrerer Produkttypen mit einem flexiblen Testsystem 

• ​Ingenieuren ermöglichen, Testverfahren einmal zu entwickeln 

• ​Diese Verfahren direkt auf Produktionsprüfgeräte anwenden 

​Ziel war es, die Ausführung zu standardisieren, Hardwareabhängigkeiten zu isolieren und die Testlogik produktspezifisch und dennoch geräteunabhängig zu halten. 

​Architekturanforderungen 

​Unsere wichtigsten Ziele für eine anpassungsfähige, wiederverwendbare Testsystemarchitektur waren: 

• ​Produkttypflexibilität—Unterstützt mehrere elektronische Fahrzeugkomponenten mit unterschiedlichen Testverfahren wie Fahrzeugsteuerung, Batteriemanagementsystem, elektrische Leistungsregelung, Wasserstoffversorgung, Motorsteuerung und Getriebesteuerung  

• ​Trennung von Bedenken – Entkoppelung der Entwicklung von Testverfahren und Testausrüstung 

• ​Direkte Anwendbarkeit—Ingenieureigene Testverfahren müssen auf Produktionsprüfgeräten ausgeführt werden. 

• ​Wiederverwendbarkeit – Testverfahren sollten produkt- und produktionsübergreifend wiederverwendbar sein 

   

​Herangehensweise  

​Wir entwarfen eine gemeinsame Plattform (CP) um drei zentrale Säulen (siehe Abbildung 1). 

• ​Skriptentwicklung—Ingenieure definieren Testmethoden, Sequenzen und Spezifikationen als standardisierte Testskripte 

• ​Zentrale Verwaltung—Testskripte werden zentral verwaltet und verteilt 

• ​Hardwareabstraktion – Produktionstestgeräte führen Skripte auf einer standardisierten Testplattform aus 

   

   

  

​Abbildung 1: Gemeinsames Plattform-Workflow-Konzept

​Die Testskriptschicht enthält ein standardisiertes Testskript zur Definition der produktspezifischen Testlogik: Testmethoden, Ausführungssequenzen, Spezifikationen und Kriterien. Diese Testlogik ist von der Konfiguration und Hardware der Testausrüstung entkoppelt (siehe Abbildung 2).

​Das Testausführungs-Framework dient als gemeinsame Ausführungs-Engine für alle Produkte. Dieses Framework interpretiert Testskripte, steuert den Ablauf der Testausführung, führt Messungen und Ergebnisauswertung durch und verwaltet Fehlerbehandlung und Protokollierung unabhängig vom Produkttyp. 

​Abbildung 2: Architektur des Test Execution Frameworks

​Schließlich bietet die Hardwareabstraktionsschicht standardisierte Steuerschnittstellen zwischen dem Testausführungs-Framework und physischer Hardware, unabhängig vom Gerätetyp oder Hersteller, wodurch dieselben Testskripte und das Ausführungs-Framework auf verschiedenen Hardwarekonfigurationen ausgeführt werden können (siehe Abbildung 3).

​Abbildung 3. Hardwareabstraktion

​Hardwareabstraktion ermöglicht Hardwareflexibilität ohne Unterbrechung der Teststandardisierung.

​Wir haben den PXI-basierten CP-Tester bereitgestellt, indem wir die Kernarchitektur standardisiert und die modulare Hardwarestruktur von PXI verwendet haben, was Konfigurationsänderungen wesentlich erleichtert hat. Die PXI-Plattform bot auch eine saubere Software-Schnittstellenschicht, so dass die Integration neuer Funktionen oder Protokolle nur minimale Umgestaltungen erforderte. Daher könnten wir große EV-Projekte unterstützen, indem wir dieselbe Architektur wiederverwenden und nur die notwendigen Module aktualisieren.

​Heute ist der CP-Tester im Einsatz, um eine Vielzahl elektronischer Steuergeräte in den Produktionsstätten von Hyundai Kefico durch mehrere Varianten dieser standardisierten Plattform zu testen. Um das Testen verschiedener ECU-Typen mit weniger als 200 Pins zu standardisieren, werden mehrere PXI-Matrixmodule von NI eingesetzt. In einer typischen Konfiguration sind zwei PXI-Chassis in einer Daisy-Chain-Topologie verbunden. Neben der Matrix bestehen die anderen Module aus modularen PXI-Geräten und rekonfigurierbaren Multifunktions-I/O-Modulen für PXI. In der folgenden Liste finden Sie einige Beispiel-Testkonfigurationen.

​CP: allgemeine Steuereinheit

• ​Prüflinge: Hauptsteuergeräte für den Antriebsstrang (ECU, TCU, PCU) und EV-Steuergeräte (VCU, SCU, CVMS und mehr)

• ​NI-PXI-Hardware: Matrixschalter, DMM, DAQ, SMU, CAN, variabler Widerstand

• ​Zusätzliche Hardware: Stromversorgung, Ersatzlasten, Funktionsgenerator

   

​CP: Wireless-RF-Fähigkeitstest

• ​Prüflinge: drahtlose BMU und CMU

• ​Hardware: Wireless Test System, Netzteil, F/Q-Debugger mit UART-Modul

   

​CP: Motorsteuergeräte

• ​NI-PXI-Hardware: Matrixschalter, DMM, DAQ, CAN, variabler Widerstand

   

​Wert und Auswirkung

​Vor der Verwendung der standardisierten PXI-basierten Hardware fühlte sich alles wie eine Blackbox an. Jeder Systemintegrator erstellte Tester anders; selbst die grundlegende Funktionsstandardisierung war schwierig und jedes Projekt begann von Grund auf neu. Ein gutes Beispiel ist der Matrixschalter. Vorher hatte jeder Anbieter eine andere Art, die Matrix zu erstellen, so dass sich das Routing inkonsistent anfühlte. Dadurch war es schwierig, auch einfache Funktionen zu standardisieren. Nach dem Übergang zum PXI-Matrixschalter wurden das Routing und das Kanalverhalten bei allen Testern gleich, so dass die Funktionsstandardisierung endlich einfach wurde.

​Der Wert der Standardisierung auf dem CP-Tester umfasst folgende Vorteile:

• ​Schnellere Verteilung für neue Produkte

• ​Schnelle Reaktion auf Änderungen an Testspezifikationen

• ​Reduzierte Abhängigkeit von produktspezifischen Testgeräten

• ​Verbesserte Wiederverwendbarkeit der Testlogik

• ​Klare Trennung von Testlogik, Ausführung und Hardware

   

​Nachdem sich die standardisierte Hard- und Software über mehrere Projekte hinweg als zuverlässig erwiesen hatte, wurde die Entwicklung viel einfacher und wir konnten uns auf den eigentlichen Test konzentrieren, anstatt jedes Mal ein neues System zu erstellen. Im Laufe der Zeit erkannten wir, dass Standardisierung kein einzelnes Objekt ist, sondern eine Kultur. Es ist ein lebendiges System, das kaputt geht, wenn wir es nicht ständig aktualisieren. Jetzt bleibt das gesamte Team also dabei, es in allen Projekten am Laufen zu halten und zu verbessern.

​Mit skalierbarer Hardware und klaren Testmethoden bin ich zuversichtlich, dass wir das bestehende System erweitern können. Daher konzentriere ich mich darauf, neue Anforderungen zu integrieren, ohne Probleme in der veralteten Architektur zu verursachen. Es verschob sich meine Einstellung vom Ersetzen des Setups zu kontrollierten, skalierbaren Möglichkeiten, es zu aktualisieren.