-
Die Erfindung betrifft ein Fahrzeugsteuergerät, dessen Funktionalität nachträglich verändert werden kann, sowie ein Verfahren zum Ergänzen der Funktionalität eines Fahrzeugsteuergeräts.
-
Moderne Fahrzeuge, insbesondere moderne Kraftfahrzeuge, umfassen ein oder mehrere Fahrzeugsteuergeräte, welche einzelne Funktionalitäten zum Regeln, Steuern oder zum Diagnostizieren von Fahrzeugkomponenten bereitstellen. Der von einem Steuergerät bereitgestellte Funktionsumfang wird hierbei bei der Entwicklung des jeweiligen Steuergeräts festgelegt. Hierbei sind die Funktionen häufig auf Signale oder Informationen von bestimmten Sensoren oder anderen Steuergeräten angewiesen, um ihre spezielle Funktionalität bereitzustellen. Häufig kommt es jedoch vor, dass im Laufe einer Serienfertigung neue Fahrzeugvarianten angeboten werden sollen, welche einen erweiterten Funktionsumfang aufweisen oder in welche von dem ursprünglichen Modell abweichende Steuergerätekombinationen und Modelle eingebaut werden sollen. In solchen Situationen ist es wünschenswert, ein bereits fertig entwickeltes Steuergerät anpassen zu können und keine komplette Neuentwicklung erforderlich zu machen.
-
Die
EP 0 869 417 B1 beschäftigt sich mit diesem Problem. Dort ist eine Fahrzeugsteuerungseinheit zur Steuerung eines Fahrzeugs mit Sensoren zur Bestimmung eines Betriebszustands des Fahrzeugs und der Fahrzeugeinrichtung mit Steuerstellgliedern zur Steuerung des Fahrzeugs auf Basis der Sensorsignale beschrieben, welche einen Einchipmikrocomputer mit einem ersten Speicher, der ein Programm zur Steuerung der Stellglieder speichert, und eine CPU umfasst, die die Berechnung des Programms durchführt. Vorgesehen ist, dass das Programm ein Anwendungssoftwareprogramm zur Steuerung der Fahrzeugeinrichtung und ein Schnittstellensoftwareprogramm enthält. Die CPU ist ausgebildet, das Anwendungssoftwareprogramm und das Schnittstellensoftwareprogramm auszuführen. Der Einchipmikrocomputer umfasst einen zweiten Speicher zur Speicherung von Daten, beispielsweise dem Ergebnis der Verarbeitung der Anwendungssoftware. Das in dem ersten Speicher gespeicherte Programm ist so gestaltet, dass das Schnittstellensoftwareprogramm entsprechend der Fahrzeugtypänderungen unabhängig von dem Anwendungssoftwareprogramm geändert werden kann, sodass das Anwendungssoftwareprogramm gemeinsam für verschiedene Fahrzeugtypen ohne Änderung genutzt werden kann und lediglich Änderungen des Schnittstellensoftwareprogramms von Fahrzeug zu Fahrzeug notwendig sind.
-
In der
DE 10 2009 018 761 A1 ist ein Verfahren zum Aktualisieren zumindest einer Softwarekomponente eines Kraftfahrzeugs beschrieben, bei der ein Ersetzen von einer Softwarekomponente nur unter Mitwirkung des Fahrers möglich ist.
-
Auch die
US 2010 / 0 179 720 A1 befasst sich mit einem System und einem Verfahren zum Ausführen von Wartung und Reparatur eines Fahrzeugs. Beschrieben ist ein System, bei dem Teile eines Programmcodes einer Software beispielsweise durch Patches ergänzt oder ersetzt werden.
-
In der
DE 10 2008 036 711 A1 ist vorgeschlagen, softwarebasierte Fahrzeugfunktionen eines Kraftfahrzeugs unter Anwendung einer Ersetzungs-, Erweiterungs- und/oder Freischaltungssoftware vorzunehmen, wobei eine bereits vorhandene fahrzeugspezifische Software durch die Ersetzungs-, Erweiterungs- und/oder Freischaltungssoftware zumindest teilweise ersetzt, erweitert bzw. freigeschaltet wird. Die Ersetzungs-, Erweiterungs- und/oder Freischaltungssoftware wird mittels einer in das Kraftfahrzeug integrierten Einrichtung über eine Onlineverbindung von einem anbieterseitigen Server heruntergeladen.
-
Die
US 2011 / 0 213 829 A1 zeigt ein Verfahren zum Identifizieren eines Anforderungsversandes, der innerhalb eines ausführbaren Codes während der Ausführungszeit ausgeführt werden soll. Ein Ausführungsmodus wird bestimmt, um einen anderen ausführbaren Code vor der Ausführung des letzteren ausführbaren Code auszuführen, indem entweder die Leistungsmetrik oder der Schwellenwert ausgewertet werden. Der Anforderungsversand wird basierend auf dem Ausführungsmodus ausgeführt, der anspricht, um den Ausführungsmodus zu bestimmen, wobei ein synchroner Ausführungsmodus und ein asynchroner Ausführungsmodus dazu führen, dass die ausführbaren Cades gleichzeitig ausgeführt werden.
-
DE 10 2005 040 075 A1 zeigt ein verfahren zum Simulieren von Prozessen von vernetzten Konten unter Verwendung eines Software-Aktualisierungssimulators auf einem Computersystem auf, wobei jeder simulierte Prozess eine minimale Version eines Funktionsprozesses ist, der auf den Knoten ausgeführt wird. Ein Softwareupdatesimulator übergibt die Steuerprozessidentitäten der zu aktualisierenden Softwarepakete und die Softwareabhängigkeitsinformationen. Der Steuerprozess ermittelt anhand der Softwareabhängigkeitsinformationen, welche funktionellen Knotenprozesse ausgeführt werden, die von der Softwareaktualisierung betroffen sind.
-
In der
DE 10 2005 050 304 A1 wird eine Methode aufgezeigt, die eine Generierung eines CodeGenerator-Client-Programm beinhaltet, das automatisch in weiteren Zusatztext auf dem Client-Computer aufgeteilt wird oder zu Hardware synthetisiert werden kann. Der Codegenerator speichert seine Daten über den vom Anwendungsserver bereitgestellten Dienst und gibt sie an anderen anwendungsspezifisch bereitgestellten Client-Code zurück. Ein Cadefragment wird generiert und in das Client-Programm integriert, das die wichtigen Netzwerkadressdaten enthält, die die Dienste oder der Anwendungsserver im Netzwerk verwenden können. Die Entwicklung der anwenderspezifischen Client-Codes erfolgt während der Installation des vom Client generierten Code-Fragment-Platzhalter-Codes.
-
In der
US 7 376 945 B1 wird in einem Bibliotheksspeicher eine Bibliothek vor dem Betriebssystem gespeichert, die eine geladene Kopie des Bibliotheksmodul enthält. Ein Anwendungsspeicherplatz speichert die Anwendung vor dem Betriebssystem einschließlich des Ladegeräts und einer anderen geladenen Kopie des Moduls. Ein Prozessor führt den Loader zur Laufzeit aus, generiert die geladene Kopie des Moduls aus der zuvor geladenen Kopie und verknüpft die generierte geladene Kopie mit der Anwendung unter der Steuerung des Loaders.
-
Alle bekannten Verfahren gehen davon aus, dass zumindest ein Teil des bestehenden Programmcodes ersetzt oder modifiziert wird. Solche Änderungen sind jedoch mit hohen Risiken verknüpft, da Nebeneffekte solcher Änderungen auf andere Softwarebestandteile des Steuergeräts sich nur begrenzt abschätzen lassen. Daher ist ein Aufwand hinsichtlich der Verifikation und Absicherung solcher Softwareänderungen enorm hoch und vergleichbar mit dem Aufwand zur Absicherung einer kompletten Softwareneuentwicklung.
-
Der Erfindung liegt somit das technische Problem zugrunde, verbesserte Steuergeräte zu schaffen, bei denen eine Funktionserweiterung oder Änderung nach deren Fertigstellung und/oder im Betrieb möglich ist und mögliche Nebeneffekte durch die Änderung der Funktionalität zumindest hinsichtlich ihren Auswirkungen begrenzt sind. Ebenso wird ein verbessertes Verfahren zum Ergänzen der Funktionalitäten eines Steuergeräts benötigt.
-
Die Aufgabe wird erfindungsgemäß durch eine Vorrichtung mit den Merkmalen des Patentanspruchs 1 sowie ein Verfahren mit den Merkmalen des Patentanspruchs 7 gelöst. Vorteilhafte Ausführungsformen der Erfindung ergeben sich aus den Unteransprüchen.
-
Der Erfindung liegt die Idee zugrunde, die Steuergerätefunktionalitäten bei der Herstellung in einem oder mehreren Anwendungsmodulen zu programmieren, welche die zum Zeitpunkt der Konstruktion gewünschten Funktionalitäten bereitstellen. Zusätzlich wird eine weitere Softwareanwendung in das Steuergerät integriert, welche eine Laufzeitumgebung zum Ausführen von Programmcodes bereitstellt. Die Anwendungsmodule, welche die Basisfunktionalität zum Zeitpunkt der Konstruktion des Steuergeräts bereitstellen, sowie dasjenige Anwendungsmodul, welches die Laufzeitumgebung bereitstellt, werden in dem Steuergerät so realisiert, dass diesen jeweils statische Prozessorzugriffszeiten als auch statische Speicherbereiche zugewiesen sind. Zu der Basisfunktionalität des Steuergeräts, die in einem der Anwendungsmodule realisiert ist, gehört es, dass es über eine Kommunikationsschnittstelle des Fahrzeugsteuergeräts möglich ist, ein Programmcode eines Ergänzungsmoduls zu dem Fahrzeugsteuergerät zu übertragen und eine Speicherung des Programmcodes des Ergänzungsmoduls in einem Programmspeicherbereich des Laufzeitumgebungsmoduls zu erreichen. Die erweiterte Funktionalität wird somit von dem in der Laufzeitumgebung ausgeführten Programmcode des Ergänzungsmoduls bereitgestellt. Darüber, dass die dem Laufzeitumgebungsmodul und den anderen Anwendungsmodulen zugewiesenen Prozessorzeiten von vornherein festgelegt sind, ist sichergestellt, dass die bei der Herstellung des Steuergeräts realisierten Funktionen, welche in den Anwendungsmodulen ausgeführt sind, jeweils eine ausreichende Prozessorzugriffszeit erhalten, um ihre Funktionen bereitzustellen. Darüber hinaus ist durch eine statische Trennung der Speicherbereiche eine negative Beeinflussung eines der Anwendungsmodule aufgrund nicht ausreichend vorhandenen Speichers oder aufgrund eines Überschreibens von Speicherbereichen ausgeschlossen. Eine Funktionsbeeinträchtigung durch die Ergänzungsmodule ist somit nicht zu befürchten. Lediglich die in der Laufzeitumgebung ausgeführten Programmcodes unterschiedlicher Ergänzungsmodule können einander in dieser Hinsicht nachteilig beeinflussen. Nebeneffekte sind somit ausschließlich auf die Ergänzungsmodule beschränkt.
-
Insbesondere wird somit ein Fahrzeugsteuergerät vorgeschlagen, welches umfasst: mindestens einen Prozessor, einen mit dem Prozessor gekoppelten Speicher, wobei in dem Speicher auf dem Prozessor ausführbare Programmcodes eines Betriebssystems und mehrerer Anwendungsmodule, die die Funktionalitäten des Steuergeräts bereitstellen, gespeichert sind sowie mindestens eine Kommunikationsschnittstelle zum Datenaustausch mit anderen Fahrzeugsteuergeräten oder einer externen Einrichtung, wobei den Anwendungsmodulen jeweils die für ihre jeweilige Ausführung benötigten Programm- und Datenspeicherbereiche des Speichers statisch zugeordnet sind und wobei das Betriebssystems ausgebildet ist, den einzelnen Anwendungsmodulen einen Zugriff zur Ausführung ihres Programmcodes zu vorher statisch festgelegten Zeitabschnitten auf den Prozessor zu gestatten, wobei eines der mehreren Anwendungsmodule als Updatemodul ausgebildet ist, um über die mindestens eine Kommunikationsschnittstelle einen Programmcode eines oder mehrerer Ergänzungsmodule zu empfangen und in dem Speicher abzulegen, um eine Erweiterung und/oder Änderung der Funktionalität des Fahrzeugsteuergeräts zu bewirken, wobei eines der mehreren Anwendungsmodule als Laufzeitumgebungsmodul ausgebildet ist, welches eine Laufzeitumgebung bereitstellt, um den Programmcode des einen oder der mehreren Ergänzungsmodule auszuführen, und das Updatemodul ausgebildet ist, den Programmcode des oder der Ergänzungsmodule in dem dem Laufzeitumgebungsmodul zugeordneten Programmspeicherbereiche abzulegen, wobei das Laufzeitumgebungsmodul ausgebildet ist, den ihm zugewiesenen Datenspeicherbereich sowie die ihm zur Verfügung stehende Prozessorzugriffszeit dynamisch zur Laufzeit aufzuteilen, um den Programmcode des einen oder der mehreren Ergänzungsmodule auszuführen.
-
Ferner wird ein Verfahren zum Ergänzen der Funktionalität eines Fahrzeugsteuergeräts, wie es oben beschrieben ist, geschaffen, welches die Schritte umfasst: Bereitstellen oder Erzeugen eines Programmcodes eines Ergänzungsmoduls, welches eine neue oder veränderte Funktionalität des Fahrzeugsteuergeräts bei dessen Ausführung bewirkt, Ausbilden einer Kommunikationsverbindung mit dem Updatemodul des Fahrzeugsteuergeräts über die mindestens eine Kommunikationsschnittstelle, Übertragen des Programmcodes des Ergänzungsmoduls zu dem Fahrzeugsteuergerät und Speichern des Programmcodes in einem dem Laufzeitumgebungsmodul zugewiesenen Programmspeicherbereich, sodass das Laufzeitumgebungsmodul den Programmcode des Ergänzungsmoduls ausführt.
-
Ein wesentlicher Vorteil der Erfindung besteht darin, dass eine zu einem späteren Zeitpunkt eingebrachte Erweiterung in Form eines Ergänzungsmoduls bei ihrer Erstellung die konkrete Ausprägung des Steuergerätes oder der Steuergeräte, auf dem oder denen das Ergänzungsmodul ausgeführt werden soll, nicht kennen muss. Dies betrifft vor allem das verwendete Prozessorderivat, die Anzahl der Prozessorkerne sowie das Speicherlayout des Steuergeräts. Die Erweiterung wird deshalb in einer plattformunabhängigen Form als Programmcode oder Skriptcode eines Ergänzungsmoduls implementiert, der im Steuergerät durch die Laufzeitumgebung ausgeführt wird.
-
Um die in einem Steuergerät realisierten Funktionen an ein spezielles Fahrzeug oder an spezielle Fahrzeugsteuergerätekombinationen anpassen zu können, ist es üblich, in einem nicht flüchtigen Speicherbereich Parameter abzulegen, welche die bereitgestellten Funktionalitäten beeinflussen.
-
Bei einer bevorzugten Ausführungsform der Erfindung ist somit vorgesehen, dass der Speicher einen nicht flüchtigen Bereich umfasst, in dem Parameter für die Anwendungsmodule abgelegt sind oder ablegbar sind, wobei eines der Anwendungsmodule eine Funktionalität bereitstellt, welche ein Auslesen und/oder Ersetzen der Parameter über eine Kommunikation über die mindestens eine Kommunikationsschnittstelle gestattet, und wobei Parameter für Ergänzungsmodule in Form von Schlüssel-Wert-Paaren in dem Parameterspeicher abgelegt werden. Eine Verwendung eines Formats in Form eines Schlüssel-Wert-Paares ist deshalb vorteilhaft, da eine Anzahl der für die einzelnen Ergänzungsmodule benötigten Parameter und deren Format im Voraus nicht bekannt ist. Über den Schlüssel kann jedoch der jeweilige benötigte Parameter einfach und zuverlässig identifiziert und der entsprechende zugehörige Parameterwert aufgefunden werden. Der Speicherbereich, in dem die Parameter abgebildet sind, oder zumindest der Speicherbereich, in dem die Schlüsselparameterwertpaare abgelegt sind, wird vorzugsweise in den statisch zugewiesenen Speicherbereich gespiegelt, der dem Laufzeitumgebungsmodul zugeordnet ist. Somit können die Ergänzungsmodule auf die Parameterwerte zugreifen, ohne dass unmittelbare Zugriffe auf Speicherbereiche auf der Betriebssystemebene des Steuergeräts stattfinden.
-
Grundsätzlich birgt die Verwendung von Speicherbereichen durch mehrere Anwendungsmodule die Gefahr, dass unbeabsichtigte Effekte auftreten. Zwar ist es bei der Verwendung von statisch zugewiesenen Speicherbereichen möglich, eine Kommunikation zwischen unterschiedlichen Anwendungsmodulen oder unterschiedlichen Programmcodesträngen dadurch zu realisieren, dass diese auf einen gemeinsamen Speicherbereich zugreifen. Diese Kommunikation ist jedoch nur dann zuverlässig, wenn gewährleistet ist, dass beispielsweise von einem Programmcodestrang geschriebene Werte von dem anderen Programmcodestrang ausgelesen werden, bevor der eine Programmcodestrang die Werte erneut aktualisiert. Da eine Kommunikation zwischen den Anwendungsmodulen und den Ergänzungsmodulen nicht auf diese Weise realisiert werden soll, um Nebeneffekte, welche nicht beabsichtigt sind, zu vermeiden, ist bei einer bevorzugten Ausführungsform vorgesehen, dass die Kommunikationsstruktur im Steuergerät statisch zur Herstellungszeit des Fahrzeugsteuergeräts festgelegt ist oder sind, und diese so genannte Message-Queues umfasst, über die zumindest das Laufzeitumgebungsmodul mit den übrigen Anwendungsmodulen Daten austauschen kann. Bereits zum Zeitpunkt der Herstellung des Fahrzeugsteuergeräts werden die Schnittstellen und Funktionen bzw. Funktionalitäten festgelegt, welche möglicherweise später zugefügte Ergänzungsmodule nutzen können sollen. Für den Datenaustausch, welcher erforderlich ist, um beispielsweise Funktionen aufzurufen oder auf bereitgestellte Schnittstellen zuzugreifen, werden daher statische Message-Queues auf Betriebssystemebene bereitgestellt, welche eine spätere Anbindung der Ergänzungsmodule an die Anwendungsmodule ermöglicht. Ein Vorteil der Realisierung einer Zwischenmodulkommunikation, d.h. einer Kommunikation zwischen unterschiedlichen Anwendungsmodulen, über Message-Queues liegt darin, dass ein Datenaustausch asynchron erfolgen kann. Die auszutauschenden Daten werden von der einen Anwendung in eine definierte Message-Queue abgelegt und zu einem anderen Zeitpunkt von einer anderen Anwendung aus der Message-Queue ausgelesen. Diese kann dann wiederum Daten in dieselbe oder eine andere Message-Queue ablegen, um Daten zu dem einen Prozess zurück zu übertragen. Vorzugsweise nutzen auch die Anwendungsmodule statische Message-Queues für die Zwischenmodulkommunikation.
-
Um auch eine Kommunikation zwischen den unterschiedlichen Ergänzungsmodulen zu ermöglichen, ist es vorteilhaft, wenn das Laufzeitumgebungsmodul in seiner Laufzeitumgebung einen Message-Queuemanager bereitgestellt, der statische Laufzeitumgebungs-Message-Queues bereitstellt, die auf die statischen Message-Queues der Betriebssysteme abgebildet werden und den Ergänzungsmodulen hierüber eine Kommunikation mit den übrigen Anwendungsmodulen ermöglichen, und die eine Ausbildung dynamischer Message-Queues zur Laufzeit gestattet, um eine Kommunikation zwischen den Ergänzungsmodulen zu ermöglichen. Der Message-Queuemanager der Laufzeitumgebung muss somit auch dynamische Message-Queues zulassen und verwalten, da im Vorfeld nicht bekannt ist, welcher Datenaustausch zwischen den einzelnen Ergänzungsmodulen notwendig sein könnte.
-
Eine besonders einfache und hinsichtlich eines Ressourcenverbrauchs sparsame Umsetzung eines Laufzeitumgebungsmoduls umfasst eine virtuelle Maschine in Form einer StackMaschine. Der Programmcode der Ergänzungsmodule muss dafür so implementiert sein, dass die virtuelle Maschine diesen interpretieren und in Maschinenbefehle des tatsächlich vorhandenen Prozessors überführen kann. Die konkrete Speicherallokation wird bei dieser Umsetzung ebenfalls durch die virtuelle Maschine vorgenommen, so dass bei der Implementierung der Ergänzungsmodule keine absoluten Speicheradressen verwendet werden. Somit wird für die Ergänzungsmodule erreicht, dass diese unabhängig von der tatsächlich vorhandenen Hardware programmiert werden können. Notwendig sind jedoch die Kenntnisse über die einzelnen von den Anwendungsmodulen bereitgestellten Funktionen und Schnittstellen, auf die die Ergänzungsmodule über eine Kommunikation über die bereitgestellten Message-Queues zugreifen können.
-
Um sicherzustellen, dass ein Ergänzungsmodul auf einem Steuergerät auch tatsächlich ausführbar ist, ist bei einer Ausführungsform vorgesehen, dass dem Ergänzungsmodul Metadaten zugefügt werden, welche zumindest Anforderungsinformationen über zur Ausführung benötigte Ressourcen umfassen, und die Metadaten vor einer Übertragung des Programmcodes oder mit dem Programmcode zu dem Fahrzeugsteuergerät übertragen werden und das Updatemodul, jenes Modul, welches eine Installation von Ergänzungsmodulen in dem Steuergerät ermöglicht, anhand der Metadaten überprüft, ob das Fahrzeugsteuergerät die Anforderungen hinsichtlich der benötigten Ressourcen erfüllt und, wenn dies der Fall ist, die Programmdaten in dem Programmdatenspeicherbereich des Laufzeitumgebungsmoduls ablegt oder andernfalls, wenn die Anforderungen hinsichtlich der benötigten Ressourcen nicht erfüllt sind, eine Übertragung der Programmdaten des Ergänzungsmoduls abbricht, abweist, verwirft oder bereits abgelegte Programmdaten aus dem Speicher wieder löscht. Zu den benötigten Ressourcen eines Ergänzungsmoduls gehören vor allem: Benötigter Speicher, benötigte Prozessorzeit, Kommunikationsschnittstellen zu anderen Anwendungs- oder Ergänzungsmodulen. Durch die Überprüfung der Metadaten kann sichergestellt werden, dass auf einem Steuergerät nicht fälschlicherweise Programmdaten eines Ergänzungsmoduls abgelegt und zur Ausführung gebracht werden, welche dort bei der Ausführung Fehler verursachen. Dieses könnte möglicherweise andere in der Laufzeitumgebung ausgeführte Ergänzungsmodule ebenfalls an einer korrekten Ausführung hindern. Ein bevorzugtes Verfahren zum Ändern oder Ergänzen der Funktionalität eines Fahrzeugsteuergeräts sieht somit eine solche Überprüfung der Metadaten oder, verallgemeinert ausgedrückt, eine Ressourcenprüfung vor.
-
Eine weitere Ausführungsform sieht vor, dass der Programmcode sowie die Metadaten eines Ergänzungsmoduls durch eine kryptographische Hashfunktion, die dem Updatemodul bekannt ist, gesichert werden, so dass versehentliche Veränderungen und damit einhergehende Inkonsistenzen zwischen der Beschreibung der Funktionalität in den Metadaten und der tatsächlichen Umsetzung im Programmcode vom Updatemodul erkannt werden kann. Das Updatemodul kann das korrupte Ergänzungsmodul dann wieder entfernen und/oder dessen Installation verhindern oder abbrechen.
-
Eine weitere Ausführungsform sieht vor, dass der Programmcode, die Metadaten sowie der Wert der Hashfunktion zusätzlich durch eine digitale Signatur, wie sie aus dem Stand der Technik bekannt ist, signiert werden. Dadurch kann das Updatemodul überprüfen, ob das Ergänzungsmodul von einer vertrauenswürdigen Quelle erstellt wurde und dass keine Manipulation des Programmcodes des Ergänzungsmoduls stattgefunden hat.
-
Um die Funktionen eines Fahrzeugsteuergeräts zu erweitern, ist in manchen Fällen jedoch nicht nur eine Kommunikation mit Anwendungsmodulen des eigenen Steuergeräts notwendig, sondern auch eine Kommunikation mit Anwendungsmodulen anderer Steuergeräte und/oder eine Kommunikation mit anderen Ergänzungsmodulen auf anderen Fahrzeugsteuergeräten des Fahrzeugs von Vorteil.
-
In Fahrzeugen werden die Steuergeräte in der Regel über Bussysteme, insbesondere serielle Bussysteme, miteinander verbunden. Am weitesten verbreitet sind so genannte CAN-Bussysteme und Flexray-Bussysteme. Dies sind unterschiedliche mit einem genormten Übertragungsprotokoll ausgestattete Bussysteme. Während bei CAN-Bussystemen die einzelnen versandten Nachrichten eine Kennung aufweisen, die deren Inhalt kennzeichnet, wird auf einem Flexray-Bussystem die für eine Nachrichtenübertragung zur Verfügung stehende Zeit in Zyklen unterteilt. In jedem Zyklus existiert ein Zeitabschnitt, in dem statisch Zeitfenster, so genannte Slots, einzelnen Kommunikationsknoten zugewiesen sind. Ein Zyklus umfasst darüber hinaus einen dynamischen Abschnitt, in dem die unterschiedlichen Kommunikationsteilnehmer priorisiert nach ihrer ihnen zugeordneten Identifikation Nachrichten variabler Länge übertragen können.
-
Ferner sind die einzelnen Steuergeräte in der Regel so ausgelegt, dass eine Anwendung, welche die Kommunikationsschnittstelle steuert, die auf der Kommunikationsschnittstelle eingehenden Nachrichten hinsichtlich ihrer Kennung filtert. So werden nur die Nachrichten, welche Informationen enthalten, die eines der Anwendungsmodule des Fahrzeugsteuergeräts auch tatsächlich auswertet, diesen Anwendungen zu ihrer Verarbeitung zugeführt. Andere Nachrichten werden bereits beim Eingang gefiltert und verworfen. Hierdurch kann die Speicherkapazität, welche zum Zwischenspeichern der Nachrichten benötigt wird, und ein Verarbeitungsaufwand der einzelnen Anwendungsmodule reduziert werden.
-
Um jedoch bei einer Erweiterung der Funktionalität den Ergänzungsmodulen die Möglichkeit zu geben, Nachrichten an andere Fahrzeugsteuergeräte und somit an andere Anwendungsmodule und/oder Ergänzungsmodule in anderen Fahrzeugsteuergeräten zu versenden oder Nachrichten von diesen auszuwerten, ist es bei einer bevorzugten Ausführungsform vorgesehen, dass bereits bei der Herstellung des Fahrzeugsteuergeräts eine oder mehrere Nachrichtenkennungen für Nachrichten von Ergänzungsmodulen reserviert werden, die von dem Steuergerät genutzt werden, um Informationen von Ergänzungsmodulen zu versenden bzw. um Informationen zu diesen zu übermitteln.
-
Bei einer Ausführungsform ist vorgesehen, dass die Kommunikationsschnittstelle eine nachrichtenbasierte Schnittstelle ist und den einzelnen Fahrzeugsteuergeräten Kommunikationskennungen zugeordnet sind und mindestens eine Kommunikationskennung, vorzugsweise eine Gruppe von Kommunikationskennungen, dafür reserviert werden, dass Nachrichten von und zu Ergänzungsmodulen des Fahrzeugsteuergeräts übermittelt und empfangen werden können. Die Kommunikationskennungen können im CAN-Bus als Nachrichtenkennungen verwendet werden. Bei Flexray-Bussystemen kann die Kommunikationskennung als ID verwendet werden.
-
Nachfolgend wird die Erfindung unter Bezugnahme auf eine Zeichnung näher erläutert. Hierbei zeigt:
- 1 eine schematische Darstellung eines in ein Fahrzeug integrierten Fahrzeugsteuergeräts.
-
In 1 ist schematisch ein Kraftfahrzeug 1 mit mehreren darin befindlichen Steuergeräten 11-14 schematisch dargestellt. Die Steuergeräte 11-14 sind über einen Bus 15 kommunikationstechnisch miteinander verbunden. Ferner ist mit dem Bus 15 ein fahrzeugexterner Tester 16 verbunden, über den Diagnose- und Wartungsarbeiten an den Steuergeräten 11-14 des Kraftfahrzeugs 1 vorgenommen werden können. Im normalen Fahrbetrieb ist der Tester 16 selbstverständlich nicht mit dem Kraftfahrzeug 1 verbunden.
-
Von den Steuergeräten 11-14, deren Gesamtanzahl in den Fahrzeugen variieren kann, ist hier eines der Steuergeräte 11 exemplarisch vergrößert dargestellt. Die anderen Steuergeräte 12-14 sind vorzugsweise strukturell ähnlich aufgebaut.
-
Das Steuergerät 11, welches dafür vorgesehen ist, dass dessen Funktionalität nachträglich verändert und/oder erweitert werden kann, umfasst eine Prozessoreinheit 21 und einen hiermit gekoppelten Speicher 22. Ferner umfasst das Steuergerät 11 eine Kommunikationsschnittstelle 25, welche einen Zugriff auf den Fahrzeugbus 15 ermöglicht. Ferner verfügt das Steuergerät über weitere Schnittstellen 26, 27, die mit Sensoren 28, 29 verbunden sind. Anstelle der Sensoren 28, 29 können auch Aktoren, Stellglieder oder Ähnliches mit dem Steuergerät über Schnittstellen verbunden sein. Eine Anzahl der vorhandenen Schnittstellen ist abhängig von der Funktion oder den Funktionen, die das Steuergerät in dem Fahrzeug ausführt.
-
Der Speicher 22 umfasst in der Regel einen Programmspeicherbereich 31 und einen Datenspeicherbereich 32. Diese können hardwaretechnisch unterschiedlich oder gleich, sogar in demselben Speichermodul ausgeführt sein. Der Programmspeicherbereiche 31 muss in jedem Falle ein nicht flüchtiger Speicher sein. Für den Datenspeicher ist Voraussetzung, dass dieser als Lese- und Schreibspeicher geeignet ist. Zur Anwendung kann beispielsweise Flash-Speicher oder EEPROM-Speicher kommen. Als Datenspeicher können jedoch auch Speicherbausteine, welche flüchtige Speicher bereitstellen, wie sie dem Fachmann bekannt sind, verwendet werden.
-
In dem Speicher 22 ist ein Programmcode 40 eines Betriebssystems 41 abgelegt. Dem Betriebssystem ist statisch ein für dessen Ausführung benötigter Daten- oder Arbeitspeicher 42 zugeordnet. Daneben sind in dem Speicher 22 Speicherbereiche für Anwendungsmodule, im dargestellten Beispiel beispielsweise für h-Anwendungsmodule, reserviert und statisch zugewiesen. Jedes der Anwendungsmodule 51-1 bis 51-h umfasst einen Programmcode, der in einem der Programmspeicherbereiche 52-1 bis 52-h in dem Programmspeicher 31 des Speichers 22 abgelegt ist. Jedem Anwendungsmodul ist darüber hinaus ebenfalls ein Bereich des Datenspeichers 53-1 bis 53-h zugewiesen, den das entsprechende Anwendungsmodul als Daten- und Arbeitsspeicher zur Erbringung seiner Funktionalität benötigt. Dadurch, dass jedem Anwendungsmodul 51-1 bis 51-h genau die benötigte Menge an Speicher zur Verfügung gestellt wird, wird sichergestellt, dass es nicht zu einem Ressourcen-Engpass kommt, wenn alle Anwendungsmodule ausgeführt werden. Seiteneffekte wie Wettlaufbedingungen um Ressourcen, z.B. Speicherbereiche, sind von vornherein ausgeschlossen. Das Betriebssystem kann bei einer solchen Ausführungsform auch als ein nahezu gleichwertiges Anwendungsmodul betrachtet werden, welches die Funktion übernimmt, insbesondere die Rechenzeit auf dem Prozessor 21 zwischen den einzelnen Anwendungsmodulen 51-1 bis 51-h zu verteilen.
-
Den einzelnen Anwendungsmodulen 51-1 bis 51-h sind statisch feste Zugriffszeiten auf den Prozessor 21 zugewiesen. Hierdurch kann sichergestellt werden, dass jedes Anwendungsmodul 51-1 bis 51-h die benötigte Prozessorzeit erhält, um seine Funktionalität auszuführen. Zwischen den einzelnen Anwendungsmodulen 51-1 bis 51-h kann eine so genannte Zwischenmodulkommunikation sehr performant durch die Nutzung gemeinsamer Speicherbereiche realisiert werden. Dieses ist auch bei statischer Zuweisung möglich, indem unterschiedlichen Anwendungsmodulen gleiche Speicherbereiche, welche zur Zwischenmodulkommunikation genutzt werden, zugewiesen werden. Darüber hinaus können die Anwendungsmodule 51-1 bis 51-h miteinander in Wechselwirkung treten, indem Funktionsaufrufe zugelassen werden, welches aufgrund der festen Speicherzuweisung durch die unterschiedlichen Anwendungsmodule 51-1 bis 51-h auf einfache Weise möglich ist. Ein solches Vorgehen weist jedoch den Nachteil auf, dass die einer Anwendung zugewiesene Prozessorzeit bei Aufruf einer Funktion eines anderen Moduls insgesamt verlängert wird. Hierdurch kann es dazu kommen, dass eine Funktion des einen Anwendungsmoduls nicht „rechtzeitig fertig“ wird, wenn diese eine Funktion eines anderen Anwendungsmoduls aufruft. Diese Methode der Zwischenmodulkommunikation kann nur verwendet werden, wenn die zusätzliche Ausführungszeit zum Zeitpunkt der Entwicklung genau bekannt ist und diese bei der Zuteilung der benötigten Prozessorzeit berücksichtigt werden kann.
-
Bevorzugt wird jedoch eine Zwischenmodulkommunikation über statisch bereitgestellte so genannte Message-Queues ausgeführt. Dies sind Speicherbereiche, in die auszutauschende Daten in der Form von so genannten Nachrichten (Messages) in eine Warteschlange abgelegt werden. Andere Prozesse können dann asynchron die dort abgelegten Daten abholen und verarbeiten und selber Ergebnisse in Form einer neuen Nachricht in dieselbe oder eine andere Message-Queue (Nachrichtenschlange) ablegen. Eine solche Zwischenmodulkommunikation kann zwar in ungünstigen Fällen, bei denen aus der Message-Queue die Nachrichten nicht zeitgerecht abgeholt werden, zu einem Überlaufen der Message-Queue führen, jedoch beeinträchtigt dies den sendenden, d.h. die Nachrichten ablegenden, Prozess nicht. Sender und Empfänger arbeiten jeweils mit einer eigenen Kopie der ausgetauschten Daten, sodass eine nachteilige gegenseitige Beeinflussung durch inkonsistenten gemeinsamen Zugriff auf denselben Speicher vermieden wird.
-
Während bei Steuergeräten nach dem Stand der Technik für ein Erweitern einer Funktionalität eines Steuergeräts der Programmcode eines der Anwendungsmodule modifiziert werden musste oder Programmcode eines neuen Anwendungsmoduls zugefügt werden musste, ist bei der hier beschriebenen Ausführungsform des Steuergeräts eine andere Realisierung vorgeschlagen. Zum Zeitpunkt der Herstellung des Steuergeräts werden die ursprünglich vorhandenen Anwendungsmodule festgelegt und die von diesem benötigten Speicherbereiche diesen zugewiesen. Ferner wird die jeweils benötigte Prozessorzeit ermittelt und diesen statisch zugewiesen. Verbleibende Ressourcen im Hinblick auf den vorhandenen Speicher als auch im Hinblick auf vorhandene Prozessorzeit werden dem einen Anwendungsmodul, welches hier als Laufzeitumgebungsmodul 61, 51-h bezeichnet wird, statisch zugewiesen. Dieses Laufzeitumgebungsmodul 61 ist so ausgebildet, dass es den Programmcode 72-1 bis 72-i, in der Regel in Form von Skriptcode (SC), interpretieren und in Maschinenbefehle des vorhandenen Prozessors überführen und dadurch die Ergänzungsmodule 71-1 bis 71-i ausführen kann. Ein wesentlicher Vorteil eines solchen Vorgehens besteht darin, dass die ursprünglich in dem Steuergerät 11 vorgesehene Funktionalitäten, welche durch die Anwendungsmodule 51-1 bis 51-h-1 bereitgestellt werden, durch ein Ausführen von Ergänzungsmodulen 71-1 bis 71-i nahezu unbeeinflusst sind. Die Ergänzungsmodule 71-1 bis 71-i können weder auf Speicherbereiche der Anwendungsmodule 51-1 bis 51-h-1 zugreifen, noch deren Prozessorzeit, die ihnen für die Ausführung jeweils statisch zugewiesen ist, beeinträchtigen. Eine Ausführung der Ergänzungsmodule 71-1 bis 71-i, d.h. der Programmcodes 72-1 bis 72-i der jeweiligen Ergänzungsmodule 71-1 bis 71-i, findet nur in der Prozessorzeit statt, die dem Laufzeitumgebungsmodul 61 zugewiesen ist.
-
Während den Anwendungsmodulen 51-1 bis 51-h, einschließlich des Laufzeitumgebungsmoduls 51-h, 61, ein direkter Zugriff auf den Prozessor zu den jeweils festgelegten Zugriffszeiten gewährt wird, wird die für die Ausführung der Ergänzungsmodule 71-1 bis 71-i jeweils zur Verfügung gestellte Ausführungszeit dynamisch durch die Laufzeitumgebung festgelegt. Diese interpretiert den Code und führt diesen in der Laufzeitumgebung aus. Auch der von den einzelnen Ergänzungsmodulen 71-1 bis 71-i jeweils genutzte Datenspeicher 73-1 bis 73-i wird den einzelnen Ergänzungsmodulen 71-1 bis 71-i jeweils dynamisch zur Ausführungszeit der jeweiligen Module zugewiesen. Hierdurch kann ein verbesserter Ressourcenverbrauch realisiert werden. Hierfür kann nur Speicher genutzt werden, der dem Laufzeitumgebungsmodul statisch zugewiesen ist.
-
Bevorzugt sind die Anwendungsmodule 51-1 bis 51-h so ausgebildet, dass diese miteinander über statische Message-Queues (sMqj) 91-1 bis 91-m miteinander kommunizieren. Um den Ergänzungsmodulen die Möglichkeit zu geben, auf Funktionen oder Schnittstellen zugreifen zu können, die die Anwendungsmodule 51-1 bis 51-h-1 bereitstellen, einschließlich eines Zugriffs auf den Datenbus 15, ist es notwendig, dass bei der Konstruktion des Steuergeräts die hierfür erforderlichen Kommunikationsobjekte definiert und bereitgestellt werden.
-
Für eine Zwischenmodulkommunikation der Ergänzungsmodule 71-1 bis 71-i sowie für eine Kommunikation mit den Prozessen der Anwendungsmodule 51-1 bis 51-h-1 ist in der Laufzeitumgebung des Laufzeitumgebungsmoduls 61, 51-h eine so genannte Messagebridge 94 realisiert. Diese stellt eine Zugriffsmöglichkeit der Ergänzungsmodule 71-1 bis 71-i auf die statischen Message-Queues 91-1 bis 91-m zur Verfügung, indem diese in den Datenspeicherbereich 53-h des Laufzeitumgebungsmoduls 61, 51-h eingeblendet werden 92-1 bis 92-m. Zusätzlich können die Ergänzungsmodule 71-1 bis 71-i für die Kommunikation untereinander dynamische Message-Queues 93-1 bis 93-n erzeugen und nutzen.
-
Zusätzlich können sowohl die Prozesse der Anwendungsmodule 51-1 bis 51-h als auch die Ergänzungsmodule 71-1 bis 71-i Parameter definieren, die deren Ausführung beeinflussen und von dem externen Texter 16 ausgelesen und/oder verändert werden können. Während die Parameter für die Anwendungsmodule bereits bei der Herstellung des Steuergeräts hinsichtlich des Typs und Wertebereichs festgelegt werden, brauchen für diese Parameter nur die Speicherbereiche definiert zu werden und statisch zugewiesen zu werden, welche den Parameterwert 101-1 bis 101-k speichern. Diese Parameter werden somit in einem Parameterspeicher 100 abgelegt, der im nicht flüchtigen Speicherbereich, der auch als Programmspeicherbereich 31 dienen kann, des Speichers 22 abgelegt ist. In dem Parameterspeicher 100 können darüber hinaus die Parameter für die Ergänzungsmodule abgelegt werden. Diese werden vorzugsweise als Schlüssel-Wert-Paare abgelegt (Key-Value-Speicherung) 102-1 bis 102-1. Ein Schlüssel-Wert-Paar weist jeweils einen Schlüssel auf, der eindeutig den Parameter charakterisiert und zusätzlich einen Wert und gegebenenfalls einen Typ des Parameters. Über den Schlüssel ist es möglich, auch bei Nichtkenntnis des Speicherortes, an dem das Schlüssel-Wert-Paar abgelegt ist, den entsprechenden Parameterwert aufzufinden, sodass dieser durch das entsprechende Ergänzungsmodul 71-1 bis 71-i genutzt werden kann. Da ein Zugriff der Ergänzungsmodule 71-1 bis 71-i auf Speicherbereiche, die nicht statisch dem Laufzeitumgebungsmodul 61, 51-h zugewiesen sind, nicht zugelassen ist, wird der Parameterwertspeicher 100 in den Speicher des Laufzeitumgebungsmoduls 61, vorzugsweise in den nicht flüchtigen Speicherbereich, abgebildet. Dort existiert somit eine Kopie 110 des Parameterwertspeichers 100, in dem die kopierten Parameterwerte 111-1 bis 111-k sowie die Schlüssel-Wert-Paare 112-1 bis 112-1 als Kopien vorliegen. Alternativ kann auch eines der Ergänzungsmodule 71-1 bis 71-i die Laufzeitumgebung 61 anweisen, auf den Parameterspeicher 100 zuzugreifen und Werte an das Ergänzungsmodul 71-1 bis 71-i zu liefern.
-
Um ein neues Ergänzungsmodul zum Erweitern der Funktionalität oder Ändern der Funktionalität des Steuergeräts 11 in dieses zu integrieren, ist eines der Anwendungsmodule 51-1 bis 51-h-1 als so genanntes Updatemodul 62 ausgebildet. Diese Funktionalität wird häufig durch ein Anwendungsmodul bereitgestellt, welches auch so genannte Unified Diagnostic Services bereitstellt. Dieses Anwendungsmodul 51-1, 62 stellt eine Funktionalität bereit, über die der Tester 16 veranlassen kann, dass an das Steuergerät 11 übermittelter Programmcode 72-1 bis 72-i eines Ergänzungsmoduls 71-1 bis 71-i in den nicht flüchtigen Programmspeicherbereich 52-h des Laufzeitumgebungsmoduls 61, 51-h installiert wird.
-
Bei einer bevorzugten Ausführungsform ist vorgesehen, dass den Ergänzungsmodulen 71-1 bis 71-i jeweils Meterinformationen 74-1 bis 74-i zugeordnet werden, in welchen die benötigten Ressourcen, beispielsweise in Form von benötigten Kommunikationsobjekten, Speicherbedarf, Prozessorleistung usw. angegeben sind.
-
In dem Steuergerät 11 existiert ein Metadatenspeicher 95, in dem die zugehörigen in dem Steuergerät 11 vorhandenen Ressourcen (z.B. noch verfügbarer Speicher 52h, 53h, unbenutzte Prozessorzeit, verfügbare Message-Queues) abgespeichert werden. Bei dem Vorgang des Installierens eines neuen Ergänzungsmoduls 71-1 bis 71-i prüft das Updatemodul 51-1, 62 anhand der übermittelten Metadaten 74-1 bis 74-i des Ergänzungsmoduls 71-1 bis 71-i, ob dieses in dem Steuergerät ausführbar sein wird. Verläuft der Abgleich positiv, so wird der Programmcode 72-1 bis 72-i des Ergänzungsmoduls 71-1 bis 71-i in dem Programmspeicherbereich 52-h des Laufzeitumgebungsmoduls 61 installiert. Andernfalls wird ein Herunterladen des Programmcodes 72-1 bis 72-i abgebrochen, abgewiesen oder eine bereits erfolgte Einspeicherung von Programmcodedaten über ein Löschen des entsprechenden Programmcodes 72-1 bis 72-i rückgängig gemacht. Anhand der dem Ergänzungsmodul 71-1 bis 71-i beigefügten Metadaten 74-1 bis 74-i wird der Metadatenspeicher 95 um jene Ressourcen, z.B. neue Message-Queues, ergänzt, die das entsprechende Ergänzungsmodul 71-1 bis 71-i zur Verfügung stellt. Die weiterhin verfügbaren ungenutzten Ressourcen werden im gleichen Schritt reduziert.
-
Das beschriebene Steuergerät sowie das Verfahren zum Aktualisieren ermöglichen somit eine einfache Anpassung der Funktionalität eines Fahrzeugsteuergeräts 11 und sichern zugleich, dass die bereits in den ursprünglichen Anwendungsmodulen 51-1 bis 51-h bereitgestellte Funktionalität durch die Ergänzungsmodule 71-1 bis 71-i nicht beeinträchtigt wird. Die Anwendungsmodule 51-1 bis 51-h werden bei der ursprünglichen Konzeption bereits so ausgerichtet, dass sie die notwendigen Kommunikationsobjekte (z.B. Message-Queues) bereitstellen, sodass anschließend Ergänzungsmodule 71-1 bis 71-i mit ihnen zusammenwirken können. Um auch eine Kommunikation mit anderen Steuergeräten 12-14 zu ermöglichen, ist es vorteilhaft, wenn bei der Konzeption Nachrichtenkennungen bereits für mögliche zukünftig zugefügte Ergänzungsmodule 71-1 bis 71-i reserviert und bereitgehalten werden bzw. ein Mechanismus vorgesehen ist, über den Ergänzungsmodule 71-1 bis 71-i einer Busschnittstelle 16 mitteilen können, welche Nachrichten von dem entsprechenden Ergänzungsmodul 71-1 bis 71-i für deren Funktion benötigt werden.
-
Es versteht sich, dass lediglich beispielhafte Ausführungsformen beschrieben sind.
-
Bezugszeichenliste
-
- 1
- Kraftfahrzeug
- 11 - 14
- Steuergeräte
- 15
- Bus
- 16
- Tester
- 21
- Prozessor (CPU)
- 22
- Speicher
- 25
- Kommunikationsschnittstelle
- 26, 27
- Schnittstellen
- 28, 29
- Sensoren
- 31
- Programmspeicherbereich
- 32
- Datenspeicherbereich
- 40
- Programmcode des Betriebssystems
- 41
- Betriebssystem des Steuergeräts
- 42
- Arbeitsspeicher
- 51-1 - 51-h
- Anwendungsmodule
- 52-1 - 52-h
- Programmspeicherbereich der Anwendungsmodule
- 53-1 - 53-h
- Datenspeicherbereich der Anwendungsmodule
- 61
- Laufzeitumgebungsmodul
- 62
- Updatemodul
- 71-1 - 71-i
- Ergänzungsmodule
- 72-1 - 72-i
- Programmcode der Ergänzungsmodule
- 73-1 - 73-i
- Datenspeicher/Arbeitsspeicher der Ergänzungsmodule
- 74-1 - 74-i
- Metadaten der Ergänzungsmodule
- 91-1 - 91-m
- statische Message-Queues
- 92-1 - 92-m
- abgebildete (kopierte) statische Message-Queues
- 93-1 - 93-n
- dynamische Message-Queues
- 94
- Messagebridge
- 95
- Metadatenspeicher
- 100
- Parameterspeicher
- 101-1 - 101-k
- Parameterwert
- 102-1 - 102-1
- Schlüssel-Wert-Paare
- 110
- Parameterspeicherkopie
- 111-1 - 111-k
- Parameterwertkopie
- 112-1 - 112-1
- Schlüsselwertepaarkopie
