Automotive Ethernet testen Methodologie zur Validierung der Kommunikationsfunktionen

Automotive Ethernet hält unausweichlich Einzug in Fahrzeuge aller Art.
Automotive Ethernet hält unausweichlich Einzug in Fahrzeuge aller Art.

Automotive Ethernet, mit BroadR-Reach als physikalischem Layer, hält unausweichlich Einzug in das Fahrzeug. Durch die Nutzung hochauflösender Kameras und die Implementierung von immer mehr Sensoren steigt die Anforderung an die Übertragung von großen Datenmengen.

Ethernet als Kommunikationsmedium ist bereits durch die Nutzung in der Telekommunikation und in der IT-Welt ein weit entwickelter Standard mit wenigen „Kinderkrankheiten“. Allerdings bringt es auch neue Herausforderungen in die Welt des Testens in der Automotive Industrie. Traditionelle Bussysteme wie CAN oder LIN stellen hohe Anforderungen im Bereich der Validierung des physikalischen Layers. Ist dieser zu 100 Prozent konform, arbeitet in der Regel die Kommunikation über die eher einfachen Protokolle weitestgehend einwandfrei. Eine Validierung der Applikationen, die den CAN-Bus nutzen, erfolgt in der Regel mit Data-Loggern und Restbussimulationen, um die Funktionen der Systeme zu überprüfen.

Ethernet erweitert die ECU mit einer neuen „funktionalen Applikation“, die neben den eigentlichen Funktionen der ECU, beispielsweise ADAS/Engine Control, auch die Teilsteuerung des Kommunikationsnetzwerkes übernimmt. Wobei anzumerken ist, dass der im Bild gezeigte Switch mit AVB/TSN Funtionen immer nur ein Teil der Gesamtarchitektur darstellt.

Was bedeutet dies für die funktionale Validierung der ECU oder des Systems unter Test? Natürlich ist der klassische Ansatz, die Kern-Systemfunktionen mit einer Restbus-Simulation zu überprüfen, weiterhin valide. Auch ein Aufzeichnen der Daten zur Analyse der Datenpakete ist weiterhin nötig. Neu ist allerdings, dass auch die Kommunikationsapplikation, der Switch mit der implementierten AVB/TSN Funktionalität, getestet werden muss. D. h. auch für den Kommunikations-Layer wird eine Art Restbussimulation benötigt, um diese Funktionen zu testen. Insbesondere ist das eine Herausforderung für den Tester, da er neben der zu erwartenden Kommunikation auch Fehlfunktionen im Netzwerk simulieren muss (Best & Worst Case Simulation). Je nach Entwicklungsstand ist ebenfalls die Konformität der implementierten Protokolle zu überprüfen, und auch die Validierung von Cyber-Security-Funktionen sollten Bestandteil des Test-Prozesses sein.

Eine weitere Frage ist, ob diese Switch-Validierung nur bei der Auswahl der entsprechenden Hard- und Software-Komponenten erfolgen muss, oder ob diese Funktionen nach jeder Neukonfiguration sowie in verschiedenen Entwicklungsstufen wiederholt werden müssen. Grundsätzlich kann man diese Frage nicht eindeutig beantworten, denn es kommt immer darauf an, wie die Gesamtarchitektur der ECU gestaltet ist, und/oder ob die ECU eine sicherheitsrelevante Funktion übernimmt. In der Regel werden in modernen ECUs Ressourcen wie CPU oder Speicherbausteine von verschiedenen Applikationen gemeinsam genutzt, wie auch im Beispiel gezeigt. D. h. eine Änderung der Kernfunktion hat auch indirekt Einfluss auf die Funktionen des Switches, da eventuell weniger Prozessorleistung oder Speicher zur Verfügung steht. Sollte die Switch-Applikation völlig autark arbeiten, ist eine kontinuierliche Überprüfung der Funktionen trotzdem ratsam.

Klassische Testmethoden sind bei der Integration von neuen Kommunikations-Technologien weiterhin nötig, allerdings müssen im Zuge der Einführung auch neue, der Technologie angepasste, Testmethoden hinzugefügt werden. Diese müssen dann in den entsprechenden Test-Spezifikationen festgelegt und in die vorhandenen Prozesse aufgenommen werden.