-
Die Erfindung betrifft ein Verfahren zum Anpassen einer Funktionalität einer fahrzeugbasierten Softwareapplikation an eine für die Ausführung der Funktionalität verfügbare Hardwareausstattung eines Kraftfahrzeugs. Eine Softwareapplikation kann in dem Kraftfahrzeug beispielsweise auf einem Steuergerät ausgeführt werden, um eine Fahrzeugfunktion bereitzustellen, z.B. eine Kommunikationsanbindung an einen Backendserver. Immer dann, wenn in der Softwareapplikation eine bestimmte Funktionalität (also eine Teilfunktion oder Unterfunktion) benötigt wird, beispielsweise kryptografisches Verschlüsseln oder Entschlüssen von Daten, wird hierzu eine Hardwareausstattung genutzt, die sich je nach Fahrzeugtyp unterscheiden kann, weil beispielsweise unterschiedliche Verschlüsselungsmodule verbaut sind. Die Softwareapplikation soll dennoch für unterschiedliche Fahrzeugtypen und damit für unterschiedliche Hardwareausstattungen verfügbar oder anpassbar gemacht werden. Zu der Erfindung gehören auch ein computerlesbares Speichermedium, um das Verfahren mittels einer Prozessorschaltung ausführen zu können, sowie ein Computersystem, welches das Verfahren ausführen kann.
-
In einem Kraftfahrzeug können durch ein Steuergerät oder mehrere Steuergeräte eine Softwareapplikation oder mehrere Softwareapplikationen ausgeführt werden, durch welche jeweils eine Fahrzeugfunktion bereitgestellt wird, beispielsweise das Steuern eines Motors und/oder der Betrieb eines Infotainmentsystems und/oder das Bereitstellen einer Internetverbindung, um nur Beispiele zu nennen. Man ist daran interessiert, solche Softwareapplikationen für unterschiedliche Fahrzeugtypen dahingehend gleichzeitig entwickeln oder programmieren zu können, dass die anwendungsspezifische Programmierung, also das Programmieren der jeweiligen Fahrzeugfunktion, nur einmal für alle Fahrzeugtypen durchgeführt werden muss. Dies kann dann erschwert sein, wenn eine Fahrzeugfunktion Hardwarebezug hat, also innerhalb der Fahrzeugfunktion zumindest eine Funktionalität auf einer spezifischen Hardware oder einem spezifischen Bauteil ausgeführt werden muss, das sich je nach Fahrzeugtyp unterscheidet.
-
Eine bei Betriebssystemen bekannte sogenannte Hardwareabstraktion (HAL - Hardware Abstraction Layer) kann bei Steuergeräten nicht in jedem Fall bereitgestellt werden, weil dies eine Rechenleistung und/oder einen Speicherumfang erfordert, der bei einem Steuergerät nur mit einem unerwünscht großen Aufwand bereitgestellt werden kann.
-
Aus der
US 2005/0251796 A1 ist bekannt, dass Programmbibliotheken einer Softwareapplikation wiederverwendet werden können und dass in Programmbibliotheken die dort vorhandenen oder bereitgestellten Funktionalitäten durch eine Suchfunktion gefunden werden können. Eine Programmbibliothek kann damit zwar für mehrere unterschiedliche Softwareapplikationen verfügbar gemacht werden, nicht aber anders herum eine Programmbibliothek für mehrere unterschiedliche Hardwareausstattungen.
-
Um Programmcode einer Softwareapplikation für unterschiedliche Hardwareausstattungen oder sogenannte Targets erstellen zu können, ist gemäß der
EP 2 417 521 B1 eine Software-Entwicklungsumgebung vorgesehen, in welcher alle zum Erzeugen des Programmcodes der Softwareapplikation benötigten Programmmodule in sogenannten Makefiles aufgelistet oder eingetragen werden können. Beim Verwenden von Makefiles ist es in der Regel so, aber zugleich auch für jedes „Target“ ein entsprechendes Header-File oder eine Header-Datei pro Target vorgesehen ist. Damit ergibt sich ein entsprechender Aufwand, da stets alle Header-Dateien auf demselben aktuellen Stand gehalten werden müssen.
-
Aus der
US 6,662,357 B1 ist bekannt, den Quellcode für eine Softwareapplikation in sogenannten „Repositories“ zusammenzufassen.
-
Der Erfindung liegt die Aufgabe zugrunde, eine fahrzeugbasierte Softwareapplikation mit geringem Aufwand für mehrere unterschiedliche Fahrzeugtypen bereitstellen zu können, die sich in ihrer für zumindest eine Funktionalität der Softwareapplikation relevanten Hardwareausstattung voneinander unterscheiden.
-
Die Aufgabe wird durch die Gegenstände der unabhängigen Patentansprüche gelöst. Vorteilhafte Weiterentwicklungen der Erfindung ergeben sich durch die Merkmale der abhängigen Patentansprüche, die folgende Beschreibung sowie die Figuren.
-
Als eine Lösung umfasst die Erfindung ein Verfahren zum Anpassen einer Funktionalität einer fahrzeugbasierten Softwareapplikation an eine für das Ausführen dieser Funktionalität verfügbare Hardwareausstattung eines Kraftfahrzeugs. Die Softwareapplikation soll also in unterschiedlichen Kraftfahrzeugtypen betrieben werden können, wobei sich die Kraftfahrzeugtypen in ihrer Hardwareausstattung unterscheiden, welche für das Ausführen einer Funktionalität der Softwareapplikation betriebsrelevant ist. Der Begriff „Funktionalität“ soll hier ein Bestandteil oder eine Teilmenge all derjenigen Vorgänge oder Programmschritte sein, die insgesamt die Softwareapplikation ausmachen. Die Softwareapplikation kann insgesamt eine Fahrzeugfunktionalität in dem Kraftfahrzeug bereitstellen, beispielsweise das eingangs beschriebene Steuern eines Motors und/oder eines Infotainmentsystems und/oder einer Anbindung (Connectivity) von Geräten des Kraftfahrzeugs an das Internet, insbesondere an zumindest einen sogenannten Backend-Server für das Kraftfahrzeug. Die Softwareapplikation kann dafür vorgesehen sein, auf einem Steuergerät oder mehreren Steuergeräten ausgeführt zu werden. Als Funktionalität kann beispielsweise vorgesehen sein, dass in der Softwareapplikation Daten kryptografisch verschlüsselt und/oder entschlüsselt werden.
-
Die Softwareapplikation ist insgesamt durch einen Programmcode bereitgestellt oder gebildet, also die insgesamt vorgesehene Menge von Programminstruktionen für die Softwareapplikation. Bei dem hier beschriebenen Verfahren wird dieser Programmcode der Softwareapplikation durch ein anwendungsspezifisches erstes Programmmodul und ein die Funktionalität implementierendes zweites Programmmodul bereitgestellt. Mit „anwendungsspezifisch“ ist hierbei gemeint, dass das erste Programmmodul die Fahrzeugfunktion, wie sie durch die Softwareapplikation bereitgestellt werden soll, implementiert oder repräsentiert oder umsetzt. Die Funktionalität stellt hierbei aber eine besondere Teilmenge der Fahrzeugfunktion dar, denn sie ist von dem ersten Programmmodul getrennt in einem zweiten Programmmodul implementiert. Als Programmmodul kann beispielsweise ein Quellcode oder ein bereits kompilierter Binärcode vorgesehen sein.
-
Um aus diesen beiden Programmmodulen den funktionsfähigen Programmcode der Softwareapplikation zu erzeugen, ist das erste Programmmodul mit einer Sprunginstruktion zum Springen an eine Einsprungadresse bereitgestellt oder ausgestattet. Eine solche Sprunginstruktion instruiert beim Ablauf oder beim Ausführen des ersten Programmmoduls die ausführende Prozessorschaltung oder den ausführenden Prozessor oder die ausführende CPU (Central Proccessing Unit), dass sie ihren Programmzeiger oder Program-Pointer auf die Einsprungadresse umzustellt, sodass als nächstes die an der Einsprungadresse stehende Programminstruktion ausgeführt wird. Eine solche Sprunginstruktion kann in einem Assembler-Code durch die Instruktion „call“ implementiert werden. Diese Sprunginstruktion ist in dem ersten Programmmodul dabei an der Stelle vorgesehen, die dazu vorgesehen ist, das Prozessieren von Daten mittels der Funktionalität zu starten. Wird also in dem anwendungsspezifischen ersten Programmmodul im Prozessablauf oder Programmablauf die Funktionalität benötigt oder gewünscht, wird an diese Stelle die Sprunginstruktion gesetzt oder eingefügt. Das erste Programmmodul weist des Weiteren einen Sprungadressenspeicher, also einen Speicherort, auf, um einen Wert der Einsprungadresse zu speichern. Durch Ändern des Werts der Einsprungadresse in dem Sprungadressenspeicher wird damit das Sprungziel der Sprunginstruktion verändert. Die Sprunginstruktion stellt also in der Programmmodul keinen festen oder vorbestimmten Sprung an eine konstante oder unveränderliche Einsprungadresse dar, sondern die Sprunginstruktion springt an diejenige Einsprungadresse, deren Wert in dem Sprungadressenspeicher steht. Somit ist also das Sprungziel der Sprunginstruktion adaptiv ausgestaltet. Erst im fertigen Programmcode muss ein fester oder konstanter Wert verfügbar sein.
-
Um eine Anpassungsfähigkeit an unterschiedliche Hardwareausstattungen zu erhalten, ist das zweite Programmmodul in mehreren Varianten oder Ausführungsformen vorhanden. Es gibt nämlich mehrere vorbereitete zweite Programmmodule, von denen jedes die Funktionalität für jeweils eine andere Hardwareausstattung aus mehreren möglichen Hardwareausstattungen implementiert. Mit anderen Worten wird in Bezug auf die Funktionalität für alle zu versorgenden oder zu berücksichtigenden Hardwareausstattungen jeweils die Funktionalität getrennt implementiert oder programmiert, sodass sich mehrere mögliche oder mehrere verfügbare oder auswählbare zweite Programmmodule ergeben.
-
Welches Programmmodul ausgewählt wird, ist dann davon abhängig, für welche Hardwareausstattung oder für welchen Kraftfahrzeugtyp ein Programmcode der Softwareapplikation benötigt wird. Um den benötigten Programmcode bereitzustellen, wird deshalb durch eine Prozessorschaltung ein externes Signal empfangen, welches signalisiert, welche Hardwareausstattung das Kraftfahrzeug aufweist. Ein solches externes Signal kann beispielsweise durch den Fachmann vorgegeben werden, der auswählt, welche Hardwareausstattung vorliegt oder berücksichtigt werden soll. Die Prozessorschaltung wählt dann aus den mehreren vorbereiteten zweiten Programmmodulen dasjenige für die Hardwareausstattung aus, die durch das Signal signalisiert oder angegeben ist.
-
Der Programmcode der Softwareapplikation wird aus dem ersten Programmmodul und dem ausgewählten zweiten Programmmodul zusammengesetzt. Um nun die beiden Programmmodule zu verknüpfen, wird ermittelt, an welcher Speicheradresse innerhalb des zusammengesetzten Programmcodes sich eine Start-Instruktion der Funktionalität aus dem ausgewählten zweiten Programmmodul befindet. Es wird also gesucht, wo sich die initiale oder erste Instruktion (Startinstruktion) zum Starten der Funktionalität in dem zusammengesetzten Programmcode befindet. Eine Startinstruktion lässt sich im Programmcode beispielsweise mittels einer Textsuche finden oder lokalisieren, indem beispielsweise ein Symbol, das der Startinstruktion zugeordnet ist, in dem Programmcode oder in dem zweiten Programmmodul gesucht wird. Die Speicheradresse kann auch beispielsweise berechnet werden, wenn das zweite Programmmodul an das erste Programmmodul angefügt wird, und man bereits die relative Position der Startinstruktion in Bezug auf den Beginn oder den Anfang des zweiten Programmmoduls kennt. Dann kann man zusätzlich die Länge oder Größe des ersten Programmmoduls hinzuaddieren und erhält somit die Speicheradresse in Bezug auf den Beginn des insgesamt zusammengesetzten Programmcodes. Die ermittelte Speicheradresse, das heißt deren Wert, wird in den Sprungadressenspeicher des ersten Programmmoduls eingetragen. Wird also in einem Steuergerät oder in einem Verbund mehrerer Steuergeräte im Kraftfahrzeug ein Prozess in einem Betriebssystem und/oder einer Laufzeitumgebung gestartet und hierzu der besagte Programmcode der Softwareapplikation als eine Prozess des Betriebssystems ausgeführt, werden zunächst Programminstruktionen, die dem ersten Programmmodul entstammen oder entsprechen, ausgeführt und hierdurch die anwendungsspezifische Fahrzeugfunktion in dem Kraftfahrzeug bereitgestellt. Gelangt dann beim Ausführen des Programmcodes der ausführende Mikroprozessor oder die ausführende CPU an die Stelle, wo die Sprunginstruktion zum Springen an die Einsprungadresse bereitgestellt ist, so wird gemäß dem Wert in dem Sprungadressenspeicher der Mikroprozessor oder die CPU an die Startinstruktion der Funktionalität springen und somit die Funktionalität ausführen.
-
Durch die Erfindung ergibt sich der Vorteil, dass die Softwareapplikation nur einmalig mittels des anwendungsspezifischen ersten Programmmoduls implementiert werden muss und die Anpassung an die verfügbare Hardwareausstattung mit geringem Aufwand durch Bereitstellen von hardwarespezifischen oder hardware-angepassten zweiten Programmmodulen erfolgen kann, die an das erste Programmmodul angefügt und mit diesem über den Wert der Speicheradresse der Startinstruktion verknüpft werden. Die Startinstruktion ist dabei eine Programminstruktion, die die erste in einer Folge von Programminstruktionen darstellt, durch welche die Funktionalität implementiert oder programmiert ist.
-
Die Erfindung umfasst auch Weiterentwicklungen, durch die sich zusätzliche Vorteile ergeben.
-
Die besagte Startinstruktion und die darauf folgenden Programminstruktionen der Funktionalität können beispielsweise vorsehen, dass vorbestimmte Aufrufparameter übernommen werden oder erwartet werden, die von dem ersten Programmmodul übergeben oder in einem RAM, beispielsweise einem Stack, abgelegt sein müssen, wo sie durch die Startinstruktion und/oder folgende Programminstruktionen der Funktionalität erwartet oder abgerufen oder ausgelesen werden. Dieses Protokoll der erwarteten Abrufparametern und deren Verarbeitung durch eine aufgerufene Funktionalität wird auch als Aufrufschnittstelle oder Funktionsdefinition bezeichnet.
-
In einer Ausgestaltung weist von den mehreren vorbereiteten zweiten Programmmodulen, also den unterschiedlichen Programmmodulen für die unterschiedlichen Hardwareausstattungen, jedes davon zum Starten der Funktionalität dieselbe Ausgestaltung ihrer Aufrufschnittstelle mit denselben Aufrufparametern auf. Ein Beispiel für einen solchen Aufrufparameter kann ein sogenannter Speicherzeiger oder Pointer zu den besagten Daten sein, die durch die Funktionalität verarbeitet oder prozessiert werden sollen. Ein weiterer Aufrufparameter kann beispielsweise den Betrieb der Funktionalität steuern, beispielsweise festlegen, welcher kryptografischer Algorithmus auf die Daten angewendet werden soll und/oder welcher kryptographische Schlüssel verwendet werden soll. Die Reihenfolge und/oder der Datentyp solcher Aufrufparameter sind gemäß dieser Weiterentwicklung bei allen vorbereiteten zweiten Programmmodulen identisch. Somit ist aus Sicht oder beim Entwickeln des ersten Programmmoduls für die anwendungsspezifische Programmierung keine Rücksicht darauf zu nehmen oder es kann Hardware-unabhängig in dem ersten Programmmodul die zweite Funktionalität eingesetzt oder integriert werden. Mit anderen Worten kann das erste Programmmodul „agnostisch“ in Bezug auf die genutzte Hardwareaustattung ausgestaltet werden.
-
Eine Weiterentwicklung umfasst, dass der Programmcode mittels eines Compilers und/oder Linkers und/oder Interpreters erzeugt wird. Wird ein Compiler verwendet, so können die Programmmodule jeweils als Quellcode bereitgestellt werden. Wird ein Linker verwendet, so können die Programmmodule jeweils bereits als Binärcode, sogenannter Objektcode, bereitgestellt werden. Wird ein Interpreter verwendet, so können die Programmmodule als Programmskripte bereitgestellt werden. Somit kann auf unterschiedliche Implementierungsformen zurückgegriffen werden.
-
Eine Weiterentwicklung umfasst, dass die Prozessorschaltung in dem Kraftfahrzeug selbst betrieben wird, also das Zusammensetzen des Programmcodes im Kraftfahrzeug bei Bedarf geschehen kann. Das erste Programmmodul und das ausgewählte zweite Programmmodul werden dabei zur Laufzeit des jeweiligen Betriebssystems des Steuergeräts oder des Verbunds der Steuergeräte zusammengefasst, wobei es sich um das Betriebssystem handelt, das dann auf die Softwareapplikation in dem Kraftfahrzeug startet oder ausführt. Mit anderen Worten werden also die Programmmodule dynamisch zusammengefasst, was beispielsweise auf der Grundlage des sogenannten dynamischen Linkens (Dynamic Linking) erfolgen kann.
-
Alternativ dazu kann die Prozessorschaltung auch in einem Computersystem bereitgestellt sein, das in einem Labor oder bei einem Hersteller des Kraftfahrzeugs oder in einem Backend für das Kraftfahrzeug betrieben werden kann, also insbesondere kann es sich um eine stationär bereitgestellte Prozessorschaltung handeln. Der Programmcode kann dann beispielsweise über eine Funkverbindung in dem zumindest einen Steuergerät des Kraftfahrzeugs eingespielt werden. Dann ist in dem Kraftfahrzeug der Programmcode zum Ausführen oder Starten bereit.
-
Um das beschriebene dynamische Zusammenfassen der Programmmodule in einem Kraftfahrzeug vorzusehen, können das erste Programmmodul und das ausgewählte zweite Programmmodul für das Zusammenfassen in einem gemeinsamen Adressraum in einem RAM der Prozessorschaltung geladen werden. Durch das Laden oder Einblenden insbesondere des zweiten Programmmoduls in den Adressraum des ersten Programmmoduls ergibt sich die besagte benötigte Speicheradresse der Startinstruktion der Funktionalität, deren Wert dann in den Sprungadressenspeicher des ersten Programmmoduls abgespeichert werden kann.
-
Wie bereits ausgeführt, handelt es sich bei der Funktionalität um eine hardware-abhängige Prozessierungseinheit oder -einrichtung, die sich zwischen den Fahrzeugtypen unterschiedlicher Kraftfahrzeuge unterscheiden muss. Insbesondere handelt es sich um einen kryptografischen Algorithmus, der in unterschiedlichen Steuergeräten mittels unterschiedlicher Hardware implementiert sein kann. Zusätzlich oder alternativ dazu kann die Funktionalität einen Video-Encoder, Video-Decoder und/oder Audio-Encoder und/oder Audio-Decoder und/oder eine grafische Steuerung für einen Bildschirm umfassen, um nur Beispiele für hardware-abhängige Funktionalitäten zu nennen.
-
Im Zusammenhang mit einem kryptografischen Algorithmus sieht eine Weiterentwicklung vor, dass die zugehörige Hardwareausstattung, die sich je nach Kraftfahrzeug unterscheiden können, einen integrierten Schaltkreis umfasst, der eine sichere Ausführungsumgebung (SPE - Secure Processing Environment) oder TEE (Trusted Execution Environment) enthält. Ein solcher Schaltkreis wird auch als Sicherheitsmodul bezeichnet, es handelt sich insbesondere um einen Schaltkreis mit eigener, integrierter CPU, die unabhängig von einer Prozessorschaltung, welche den Programmcode des ersten Programmmoduls der Softwareapplikation ausführt, betrieben werden kann. Ein solcher integrierter Schaltkreis kann beispielsweise manipulationssicher und/oder auslesesicher ausgestaltet sein, wie dies für sichere Ausführungsumgebungen SPEs oder TEEs an sich bekannt ist. Ein Beispiel für ein SPE ist ein jeweils TPM (Trusted Platform Module) und eine SIM (Subscriber Identity Module).
-
Wie bereits ausgeführt, wird das erste Programmmodul bevorzugt in der Weise bereitgestellt, dass es eine von der verfügbaren Hardwareausstattung unabhängige Programmierung aufweist, also in dem ersten Programmmodul keine Rücksicht darauf genommen wird, welche Hardwareausstattung tatsächlich vorliegt, sondern lediglich die Funktionalität genutzt wird und bei Nutzung der Funktionalität die Sprunginstruktion zum Springen an die Einsprungadresse verwendet wird.
-
Für Anwendungsfälle oder Anwendungssituationen, die sich bei dem Verfahren ergeben können und die hier nicht explizit beschrieben sind, kann vorgesehen sein, dass gemäß dem Verfahren eine Fehlermeldung und/oder eine Aufforderung zur Eingabe einer Nutzerrückmeldung ausgegeben und/oder eine Standardeinstellung und/oder ein vorbestimmter Initialzustand eingestellt wird.
-
Um das erfindungsgemäße Verfahren in einer Prozessorschaltung zu implementieren, umfasst die Erfindung auch ein computerlesbares Speichermedium. Das Speichermedium kann z.B. zumindest teilweise als ein nicht-flüchtiger Datenspeicher (z.B. als eine Flash-Speicher und/oder als SSD - solid state drive) und/oder zumindest teilweise als ein flüchtiger Datenspeicher (z.B. als ein RAM - random access memory) bereitgestellt sein. Das Speichermedium kann in der Prozessorschaltung in deren Datenspeicher realisiert sein. Das Speichermedium kann aber auch beispielsweise als sogenannter Appstore-Server im Internet betrieben sein. Durch den Computer oder Computerverbund kann eine Prozessorschaltung mit zumindest einem Mikroprozessor bereitgestellt sein. Der Programmcode können als Binärcode oder Assembler und/oder als Quellcode einer Programmiersprache (z.B. C) und/oder als Programmskript (z.B. Python) bereitgestellt sein.
-
Die Erfindung umfasst auch ein Computersystem zum Erzeugen einer fahrzeugbasierten Softwareapplikation, wobei zum Bereitstellen des Programmcodes der Softwareapplikation in einer Variante, wie sie für eine aus mehreren vorbestimmten Hardwarespezifikationen oder Hardwareausstattungen notwendig ist, in dem Computersystem eine Prozessorschaltung bereitgestellt ist, die dazu eingerichtet ist, eine Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Hierzu kann die Prozessorschaltung beispielsweise eine Ausführungsform des erfindungsgemäßen computerlesbaren Speichermediums aufweisen. Die Prozessorschaltung kann hierzu zumindest einen Mikroprozessor und/oder zumindest einen Mikrocontroller und/oder zumindest einen FPGA (Field Programmable Gate Array) und/oder zumindest einen DSP (Digital Signal Processor) aufweisen. Des Weiteren kann die Prozessorschaltung Programmcode aufweisen, der dazu eingerichtet ist, bei Ausführen durch die Prozessorschaltung die Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Der Programmcode kann in einem Datenspeicher der Prozessorschaltung gespeichert sein.
-
Das erfindungsgemäße Kraftfahrzeug ist bevorzugt als Kraftwagen, insbesondere als Personenkraftwagen oder Lastkraftwagen, oder als Personenbus oder Motorrad ausgestaltet.
-
Die Erfindung umfasst auch die Kombinationen der Merkmale der beschriebenen Ausführungsformen. Die Erfindung umfasst also auch Realisierungen, die jeweils eine Kombination der Merkmale mehrerer der beschriebenen Ausführungsformen aufweisen, sofern die Ausführungsformen nicht als sich gegenseitig ausschließend beschrieben wurden.
-
Im Folgenden sind Ausführungsbeispiele der Erfindung beschrieben. Hierzu zeigt:
- 1 eine schematische Darstellung eines Computersystems zum Ausführen einer Ausführungsform des erfindungsgemäßen Verfahrens; und
- 2 eine Diagramm zur Veranschaulichung einer Ausführungsform des erfindungsgemäßen Verfahrens.
-
Bei den im Folgenden erläuterten Ausführungsbeispielen handelt es sich um bevorzugte Ausführungsformen der Erfindung. Bei den Ausführungsbeispielen stellen die beschriebenen Komponenten der Ausführungsformen jeweils einzelne, unabhängig voneinander zu betrachtende Merkmale der Erfindung dar, welche die Erfindung jeweils auch unabhängig voneinander weiterbilden. Daher soll die Offenbarung auch andere als die dargestellten Kombinationen der Merkmale der Ausführungsformen umfassen. Des Weiteren sind die beschriebenen Ausführungsformen auch durch weitere der bereits beschriebenen Merkmale der Erfindung ergänzbar.
-
In den Figuren bezeichnen gleiche Bezugszeichen jeweils funktionsgleiche Elemente.
-
1 zeigt ein Computersystem 10, das beispielsweise als ein Backend-Server und/oder eine Entwicklungsumgebung für Fahrzeugfunktionen von Kraftfahrzeugen 11 ausgestaltet sein kann. Die Kraftfahrzeuge 11 können jeweils zumindest ein Steuergerät 12 aufweisen, wobei sich aber bei den Kraftfahrzeugen eine Hardwareausstattung 13, die für den Betrieb der Steuergeräte 12 vorgesehen ist, unterscheiden kann. Die Unterschiede sind in 1 durch unterschiedliche Bezeichnungen HW1, HW2, HW3 symbolisiert. Beispielsweise kann sich die Hardwareausstattung 13 dadurch unterscheiden, dass unterschiedliche Schaltungen, insbesondere integrierte Schaltungen, für eine sichere Ausführungsumgebung, sogenannte SPEs, bereitgestellt sind.
-
In den Kraftfahrzeugen 11 soll jeweils eine Fahrzeugfunktion F bereitgestellt werden, beispielsweise kann es sich um das Übertragen von Daten handeln, für die eine kryptografische Absicherung oder ein kryptografischer Schutz, das heißt eine kryptografische Verschlüsselung, verwendet werden soll. Die Fahrzeugfunktion F weist hierzu eine Funktionalität 14 auf, die als Bestandteil der Fahrzeugfunktion F vorgesehen ist, die sich aber für die unterschiedlichen Hardwareausstattungen 13 in den Fahrzeugfunktionen F unterscheiden muss, damit in dem jeweiligen Steuergerät 12 die Fahrzeugfunktion F funktional gleich, aber in Bezug auf die Implementierung unterschiedlich bereitgestellt werden kann.
-
Um dennoch den Entwicklungsaufwand und/oder den Bedarf an unterschiedlichen Varianten für die Fahrzeugfunktion F gering zu halten, kann für alle Hardwareausstattungen 13 in dem Computersystem 10 ein Programmmodul 15 bereitgestellt sein, welches dem beschriebenen ersten Programmmodul entspricht und welches die Fahrzeugfunktion F Hardware-unabhängig, also unabhängig von der Hardwareausstattung 13, implementiert oder bereitstellt. Um innerhalb der Fahrzeugfunktion F die Funktionalität 14 zu implementieren, kann für jede Hardwareausstattung jeweils ein an die Hardwareausstattung 13 angepasstes zweites Programmmodul 16 in dem Computersystem 10 vorgesehen sein.
-
Möchte man nun für eines der Kraftfahrzeuge 11 die Fahrzeugfunktion F bereitstellen oder implementieren, so kann beispielsweise durch ein Steuern des Skripts und/oder durch eine Bedienperson und/oder durch ein Sensorsignal eines Sensors des jeweiligen Kraftfahrzeugs 11 ein Signal 17 vorgegeben werden, welches signalisiert, welche Hardwareausstattung 13 in dem Zielfahrzeug, das heißt im Kraftfahrzeug 11 signalisiert, welches das sogenannte Target für die Erzeugung eines Programmcodes 18 der Fahrzeugfunktion F darstellt.
-
Durch das Signal 17 wird eine Auswahl 18 aus den vorgefertigten oder bereitgestellten Programmmodulen 16 durchgeführt, was hier durch einen Schalter symbolisiert ist. Durch eine Prozessorschaltung 19 des Computersystems 10 kann die Auswahl 18 in Abhängigkeit von dem Signal 17 ausgeführt werden und es kann das jeweilige zweite Programmmodul 16, das ausgewählt ist, also das ausgewählte Programmmodul 20, mit dem ersten Programmmodul 15 zusammengefasst oder kombiniert werden, was beispielsweise durch eine Zusammenfassungseinheit 21 erfolgen kann, die beispielsweise einen Compiler und/oder Linker und/oder Interpreter umfassen kann. Die zusammengefassten Programmmodule, das heißt das erste Programmmodul 15 und das ausgewählte Programmmodul 20, können dann als der Programmcode 18 bereitgestellt werden. Um die beiden Programmmodule zu verknüpfen, kann in dem ersten Programmmodul 15 eine Sprunginstruktion 23 vorgesehen sein, die beispielsweise als ein Progammaufruf ausgestaltet sein kann, wie er im Assembler als der Befehl oder die Programminstruktion CALL ausgestaltet sein kann. Eine Einsprungadresse 24, die das Sprungziel oder ein Sprungziel für die Sprunginstruktion 23 darstellt, kann in einem Sprungadressenspeicher 25 gespeichert sein. Nach dem Zusammenfassen des ersten Programmmoduls 15 mit dem ausgewählten zweiten Programmmodul 20 kann in dem Programmcode 18 ermittelt werden, an welcher Speicheradresse 26 eine Startinstruktion 27 der Funktionalität 14 in dem ausgewählten zweiten Programmmodul 20 angeordnet ist. Diese Speicheradresse 26 kann in dem Sprungadressenspeicher 25eingetragen oder abgespeichert werden, sodass durch die Sprunginstruktion 23 beim Aufrufen derselben ein Einsprung 30 an die Startinstruktion 27 der Funktionalität 14 erfolgt. Als Parameter oder als Objekt, auf welches die Funktionalität 14 angewendet werden soll, können Daten 31 durch das erste Programmmodul 15 ermittelt werden, bei denen es sich beispielsweise um zu verschlüsselnde oder um zu entschlüsselnde Daten handeln kann.
-
Der Programmcode 18 kann dann über eine Kommunikationsverbindung 33 in das jeweilige Kraftfahrzeug 11 und dessen Steuergerät 12 übertragen werden, sodass in dem Steuergerät 12 der Programmcode 18 mit dem ausgewählten zweiten Programmmodul 20 zum Ausführen bereitsteht, wobei das ausgewählte Programmmodul 20 die Hardwareausstattung 13, also in dem Beispiel HW2, berücksichtigt. Wird der Programmcode 18 durch einen Mikroprozessor oder eine CPU des Steuergeräts 12 ausgeführt und die Sprunginstruktion 23 erreicht, so erfolgt der Einsprung 30 gemäß dem Wert im Sprungadressenspeicher 25 an die Startinstruktion 27 der Funktionalität 14 und die Funktionalität 14 wird somit mit Programminstruktionen ausgeführt, die zu der Hardwareausstattung 13 passen oder ein fehlerfreies Ausführen für die Hardwareausstattung 13, also HW2, durchführen. Stattdessen würde die Verwendung des Programmcodes 18 in einer der anderen Hardwareausstattungen 13, also hier HW1, HW3, zu einem Fehler führen. Die Kommunikationsverbindung 33 kann beispielsweise auf der Grundlage eines sogenannten OTA-Updates, OTA - Over the Air, oder beim Herstellen des Steuergeräts 12 in dem jeweiligen Steuergerät 12 installiert werden.
-
2 veranschaulicht, wie gemäß einer bevorzugten Ausführungsform ein erstes Programmmodul 15 mit einer Auswahl des zweiten Programmmoduls 16 kombiniert werden kann. Die Programmmodule 15, 16 können hierbei jeweils als ein Quelltext, beispielsweise ein Programm in der Programmiersprache C oder C++, ausgestaltet sein. Dargestellt ist, wie in dem ersten Programmmodul 15 eine anwendungsspezifische Programmierung 40 die Fahrzeugfunktion F implementieren kann. Die anwendungsspezifische Programmierung 40 ist hier als ein Benutzer dargestellt, da sie optional ein Kapselmodul 41 nutzt, die beispielsweise als Programmbibliothek „.lib" ausgestaltet sein kann.
-
Durch die Programmbibliothek oder allgemein durch das Kapselmodul 41 kann für die Programmierung 40 ermöglicht werden, Hardware-unabhängig ausgestaltet zu werden. Vor allem kann vorgesehen sein, dass die Sprunginstruktion 23 als ein Funktionsaufruf ausgestaltet ist. Die Ausgestaltung des Funktionsaufrufs kann durch eine Funktionsdeklaration 42 vorgegeben sein, die beispielsweise als ein sogenanntes Headerfile .hpp bereitgestellt sein kann. Dies stellt eine Aufrufschnittelle dar. Anders als im Stand der Technik üblich, ist dem Headerfile aber nicht eine einzelne Datei mit Funktionsdefinitionen, also Quelltextdateien, beispielsweise sogenannte .c-Dateien oder .cpp-Dateien, bereitgestellt, sondern es können beispielsweise in unterschiedlichen Dateiordnern zu ein und demselben Headerfile mehrere unterschiedliche Quelltextdateien als jeweiliges zweites Programmmodul 16 vorgesehen sein. Dies kann erreicht werden, indem die Funktionsdeklaration in der Headerdatei einerseits und die korrespondierenden Funktionen in den zweiten Programmmodulen 16 alle identisch ausgestaltet sind. Ein Compiler kann dann nicht unterscheiden, zu welchem Programmmodul 16 die Headerdatei gehört.
-
Aber die Quelltextdateien müssen nicht mal zwingend in verschiedenen Ordnern liegen, können es aber. Wichtig ist nur dass die über Dateiname oder Dateipfad unterscheidbar sind. Die eigentliche Auswahl der Source-Files (Quelltextdateien) kann über die CMake-Files für einen Compiler gesteuert. Hier kann also über unterschiedliche Dateinamen im selben Ordner gearbeitet werden, wenn aus welchen Gründen auch immer so gewünscht. Einzig die Konfigurationsdateien für CMake müssen in getrennten Ordnern liegen, um getrennt ansteuerbar zu sein. Die Quelltextdateien nicht.
-
Stellt man während des Vorgangs des Kompilierens in der Einheit 21 nur eines der zweiten Programmmodule 16 bereit, so erfolgt das Kompilieren ohne Fehler und es kann der entsprechende Quelltext eines zweiten Programmmoduls 16 genutzt werden, um über die Headerdatei einen vollständigen Programmcode zu kompilieren, der die Fahrzeugfunktion F Hardware-spezifisch gemäß der Hardwarespezifizierung des jeweiligen ausgewählten Programmmoduls 16 implementiert. In 2 ist dargestellt, dass auch ein zweites Programmmodul 44 vorgesehen sein kann, welches Hardware-unabhängig ist, indem eine lokale Implementierung der Funktionalität 14 ohne Zugriff auf eine spezialisierte Hardware vorgesehen ist. Dies kann beispielsweise genutzt werden, falls die für die Funktionalität notwendige spezialisierte Hardware nicht zur Verfügung steht.
-
Die entwickelte Software kann damit als einheitliche Plattform über alle Fahrzeuge hinweg eingesetzt werden. In diesem Zusammenhang kann eine Bibliothek, die eine einheitliche Crypto-API für Benutzer dieser Plattform bereitstellt, entwickelt werden. Die Steuergeräte, in die die Software integriert wird, müssen nicht einheitlich mit derselben Hardwareausstattung versehen sein. Es sind mehrere unterschiedliche Zielimplementierungen möglich, die alle die gleiche einheitliche Schnittstelle bereitstellen.
-
Teilweise werden die Implementierungen von einigen Zielen gemeinsam genutzt, aber nicht von allen, und für jedes Ziel kann diese Gruppe von gemeinsamen Schnittstellenimplementierungen unterschiedlich sein.
-
Dennoch kann der gesamte Code aller Programmodule für alle Ziele / Hardwareausstattungen in einem Repository gehalten werden:
- - hier werden die Header-Dateien gepflegt
- - eine Standardimplementierung wird bereitgestellt
- - jedes Ziel hat bevorzugt seinen eigenen Bereich (Unterordner) für die Implementierung der Quelldateien. Optional, wenn auch sinnvoll. CMake-Konfigurationen müssen dagegen in eigenem Dateiordner liegen.
- - für jedes Ziel gibt es eine Konfigurationsdatei (CMake), die die Quelldateien auswählt, die für den Build verwendet werden sollen
- - Da sich alle Dateien im selben Repository befinden, kann Code von anderen Zielen oder die Standardimplementierung einfach verwendet werden, ohne Code zu duplizieren
- - Beim Bauen der Bibliothek über die Build-Konfiguration wird eine der Zielkonfigurationen per Signal, abhängig von der gesamten Build-Konfiguration ausgewählt und alle dort aufgeführten Dateien werden gegen die gemeinsamen Header-Dateien gebaut.
-
Konsistenz ist gewährleistet: Da sich der gesamte Code in einem gemeinsamen Repository befindet, kann keine veraltete Version von Header-Dateien verwendet werden.
-
Konfigurationsmanagement ist möglich: Durch die automatische Auswahl der richtigen Zielkonfiguration können alle verfügbaren Hardwareausstattungen durch eine Pipeline, die auf derselben Codebasis basiert, parallel berücksichtigt werden. Wartung ist möglich: jeder Code muss nur einmal gewartet werden; es muss keine Arbeit geleistet werden, um die Gleichheit über verschiedene Code-Basen sicherzustellen.
-
Wiederverwendung: Da es einen Pool verfügbarer Implementierungen gibt, kann jedes Ziel frei aus diesem Pool auswählen und Code kann zwischen den Zielen geteilt werden.
-
Insgesamt zeigen die Beispiele, wie eine Auswahl aus mehreren, parallelen Zielimplementierungen, die dieselbe Header-Datei verwenden, zur Erstellungszeit bereitgestellt werden kann.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 2005/0251796 A1 [0004]
- EP 2417521 B1 [0005]
- US 6662357 B1 [0006]
