Test der CAN-, LIN- und FlexRay-Netzwerkeigenschaften von Steuergeräten

Transkript

1 Test der CAN-, LIN- und FlexRay-Netzwerkeigenschaften von Steuergeräten Voraussetzung für die Gewährleistung der Funktionssicherheit von Bussystemen im Kraftfahrzeug Dipl.-Ing. Manfred Schneider, GÖPEL electronic GmbH, Jena, Dipl.-Ing. Jens Münzberg, GÖPEL electronic GmbH, Jena Einleitung Elektronische Steuergeräte sind im Kraftfahrzeug über Kommunikationsschnittstellen miteinander vernetzt. Ein Steuergerät empfängt dabei Informationen anderer Systemkomponenten, die es für seine eigene Funktion benötigt, z.b. die aktuelle Geschwindigkeit oder Motordrehzahl. In umgekehrter Richtung legt das Steuergerät Daten zum eigenen Status auf das Netz, die von anderen Steuergeräten empfangen und ausgewertet werden. Die weiteste Verbreitung bei der Realisierung von Datennetzen im Fahrzeug genießt nach wie vor der CAN-Bus. Aufgrund der kontinuierlichen Zunahme der Anzahl an Steuergeräten im Fahrzeug haben mittlerweile weitere Bussysteme ihren Weg ins Fahrzeug gefunden. Der LIN-Bus zum Beispiel stellt Subsystem zur CAN-Vernetzung dar und reduziert die Buslast des übergeordneten CAN-Netzes, gleichzeitig ist er auch ökonomisch günstiger realisierbar. Die FlexRay-Kommunikation zwischen den Steuergeräten sich hat besonders bei sicherheitskritischen Applikationen wie Drive-By-Wire durchgesetzt. All die verschiedenen Netzwerke in Fahrzeugen sind über Gateways miteinander verbunden, weshalb besondere Testszenarien bzgl. Routing und Übertragungszeiten vonnöten sind.

2 Abb.1: Funktionstestsystem für die Prüfung von Netzwerkeigenschaften von Steuergeräten In den einzelnen Phasen ihrer Entwicklung und Fertigung, wie Prototyping, Manufacturing, Run-In und Zuverlässigkeitsprüfungen, werden die Steuergeräte Funktionstests unterzogen. Dabei wird das einzelne Steuergerät in eine vom Testsystem simulierte Fahrzeugumgebung eingebunden. Geprüft wird typischerweise die applikative Funktion des Steuergerätes, mit der das Gerät die ihm zugeordnete Steuer- und Regelaufgabe im Fahrzeug realisiert. Der applikativen Funktion eines Steuergerätes steht die Systemfunktion gegenüber, welche für die Fahrzeugsicherheit von immenser Bedeutung ist. Das Steuergerät muss in der Lage sein, unter allen Betriebszuständen spezifikationsgerecht zu senden und zu empfangen. Es muss außerdem gewährleistet sein, dass das Steuergerät, sobald es sich am Bus befindet, die Kommunikation innerhalb der Fahrzeugumgebung nicht beeinträchtigt bzw. dass es bei gestörter Kommunikation keine unkontrollierten Reaktionen ausführt. Die Systemeigenschaften eines Steuergerätes lassen sich in physikalische Eigenschaften und in Kommunikationseigenschaften unterteilen. Zur Messung der physikalischen Eigenschaften arbeitet das System offen, d.h. ohne Einbindung in das Netzwerk, während zum Test der Kommunikationseigenschaften die Simulation der Fahrzeugumgebung über ein oder mehrere Busknoten erforderlich ist. 2

