Bei der Auswahl einer Steuergeräte-Schnittstelle für externe Bypass-Aufgaben sind verschiedene Kriterien zu berücksichtigen. Dazu zählen die elektrischen und mechanischen Voraussetzungen des Steuergerätes sowie dessen Umgebungsbedingungen, die Aktivierungsrate der Bypass-Funktion und der Einsatz gleicher Schnittstellen für Mess-, Applikations- und Bypass-Aufgaben. Zusätzlich spielen die Kosten und der Zeitaufwand für die Integration im Steuergerät eine wichtige Rolle.
RCP-Systeme von dSPACE bieten für Bypass-Aufgaben eine umfassende Unterstützung von Steuergeräte-Schnittstellen und -Protokollen wie DPMEM PODs, On-Chip-Debug-Schnittstellen, XCP on CAN und dem CAN Calibration Protocol CCP. Insbesondere für Bypass-Aufgaben, die sehr geringe Latenzen bei der Datenübertragung zwischen Steuergerät und RCP-System erfordern, werden häufig Dual-Port-Memories (DPMEM) eingesetzt, die als Bestandteil eines im oder am Steuergerät verbauten Plug-on-Devices (POD) direkt mit dem Mikrocontroller-Bus verbunden sind. PODs sind häufig OEM- oder steuergerätespezifisch. Daneben werden für bestimmte Prozessorfamilien, zum Beispiel für MPC55xx-Mikrocontroller von Freescale, Standard-Lösungen bereitgestellt.
Der externe Mikrocontroller-Bus steht bei modernen Steuergeräten nicht immer oder nicht immer exklusiv für den Anschluss von DPMEM-PODs zur Verfügung. Daneben sind Fahrzeughersteller zunehmend an generischen, wiederverwendbaren Lösungen interessiert. Daher gewinnen On-Chip-Debug-Schnittstellen an Bedeutung – vor allem für anspruchsvolle Bypass-Aufgaben, bei denen serielle Schnittstellen wie CAN nicht genügend Bandbreite bieten.
Das Generic Serial Interface (GSI) von dSPACE unterstützt verschiedene On-Chip-Debug-Varianten wie Nexus, JTAG, AUD oder NBD sowohl für externe Bypass-Aufgaben als auch für die Steuergeräte-Applikation. Eine interne Arbitrierungslogik garantiert, dass Mess-, Applikations- und Bypass-Zugriffe auf das Steuergerät parallel durchgeführt werden können, und das ohne Beeinflussung der Latenzzeiten bei der Datenkommunikation zwischen Steuergerät und Prototyping-Hardware. Der Anwender kann dabei das GSI durch Software-Anpassung an verschiedene Mikrokontroller adaptieren, was zu einer hohen Wiederverwendbarkeit in unterschiedlichen Projekten führt.
Aufgrund der Steuergeräte-Vielfalt und der unterschiedlichen Einsatzszenarien rücken zudem Lösungen auf Basis existierender Busschnittstellen und standardisierter Protokolle zunehmend ins Blickfeld. Das Universal Measurement and Calibration Protocol XCP stellt die Weiterentwicklung des bereits etablierten Protokollstandards CCP dar. Durch die konsequente Trennung von Protokoll- und Transportschicht werden künftige Kommunikationsstandards im Fahrzeug berücksichtigt, ohne das eigentliche Protokoll verändern zu müssen. XCP on CAN ist Teil der Protokollfamilie und als ASAM-Standard definiert. Im Gegensatz zu CCP stellt XCP mit der so genannten Data-Stimulation-Methode (STIM) Möglichkeiten bereit, Daten synchron und zyklisch auf das Steuergerät zu schreiben, ohne jeweils eine Rückmeldung vom Steuergerät bekommen zu müssen. Die STIM-Methode ist somit vergleichbar mit der Messdatenerfassung im Steuergerät (DAQ), allerdings bei umgekehrtem Datenfluss.
In sehr vielen Steuergeräten findet man heute bereits eine CCP-Implementierung. Es liegt daher nahe, auch CCP für weniger anspruchsvolle Bypass-Anwendungen zu unterstützen, insbesondere dann, wenn Anwender den Aufwand einer weiteren Service-Implementierung einsparen möchten. Ein typisches Anwendungsbeispiel ist die Entwicklung einer neuen Software-Funktion, ohne dabei den vorliegenden Steuergeräte-Code verändern zu müssen. Dazu können die Funktionseingänge über CCP synchron zum Steuergerät erfasst, die neue Funktion auf dem RCP-System berechnet und die Ausgangswerte direkt mit den Aktoren im Fahrzeug über die dSPACE-RapidPro-Leistungsendstufen verbunden werden.
Funktionsfreischnitte im Steuergerät
Bypass-Implementierungen im Steuergerät erfordern in der Regel Modifikationen des Steuergeräte-Codes. Hierzu werden spezifische Code-Patches oder Service-Aufrufe, auch Funktions- oder Bypass-Freischnitte genannt, in den bestehenden Steuergeräte-Code eingebracht. Aufgabe dieser Freischnitte ist es, dem RCP-System die Eingangsgrößen der neuen Bypass-Funktionen verfügbar zu machen, je nach Bypass-Schnittstelle die Funktionsberechnung zu initiieren und die Ausgangsgrößen dieser Funktion wieder in den Programmablauf des Steuergerätes einzubringen.
Ziel des Fahrzeugherstellers ist es, eigene Software-Funktionen möglichst unabhängig vom Steuergeräte-Zulieferer zu entwickeln. Dazu ist es in der Regel erforderlich, den jeweiligen Funktionsfreischnitt im Steuergeräte-Code sowie die Ein- und Ausgangsvariablen der Bypass-Funktion über das RCP-System aktivieren beziehungsweise auswählen zu können. Erreicht wird dies durch die Integration so genannter Services. dSPACE stellt sowohl für DPMEM-PODs und das Generic Serial Interface als auch für XCP on CAN Steuergeräte-Services bereit, die neben der Steuergeräte-Applikation, der Messdatenerfassung und der Flash-Programmierung auch das Bypassing von Steuergeräte-Funktionen unterstützen. Flexible Konfigurationsoptionen erlauben es zudem, die Services bezüglich Funktionalität und Ressourcenbedarf im Steuergerät maßzuschneidern.
Software-Funktionen sind häufig im Steuergerät auf verschiedene Prozesse verteilt, die in unterschiedlichen Tasks berechnet werden. Aufgrund dieser Komplexität erfordert die sichere und zuverlässige Bypass-Implementierung im Steuergeräte-Code genaue Kenntnis der Software-Strukturen, so dass die Integration der Funktionsfreischnitte in der Regel bei Projektbeginn vom Steuergeräte-Zulieferer durchgeführt wird. Dabei können bis zu 255 Service-Aufrufe im Steuergeräte-Code implementiert werden, ohne das Laufzeitverhalten merklich zu beeinflussen. Nach erfolgter Integration und Verifikation der Funktionsfreischnitte sind keine weiteren Anpassungen am Steuergeräte-Code notwendig. Servicebasiertes Bypassing ermöglicht somit dem Fahrzeug-Hersteller im weiteren Verlauf des Projektes, neue Funktionen unabhängig vom Steuergeräte-Zulieferer zu entwickeln und zu testen. Bis zu 128 Bypass-Funktionen lassen sich dabei gleichzeitig zwischen RCP-System und Steuergerät synchronisieren. Bild 2 zeigt eine typische Beispiel-Implementierung für XCP on CAN.
Die maximal verfügbare Bandbreite von 1 Mbit/s über CAN und die daraus resultierende Latenz bei der Datenübertragung ermöglicht es nicht immer, im gleichen Berechnungsschritt der Steuergeräte-Task Modelleingangsgrößen an das RCP-System zu senden, die Bypass-Funktion dort zu berechnen und die Modellausgänge unmittelbar an das Steuergerät zu schicken. Insbesondere beim Bypassing von Steuergeräte-Funktionen mit schnellen Aktivierungsraten ist es daher sinnvoll, die an das Steuergerät übertragenen Ausgangsgrößen jeweils auf Basis der Eingangsgrößen vom zurückliegenden Abtastschritt zu berechnen. Alternativ kann bei Bypass-Funktionen, die keinen Abtastschrittversatz der Ein- und Ausgangsgrößen erlauben, der Service derart konfiguriert werden, dass das Steuergerät eine vorher definierte maximale Zeitdauer auf Rückgabewerte vom RCP-System wartet.
Häufig besteht der Wunsch, mit mindestens zwei Werkzeugen gleichzeitig auf das Steuergerät zugreifen zu können. Beispielsweise möchte man unabhängig voneinander ein Mess- und Applikationswerkzeug sowie ein Bypass-System bzw. eine Prüfstandsregelung ankoppeln können. Für diesen Fall erlaubt der dSPACE XCP on CAN Service die Implementierung einer zweiten Service-Instanz, ohne dabei den ROM- bzw. Flash-Speicherbedarf des Services im Steuergerät merklich zu beeinflussen (Bild 3). Der zusätzliche RAM-Speicherbedarf der zweiten Instanz richtet sich dabei nach der zugehörigen Mess- oder DAQ-Konfiguration. Das Aufsetzen von Messlisten, das Starten und Stoppen von Messungen sowie die Verbindung zum Steuergerät können beim Einsatz zweier Instanzen komplett unabhängig erfolgen.
In einigen Fällen liegt jedoch bereits eine XCP-Implementierung mit nur einer Instanz im Steuergerät vor. Um dennoch mit zwei Werkzeugen unabhängig arbeiten zu können, wird zukünftig eine XCP-Gateway-Implementierung auf dem RCP-System bereitgestellt, die die Arbitrierungvon XCP-Zugriffen unterschiedlicher Werkzeuge ermöglicht (Bild 3).