Der einfache Weg zur Simulation komplexer

Der
einfache
Weg
zur
Simulation
komplexer
Fahrzeugnetzwerke für den Test von Steuergeräten
Autor: Dipl.-Ing. Manfred Schneider, GÖPEL electronic GmbH, Jena
Dipl.-Ing. Thomas Sedlaczek, GÖPEL electronic GmbH, Jena
Der immerhin überschaubaren Anzahl von Bussystemen zur Steuergerätevernetzung in
Kraftfahrzeugen steht trotz aller Bestrebungen zur Standardisierung eine Flut unterschiedlicher
Kommunikationsprotokolle und Funktionsumfä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. Er hat dabei nicht nur die
Kommunikationsumfänge im Auge zu behalten, welche die eigentliche Funktion seines
Steuergerätes betreffen, sondern muss zusätzliche Anforderungen wie Netzwerkmanagement
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 im Vordergrund, welche 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. Welche
Softwarephilosophie sich hinter diesen Begriffen verbirgt, soll mit dem folgenden Beitrag
beispielhaft veranschaulicht werden.
Abb.1 Funktionsumfang der Softwaresuite Net2 Run
Erzeugung einer Restbussimulation
Um eine signalbasierte Restbussimulation zu konfigurieren ist im ersten Schritt die Auswahl der
Datenbasis notwendig, welche alle Informationen zu den in einem Netzwerk verbundenen
Steuergeräten enthält. Net2Run unterstützt CANdb, LIN und Fibex-Datenbasen (.dbc, .ldf, .xml).
Die Software nutzt intern das aktuellste Fibex-Datenformat, deshalb werden dbc- und ldf-Files
automatisch in entsprechende Fibex-Dateien konvertiert. Der Bediener wählt die für seinen
Steuergerätetest relevanten Datenbasen aus und übernimmt diese in sein aktuelles Projekt. Da
ein Steuergerät über mehrere Interfaces verfügen kann, die in unterschiedliche Fahrzeugnetze
eingebunden sind (z.B. Gatewaysteuergeräte oder Kombiinstrumente), können mehrere
Datenbasen parallel geladen werden. Danach durchsucht der Anwender das importierte
Netzwerk nach den für ihn interessanten, d.h. zu testenden Steuergeräten und zieht diese per
per Drag & Drop in das Projektfenster. Der Net2Run Konfigurator erkennt automatisch, welche
für das bzw. die Steuergeräte 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 Datenbasis
heraussucht und mit den dafür hinterlegten Defaultwerten parametriert. In Abhängigkeit, ob die
komplette Steuergeräteumgebung oder nur einzelne Botschaften bzw. Signale simuliert werden
sollen, erfolgt im Projektfenster eine entsprechende Auswahl. Nun braucht lediglich noch eine
Zuordnung
der
Botschaften
zu
dem
gewünschten
Hardwareinterface
des
Kommunikationscontrollers vorgenommen zu werden und die Erzeugung der Restbus Simulation
gestartet werden. Botschaftszä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überhinaus kann der Benutzer
eigene Checksummenmodelle in Form von C-Bibliotheken hinzufügen. Die Software stellt hierfür
ein entsprechendes C-Template bereit.
Abb.2 Bedienoberfläche des Net2Run Konfigurators
2
Net2Run unterstützt die Kommunikationscontroller der aktuellen Serie 61 von GÖPEL electronic,
auf denen je nach Ausstattungsvariante mehrere CAN-, LIN- und FlexRay- Interfaces
bereitgestellt werden.
Benutzerspezifische Restbussimulationen sowie Variantenanpassungen lassen sich mit geringem
Aufwand durch Hinzufügen bzw. Entfernen von einzelnen Frames bzw. Signalen erzeugen. Der
Anwender kann durch Aufklappen der in Form einer Baumstruktur dargestellten Datenbasis bis
auf Signalebene vordringen und einzelne Frames, PDUs oder Signale per Drag & Drop den
Projekt hinzufügen, bzw. bereits enthaltene Elemente heraus löschen oder dessen Eigenschaften
im Properties Fenster editieren.
Abb.3 Konfiguration der Zielhardware mittels Hardware Explorer
Damit hat der Anwender in sehr effizienter Weise 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.
AUTOSAR PDU Unterstützung
Die
voranschreitende
Standardisierung
von
Fahrzeugsteuergeräte
Software
und
Softwarekomponenten im Rahmen der AUTOSAR (AUTomotive Open System ARchitecture)
Entwicklungspartnerschaft bringt veränderte Anforderungen an das Testsystem mit sich. Um
diesen Anforderungen Rechnung zu tragen, hat GÖPEL electronic bei der Entwicklung von
Net2Run
besonderes
Augenmerk
auf
die
Unterstützung
der
im
AUTOSAR
Standard
beschriebenen Kommunikationsmechanismen und Protokolle gelegt.
Net2Run unterstützt das Konzept der Protocol Data Units (PDUs), wie es im AUTOSAR Standard
Anwendung findet. Das PDU Konzept erlaubt es Datenpakete zwischen verteilten Applikationen
3
auszutauschen, ohne dass die Applikation hierzu Kenntnisse des verwendeten Bussystems
benötigt. Der Kommunikationsstack übernimmt hierbei das Packen bzw. Entpacken der
Datenpakete in busspezifische Botschaften. Hierzu verfügt die Net2Run Firmware über einen
PDU-Router, welcher 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 Net2Run Firmware ist der PDU-Multiplexer, 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
Multiplexeres und damit die im dynamischen Teil zu übertragende PDU festlegt.
Abb.4 Frame Layout einer gemultiplexten PDU
Das FlexRay Bussystem erlaubt es, bis zu 254 Bytes an Nutzdaten in einer einzelnen Botschaft zu
übertragen. Will man in heterogenen Bordnetzen die PDUs in der Anwendungsschicht vom
verwendeten Bus-System unabhängig behalten, darf die von CAN bekannte Nutzdatenlänge von
8 Bytes 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. Zur Reduzierung
dieser Blindleistung wurde im AUTOSAR das Konzept der Update-Bits eingeführt. Hierbei teilt der
Sender einer PDU durch Setzen des zugehörigen Update-Bits dem Empfänger mit, dass der
Dateninhalt der PDU aktualisiert wurde. Entsprechend werden PDUs deren Update-Bit nicht
4
gesetzt wurde auch nicht ausgewertet. Enthält die Fibex Datenbasis 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 Restbussimulation fehlt dem Anwender
bislang
noch
die
Möglichkeit,
Applikationsprogramm bzw.
Signale
während
des
Programmablaufes
seiner Testautomation heraus
aus
seinem
aktiv zu beeinflussen, d.h.
veränderbare Botschaftsinhalte (z.B. Sensoristwerte) zu generieren. Dazu stellt ihm der Net2Run
Konfigurator ein Signalfenster bereit, in das der Anwender per Drag & Drop alle Signale
hineinziehen kann, die während des Programmlaufes verändert werden sollen. Zur besseren
Orientierung werden auf der Bedienoberfläche die Signaleigenschaften und das Layout des
dazugehörigen Frames dargestellt. Die in die Signalliste aufgenommenen Signale können nun zur
Laufzeit der Restbus Simulation über die GÖPEL C API (G-API) gelesen bzw. geschrieben
werden. Hierbei kann sowohl auf den physikalischen als auch den Rohwert des Signals
zugegriffen werden. Darüber hinaus können Signalwerte auch direkt aus der Net2Run
Bedienoberfläche heraus geändert werden, hierzu steht ein entsprechendes Signal Panel bereit.
Die G-API benutzt symbolische Signalnamen, welche in der Signalliste vom Anwender geändert
werden können. Die G-API Befehle können On-Board auf der Karte bzw. auf dem Host-Rechner
unter Windows genutzt werden. Bei der G-API handelt es sich um eine C-API welche 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 entsprechende VIBibliothek zur Verfügung.
Gateway Editor
Der in Net2Run integrierte Gateway Editor unterstützt die Konfiguration eines Multibus-Gateways
mittels Bus System 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
sowie
die
gewünschte
Transferfunktion
auswählt
und
ggf.
erforderliche Umrechnungsparameter wie Skalierung, Offset oder Wertebereich angibt. Sind in
der Fibex Datenbasis bereits Gateway-Mappings vorhanden, so können diese direkt ins Projekt
übernommen werden.
5
Erstellung von On-Board Anwenderprogrammen
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 Softwaresuite mit einer kompletten Toolkette
Net2Run IDE für die Erstellung von On-Board Anwenderprogrammen auszustatten. Net2Run IDE
basiert auf der Eclipse Entwicklungsumgebung bietet mit den QNX Neutrino Command Line Tools
eine vollwertige C/C++ Cross Development Plattform für die Kommunikationscontroller der Serie
61. Der Zugriff auf die Kommunikationsroutinen und IO Funktionen der Serie 61 Hardware
erfolgt über die bekannten G-API Funktionen. So lassen sich bereits bestehende Windows
Prüfprogramme mit geringem Aufwand für die On-Board Programmierung portieren. Mittels
Ethernetverbindung und des Remote Debug Dienstes der Serie 61 lassen sich die erstellten
Applikationsprogramme direkt aus dem Net2Run IDE heraus debuggen. Anschließend können die
Programme im Flash Dateisystem der Serie 61 abgelegt werden und lassen sich entweder mittels
Autostartfunktion automatisch ausführen oder über die G-API von Host PC aus starten.
Abb.5 Entwicklungsumgebung Net2Run IDE
So lassen sich zeitkritische Anwendungen wie z.B. Regler-Modelle 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 BedienPC auskommen, wie z.B. Dauerlaufprüfstände. Hier wird der komplette Prüfablauf auf die
Zielhardware verlagert und eine Verwaltung erfasster Messdaten vorgenommen, sodass während
des teils mehrwöchigen Prüfdurchlaufes kein PC angesteckt sein muss.
6
Autoren:
Dipl.-Ing. Manfred Schneider studierte von 1971-75 Nachrichtentechnik an der Technischen
Hochschule Ilmenau und war 1991 Mitgründer der GÖPEL electronic GmbH, wo er als
geschäftsführender Gesellschafter für den Bereich Automotive Test Solutions verantwortlich ist.
Thomas Sedlaczek studierte Industrieinformatik an der Fachhochschule in Wolfsburg und
Electronic Design an der University of Glamorgan in Süd Wales. Er sammelte einige Jahre
Erfahrung als Softwareentwickler bei Sanken Power Systems Ltd. in Cardiff und als FAE bei
dSPACE Ltd. in Cambridge. Seit Januar 2008 ist er als Softwareentwickler bei der der GÖPEL
electronic GmbH in Jena für die FlexRay Lösungen verantwortlich.
7