Test von Steuergeräten
Simulierte Fahrzeugnetzwerke
Der immerhin überschaubaren Anzahl von Bussystemen zur Steuergerätevernetzung in Kraftfahrzeugen steht trotz aller Bestrebungen zur Standardisierung eine Flut unterschiedlicher Kommunikationsprotokolle und Funktions-umfänge gegenüber. Will ein Entwicklungs- oder Prüfingenieur ein Steuergerät für Testzwecke über seine Kommunikationsschnittstelle ansprechen, so besteht seine größte Schwierigkeit darin, eine den realen Verhältnissen im Fahrzeug entsprechende Steuergerätekommunikation zu simulieren.
Der Prüfingenieur hat nicht nur die Kommunikationsumfänge im Auge zu behalten, welche die eigentliche Funktion seines Steuergerätes betreffen, sondern muss zusätzliche Anforderungen wie Netzwerk-management oder Komponentenschutz berücksichtigen, ohne deren vorbildgetreue Simulation das Steuergerät nicht die gewünschte Funktion ausführen wird.
Dieses Problem stand bei der Entwicklung der Softwaresuite »Net2Run« (Bild 1) im Vordergrund, die dem Anwender eine vollständige, mit Datenbankunterstützung generierte Restbussimulation für sein Steuergerät zur Verfügung stellt. Dabei wurde der AUTOSAR-Ansatz eines einheitlichen Signalzugriffs sowie das PDU-Konzept (PDU = Protocol Data Unit) für den CAN-, LIN- und FlexRay-Bus umgesetzt. Die Software unterstützt die Kommunikationscontroller der aktuellen »Serie 61« von Göpel, die je nach Ausstattungsvariante mehrere CAN-, LIN- und FlexRay-Schnittstellen bereitstellen.
Erzeugen einer Restbussimulation
Um eine signalbasierte Restbussimulation zu konfigurieren, ist im ersten Schritt die Auswahl der Datenbank notwendig, die alle Informationen zu den in einem Netzwerk verbundenen Steuergeräten enthält. Net2Run unterstützt CANdb-, LIN- und Fibex-Datenbanken (.dbc, .ldf, .xml). Die Software nutzt intern das aktuellste Fibex-Datenformat, deshalb konvertiert sie dbc- und ldf-Files automatisch in entsprechende Fibex-Dateien. Der Bediener wählt die für seinen Steuergerätetest relevanten Datenbanken aus und übernimmt diese in sein aktuelles Projekt.
Jobangebote+ passend zum Thema
Da ein Steuergerät über mehrere Schnittstellen verfügen kann, die in unterschiedliche Fahrzeugnetze eingebunden sind (etwa Gateway-Steuergeräte oder Kombiinstrumente), können mehrere Datenbanken parallel geladen werden. Danach durchsucht der Anwender das importierte Netzwerk nach den für ihn interessanten zu testenden Steuergeräten und zieht diese per Drag&Drop in das Projektfenster.
Der Net2Run-Konfigurator (Bild 2) erkennt automatisch die für das Steuergerät relevanten Botschaften und erstellt eine vollständige Restbussimulation für die zu untersuchende Baugruppe, hierbei werden alle zyklischen und sporadischen Sende- und Empfangsbotschaften des Steuergerätes aus der Datenbank herausgesucht und mit den dafür hinterlegten Defaultwerten parametriert. Abhängig davon, ob die komplette Steuergeräteumgebung oder nur einzelne Botschaften beziehungsweise Signale zu simulieren sind, erfolgt im Projektfenster eine entsprechende Auswahl.
Nun ist lediglich noch eine Zuordnung der Botschaften zu der gewünschten Hardwareschnittstelle des Kommunikationscontrollers vorzunehmen (Bild 3), woraufhin der Anwender die Erzeugung der Restbussimulation starten kann. Botschaftenzähler und Checksummenberechnungen werden dabei automatisch eingefügt. Die Modelle zur Checksummenberechnung sind in einer C-Bibliothek hinterlegt und werden über entsprechende Namensattribute zugewiesen. Darüber hinaus kann der Benutzer eigene Checksummenmodelle in Form von C-Bibliotheken hinzufügen.
Die Software stellt hierfür ein entsprechendes C-Template bereit. Benutzerspezifische Restbussimulationen sowie Variantenanpassungen lassen sich mit geringem Aufwand durch Hinzufügen oder Entfernen von einzelnen Frames beziehungsweise Signalen erzeugen. Der Anwender kann durch Aufklappen der in Form einer Baumstruktur dargestellten Datenbank bis auf Signalebene vordringen und dem Projekt einzelne Frames, PDUs oder Signale hinzufügen, bereits enthaltene Elemente herauslöschen oder Eigenschaften im »Properties«-Fenster editieren. Damit hat der Anwender alle notwendigen Schritte abgearbeitet, um zu einer den realen Verhältnissen im Fahrzeug entsprechenden, vollständigen und funktionsfähigen Testumgebung für sein zu untersuchendes Steuergerät zu kommen.
Unterstützung der AUTOSAR-PDUs
Die voranschreitende Standardisie-rung von Fahrzeugsteuergeräte-Software und -Softwarekomponen-ten im Rahmen der AUTOSAR-Entwicklungspartnerschaft (AUTomotive Open System ARchitecture) bringt veränderte Anforderungen an das Testsystem mit sich. Um diesen Anforderungen Rechnung zu tragen, hat Göpel bei der Entwicklung von Net2Run besonderes Augenmerk auf die Unterstützung der im Standard beschriebenen Kommunikationsmechanismen und Protokolle gelegt.
Net2Run unterstützt das Konzept der PDUs (Protocol Data Units), wie es in AUTOSAR Anwendung findet. Dieses Konzept erlaubt es, Datenpakete zwischen verteilten Applikationen auszutauschen, ohne dass die Applikation hierzu Kenntnisse des verwendeten Bussystems benötigt. Der Kommunikationsstack übernimmt hierbei das Packen beziehungsweise Entpacken der Datenpakete in busspezifische Botschaften. Hierzu verfügt die Firmware über einen PDU-Router, der als Bindeglied zwischen der Vermittlungsschicht (Data-Link-Layer) und der Anwendungsschicht (Interaction Layer) fungiert. Die Information, welches Datenpaket in welcher Botschaft enthalten ist, ist in der Fibex-Datenbank hinterlegt und wird vom Net2Run-Konfigurator automatisch konfiguriert.
Ein weiterer Baustein der Firmware ist der PDU-Multiplexer (Bild 4), dieser ermöglicht es, dynamisch verschiedene Datenpakete innerhalb einer Botschaft zu übertragen. Hierzu wird ein Bitvektor im statischen Segment der Botschaft definiert, dessen Wert die Stellung des Multiplexers und damit die im dynamischen Teil zu übertragende PDU festlegt. Das FlexRay-Bussystem erlaubt es, bis zu 254 Byte an Nutzdaten in einer einzelnen Botschaft zu übertragen. Sollen in heterogenen Bordnetzen die PDUs in der Anwendungsschicht vom verwendeten Bussystem unabhängig bleiben, darf die von CAN bekannte Nutzdatenlänge von 8 Byte nicht überschritten werden. Daher ist es zweckmäßig, eine FlexRay-Botschaft in mehrere PDUs zu unterteilen.
Diese Segmentierung hat den Nebeneffekt, dass bei erfolgter Änderung eines einzelnen Signals alle enthaltenen PDUs in einen temporären Speicher kopiert und anschließend die gesamte Botschaft gesendet werden muss. Auf der Empfangsseite müssen dann umgekehrt alle in der Botschaft enthaltenen PDUs aktualisiert und an die zugehörige Applikation übergeben werden. Dies belastet den Kommunikationsstack unnötig mit dem Kopieren unveränderter Botschaftsinhalte und deren erneuter Auswertung.
Um diese »Blindleistung« zu verringern, führte AUTOSAR das Konzept der Update-Bits ein. Hierbei teilt der Sender einer PDU durch Setzen des zugehörigen Update-Bits dem Empfänger mit, dass der Daten-inhalt der PDU aktualisiert wurde. Entsprechend werden PDUs, deren Update-Bit nicht gesetzt wurde, auch nicht ausgewertet. Enthält die Fibex-Datenbank für das zu testende Steuergerät Update-Bit-Informationen, so erkennt dies der Net2Run-Konfigurator und konfiguriert die Net2Run-Firmware entsprechend. Unterstützt das zu testende Steuergerät keine Update-Bits, so werden wie gehabt alle in der Botschaft enthaltenen PDUs aktualisiert.
Manipulation von Signalen
In einer auf die beschriebene Art und Weise generierten Restbus-simulation fehlt dem Anwender bislang noch die Möglichkeit, Signale während des Programmablaufes aus seinem Applikationsprogramm beziehungsweise seiner Testautomatisierung heraus aktiv zu beeinflussen, sprich veränderbare Botschaftsinhalte (beispielsweise Sensor-Istwerte) zu generieren. Dazu stellt ihm der Konfigurator ein Signalfenster bereit, in das der Anwender per Drag&Drop alle Signale hineinziehen kann, die während des Programmlaufes veränderbar sein sollen.
Zur besseren Orientierung stellt die Bedienoberfläche die Signaleigenschaften und das Layout des dazugehörigen Frames dar. Die in die Signalliste aufgenommenen Signale lassen sich nun zur Laufzeit der Restbussimulation über Göpels C-API (G-API) lesen beziehungsweise schreiben. Hierbei kann sowohl auf den physikalischen als auch den Rohwert des Signals zugegriffen werden. Darüber hinaus lassen sich Signalwerte auch direkt aus der Bedienoberfläche heraus ändern, hierzu steht ein entsprechendes »Signal-Panel« bereit.
Die G-API benutzt symbolische Sig-nalnamen, die der Anwender in der Signalliste ändern kann. Die G-API-Befehle lassen sich On-Board auf der Karte beziehungsweise auf dem Host-Rechner unter Windows nutzen. Bei der G-API handelt es sich um eine C-API, die direkt in C/C++-Programme eingebunden werden kann. Hierzu stehen Beispiele für »Visual Studio« und »LabWindowsCVI« bereit.
Für den Einsatz unter »Labview« steht dem Anwender eine entsprechende VI-Bibliothek zur Verfügung. Der in Net2Run integrierte »Gateway Editor« unterstützt die Konfiguration eines Multibus-Gateways mittels vom Bussystem unabhängigen Routings auf PDU- und Signalebene. Neben einfachen 1:1-Mappings von PDUs und Signalen unterstützt der Gateway-Editor die Umrechnung von Signalwerten mittels vordefinierter Transferfunktionen.
Zur Konfiguration werden Routingtabellen erstellt, in denen der Benutzer Quell- und Zielsignal aus der vorhandenen Signalliste auswählt, die Triggerbedingung festlegt und die gewünschte Transferfunktion selektiert und gegebenenfalls erforderliche Umrechnungsparameter wie Skalierung, Offset oder Wertebereich angibt.
Anwenderprogramme erstellen
Sind in der Fibex-Datenbank bereits Gateway-Mappings vorhanden, so lassen sich diese direkt ins Projekt übernehmen. Die Möglichkeit, Applikationsprogramme mit zeitkritischen Anforderungen an die Steuergerätekommunikation unabhängig vom PC unter Echtzeitbedingungen abarbeiten zu können, stellte auch die Motivation dar, die Software-suite mit einer kompletten Toolkette (»Net2Run IDE«, Bild 5) für die Erstellung von On-Board-Anwenderprogrammen auszustatten.
Die IDE basiert auf der Entwicklungsumgebung »Eclipse« und bietet mit den »Neutrino Command Line Tools« von QNX eine vollwertige C/C++-Cross-Development-Plattform für Göpels Kommunikationscontroller der Serie »61«. Der Zugriff auf die Kommunikationsroutinen und IO-Funktionen der Hardware erfolgt über die G-API-Funktionen. So lassen sich bereits bestehende Windows-Prüfprogramme mit geringem Aufwand für die On-Board-Programmierung portieren.
Mittels Ethernetverbindung und Remote-Debug-Dienst der Serie 61 lassen sich die erstellten Programme direkt aus der Net2Run-IDE heraus debuggen. Anschließend lassen sich die Programme im Flash-Dateisystem der Hardware ablegen und können entweder mittels Autostartfunktion automatisch ausgeführt oder über die G-API vom Host-PC aus gestartet werden. So lassen sich zeitkritische Anwendungen wie Reglermodelle direkt auf die Zielhardware verlagern und direkt in Echtzeit ausführen.
Ein weiteres Einsatzgebiet sind auch Stand-alone-Messdatenerfassungseinheiten und Prüfstandskonfigurationen, die ohne fest installierten Bedien-PC auskommen, beispielsweise Dauerlaufprüfstände. Hier wird der komplette Prüfablauf auf die Zielhardware verlagert und die erfassten Messdaten verwaltet, sodass während des teils mehrwöchigen Prüfdurchlaufes kein PC angesteckt sein muss.
Über die Autoren:
Manfred Schneider ist als geschäftsführender Gesellschafter für den Bereich Automotive Test Solutions verantwortlich, Thomas Sedlaczek ist als Softwareentwickler für FlexRay-Lösungen verantwortlich, beide bei Göpel electronic.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
