Der einfache Weg zur Simulation komplexer Fahrzeugnetzwerke für den Test von Steuergeräten

Transkript

1 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

2 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

3 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

4 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

5 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, Signale während des Programmablaufes aus seinem Applikationsprogramm bzw. seiner Testautomation heraus 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 VI- Bibliothek 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

6 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 Bedien- PC 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

7 Autoren: Dipl.-Ing. Manfred Schneider studierte von 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