3 Als dritte Gruppe von Prüfaufgaben ist die Fehlersimulation zu erwähnen, welche hardwaremäßige Störungen (Kurzschlüsse und Unterbrechungen) sowie per Software zu realisierende Fehler des Kommunikationsprotokolls beinhaltet. Anforderungen an die Systemarchitektur Die Systemarchitektur eines Testsystems für diese Anforderungen geht stets mit den aktuellen Entwicklungen im Bereich Kfz-Elektronik und unterstützten Busprotokollen einher. Waren vor ca. 15 Jahren die Unterstützung für Highspeed- und Lowspeed-CAN, CAN- Transportprotokoll oder Diagnose über CAN (KWP 2000) erforderlich, wurde in späteren modularen Ausbaustufen der Test von K-Leitungsfunktionen und LIN-Bussystemen aktuell. Heute muss ein entsprechendes System Applikationen wie Netzwerkmanagement, Subnetzwerk-Prozesse oder Gateway-Tests abdecken. Da es in der Automobilbranche je nach Kfz-Hersteller und Kfz-Typ sehr große Varianten gibt, sind Konzernlastenheften der Automobilhersteller notwendig, welche Busprotokolle und die physikalischen Randbedingungen im Fahrzeug definieren. Daraus werden zunächst individuelle Prüfvorschriften abgeleitet. Diese Spezifikationen legen Funktion und Inhalt der einzelnen Testschritte fest, sie definieren das erforderliche Stimuliregime und die aufzunehmenden Messgrößen mit den entsprechenden Genauigkeitsforderungen. Durch Aufstellung einer Realisierbarkeitsmatrix wird dabei sichergestellt, dass die konzipierte Testerkonfiguration den außerordentlich komplexen Prüfanforderungen gerecht wird. Aus dem Umfang zu realisierender Prüfaufgaben leitet sich eine Anzahl zwingend notwendiger Komponenten demnach die Grundkonfiguration des Testers für die Prüfung von Netzwerkeigenschaften ab. Beispielhaft seien hier genannt: Oszilloskop- und Multimeterfunktionen für die elektronische Messungen CAN-Schnittstellen dabei muss die Softwareunterstützung messende Funktionen sowie die Erzeugung fehlerhafter Protokolle zulassen Restbussimulation für jedes Steuergerät Programmierbare und erweiterbare Prüflingsstromversorgung Baugruppe zur Simulation von Leitungsfehlern Diagnoseschnittstelle zur Auswertung des internen Fehlerspeichers des Prüflings Die Kommunikation über den LIN-Bus und den FlexRay-Bus haben sich mittlerweile zu wesentlichen Bestandteilen in modernen Fahrzeugen entwickelt. Ihre Testabdeckung bedingt weitere intelligente Schnittstellenbaugruppen, welche speziell für den entsprechenden Anwendungsfall entwickelt wurden. Ein LIN-Bus-Controller aus der Serie 61 von GÖPEL electronic, zum Beispiel, verfügt über drei aktive LIN-Interfaces und ist damit in der Lage, alle laut LIN-Protokoll möglichen Netzwerkzustände zu simulieren. Der entsprechende FlexRay-Controller dieser Serie stellt zwei unabhängige FlexRay-Interfaces bereit, wobei jede mit einem A- und B-Kanal ausgestattet ist. 3

4 In der Regel lässt sich zwar ein Großteil applikativer Funktionen des Steuergerätes über die Diagnoseschnittstelle simulieren, die bereits Bestandteil der Grundkonfiguration des Testsystems sein sollte; praktisch muss das Testsystem jedoch zumindest eine Standardschnittstelle für die Einbindung projektspezifischer Testressourcen zur Verfügung stellen. Diese Anforderung besteht für Hard- und Software des Systems gleichermaßen. Hardwarekonfiguration Ein Beispiel für die Umsetzung dieser Anforderungen stellt der Netzwerktester von GÖPEL electronic dar. Kernstück der Systemarchitektur ist ein PXI Mess- und Stimulikomplex, der mit Ausnahme der Prüflingsstromversorgung, der CAN-Restbussimulation und der CANstress- Baugruppen für die Fehlersimulation alle Mess- und Stimulikomponenten aufnimmt. Die Entscheidung für den PXI-Standard beruhte neben dem kompakten Aufbau vor allem darauf, dass im Rahmen einer bereits existierenden Produktlinie (Modulares Funktionstestsystem für Kfz-Steuergeräte) ein geeignetes Spektrum von Stimuligeräten zur Verfügung steht. Dazu gehören Generatoren und I/O-Baugruppen, die speziell für die Simulation typischer Signalverläufe im Fahrwerks-, Antriebs- und Ausstattungsbereich ausgelegt sind. Auch die im Testsystem verwendeten CAN-Baugruppen stammen aus der Serie 61, einer PXI- Modulfamilie zur Bus-Kommunikation. Abb.2: Kommunikations-Controller der Serie 61 für CAN, LIN und FlexRay Als weitere Messgeräte sind in der Grundkonfiguration des Testsystems Arbitrarygenerator, Multimeter und Oszilloskop als Standardmessgeräte für physikalische Messungen enthalten. Da Antriebs- und Komfort-CAN parallel verfügbar sein müssen (zum Test von Steuergeräten mit Gatewayfunktionen), ist es erforderlich, die Messgeräte mittels Relaisbaugruppen auf unterschiedliche Messpunkte umzuschalten. 4

