-
Die Erfindung betrifft ein Verfahren zur Erstellung eines vereinfachten virtuellen Steuergeräts, mit dem in einem Simulationsszenario ein Teil der Funktionen eines realen Steuergeräts simulierbar sind, mit den Verfahrensschritten:
- Bereitstellen eines Teils eines das virtuelle Steuergerät darstellenden Programmcodes und
- Durchführen eines Build-Prozesses für diesen Programmcode durch Kompilieren und Linken des Programmcodes.
-
Ein virtuelles Steuergerät, eine sogenannte V-ECU, weist verschiedene Bestandteile auf. Ein Bestandteil ist eine Software, die in einem Simulationsszenario ein echtes Steuergerät oder einen Teil eines echten Steuergeräts simuliert. Dazu kommt die eigentliche ECU-Software, also die Software, die auch später auf der Hardware-Version des Steuergeräts laufen soll. Eine V-ECU enthält somit in der Regel immer Komponenten von Applikations- und Basis-Software und bietet daher Funktionalitäten, die mit denen echter Steuergeräte vergleichbar sind. Eingesetzt werden V-ECUs z.B. für die Validierung während einer Computer-basierten Simulation. Verschiedene V-ECU-Versionen decken einen großen Variantenbereich ab - von sehr einfachen Versionen bis hin zu einer Komplettversion, die alle Komponenten eines realen Steuergeräts enthält: Die einfachste Form einer V-ECU hat für jede Funktion nur eine Komponente. In einer komplexeren Version enthält die V-ECU mehrere verknüpfte Software-Komponenten, zum Beispiel die komplette Funktionalität eines Steuergeräts.
-
Da beim Einsatz einer V-ECU nicht mit realer Steuergeräte-Hardware gearbeitet wird, kann die Simulation schneller als in Echtzeit erfolgen, so dass die Analyse des simulierten Steuergeräts sehr zeitsparend und komfortabel erfolgen kann. Durch Software-in-the-Loop-Test (SIL-Tests) in Computer-basierten Simulationen können Software-Funktionen, V-ECUs oder komplette V-ECU-Netzwerke simuliert und getestet werden. Wie oben schon angesprochen, kann dies in Echtzeit oder sogar schneller und hochgradig parallel erfolgen.
-
Software-Entwicklungsprozesse für klassische Automobilanwendungen, wie Antriebsstrang- oder Bremssystemen, bis hin zu E-Drive-Anwendungen und Funktionen für das autonome Fahren können mittels SIL-Tests durch virtuelles Testen und Validieren deutlich beschleunigt werden. So kann ein DUT (device under test) komfortabel auf einem Computer simuliert werden, es kann mit physikalisch basierten Modellen verbunden werden, und Testskripte können später auf Hardware-in-the-Loop (HIL)-Systemen einfach wiederverwendet werden.
-
Die Erstellung von V-ECUs ist ein komplexer Prozess, der sehr viel Wissen über die Bestandteile der V-ECU voraussetzt und zahlreiche Abhängigkeiten vom V-ECU-Integrator, also dem Ersteller der V-ECU, zu seinen Software-Lieferanten aufweist. Lieferungen von Software erfolgt daher oft in kleinen Teillieferungen, die wiederum nur sinnvoll in eine V-ECU zu integrieren sind, wenn alle Bestandteile vorhanden sind oder entsprechende offene Schnittstellen durch sogenannte Stubs geschlossen werden.
-
Ein Stub (von englisch „stub“) bezeichnet in der Softwareentwicklung einen Programmcode, der anstelle eines anderen, meist komplexeren Programmcodes steht. Im Deutschen spricht man anstatt von einem Stub mitunter auch von einer stark vereinfachten Stellvertreterkomponente. Dabei ist der eigentliche Programmcode, der durch den Stub ersetzt wird, z.B. noch nicht entwickelt (Top-Down-Ansatz), nur auf einem anderen Rechner oder in einem anderen Speicherbereich vorhanden oder nicht kompatibel mit der virtuellen Umgebung, z.B. aufgrund von Hardeware-Abhängigkeiten (Register, Peripherie), die in der V-ECU noch nicht existieren. Liegt der Code an einem anderen Ort, so ist der Stub der lokale Anknüpfungspunkt, um Softwarekomponenten einfach anzusprechen, die ansonsten nur über komplexe Protokolle erreichbar wären, und um diese Komplexität zu verbergen. Ein Stub entspricht dann dem Entwurfsmuster eines Stellvertreters. Insbesondere kommen Stubs bei der Entwicklung sehr komplexer Systeme zur Anwendung. Stubs geben auf Anfragen also vordefinierte Werte zurück, um das Verhalten eines noch nicht vollständig erstellen Softwarecodes testen zu können.
-
Diese Stubs müssen typischerweise manuell programmiert werden und können je nach Komplexität der V-ECU und je nach Vollständigkeit der Lieferungen schnell zu mehr als 1000 offenen Schnittstellen führen, die alle über einen manuellen Stub behandelt werden müssen. Ziel bei der Erstellung einer V-ECU ist es, schnellstmöglich eine kompilierbare und erfolgreich gelinkte V-ECU zu erhalten, die anschließend untersucht oder getestet werden kann, ohne dass erst auf die gesamte Lieferung der V-ECU-Software gewartet werden muss. So können bereits frühzeitig Fehler in den Softwarelieferungen gefunden und fehlende Teile identifiziert werden. Mit späteren Lieferungen werden die Stubs dann nach und nach durch neu angelieferte Softwareteile ersetzt.
-
Davon ausgehend ist es die Aufgabe der Erfindung, ein Verfahren bereitzustellen, um möglichst schnell eine ausführbare V-ECU zu erhalten, die bereits Teilfunktionalitäten ihrer Software testbar macht.
-
Diese Aufgabe wird durch den Gegenstand des Patentanspruchs 1 gelöst. Bevorzugte Weiterbildungen finden sich in den Unteransprüchen.
-
Erfindungsgemäß wird somit ein Verfahren zur Erstellung eines vereinfachten virtuellen Steuergeräts bereitgestellt, mit dem in einem Simulationsszenario ein Teil der Funktionen eines realen Steuergeräts simulierbar sind, mit folgenden Verfahrensschritten:
- Bereitstellen eines Teils eines das virtuelle Steuergerät darstellenden Programmcodes,
- Durchführen eines Build-Prozesses für diesen Programmcode durch Kompilieren und Linken des Programmcodes,
- automatisches Erstellen einer Liste von beim Linken festgestellter Linker-Fehler, die von Fehlstellen in dem Programmcode herrühren, wobei die Liste den Ort der jeweiligen Fehlstelle und eine an der jeweiligen Fehlstelle jeweils fehlende Referenz und/oder Implementierung beinhaltet,
- automatisches Erstellen eines Stubs für jede Fehlstelle auf der Grundlage der an der jeweiligen Fehlstelle jeweils fehlenden Referenz und/oder Implementierung und
- automatisches Einsetzen des jeweiligen Stubs in die jeweilige Fehlstelle.
-
Wenn vorliegend von einem vereinfachten virtuellen Steuergerät die Rede ist, so soll damit zum Ausdruck gebracht werden, dass ein solches virtuelles Steuergerät nicht alle Funktionen aufweist, die das reale Steuergerät aufweist, das es simulieren soll. Das ist genau die der Erfindung zu Grunde liegende Problematik: Obwohl das virtuelle Steuergerät noch nicht komplett fertiggestellt ist, soll es schon eingesetzt werden können, so dass zumindest Teilfunktionen seiner Software getestet werden können.
-
Der Build-Prozess (von englisch „to build“) bezeichnet in der Softwareentwicklung einen Vorgang, durch den ein fertiges Anwendungsprogramm automatisiert erzeugt wird. Der Build-Prozess macht das Programm also ausführbar. Der Build-Prozess besteht typischerweise aus der Code-Kompilierung und dem Linken des kompilierten Codes an Bibliotheken. Da der Build-Prozess automatisiert ausgeführt wird, benötigt das ausführende Erstellungsprogramm eine formale Beschreibung der durchzuführenden Programm- oder Funktionsaufrufe durch Kompiler, Linker usw. sowie der Abhängigkeiten dieser Aufrufe untereinander.
-
Da die Erstellung einer V-ECU ein relativ langwieriger Prozess ist, beim dem es viele Zuliefererabhängigkeiten geben kann, ist es gewünscht, möglichst schnell eine ausführbare V-ECU zu erhalten, die bereits Teilfunktionalitäten der V-ECU testbar macht. Die Erfindung ermöglicht es, noch nicht bereitstehende Teile der V-ECU sehr effizient so zu ersetzen, dass es nach dem Kompilierungsvorgang nicht zu Fehlern des Linkers durch fehlende Referenzen oder Symbole, wie zum Beispiel extern deklarierte globale Variablen oder Funktionen, kommt.
-
Ein wesentlicher Schritt des erfindungsgemäßen Verfahrens besteht darin, automatisch eine Liste von beim Linken festgestellter Linker-Fehler zu erstellen, die von Fehlstellen in dem Programmcode herrühren, wobei eine solche Fehlstelle jeweils einer fehlenden Referenz und/oder einer fehlenden Implementierung entspricht.
-
Grundsätzlich ist es im Rahmen des erfindungsgemäßen Verfahrens möglich, genau die Stubs an den ermittelten Fehlstellen einzusetzen, die im Rahmen des computerimplementierten Verfahrens automatisch erstellt worden sind. Gemäß einer bevorzugten Weiterbildung der Erfindung ist jedoch vorgesehen, dass das Verfahren die folgenden Schritte aufweist:
- Bereitstellen einer Editierfunktion, mit der die jeweiligen erstellten Stubs von einem Nutzer editierbar sind,
- Abspeichern eines erstellten Stubs als editierten Stub, sofern der jeweilige Stub von dem Nutzer editiert worden ist, und
- automatisches Einsetzen des jeweiligen editierten Stubs in die jeweilige Fehlstelle.
-
Dies hat den Vorteil, dass in der noch nicht vollständig erstellten V-ECU nicht nur standardisierte Stubs verwendet werden können, die nach vorbestimmten Regeln in Abhängigkeit von Charakteristiken der jeweiligen Fehlstelle und abhängig von dem die Fehlstelle „umgebenden“ Programmcode automatisch erstellt worden sind. Vielmehr ist es auf diese Weise auch möglich, dem Nutzer des erfindungsgemäßen Verfahrens die Möglichkeit zu geben, bei der Art und der Eigenschaften des jeweils einzubauenden Stubs Einfluss zu nehmen.
-
In diesem Zusammenhang ist es insbesondere bevorzugt, dass die Editierfunktion das Ergänzen der Stubs um einen Datentyp, einen Rückgabewert und/oder einen Funktionsparameter ermöglicht. Der Datentyp, der Rückgabewert und der Funktionsparameter können somit vom Nutzer des erfindungsgemäßen Verfahrens individuell an verschiedene Entwicklungsstufen der in der Entwicklung begriffenen V-ECU angepasst werden.
-
Bei dem computerimplementierten Verfahren ist im Rahmen des automatisieren Erstellens der Stubs ganz besonders bevorzugt, dass die Stubs Funktionen ohne Rückgabewerte aufweisen. Auf diese Art und Weise können universelle Stubs erstellt werden, die regelmäßig an praktisch jeder Fehlstelle verwendbar sind.
-
Schließlich ist gemäß einer bevorzugten Weiterbildung der Erfindung vorgesehen, dass das Verfahren zusätzlich noch die folgenden Schritte aufweist:
- Durchführen eines Build-Prozesses für den um die Stubs ergänzten Programmcode durch Kompilieren und Linken dieses Programmcodes zur Erstellung des vereinfachten virtuellen Steuergeräts und
- Testen von Funktionen des realen Steuergeräts in einem Simulationsszenario des vereinfachten virtuellen Steuergeräts.
-
Nach dem ersten Build-Prozess erfolgt hier also ein zweiter Build-Prozess, nämlich durch Kompilieren und Linken des um die Stubs ergänzten Programmcodes. Durch das Erstellen der Liste von beim Linken festgestellter Linker-Fehler im ersten Build-Prozess und das Ergänzen der festgestellten Fehlstellen um passende Stubs, läuft der zweite Build-Prozess jetzt zumindest im Hinblick auf die zuvor festgestellten Fehlstellen fehlerfrei durch, so dass damit eine V-ECU zur Verfügung steht, mit der bereits Funktionen des realen Steuergeräts in einem Simulationsszenario des vereinfachten, weil noch nicht alle Funktionen aufweisenden, virtuellen Steuergeräts getestet werden können.
-
Nachfolgend wir die Erfindung anhand eines bevorzugten Ausführungsbeispiels unter Bezugnahme auf die Zeichnungen weiter im Detail erläutert.
-
In den Zeichnungen zeigen
- 1 schematisch ein Verfahren zur Erstellung eines Teils eines ein virtuelles Steuergerät darstellenden Programmcodes gemäß einem bevorzugten Ausführungsbeispiel der Erfindung und
- 2 schematisch ein Verfahren zur Erstellung eines vereinfachten virtuellen Steuergeräts, mit dem in einem Simulationsszenario ein Teil der Funktionen eines realen Steuergeräts simulierbar sind, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
-
Wie weiter oben schon erläutert worden ist, ist die Erstellung von V-ECUs ein komplexer Prozess, der sehr viel Wissen über die Bestandteile der V-ECU voraussetzt und zahlreiche Abhängigkeiten des V-ECU-Integrators zu seinen Software-Lieferanten aufweist. Da die Lieferungen von Software oft in kleinen Teillieferungen erfolgt, kann in Fällen, in denen noch nicht alle Bestandteile vorhanden sind, die Software nur sinnvoll in die entstehende V-ECU integriert werden, wenn Fehlstellen durch sognannte Stubs geschlossen werden. Solche Fehlstellen entsprechen vorliegend jeweils einer fehlenden Referenz und/oder einer fehlenden Implementierung.
-
Bevor nachfolgend darauf eingegangen wird, wie im Rahmen eines bevorzugten Ausführungsbeispiels der Erfindung das „Schließen“ von Fehlstellen durch automatisch generierte Stubs erfolgt, sei unter Bezugnahme auf 1 auf das vorgelagerte Verfahren zur Erstellung einer V-ECU eingegangen:
- Wie in 1 schematisch dargestellt, wird in einem ersten Schritt S1 von einem ECU-Architekt eine Software-Architektur für die zu erstellende V-ECU erstellt. Diese Software-Architektur wird dann an den V-ECU-Integrator übergeben, der dann in Schritt S2 damit eine leere V-ECU füllt.
-
Zur eigentlichen Erstellung der V-ECU werden dann praktisch kontinuierlich Software-Komponenten einerseits und Basissoftware-Module andererseits angeliefert (Schritte S3 und S4), die vom V-ECU-Integrator, entsprechend der vorgegebenen Architektur der V-ECU, in diese integriert werden (Schritt S5). In Schritt S6 wird damit schließlich eine V-ECU bereitgestellt, die grundsätzlich einem vereinfachten virtuellen Steuergerät entspricht, mit dem in einem Simulationsszenario bereits ein Teil der Funktionen des eigentlich zu erstellenden realen Steuergeräts simulierbar wäre, wenn denn die noch vorhandenen Fehlstellen aufgrund von fehlenden Referenzen und/oder Implementierungen mit Stubs gefüllt würden.
-
Hier setzt die Erfindung mit dem nachfolgend anhand von 2 beschriebenen Ausführungsbeispiel an:
- Noch mal aufgeführt in 2 ist der Schritt S6 des Bereitstellens eines Teils des das virtuelle Steuergerät darstellenden Programmcodes, indem vorab Software-Komponenten und Basissoftware-Module in die vorgegebene Architektur der V-ECU integriert worden sind. Für diesen Programmcode wird dann in Schritt S7 durch Kompilieren und Linken des Programmcodes ein Build-Prozess durchgeführt. Dabei wird automatisch eine Liste von beim Linken festgestellter Linker-Fehler erstellt (Schritt S8), die von Fehlstellen in dem Programmcode herrühren. Die Liste beinhaltet dabei den Ort der jeweiligen Fehlstelle und eine an der jeweiligen Fehlstelle jeweils fehlende Referenz bzw. Implementierung. In Schritt S9 wird nun für jede Fehlstelle auf der Grundlage, der an der jeweiligen Fehlstelle jeweils fehlenden Referenz bzw. Implementierung, automatisch ein Stub erstellt, der dann in Schritt S10 automatisch in die jeweilige Fehlstelle eingesetzt wird und diese quasi „schließt“. Mit „Schließen“ ist hier insofern gemeint, dass zwar nicht die Funktion vorhanden ist, die die fehlende Referenz bzw. Implementierung bereitstellen sollte, es beim Linken aber zu keinen erneut auftretenden Linker-Fehlern kommt.
-
Ein wesentlicher Aspekt des vorliegend beschriebenen Verfahrens gemäß dem hier bevorzugten Ausführungsbeispiel der Erfindung liegt nun auch darin, dass das Verfahren eine Editierfunktion vorsieht, mit der die jeweiligen erstellten Stubs von einem Nutzer editierbar sind. Diese Editierfunktion ist in 2 als Schritt S13 dargestellt. Damit wird es ermöglicht, dass in der noch nicht vollständig erstellten V-ECU nicht nur standardisierte Stubs verwendet werden können, die automatisch nach vorbestimmten Regeln in Abhängigkeit von Charakteristiken der jeweiligen Fehlstelle und des entsprechenden Programmcodes erstellt worden sind. Vielmehr können solche Stubs erstellt werden, die an die zu testenden Funktionen der V-ECU angepasst sein können. Insofern werden die von dem Nutzer erstellten Stubs als editierte Stubs abgespeichert und in die jeweilige Fehlstelle eingesetzt.
-
Während die Stubs, wenn sie denn automatisch erstellt werden, typischerweise Funktionen ohne Rückgabewerte aufweisen, ist es durch die Editierfunktion möglich, die Stubs um einen Datentyp, einen Rückgabewert und/oder einen bzw. mehrere Funktionsparameter zu ergänzen, um die Testfunktionalität zu erweitern.
-
Um nun schließlich zum eigentlichen Testen von Funktionen des realen Steuergeräts in einem Simulationsszenario des vereinfachten virtuellen Steuergeräts kommen zu können, weist das Verfahren gemäß dem hier beschriebenen bevorzugten Ausführungsbeispiel der Erfindung weiterhin den Schritt S 11 auf, in dem ein Build-Prozesses für den um die Stubs ergänzten Programmcode durch Kompilieren und Linken dieses Programmcodes zur Erstellung des vereinfachten virtuellen Steuergeräts erfolgt. Dem schließt sich dann Schritt S12 an, also das eigentliche Testen von Funktionen des realen Steuergeräts in einem Simulationsszenario des vereinfachten virtuellen Steuergeräts.
-
Bezugszeichenliste
-
- S1
- Erstellen einer Software-Architektur
- S2
- Füllen einer leeren V-ECU mit der Software-Architektur
- S3
- Anliefern von Basissoftware-Modulen
- S4
- Anliefern von Software-Komponenten
- S5
- Integration der Basissoftware-Module und der Software-Komponenten in die V-ECU
- S6
- Bereitstellens eines Teils des das virtuelle Steuergerät darstellenden Programmcodes ohne Stubs
- S7
- Durchführen eines Build-Prozesses für den einen Teil des das virtuellen Steuergeräts darstellenden Programmcodes ohne Stubs
- S8
- automatisches Erstellen einer Liste von Linker-Fehlern
- S9
- automatisches Erstellen von Stubs
- S10
- automatisches Einsetzen der Stubs
- S11
- Durchführen eines Build-Prozesses für den um die Stubs ergänzten Programmcode zur Erstellung eines vereinfachten virtuellen Steuergeräts
- S12
- Testen von Funktionen des realen Steuergeräts in einem Simulationsszenario des vereinfachten virtuellen Steuergeräts
- S13
- Editieren der automatisch erstellten Stubs durch einen Nutzer