5 Die Prüflingsstromversorgung besteht aus zwei getrennt geregelten SV-Einheiten, um Masseoffset herbeiführen zu können. Die Ansteuerung erfolgt über ein Ethernet-Interface. Der Prüfling wird über ein universelles Panel angeschlossen, das neben dem Steckverbinder für den Prüflingsanschluss über parallel geschaltete Steckverbinder für den Anschluss weiterer Originalsteuergeräte, Monitorbuchsen für CAN, LIN und Diagnose sowie Messbuchsen für externe Messgeräte oder Lastaufschaltungen verfügt. Systemsoftware Für die Konzeption der Bedienersoftware ist die Forderung des Anwenders ausschlaggebend, am Testsystem sowohl einzelne, interaktive Tests durchzuführen, als auch komplexe Prüfprogramme als automatisierte Tests ablaufen zu lassen. Dabei sollte der Aufwand bei der Steuergeräte-Testprogrammentwicklung optimiert werden, beispielsweise durch eine spezielle Automatisierungsmethode, die unabhängig alle notwendigen Testparameter aus der Datenbank des Automobilherstellers generiert (etwa in den Formaten dbc, ldf oder Fibex). Abb.3: Architektur der Systemsoftware Im Falle des Netzwerktesters von GÖPEL electronic wurden Bedienoberfläche und Testablaufsteuerung auf Basis einer Testsequenzer Software realisiert, die als Add-On-Tool zu LabVIEW entwickelt wurde und bereits seit mehreren Jahren erfolgreich für die Realisierung von Testsystemen im Entwicklungs- und Fertigungsbereich eingesetzt wird. Die Blockstruktur dieser Systemsoftware ist in Abbildung 3 dargestellt. Der Testsequenzer ermöglicht die Erstellung von Anwenderprogrammen durch Auswahl und Parametrierung vorgefertigter Einzeltestschritte, die aus einer Makrobibliothek abgerufen und zu einem kompletten Prüfprogramm zusammengestellt werden können. Die Anpassung an die spezifische Messaufgabe erfolgt durch einfache Parametrierung, dazu verfügt jedes Makro 5

6 über eine graphische Eingabeoberfläche. Die Abbildungen 4 und 5 zeigen Beispiele für die Bedienoberfläche des Prüfprogrammeditors sowie Makrooberflächen für spezielle CAN- Funktionen. Ein signifikanter Vorteil dieses Ansatzes liegt darin, dass der Anwender den Fokus auf die physikalischen Aspekte legen kann und sich nicht mit den Algorithmus-Details dahinter befassen muss. Abb. 4: Hauptmenü des Prüfprogrammeditors Die Makrobibliothek kann modular entsprechend den Anwender-Anforderungen erweitert werden. Beispiele hierfür sind die Verfügbarkeit von Testschritt-Bibliotheken für CAN, LIN und FlexRay Diagnose- und Netzwerkmanagement. Abb.5 Beispiele für Parametrieroberflächen einzelner Makrofunktionen 6

7 Weitere Bestandteile der Testsequenzer-Software sind ein Debugger für die Inbetriebnahme und schrittweise Abarbeitung von Testprogrammen sowie ein Run-Modul für automatisierte Prüfabläufe. Jeder von der Ablaufsteuerung ausgeführte Prüfschritt liefert eine Pass-/Fail- Aussage, die Bewertung numerischer Messergebnisse nach parametrierbaren Toleranzgrenzen erfolgt innerhalb der Makros. Die Ergebnisse werden in ein Prüfprotokoll eingetragen, das den gesamten Testablauf für den jeweiligen Prüfling umfasst. Die Protokollierung der Testergebnisse erfolgt im HTML- oder XML-Format, welches Links zu Messwertetabellen oder mittels Oszilloskop aufgenommenen Screenshots ermöglicht. Praktische Erfahrungen beim Einsatz des Funktionstestsystems für Netzwerkeigenschaften Aus Anwendersicht haben sich durch die Einführung des automatisierten Prüfstandes für den Test der CAN-Netzwerkeigenschaften folgende wesentlichen Arbeitsergebnisse herausgestellt: Reduzierung des Testzeitbedarfes gegenüber der laborativen Prüfung auf weniger als ein Drittel Das Testsystem ermöglicht die Erfassung und Auswertung zeitsynchroner Abläufe im Zeitraster kleiner 1 ms Durch verschiedene Kfz-Bus- und Diagnosefunktionen innerhalb des Testsystems können spezielle Prüfungen realisiert werden, deren Ausführung bislang nicht möglich waren Durch die modulare Architektur des Netzwerktesters hat der Anwender die Möglichkeit, das System seinen Anforderungen gemäß für mehrere Kommunikationsschnittstellen aufzurüsten. Diese Option dient nicht nur der Einsparung von Investmitteln, sondern ermöglicht in erster Linie die Prüfung von Gateway-Funktionen zwischen unterschiedlichen Kommunikationsnetzen. Zur Realisierung einer einheitlichen Zeitbasis wird dabei auf die vom PXI-Bus gebotenen Trigger- und Synchronisationsmöglichkeiten zwischen den Interfacebaugruppen zurückgegriffen. Die wichtigste Erkenntnis, die aus dem Einsatz des Netzwerktesters gezogen wurde, sollte Fahrzeug- und Steuergerätehersteller gleichermaßen sehr nachdenklich stimmen: Nahezu 100% aller getesteten Steuergeräte weisen Mängel bei der Umsetzung der jeweiligen Busspezifikation auf! Aus diesem alarmierenden Fazit leitet sich die unabdingbare Forderung ab, den Netzwerktest bereits in der Designphase von Steuergeräten als Bestandteil des Qualitätsmanagements zu etablieren. Mögen Kommunikationsfehler im Komfortbereich sich im Endeffekt nur als ärgerliche oder lästige Fehlfunktionen äußern, im Hinblick auf den bevorstehenden 7

8 Durchbruch bei Drive-By-Wire Systemen ist die Einführung entsprechender Teststrategien absolut unumgänglich. Die Autoren: Manfred Schneider (geb. 1953) studierte von 1971 bis 1975 Nachrichtentechnik an der Technischen Universität Ilmenau. Seine berufliche Karriere begann im Forschungszentrum von Carl Zeiss Jena im Bereich Technologische Entwicklung, danach als Hardware-Entwickler im Bereich Hybridbauelemente war Manfred Schneider Mitgründer der GÖPEL electronic GmbH, deren Geschäftsbereich Automotive Test Solutions er als geschäftsführender Gesellschafter leitet. Jens Münzberg (geb 1966) studierte Informatik an der Technischen Universität Ilmenau von 1987 bis Im Jahr 1993 begann er seine Tätigkeit bei GÖPEL electronic als Software- Entwickler. In den späten 1990er Jahren übernahm er die Leitung des Teams Bus- Kommunikation, Diagnose und Netzwerkmanagement in der Abteilung Automotive Test Solutions. Jens Münzberg ist heute Senior Manager dieses Teams. 8